メルカリのグローバルアプリで挑んだ AlloyDB 運用と課題解決の実践記

Google Cloud Next Tokyo 2026
#googlecloudnext

1. メルカリのグローバルアプリで 挑んだ AlloyDB 運用と 課題解決の実践記 Proprietary
2. 畑中 悠作 (@hatappi) 株式会社メルカリ Cross Border SRE Google Cloud Next Tokyo Proprietary
3. アジェンダ 01 メルカリ グローバルアプリと AlloyDB 02 AlloyDB 運用の 3 つの取り組み ・ベクトル検索 ・Read Pool ・Managed Connection Pooling 03 まとめ Google Cloud Next Tokyo Proprietary
4. 01. メルカリ グローバルアプリと AlloyDB Google Cloud Next Tokyo Proprietary
5. メルカリ グローバルアプリとは 2025 年 9 月に台湾・香港で提供開始、 3 年以内に 50 以上の国や地域への拡大を目指す 海外の購入者と日本国内の事業者の双方の体験を向上し、よりかんたんかつ安心・安全な取引環境構築を実現に向けて 越境取引における購入者・事業者双方の課題を解決し、グローバルでの事業拡大を目指す。 メルカリ、米国で世界共通アプリ「メルカリ グローバルアプリ」提供開始 (2026 年 6 月) https://about.mercari.com/press/news/articles/20260618globalapp/ Google Cloud Next Tokyo Proprietary
6. メルカリ グローバルアプリのアーキテクチャ https://speakerdeck.com/mercari/mercari-gears-2025-building-foundation-for-mercaris-global-expansion?slide=56 Google Cloud Next Tokyo Proprietary
7. メルカリ グローバルアプリのアーキテクチャ https://speakerdeck.com/mercari/mercari-gears-2025-building-foundation-for-mercaris-global-expansion?slide=59 Google Cloud Next Tokyo Proprietary
8. AlloyDB for PostgreSQL とは PostgreSQL 互換の Google Cloud フルマネージド DB • コンピューティングとストレージが分離 ◦ • 高可用性 ◦ • 独立スケーリング可能。セルフマネージド PostgreSQL 比で 4 倍以上高速 99.99% の可用性 SLA（メンテナンス含む）。自動フェイルオーバーと復元 フルマネージド ◦ Backup、Replication、パッチ適用、メモリ・ストレージ管理を自動化 Google Cloud Next Tokyo Proprietary
9. 02. AlloyDB 運用の 3 つの取り組み Google Cloud Next Tokyo Proprietary
10. ベクトル検索 Google Cloud Next Tokyo Proprietary
11. ベクトル検索 データを『意味・特徴を表すベクトル』で表現し、近いものを探す Google Cloud Next Tokyo Proprietary
12. AlloyDB のベクトル検索 • AlloyDB は pgvector（PostgreSQL 拡張）をサポート ◦ • 素朴にやると全件スキャンで重い ◦ • vector 型 ＋ コサイン距離演算子 → いつもの SQL の中でベクトル検索できる AlloyDB の ScaNN インデックス（近似最近傍 / ANN）で高速化 AlloyDB なら「ベクトルの保存」も「近傍検索」も DB の中で完結 Google Cloud Next Tokyo Proprietary
13. メルカリ グローバルアプリでのベクトル検索 • • 商品詳細ページに表示される類似商品に AlloyDB のベクトル検索を使用 商品画像の Embedding ◦ ◦ Google Cloud Next Tokyo Vision-Language Model である SigLIP を 使用してベクトル化 ベクトルを AlloyDB に格納する Proprietary
14. AlloyDB（pgvector）で実現するメリット • 類似検索で返したいのは「近い」だけではない ◦ ◦ • • 「販売中」といった条件も必要になる 1 本の SQL で「似てる×今買える」を同時に絞れる AlloyDB 外で行う場合だと「候補取得=>在庫を別途問い合わせ」と依存が 増える 既存の AlloyDB を活用することで新しい外部サービスも不要 Google Cloud Next Tokyo Proprietary
15. 運用課題 課題① ScaNN index の手動管理 データの傾向や量に応じて作成していく必要がある。 解決策として Automatic index maintenance を使用を検討中 https://docs.cloud.google.com/alloydb/docs/ai/maintain-vector-indexes?hl=en#maintain-index-automatically 課題② テーブルの肥大化 古い Embedding が溜まりクエリの負荷があがる 解決策として古い Embedding を削除するバッチを実装して実行 Google Cloud Next Tokyo Proprietary
16. Read Pool Google Cloud Next Tokyo Proprietary
17. Read 負荷が増大 • • 展開国の拡大によりトラフィックが増えクエリ数も増加 類似検索のように単なる読み書きではない機能も増加 Primary だけでは支えきれなくなる Google Cloud Next Tokyo Proprietary
18. Read Pool とは • Read Pool ＝ 読み取り専用ノードのまとまり ◦ ◦ Read Pool に 1 つの IPアドレスが割り当てられる 1 つの Read Pool が複数の読み取りノードを持ち、ノード数で 読み取りをスケールできる Google Cloud Next Tokyo Proprietary
19. 導入の壁 • • Module 数が多いため 1 つ 1 つ対応するのには時間がかかる 開発者がクエリごとに Primary, Read Pool のどちらを使用すべきかを 判断するコストを下げたい ◦ これが実現できると Read Pool の導入だけでなく将来的に別のデータベースへ 移行したいとなった時などもスムーズに移行できるようになる Google Cloud Next Tokyo Proprietary
20. 解決策 透過的にクエリを振り分ける sqlc が生成する DBTX インターフェースを満たす Primary と Read Pool へのルー ティング機能をもったクライアントを実装する Google Cloud Next Tokyo Proprietary
21. 実装イメージ Google Cloud Next Tokyo Proprietary
22. 新規 Read Pool のウォームアップ • 新規作成した Read Pool はバッファプールが 温まっていない ◦ • そのまま投入すると、ディスクの読み込みが多くなり、 パフォーマンスが一時的に悪化する恐れがある。 投入前に本番クエリを mirroring で流し込み、 ウォームアップ ◦ ◦ mirroring なのでお客様への影響ゼロ。 Read Pool のキャパシティ確認にも使える。 Google Cloud Next Tokyo Proprietary
23. Managed Connection Pooling (MCnP) Google Cloud Next Tokyo Proprietary
24. Managed Connection Pooling とは 多数のクライアント接続を集約・再利用し、DB の接続数を抑える コネクション プーリングのマネージド版 Google Cloud Next Tokyo Proprietary
25. Managed Connection Pooling 導入のきっかけ 商品同期フロー Pub/Sub メッセージの Retry Storm 発生 1. 2. 3. 4. 障害や一時的な高負荷により、メッセージの ack に失敗 ack されなかったメッセージが大量に再送される 処理のために新規コネクションが増加する コネクションが逼迫する Google Cloud Next Tokyo Proprietary
26. Managed Connection Pooling への移行ステップ 1. MCnP を有効にする 2. 各モジュールを徐々に MCnP 経由にする Google Cloud Next Tokyo Proprietary
27. 壁①：MCnP を有効にできない Language Connector で自動 IAM 認証をしている場合は MCnP がサポートされていなかった https://docs.cloud.google.com/alloydb/docs/release-notes#January_21_2026 現在この問題は解決している Google Cloud Next Tokyo Proprietary
28. 解決策: Manual IAM Authへの切り替え Google Cloud Next Tokyo Proprietary
29. 壁 ②：段階的移行ができない Language Connector では自動的に MCnP 経由に切り替わる 想定 Google Cloud Next Tokyo 実際 Proprietary
30. 壁 ②：段階的移行ができない Language Connector と Direct Connect で Pooler の数が違う Google Cloud Next Tokyo 現在はどちらも同じ Pooler 数 Proprietary
31. 解決策： Direct 接続 Language Connector を使用しない Direct 接続により複数台の Pooler を 活用しつつ Module ごとの段階的な移行を実現 Google Cloud Next Tokyo Proprietary
32. 移行後も続くコネクション数のチューニング • • MCnP にはプールの設定を変更するオプションがいくつかある プールの最小コネクション数 connection-pooling-min-pool-size は Pooler ごと・DB ごとに確保される ◦ • 大きくしすぎると、今度は AlloyDB インスタンスの接続上限に 到達する恐れがある モニタリングしながら適切な値を判断していく ◦ MCnP を入れて終わりではない Google Cloud Next Tokyo Proprietary
33. AlloyDB Primary へのコネクション数 Before After Google Cloud Next Tokyo Proprietary
34. 03. まとめ Google Cloud Next Tokyo Proprietary
35. まとめ • 横断的な学び ◦ Managed は丸投げではない ▪ ◦ 導入して終わりではない ▪ ◦ 観測しながら継続的に調整・維持する （コネクション数・インデックス・データ量） 「その時々の規模に合った選択」をする ▪ • 「何が Managed されているか」を理解して使う 成長フェーズで最適解は変わる これから ◦ AlloyDB と一緒にプロダクトはより多くの国に展開して成長していく ◦ スケール課題は次々出てくるので SRE の腕の見せ所 Google Cloud Next Tokyo Proprietary
36. Thank you Proprietary