ZOZOTOWNリプレイスで得た パフォーマンス改善の知見と、 チームで継続するための取り組み 株式会社ZOZO
 EC基盤開発本部 SRE部 フロントSREブロック
 秋田 海人 Copyright © ZOZO, Inc. 1 

© ZOZO, Inc. 株式会社ZOZO EC基盤開発本部 SRE部 フロントSREブロック 秋田 海人 ニックネーム：あきちゃん 2020年新卒入社 沖縄在住 ZOZOTOWNフロントエンドリプレイスプロジェクトの SRE内の取りまとめとオンプレWEBサーバ縮退の計画と 実施を主に担当しています。 2 

© ZOZO, Inc. https://zozo.jp/ 3 ● ファッションEC ● 1,600以上のショップ、9,000以上のブランドの取り扱い ● 常時107万点以上の商品アイテム数と毎日平均2,700点以上の新着 商品を掲載（2025年6月末時点） ● ブランド古着のファッションゾーン「ZOZOUSED」や コスメ専門モール「ZOZOCOSME」、シューズ専門ゾーン 「ZOZOSHOES」、ラグジュアリー＆デザイナーズゾーン 「ZOZOVILLA」を展開 ● 即日配送サービス ● ギフトラッピングサービス ● ツケ払い など 

© ZOZO, Inc. 4 目次 ● ZOZOTOWNリプレイスプロジェクトについて ● パフォーマンスを改善（安定化）する取り組み ● 今後チームでパフォーマンス改善を継続する取り組み ● まとめ 

© ZOZO, Inc. ZOZOTOWNリプレイスプロジェクトについて 

© ZOZO, Inc. 6 リプレイスの目的 柔軟なシステム 開発生産性 技術のモダン化 採用強化 ・セールなどの高負荷時に スケール可能 ・レガシー技術による独自 実装の減少 ・汎用ミドルウェア、 SaaS を利用可能 ・並行開発 ・リリースの自動化 ・技術情報のアウトプット によるプレゼンス向上 お客様にいつでも快適にお買い物していただけるサービスを提供し、ZOZOTOWN を成長させるために システム観点での継続的に成長させるための4つのポイント ※ZOZOTOWNのアーキテクチャ変遷と意思決定の歴史を ADRから振り返る - アーキテクチャ Conference2024 

© ZOZO, Inc. 7 クラウド化 スケーラビリティ(拡張性)を手に入れる ※ZOZOTOWNのアーキテクチャ変遷と意思決定の歴史を ADRから振り返る - アーキテクチャ Conference2024 柔軟なシステム ● 新春セールは通常時の3倍(※当時)のリクエストが来る ● 今まではデータセンターに元日のためだけに3倍のハードウェアを購入しておくことはできず、毎 年エラーが出ていた ● クラウドであれば、元日だけ3倍に増強するなど柔軟な構成変更が可能 Amazon EC2 データセンター：3~5年減価償却でハードウェアを購入 クラウド：必要な時に必要な台数を増強(秒単位課金) 

© ZOZO, Inc. 開発生産性 8 マイクロサービス化 並列開発が行えるように ※ZOZOTOWNのアーキテクチャ変遷と意思決定の歴史を ADRから振り返る - アーキテクチャ Conference2024 ● 今までは、巨大は一枚岩(モノリス)なアプリケーションを複数チームで編集 ○ リリース待ちが発生し、案件を並列でこなす弊害になっていた ● 組織とアプリケーションを検索・商品情報・推薦・カートのような単位で分割 ○ マイクロサービス(ブロック)毎に並行開発・リリースが行えるように ZOZOTOWNサーバー 検索ブロック 推薦ブロック カートブロック 作業が 衝突 検索API 推薦API カートAPI 検索ブロック 推薦ブロック カートブロック 独立し て作業 

