ZOZOTOWNのMA基盤刷新 BigQueryとAlloyDBを中心としたイベント駆動設計

2026/07/30-31 開催の「Google Cloud Next Tokyo」で発表した登壇資料です。

> ZOZOTOWN では 1200 万会員の行動ログと 100 万点規模の商品データを活用し、様々なマーケティング施策でユーザーにマルチチャネル配信を行っています。大規模セール時に配信が集中することで、最大 6 時間の配信遅延や情報鮮度が課題となっていました。本セッションでは BigQuery と AlloyDB を中心に Pub/Sub・Cloud Run によるイベント駆動設計を取り入れ、遅延 80 % 削減とコスト最適化を達成した刷新事例を紹介します。

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

株式会社ZOZO
データ・AIシステム本部
MA部 MA基盤開発ブロック
ブロック長 平宮 瑛宜

株式会社ZOZO
データ・AIシステム本部
MA部 MAシステム開発ブロック
ブロック長 平井 蒼大

#GoogleCloudNext

Transcript

1. ZOZOTOWN MA 基盤刷 新 BigQuery と AlloyDB を 中心としたイベント駆動設計 Proprietary
2. 平宮 瑛宜 平井 蒼大 株式会社ZOZO 株式会社ZOZO データ・AIシステム本部MA部 データ・AIシステム本部MA部 MA基盤開発 ブロック長 MAシステム開発 ブロック長 Google Cloud Next Tokyo Proprietary
3. アジェンダ Google Cloud Next Tokyo 01 02 03 04 ZOZOTOWN と MA MA 基盤刷新 BigQuery と AlloyDB 成果と今後 Proprietary
4. 01. ZOZOTOWN と MA Google Cloud Next Tokyo Proprietary
5. ZOZOTOWN ファッション EC「ZOZOTOWN」 圧倒的なラインナップ 豊富な商品数 1,700 以上 ショップ 11,000 以上 ブランド 常時 138 万点以上 毎日平均 3,100 点以上 年間購入者数 充実 サービス 1,317 万人 即日配送 ギフト対応 ツケ払い ※ データ Google Cloud Next Tokyo 2026 年 3 月末時点 新着 も です Proprietary
6. ZOZOTOWN における MA 大きな役割   マス配信 1 to 1 配信 施策ごと セグメントに応じて配信内容を生成し、定期・ 不定期に配信 リアルタイムなイベントをもとに、ユーザーごとに最適な提 案を行う配信 ✓ 新着アイテムやセール情報などを大量配信 ✓ チャネル（メール、LINE、PUSH）・時間帯・内容をユー ザーごとに最適化 ✓ ユーザー データをもとに掲載内容を出し分け Google Cloud Next Tokyo ✓ 行動ログ・商品状態・在庫変動など、鮮度 タを活用 高いデー Proprietary
7. 02. MA 基盤刷新 Google Cloud Next Tokyo Proprietary
8. 旧アーキテクチャ Google Cloud Next Tokyo Proprietary
9. 旧アーキテクチャで顕在化していた課題 Google Cloud Next Tokyo Proprietary
10. リプレイスで解くべき課題 データ鮮度 低下 ETL に 20 時間以上かかり、直近 ユーザー行動を施策へ反映しづ  データマート作成・リバース らかった。 処理スケール 限界 制約により処理量 増加に追従しづらく、大規模セール時に  アプリケーションやミドルウェア 大 6 時間 配信遅延 が発生していた。 保守・拡張 最 難しさ 責務を持つ巨大なアプリケーション ため、障害復旧に 1 〜 2 日かかるケースが発生してい  多く た。 Google Cloud Next Tokyo Proprietary
11. 課題解決に向けた設計方針 非同期・水平スケール前提 アプリケーション設計  Pub/Sub, Cloud Run により処理を疎結合化し、 スパイク に追従しやすい構成へ BigQuery / AlloyDB を中心としたデータ活用 BigQuery、リアルタイムな参照・更新 AlloyDB が担う構成  大規模な分析・集計・コンテンツ生成 へ マネージド サービス活用による運用負荷  ミドルウェア管理を減らし、 保守・拡張 しやすい構成へ Google Cloud Next Tokyo 削減 Proprietary
12. 新アーキテクチャ Google Cloud Next Tokyo Proprietary
13. 03. BigQuery と AlloyDB Google Cloud Next Tokyo Proprietary
14. BigQuery ZOZOTOWN 選定理由 共通データ基盤 大規模データに対する複雑なクエリを高速で実行可能 Google Cloud サービスと 親和性 federated query Pub/Sub BigQuery Subscription Google Cloud Next Tokyo Proprietary
15. AlloyDB HTAP 選定理由 実現 読み取りプール インスタンス 柔軟性 フルマネージド サービスによる運用負荷 Google Cloud Next Tokyo 軽減 Proprietary
16. AlloyDB HTAP 選定理由 実現 API リクエスト テーブル規模 データ処理ピーク 最大 6,000 req/sec 数千万 〜 4 億 件 約 40 万 行/秒 差分検知・行動ログから リクエストを高速に処理 マート参照・最適化条件で 利用する大規模テーブル 書き込み処理 ピーク時において も高いスループットを維持 リアルタイム更新と複雑な参照処理を、単一 Google Cloud Next Tokyo AlloyDB 上で実行 Proprietary
17. AlloyDB 選定理由 読み取りプール インスタンス 柔軟性 用途ごとに読み取り負荷を分離し、ピーク時だけ高性能な構成へ 実際 ワークロードに応じた構成 読み取りプール 主な用途 負荷特性 運用方針 BigQuery 連携用 Federated Query から 参照 低 常時起動 汎用的な読み取り用 通常 参照クエリ 中 常時起動 最適化処理 大規模な最適化クエリ 高 ピーク時間 Google Cloud Next Tokyo 読み取り用 み起動 Proprietary
18. AlloyDB 選定理由 フルマネージド サービスによる運用負荷 軽減 システム モニタリング クエリ インサイト 標準機能で パフォーマンス最適化 容易化 可視化と健全性維持 ✓ CPU / メモリ / 接続数などを標準で可視化 ✓ 実行クエリ ✓ 負荷試験・結合試験でボトルネックを確認 ✓ 実行計画からボトルネックを特定 ✓ 本番運用後 ✓ インデックス改善 ✓ Cloud Trace 連携で処理全体を追跡 Google Cloud Next Tokyo 健全性確認にも活用 傾向を可視化 検討に活用 Proprietary
19. 04. 成果と今後 Google Cloud Next Tokyo Proprietary
20. 課題だったこと データ鮮度 低下 ETL に 20 時間以上かかり、直近 ユーザー行動を施策へ反映しづ  データマート作成・リバース らかった。 処理スケール 限界 制約により処理量 増加に追従しづらく、大規模セール時に  アプリケーションやミドルウェア 大 6 時間 配信遅延 が発生していた。 保守・拡張 最 難しさ 責務を持つ巨大なアプリケーション ため、障害復旧に 1 〜 2 日かかるケースが発生してい  多く た。 Google Cloud Next Tokyo Proprietary
21. 課題解決 : データ鮮度 低下 BigQuery から AlloyDB へ、用途に応じてデータ連携 ✓ 大規模な差分検知・集計処理 BigQuery で実 行 ✓ 集計結果 Cloud Storage 経由で AlloyDB に インポート ✓ リバース ETL Google Cloud Next Tokyo 経路を AlloyDB へ一本化 Proprietary
22. 課題解決 : 処理スケール アプリケーション 水平スケール、データベース Cloud Run ✓ イベント単位に処理を分割 ✓ アプリケーションを水平スケール Google Cloud Next Tokyo 限界 ワークロードに応じて分離 AlloyDB ✓ リアルタイム更新と複雑な参照を 両立 ✓ 読み取りプールで高負荷な処理 を分離 BigQuery ✓ 大規模なコンテンツ生成処理を実 行 ✓ 大量データ処理をアプリケーショ ンから分離 Proprietary
23. 課題解決 : 保守・拡張 難しさ キャッシュ依存から、 SQL で拡張できる構成へ KVS (memory) BigQuery AlloyDB ✓ BigQuery / AlloyDB により、配信条件や抽出ロ ✓ Google Cloud マネージド サービスにより、監視 ジックを SQL で表現 Google Cloud Next Tokyo ・リリース・インフラ運用を統一 Proprietary
24. 改善効果 配信時間 データマート作成時間 最大 6 時間 -> 1 時間以内 20 時間以上 -> 4 時間 インフラコスト 運用コスト 40% 削減 80% 削減 Google Cloud Next Tokyo Proprietary
25. 今後 展望 BigQuery / AlloyDB 更なる活用 Managed Service for Apache Airflow ベクトル検索機能 (AlloyDB ) フルマネージド Lakehouse Federation (AlloyDB x BigQuery) リプレイスによる更なる保守性 向上 ワークフロー エンジン Continuous Queries (BigQuery) Google Cloud Next Tokyo Proprietary
26. Thank you Proprietary