翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# での ASP.NET Web Forms アプリケーションの HA と自動スケーリング AWS
<a name="ha-scaling"></a>

レガシー ASP.NET Web Forms アプリケーションを に移行する場合 AWS、高可用性の実現が重要な考慮事項です。Amazon EC2 Auto Scaling グループとロードバランサーを使用して、複数の EC2 インスタンスにトラフィックを分散できます。ただし、多くの ASP.NET Web Forms アプリケーションはセッションの状態に大きく依存するため、本質的にステートフルになります。デフォルトでは、サーバーは生成されたセッション IDs をメモリに保存し、Cookie を介してクライアントに ID を返します。このアプローチは、複数の EC2 インスタンスで同じアプリケーションを実行しようとすると問題になります。これは、各インスタンスが独自のセッション状態を維持し、ユーザーエクスペリエンスに一貫性がなく、データが失われる可能性があるためです。

この課題に対処し、移行した ASP.NET Web Forms アプリケーションがセッション状態を維持しながら複数のインスタンスにシームレスにスケールできるようにするには、スティッキーセッションを有効にするか、共有バッキングストレージを使用するという 2 つの主なオプションがあります。

## &ALB のスティッキーセッションを有効にする
<a name="sticky-sessions"></a>

では AWS、*セッションアフィニティ*とも呼ばれる[スティッキーセッション](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/edit-target-group-attributes.html#sticky-sessions)を使用するように Application Load Balancer を設定できます。スティッキーセッションを有効にすると、Application Load Balancer は後続のリクエストを同じクライアントから同じ EC2 インスタンスにルーティングします。これにより、アプリケーションとのやり取りを通じてユーザーのセッション状態が維持されます。

このアプローチは簡単なソリューションを提供しますが、スケーラビリティと耐障害性には制限があります。EC2 インスタンスが失敗するか使用できなくなった場合、スティッキーセッションは中断され、ユーザーのセッション状態は失われます。さらに、スティッキーセッションにより、インスタンス間で負荷分散が不均等になり、リソースの競合や使用率の低下が発生し、アプリケーションの効果的なスケーリング能力が制限される可能性があります。このような理由から、代わりにセッションストレージに共有バッキングストアを使用することをお勧めします。

## セッションストレージに共有バッキングストアを使用する
<a name="backing-store"></a>

ステートフルな ASP.NET Web Forms アプリケーションを に移行するための推奨アプローチ AWS は、セッションストレージに共有バッキングストアを使用することです。アプリケーションは、個々の EC2 インスタンスでインメモリセッション状態に依存する代わりに、[Amazon DynamoDB](https://github.com/aws/aws-dotnet-session-provider/)、Amazon [Amazon Relational Database Service RDS) for SQL Server](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_SQLServer.html)、[Amazon ElastiCache (Redis OSS)](https://aws.amazon.com/blogs/developer/elasticache-as-an-asp-net-session-store/) などの高可用性でスケーラブルなストレージソリューションにセッションデータを保存できます。

共有バッキングストアを使用する場合、個々の EC2 インスタンスからセッション状態を切り離して、アプリケーションがセッションデータを失うことなく複数のインスタンスにシームレスにスケールできるようにします。このアプローチは、セッションデータがアプリケーションインスタンスとは独立して保持されるため、耐障害性も向上します。これにより、インスタンスが失敗しても、またはスケーリングイベント中にユーザーセッションが失われることがなくなります。

Redis をセッションストレージの共有バッキングストアとして使用するように ASP.NET Web Forms アプリケーションを設定するには：

1. クラスターの新しいセキュリティグループを作成します。セキュリティグループは、TCP ポート 6379 を使用する Redis へのインバウンドリクエストを許可する必要があります。

1. 新しい Redis クラスターを起動します。最初のステップで作成したセキュリティグループを必ず指定してください。

1. 作成したインスタンスのエンドポイントアドレスを取得します。アドレスが使用可能になるまで、クラスターが起動するまで数分待つ必要があります。

1. `web.config` ファイルを変更し、次の設定を追加します。

   ```
   <sessionState mode="Custom" customProvider="RedisStateStore">
     <providers>
       <add name="RedisStateStore" type="Microsoft.Web.Redis.RedisSessionStateProvider"
            host="[YourRedisClusterEndpoint]"
            accessKey=""
            ssl="true" />
     </providers>
   </sessionState>
   ```

   を ElastiCache (Redis OSS) クラスターの適切な値`[YourRedisClusterEndpoint]`に置き換えます。

セッションストレージ用の共有バッキングストアを実装することで、移行した ASP.NET Web Forms アプリケーションに での高可用性、スケーラビリティ、耐障害性を提供できます AWS。このアプローチはクラウドネイティブのベストプラクティスに沿ったもので、アプリケーションが複数の EC2 インスタンスまたはアベイラビリティーゾーンにまたがってスケーリングされる場合でも、シームレスなユーザーエクスペリエンスを実現します。さらに、スティッキーセッションよりも堅牢で信頼性の高いソリューションを提供し、アプリケーションが AWS インフラストラクチャが提供するスケーラビリティと回復力を最大限に活用できるようにします。