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

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

概要

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

コストへの影響

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

コスト削減のためにコンテナを使用する場合は、次の点に注意してください。

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

2 つのプライマリコンピューティングプラットフォームから選択して、 AWSEC2ベースのコンテナホストとサーバーレスまたは でコンテナを実行できますAWS Fargate。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 コンテナを使用すると、大幅な削減を実現できます。例えば、 を実行すると、コンピューティングコストを約 45% 削減できます。NET を実行する代わりに EC2 Linux 上の Core。NET EC2 Windows 上のフレームワーク。x86 の代わりに ARMアーキテクチャ (AWS Graviton) を使用すると、さらに 40% の割引を受けることができます。

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

最新の に移行するもう 1 つの利点 (NETつまり、 から遠ざかる。NET フレームワーク) は、追加のモダナイゼーションの機会が利用可能になることです。例えば、アプリケーションを、よりスケーラブルで俊敏性があり、コスト効率に優れたマイクロサービスベースのアーキテクチャに再設計することを検討できます。

次の図は、モダナイゼーションの機会を検討するための意思決定プロセスを示しています。

Savings Plans を活用する

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

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

適切なサイズの Fargate タスク

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

次の図は、Compute Optimizer が最適なタスクとコンテナサイズのレコメンデーションを生成する方法を示しています。

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

追加リソース