Composable Platform Shift ~AWS全面移設におけるプラットフォームエンジニアリングの実践~

コンテナ基盤リアルトーク〜コンテナ運用のつらみ大集合〜 https://wealthnavi.connpass.com/event/383661/ で発表した資料です。

1. 1 Composable Platform Shift ~AWS全面移設におけるプラットフォームエンジニアリングの実践 ~ drumato / Yamato Sugawara 2026.03.26
2. 2 ⾃⼰紹介 技術部 技術基盤グループ シニアエンジニア 2024年 中途⼊社 Drumato Yamato Sugawara ECサイト構築構築サービス｢カラーミーショップ by GMOペパボ｣をメインに、事業横断で信頼性向上･ プラットフォームエンジニアリングに従事。 サービスのあらゆる課題に対し、インフラとソフト ウェアエンジニアリングの専⾨性を発揮して貢献す ることをミッションに。
3. 3 本発表の流れ 1. 前提と現状 2. 事例~バッチロール移設プロジェクト~ 3. リプラットフォームにおけるトライアンドエラー 4. まとめ
4. 4 本発表のテーマ(つらみの核) 1. AWS全⾯移設プロジェクトにおけるクラウドコスト増⼤ 2. ⼤規模なインフラ刷新に伴うメンタルモデルの変化 3. Developed/Operated by AIにおけるプラットフォームの理想像と現状の ギャップ
5. 前提と現状 5
6. 私たちはインターネットやテクノロジーの力で情報発信のハードルを下げ、 あらゆるアウトプットを世界中に増やします。 さまざまなアウトプットが進化や価値を生み出すように、 私たちもプロダクトを生み出し続け、ユーザーと共に進化し拡大していきます。 ミッション 人類のアウトプットを 増やす 6
7. 7 前提と現状 商売をするすべての人を支え、 ECの多様性を広げる これからビジネスを始める方から、すでに成長中のビジネスを 手がける方まで、商材や事業規模に関わらず「成長できる」EC サイトが構築できるサービスです。多彩な機能と手厚いサポー トで商売をする人を支援しています。 国内最大級のECサイト構築サービス 利用料金 フリー / レギュラー / ラージ / プレミアム 主なユーザー 個人商店や中小店舗 契約件数 5.0万件 ※2024年9月末時点 ※料金プラン詳細(4プラン)：フリー 0円~ 、レギュラー4,950円~、ラージ9,595円~、プレミアム39,600円~
8. 前提と現状~AWS全⾯移設プロジェクト~ 8 • OpenStackベースのプライベートクラウドから、各事業のサービスインフラを全⾯ 的にAWSに移設するプロジェクト • 本発表ではカラーミーショップでの事例にのみ限定 • ⾄上命題: コスト最適化、開発⽣産性向上、プラットフォーム信頼性向上
9. 前提と現状~AWS全⾯移設プロジェクト~ 9 • OpenStackベースのプライベートクラウドから、各事業のサービスインフラを全⾯ 的にAWSに移設するプロジェクト • 本発表ではカラーミーショップでの事例にのみ限定 • ⾄上命題: コスト最適化、開発⽣産性向上、プラットフォーム信頼性向上 →単なる移設ではなく、 リプラットフォーム
10. 前提と現状~移設前のアーキテクチャ~ 10 データセンター OpenStackクラスタ VMロール(バッチ, DB, etc) 社内Kubernetes as a Service基盤 Kubernetesクラスタ コンテナロール(webapp, etc)
11. 事例 11 ~バッチロール移設プロジェクト~
12. 事例~バッチロール移設プロジェクト~ 12 • 様々なVM, コードベースで分散しているバッチロールを移設するプロジェクト • 7ロールの異なるコードベースで動くバッチが160本程度ある • ほとんどは素朴なphpスクリプトをCapistranoでデプロイ • ⼀部RubyのThor/Rakeベースのものがある • また、⼀部はRundeckで管理されてキックされる • プロジェクトリーダーかつプラットフォーム推進: 1名(発表者) • アプリケーション開発者: 4名
13. 事例~バッチロール移設プロジェクト~ 13 • バッチ基盤としての要件をサービス要件とすり合わせて決定 • 事業部CTO(@yammer)などのステークホルダと合意 • 重視ポイント • 基盤コンポーネントとのロックイン境界を明確に定義する • 移設プロジェクトの⽴ち上げと推進サイクルを⾼速化できる • オープンでコントロールしやすい仕組みを使う
14. 事例~バッチロール移設プロジェクト~ 14 • 結論: Argo Workflowsを採⽤ • Argo Workflows • argoproj主体で開発されているKubernetesネイティブなワークフローエンジン • OSSであり、シンプルさと拡張性を兼ね備えている • クラウドネイティブコミュニティでも多くの事例がある • 主な理由 • 実⾏主体がコンテナであり、ワークロードのコンテナ化⾃体の資産を他に流⽤しやすい • AWS EKSを中⼼に設計していたので、そこにも統合しやすい • Kubernetes Operatorに代表される拡張パターンに対する知⾒があった
15. 事例~バッチロール移設プロジェクト~ 15 • それぞれのバッチタスク(cron)⼀つ⼀つが、 CronWorkflowリソースに対応 • 失敗による再実⾏は、Submit APIを実⾏する • CronWorkflowはIntegrationとProductionでさらに分かれている • 可観測性はArgo Workflows ControllerのBuilt-in Metrics+ Workflow Custom Metricsで担保 • prometheus-operatorのPrometheusRuleで監視ルール設定、PagerDutyにルーティング • kube-prometheus-stack同梱のGrafanaでモニタリングダッシュボードを⽤意
16. リプラットフォームにおける トライアンドエラー 16
17. トライアンドエラー 17 • 移設における第⼀の壁: ｢タスクの多さ｣ • 全体として160本のバッチタスクをすべて移設しきる必要があった • 多いものでは1ロール約60本ものタスクが存在 • それぞれのタスクの内部実装と懸念点を、Claude Codeなどを活⽤して⾼速に調査 • ⽣じた問題: ｢マニフェスト管理の煩雑さ｣ • cronベースのバッチロールではVM全体で共有化されていた設定や依存が、CronWorkflow マニフェスト間で重複して存在することになる • プロジェクトメンバーがバッチタスクを⼀つ⼀つ移設する中で、CronWorkflowを書いて レビューするのは現実的ではない
18. トライアンドエラー 18 • 対策: CronWorkflowを複製するCLIの実装 • https://github.com/drumato/cron-workflow-replicator • 思想: ほとんどは同じでちょっとフィールドが違うマニフェストがたくさんほしい だけ • アーキテクチャ: base manifestにvalueをoverrideして実際のYAMLを⽣成する • なぜカスタムコントローラではなかったのか? • マニフェストを⼤量⽣成するCLI→いつでも引き剥がせる • base manifestとCLI設定を消して、コピペ運⽤にすぐできる • resource createを⾏うコントローラ→引き剥がすのにコスト
19. トライアンドエラー 19 • すべてのバッチタスクを spec.suspend: trueで⽣成してデプロイしてしまう • 開発者はsuspend: trueを外す1⾏の変更と、⽣成されたファイルを含めてPRを作っ てマージ
20. トライアンドエラー 20 • 移設における第⼆の壁: ｢移設スピードとコスト最適化/信頼性のバランシング｣ • 具体例の⼀つ: コンテナイメージレジストリの移⾏漏れによるコスト増加  • 現在、社内でビルド/デプロイしている多くのコンテナイメージはGitHub Enterprise Serverのコンテナレジストリにプッシュされている • そのまま移設→NATGatewayのコスト上昇 • ECRへの移設やPull Through Cacheの導⼊など実施
21. トライアンドエラー 21 • 移設における第⼆の壁: ｢移設スピードとコスト最適化のバランシング｣ • 具体例の⼀つ: Karpenterのspot NodePoolを利⽤することによる失敗率の増加 • AWS EKS構築時に、移設コストを最⼩限に押さえるために、固定のRI Node Group + spot NodePoolを⽤意 • バッチタスクがRI NodeGroupに乗り切らず、Spot Instanceにスケジュール • 削除猶予の2分間に処理が終了しきらず、失敗率が増加 • 急ぎKarpenterのNodePoolにon-demandの設定を低いweightで追加 • バッチタスクのスケジューリングポリシーで requiredDuringSchedulingIgnoredDuringExecution を指定することで解消
22. まとめ 22
23. まとめ 23 • ⽅針1: Composableなソフトウェア･仕組みを実装･構築して課題を解決する • 単なるマニフェスト複製CLIであるcron-workflow-replicator • AWS NLBにプライベートクラウドのK8sノードをつなげる drumato/targetgroup-senpai • KubernetesクラスタがProduction ReadyになるまでをブートストラップするTazuna(近 ⽇公開) • 要件と責務が明確なソフトウェアや仕組みは、Coding Agentによる⾼速な開発でリ プレイスしやすい • ⼤きく複雑な仕組みを作るよりも、⼩さくシンプルなしくみを作ったほうが全体として速 を出せる
24. まとめ 24 • ⽅針2: 影響を最⼩化し多くの課題を初期段階で発⾒する移⾏⽅針がとにかく重要 • バッチロール移設では多くの問題を序盤で踏み抜けるように、｢実⾏失敗やプラット フォームの未熟によってユーザ影響が出ないバッチタスク｣を優先して移設 • 多くの課題を実地検証で⾒つけて改善することで、⽇々安定性が向上している
25. まとめ 25 • ⼤規模なサービスインフラをクラウドネイティブ化するうえでの課題(つらみ)と継 続的な取り組みをご紹介 • オープンでコントロールしやすい技術を使い、作ることでメンテナンスコストと移 設容易性を担保 • Developed/Operated by AIを前提に、進化しつづけるプラットフォームを⽬指す
26. 26 最後に カジュアル面談 https://open.talentio.com/r/1/c/pepabo/pages/79696
27. 27 ご清聴ありがとうございました 「ご静聴ありがとうございました」「We're hiring」などに⾔い換えても。