AlloyDB 奮闘記

https://layerx.connpass.com/event/385842

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 と して腕の見せ所になるので楽しみ まとめ