はじめに

こんにちは！開発エンジニアのクリスです！

Google Cloud Next Tokyo 26 に参加してきました！今回は Day 1 のカスタマー セッション「大規模レガシーを刷新！手動運用からの脱却と CI / CD によるモダナイズ」のレポートをお届けします。

手動スケールに手動リリース、商用データベースの運用コスト…。長年ビジネスを支えてきた基幹システムほど、こうした「レガシーの重み」を抱えているものですよね。マクロミルがその大規模基幹システムを Google Cloud へ全面移行するという、モダナイズの実践例が詰まったセッションでした！

セッション概要

タイトル：大規模レガシーを刷新！手動運用からの脱却と CI / CD によるモダナイズ

登壇者：

  • 片切 亮 氏（株式会社マクロミル Tech PM）
  • ジョン アラン 氏（株式会社マクロミル Tech Lead）

日時・会場：Day 1（7 月 30 日）17:00 – 17:30 / Room 6（セッション ID：D1-INF-03）

公式カタログの紹介文は以下のとおりです。

マクロミルが長年ビジネスの根幹を支えてきた大規模基幹システムを、Google Cloud へ全面移行するアプローチと実践的ノウハウを紹介します。手動スケールや手動リリース、商用 DB の運用コストといった課題に対し、Tech Acceleration Program (TAP) を活用してアーキテクチャのグランド デザインを策定。Google Cloud のインフラ構築から、GKE・Valkey によるオートスケールの実現、AlloyDB でのコストとスケールの最適化、CI/CD を用いた無停止リリースまで、2026 年にローンチする大規模モダナイズの軌跡を解説します。

背景 ― 20 年間レガシーを支え続けたシステム

まずは、そもそもマクロミルがどんな会社なのかという紹介からセッションは始まりました。日本最大のオンライン リサーチ会社で、アンケートの集計やその提供などを手がけています。私たちが日常で目にする調査データの裏側を支えている会社、というわけですね。

そして印象的だったのが、その基幹システムを表す一言です。

レガシーを支え続けた 20 年。

20 年。

20 年動き続けているということは、それだけビジネスを支えてきた証でもあるのですが、同時に技術的な重みも 20 年分積み上がっているということですよね。

立ちはだかっていた 3 つの限界

その 20 年で積み上がった課題として挙げられたのが、次の 3 つの限界でした。

  • スケーラビリティの限界
  • 手動作業の限界
  • コストの限界

「スケールできない」「人手に頼っている」「お金がかかる」。レガシー システムの悩みを言い切ると、だいたいこの 3 つに収束するんじゃないでしょうか。自分の担当システムを思い浮かべながら聞いていました。

目標は「1 年間の集中プロジェクト」

この 3 つに対して立てられた目標が、1 年間という集中プロジェクトで、運用コストの削減と無停止リリースを実現するというものでした。

20 年分のレガシーを、1 年で。……これ、聞いた瞬間に「本気か！」と思いましたよね。

プロジェクト キックオフ ― 「1 年は無理でしょう」からのスタート

そして実際、社内の空気も同じだったそうです。

キックオフ時点では「1 年は無理でしょう」という空気から始まったと、正直に語られていました。ここを隠さず話してくれるのが、カスタマー セッションのいいところですよね。

その空気をどう変えたのか。やったことは 2 つでした。

  • 課題とボトルネックを洗い出し、マイグレーションの目的を整理する
  • デモを見せる

そして「行ける！」という判断に至った、と。議論だけで空気を変えるのではなく、動くものを見せて納得を作りにいったわけです。「できます」と言葉で言うより、動くデモを 1 回見せたほうが早い ― これは規模の大小に関わらず効く進め方だと思いました。

戦略 ― 3 つの限界に、3 つのサービスで答える

方針は驚くほどシンプルでした。3 つの限界に、それぞれ打ち手を 1 つずつ当てていく形です。

課題 打ち手
スケーラビリティ GKE
手動作業 GitHub Actions
コスト AlloyDB

そのうえで掲げられたゴールが、「自動化と無停止リリース」です。

課題と打ち手が 1 対 1 で並ぶこの整理、すごく好きです。手段が先に来るとブレますが、「この限界を壊すためにこのサービスを選んだ」という順序で語られると、あとの技術選定の話がすべて筋道立って聞こえてきます。

プロジェクトの進め方 ― Transparency、建設的なディスカッション と Respect

個人的に一番おもしろかったのが、技術ではなく進め方の話でした。挙げられたキーワードは 3 つです。

Transparency（透明性）として、具体的にこうした体制が取られていました。

  • 3 つのスクラム チームで並行して進める
  • 月 2 回のスプリント レビューを実施する

