先月末に AWS Fargate が Graviton2 (ARM64) 対応したことで、お下がり感CPUからグッと引き締まり、俄然Fargate採用度が高まりました。
……ので、今ならどっち選ぶの雑談をしつつ、次記事のTerraform編につないでいきたいと思います。
Fargate の躍進
２年前にFargateのCPUをチェックしたことがあって、半年前には、より真面目？に検証し、
要約すると、Fargeteは少なくとも２年以上は 2013年代モノ～ のCPUを採用しており、お世辞にもコスパも性能も良いとは言えない代物でした。ただ、仕組み自体は非常によくできているので、もどかしさが半端ない状態だったというわけです。
そしてようやく先月末、ニュースとしての時系列は前後しますが、Graviton3 が発表されたこと？で、
Fargateにお下がりCPUがやってまいりました。
私も Graviton2 について茶々気味な記事を書きましたが、基本的には良いCPUだと思っていますので、お下がりというか現時点では現役バリバリな条件になったと言っていいでしょう。
Graviton2 搭載 Fargate のコスパ
X86 vs ARM
これによって、どのくらいコスパがよくなったかというと、それは公式の通りです。AWS Graviton2 プロセッサーを搭載した AWS Fargate は、コンテナー化されたアプリケーション向けの Intel x86 ベースの Fargate に比べて 20% 低費用で、コストパフォーマンスが最大 40% 向上しています。
要は性能が数十％上がって、20％安くなったから、合わせて40％の効果ってことですね。CPUについては既に検証済みなので、費用について軽くまとめてみましょう。
| CPU | CostType | $vCPU/h | $MemGB/h | % | |
| Fargate | X86 | Ondemand | 0.05056 | 0.00553 | 100% |
| SavingsPlan | 0.042976 | 0.0047005 | 85.0% | ||
| Spot | 0.01544723 | 0.00168954 | 30.5% | ||
| ARM | Ondemand | 0.04045 | 0.00442 | 80.0% | |
| SavingsPlan | 0.03185 | 0.00348 | 63.0% | ||
| Spot | 未対応 |
※2 SavingsPlan は１年・前払いなし
SavingsPlan のどの支払いオプションでも、X86の削減効果に対してARMの方が 5～6％ 効果が高いことに、AWSの本気が垣間見えます。
X86 の SavingsPlan よりも ARM の Ondemand の方が安価だし、ARM の SavingsPlan はより安い割合だし、CPU強化やCPUガチャ回避も踏まえると少なくとも Fargate においては切り替えを考えるに十分すぎる材料と言えます。
Fargate vs EC2
次に、同じ Graviton2 同士で比べてみます。費用形態が異なるのでザックリ比較ですが、EC2 c6g.large の vCPU=2 , Mem=4GB と合わせて見てみましょう。| CPU | CostType | $/h | % | |
| Fargate 2vCPU 4GB | ARM | Ondemand | 0.09858 | 100% |
| SavingsPlan | 0.07762 | 78.7% | ||
| Spot | 未対応 | |||
| EC2 c6g.large | Ondemand | 0.0856 | 86.8% | |
| SavingsPlan | 0.0707 | 71.7% | ||
| Spot | 0.0349 | 35.4% |
Fargate はコンテナホストとしてのリソースが不要なので、こんなもんでしょう。以前は貧弱CPUのせいで割高感が強かったですが、これならトントンに近い印象です。
ECS on EC2 or Fargate ?
性能・コスパ差が拮抗したとして、ではECSにおいて on EC2 と Fargate どちらを選ぶべきか、の要点を考えてみます。構築
まず構築についてですが、細かい違いは多くあるものの、コード化してしまえば困ることはそうありません。EC2の方が、より選択と工夫の余地があり、Fargateの方がそれなりにシンプルに仕上る感じです。リソース構成の差異については、後でTerraformコードで切り抜いて記述します。
EC2のデメリット
構成で最も異なるのは当然、インスタンスの有無──すなわちAutoscalingGroupの有無ですが、on EC2 にすることでデメリットと考えられる事項がいくつかあります。- AutoscalingGroupやインスタンスの監視
- リソース不足時のインスタンス追加起動時間
- ASGで複数インスタンスタイプ混在時のリソース管理
- リソース増減条件の二重化（ASG, ECS service）
──などです。もの凄く難しいとかは無いんですが、Fargateに比べると何割増しかで、仕組みの把握と調整が必要になります。
この辺をうまく仕上げられるかどうかで、コスパや堅牢性で優位性がひっくり返るくらいの差なんじゃないかな、と思っています。
補足情報の機会
下記のように、そもそものリソース構成が異なるので、- on EC2 : AutoscalingGroup → Instance → ECS Service → Task → Container
- Fargate : ECS Service → Task → Container
複雑さにも関わるので良し悪しは一概に言えないですが、複雑なEC2の方が、より細かく区別や調整を行う余地があると言えます。
CPU / Memory
タスクにおける CPU / Memory のリソース指定は、Fargate は固定値かつ低上限になりますが、EC2 にはそれなりの自由度があります。自由度が高いと、１つのインスタンスに細かく詰め込むなど節約の工夫ができる反面、過剰な余剰リソースを出したり、ホストや別タスクにリスクを負わせることが考えられます。
コスパ面だと、一見EC2の方が安く、構成と運用をキッチリやれればその通りになるでしょう。が、テキトーな調整だとせっかくのFargateとのコスト差以上の余剰リソースを出してしまい、実は高く付いている、ということがあっても不思議ではありません。
コンピューター・リソースの取り扱い知識に自信ニキはEC2、それ以外はFargate安定といったところでしょうか。
Spot と Blue/Green
デプロイの話になりますが、大雑把には「ECSローリング」と「Blue/Green」の２種類があって、キャパシティプロバイダーというリソース種類の選択には「AuroscalingGroup」「FARGATE」「FARGATE_SPOT」の３つがあります。このうち FARGATE_SPOT を含む ECS Service は、Blue/Green デプロイを選択できない、という仕様があります。
そのため、スポット節約大好きマンにとっては、EC2にするか、ECSローリングにするか、という残酷な選択を迫られることになります。なにかしら構成や手順を工夫すれば、なんとかなるかもしれませんが、素直な構成でなくなることは大きいデメリットなので、わりと考えどころになるでしょう。
CPUアーキテクチャ
X86 か ARM かで、イメージビルド環境とコンテナ起動環境のCPUアーキテクチャを揃える必要があるのですが、EC2 or Fargate という点においては、コレに関しては影響がないと言っていいです。ビルド環境はビルド用のイメージの指定をARMに変えるだけで済みます。
EC2ならECS用イメージをARM版で起動するだけですし、Fargateはタスク定義に１項目追加するだけでARMとなります。
今後の展望
EC2 には Graviton3 のインスタンスタイプが控えており、これにより優位性が開くことは確実です。また、仮に Graviton4 が出た時に、Fargate に Graviton3 のお下がりはくるのか。きたとして Graviton2 と 3 は選択式なのか混在ガチャなのか、で多少は揺らぐ面がでてくるでしょう。
ただ、この程度のことで２年毎にあまりフラフラ迷っても仕方ない側面もあります。
大雑把に表現すると、『安定のFargate』『工夫のEC2』といったところで、強いて言うならば、小～中規模はFargate、中～大規模はEC2なイメージで、なかなか拮抗している印象です。
ただ、どちらもそれなりに触るとわかるのですが、切り替えることはそう難しいことではなく、一部の独自の仕組みの表現に悩むくらいになるはずです。
その辺については次記事で触れていこうと思いますが、現時点ではどちらか決め打ちでも悪くないですし、サービス開始前に選択したり、なんならリリース後に変更することも視野に入れて準備しておくことも現実的な範囲だと思います。
Gravitonの躍進１つで結構情勢が変わる感じ、嬉しいやら面倒くさいやらですが、進化に振り落とされないよう頑張っていきまっしょい:-)
