AlloyDB 奮闘記

Transcript

1. 1 AlloyDB 奮闘記 ふかぼりSRE ー現場の深淵ー @hatappi

2. 2 • 株式会社メルカリ • 2019年入社 • Cross-Border SRE & Enabling

   チーム @hatappi

3. 3 1. メルカリ グローバルアプリ / AlloyDB の紹介 2. 運用の中で起きた課題 3.

   どのように解決を試みたか 4. まとめ アジェンダ

4. 4 メルカリ グローバルアプリ / AlloyDB の紹介

5. 5 　　 世界共通アプリ「メルカリ グローバルアプリ」 2025年9月に台湾・香港で提供開始、3年以内に50以上の国や地域への拡大を目指す 海外の購入者と日本国内の事業者の双方の体験を向上し、よりかんたんかつ安心・安全な取引環境構築を実現に向けて 越境取引における購入者・事業者双方の課題を解決し、グローバルでの事業拡大を目指す。 5

6. 6 AlloyDB for PostgreSQL とは • コンピューティングとストレージが分離 ◦ 独立スケーリング可能。セルフマネージド PostgreSQL

   比で 4 倍以上高速 • 高可用性 ◦ 99.99% の可用性 SLA（メンテナンス含む）。自動フェイルオーバーと復元 • フルマネージド ◦ Backup、Replication、パッチ適用、メモリ・ストレージ管理を自動化 PostgreSQL 互換の Google Cloud フルマネージド DB

7. 7 運用の中で起きた課題

8. 8 https://speakerdeck.com/mercari/mercari-gears-2025-building-foundation-for-mercaris-global-expansion?slide=56

9. 9 https://speakerdeck.com/mercari/mercari-gears-2025-building-foundation-for-mercaris-global-expansion?slide=59

10. 10 商品情報の同期フロー

11. 11 モジュール間で AlloyDB Cluster を共有しているため 他の Module の処理にも影響が出てしまった 😢 1.

    障害や一時的な高負荷により、メッセージの ack に失敗 2. ack されなかったメッセージが大量に再送される 3. 処理のために新規コネクションが増加する 4. コネクションが逼迫する Pub/Sub メッセージの Retry Storm 発生 🔥

12. 12 どのように解決を試みたか

13. 13 • アプリケーションの改善 • Dead Letter Queue 導入 • データベース周りの改善

    改善策の全体

14. 14 コネクション管理の最適化 読み込み負荷の分散 データベース周りの改善 Read Replica Managed Connection Pooling

15. 15 改善 Before / After Before After

16. 16 コネクション管理の最適化 読み込み負荷の分散 データベース周りの改善 Read Replica Managed Connection Pooling

17. 17 Read Replica 対応の課題 • Module 数が多いため１つ１つ対応するのには時間がかかる • 開発者がクエリごとにPrimary, Read

    Poolのどちらを使用すべきかを 判断するコストを下げたい ◦ これが実現できるとRead Replicaの対応だけでなく将来的に別のデータベースへ 移行したいとなった時などもスムーズに移行できるようになる

18. 18 実装の課題 • Primary と Read Pool で接続先が違うため sql.DB は最低２つ必要になるた

    め使い分けクエリ種別で使い分けが必要 • sqlc はクエリ種別でメソッドを分けるが、接続先の選択（Read Replica振 り分け等）は非対応

19. 19 sqlc が生成する DBTX インターフェースを満たす PrimaryとRead Pool へのルー ティング機能をもったクライアントを実装する 解決策

    透過的にクエリを振り分ける

20. 20 Read Replica: 解決策 実装イメージ

21. 21 コネクション管理の最適化 読み込み負荷の分散 データベース周りの改善 Read Replica Managed Connection Pooling

22. 22 STEP 1: MCnP を Enable する STEP 2: 各

    Module を徐々に MCnP 経由に移行する Managed Connection Pooling (MCnP) 移行ステップ

23. 23 Language Connector で自動 IAM 認証をしている場合は MCnP がサポートされていなかった 壁 ①：MCnP

    を Enable できない https://docs.cloud.google.com/alloydb/docs/release-notes#January_21_2026

24. 24 解決策: Manual IAM Authへの切り替え

25. 25 壁 ②：段階的移行ができない Language Connector を使っていると、自動的に MCnP 経由に切り替わる 想定 実際

26. 26 壁 ②：段階的移行ができない Language Connector と Direct Connect で Pooler

    の数が違う

27. 27 • Language Connector を使用しない Direct 接続により複数台の Pooler を 活用しつつ

    Module ごとの段階的な 移行を実現 • Pooler は台数やコネクション数の 上限があるため引き続きコネクションの設 計は必要 解決策：Direct 接続

28. 28 結果 データベースごとのコネクション数も落ち着いた 🎉

29. 29 まとめ

30. 30 ① Managed サービスは「丸投げ」ではない 内部の挙動（認証方式、Pooler のデプロイ方法、コネクションの経路）を 理解した上で使うことが重要 ② 抽象化レイヤーが移行時には障壁になることも Language

    Connector のような便利な抽象化も、移行・チューニング時には「中で 何が起きているか」が見えなくなるリスクがある ③ スケールの挑戦はこれから 今後より多くの国や地域に展開されていく中でどうスケールさせていくかなど SRE と して腕の見せ所になるので楽しみ まとめ