はじめに

DX開発事業部の北村です。

2026年7月30日にGoogle Cloud Next Tokyo 26 に参加してきました。

『メルカリのグローバルアプリで挑んだ AlloyDB 運用と課題解決の実践記』というセッションを聴講しましたので、特に印象に残った内容と学びをまとめます。

セッション概要

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

登壇者：株式会社メルカリ 畑中 悠作 氏

公式より

メルカリが世界 50 ヶ国以上に展開を予定しているグローバル アプリは、立ち上げ期から成長期へと歩みを進めています。その時々の規模に合った選択を重ねながら、私たちは AlloyDB とともにデータベース基盤を育ててきました。本セッションでは、マネージド コネクション プーリングやベクトル検索の導入をはじめ、成長の過程で試してきた工夫や、AlloyDB の運用で直面したトラブルとその解決策を、うまくいった話もそうでない話も交えて、実際の経験からお話します。

セッション内容

メルカリのグローバルアプリを支えるデータベース基盤 AlloyDB について、運用で直面した課題と解決に向けた3つの取り組み(ベクトル検索・Read Pool・Managed Connection Pooling)を解説いただきました。

メルカリ グローバルアプリと AlloyDB

メルカリ グローバルアプリは、2025年9月に台湾・香港で提供開始されたメルカリ初の世界共通アプリで、3年以内に50以上の国や地域への拡大を目指しています(2026年6月には米国でも提供開始)。

アーキテクチャはモジュラーモノリスを採用し、データベースには PostgreSQL 互換のフルマネージド DB である AlloyDB を利用しています。AlloyDB はセルフマネージド PostgreSQL 比で4倍以上高速、メンテナンス込みで 99.99% の可用性 SLA を持ち、1つのクラスタ内でモジュールごとに DB を分離する構成で運用されています。DBの選定で興味深かったのは、性能面ではSpannerの方が勝っていたものの、ロックインを避けるためにAlloyDBを選定された点が印象的でした。

取り組み① ベクトル検索

商品詳細ページの類似商品表示に、AlloyDB のベクトル検索(pgvector)を活用しています。商品画像を Vision-Language Model の SigLIP でベクトル化して AlloyDB に格納し、「見た目が似た商品」を表示しています。

ポイントは、類似検索で返したいのは「近い」だけではないことです。「販売中」という条件も必要なため、1本の SQL で「似てる×今買える」を同時に絞れるのが AlloyDB の強みです。外部のベクトル検索サービスを使うと在庫の問い合わせが別途必要になり依存が増えますが、既存の AlloyDB なら DB 内で完結します。

一方で運用課題もあり、ScaNN インデックスの手動管理には Automatic index maintenance の活用を検討中、古い Embedding が溜まるテーブルの肥大化には削除バッチで対応しているとのことでした。

取り組み② Read Pool

プロダクトのユーザーが増えるにつれ課題も出てきました。展開国の拡大でクエリ数が増え、さらにベクトル検索のような単なる読み書きではない機能も加わったことで、Primary だけでは読み取り負荷を支えきれなくなり、読み取り専用ノードのまとまりである Read Pool を導入しました。ただし Module 数が多く、開発者がクエリごとに接続先を判断するのはコストが高いという課題がありました。

解決策は「透過的にクエリを振り分ける」ことです。sqlc が生成する DBTX インターフェースを満たすルーティングクライアントを実装し、SELECT 系は Read Pool へ、書き込み系は Primary へ自動で振り分けます。アプリケーション側は接続先を意識する必要がありません。

ℹ️ sqlc / DBTX：Go言語向けのSQLコード生成ライブラリ（sqlc）のDBTXインターフェース

投入前には本番クエリを mirroring で流し込み、バッファプールをウォームアップします。ユーザーへの影響ゼロでパフォーマンス悪化を防ぎ、キャパシティ確認にも使えるという実践的な工夫も紹介されました。

取り組み③ Managed Connection Pooling（MCnP）

Managed Connection Pooling(MCnP)は、クライアント接続を集約・再利用して DB の接続数を抑えるマネージド機能です。導入のきっかけは、Pub/Sub メッセージの Retry Storm によるコネクションの逼迫でした。

導入時は「Language Connector の自動 IAM 認証では MCnP が使えない(当時)」「段階的移行ができない」という壁がありましたが、Manual IAM Auth への切り替えと Direct 接続により、Module ごとの段階的な移行を実現しています。

効果は絶大で、大きく波打っていたコネクション数が導入後は安定して推移しています。一方で、プール設定を大きくしすぎると接続上限に達する恐れもあるため、「MCnP を入れて終わりではなく」モニタリングしながらチューニングを続けているとのことでした。

まとめ

AlloyDB の3つの機能を、実際のグローバルプロダクトの運用実践として学べるセッションでした。

特に印象的だったのは、「マネージドは丸投げではない」ということです。「何がマネージドされているか」を正しく理解して使うことで、最適な運用や課題に対する解決策を選択することができると感じました。また、「導入して終わり」ではなく、インデックス管理やコネクション数のチューニングなど、導入後も観測と調整を続けることで初めて価値を発揮するということを学びました。

また、透過的なクエリ振り分けや mirroring によるウォームアップなど、開発者体験とサービス品質を両立させる工夫も大変参考になりました。

マネージドサービスとの向き合い方、最適な解決策を選択する考え方、開発者体験とサービス品質を両立する工夫など、普段の業務で取り入れていきたいと感じました。