このブログは NewsPicks Advent Calendar 2022 1日目の記事です。
NewsPicksのSREチームでリーダーをしている安藤です。
NewsPicksに入社して1年が経ちましたが、最近は円安により親の顔よりもAWS Cost Explorerを見る毎日です。
ということで、コストの話をしていきたいと思います。
NewsPicksでのコンテナ移行について
NewsPicksでは、Amazon ECSによる全面コンテナ化を進めています。
本丸の共通バックエンドのコンテナ移行は完了し、AWS Dev Day 2022 Japanでも事例として発表させていただきました。
ここで、「当初はマネージドサービスを優先してFargateを利用するつもりだったが、コストメリットの観点からECS on EC2を選択した」という話が意外に反響をいただいたので、一度冷静になってECS on EC2を選ぶメリットや、「大変だ」と言われている運用が本当に大変なのか？を再考してみようと思います。
AWS Dev Day でも「ECS on Fargate」や「EKS on Fargate」の事例紹介があり、ECS on EC2のコンテナワークロードはマジョリティではないかもしれませんが、参考になれば幸いです。
ECS on EC2とは？
AWSのコンテナ関連サービスとして、大きく分けると「オーケストレーション」「実行環境」「イメージレジストリ」が存在します。
AWSユーザーとしてはイメージレジストリにECRを使うことが一般的だと思うので、「オーケストレーション」「実行環境」にそれぞれ2つの選択肢があり、組み合わせで4パターン存在することになります。
- ECS on Fargate
- ECS on EC2
- EKS on Fargate
- EKS on EC2
NewsPicksでは、オーケストレーションにECSを利用し、実行環境としてEC2を選択しているので、ECS on EC2となります。
オーケストレーションにECSかEKSかという選択の比較は、本記事では扱いません。AWSのサービス以上に自由度の高いKubernetesを運用するかどうかの判断になり、現在のNewsPicksではECSでコンテナオーケストレーションの要件を十分満たせているため、ECSを利用しています。
以下、コンテナ実行環境としてFargateを選択するか、EC2を選択するかを考えていきます。
コンテナの実行環境としてFargate or EC2を選択する時の評価基準
コンテナの実行環境としてFargate or EC2を選択する時、メリット・デメリットを考える上で以下の論点が出てくるかと思います。
（他にもあれば、はてブコメントなどで教えてください…！）
- コンピューティングコスト
- 設計上の考慮事項(スケーリングなど)
- 運用コスト
- セキュリティの考慮事項
ワークロードや非機能要件にもよりますが、概ね以下のように整理できるのではないかと思っています。
| Fargate | EC2 | |
|---|---|---|
| コンピューティングコスト | 割高 | 適正 |
| 設計上の考慮事項 | 少ない | 多い |
| 運用コスト | 低い | 高い |
| セキュリティの考慮事項 | 少ない | 多い |
コスト以外はFargateの圧勝のように見えます。実際は、この表だけを見て判断できることはないでしょう。
FargateかEC2を選択する上で、上記1.〜4.のうち、自社のサービス・事業にとって何が重要なのか、その上で何を許容すれば目的を達成できるかを考えることが大切だと思います。
NewsPicksは会員数700万人超のtoCサービスであり、経済ニュースメディアという事業の特性からもトラフィックは多く、コンピューティングコストの適正化は重要視しています。
そこで、金額インパクトを基準に他の論点でのデメリットを許容できるかどうかを考えれば判断できるのではないかと思いました。
今回は、コストにフォーカスして違いを整理してみたいと思います。
実際、Fargateはどれだけ割高なの？
AWS Dev DayでのNewsPicksの発表では、「EC2からECS on Fargateに移行すると同じSLO(サービスレベル目標)を達成するために大きくコストが増えた」と紹介させていただきました。 SLOというのはサービスにかなり依存するため、純粋なコンピューティングリソースに対する価格としてどれくらい違うかということを検証してみたいと思います。
CPU性能の比較
FargateはIntel CPUかARM CPU(Graviton2)を利用できますが、コンテナ移行時のNewsPicksは、C5インスタンスで動いていました。(現在はECS on EC2 でC6iインスタンスで動いています)
よってFargateに移行する場合はIntel CPU同士でどれだけの性能差があるかが検討ポイントになります。
12/1現在、EC2インスタンスで/proc/cpuinfoを調べたところ、インスタンスごとにIntel CPUは以下となっていました。
| インスタンスタイプ | model name |
|---|---|
| m5.large | Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz |
| r5.large | Intel(R) Xeon(R) Platinum 8175M CPU @ 2.50GHz |
| c5.large | Intel(R) Xeon(R) Platinum 8223CL CPU @ 3.00GHz |
| c6i.large/m6i.large | Intel(R) Xeon(R) Platinum 8375C CPU @ 2.90GHz |
| m4.large | Intel(R) Xeon(R) CPU E5-2686 v4 @ 2.30GHz |
Fargateの場合、インスタンスタイプの選択が不要のため、タスクが起動するごとにCPUが変更となる可能性があります。
そのため、以下の簡単なDockerfileで作成したnginxコンテナをECS on Fargateで20タスクデプロイして、CloudWatch Logsに出力されたCPUのmodel nameを集計してみました。
FROM public.ecr.aws/nginx/nginx
RUN sed -i -re "s/(exec)/grep -m1 'model name' \/proc\/cpuinfo;\1/" /docker-entrypoint.sh
nginx公式イメージでは /docker-entrypoint.sh 内のexecコマンドでnginxを起動しているので、そのexecコマンドの前に/proc/cpuinfoのmodel name を標準出力するようにしただけです。
標準出力をCloudWatch Logsに出力していれば、集計が可能です。
20タスク起動した時のCPU/タスク数が以下となります
| model name | タスク数(%) |
|---|---|
| Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz | 17(85%) |
| Intel(R) Xeon(R) Platinum 8175M CPU @ 2.50GHz | 3(15%) |
M5インスタンスのCPUが中心で、R5インスタンスのCPUが少し混ざっていました。（これはもちろんタイミングやリージョン・AZによって変動すると思います）
1年前に確認した時はM4やR4も混ざっていたと思うので、Fargateの利用するCPUもアップデートされていくと思いますが、コンピューティング特化のC5や最新のC6iと比べると、FargateのベースラインのCPU性能は20%程度低下すると考えても良いのではないかと思います。
コンピューティング料金の比較
最新のc6i.largeインスタンスを利用する場合とFargateで同等のvCPU数/メモリを割り当てる場合の料金を比較してみます。
東京リージョンで、12/1時点のオンデマンド料金は以下です。
| 条件 | オンデマンドの時間単価 |
|---|---|
| c6i.large(2vCPU/4GiBメモリ) | 0.107 USD |
| Fargate(2vCPU/4GiBメモリ) | 0.12324 USD |
c6i.largeインスタンスに対して、Fargateの方が15%コストが高いです。
パフォーマンスに対するコスト
上記で確認した結果より、あくまで12/1の現時点ではですが、
- FargateのCPU性能の期待値は最新のコンピューティング向けEC2インスタンスに対して20%減
- Fargateのコンピューティング料金はコンピューティング向けEC2インスタンスに対して15%増
ということが言えるのではないかと思います。 つまり、EC2と同等のCPUパフォーマンスをFargateで出そうとすると、コストは40%アップすると考えても良さそうです。 この結果は、NewsPicksのコンテナ移行で経験した肌感覚ともかなり近いです。
コストに対して、マネージドサービスのメリットが上回るか
Fargateを採用することで、パフォーマンスに対するコンピューティングコスト +40%という料金インパクトは意外に大きいと感じられたのではないでしょうか。
Fargateは設計・運用・セキュリティの考慮事項や工数を削減する素晴らしいマネージドサービスであり、コストの問題がなければ私もぜひ採用したいと思います。
とはいえ、仮にコンピューティングコストが毎月100万円かかっているサービスの場合プラス40万円の価値があるか？は冷静に検討して判断しても良いと思います。もし月数万円しかコンピューティングコストがかからないサービスなら、迷わずFargateを選択して良いと思います。
終わりに
NewsPicksでは、コストの観点からECS on EC2でサービスを運用していますが、当初on EC2のデメリットと考えていた設計や運用の問題は「思っていたほど大変ではなかったのでコストメリットが上回るEC2を採用してよかった」というのが率直な感想です。
とはいえ、GravitonでFargateを利用する場合、今回整理したようなコスト性能差は小さくなる可能性があります。マネージドサービスを積極的に利用してプロダクトの価値を高める活動に集中するため、引き続きFargate採用は狙っていきたいと思います。
ECS on EC2の運用がどれくらい大変なのか？については、12/7の Ops JAWS Meetup#22 でLT発表予定ですので、よければそちらもご覧いただければと思います。