AWS から Google Cloud へどのようにして段階的に移行することになったのか？
ユアマイスターでは 2021 年から、利用中のパブリッククラウドサービスを AWS から Google Cloud へ段階的に移行し始めました。主要プロダクトの移行が始まったのは 2023 年 8 月で、その後 2024 年 2 月に主要プロダクトが Google Cloud へ移行完了しました。今回は、今まで取り組んできた段階的な移行方法について紹介する記事の前編となります。
パブリッククラウドを移行した背景
ユアマイスターは創業時から 2024 年現在に至るまで、プロダクトをモノリシックな Web アプリケーションで構築してきました。ただモノリシックであるが故にフロントエンドとバックエンドに明確な境界が無く、責務分担の曖昧なソースコードが増えてきつつありました。
また、ビジネスの拡大要請からスピード重視で開発を進めてきた結果、技術的負債が蓄積し、拡張しづらいコードが増えてきました。このため小規模リリースが難しくなる課題も併せて発生するようになりました。
これらの状況を鑑みた結果、 「ソースコードをフロントエンドとバックエンドに責務を分けた構成にしていこう」 という方針が組み上がります。それが、現在ユアマイスターが取り組む主要言語フレームワークの変更（具体的には PHP, CakePHP を中心とした構成から TypeScript, Vue.js, Nuxt への変更）です。
実際にフレームワーク変更を進めてみると、今度はそれらの新しいコードを 「どこで・どのように動かすか？」 の検討が入りました。「どこで」はパブリッククラウドを指し、「どのように」はランタイムを指します。
コンテナをベースとした開発およびパブリッククラウドサービスの普及
昨今のランタイムはコンテナベースのものが多く、パブリッククラウドのプロダクトもコンテナで提供されるものが増えてきました。コンテナにすると
- 構成をファイル（Dockerfile）に書くため変更管理がしやすい
- スケーラビリティやクラウド間ポータビリティが高い
という利点があります。このことからコンテナを主要なランタイムとして使う人が増えてきた結果、その動向に併せてコンテナをサポートするパブリッククラウドのサービスが発達してきたという背景があります。
翻りましてユアマイスターでは今までローカル開発環境にのみ、docker composeによるコンテナを活用していました。ですがコンテナの潮流を鑑みた結果、この機にステージングや本番環境におけるランタイムもコンテナに切り替えたいと考えるようになりました。
ビジネス面からのインフラ構成再検討の要請
ユアマイスター上で取り扱われるカテゴリにはエアコンクリーニング等のように夏に繁忙期を迎える等、季節に応じて繁閑差が存在するものがあります。故にインフラとして採用したい構成は、ビジネス上の繁閑差に合わせて柔軟にスケール可能なサーバーレスアーキテクチャです。
ユアマイスターのインフラは歴史的経緯で、創業時から AWS の EC2 に構成されておりました。ですが、その延長でサーバーレスアーキテクチャに再構成するのが本当に良いかが焦点となります。
どのパブリッククラウドにするか？
ここまでの要請であればどのパブリッククラウドでも候補足りうるのですが、他に考慮すべき点が2つありました。
1 点目はユアマイスター内で Google Workspace、Google Analytics、BigQuery の 3 プロダクトを活用していること です。これらは今後も使い続ける公算が大きく、また Google Cloud とも連携しやすい利点がありました。
2 点目は Google Cloud にサーバーレスの特性を備えたプロダクトが多く、且つ機能が充実してきたこと です。特に Cloud Run を中心としたプロダクトの進化がめざましく、その周辺機能も充実してきたことは見逃せない点でした。
これらが決め手となり、ユアマイスターでは Google Cloud への移行が決定します。
全体的な移行方針
下記の通りです。
1. 主要言語フレームワークの移行（CakePHP → Nuxt）
- 新しい機能を作る場合は基本的に Nuxt で作る
- 既存機能に機能追加する場合は基本的に Nuxt で作り替える
- 既存機能のメンテは CakePHP で対応する
- 上記以外でCakePHP でできた機能のうち、Nuxt 化可能なものは随時 Nuxt へ
2. パブリッククラウドサービスの移行（AWS → Google Cloud）
- 新しい機能を作る場合は基本的に Google Cloud 上に作る
- 既存機能に機能追加する場合は基本的に Google Cloud 上に作り替える
- 既存機能のメンテは AWS で対応する
- 上記以外でAWS から Google Cloud へ移行可能なものは随時 Google Cloud へ
見ての通り、フレームワークにしてもパブリッククラウドにしても一気に移行するのは難しいため、徐々に移行する方針としました。以下では Google Cloud への移行について解説していきます。
移行方針の課題
実際に進めてみると、下記 2 点が大きな壁となりました。
- プロダクト構成がインフラ・機能・DB・ソースコードそれぞれで癒着が激しく、想定より移行が進まない
- Google Cloud や IaC（Terraform）の習熟
今回は 1.について解説します。2.は別途記事にします。
1.の癒着についてはプロダクトにおける技術的負債の蓄積の影響が大きいですが、他方で開発プロジェクト内で取り組むにしても納期の要請を考慮する背景がありました。
他方、開発プロジェクト前段の PRD（プロダクト要求仕様書）の中身が「本当に取り組む価値のある施策なのか？」のレベルで見直しが進んだこともあり、移行作業に専念できるエンジニアを配置することができるようにもなりました。
エンジニアの配置変更
というわけで、開発プロジェクトにおけるエンジニアの配置を下記の構成で変えることになります。
- 主に Google Cloud の移行を進めるエンジニア
- 既存システム構成上で開発プロジェクトを進めるエンジニア
1.を担当するエンジニアは移行の過程で、不要機能やシステムの癒着を削ぎ落としたり開発プロセスを刷新する動きを併せて進めます。そのため間接的ではありますが、 2.を担当するエンジニアの開発・運用がスムーズになる効果も見込めます。
体制が整ったことでいよいよ本格的に主要プロダクトの Google Cloud 移行が始まりますが、時間軸の兼ね合いもあり「作り直しながら移行を進める」ではなく 「思い切って AWS 上の構成をひとまず Google Cloud へとにかく移行する（但しサーバーレス化はする）」 へ舵を切ります。
どうせ後で作りかえるけど、その前にパブリッククラウド移行は終えてサーバーレス化の恩恵を受けられるようにしつつ、作り替えやすい状態にしておく狙いです。
続きは後編にて
現在、鋭意執筆中です。お楽しみに。
