【TECH BLOG】ZOZOTOWNで最大級のイベントである新春セールを乗り越えるための負荷試験とその効果

はじめに

こんにちは、SRE部の秋田と伊藤です。普段はZOZOTOWNのオンプレミスとクラウドの運用・保守・構築に携わっています。

新春セールはZOZOTOWNの中でも最も力を入れているイベントの1つであり、セール開始直後は毎年最大級のアクセスやトラフィックが発生しています。この新春セールを無事に乗り越えるために2020年度から負荷試験を実施しています。負荷試験のシナリオでは機能ごとの試験ではなく、ユーザー導線に合わせてZOZOTOWNにセール同等のトラフィックを再現します。

本記事は、様々な変化をするZOZOTOWNにおける新春セールを乗り越えるための負荷試験を実施するまでにあった課題とその課題解決に向けた取り組みについてご紹介します。

目的

負荷試験の目的は、ボトルネックとなりうる箇所の特定、新春セールに耐えうるインフラリソースを算出することです。また、新春セールで必要な準備やトラブルが発生してしまった際の迅速な連携・対処の練習も兼ねています。

負荷試験における課題

負荷試験を実施する上で、以下のような課題がありました。

一気通貫で負荷試験することが困難
限られた試験時間で最も効果を得られる負荷試験の実施
2021年に新たにリリースされたマイクロサービスへの理解
過去の負荷試験で生じた課題

課題1：一気通貫で負荷試験することが困難

ZOZOTOWNは、パブリッククラウドを活用したマイクロサービス化が着実に進む一方で、まだアーキテクチャの再設計に着手できていないシステムも多く存在します。例えばオンプレミス環境でもWebサーバーや基幹データベースなど多くの重要システムが稼働しています。すさまじい勢いで成長するZOZOTOWNのトラフィックに耐えうるインフラ構成をオンプレミス環境で実現するため、これらのシステムは幾度となくスケールアウト・スケールアップを繰り返してきました。オンプレミス環境で負荷試験のために本番同等のインフラ環境を用意するのはコスト的にも難しい現状があります。

課題2：限られた試験時間で最も効果を得られる負荷試験の実施

ZOZOTOWNではアクセス数以外にも日々の施策によってWebサーバやAPIサーバの負荷状況が大幅に変化します。新春セールでは毎年多くの施策が実施されるため、負荷試験のシナリオ以外にも高負荷の要因となる状況を再現する必要がありました。

課題3：2021年に新たにリリースされたマイクロサービスへの理解

2021年には以下のリプレイスを実施しました。

「2021年ZOZO開発組織の進捗」でリプレイスの進捗についても紹介されています。

ZOZO開発組織の2021年の振り返りと現状 - Qiita

株式会社ZOZO 技術本部本部長の @sonots です。この記事は ZOZOのAdvent Calendar 2021のカレンダー 1の最終回（25日目）です。 ...

https://qiita.com/sonots/items/629b8d5785c04ae9c953

1年間で多くのマイクロサービスのリリースが行われました。多くはバックエンド機能のリプレイスです。これらはユーザー側から見たリクエスト先のURLは変えずに実現するケースが多いです。つまりバックエンド処理をモノリシックな構成から各APIを呼び出すマイクロサービス化を進めています。そのため、各マイクロサービスへ負荷が適切にかかるエンドポイントをリプレイス状況に合わせて精査、必要に応じて前年度利用した負荷試験のシナリオ改修が必要です。

課題4：過去の負荷試験で生じた課題

新春セールのような大規模な負荷を想定した場合、負荷をかける側がボトルネックとならないように負荷試験の環境を用意する必要があります。試験中にスムーズにスケールアウトを行うために2020年頃から分散負荷試験を採用するようになりました。

負荷試験の準備

前述した課題を解決するために負荷試験を実施するメンバーで様々な準備を1か月に渡って行いました。

負荷試験の実施に向けた準備
シナリオの準備
負荷試験の実施環境の作成

