Amazon Web Services ブログ

Amazon ECS on AWS Fargate のコスト最適化チェックリスト

この記事は、シニアソリューションアーキテクトの Charu Khurana とソリューションアーキテクトの John Formento によって寄稿された Cost Optimization Checklist for Amazon ECS and AWS Fargate (記事公開日: 2020 年 10 月 2 日) を翻訳したものです。

AWS Fargate 起動タイプの Amazon Elastic Container Service (Amazon ECS) は、強力なクラウドネイティブのコンテナサービスです。基盤となるインフラストラクチャを管理することなく、コンテナベースのワークロードを数分で作成できます。Fargate はサーバーレスで提供されますが、ワークロードを実行するためのコストをさらに最適化するために、検討できる領域がまだあります。この記事では、Amazon ECS on Fargate 上で動くワークロードを最適化する際に考慮すべき 7 つのトピックを取り上げます。

コストエクスプローラー: 実行時間と使用量の追跡

コストエクスプローラーで Fargate のコストと使用量を表示します。コストエクスプローラーは、Fargate の時間あたりのコストだけでなく、利用時間を深堀りするのに非常に効果的です。

「使用タイプ」フィルターを使用して、ECS on Fargate の時間あたりのコストや利用時間を表示できます。利用料は AWS リージョン別に分類されます。たとえば、us-east-1 の Fargate の vCPU 利用時間を表示するには、検索ボックスに「Fargate」と入力し、USE1-Fargate-vCPU-Hours:perCPU(Hrs) と USE1-Fargate-GB-Hours(Hrs) を入力します。同様に、us-west-2 の Spot でカバーされる Fargate の vCPU 利用時間は、USW2-SpotUsage-Fargate-vCPU-Hours:perCPU(Hrs) でフィルタリングできます。

コストエクスプローラー: タグが付与されていない ECS と Fargate のリソースを表示します。

タグの付与

サービス、タスク定義、タスク、クラスター、コンテナインスタンスなどの Amazon ECS や AWS Fargate のリソースにタグを付与します。これによりコスト配分がより細分化され、ワークロードの可視性が向上し、コンテナ化されたアプリケーションのコストを簡単に検索して特定できるようになります。タグの付与により、プログラムによるインフラストラクチャの管理アクション (スケールインなど) の実装や、リソースレベルのきめ細かな権限の定義にも役立ちます。タグの付与が無い場合、さまざまなチーム、プロダクト、ビジネスユニット、環境などに分散しているインフラストラクチャとコスト全体を体系的に管理をすることは困難です。

タグ機能を使用するには、新しい Amazon リソースネーム (ARN) とリソース識別子 (ID) 形式をオプトインする必要があります。詳細については、「Amazon リソースネーム (ARN) と ID」を参照してください。

さまざまなチーム、プロダクト、ビジネスユニット、環境に分散しているタスク定義、サービス、タスク、クラスターなどの、タグが付与されていないリソースを分析し、コスト削減を実現します。これにより、今まで認識されていなかった実行中のリソースを発見できる場合があります。孤立したリソースはクラウドを利用する上での無駄の原因となり、不要な料金が発生します。以下に示すように、タグが付与されていないアプリケーション全体を「Group by (グループ化の条件)」タグを使用して表示できます。

Savings Plans

Compute Savings Plans を使用して、ECS on Fargate のコストをカバーします。Compute Savings Plans は、コンバーティブル RI と同じ割引を提供する、新しい柔軟な割引モデルです。詳細については、Savings Plans のローンチブログをご覧ください。AWS Fargate の料金は、コンテナイメージのダウンロードを開始してから Amazon ECS タスクが終了するまでに使用される vCPU とメモリリソースに基づいており、最も近い秒単位に切り上げられます。Savings Plans では、1 年または 3 年の期間に一定量のコンピューティングリソース (1 時間あたりのドルで測定) を使用するという契約を結ぶことにより、AWS Fargate の使用料金を最大 66% (2022 年 6 月時点) 節約できます。AWS コストエクスプローラーは Savings Plans の選択を支援し、購入プランをガイドします。

