Amazon ECS Fargate/EC2 起動タイプでの理論的なコスト最適化手法

この記事は、 Theoretical cost optimization by Amazon ECS launch type: Fargate vs EC2 を翻訳したものです。

本ブログは Julia Beck, Thomas Le Moullec, Kevin Polossat, and Sam Sanders によって投稿されました。

お客様から、 Amazon Elastic Container Service (Amazon ECS) のベストプラクティスについてご質問をいただくことがよくあります。特に、 Well-Architected Framework の コスト最適化 の柱に注目されるケースがあります。こちらに関する大きな要因の 1 つには、お客様が EC2 もしくは Fargate 起動タイプという選択肢をとることができるという点が考えられます。2019年には Fargate 起動タイプについて 最大50%の値下げ が発表され、また現在は Fargate Spot や Savings Plan も発表されており、大きく節約することが可能です。これらの考慮事項を踏まえて、 2 つの起動タイプにおけるコスト最適化パターンを理解することが重要になる場合があります。

このブログでは Amazon ECS で利用可能な 2 つの起動タイプについて探り、 EC2 と Fargate の料金ページをもとに ECS 上でコンテナワークロードを稼働させた場合のコストの差を比較します。なお、 Fargate タスクは Amazon EKS 上でも利用することが可能であり、また多くの共通的な考慮事項が存在するため、このブログの情報は Amazon EKS においても活用できます。しかしながら、本ブログでは簡潔さを目的とし、 Amazon ECS のデプロイオプションと用語体系のみをカバーします。

またとても重要なポイントとして、このブログでは純粋な利用料金のみを比較対象としています。運用コストなどは全体コスト比較を行う上でとても重要な要素ですが、このブログには含まれていません。それらの複数の運用要素については、こちらの ブログ記事 (Saving money a pod at a time with EKS, Fargate, and AWS Compute Savings Plans) を参照してください (参照先の記事では EKS について言及されていますが、多くの要素を ECS での検討に活用できます)。

ECS の起動タイプとは？

Amazon ECS は、コンテナクラスターの構築と管理のためのコンテナオーケストレーションサービスです。独自の設定や管理、管理ツールのスケーラビリティを意識することなく、クイックなデプロイを実現し、コンテナワークロードのスケーラビリティを確保することが可能です。

ECS は EC2 と Fargate の 2 つの起動タイプをサポートします。コンテナクラスターはどちらか 1 つのタイプ、あるいはタイプが混在した環境を選択でき、それぞれの起動タイプの様々な料金オプションを活用できます。 EC2 起動タイプでは、クラスターは Amazon Elastic Compute Cloud (EC2) インスタンス群を利用します。この場合、あなたの環境をより細かく制御・カスタマイズすることが可能です。また、要件に合わせて様々な選択肢(ネットワーク最適化や GPU 最適化インスタンスなど)をとることができる代わりに、インスタンス群の維持やパッチ適用、インスタンスタイプの選択、ネットワーキング、そしてインスタンスのセキュリティなど、様々な責任を担う必要があります。

Fargate 起動タイプでは、サーバーレイヤーが抽象化されているため、コンテナ化されたアプリケーションの開発とメンテナンスに集中できます。 Fargate は、開発者をサーバーの構築や管理といった作業から開放します。タスクごとのシンプルなリソースを定義するだけで良く、またアプリケーションごとに独立した環境となるよう設計されているため、セキュリティを向上できます。 ECS は Fargate と連携して、コンテナの起動や実行、管理を、あなたの代わりに行います。

料金に基づく比較

EC2 起動タイプにおける料金は、メモリやキャパシティにをもとに選択されたインスタンスタイプによって決定されます。つまり、ワークロードでどれだけリソースを使ったかによらず、インスタンスの全ての料金を支払うことになります。一方 Fargate は、リソースの要求により近い形の料金モデルを提供します。 Fargate ワークロードはタスクごとに指定された CPU /メモリの量に応じて課金され、 AWS は抽象化されたインフラレイヤー上でタスクに割り当てられたリソースを管理します。特定の閾値までは、 Fargate で設定された料金モデルにおけるコスト効率が、 EC2 起動タイプを上回ります。しかし、そのポイントを超えると、 EC2 インスタンス群のコスト効率が Fargate を上回ります。この境界の定義が本ブログで注目する点ですが、 Amazon ECS Capacity Providers を利用して両方の起動タイプを利用できるため、どちらかの選択肢に限定されているわけではないことに注意してください。

