トモニテでEKSからECSに乗り換えによるコスト削減

2024/12/11 そのリプレイスは最適解？ -コストから見るプロダクト開発Tips
https://findy.connpass.com/event/336975/

Transcript

1. トモニテでEKSからECSに乗り換えによるコスト削減 2024/12/11 そのリプレイスは最適解︖ -コストから⾒るプロダクト開発Tips 株式会社エブリー 宮本 涼司
2. ⾃⼰紹介
3. Copyright © 2015 every, Inc. All rights reserved. 3 • 宮本 涼司 (@rymiyamoto129) • 株式会社 エブリー • BEを中⼼に薄く広くやってます • メインはGo • 最近は開発組織の活性周りのことも やってます(DevEnable) ⾃⼰紹介
4. エブリーについて
5. 5 Copyright © 2015 every, Inc. All rights reserved. エブリーが提供しているプロダクト、ソリューション⼀覧
6. 6 トモニテでのEKS脱却の経緯
7. 7 Copyright © 2015 every, Inc. All rights reserved. 当時のトモニテにおける構成 EKS on EC2を中⼼として動いているメディアサービス 各プロダクトで単位でインフラ管理を⾏っている https://tech.every.tv/entry/2021/01/12/120000
8. 8 Copyright © 2015 every, Inc. All rights reserved. • Kubernetes（以降 k8s）は⾼頻度でアップデートされるため、⽇々の業務を進めなが らキャッチアップするのが難しい • アップデートは EKS のサポートが切れる間際に、だいたい年 1 回のペースで実施して いた • 対応も1メンバー1ヶ⽉程度かかってしまう... メンテナンスコストが⾼い なぜ脱却するのか︖①
9. 9 Copyright © 2015 every, Inc. All rights reserved. • サービス規模的にマイクロサービスが⼤量にあるわけでもなく、各サービスのやり取り がシンプル • 特段k8sが使えないと困るものがなく、AWSだけである程度完結している • 社内の別プロダクトで ECS の運⽤実績がしっかりとあるので合わせられる EKSにこだわる理由が薄い なぜ脱却するのか︖②
10. 10 移⾏計画
11. 11 Copyright © 2015 every, Inc. All rights reserved. • 時間的制約 (EKSのサポート終了)の都合 ⽅針 全体的なアーキテクチャの変更はせずシンプルに乗り換える 他プロダクトに合わせてECS on Fargate とする • 運⽤実績が豊富なので参考にしやすい
12. 12 Copyright © 2015 every, Inc. All rights reserved. ロードマップ AWS コンソール上で ECS 環境を⽤意 1 ECS 環境の IaC 化 & CI/CD の整備 2 ECS 環境に切り替え 3 本番環境も移⾏ 4 EKS環境の破棄 5
13. 13 移⾏作業
14. 14 Copyright © 2015 every, Inc. All rights reserved. AWS コンソール上で ECS 環境を⽤意 • クラスターの作成 • API server やら web 等をタスク定義 • タスク定義をもとに ECS のサービスを Fargate で作成 • これらに伴う role や policy の作成/変更
15. 15 Copyright © 2015 every, Inc. All rights reserved. • terraformで必要なリソースのみに絞って作成 • 各サービスのタスク定義はそれぞれのrepositoryで保持 • 初回以降は都度更新をinfra側でしたくない • それぞれのサービスで環境変数やコンテナイメージを管理 • 都度CD時にみる ECS 環境の IaC 化 & CI/CD の整備 (全体)
16. 16 Copyright © 2015 every, Inc. All rights reserved. • ecs-deploy を使ってデプロイ • 採⽤理由は社内の運⽤実績があるところ • ecspresso は今回は対応できる期間も短く社内で運⽤実績ないため採⽤は⾒送り • jsonを渡せば良い感じにやってくれる ECS 環境の IaC 化 & CI/CD の整備 (サービス関連)
17. 17 Copyright © 2015 every, Inc. All rights reserved. • ecschedule を使ってデプロイ • スケジュール管理&デプロイ、override含めてyamlで管理可能 • runでの即時実⾏にも対応しており、ショット実⾏も容易 • テンプレート化して都度必要なスケジュールタスクを⾜す構成に ECS 環境の IaC 化 & CI/CD の整備 (バッチ関連)
18. 18 Copyright © 2015 every, Inc. All rights reserved. ECS 環境に切り替え • Route53 で新環境へ荷重を数⽇かけて少しず増やす • ⼀気に新環境に切り替えていくのは、不測の事態があったときに対応が⼤変 • EKSのCronJob側を停⽌した状態でスケジュールタスクを active に変更して反映する • バッチ系が⼆重で⾛らないように • 過去⼀度EKSアップデートのときにやらかしたことがある...
19. 19 Copyright © 2015 every, Inc. All rights reserved. • 不要になった EKS 向けの CI/CD や関連する aws リソースの削除を⾏う • ⼀気に terraform で関連リソースをまとめて削除をしない • 依存する別のリソースまで影響する可能性が⾼いため • 信頼関係を⾒つつ地道にモジュール削除をするしかない EKS環境の破棄
20. 20 移⾏を伴っての効果
21. 21 Copyright © 2015 every, Inc. All rights reserved. • マニフェストで管理するよりはシンプル 良かった⾯ 構成がシンプルになった k8sのアップデートに追われる⽇々が終焉に • プロダクトに集中して開発が進められる • さよなら式年遷宮 料⾦の削減もついでにできた • サーバーコストが半分近く減らすことができた • おおよそ$500ぐらい
22. 22 Copyright © 2015 every, Inc. All rights reserved. • 今までEKS on EC2の内部でよしなに処理されていた部分が明るみに出る • これまで⾒えていなかったメモリリークが起きていたことに気付かされた ⼤変だったところ 厳密なリソース管理が必要になった AWS ECS 故の独⾃性 • k8s ⾃体が活発なコミュニティ故にツールが豊富だった • AWSのサービスに閉じられるのでデファクトスタンダードらしきものが⾒つけづらい
23. 23 まとめ
24. 24 Copyright © 2015 every, Inc. All rights reserved. まとめ EKSからECSへの移⾏で⼈的コストの削減ができた 基盤の新規検討や切り替えは慎重に • ⽴ち上げ時に将来先を考えるのは難しい問題 • 対応できる組織体制が整備できているかは重要 • 将来性ある作りであっても管理が⾟くては⼈件費がかさんでしまう • 構成変更は最⼩限にして考えることを減らすと時間短縮にもなる • 本来重きを置きたいサービス開発に専念できるようになった • ついでにサーバー費⽤の削減もできた
25. 25 Copyright © 2015 every, Inc. All rights reserved. エブリーからのお知らせ ⼀緒にサービスを作る仲間を⼤募集中です︕ 🔍 エブリー 採⽤ https://corp.every.tv/rec ruits • Tech Blogもやってます • 開発部 Xアカウント • エブリー公式オウンドメディア「every.thing」はこちら https://tech.every.tv/ https://everything.every .tv/ https://x.com/every_engine er