© ZOZO, Inc. 技術のモダン化 9 脱VBScript ZOZOTOWNはVBScriptというプログラミング言語を利用して作られた 事業継続できなくなるリスクヘッジ 「VBScript」は非推奨に、将来のWindowsリリースで削除 長期 短期 VBScriptはWindows用のスリプト言語、当初はJavaScriptの対抗馬として作られ、習熟の容易さからサーバ言語として成功を収めた モダンなミドルウェアやSaaSが利用できる マイクロサービス化の家庭で、開発言語も置き換えて、モダン化(VBScript -> Java,Go,Nodejs) → クラウドベンダーが提供しているライブラリをそのまま使える開発環境に VBScript 例) Amazon DynamoDB ❌ ❌ Java-Go 例) Amazon DynamoDB ⭕ ※ZOZOTOWNのアーキテクチャ変遷と意思決定の歴史を ADRから振り返る - アーキテクチャConference2024 ⭕ 

© ZOZO, Inc. 10 リプレイスプロジェクトの開発方針 事業を止めずにサイト無停止でユーザー影響がでないようにリプレイスする ● 既存の仕様を踏襲する ○ ただし、一部は画面仕様から考え直すことも可能 ● 現在の使われていないコードを捨てる ● SQL Serverのリプレイスを一部保留する ● リリース前には、負荷試験を実施しボトルネックを事前に把握、改善する 

© ZOZO, Inc. 11 システム移行のアプローチ ストラングラーパターン →段階的にレガシーからモダンなシステムへ移行する方法 ● ファサードとなるAkamaiの背後にレガシーシステム（VBScriptで動くアプリケーション）を配置 ● Akamaiの裏で、徐々にモダンなシステムに振り分けていく 移行前 移行中 移行中 移行後 ファサード レガシー ファサード レガシー モダン ファサード レガシー モダン ファサード モダン ※ZOZOTOWNのアーキテクチャ変遷と意思決定の歴史を ADRから振り返る - アーキテクチャ Conference2024 

