Google Cloud Next Tokyo | メルカリShops における Cloud SQL 活用とその歴史

https://www.googlecloudevents.com/next-tokyo/sessions?session_id=3127645

メルカリ Shops では、マイクロサービス アーキテクチャを採用しており主要なデータベースとして Cloud SQL を利用しています。リリースから約 4 年が経過しサービス規模は大きく拡大しましたが、それに伴い様々な問題に直面しました. 本セッションでは主にアプリケーションとデータベースにフォーカスし、 私たちがスケールや安定性、運用、コストなどどのような課題を抱えそれらをどのように解決してきたのかを紹介します。

取り上げる主な Google Cloud 製品 / サービス
・Cloud Run
・Cloud SQL
・Database Migration Service

Transcript

1. Proprietary メルカリShops における Cloud SQL 活用とその歴史
2. Proprietary 02 Google Cloud Next Tokyo 本田 恭 DBRE team
3. Proprietary 03 Google Cloud Next Tokyo Agenda 01. メルカリShops の歴史 02. サービスの成長と課題 Cloud SQL Enterprise Plus 03. 運用事例 Data cache Serverless VPC Access DB Consolidation 04. まとめ
4. Proprietary 04 Google Cloud Next Tokyo Agenda 01. メルカリShops の歴史 02. サービスの成長と課題 Cloud SQL Enterprise Plus 03. 運用事例 Data cache Serverless VPC Access DB Consolidation 04. まとめ
5. Proprietary 05 Google Cloud Next Tokyo 01. メルカリShops の歴史
7. Proprietary 07 Google Cloud Next Tokyo
8. Proprietary 08 Google Cloud Next Tokyo 2021-10 リリース 2023-02 Cloud Run service が 35 を突破 (microservice 数) 2024-04 すべての Cloud SQL を Enterprise Plus へ移行 2024-10 リリース 3 年を迎え 着実に成長中 01. メルカリShops の歴史
9. Proprietary 09 Google Cloud Next Tokyo 2021-10 リリース 2023-02 Cloud Run service が 35 を突破 (microservice 数) 2024-04 すべての Cloud SQL を Enterprise Plus へ移行 01. メルカリShops の歴史 2024-10 リリース 3 年を迎え 着実に成長中
10. Proprietary 010 Google Cloud Next Tokyo Cloud Run gRPC サーバとして稼働 microservice アーキテクチャを採 用し各サービス間は gRPC で通信 Cloud SQL Cloud SQL for PostgreSQL を採用 microservice 毎にインスタンスも論 理 DB も別 VPC Cloud SQL は VPC 上に構築 Cloud Run と Cloud SQL は Serverless VPC Access で疎通 01. メルカリShops の歴史 https://go.dev/blog/go-brand/Go-Logo/PNG/Go-Logo_Blue.png https://wiki.postgresql.org/images/3/30/PostgreSQL_logo.3colors.120x120.png
11. Proprietary 011 Google Cloud Next Tokyo 01. メルカリShops の歴史 auth product auth service Cloud Run Multiple Instances product service Cloud Run Multiple Instances VPC Cloud SQL Serverless VPC Access Cloud SQL
12. Proprietary 012 Google Cloud Next Tokyo 01. メルカリShops の歴史 02. サービスの成長と課題 Cloud SQL Enterprise Plus 03. 運用事例 Data cache Serverless VPC Access DB Consolidation 04. まとめ Agenda
13. Proprietary 013 Google Cloud Next Tokyo 02. サービスの成長と課題
14. Proprietary 014 Google Cloud Next Tokyo 02. サービスの成長と課題
15. Proprietary 015 Google Cloud Next Tokyo • 利用シーンの拡大 ◦ 大規模キャンペーンなどの実施 • メルカリのトップページからの誘導 ◦ 影響がメルカリ本体にも波及 • リリース当初と比べてよりに品質が求められる 02. サービスの成長と課題
16. Proprietary 016 Google Cloud Next Tokyo • 利用シーンの拡大 ◦ 大規模キャンペーンなどの実施 • メルカリのトップページからの誘導 ◦ 影響がメルカリ本体にも波及 • これまで以上に品質が求められる 02. サービスの成長と課題 特に Cloud SQL 周りの課題
17. Proprietary 017 Google Cloud Next Tokyo 1. アプリケーションの Latency 2. メンテナンスのダウンタイム 3. 大規模イベント前の対応 02. サービスの成長と課題
18. Proprietary 018 Google Cloud Next Tokyo • 徹底的な正規化による弊害 ◦ 1 商品を返すために数多くのテーブルにクエリを打つ • 大量の INSERT/DELETE の影響による dead tuples の増加 ◦ シンプルな Scan の劣化 • クエリは遅くないが Latency は高い 02. サービスの成長と課題 アプリケーションの Latency
19. Proprietary 019 Google Cloud Next Tokyo • 徹底的な正規化による弊害 ◦ テーブルの非正規規化と QueryView • 大量の INSERT/DELETE の影響による dead tuples の増加 ◦ KVS ライクな利用にスキーマ変更 • クエリは遅くないが Latency は高い ◦ database/sql の Stats の可視化 02. サービスの成長と課題 アプリケーションの Latency
20. Proprietary 020 Google Cloud Next Tokyo • Cloud SQL メンテナンスのダウンタイムが長い ◦ ドキュメント上だと 30s - 60s • 40 台以上あり一部機能毎に数台ずつ夜間やるのも困難(面倒) • メンテナンス毎に都度スケジュール調整 / 周知も大変 02. サービスの成長と課題 メンテナンスのダウンタイム
21. Proprietary 021 Google Cloud Next Tokyo • Cloud SQL メンテナンスのダウンタイムが長い ◦ ドキュメント上だと 30s - 60s • 40 台以上あり一部機能毎に数台ずつ夜間やるのも困難(面倒) • メンテナンス毎に都度スケジュール調整 / 周知も大変 Deny maintenance period を指定し回避 02. サービスの成長と課題 メンテナンスのダウンタイム
22. Proprietary 022 Google Cloud Next Tokyo • Cloud SQL の Scale Up のダウンタイム ◦ primary の Scale Up でサービス影響が出る • replica を追加しても効果の薄い系統がある ◦ primary でのみ実行可能なクエリが多い系統には効果薄 02. サービスの成長と課題 大規模イベント前の対応
23. Proprietary 023 Google Cloud Next Tokyo • Cloud SQL の Scale Up のダウンタイム ◦ primary の Scale Up でサービス影響が出る • replica を追加しても効果の薄い系統がある ◦ primary でのみ実行可能なクエリが多い系統には効果薄 イベント前の作業がボトルネック 02. サービスの成長と課題 大規模イベント前の対応
24. Proprietary 024 Google Cloud Next Tokyo 1. アプリケーションの Latency 2. メンテナンスのダウンタイム 3. 大規模イベント前の対応 02. サービスの成長と課題
25. Proprietary 025 Google Cloud Next Tokyo 1. アプリケーションの Latency 2. メンテナンスのダウンタイム 3. 大規模イベント前の対応 02. サービスの成長と課題
26. Proprietary 026 Google Cloud Next Tokyo 1. アプリケーションの Latency 2. メンテナンスのダウンタイム 3. 大規模イベント前の対応 02. サービスの成長と課題 Cloud SQL Enterprise Plus
27. Proprietary 027 Google Cloud Next Tokyo • near-zero downtime(nZDT)によるサービス影響の軽減 ◦ メンテナンス ◦ Scale Up ◦ Scale Down(制限あり) • replica の追加ではなく Scale Up による負荷対策 ◦ 構築時間やストレージ費用の節約 • 現状の Cloud SQL と同じアーキテクチャ ◦ AlloyDB も選択肢にあったが後述の移行容易性により E+ を採用 02. サービスの成長と課題 Cloud SQL Enterprise Plus の導入目的
28. Proprietary 028 Google Cloud Next Tokyo • アップグレードはスケジュールを決めて深夜に一気に敢行 ◦ gcloud コマンドで全台一気に反映するスクリプト ◦ コマンド実行のみで事前の作業は特に不要 • DMS(Database Migration Service) は利用せず ◦ DMS を利用する場合アプリケーションの反映が必要 ◦ 系統も多く DMS による移行は工数的にも困難 02. サービスの成長と課題 Cloud SQL Enterprise Plus の導入作業
29. Proprietary 029 Google Cloud Next Tokyo • メンテナンス作業の対応が不要 ◦ リスケジュールや事前連絡, 適応など不要でスケジュールに従う • 大規模イベント前も負荷予測を基に Scale Up するのみ ◦ 再起動に関わるスケジュール調整は不要 ◦ replica 追加不要になり工数/ストレージコスト節約 • イベント終了後は Scale Down しコスト最適化 02. サービスの成長と課題 Cloud SQL Enterprise Plus の導入効果
30. Proprietary 030 Google Cloud Next Tokyo • メンテナンス作業の対応が不要 ◦ リスケジュールや事前連絡, 適応など不要でスケジュールに従う • 大規模イベント前も負荷予測を基に Scale Up するのみ ◦ 再起動に関わるスケジュール調整は不要 ◦ replica 追加不要になり工数/ストレージコスト節約 • イベント終了後は Scale Down しコスト最適化 02. サービスの成長と課題 Cloud SQL Enterprise Plus の導入効果 最小限の工数で最大限の効果
31. Proprietary 031 Google Cloud Next Tokyo Agenda 01. メルカリShops の歴史 02. サービスの成長と課題 Cloud SQL Enterprise Plus 03. 運用事例 Data cache Serverless VPC Access DB Consolidation 04. まとめ
32. 032 Google Cloud Next Tokyo 03. 運用事例
33. Proprietary 033 Google Cloud Next Tokyo 1. Data cache 2. Serverless VPC Access 3. DB Consolidation 03. 運用事例
34. Proprietary 034 Google Cloud Next Tokyo 1. Data cache 2. Serverless VPC Access 3. DB Consolidation 03. 運用事例
35. Proprietary 035 Google Cloud Next Tokyo • Cloud SQL Enterprise Plus で利用可能なキャッシュ機能 • 通常のメモリに加え local SSD もキャッシュストレージとして利用 • vCPU 数に応じて local SSD サイズは大きくなる ◦ 80 vCPU で 6000GB Data cache 03. 運用事例
36. Proprietary 036 Google Cloud Next Tokyo • メルカリShops の DB は系統によって傾向が異なる ◦ PK 一発なものから複雑なものまで多様 ◦ 共通点は read-heavy であること • 多くの系統でメモリをフルに利用していて余剰なし • Data cache で更にキャッシュ領域を拡張し Latency 改善を期待 Data cache 03. 運用事例
37. Proprietary 037 Google Cloud Next Tokyo Data cache 03. 運用事例 p95 Latency
38. Proprietary 038 Google Cloud Next Tokyo • Data cache を有効化した多くの workload で改善を確認 • メルカリShops は read-heavy ため効果は絶大 ◦ 特に index 1つで多量のレコードを取得するようなもの ▪ “いいね” した商品の情報など • 一部の巨大な DB においていくつかの問題が Data cache 03. 運用事例
39. Proprietary 039 Google Cloud Next Tokyo Data cache 03. 運用事例 p95 Latency
40. Proprietary 040 Google Cloud Next Tokyo • Data cache 有効後クエリの Latency 定期的な劣化を観測 ◦ それに伴い active(クエリ実行中)な接続が跳ねる • クエリや work_mem などをチューニングしていたが復旧せず • サポートケースで問い合わせしたところ内部的な問題と判明 ◦ Data cache のコンポーネントの一部の処理が Latency を引き起こす Data cache 03. 運用事例
41. Proprietary 041 Google Cloud Next Tokyo • Data cache を一時的に無効化し解消を確認 ◦ 当時は無効化に数分のダウンタイムが必要だった • この “内部的な問題” の修正がされたため再度 Data cache を有効化 • しばらく様子見をしていたがまた別の問題が発生 Data cache 03. 運用事例
42. Proprietary 042 Google Cloud Next Tokyo Data cache 03. 運用事例 p95 Latency[赤] と Data Cache usage[青]
43. Proprietary 043 Google Cloud Next Tokyo • Data cache の usage bytes が定期的にドロップ ◦ それに合わせてクエリの Latency が劣化 • サポートに問い合わせしたところ下記で起こり得る問題と発覚 ◦ Data cache サイズが巨大 ◦ クエリ数が多い • いくつかのアップデートにより現在は解消 Data cache 03. 運用事例
44. Proprietary 044 Google Cloud Next Tokyo • Data cache により Latency 改善に大きく寄与 • read-heavy なメルカリShops では特に効果が得られた • 内部的な問題など多少トラブルはあったが安定稼働中 Data cache 03. 運用事例
45. Proprietary 045 Google Cloud Next Tokyo 1. Data cache 2. Serverless VPC Access 3. DB Consolidation 03. 運用事例
46. Proprietary 046 Google Cloud Next Tokyo • Cloud Run と VPC 上のリソースへの疎通経路 ◦ Cloud SQL ◦ Memorystore • 歴史的経緯により Direct VPC egress ではなく Serverless を利用 Serverless VPC Access 03. 運用事例
47. Proprietary 047 Google Cloud Next Tokyo • 再起動を伴う Cloud SQL の flag 変更の際に接続の問題が発生 • Golang の connection pool は余裕があるにも関わらず 5xx を返し続ける ◦ 新リビジョンのリリースにより解消 • 様々な要因により問題が長期化 Serverless VPC Access 03. 運用事例
48. Proprietary 048 Google Cloud Next Tokyo Serverless VPC Access 03. 運用事例 Cloud SQL Serverless VPC Access Cloud Run Container Instance Container Instance Google Front End
49. Proprietary 049 Google Cloud Next Tokyo Serverless VPC Access 03. 運用事例 Cloud SQL Serverless VPC Access Cloud Run Container Instance Container Instance Google Front End インスタンス再起動
50. Proprietary 050 Google Cloud Next Tokyo Serverless VPC Access 03. 運用事例 Serverless VPC Access Cloud Run Container Instance Container Instance Google Front End connection pool の接続が 全て切断される Cloud SQL
51. Proprietary 051 Google Cloud Next Tokyo Serverless VPC Access 03. 運用事例 Serverless VPC Access Cloud Run Container Instance Container Instance Google Front End 再接続の試行を繰り返す Cloud SQL
52. Proprietary 052 Google Cloud Next Tokyo Serverless VPC Access 03. 運用事例 Serverless VPC Access Cloud Run Container Instance Container Instance Google Front End 過剰な接続要求を原因に port isolation が発生 全ての新規接続を拒否する Cloud SQL
53. Proprietary 053 Google Cloud Next Tokyo Serverless VPC Access 03. 運用事例 Cloud Run Container Instance Container Instance Google Front End connection pool が枯渇し リクエストが滞留する (利用可能な接続の開放を待つ) Serverless VPC Access Cloud SQL
54. Proprietary 054 Google Cloud Next Tokyo Serverless VPC Access 03. 運用事例 Cloud Run Container Instance Container Instance Google Front End MaxConcurrency に達して インスタンス にリクエストが到達しない (pending_queue の滞留) concurrency が上限に達する Serverless VPC Access Cloud SQL Container Instance Container Instance
55. Proprietary 055 Google Cloud Next Tokyo Serverless VPC Access 03. 運用事例 Cloud Run Container Instance Container Instance Google Front End Serverless VPC Access Cloud SQL DB が起動し接続が復旧 Container Instance Container Instance
56. Proprietary 056 Google Cloud Next Tokyo Serverless VPC Access 03. 運用事例 Serverless VPC Access Cloud Run Container Instance Container Instance Google Front End DB への接続が正常に戻るがこれまで に溜まったリクエストで埋まる port isolation 制限が解除される Cloud SQL Container Instance Container Instance
57. Proprietary 057 Google Cloud Next Tokyo Serverless VPC Access 03. 運用事例 Serverless VPC Access Cloud Run Container Instance Container Instance Google Front End 滞留したリクエストが GFE から インスタンスに到達する前にタイムアウト を迎える AutoScaling でインスタンスが上 限まで起動 Cloud SQL Container Instance Container Instance Container Instance Container Instance
58. Proprietary 058 Google Cloud Next Tokyo Serverless VPC Access 03. 運用事例 Serverless VPC Access Cloud Run Container Instance Container Instance Google Front End タイムアウトを迎えたリクエストを処理する のみでインスタンスの処理スロットが埋まる ほとんどのリクエストが 500 で返り DB へ の接続は余裕が生まれる 処理スロットが埋まりかつ起動数も上限となり リクエストが割り当てられず 429 となる Cloud SQL Container Instance Container Instance Container Instance Container Instance
59. Proprietary 059 Google Cloud Next Tokyo Serverless VPC Access 03. 運用事例 Serverless VPC Access Cloud Run Container Instance Container Instance Google Front End 新 revision をデプロイしたことで 正常に稼働するインスタンスが起動 新規インスタンスのリクエストは 200 既存のインスタンスは 500/429 となる (500 はキャンセル /429 はインスタンス数上限) Container Instance Cloud SQL Container Instance Container Instance Container Instance Container Instance
60. Proprietary 060 Google Cloud Next Tokyo Serverless VPC Access 03. 運用事例 Serverless VPC Access Cloud Run Container Instance Container Instance Google Front End 正常なインスタンスが 増える 滞留したリクエストが解消し pending_queue の値が復旧する Container Instance Container Instance 新規インスタンスにリクエストが流れ 既存インスタンスの処理スロットに 余裕がうまれ一部 200 を返す (timeout もありすべて 200 ではない） Cloud SQL Container Instance Container Instance Container Instance Container Instance Container Instance
61. Proprietary 061 Google Cloud Next Tokyo Serverless VPC Access 03. 運用事例 Serverless VPC Access Cloud Run Container Instance Container Instance Google Front End 新旧両方のインスタンスで正常化し デプロイの最中でも復旧する Container Instance Cloud SQL Container Instance Container Instance Container Instance Container Instance Container Instance Container Instance
62. Proprietary 062 Google Cloud Next Tokyo • connection pool には余裕があるにも関わらずエラーが継続した ◦ DB 再起動起因だが DB 側は正常に動作している • 新 revision のデプロイで旧 revision のインスタンスが完全に復旧しない ◦ 200 だけでなく 500 系も返していた • DB 再起動を起因として様々な箇所でリソース枯渇が発生していた Serverless VPC Access 03. 運用事例
63. Proprietary 063 Google Cloud Next Tokyo • リクエストが滞留しないようにボトルネックになる箇所で timeout を指定 ◦ DB への接続など • 最大インスタンス数を調整し十分余裕を持っておく • 異常時には新 Revision をリリースして新規接続を流せるようにする Serverless VPC Access 03. 運用事例
64. Proprietary 064 Google Cloud Next Tokyo 1. Data cache 2. Serverless VPC Access 3. DB Consolidation 03. 運用事例
65. Proprietary 065 Google Cloud Next Tokyo • PITR 有効時の WAL により拡張されたストレージ ◦ 現在は GCS にログがアップロードされる ◦ 当時の local disk に保存する仕組みのまま運用していたため問題が発生 ▪ (当時は PITR の変更も再起動が必要だったためそのままだった) • microservice 構成により Tier の小さいインスタンス群のコスト DB Consolidation 03. 運用事例
66. Proprietary 066 Google Cloud Next Tokyo DB Consolidation 03. 運用事例
67. Proprietary 067 Google Cloud Next Tokyo • PITR 有効時の WAL により拡張されたストレージ ◦ 現在は GCS にログがアップロードされる ◦ 当時の local disk に保存する仕組みのまま運用していたため問題が発生 ▪ (当時は PITR の変更も再起動が必要だったためそのままだった) • microservice 構成により Tier の小さいインスタンス群のコスト DB Consolidation 03. 運用事例 統合によりコスト最適化
68. Proprietary 068 Google Cloud Next Tokyo DB Consolidation 03. 運用事例 https://engineering.mercari.com/blog/entry/20250220-8685a1def6/
69. Proprietary 069 Google Cloud Next Tokyo DMS • managed なデータベース 移行サービス • データベースの統合は未対 応 export/import • 最もシンプルな手順 • 停止時間が長時間 ◦ 特に更新系 Logical Replication • いくつか制限がある ◦ Cloud SQL 固有 ◦ PostgreSQL 固有 • Cloud SQL で同期レプリ ケーションは非対応 • 手作業が多く面倒 DB Consolidation 03. 運用事例
70. Proprietary 070 Google Cloud Next Tokyo DMS • managed なデータベース 移行サービス • データベースの統合は未対 応 export/import • 最もシンプルな手順 • 停止時間が長時間 ◦ 特に更新系 Logical Replication • いくつか制限がある ◦ Cloud SQL 固有 ◦ PostgreSQL 固有 • Cloud SQL で同期レプリ ケーションは非対応 • 手作業が多く面倒 DB Consolidation 03. 運用事例
71. Proprietary 071 Google Cloud Next Tokyo • Cloud SQL の制限 ◦ 同期レプリケーションは非対応 ◦ ConnectorEnforcement の場合非対応 ▪ instance 同士を直接接続させるため • PostgreSQL の制限 ◦ replication されないもの(一部抜粋) ▪ DDL ▪ Sequential data ▪ View, Materialized View DB Consolidation - Logical Replication 03. 運用事例
72. Proprietary 072 Google Cloud Next Tokyo • Cloud SQL の制限 ◦ 同期レプリケーションは非対応 ◦ ConnectorEnforcement の場合非対応 ▪ instance 同士を直接接続させるため • PostgreSQL の制限 ◦ replication されないもの(一部抜粋) ▪ DDL ▪ Sequential data ▪ View, Materialized View DB Consolidation - Logical Replication 03. 運用事例 利用していないため 問題なし
73. Proprietary 073 Google Cloud Next Tokyo • Cloud SQL の制限 ◦ 同期レプリケーションは非対応 ◦ ConnectorEnforcement の場合非対応 ▪ instance 同士を直接接続させるため • PostgreSQL の制限 ◦ replication されないもの(一部抜粋) ▪ DDL ▪ Sequential data ▪ View, Materialized View DB Consolidation - Logical Replication 03. 運用事例 手順でカバーするため 問題なし
74. Proprietary 074 Google Cloud Next Tokyo • Cloud SQL で cloudsql.logical_decoding を有効化 ◦ 再起動のダウンタイムは 30s - 60s • アプリケーションの接続を DNS base に変更可能にしておく ◦ メルカリShops は IP ベースで直接接続のため ▪ postgres://src:xxxxxx@10.0.0.1:5432/src ▪ postgres://src:xxxxxx@foo.local:5432/src DB Consolidation - Logical Replication[事前準備] 03. 運用事例
75. Proprietary 075 Google Cloud Next Tokyo 1. pg_dump --schema-only で Schema のみ複製 2. Logical Replication を開始 a. DDL が実行されないように migration の workflow を制御 3. アプリケーションを DNS base の接続に変更 DB Consolidation - Logical Replication[同期] 03. 運用事例
76. Proprietary 076 Google Cloud Next Tokyo 1. 更新をブロック a. ALTER DATABASE … SET default_transaction_read_only TO on; 2. 既存の接続を全て KILL a. Sequence の場合はここで番号をあわせる 3. DNS を統合先の IP に変更 a. DNS 伝播後統合元の接続があれば再度 KILL DB Consolidation - Logical Replication[切り替え] 03. 運用事例
77. Proprietary 077 Google Cloud Next Tokyo • 更新のみをブロックする方法 ◦ 更新ユーザーの rename ▪ 更新ユーザーと読込ユーザーが同じなため不可 ◦ GRANT 文の変更 ◦ ALTER DATABASE ▪ 明示的な SET を利用していないため可 • 簡単な ALTER DATABASE を採用 DB Consolidation - Logical Replication[切り替え] 03. 運用事例
78. Proprietary 078 Google Cloud Next Tokyo • 更新ブロックによるダウンタイムは長くても 1, 2min ◦ readonly の後 DNS の変更が伝播するまで(=TTL)が実質のブロック時間 • read-heavy なため大多数のリクエストに影響はなし ◦ エラーは出るがリトライで救われる • コストを 25% 以上削減 ◦ 余剰ストレージの削除 ◦ Compute リソース最適化 DB Consolidation - Logical Replication[切り替え] 03. 運用事例
79. Proprietary 079 Google Cloud Next Tokyo 01. メルカリShops の歴史 02. サービスの成長と課題 Cloud SQL Enterprise Plus 03. 運用事例 Data cache Serverless VPC Access DB Consolidation 04. まとめ Agenda
80. Proprietary 080 Google Cloud Next Tokyo 04. まとめ
81. Proprietary 081 Google Cloud Next Tokyo • 利用シーンの拡大 ◦ 大規模キャンペーンなどの実施 • メルカリのトップページからの誘導 ◦ 影響がメルカリ本体にも波及 • リリース当初と比べてよりに品質が求められる 02. サービスの成長と課題
82. Proprietary 082 Google Cloud Next Tokyo • 利用シーンの拡大 ◦ 大規模キャンペーンなどの実施 • メルカリのトップページからの誘導 ◦ 影響がメルカリ本体にも波及 • これまで以上に品質が求められる 02. サービスの成長と課題 特に Cloud SQL 周りの課題
83. Proprietary 083 Google Cloud Next Tokyo 1. アプリケーションの Latency 2. メンテナンスのダウンタイム 3. 大規模イベント前の対応 02. サービスの成長と課題
84. Proprietary 084 Google Cloud Next Tokyo 1. アプリケーションの Latency 2. メンテナンスのダウンタイム 3. 大規模イベント前の対応 02. サービスの成長と課題 Cloud SQL Enterprise Plus
85. Proprietary 085 Google Cloud Next Tokyo • メンテナンス作業の対応が不要 ◦ リスケジュールや事前連絡, 適応など不要でスケジュールに従う • 大規模イベント前も負荷予測を基に Scale Up するのみ ◦ 再起動に関わるスケジュール調整は不要 ◦ replica 追加不要になり工数/ストレージコスト節約 • イベント終了後は Scale Down しコスト最適化 02. サービスの成長と課題 Cloud SQL Enterprise Plus の導入効果
86. Proprietary 086 Google Cloud Next Tokyo • メンテナンス作業の対応が不要 ◦ リスケジュールや事前連絡, 適応など不要でスケジュールに従う • 大規模イベント前も負荷予測を基に Scale Up するのみ ◦ 再起動に関わるスケジュール調整は不要 ◦ replica 追加不要になり工数/ストレージコスト節約 ◦ replica のストレージコストも削減 • イベント終了後は Scale Down しコスト最適化 02. サービスの成長と課題 Cloud SQL Enterprise Plus の導入効果 最小限の工数で最大限の効果
87. Proprietary 087 Google Cloud Next Tokyo 1. Data cache 2. Serverless VPC Access 3. DB Consolidation 03. 運用事例
88. Proprietary 088 Google Cloud Next Tokyo • メルカリShops の DB は系統によって傾向が異なる ◦ PK 一発なものから複雑なものまで多様 ◦ 共通点は read-heavy であること • 多くの系統でメモリをフルに利用していて余剰なし • Data cache で更にキャッシュ領域を拡張し Latency 改善を期待 Data cache 03. 運用事例
89. Proprietary 089 Google Cloud Next Tokyo Data cache 03. 運用事例 p95 Latency
90. Proprietary 090 Google Cloud Next Tokyo • PITR 有効時の WAL により拡張されたストレージ ◦ 現在は GCS にログがアップロードされる ◦ 当時の local disk に保存する仕組みのまま運用していたため問題が発生 ▪ (当時は PITR の変更も再起動が必要だったためそのままだった) • microservice 構成により Tier の小さいインスタンス群のコスト DB Consolidation 03. 運用事例
91. Proprietary 091 Google Cloud Next Tokyo • PITR 有効時の WAL により拡張されたストレージ ◦ 現在は GCS にログがアップロードされる ◦ 当時の local disk に保存する仕組みのまま運用していたため問題が発生 ▪ (当時は PITR の変更も再起動が必要だったためそのままだった) • microservice 構成により Tier の小さいインスタンス群のコスト DB Consolidation 03. 運用事例 統合によりコスト最適化
92. Proprietary 092 Google Cloud Next Tokyo • C4A instance @ tokyo ◦ より高いコスト最適化への期待 • Read pool ◦ read replica の追加/削除時の作業を削減 • Backup の統制と不正防止 ◦ BCP/DR など長期保存目的 ◦ 改ざんできないようなガードレールを中央管理 今後導入したい機能 /解決したい課題 04. まとめ
93. Proprietary 093 Google Cloud Next Tokyo • C4A instance @ tokyo ◦ より高いコスト最適化への期待 • Read pool ◦ read replica の追加/削除時の作業を削減 • Backup の統制と不正防止 ◦ BCP/DR など長期保存目的 ◦ 改ざんできないようなガードレールを中央管理 今後導入したい機能 /解決したい課題 04. まとめ Cloud SQL E+の機能拡張に期待
94. Proprietary 094 Google Cloud Next Tokyo We’re hiring! https://careers.mercari.com/