本ブログでは、理論上での比較を行うため m5.8xlarge EC2 インスタンスを起動した場合の料金と、 Fargate クラスタ上で同程度の CPU とメモリを搭載したタスクを実行した場合の料金の比較から開始します。 m5.8xlarge は、汎用的な用途で利用可能なインスタンスタイプであり、コンテナを実行するときに良く採用される選択肢ですが、後述する説明は一般的なもので、様々なワークロードやインスタンスファミリーで適用可能です。

Fargate の料金ページ によると、 Fargate 起動タイプはタスクのサイズに基づいています。 Fargate のタスク定義によってリクエスト可能な vCPU とメモリの量は、いくつかの設定に制限されており、それぞれが料金と比例します。サポートされている設定のリストは下記の通りです。

なお、ここでは、 EC2 起動タイプにリソースの余剰や不足がなく、 100% のリソースが利用可能であるとしています。ただし、実際にはあまり現実的でない仮定であり、完全なタスク配置戦略を必要とします。より詳しい情報については、 over-subscription や task placement strategies を参考にしてください。

EC2 起動タイプでは運用やその他のコストがかかるため、それらを単純化した仮定を行うことが重要です。例えば、 EC2 起動タイプでは、開発者は EC2 インスタンス群そのものスケールの管理や、インスタンスタイプやサイズ、ディスクなどの構成の管理に、時間や労力をかける必要がある場合があります。 EC2 インスタンス群への負荷が変動するシナリオで、後述するコスト最適化に向けて EC2 を構成すると、この比較で取りあげていない課題が発生する可能性があります。また、 EC2 起動タイプでは、 Amazon EBS のストレージ料金は含まれていませんが、 Fargate の料金には含まれています。全体のコスト比較では、これらのポイントに考慮に入れる必要があります。

このセクションでは、 Fargate クラスター上で 8 つのタスクを起動した場合と、 8 つのタスクを起動するために必要なリソースを持った 1 台の EC2 インスタンスを利用した場合のコストを比較します。なお、比較が目的であるため 1 台のインスタンスとしていますが、 4 台の m5.2xlarge は 1 台の m5.8xlarge と同じコストであるため、ベストプラクティスは複数の Availability Zone に分散して配置し、耐障害性を向上することとなります。

このインスタンスで実行されている 8 つのタスクは、タスクサイズに応じてインスタンスのリソースの一部を利用します。本ブログでは、 CPU 予約率やメモリ予約率などの EC2 リソースの利用割合を、下記のように計算します。

* メモリ予約率 = (タスク数 * タスクごとのメモリサイズ) / (EC2 インスタンスのメモリサイズ)
* CPU 予約率 = (タスク数 * タスクごとの vCPU サイズ) / (EC2 インスタンスの vCPU ユニット数)

下記のグラフでは、与えられたメモリ予約率と CPU 予約率をもとに、 EC2 と比較した Fargate のコスト効率性を Y 軸に表現しています。 0 以上であれば、 EC2 より Fargate がコスト効率が良いことを示し、 0 以下であればその逆が当てはまります。計算は、 Fargate のタスク定義がサポートするコンピュートリソースの全域 (0.5 vCPU, 1 vCPU, 2 vCPU, and 4 vCPU) と、それに対応するメモリ構成にわたって実行されています。

左側の 1 つ目のバーを例に挙げてみると、 EC2 のメモリと vCPU の予約率がそれぞれ 6.25% と 12.5% であり、 Fargate が EC2 と比べて87%のコスト削減を実現できていることがわかります。一方、 EC2 のリソースが完全に使用されている場合、 EC2 起動タイプは 20% 以上ものコスト削減を実現しています。

ご覧の通り、 Fargate 起動タイプの優位性は、コンピュートとメモリの使用状況がインスタンスのキャパシティに近づくにつれて減少します。安定かつ予測可能なワークロードでインスタンスの CPU とメモリの使用率を高いレベルに保つことができれば、タスクにとって最適なインスタンスタイプの選定が簡単になるため、 EC2 の方がよりコスト効率性のある選択肢となりえます。