負荷試験の実施に向けた準備

課題1で挙げた問題は、すぐに解決できなかったため本番環境を利用して負荷試験を実施しました。本番環境では通常のユーザーのトラフィックを受けるため、いくつかのことを考慮して負荷試験を行う必要がありました。

ユーザーのトラフィックが少ない時間を選定
万が一の障害が起きた場合の対処準備
各部署への周知連絡

負荷試験の実施日と時間の選定は課題2で挙げた施策数が多い日を数日含めるように調整しました。負荷試験を実施する回数は4回で、施策数が多い日を2日間、シナリオ調整を含めた施策数の少ない2日間を選定しました。この施策数が多い日はビジネスサイドに相談した上で決定しています。

リモート環境でのコミュニケーション方法はGoogle MeetとSlackを活用しました。Google Meetは負荷試験の実施者の画面共有、各チームと会話するために利用します。Slackは負荷試験の実行前の簡易連絡や負荷試験の実施中の簡易メモなどで利用します。負荷試験の実施中の実行結果は記録用スプレッドシートを事前に共有して、なるべく負荷試験中に今何やっているかすぐにわかるように準備しました。

障害が起きた場合の対処に関しては、シナリオを迅速に停止できるよう準備をしていました。各チームにはメトリクスを常に監視してもらい何かエラーが増えた時点ですぐコミュニケーションをとるようにお願いしていました。また、周知に関しては各チームに関連部署へ連携をお願いしました。

シナリオの準備

シナリオ作成にはアクセスログを活用しました。過去のアクセスログからアクセス数や各URLごとのリクエスト数などの分析をし、なるべくユーザーの導線に近いものを再現できるようにします。ZOZOTOWNのWebサーバーのアクセスログの分析にはSplunkを用いています。

テックブログやQiitaでもTipsなどを紹介しているので興味のある方はご覧になってください。

使い勝手の良いSplunkダッシュボードの作り方 - ZOZO TECH BLOG

こんにちは。EC基盤本部 SRE部の渡邉です。去年の今頃はリモートワークによる運動不足を解消するために毎朝ロードバイクで走っていたのですが、3か月目に突入したころ急に飽きてしまいました。継続することの大切さを痛感しています。さて、以前公開した記事でも Splunkを導入した話について書きました。今回はSplunkをもっと活用していくために、効率的なサーチ方法やダッシュボード作成のTIPSを紹介します。あらかじめ、よく使うサーチやメトリクスのダッシュボードを作成しておくと、都度SPL（サーチ処理言語）

https://techblog.zozo.com/entry/splunk-easy-to-use-dashboard

【Splunk】１サーチで複数の時間範囲のサーチ結果を比較する - Qiita

Splunkは様々なデータに対応した統合ログプラットフォームです。 SPLというサーチ言語を利用してログから自分の見たい情報を抽出、Commnadsを活要して集計処理やデータの加工など様々なことが可能です。 Splunkは以下の図のようにlinechartをはじめpiechartやareachartなど様々な視覚エフェクトが提供されており、サーチ結果に対する可視化にも優れています。 ...

https://qiita.com/yokochin0105/items/b3e3cfa0f5391f73cee3

Splunkによる分析

Splunkを用いてアクセスログから以下の情報を抽出し、シナリオ作成に役立てました。

総リクエスト数
各機能ごとのリクエスト割合
秒間・分間リクエスト数の平均値
各エンドポイントに対応するParameter毎の統計情報

また、課題3で挙げた各マイクロサービスへの負荷がかかるエンドポイントの調査にもSplunkを利用しています。Splunk App for Streamを使ってWebサーバーやAPIサーバーから出ていくHTTP Requestを分析し、各マイクロサービスのエンドポイントに対しどのようなParameter、Bodyでリクエストを実行するか精査しました。不透明だった各マイクロサービスの呼び出しを正確に分析することで、シナリオの精度をあげられました。

以下はStreamを使ったSPLの実行例になります。

続きはこちら