はじめに

本記事はGoogle Cloud Next Tokyo 2024 のDay1(8/1)においてキャリアデザインセンター森さん、システムサポート山本さん、Google Cloud 田野倉さんがディスカッションされた「『type 就活』DX 成功は Amazon RDS から AlloyDB への完全移行にあった」のレポートです。

公式セッション紹介

就活生向けのサービスである『type 就活』は、コロナ禍の就活市場における学生の行動変化により、この数年で会員数が 1.5 倍、トラフィックは 10 倍に。今後、さらに拡大が予想される『type 就活』ですが、安定かつ高品質なサービス提供を考えた際の最適解が、既存の AWS から BigQuery や AlloyDB がある Google Cloud への完全移行だった背景を、ビジネスとシステムの両側面から紹介いたします。

発表資料

アーカイブ動画は9月に公開されるとのこと(Google Cloud Next Tokyo 2024として)

概要／おすすめポイント

もともと RDS for MySQL で稼働していたシステムを(分析基盤としてBigQuery+Looker Studioをすでに利用していた)Google Cloudへ寄せていく(移行する)にあたり、AlloyDB for PostgreSQLを採用することになった、というお話になります。
Google CloudではMySQL互換のDBaaSとしては Cloud SQL for MySQLもありますが、AlloyDBでは(カラムナエンジンも搭載されているため)集計・集約クエリも実行できることが決め手となり、(エンジンを変更するコストを考慮しても)AlloyDBの採用に至ったとのことでした。

セッション内容の紹介

ビジネス的な背景などについても時間を割いてディスカッションされていましたが、こちらでは Google Cloudへの移行にフォーカスして紹介します。
ディスカッション形式でしたためそれぞれの内容については概要に触れるくらいでしたが、私は次の2点がポイントかと思いました。

MySQL から PostgreSQLへの移行について、そんなに難易度が高くなかった
- pgloaderを使用してテーブル毎に移行を実施
全体的に性能が向上した
- Query Insightsで負荷の高いクエリをチューニングすることで、最終的にピーク時DB負荷が 1/4 程度に低減

MySQLからPostgreSQLへの移行は、もちろん行うことはできますがテーブル定義やSQLなど含めて互換性がないものもあるので、移行を決断してやりとげた、というのはお互いに信頼して実施されていることが伝わってきました。
また、負荷の高いクエリを自分たちでもチューニングを簡単に行える、という点は運用を行っている中で今後何か起こっても大丈夫、という安心感を得ることができるのため運用側にとっても助かるポイントだなと思いました。

可能であれば両方とももう少し深堀してお話が聞けると良いかと思いました。特にPostgreSQLへの移行時に気を付けたポイントやはまりポイントは知見を知りたい人も多くいると思います。
また、性能についてもMySQLを利用していた時のボトルネックとどのような違いが出てきたのか、辺りを知りたいと思いました。

まとめ

リレーショナルデータベースの移行をおこなう際には、なるべくデータベースエンジンの変更を行わずに移行を行いたい、というのがスタンダードですが、それを乗り越えても AlloyDB for PostgreSQLを採用された、というのが驚きでした。
詳細は触れられていませんでしたが、リアルタイムの集計・集約クエリがそのまま実現できるというところがニーズにマッチしていたと思われます。

タイミング的にAsk The Speakerに並べなかったのが残念です。。