極めて動的なワークロードで、 EC2 インフラストラクチャの適切なサイジングとスケーリングがプロビジョニングの不足/余剰のリスクを招く場合は、 Fargate が提供するコストと運用の柔軟性が価値となりえます。

さらなる料金オプション

持続的かつ予測可能なタスクであれば、必要なタスクキャパシティに合わせて最適なインスタンスタイプを選択することができるため、結果として同じキャパシティの Fargate と比べてコストを最適化できます。また、ここまでは、オンデマンド利用のみを考えてきました。 Savings Plans では、1 または 3 年の期間のコンピュート利用のコミットによって、継続的なワークロードを実行する EC2 と Fargate で必要とされるコストを削減できます。下記に、それぞれの起動タイプにおける Savings Plans の効果を示します。なお、下記では同じ Savings Plans が EC2 と Fargate の双方に適用されていますが、利用者はそれぞれの Savings Plans を個別に申し込む必要はありません。

上記の図は、3 年全額前払いにおける Savings Plans for EC2 と Savings Plans for Fargate の料金の違いを示しています。高い CPU 使用率を実現できる場合、 Savings Plans を利用していない場合と比べてより高いコスト効率性を実現できます。必要となるコンピュートリソースを予測可能な状況下においては、 Savings Plans のコスト削減効果によって EC2 起動タイプのコストをさらに最適化できます。

中断性を考慮した設計となっているアーキテクチャでは、オンデマンドと比べて最大 70% のコスト削減を実現するスポットインスタンスの利用が効果的です。より詳しい情報については、Deep dive into Fargate Spot to run your ECS Tasks for up to 70% less を参考にしてください。

上記の図は、それぞれの起動タイプでスポットを使って 8 つのタスクを起動した場合の差を示しています。なお、ある時点のスポット価格の値を取得して計算していますが、スポット価格は長期の需要と供給によって異なるため、それぞれのケースで少し異なる結果となる可能性がある点に注意してください。閾値が少しずれていますが、オンデマンド料金と比較すると今回は Fargate ベースのワークロードが優位です。そのため、ワークロードがフォールトトレラントである場合、 Fargate Spot による大きなコスト削減によって、さらにコストを最適化できます。しかしながら、起動タイプを択一的に見るのではなく、それぞれが補完するコスト効果を共に利用することでさらなる効果を産むことができます。

このグラフは、 Fargate と EC2 の起動タイプのそれぞれの料金オプションとそれぞれのメモリ予約率をもとにしたコストの差を示しています。ご覧のとおり、料金プランによる Fargate のコスト最適化の違いはありませんが、メモリと CPU の予約率の向上に伴って違いが顕著になります。つまり、どの料金プランを選択したとしても上記の結論が当てはまります。インスタンスのキャパシティ使用率が高いほど、 EC2 起動タイプのコスト効率が高くなります。しかし、ワークロードにとって最適な料金モデルを選択することで、さらにコストを最適化できます。

まとめ

本ブログでは、 ECS の Fargate と EC2 という 2 つの起動タイプにて理論上でのコスト比較について考えました。クラスターの使用率を最大化できた場合、 EC2 の利用に優位性があり、特定の閾値を下回る場合は Fargate に利点があることを述べました。しかしながら、技術選定を行う場合には、コストとその他の柱のトレードオフの管理に対する検討や、技術的要件を満たす必要があります。例えば、パフォーマンス効率の柱にはいくつかの構成要素 (ディスクタイプ, GPU など) があり、 EC2 起動タイプの選定によって大きな効果が得られる場合があります。一方で、お客様は Fargate の採用と運用上の優秀性の柱を中心とした最適化によって、生のコストを考慮してもより高い価値を実現できます。コンテナのベストプラクティスガイドによるアーキテクチャ選定を行うことで、それぞれの柱のバランスを保つことができます。最終的に、一方、または両方の起動タイプの選択は、お客様のユースケースに強く依存します。

翻訳はソリューションアーキテクト石本 (いしもと) が担当しました。