東京ガス（内製開発チーム）
東京ガス、myTOKYOGASのマイクロサービス基盤をEKSからECS/Fargateへ。運用2名・Kubernetes経験者の異動で保守が回らずECSへ約4ヶ月で移行
東京ガスの内製開発チームは、myTOKYOGASのマイクロサービスプラットフォームをAmazon EKSで運用していたが、サポート期間14ヶ月に伴う年1回程度のクラスターバージョンアップとIstio・Argo CD等エコシステムの同時更新が他業務を圧迫していた。運用メンバーは2名で、Kubernetes経験者が異動により離職。学習コストの高さも課題だった。ECS/Fargateで要件を満たせる見通しを確認した上で、3名体制・約4ヶ月で本番移行を完了し、インフラ保守に割く時間はほぼなくなった。
課題
EKSのバージョンアップ負荷とKubernetes経験者の離職。運用2名では基盤保守が回らない
アプローチ
ECSで機能要件を満たせるか検証後、3名体制でECS/Fargate+ecspressoへ約4ヶ月で移行
効果
クラスター更新が不要になり、インフラ保守に割く時間がほぼなくなった
背景
東京ガスの内製開発チームは、myTOKYOGASのマイクロサービスプラットフォームをAmazon EKSで構築・運用しており、EKSアドオン・Istio・Argo CDといったエコシステムを組み合わせていた。しかしEKSは各バージョンのサポート期間が14ヶ月のため、年に1回程度はクラスターのバージョンアップが必要で、その際には複数のエコシステムも同時に更新しなければならず、他業務に支障が出るほどの負荷になっていた。設定変更時の調査や検証にかかるコストもECSより大きいと判断された。さらにマイクロサービスプラットフォームの運用メンバーは筆者を含めて2名という薄い体制で、そのうちKubernetes経験者が異動により離職。EKSおよびKubernetesはECSと比べて理解すべきリソースの種類や固有の概念が多く、学習コストの高さも課題として残っていた。
移行のプロセス
筆者は過去にECS/Fargateを運用した経験があり、その知見をもとに移行の実現可能性を検討した。
- ECSへ移行することで提供できなくなる機能がないかを確認
- 将来的に困難が生じないかを、組織リーダー・グループマネージャーとの対話を含めて検討
- 「少なくとも当面の範囲では、ECS/Fargateで要件を満たせる見通し」を得て意思決定
- 内製開発チーム2名＋ソフトウェアエンジニアリングチーム1名の計3名体制で移行を実施
- デプロイツールにはecspressoを採用
- バッチ処理はAmazon EventBridge・AWS Step Functions・ECSの組み合わせで再構成
立ち上げから本番環境の移行完了までは約4ヶ月。マイクロサービスが本格的に増え始める前という移行タイミングも有利に働いた。
移行前後の変化
| 指標 | Before | After | |
|---|---|---|---|
| コンテナ基盤 | Amazon EKS（EKSアドオン/Istio/Argo CD） | Amazon ECS on AWS Fargate | |
| クラスターのバージョンアップ | サポート期間14ヶ月のため年1回程度必要 | 不要（インフラ保守時間はほぼゼロ） | |
| 運用メンバー | 2名（Kubernetes経験者が異動で離職） | 2名（ECS運用経験を活かせる体制） | |
| 移行体制・期間 | — | 3名体制・立ち上げから本番移行完了まで約4ヶ月 |
結果
移行から半年が経ち、当初期待していた効果が得られていると報告されている。クラスターやエコシステムのバージョンアップが不要になったことで、インフラ保守に割く時間はほぼなくなった。その結果、コスト削減やIaCの推進といった改善活動に加え、プロダクト開発にも貢献できるようになっている。記事中に具体的なコスト削減額の数値は明記されていない。
学び
現時点ではECSが最適と判断したが、組織やプロダクトの成長、今後の要件に合わせて継続的に見直していきたいとしている。また、意思決定から移行完了までスピーディに進められたのは内製開発ならではだと振り返っている。