そして、その場で建設的なディスカッションを重ねる。もう 1 つのキーワードが Respect（尊重）でした。

1 年で 20 年分を刷新するようなプロジェクトって、どうしても「間に合わせる」ための空気が張り詰めがちですよね。そこで透明性と尊重が最初に語られるのは、けっこう本質的だと思います。月 2 回レビューを回して全員が同じ状況を見ている状態を作れているなら、それだけで進捗の遅れも早く見つかりますし。

タイムライン：2025 年 7 月 → 2026 年 7 月

プロジェクト全体の期間は 2025 年 7 月から 2026 年 7 月まで。ちょうどこのセッションが、その 1 年を走り終えた地点での報告になっていたわけです。

2025 年 7 月：Tech Acceleration Program で方向性を固める

スタート地点で効いたのが、Google Cloud が提供する Tech Acceleration Program（TAP）でした。

内容は2 日間の建設的なディスカッション。ここでアーキテクチャのグランド デザインを描き、方向性の合意が取れたとのことです。

2 日間で 1 年分の方向性を決める。凝縮されていますが、逆に言えば「最初に全員で方向を合わせる」ことにそれだけ投資する価値があるということですよね。ここが曖昧なまま走り出したプロジェクトがどうなるかは、皆さんもきっと想像がつくと思います（笑）。

改修のポイントと、その効果

そして、実際に得られた効果がこちらです。数字で語られると気持ちいいですね。

打ち手 効果
GKE 手動作業 6 時間 → 0 分
GitHub Actions 夜間停止 6 時間 → 0 分
AlloyDB コスト 約 50% 削減

「6 時間を 0 分に」が 2 つ並んでいるのがインパクト大です。手を動かしていた 6 時間と、サービスを止めていた 6 時間が、どちらも消えた。1 回あたり 6 時間ということは、リリースの頻度を上げようという発想自体が生まれにくかったはずで、それが 0 分になったというのは単なる時短ではなく、開発サイクルそのものが変わる話ですよね。

アーキテクチャ ― Google Cloud での全体構成

ここからが技術パートです。移行後の構成が、コンポーネント単位で解説されました。

Cloud Load Balancing

  • GKE Ingress にアタッチして利用する
  • IP 制限などのアクセス制御を実施
  • Cloud Armor を組み合わせて防御

GKE

  • 社内向けのアプリも同じクラスタに載せ、Namespace で分離する
  • ログ分析などは Datadog を利用
  • ログは Vector 経由で Cloud Storage へ

基幹システムと社内アプリを同じクラスタに同居させて Namespace で切る、という判断が実用的だなと思いました。クラスタを分ければ確かに安心ですが、その分だけ運用対象が増えますからね。「どこまで分けるか」の線引きは、いつも悩みどころです。

AlloyDB とファイル システム

  • アプリケーションからは プロキシ経由で接続する
  • プライベート接続とし、IAM で権限を制御する
  • ファイル システムは Cloud Storage（fuse でマウント）

コスト削減の主役が AlloyDB だったわけですが、接続経路もきっちりプライベート＋ IAM で締められていて、「安くなったけど緩くなった」がない構成でした。

バッチ サーバー

  • Compute Engine 上で稼働
  • lift and shift 形式で移行
  • 内部ロード バランサ経由で GKE へ流れる

すべて Terraform で IaC 化

そして、これらすべてが Terraform 経由で IaC 化されており、モノレポで管理されているとのことでした。

「手動作業の限界」を課題に掲げたプロジェクトですから、ここが徹底されているのは当然といえば当然ですが、全部を Terraform に寄せ切るのは相応の覚悟が要りますよね。しかも 1 年で。

バッチは lift and shift ― 無理にコンテナ化しない

このセッションで一番刺さったのがこのパートです。

Web 側は GKE に載せてコンテナ化しているのに、バッチは 無理にコンテナ化せず、Compute Engine のまま lift and shift する。この割り切りが明確に語られました。

さらに具体的なのがファイル システムの扱いです。

  • ファイル システムは gcsfuse で Cloud Storage を POSIX マウントする
  • マウント先は旧基盤のパスを踏襲する

マウント先のパスを旧基盤と同じにしてしまえば、バッチ側のコードは「自分がどこに書いているか」を意識しなくて済むわけです。つまりアプリを直さずに、下のストレージだけ差し替えられる。

モダナイズと聞くと「全部コンテナに載せる」と考えたくなりますが、それをやると移行そのものが終わりません。どこをモダンにして、どこを据え置くかの線引きこそが、1 年で完走できた理由の 1 つなんじゃないかと思いました。

デプロイ自動化 ― GitOps アプローチ

