GKEからECSへ移行したときに考えたこと ── コンテナ基盤の技術選定のリアルと、その判断軸

コンテナ基盤リアルトーク
〜コンテナ運用のつらみ大集合〜
2026/03/26
https://wealthnavi.connpass.com/event/383661/

Transcript

1. © estie Inc. GKEからECSへ移行したときに考えたこと コンテナ基盤の技術選定のリアルと、その判断軸 コンテナ基盤リアルトーク〜コンテナ運用のつらみ大集合〜 2026/03/26 株式会社estie Kento Shimada
2. © estie Inc. 自己紹介 1 Kento Shimada/P2O（X: @hitsumabushi845） 経歴 • 株式会社estie 技術戦略室 SRE • ワークスアプリケーションズ、FLUX、フリーランスを経て 昨年11月に入社 お仕事 • Terraform を活用した各種プロダクトの IaC 推進 • CI/CD パイプラインの改善と開発者体験の向上 • CKAD/CKA/CKS を持ってました（全部expireしました）
3. © estie Inc. 導入 2 背景 • 昨年、M&A によって新たなプロダクトが estie に舞い込む • そのプロダクトは Google Cloud の GKE 上で稼働していた 現状 • GKE 上でも安定稼働していたが、AWS/ECS への移行を決断 → 現在、移行のまっただ中 本発表のテーマ • 移行の決断に至った「技術選定の判断軸」について紹介 M&Aによる継承 壊れていないシステムを なぜ移行するのか？
4. © estie Inc. 3 引き継いだ GKE 環境の構成 →Deployment, CronJob, StatefulSet, Service, PV, PVC のみのシンプルな構成
5. © estie Inc. 4 検討した選択肢 GKE を維持 今あるインフラを そのまま運用し続ける選択肢。 既存のプロダクトは このままでも動作する。 EKS に移行 estie では主に AWS を使用。 AWS への統一を図りつつ、 Kubernetes を継続利用。 ECS に移行 estie のプロダクトの ほとんどが動いている ECS Fargate に合わせる。 ✓ 移行コストなし ✓ k8s-way な発展も可能 ✓ AWS 基盤への統合 ✓ k8s-way な発展が可能 ✓ 社内標準構成への完全準拠 ✓ estie-way を実現
6. © estie Inc. 5 検討した選択肢 GKE を維持 今あるインフラを そのまま運用し続ける選択肢。 既存のプロダクトは このままでも動作する。 EKS に移行 estie では主に AWS を使用。 AWS への統一を図りつつ、 Kubernetes を継続利用。 ECS に移行 estie のプロダクトの ほとんどが動いている ECS Fargate に合わせる。 ✓ 移行コストなし ✓ k8s-way な発展も可能 ✓ AWS 基盤への統合 ✓ k8s-way な発展が可能 ✓ 社内標準構成への完全準拠 ✓ estie-way を実現
7. © estie Inc. 判断軸① - 理解可能性 6 高い学習コスト • Kubernetes は抽象度が高く、概念理解と習熟に時間がかかる • Google Cloud 固有の知識も必要 組織への適合性 • estie の主要プロダクトは AWS/ECS で動作している • 開発者・SRE全員がいきなり GKE を使えるわけではない 属人化のリスク • 「触れる人だけ触る」状態は、将来必ずボトルネックになる • 特定のエンジニアに依存しない持続可能な体制が必要 理解可能性 プロダクトに関わる全員が スムーズに開発や運用に携われるか？
8. © estie Inc. 判断軸② - 運用の一貫性 7 運用が一貫していることの価値 ✓ 運用手順や改善施策の横展開が容易になる ✓ どのプロダクトでも同じ運用フローで、迅速な障害対応が可能 ✓ 開発者が担当プロダクトを変更する際もスムーズに移動可能 属人化の回避 「これはGKEだから〇〇さん対応」といった特定個人への依存を防ぐ 特殊な環境を減らすことでチーム全体でカバーし合える体制を作る 運用の一貫性 基盤を統一することで、 プロダクト全体の運用品質を高める
9. © estie Inc. 判断軸③ - 運用責任 8 継続的な運用の担保 「今」運用できるだけでなく、将来にわたって運用し続けられるかが重要。 スタートアップでは人の入れ替わりも考慮する必要がある 運用責任 組織として運用に対する責任を 中長期的に担保できるか？ 採用難易度の高さ 「AWSとECS」の人材に比べ、「AWSとGoogle Cloud」「ECSとGKE」を すべて理解している人材の採用は難易度が高い クラスタ管理の責務 小規模であってもKubernetesクラスタを持つ以上、そのバージョン管理や脆弱性 対応などの運用コストと責任は小さくならない
10. © estie Inc. 判断軸まとめ 9 ① 理解可能性 ▪ 「触れる人が触る」状態は将来 ボトルネックになる ▪ 社内の標準に合わせることで学 習コストを最小化 ▪ 特定の個人に依存しない 技術選定が重要 ② 運用の一貫性 ▪ 構成が一貫していると、 障害対応の品質とスピードが向上 ▪ 「このプロダクトだけは別手順」 という負荷を排除 ▪ 新しい取り組みや改善を 横展開しやすくする ③ 運用責任 ▪ プロダクトの寿命は 人の在籍期間よりも長い ▪ K8sクラスタを持つ責任を理解 する ▪ 「組織として継続的に責任を持 てるか」が最も重要 技術的な好き嫌いや優劣ではなく 「組織として運用し続けられるか」で判断する
11. © estie Inc. 現在の構成とまとめ 10 移行前の構成: GKE 移行後の構成(WIP): ECS ✓ ECS > GKE ではなく「組織としての技術選定」として ECS を選択 ✓ 「今、ここ」の構成を揃えることで将来的な施策の進めやすさにも寄与 ポイン ト
12. © estie Inc. 判断軸まとめ 11 ① 理解可能性 ▪ 「触れる人が触る」状態は将来 ボトルネックになる ▪ 社内の標準に合わせることで学 習コストを最小化 ▪ 特定の個人に依存しない 技術選定が重要 ② 運用の一貫性 ▪ 構成が一貫していると、 障害対応の品質とスピードが向上 ▪ 「このプロダクトだけは別手順」 という負荷を排除 ▪ 新しい取り組みや改善を 横展開しやすくする ③ 運用責任 ▪ プロダクトの寿命は 人の在籍期間よりも長い ▪ K8sクラスタを持つ責任を理解 する ▪ 「組織として継続的に責任を持 てるか」が最も重要 技術的な好き嫌いや優劣ではなく 「組織として運用し続けられるか」で判断する
13. © estie Inc. 12