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

.NET アプリケーションをコンテナ化する

概要:

コンテナは、一貫して再現可能な方法でアプリケーションをパッケージ化およびデプロイするための軽量で効率的な方法です。このセクションでは、サーバーレスコンテナサービスである AWS Fargateを使用して .NET アプリケーションのコストを削減し、スケーラブルで信頼性の高いインフラストラクチャを提供する方法について説明します。

コストへの影響

コスト削減のためのコンテナの使用の有効性に影響を与える要因には、アプリケーションのサイズと複雑さ、デプロイする必要があるアプリケーションの数、アプリケーションのトラフィックと需要のレベルなどがあります。小規模または単純なアプリケーションの場合、コンテナと関連サービスの管理のオーバーヘッドによって実際にコストが増加する可能性があるため、従来のインフラストラクチャアプローチと比較して、コンテナでは大幅なコスト削減が得られない可能性があります。ただし、大規模または複雑なアプリケーションの場合、コンテナを使用すると、リソース使用率を向上させ、必要なインスタンスの数を減らすことでコスト削減を実現できます。

コスト削減のためにコンテナを使用する場合は、次の点に留意することをお勧めします。

アーキテクチャやオペレーティングシステムが異なると、コンテナのコストに影響します。Windows コンテナを使用している場合、ライセンス上の考慮事項により、コストが削減されない場合があります。Linux コンテナでは、ライセンスコストが低くなるか、ライセンスコストがかかりません。次のグラフでは、米国東部 (オハイオ) リージョン AWS Fargate の の基本設定と、4 つの vCPUs と 8 GB のメモリを割り当てた 12 時間実行される 1 か月あたり 30 個のタスクを使用します。

EC2 ベースのコンテナホストとサーバーレスまたは AWSの 2 つのプライマリコンピューティングプラットフォームからコンテナを実行できますAWS Fargate。 EC2-based Fargate の代わりに Amazon Elastic Container Service (Amazon ECS) を使用する場合は、実行中のコンピューティング (インスタンス) を維持し、必要に応じてプレイスメントエンジンがコンテナをインスタンス化できるようにする必要があります。代わりに Fargate を使用する場合、必要なコンピューティングキャパシティのみがプロビジョニングされます。

次のグラフは、Fargate を使用した場合と Amazon EC2 を使用した場合の同等のコンテナの違いを示しています。Fargate の柔軟性により、アプリケーションのタスクは 1 日 12 時間実行でき、オフ時間には使用率をゼロにすることができます。ただし、Amazon ECS の場合は、EC2 インスタンスの Auto Scaling グループを使用してコンピューティングキャパシティを制御する必要があります。これにより、キャパシティが 1 日 24 時間稼働することになり、最終的にコストが増加する可能性があります。

コスト最適化の推奨事項

Windows ではなく Linux コンテナを使用する

Windows コンテナの代わりに Linux コンテナを使用すると、大幅なコスト削減を実現できます。例えば、EC2 Windows で .NET Framework を実行するのではなく、EC2 Linux で .NET Core を実行すると、コンピューティングコストを約 45% 削減できます。x86 の代わりに ARM アーキテクチャ (AWS Graviton) を使用すると、さらに 40% の割引を受けることができます。

既存の .NET Framework アプリケーション用に Linux ベースのコンテナを実行する場合は、Linux コンテナを使用するために、これらのアプリケーションを最新のクロスプラットフォームバージョンの .NET (.NET 6.0 など) に移植する必要があります。重要な考慮事項は、リファクタリングのコストと、Linux コンテナのコスト低下によって得られるコスト削減を比較検討することです。最新の .NET へのアプリケーションの移植の詳細については、 AWS ドキュメントの「Porting Assistant for .NET」を参照してください。

最新の .NET に移行する (つまり、.NET Framework から移行する) もう 1 つの利点は、追加のモダナイズの機会が利用可能になることです。例えば、アプリケーションを、よりスケーラブルで俊敏で、コスト効率の高いマイクロサービスベースのアーキテクチャにリアーキテクトすることを検討できます。

次の図は、モダナイズの機会を探るための意思決定プロセスを示しています。

Savings Plans を利用する

コンテナを使用すると、Compute Savings Plans を活用して Fargate のコストを削減できます。柔軟な割引モデルは、コンバーティブルリザーブドインスタンスと同じ割引を提供します。Fargate の料金は、コンテナイメージのダウンロードを開始した時点から Amazon ECS タスクが終了するまで (最も近い秒に切り上げ) に使用された vCPU およびメモリリソースに基づいています。Fargate の Savings Plans は、1 年または 3 年の期間に特定の量のコンピューティング使用量 (1 時間あたりのドルで測定) を使用するコミットメントと引き換えに、Fargate の使用量に対して最大 50% のコスト削減を提供します。AWS Cost Explorer を使用して Savings Plans を選択できます。

Compute Savings Plans は、最も大きなコスト削減を最初に得られる使用量に適用されることを理解することが重要です。例えば、us-east-2 で t3.medium Linux インスタンスを実行し、同一の Windows t3.medium インスタンスを実行している場合、Linux インスタンスが最初に Savings Plans の特典を受け取ります。これは、Linux インスタンスのコスト削減の可能性は 50% であるのに対し、同じ Windows インスタンスのコスト削減の可能性は 35% であるためです。Amazon EC2 や Lambda など AWS アカウント、他の Savings Plans 対象リソースが で実行されている場合、Savings Plans を最初に Fargate に適用する必要はありません。詳細については、Savings Plans ドキュメント」の「Savings Plans AWS が使用状況にどのように適用されるかを理解する」およびこのガイドのAmazon EC2 での Windows の支出を最適化する」セクションを参照してください。 Savings Plans

Fargate タスクのサイズを適切に設定する

最大限のコスト最適化を実現するには、Fargate タスクのサイズが正しく設定されていることを確認することが重要です。多くの場合、開発者は、アプリケーションで使用される Fargate タスクの設定を最初に決定する際に、必要なすべての使用状況情報を持っているわけではありません。これにより、タスクの過剰プロビジョニングが発生し、不要な支出が発生する可能性があります。これを回避するには、Fargate で実行されているテストアプリケーションをロードして、さまざまな使用シナリオで特定のタスク設定がどのように実行されるかを理解することをお勧めします。負荷テスト結果、vCPU、タスクのメモリ割り当て、自動スケーリングポリシーを使用して、パフォーマンスとコストの適切なバランスを見つけることができます。

次の図は、Compute Optimizer が最適なタスクおよびコンテナサイズの推奨事項を生成する方法を示しています。

1 つのアプローチは、分散負荷テストで説明されているような負荷テスト AWSツールを使用して、vCPU とメモリ使用率のベースラインを確立することです。負荷テストを実行して一般的なアプリケーションの負荷をシミュレートした後、ベースライン使用率が達成されるまでタスクの vCPU とメモリの設定をファインチューニングできます。

その他のリソース