ZOZOTOWNの進化と信頼性を両立する負荷試験

2026/07/11 に「SRE NEXT 2026 Lightning Talk」で発表した登壇資料です。

> ZOZOTOWNの会員ID基盤では、年十数回の負荷試験を実施しています。
> 新機能の追加やリプレイスなどプロダクトの進化が続く中で、信頼性をどう担保し続けるか — その要が負荷試験運用です。
> しかし実施要否の検討・シナリオ作成・mock準備・想定RPSの見積もりなど、試験前に積み重なる判断と調整が、見えないコミュニケーションコストを生み、運用を試験を回すだけで精一杯の状態にしていました。
> 本LTでは、要否判定の属人化解消・シナリオ資産の使い回し・分析工程の仕組み化、結果のテンプレート化など、現場で有効だった運用改善と、これから取り組みたい効率化の方向性を共有します。同じ負荷試験運用に悩む方々、これから基盤を整えていきたい方々の参考になれば幸いです。

https://sre-next.dev/2026/schedule/#slot098

株式会社ZOZO
EC基盤開発本部 SRE部 会員ID基盤SREブロック
松石 侑樹 (@kitsune_yk)

#srenext

Transcript

1. ZOZOTOWNの進化と信頼性を 両立する負荷試験 年十数回、現場の課題と効率化 株式会社ZOZO EC基盤開発本部 SRE部 会員ID基盤SREブロック 松石 侑樹 Copyright © ZOZO, Inc. 1
2. © ZOZO, Inc. 株式会社ZOZO EC基盤開発本部 プラットフォームSRE部会員ID基盤SREブロック 松石 侑樹 ZOZOTOWNの認証認可基盤を運用しています。 • 趣味: フットサル・旅行・料理 • 好きな技術: DevOps, Observability, Datadog • X: @kitsune_yk 2
3. © ZOZO, Inc. 3 概要 — ZOZOTOWNのマイクロサービス負荷試験とは • 対象: 6つのマイクロサービス ◦ もちろん、他ドメイン（カートや検索）のSREも × マイクロサービス分実施 • 準備含め3週間程度 × 年十数回のペース（弊チームの場合） • 見逃すとログイン・購入障害に直結 要件すり合わせ 事前準備 試験実施 試験完了後の確認
4. © ZOZO, Inc. 4 今日話すこと • 本来SREとして力を入れたいのは、サービス信頼性や開発効率化、DevOps、 オブザーバビリティの改善 etc • そのための時間を作るため、負荷試験の工数削減に取り組んできた • 負荷試験基盤の改修ではなく、既存の仕組みをどう整えてきたか
5. © ZOZO, Inc. 5 つらみな背景 — 判断の積み重ねで手一杯だった時期 • 事前準備だけでも大変 • それぞれの項目の判断のたびに議論、試験を回すだけで手一杯 2025年:手順の多さ・考慮ポイントの多さに限界を迎え始めた自分
6. © ZOZO, Inc. 6 負荷試験では考えることがいっぱい！！ • 実際のガイドラインより抜粋（事前準備フェーズの一部だけでこの量）
7. © ZOZO, Inc. 7 解決した課題① — シナリオの標準化 • 本番の実測RPSを基準に、ベースとなる負荷試験シナリオを作成 ◦ 他サービスにも展開中 • シナリオ作成のたびの議論がなくなった
8. © ZOZO, Inc. 8 解決した課題② — 外部依存の切り離し（チームの取り組み） • 外部サービス依存で試験が止まる問題を、ルーティングの工夫で解消 Before 各Deploymentの環境変数を 直接Mockに向ける STG環境全体に影響 （他チームの開発やQAをブロック） After Istio VirtualServiceで負荷試験 基盤からのリクエストだけを転送 Mockだけに影響 STG環境の他は無傷
9. © ZOZO, Inc. 9 解決した課題③ — Mock運用への個人の貢献 • Mock環境の作成・削除のラッパーツール作成 • モックリソース・負荷試験リクエストの監視用のDatadog dashboardを作成 • OSSのprism-in-k8sにコントリビュート
10. © ZOZO, Inc. 10 解決した課題④ — 属人化を防ぐガイドライン整備 • 試験手順をガイドラインとして整備（日々ブラッシュアップ中） • 新メンバーも迷わず試験を進められる
11. © ZOZO, Inc. 11 これからの改善や理想像 • リクエスト数ベースの試験要否基準づくりはまだ道半ば • 負荷試験自体のGitHub Actions自動化・ChatOps化を構想中 • 工数削減の数字は、これから
12. © ZOZO, Inc. まとめ 最小の工数で、最大の価値を！ 判断基準を言語化・数値化すると再現性が生まれます。 浮いた時間は、サービス信頼性やDevOps・オブザーバビリティの改善に使いたい！ ※同じ悩みを持つ方、ぜひ懇親会・ブースでお話ししましょう！ 12