こんにちは！DX開発事業部の橋本です。

今回は、Google Cloud Next Tokyo 26のDay 1で聴講したセッション「メルカリのグローバルアプリで挑んだ AlloyDB 運用と課題解決の実践記」について、新卒エンジニアとしての視点や所感を交えながらレポートとしてまとめます。

1. グローバル規模のアプリを支える柔軟なアーキテクチャ

まず、海外の購入者が日本国内の「メルカリ」や「メルカリShops」の商品を直接かんたんに閲覧・購入できるように開発された、メルカリのグローバルアプリが「Modular Monolith with Flexible Deployment」というアーキテクチャを採用していることが紹介されました。

システム全体は1つのバイナリ（Monolith）で構成されながらも、内部では複数のモジュールに分割されています。これにより、BFF（Backend for Frontend）からのリクエストに応じてデプロイ単位を切り分け、モジュール間ではgRPCによる通信を行うことで、スケーラビリティと柔軟性を両立させています。

2. データベース基盤：「AlloyDB for PostgreSQL」の優位性

この大規模なアプリケーションを支えるデータベースとして、「AlloyDB for PostgreSQL」が採用されています。主な特徴は以下の3点です。

  • コンピュートとストレージの分離: それぞれを独立してスケーリングでき、セルフマネージドのPostgreSQLと比較して4倍以上の高速化を実現。

  • 高可用性: メンテナンス時を含め、99.99%のSLAを保証。

  • フルマネージド: バックアップやパッチ適用などの運用作業を自動化。

フルマネージドサービスを活用することで、運用負荷を抑えながら高い可用性やパフォーマンスを実現できる点は、クラウドを利用する大きなメリットです。 特に印象的だったのは、インフラの運用負担を軽減することで、アプリケーションエンジニアがユーザー価値の創出や機能開発に集中できる環境を作れるという点です。単に「運用が楽になる」だけでなく、エンジニアが本来注力すべき領域に時間を使えるようになることこそが、マネージドサービスの真の価値なのだと実感しました。

3. 「ベクトル検索」による類似商品検索の最適化

技術的に特に興味深かったのが、AlloyDBを活用したベクトル検索の事例です。これはアプリ内の類似商品レコメンド機能に利用されています。

具体的には、Vision-Language Model（SigLIP）を用いて商品画像をベクトル（数値列）に変換してAlloyDBに格納し、閲覧中の商品とベクトルの距離が近い商品を検索することで、見た目の似た商品を推薦しています。

AlloyDBはPostgreSQLの拡張機能であるpgvectorに加え、独自の高速インデックス「ScaNN」をサポートしているため、データベース内で処理を完結させながら高速な検索が可能です。

機械学習モデルとデータベースをシームレスに連携させている点が非常に鮮やかでした。特に、「見た目が似ている」というベクトル検索条件と、「現在販売中である」といったビジネス条件を、1本のSQLで組み合わせて検索できる点が強力です。

検索専用の外部システムを別途構築せず、既存のデータベース基盤に処理を集約することで、システム全体をシンプルに保てます。技術的な性能だけでなく、開発・運用コストや保守性まで考慮して構成を選択している点に、実際のサービス開発ならではの工夫を感じました。 これまで機械学習によるレコメンドというとモデルそのものに注目しがちでしたが、それを実際のサービスへ組み込むためのデータベースや検索基盤まで含めて考える重要性を学びました。

4. 運用上の課題と実践的な解決策：負荷分散のアプローチ

大規模サービスでは、システムを構築するだけでなく、実際の運用で発生する課題に継続対応していくことも不可欠です。

  • Read Poolを用いた読み取り負荷の分散 トラフィックの増加に伴いPrimary（書き込み用）ノードの負荷が高まったため、読み取り専用の「Read Pool」が導入されました。しかし、ここでは「開発者がクエリごとにPrimaryとRead Poolのどちらへ接続するかを判断・指定する」という新たな負担が発生します。 この課題に対してメルカリでは、sqlcが生成するインターフェースを活用し、SELECTクエリは自動的にRead Poolへ、更新系クエリはPrimaryへ透過的に振り分けるクライアントを独自実装して対応されています。

SREチームがこのような基盤改善を行うことで、アプリケーションエンジニアは接続先を意識することなく開発に集中できます。単に負荷を分散する技術的解決にとどまらず、開発者の使い勝手（DX）まで考慮して仕組みを設計している点に感銘を受けました。 個々の技術だけでなく、チーム間で役割を分担しながら開発者体験とシステムの信頼性を同時に高めていく視点の大切さを知りました。

5. コネクション管理とマネージドサービス移行への障壁

さらに、データベースへのコネクション数管理についても具体的な運用事例が紹介されました。

Pub/Subメッセージの処理エラーをきっかけとして「Retry Storm（再送の嵐）」が発生し、新規コネクションが急増してデータベースのリソースが逼迫する事態が発生したそうです。この根本解決として、接続を集約・再利用する「Managed Connection Pooling（MCnP）」が導入されました。

しかし、導入にあたっては以下の障壁も存在したとのことです。

  • 自動IAM認証の未サポート: GoのSDKを利用して手動でトークンを取得する「Manual IAM Auth」方式へ切り替えて対応。

  • 段階的な移行の難しさ: 自動ルーティングを避けるため、あえて「Direct接続（Port 5432/6432）」を採用し、モジュール単位で段階的に移行。

実際の現場では技術的制約や既存環境との兼ね合いにより、理想通りにいかない場面が多くあります。そうした制約の中で現実的な解決策を導き出し、着実にシステムへ適用していく力こそが実践的なエンジニアリングなのだと気づかされました。

6. おわりに

 セッションの最後に述べられていた、以下のメッセージが心に残っています。

  • 「Managed（マネージド）サービスは丸投げではない。内部の仕組みを理解して用いること」

  • 「導入して終わりではなく、継続的に観測・調整すること」

クラウドサービスは非常に便利な反面、ブラックボックスとして扱うのではなく、「裏側でどう動作しているか」「現在の規模や要件に適しているか」を理解し、継続的に改善していく姿勢が欠かせません。

モジュラーモノリス、AlloyDB、ベクトル検索、Read Pool、MCnPなど、一見異なる技術要素も、セッション全体を通してみると「現在の課題を正確に把握し、その時点で最適な解を選択して運用しながら育てていく」という一貫した思想で繋がっていました。

私自身も目の前のコードを書くだけに留まらず、システム全体のアーキテクチャやパフォーマンス、運用までを俯瞰して見られるエンジニアを目指します。今回得た学びを日々の業務に活かし、実際の課題に対して自ら解決策を考え行動できるよう、精進してまいります。

最後までお読みいただき、ありがとうございました！