続いてデプロイの話です。採られたのは GitOps アプローチでした。

  • Argo CD で Application を定義する
  • イメージと Helm チャートで構成し、イメージは Artifact Registry に保存して GKE へデプロイする

そして、デプロイの通知は Slack へ。

地味に見えて、この Slack 通知がちゃんと入っているのは大事ですよね。自動化すると人の目から離れるので、「何がいつ出たか」が流れてくる場所は必ず必要になります。

ビルド & デプロイのパイプライン

CI は GitHub Actions。環境は dev / stg / prd の 3 つが用意されています。

そして、成果物の種類によってデプロイ経路が分かれていました。

成果物 デプロイ経路 デプロイ先
Web イメージ Artifact Registry → Argo CD GKE
バッチの jar Ansible でデプロイ Compute Engine

先ほどの「バッチは lift and shift」という判断が、そのままパイプラインの形にも現れているのがわかります。コンテナは GitOps で、jar は Ansible で。無理に 1 本のやり方に統一しないのが、かえって現実的なんですよね。

メンテナンス モードによる切り替え

無停止リリースを目指す一方で、大きな切り替えのためのメンテナンス モードも用意されています。手順はこの 4 ステップでした。

  1. maintenanceMode=true にする
  2. メンテナンス画面を公開する
  3. 新バージョンを整備する
  4. 手動で GoLive する

最後の GoLive が手動になっているのが、個人的にはとても納得感がありました。全部を自動化するのが正解ではなく、「ここは人間が判断する」というポイントを意図的に残す。自動化の設計で一番難しいのは、この境界線の引き方だと思います。

課題と、その乗り越え方

もちろん、順風満帆というわけではありませんでした。立ちはだかった課題として語られたのがこの6つです。

  • レガシーRDBの移行
  • 繁忙期のピーク1,500TPSの性能の担保
  • 約4TBのファイル移行
  • 既存クラウドとGoogle Cloud のハイブリッド運用
  • インフラのIaC化
  • デプロイ起因のダウンタイムゼロに

特に1,500 TPSの通信量 と 4 TBファイルの移行。オンライン リサーチという事業の規模がそのまま数字に出ていますね。特にピーク時の 1,500 TPS は、アンケートの回答が一気に集中する瞬間を想像すると納得です。これを「チューニングで担保した」と一言でまとめてしまうあたりに、裏側の格闘があったんだろうなと思わされました。

まとめ

今回のセッションのポイントを、3 つに整理してみます。

  1. 3 つの限界に、3 つの打ち手を 1 対 1 で当てる。スケーラビリティは GKE、手動作業は GitHub Actions、コストは AlloyDB。目的から逆算した技術選定だからこそ、「自動化と無停止リリース」というゴールがぶれずに走り切れた。効果も手動作業 6 時間 → 0 分、夜間停止 6 時間 → 0 分、コスト約 50% 削減と明快。
  2. モダナイズは「全部コンテナ化」ではない。Web は GKE、バッチは Compute Engine で lift and shift。gcsfuse のマウント先を旧基盤のパスに踏襲することで、アプリを直さずに下のストレージだけ差し替える。この割り切りが 1 年での完走を支えている。
  3. 進め方の設計が成否を分ける。「1 年は無理でしょう」という空気を、目的の整理とデモで動かす。3 スクラム チーム＋月 2 回のスプリント レビューで透明性を保ち、TAP の 2 日間で方向性を合意する。そして GoLive は手動で残す ― 自動化と人の判断の線引きまで含めて設計されている。

そして登壇者ご本人が締めくくりで強調していたのが、Google Cloud の TAP がとても役に立ったという点でした。最初の 2 日間の投資が、その後の 1 年を決めたということですね。

さいごに

レガシー アプリをコンテナ化して再デプロイすること、そして手動の作業を自動化すること ― これって、とても大きなハードルだと思うんです。私自身の経験からしても、本当にそうでした。

それをチーム一同で同じゴールに向かって、1 年間でこれだけ大きなプロジェクトを完成させたという事実に、素直に感心しました。技術的な難しさ以上に、20 年動いてきたものに手を入れる怖さを、チーム全員で乗り越えていったわけですから。

しかも出来上がったアーキテクチャが、ベスト プラクティスに基づいた設計になっているんですよね。プライベート接続と IAM、Namespace による分離、Terraform でのモノレポ IaC 化、GitOps によるデプロイ。急いで作ったから雑になった、という箇所が見当たらない。構成図を眺めていて、エンジニアとして純粋に気持ちよかったです。

「うちのシステムも古いから…」で止まってしまいがちなところを、目的の整理とデモで空気から動かして、割り切るところは割り切って完走する。自分が関わるモダナイズの場面でも、まずはこの進め方から真似したいと思いました！

最後までお読みいただき、ありがとうございました！