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

静的 .NET Framework アプリケーションの動的スケーリングをサポートする

概要:

アプリケーションにクラウドを使用する主な利点の 1 つは、伸縮性、つまり需要に基づいてコンピューティングをスケールインまたはスケールアウトする機能です。これにより、ピーク時の使用量に合わせてプロビジョニングするのではなく、必要なコンピューティングキャパシティに対してのみ支払うことができます。オンライン小売業者が通常の何倍ものトラフィック (例えば、数分以内に数千パーセント) をすぐに取得できるサイバーマンデーは、伸縮性の良い例です。

レガシー .NET ウェブアプリケーション (IIS で実行されている ASP.NET Framework アプリケーションなど) をクラウドに持ち込む場合、アプリケーションのステートフルな性質上、負荷分散されたサーバーファームを迅速にスケーリングすることは困難または不可能な場合があります。ユーザーセッションデータは、通常、ASP.NET セッション状態または持続する必要がある相互要求データを保持する静的変数を使用して、アプリケーションのメモリ内に保存されます。ユーザーセッションのアフィニティは、通常、ロードバランサーのスティッキーセッションを通じて維持されます。

これは運用上困難であることが判明しています。キャパシティを増やす必要がある場合は、意図的にサーバーをプロビジョニングして追加する必要があります。これは時間のかかるプロセスになる場合があります。パッチ適用や予期しない障害が発生した場合にノードをサービス停止にすると、エンドユーザーエクスペリエンスに問題が発生し、影響を受けるノードに関連付けられているすべてのユーザーの状態が失われる可能性があります。これにより、うまくいっても、ユーザーは再度ログインする必要が出てきます。

ASP.NET アプリケーションのセッション状態を一元化し、Auto Scaling ルールをレガシー ASP.NET アプリケーションに適用することで、クラウドの伸縮性を活用でき、場合によってはアプリケーションの実行時にコスト削減を活用できます。例えば、コンピューティングのスケーラビリティによりコストを削減できますが、リザーブドインスタンスの使用量の削減や Amazon スポットインスタンスの料金表の使用など、利用可能なさまざまな料金モデルから選択することもできます。

2 つの一般的な手法には、セッション状態プロバイダーとして Amazon DynamoDB を使用することと、ASP.NET セッションストアとして Amazon ElastiCache (Redis OSS) を使用することが含まれます。

次の図は、セッション状態プロバイダーとして DynamoDB を使用するアーキテクチャを示しています。

次の図は、セッション状態プロバイダーとして ElastiCache (Redis OSS) を使用するアーキテクチャを示しています。

コストへの影響

本番アプリケーションのスケーリングの利点を判断するには、実際の需要をモデル化することをお勧めします。このセクションでは、サンプルアプリケーションをモデル化するために次のように仮定します。

次の図は、このモデルがピーク時の使用のためにプロビジョニングするのではなく、.NET アプリケーションで伸縮性を活用する方法を示しています。これにより、約 68% のコスト削減になります。

セッション状態ストレージメカニズムとして DynamoDB を使用する場合は、次のパラメータを使用します。

Storage: 20GB
Session Reads: 40 million
Session Writes: 20 million
Pricing Model: On demand

このサービスの推定月額コストは、1 か月あたり約 35.00 USD です。

セッション状態ストレージメカニズムとして ElastiCache (Redis OSS) を使用する場合は、次のパラメータを使用します。

Number of Nodes: 3
Node size: cache.t4g.medium
Pricing Model: 1y reserved

このサービスの推定月額コストは、1 か月あたり約 91.00 USD です。

コスト最適化の推奨事項

最初のステップは、レガシー .NET アプリケーションにセッション状態を実装することです。ステートストレージメカニズムとして ElastiCache を使用している場合は、 AWS デベロッパーツールブログの ASP.NET セッションストアとして ElastiCache のガイダンスに従ってください。DynamoDB を使用している場合は、 SDK for .NET ドキュメントの What is the AWS SDK for .NETのガイダンスに従ってください。

アプリケーションが最初に InProc セッションを使用する場合は、セッションに保存する予定のすべてのオブジェクトをシリアル化できることを確認してください。これを行うには、SerializableAttribute 属性を使用して、インスタンスがセッションに保存されるクラスを修飾します。例えば、次のようになります。

[Serializable()] 
public class TestSimpleObject { 
public string SessionProperty {get;set;}
}

さらに、.NET MachineKey は使用中のすべてのサーバー間で同じである必要があります。これは通常、インスタンスが共通の Amazon マシンイメージ (AMI) から作成された場合です。例えば、次のようになります。

<machineKey
validationKey="some long hashed value"
decryptionKey="another long hashed value"
validation="SHA1"/>

ただし、ベースイメージが変更された場合は、同じ .NET マシンイメージ (IIS またはサーバーレベルで設定可能) で設定されていることを確認することが重要です。詳細については、Microsoft ドキュメントの「SystemWebSectionGroup.MachineKey Property」を参照してください。

最後に、スケーリングイベントに応じて Auto Scaling グループにサーバーを追加するメカニズムを決定する必要があります。これを行うには、いくつかの方法があります。Auto Scaling グループの EC2 インスタンスに .NET Framework アプリケーションをシームレスにデプロイするには、次の方法をお勧めします。

その他のリソース