静的 .NET Framework アプリケーションの動的スケーリングをサポート - AWS 規範ガイダンス
概要コストへの影響コスト最適化の推奨事項追加リソース

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

静的 .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 を使用するアーキテクチャを示しています。

セッション状態プロバイダーとしての DynamoDB

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

セッション状態プロバイダーとしての ElastiCache (Redis OSS)

コストへの影響

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

  • ローテーションに追加および削除されるインスタンスは同一であり、インスタンスサイズのバリエーションは導入されません。

  • アプリケーションの高可用性を維持するために、サーバー使用率が 2 つのアクティブなサーバーを下回ることはありません。

  • サーバーの数は、トラフィックに応じて直線的にスケールされます (つまり、トラフィックの 2 倍にはコンピューティングの 2 倍が必要です）。

  • トラフィックは 1 か月にわたって 6 時間単位でモデル化され、1 日内の変動と 10 倍のトラフィックの 1 日分の異常なピーク (プロモーションセールなど) があります。週末トラフィックは、基本使用率に基づいてモデル化されます。

  • 夜間トラフィックは基本使用率でモデル化され、平日トラフィックは 4 倍の使用率でモデル化されます。

  • リザーブドインスタンスの料金では、1 年間の前払いなしの料金が使用されます。通常の日中の料金はオンデマンド料金を使用し、バースト需要はスポットインスタンス料金を使用します。

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

Auto Scaling コストのグラフ

セッション状態ストレージメカニズムとして 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 プロパティ」を参照してください。

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

  • EC2 Image Builder を使用して、完全に設定されたサーバーとアプリケーションを含む AMI を設定します。その後、この AMI を使用して Auto Scaling グループの起動テンプレートを設定できます。

  • AWS CodeDeploy を使用してアプリケーションをデプロイします。CodeDeploy では、Amazon EC2 Auto Scaling と直接統合できます。これにより、アプリケーションのリリースごとに新しい AMI を作成する代わりに使用できます。

追加リソース