Savings Plans はコスト削減に最適な方法ですが、注意すべき重要な点として、最も節約率が高くなる箇所に最初に適用されます。Savings Plans は、お客様に最大の節約をもたらすように適用されます。EC2 や AWS Lambda など、お客様の AWS アカウントで Savings Plans の対象となる他のリソースがある場合、Savings Plans が最初に Fargate に適用されるとは限りません。

EC2 や Lambda など、お客様の AWS アカウントで実行されている他の Savings Plans 対象リソースがある場合、Fargate リソースが最も節約を受けるとは限りません。Savings Plans はお客様が最も節約できる箇所に適用されます。Savings Plans が AWS の利用料にどのように適用されるかは、こちらで確認してください。

AWS コスト管理ツールは、Fargate やその他の対象サービス全体で Savings Plans の適用範囲を確認するのに最適なオプションです。

注: Compute Savings Plans のサポート対象は EC2、Fargate、Lambda です。

Spot

Fargate Spot を利用することで、お客様はフォールトトレラントな Fargate タスクを実行するためのオンデマンド価格を最大 70％ 節約できます。これは、並列実行可能なタスクだけでなく、高可用性を必要とする Web サイトや API タスクにも最適なオプションです。サービス Auto Scaling ポリシーを設定する場合、常時実行すべき通常のタスクとして最低限の数を指定しておき、その上で Fargate Spot で実行するタスクを追加することで、コスト効率の高い方法でサービスのパフォーマンスを向上できます。Fargate Spot のキャパシティが利用可能になると、スケジューラはあなたの要求を満たすタスクを起動します。Fargate Spot のキャパシティが利用できなくなった場合、Fargate Spot はアプリケーションの可用性を確保するために通常のタスクの最小数を維持しながらスケールインします。このような種類のワークロードを実行するには、FARGATE_SPOT キャパシティプロバイダーを使用します。詳細については Fargate Spot の紹介ブログと DiveDeep ブログをご覧ください。

Fargate Spot には入札価格はありません。利用可能なキャパシティにのみ依存します。予期せぬ中断をハンドリングできるタスク設計を行うように意識してください。タスクの終了通知は 2 分前に受信します。

タスクの適切なサイジング

Fargate タスクの適切なサイジングは、コストを最適化するための重要なステップです。アプリケーションを構築して Fargate のタスクを設定した後、構成について再検討されることはあまりありません。そのため Fargate タスクが過剰にプロビジョニングされ、不要な支出が発生する可能性があります。Fargate 上で動作するアプリケーションに負荷テストを行って、特定のタスクの設定が負荷テストのシナリオごとにどのように動作するかを理解する必要があります。次に、Auto Scaling ポリシーとともに、タスクに対する vCPU とメモリの割り当てを微調整して、パフォーマンスとコストのバランスが適切になるようにします。適切なサイジングを支援するために、Container Insights と組み合わせて使用できるシンプルな CloudWatch ダッシュボードテンプレートがあります。テンプレートは GitHub にホストされています。

ここ (AWS での分散負荷テスト) で紹介されているような負荷テストツールを使用して、vCPU とメモリの使用率について満足できるベースラインを決定するアプローチもあります。負荷テストを実行してアプリケーションの典型的な負荷をシミュレートし、ベースラインの使用率に達するまでタスクの vCPU とメモリの構成を微調整します。

Auto Scaling

ECS on Fargate の Auto Scaling ポリシーを正しく設定することは、コストを最適化するための手段となります。ECS クラスター上のサービスが不要なスケーリングを行わないようにすることで、コスト効率につながります。ECS on Fargate のサービス設定で Auto Scaling を微調整するには、アプリケーションのベースラインのパフォーマンスと、負荷がかかっている状態のアプリケーションのパフォーマンスを把握することが重要です。アプリケーションパフォーマンスの全体像が見えると ECS on Fargate の Auto Scaling 設定を微調整できます。Fargate では、次のタイプのスケーリングが可能です。

  • ターゲット追跡スケーリングポリシー
    • 特定のメトリクスのターゲット値に基づいて、サービスが実行するタスク数を増減させます。これはサーモスタットが家の温度を維持する方法に似ています。温度を選択すれば、後はサーモスタットがすべてを実行します。
  • ステップスケーリングポリシー
    • アラーム超過のサイズに応じて変動する一連のスケーリング調整値 (ステップ調整値) に基づいて、サービスが実行するタスク数を増減させます。
  • スケジュールに基づくスケーリング
    • 日付と時刻に基づいてサービスが実行するタスクの数を増減させます。

