.NET アプリのコンテナ化 - AWS 規範ガイダンス
概要コストへの影響コスト最適化の推奨事項追加リソース

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

.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 時間稼働し、最終的にコストが増加する可能性があります。

Fargate の月額コストと EC2 の月額コストの比較

コスト最適化の推奨事項

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

Windows コンテナの代わりに Linux コンテナを使用すると、大幅なコスト削減を実現できます。たとえば、EC2 Windows で .NET Framework を実行するのではなく、EC2 Linux で .NET Core を実行すると、コンピューティングコストを約 45% 削減できますEC2。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 は、最も大きな節約を最初に得られる使用量に適用されることを理解することが重要です。例えば、 で t3.medium Linux インスタンスus-east-2と同じ 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 が最適なタスクとコンテナサイズの推奨事項を生成する方法を示しています。

タスクとコンテナサイズに関する Compute Optimizer の推奨事項

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

追加リソース