はじめに

当該記事はラスベガスで行われていた Google Cloud Next 2025 の Day2 の Deep dive into the latest innovations in AlloyDB: The new way to PostgreSQL に関する記事となります。

概要

前編記事にては主に AloloyDB の機能面について、記載しましたが、当該記事は AlloyDB の事例を中心に記載します。

Intesa 銀行事例

導入経緯

イタリアの大手銀行の事例となります。従来のインフラサービスでは 1000 万を超える顧客アカウントへのスケールが困難であり、パートナー企業からの推奨により、AlloyDB の導入に至ったとのこと。

課題と解決策

導入においてはもちろん課題もあり、それに対してどのように対応したか、がお話されておりました。

表に纏めてみました。

種別 課題 解決策
ネットワーク Cloud VPN による高トランザクション PSC によってインターネット通らないことで解決
継続性 Postgres のクラスタ構成をとっていたが、DR テストで RPO = 0 を達成できない AlloyDB ではクロスリージョンレプリケーションにより RPO=0、最小限のRTOを達成
パフォーマンスとコスト 以前のシステムでは、スペック 64コア、10TB のディスクサイズだった 従来のインフラの同等以上(32コア、2.5TBのディスク利用)のパフォーマンスを発揮し、コスト効率向上、リストア速度も向上(1TB/時間、9TB/時間)

当該事例纏め

AlloyDB も 大手銀行で扱われているという事例でした。AlloyDB の継続性やパフォーマンスについては、前編の性能でもお話ししていましたが、やはり 1000万の顧客に対するインフラとしても十分耐えうるものであり、実際の試験で RPO、RTO ともに厳しい金融業界で基準を満たせていることから、基幹システムにおいても強力な選択肢になると感じました。
今回 PSA を使わなかった理由については、触れられていませんが、別の NW とならずに同一 NW 内で通信を完結させるためと考えられます。

NW 構成

パフォーマンス

参考内容まとめ

AlloyDB プライベートサービスコネクト
AlloyDB クロスリージョンレプリケーション
AlloyDB プライベートサービスアクセス

Manhattan Associates 社事例

導入経緯

サプライチェーン向けのソフトウェアを提供する会社で、約 2000 の MySQL インスタンスを運用しており、顧客毎に独立したデータベースを使っていて、そのデータベースから出力するレポート作成に時間を要していたとのことです。

課題と解決策

導入においてはもちろん課題もあり、それに対してどのように対応したか、がお話されておりました。

表に纏めてみました。

種別 課題 解決策
パフォーマンス 顧客単位のデータベースへのレポート出力クエリに多く時間を要していた MySQL から　AlloyDB へレプリケーションして移行し、数十分かかっていたレポートが数秒で完了し、これによりリアルタイムに近いレポート提供ができるようになった
ナレッジ共有 1200人のサービスチームが年間1万もの設計書などのドキュメントを作成しているがチーム間で知識共有がされにくい ドキュメントを Agent Space にインデックス化し、AlloyDB Omni に構造化データを格納。自然言語による質問応答システムを構築し、一般的な質問は Google Agentspace、構造化された質問は AlloyDB に連携することで、チーム間のナレッジ共有と業務効率化を実現した

当該事例まとめ

気になったのが、MySQL から AlloyDB への移行において弊害になった点などあればそれも聞きたかったですが、ちょっと見つけられずでしたが、AI と関連させた情報蓄積及び再利用について、チャットボットが応答する仕組みは勉強になりました。質問内容が具体的であれば AlloyDB へルーティングされ、SQL クエリが実行されるとのこと、その他であれば Agent Space が回答しているとのことで、SQL クエリで埋め込みの自然言語を利用していました(前編で紹介した機能)。そういった分析/ナレッジ基盤としての扱いをしている点、AlloyDB Omni として具体的な事例になっていて驚きました。

パフォーマンス

自然言語 SQL 生成

参考内容まとめ

AllyDB Omni
Google Agentspace
AlloyDB AI の自然言語を使用して SQL を生成する

まとめ

各社の事例をみまして、エンタープライズ企業でも確実に Google Cloud のサービスが多く扱われていることを、また実感できると同時に、それに耐えうるデータベースであることを再認識しました。
Cloud SQL でもスペックなどでは Enterprise Plus がでており似ている部分がありますが、クロスリージョンなどのリージョンをまたいだ構成、運用支援(前編で記載したアップデート部分など)も AlloyDB はまた整い始めているので、今後選択する際に MySQL 必須でなければまず話題にあがりそうだと感じました。AI を利用した知識共有については、こういったこともできるんだ、といい刺激になり、今後もそういったユースケースについては、アンテナ高くし取り組み、実務で良いアーキが生み出せるよう勉強を続けたいと思いました。