ECSのコストのケチり方

AWS10分LT会 - vol.4
https://aws-likers.connpass.com/event/322723/

Transcript

1. ECSのコストのケチり方 2024/07/17 AWS10分LT会 vol.4 みんなのマーケット株式会社 石橋翔太
2. 自己紹介 名前: いしばし(石橋翔太) Xなど: @kefi550 所属: みんなのマーケット株式会社 の SRE 好きなAWSサービス: AWSサポート、AWS CloudFormation 2
3. コストをケチるためにはECS on EC2を使いましょう いくつかコスト削減に関する機能などを紹介します
4. ケチり1: FargateでなくEC2を使う Fargate 2vCPU, 4GiBメモリ: 0.05056 + 0.01106 = 0.06162USD/hour EC2 t3.medium 2vCPU, 4GiBメモリ: 0.0544USD/hour https://aws.amazon.com/jp/fargate/pricing/ https://aws.amazon.com/jp/ec2/pricing/on-demand 約15%割高
5. Fargateの割り当てリソースの下限 Fargateはタスクレベルのcpu, memoryの定義が必須 vCPU, memoryについて有効な組み合わせの中から選択 0.25vCPU, 512MiBメモリが最小の組み合わせ EC2はタスクレベルのcpu, memoryの指定は必須でない 予約リソースを小さく設定できる https://docs.aws.amazon.com/ja_jp/AmazonECS/latest /developerguide/task-cpu-memory-error.html
6. 小さなタスクを複数起動したい場合のコスト差 0.1vCPU, 256MiBメモリ程あれば十分かなというECSタスクを20個起動する場合 Fargate: 0.25vCPU, 512MiB のタスクを20個 = 0.3081 USD/hour EC2: t3.medium (2vCPU, 4GiB)の1台で20個のタスクを起動 = 0.0544 USD/hour 512MiB 512MiB 512MiB 512MiB 256MiB 256MiB 256MiB 256MiB 256MiB 256MiB 256MiB 256MiB 512MiB 512MiB 512MiB 512MiB
7. EC2インスタンスでのタスク起動数の制約 EC2インスタンスへのENIの割り当て上限によってawsvpcモード等では インスタンスあたりの起動できるタスク数に上限がある https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/develo perguide/eni-trunking-supported-instance-types.html ENI trunkingという機能でこの上限緩和ができるが、それでもこれくらい
8. bridgeモードを使う - ECSのnetwork modeの一つ - タスクごとにENIを作らないの でタスク起動数の制約にかか らない https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide /networking-networkmode-bridge.html
9. EC2をbridgeモードで使うデメリット - タスクの通信にはインスタンスのENI、SGが使われる - 複数のECSサービスがインスタンスに混在する場合があるため、それら全ECS サービスに必要な全SGをアタッチする必要がある。セキュアでない
10. ケチり2: Spot Instanceを使う - オンデマンドインスタンスに比べて半額以下
11. Capacity ProviderでSpotの利用を制御 capacity providerで制御 - spotを使う、使わないサービス - spotの利用割合
12. ケチり3: Capacity Provider Managed Scalingを使う - タスクの起動状況に合わせてASGをスケーリング - タスク起動時にインスタンスの空きリソースがない場合にスケールアウト - インスタンスで起動するタスクが無くなったらスケールイン - インスタンスにタスクが残ってるとスケールインされない https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/cluster-auto-scaling.html
13. このようにタスクが停止すると スケールインするが
14. このようにタスクが停止すると 全インスタンスが残る
15. ケチり4: Scheduled Scalingを使う - managed scalingではタスクの配置具合によってはインスタンスが多く残ってしまう ことがある - 時刻指定で強制的にスケーリングさせる
16. - gitブランチごとに検証環境としてECSサービス、タスクなどが起動 - ECSタスクによっては開発時には利用頻度が少ないものも - Fargateはラクだが、利用頻度の少ないECSタスクにも一定のリソースを割り当て る必要があり、積み上がるとそれなりのコストに 当社での運用
17. 当社での運用 - 利用機会が少ないECSタスクは予約リソースを小さくしてインスタンスにギュッと詰 め込む - 複数人が同時にECSタスクを利用してリソース使用が大きくなるとOOM等になる可 能性はある
18. まとめ - ECS on EC2を使うことでFargateに比べてコストをギュッと圧縮できる - Spot Instance, Managed Scaling, Scheduled Scalingによってさらにコスト削減 - ECS on EC2(bridgeモード)はデメリットもあるため、本番ではなく開発環境のような ユースケースがおすすめ