静的 の動的スケーリングをサポートします。NET フレームワークアプリケーション - AWS 規範ガイダンス

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

静的 の動的スケーリングをサポートします。NET フレームワークアプリケーション

概要

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

レガシー .NET ウェブアプリケーションをクラウドに持ち込む場合 (例: ASP。NET IIS) で実行されているフレームワークアプリケーションは、アプリケーションのステートフルな性質上、ロードバランシングされたサーバーファームをすばやくスケーリングすることは困難または不可能な場合があります。ユーザーセッションデータは、アプリケーションのメモリ内に保存されます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 SDK for .NET ドキュメントの What is the AWS SDK for .NET のガイダンスに従ってください。DynamoDB を使用している場合は、「」のガイダンスに従ってくださいElastiCache ASP。NET デベロッパーツールブログのセッションストア。 AWS

アプリケーションが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 ドキュメントのSystemWebSectionGroupMachineKey 「.Property」を参照してください。

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

追加リソース