© ZOZO, Inc. 12 フロントエンドリプレイスプロジェクトとは？ 目的 ● フロントエンド技術のモダン化とシンプル化による実装コスト削減、開発者体 験向上、採用強化 大目的 小目的 (併せて可能な限り以下を実施する） ● UXの向上、高速化 ● システムの柔軟性向上、トレーサビリティ向上 ZOZOTOWNにおけるフロントエンドをTypeScript、React、Next.jsを用いて リプレイスするプロジェクトです。 

© ZOZO, Inc. 13 フロントエンドリプレイスプロジェクト技術要素 リプレイス前(2017年) ● VBScript(Classic ASP) ● 独自フレームワーク ● SQL Server リプレイス後(2025年) ● CDN(Akamai) ● Node.js(Next.js) ○ SSR/CSRを利用 ● BFF(Backend for Frontend) ○ Java ● Gateway(Go) ○ Web Gateway ○ API Gateway ● VBScript(Classic ASP) ● 独自フレームワーク ● SQL Server 

© ZOZO, Inc. アーキテクチャ(WEB) リプレイス前(2017年) zozo.jp Data Center Load Balancer IIS(VBScript) SQL Server群 14 

© ZOZO, Inc. アーキテクチャ(WEB) リプレイス後(2025年) Akamai Node.js Web Gateway Data Center Load Balancer IIS(VBScript) SQL Server群 API Gateway Search API ID API BFF Front API Redis Session Proxy ALB PCSP API ALB EKS AWS Direct Connect S3 zozo.jp Home 検索 会員 カート /apis/* それ以外 assets.imgz.jp Member API 15 Cart API Session API 

© ZOZO, Inc. Webのレンダリングについて 16 CSR 

© ZOZO, Inc. パフォーマンスを改善（安定化）する取り組み 

© ZOZO, Inc. 18 リプレイスプロジェクトの開発方針 事業を止めずにサイト無停止でユーザー影響がでないようにリプレイスする ● 既存の仕様を踏襲する ○ 正し、一部は画面仕様から考え直すことも可能 ● 現在の使われていないコードを捨てる ● SQL Serverのリプレイスを一部保留する ● リリース前には、負荷試験を実施しボトルネックを事前に把握、改善する 

© ZOZO, Inc. 19 負荷試験について 試験観点 ※Gatlingによる分散負荷試験を自動化するKubernetesオペレーターGatling Operatorの紹介 試験環境 ● 弊社で開発したGatling OperatorといったOSSツールを利用 ● GatlingはWebアプリケーション向けのOSS負荷試験フレームワーク ● Gatling OperatorはGatlingをベースとした分散負荷試験のライフサイクルを自動化する Kubernetes Operator ● レイテンシが目標値を超えていないか ● 1podに対して負荷試験を実施し、負荷試験の結果からリリース時に必要なリソースが見 積もれている ○ 線形スケールするか（2podにした時に1podの時の2倍のリクエストを捌けるか） ● ボトルネックが把握、改善できている 

© ZOZO, Inc. 20 負荷試験について リクエスト数算出 目標値の決定 ● 目標リクエスト数を抽出する日を決める ○ セールイベントがない土日平日 ○ 直近の高予算日かつアクセスが多い日 ● レイテンシは既存のSLOと既存IISのサーバーのアクセスログから目標値を決定 ○ 95パーセンタイルのレイテンシー ● ログ解析基盤としてSplunkを導入しているので、Splunkで既存IISのサーバーのアクセス ログからリクエスト数を算出 ○ 秒間リクエスト数を見積もる 

© ZOZO, Inc. 21 負荷試験について シナリオ作成 ● リプレイス対象エンドポイントのすり合わせ ○ バックエンドチームとフロントエンドチームに確認 ● シナリオの内容に関して詳細をすり合わせる ○ リアルなユーザートラフィックになるべく近づける ■ パラメーターのパターンを網羅 ■ ログイン済みでシナリオを実施するなど ○ リアルなユーザートラフィックを再現できない場合は要相談の上試験を実施 ● ブラウザで挙動確認をしながらシナリオ作成 

© ZOZO, Inc. 22 検索結果画面の場合 対象画面例 

© ZOZO, Inc. 23 検索結果画面の場合 性能試験 試験観点 設計したアーキテクチャでレイテンシやファーストビューのUXなどのパフォーマンスを劣化 を起こさずにリプレイスできるか。手戻りを減らすして工数見積もりを正確に算出する。ボト ルネックをこの時点で潰しておく。PoC的な意味合い。 目的 ● 1Podあたりが捌けるreq/sec ○ 各Backendの負荷状況 ○ レイテンシが目標値を満たせるか ○ ボトルネックの有無 ● 線形スケールするか確認 ○ 2podスケールできるか（1podで捌けた2倍のリクエストが捌けるか） 

© ZOZO, Inc. 24 検索結果画面の場合 負荷試験 試験観点 リリースする予定のコンテナイメージで実施する。リアルユーザーのトラフィックに近いシナ リオを作成し、アプリケーションに負荷をかけボトルネックを見つけ、リリース時に必要な Podの台数などのリソースを正確に見積もる。 目的 ● 1Podあたりが捌けるreq/sec ○ 各Backendの負荷状況 ○ レイテンシが目標値を満たせるか ○ ボトルネックの有無 ● BFFリソース、マイクロサービスの増設必要性の有無 ● 線形スケールするか確認 ○ 2podスケールできるか（想定どおりのリクエスト受け取れるか） 

© ZOZO, Inc. 25 検索結果画面の場合 性能試験(対象アプリケーション) 負荷試験(対象アプリケーション) ● Node.js(Next.js) ● BFF ● Gateway ○ Web Gateway ○ Api Gateway ● 関連マイクロサービス ○ search-api ○ front-api ● 関連オンプレWebサーバー ○ SessionProxy ○ PCSP-API ● Node.js(Next.js) 

© ZOZO, Inc. ● レイテンシ ○ 検索結果画面のSLOを比較し約900ms以内とした ■ やってみないとわからないのでSLOよりも低く値を定義 ● リクエスト数 ○ 1podあたりどれくらいのreq/secが捌けるか ○ 1podあたりどれくらい捌けるかわかるとセール時のリクエスト数が分かればどれ くらいのPodが必要か見積もることが可能 26 検索結果画面の場合(性能試験) 目標値 

© ZOZO, Inc. 27 検索結果画面の場合(性能試験) シナリオ ● SSRのページは4種類(リクエストしているAPIなどはモックを利用) ○ ショップ検索、ブランド検索、カテゴリ検索、フリーワード検索 ● SSRの描画領域を制御したクエリパラメータの利用 ○ SSRする量を制御 ● 当初は予定がなかった ○ Node.jsのマルチプロセス化(m5.4xlarge) ■ マルチプロセス化前はm5.xlargeを使用 ○ インスタンスタイプの変更(m5.4xlarge -> m6a.4xlarge, m6i.4xlarge c6a.4xlarge) 

© ZOZO, Inc. 28 検索結果画面の場合(性能試験) 試験結果 1podあたりの捌けるリクエスト数とレイテンシ 2podあたりの捌けるリクエスト数とレイテンシ この結果を受けてマルチプロセス化+インスタンスタイプを変更する方針に決定 m5.xlarge リクエスト数: 約8req/sec レイテンシー: 約700ms Node.js マルチプロセス化(m5.4xlarge) リクエスト数: 約40req/sec レイテンシー: 約630ms マルチプロセス化 + インスタイプ変更(c6a.4xlarge) リクエスト数: 約60req/sec レイテンシー: 約660ms m5.xlarge リクエスト数: 約15req/sec レイテンシー: 約770ms マルチプロセス化 + インスタイプ変更(c6a.4xlarge) リクエスト数: 約120req/sec レイテンシー: 約670ms 

© ZOZO, Inc. 29 検索結果画面の場合(負荷試験) 目標値 ● レイテンシ ○ SSR: 検索結果画面のSLOを比較し約900ms以内とした ○ CSR: 他のAPIと同じくらいになるように約600ms以内とした ● リクエスト数 ○ 1podあたりどれくらいのreq/secが捌けるか ○ 1podあたりどれくらい捌けるかわかるとセール時のリクエスト数が分かればどれ くらいのPodが必要か見積もることが可能 

© ZOZO, Inc. 30 検索結果画面の場合(負荷試験) シナリオ ● CSRのエンドポイントが3本 ● SSRのページは4種類 ○ ショップ検索、ブランド検索、カテゴリ検索、フリーワード検索 ○ ページが参照されている割合をSplunkにて算出 ● SSRのページに合わせてCSRも叩くようなシナリオを作成 ● マルチプロセス化+インスタンスタイプ変更(c6a.4xlarge)で実施 

© ZOZO, Inc. 31 検索結果画面の場合(負荷試験) 試験結果 SSR: 1podあたりの捌けるリクエスト数とレイテンシー SSR: 2podあたりの捌けるリクエスト数とレイテンシー 性能試験よりもreq/secは少なかったがPodを並べればセールに向けたスケールも可能 マルチプロセス化 + インスタイプ変更(c6a.4xlarge) リクエスト数: 約25req/sec レイテンシー: 約700ms マルチプロセス化 + インスタイプ変更(c6a.4xlarge) リクエスト数: 約50req/sec レイテンシー: 約880ms 

© ZOZO, Inc. 32 検索結果画面の場合 リリース後 ● リリース前の性能試験でNode.jsのボトルネックになりそうなところを潰せたことで 安心してリリースができた ● SLOの改善に寄与できた(検索結果画面) ○ リリース後はp95で約500msほどレイテンシーが改善された ● セール時などのタイミングはレイテンシが目標値を上回るケースがありますが、 安定したサービス提供ができている ● パフォーマンスが安定していることでアラート輪番とは別にセール時の 特別な監視体制を敷く必要もなくなった 

© ZOZO, Inc. 今後チームでパフォーマンス改善を継続する取り組み 

© ZOZO, Inc. 34 今後チームでパフォーマンス改善を継続する取り組み ● 可観測性の強化 ● 継続的な負荷試験の自動化 ● パフォーマンス改善するための開発者との体制作り ● 改善効果の事業貢献度を可視化する仕組み作り 課題 

© ZOZO, Inc. 35 今後チームでパフォーマンス改善を継続する取り組み ● パスごとのレイテンシー観測 ○ Datadogだと別要因でパスごとに観測しづらいためSplunkを利用してパスごとに観測できる ようにする ○ Splunkの活用を強化していく ● UX改善するための指標の観測 ○ CDNにAkamaiを利用しているので、Akamaiが提供しているmPulseというリアルユーザー監 視（RUM）ソリューションを利用することが可能 ○ mPulseを利用して、Core Web Vitalsの指標を継続的に確認し改善箇所を特定する 可観測性の強化 

© ZOZO, Inc. 36 今後チームでパフォーマンス改善を継続する取り組み ● CI/CDのパイプラインで負荷試験の自動化 ● 負荷試験を自動化で実行するための事前シナリオ作成の仕組み化 ○ 課題 ■ 開発者に作ってもらうまたはSREでどうやって巻き取るか ■ シナリオ作成の工数 ■ シナリオの品質担保 ● きちんと正常系が確認できる内容になっているか 継続的な負荷試験の自動化 

© ZOZO, Inc. 37 今後チームでパフォーマンス改善を継続する取り組み ● パフォーマンス改善担当者を明確化する ○ SREとFEで責任者を立ててWorking Groupの活動として昇格させ責任を持って進められるよ うにする ● 優先度・緊急度定義を確定する ● ボトルネック特定後のアクションの開発者と認識合わせ、ドキュメント化 ● 改善後のパフォーマンスレビュー会などの知見の共有会を実施し成果の成功例や失敗例などを共有 する パフォーマンス改善するための開発者との体制作り 

© ZOZO, Inc. 38 今後チームでパフォーマンス改善を継続する取り組み ● グロースチームとの協業体制の構築 ● パフォーマンス改善と事業KPIを紐付けられる用なダッシュボードを作成する ● 成功事例の共有 ○ 月一の部内の定例で共有する ○ 最終的には成果報告会などでパフォーマンス改善をしたことによる事業KPIの向上で発表する 改善効果の事業貢献度を可視化する仕組み作り 

© ZOZO, Inc. まとめ 

© ZOZO, Inc. 40 まとめ リプレイスは「終わり」ではなく「始まり」 ZOZOTOWNは、リプレイスを通じて、柔軟なシステム、開発生産性、そして技術のモダン化という基盤を築きました 。 このプロジェクトはゴールではなく、お客様にいつでも快適にお買い物していただけるサービスを継続的に提供するため のスタート地点です 。 「点」の改善から「線」の改善へ リプレイスプロジェクトの負荷試験で得られた知見は、ボトルネックを特定し、リリース時の安定化に大きく寄与しまし た 。しかし、本当の価値は、この経験を一過性のものにせず、日々の開発に活かすことにあります。 パフォーマンスを支えるのはチームの「文化」 今後は、可観測性の強化、継続的な負荷試験の自動化、そして開発者との連携体制を通じて、パフォーマンス 改善をチームの文化として定着させていきます 。 パフォーマンス改善は「事業貢献」に繋がる グロースチームと連携し、技術指標が事業KPIの向上にどう貢献したかを可視化することで 、パフォーマンス改善は全社 的な活動へと昇華します。 

No content