現在の負荷に必要な数よりも、多い / 少ないタスクがサービス内で実行されないようにする効率的なスケーリングが目標です。たとえば、CPU を集中的に使用するアプリケーションでは CPU 使用率を 75% に設定し、その CPU メトリクスを維持するためのターゲット追跡スケーリングポリシーを設定することができます。スケーリングは、あるアプリケーションではうまく機能するものが別のアプリケーションでは機能しない可能性があるため、ユースケース別で見なければなりません。注意点としては、タスクが healthy な状態でオンラインになるまでにかかる時間のメトリクスを収集し、それをスケーリング設定に反映させることです。

Application Load Balancer

Amazon ECS サービスで複数のロードバランサーターゲットグループのサポートの機能により、EC2 または AWS Fargate のいずれかで実行されている単一の Amazon ECS サービスを、複数のターゲットグループにアタッチできます。ターゲットグループは、ロードバランサーを使用するときに 1 つ以上の登録済みターゲットにリクエストをルーティングするために使用されます。サービスに複数のターゲットグループをアタッチすると、インフラストラクチャコードを簡素化し、コストを削減し、ECS サービスの管理性を向上させることができます。これにより、内部ロードバランサーと外部ロードバランサーの両方からのトラフィックを処理できる単一の ECS サービスをメンテナンスできます。また、たとえば内部トラフィックと外部トラフィックをサーバーに送信する 2 つのサービスのコピーを用意することなく、1 つのサービスを維持できます。こちらのブログで上記のアプローチについて詳しく説明しています。重要なこととして、複数のロードバランサーの背後にサービスを配置すると Blast Radius が大きくなり、管理が複雑になる可能性があります。

サービスのスケジューリング

開発やテストなど、本番以外での環境ではタスクを常時実行しても意味がない場合があります。タスクを実行、または停止するタイミングをスケジュール設定することは、コストを最適化する簡単な方法です。たとえば、営業時間外にアプリケーション開発に取り組んでいるチームがいない場合、タスクを確実に停止するための自動化されたスケジュールを設定することは非常に効果的です。スケジュールされた ECS サービスの実装を始めるのに簡単な方法は、ECS on Fargate サービスのスケジュールに基づくスケーリング設定を活用することです。これにより、営業時間外にサービスをスケールインし、開発者がサービスを利用して開発を行うときに再開することができます。

バッチアーキテクチャパターンで動作する ECS on Fargate タスクがある場合は、タスクスケジューリングを活用できます。ECS は cron のようなスケジュール機能と、さまざまなカスタムスケジューラで実行中のタスクをサポートします。このアプローチでは、タスクを待機させておくのではなく、EventBridge ルールに基づいてタスクを開始し、必要なときにだけタスクを実行できます。

まとめ

この記事では Amazon ECS on AWS Fargate のコスト最適化に取り組む際に、考慮すべき 7 つの異なる方法を紹介しました。各トピックについて検討を行い、お客様のワークロードにとって意味があるかどうかを判断することは非常に重要です。繰り返しになりますが、これら 7 つのアプローチを使用したコスト最適化は万能のアプローチではなく、この記事で取り上げた方法以外にも他の方法を見つけることができます。例として、ワークロードが中断を許容できない場合、AWS Fargate で Spot を活用することは賢明な選択ではありません。特定のワークロードについて、個別に方法を検討することが、コスト最適化の鍵となります。

訳注

2021 年 11 月に、AWS Fargate の AWS Graviton2 のサポートを発表しております。コスト最適化の選択肢の 1 つとしてこちらもご検討ください。

翻訳はソリューションアーキテクトの加治が担当しました。原文はこちらです。