はじめに
こんにちは、MA部の林です。
ZOZOTOWNでは、プッシュ通知・LINE・メール・サイト内お知らせなどを通じてキャンペーン配信をしています。MA部ではそれらの配信を担うマーケティングオートメーション（MA）システムの開発を担当しています。一部のメンバーは直近3年ほど、マーケティングシステムのリプレイスプロジェクトZOZO Marketing Platform（ZMP）に注力しています。2025年7月にはパーソナライズ・リアルタイム処理のリプレイスが完了し、ZMPフェーズ2としてリリースしました。
しかし、ZMPフェーズ2のリリースには課題がありました。リプレイスプロジェクトに携わったメンバーとそれ以外のメンバーで、ZMPへの理解度に差が生じていたのです。MA部では全メンバーがローテーションでオンコール対応を担当しており、プロジェクトに関わっていないメンバーもZMPフェーズ2の障害対応が求められます。
この状態でリリースを迎えれば、障害対応時に特定のメンバーに負荷が集中し、迅速な対応が困難になることが予想されました。そこで、リリース直前の7月3日〜4日の2日間、カオスエンジニアリング手法を用いた合宿を実施しました。本記事では、この合宿の取り組みと成果について報告します。
目次
存在していた課題：リプレイスプロジェクトによる理解度の差
ZMPは、システムの大幅な刷新を伴うプロジェクトでした。フェーズ1・2のそれぞれの概要については、下記のテックブログをご覧ください。
ZMPフェーズ2は、パーソナライズ・リアルタイム処理を担当するリアルタイムマーケティングシステム、バッチシステム、管理画面という3つの主要コンポーネントで構成されています。
このような複雑な構成に加えて、リプレイスプロジェクトのため既存システムの理解も必要であったことから、以下のような理解度の差が生じていました。
非プロジェクトメンバーの課題
- ZMPフェーズ2のシステム構成が把握できない
- ログの場所や確認方法が不明
- 障害時の初動対応ができない
プロジェクトメンバーの課題
- 稼働前のシステムのため、実際の障害パターンが未知数
- 担当領域の細分化により、システム全体の理解が不足
- 「リアルタイムマーケティングシステムは詳しいが、管理画面は不慣れ」といった偏り
このような理解度の差は、リリース後の運用において以下の問題が予想されました。
- 夜間・休日の障害対応が特定メンバーに集中
- 初動調査の遅れによる復旧時間の長期化
- システム理解不足による誤った対応で二次障害を引き起こす可能性
これらの課題を解決するため、全メンバーがZMPフェーズ2を理解し、基本的な障害対応ができる体制の構築が必要でした。
解決アプローチ：カオスエンジニアリング合宿
カオスエンジニアリングは、システムに意図的に障害を発生させ、影響調査・原因特定・障害対応をする手法です。今回、この手法を採用し、合宿を開催した理由は以下のとおりです。
実践的な学習
- 座学だけでなく、実際の障害対応を体験できる
- オフライン合宿で気軽に会話できる環境を活かし、障害発生時に必要なコミュニケーションを体験できる
知識の共有
- リプレイスプロジェクトメンバーの暗黙知を形式知化できる
- 合宿を踏まえ、障害対応の手順書をブラッシュアップできる
合宿の設計と準備
事前準備
リプレイスプロジェクトメンバーを運営委員とし、合宿を円滑に進めるため以下の準備をしました。
まず、ZMPフェーズ2の概要を非プロジェクトメンバーに説明するため、アーキテクチャ図などのドキュメントを改めて整備しました。管理画面についても理解を深めてもらうため、運用者目線の操作説明書を作成しました。
また、カオスエンジニアリングで使用する障害パターンを洗い出し、合宿で取り組む課題として整理しました。具体的には、シミュレーション試験中に発生したアラートや、特殊なデータを投入してバリデーションエラーを発生させるシナリオなどを準備しました。
タイムテーブル
2日間の合宿は、以下のスケジュールで実施しました。座学でシステム全体の知識を習得した後、障害対応の実践を通じて実際のコードを確認しながら詳細を理解してもらう構成としました。
Day1
| 時間 | 内容 | 詳細 |
|---|---|---|
| 10:30 〜 13:00 |
システム理解 | リプレイスプロジェクトメンバーによる ZMPフェーズ2の詳細解説 ・実際に管理画面を操作 |
| 14:00 〜 19:00 |
カオスエンジニアリング （リアルタイムマーケティングシステム） |
障害シナリオ5件の実践と模範解答 |
| 19:00 〜 22:00 |
振り返り | ワールド・カフェ形式での学びの共有 |
Day2
| 時間 | 内容 | 詳細 |
|---|---|---|
| 08:00 〜 10:00 |
システム理解 | ZMPフェーズ2のピーク時間帯の解説・ログの追い方など |
| 10:00 〜 16:00 |
カオスエンジニアリング （バッチシステム） |
障害シナリオ4件の実践と模範解答 |
| 16:00 〜 18:00 |
振り返り | 全体を通しての振り返り ・今後の障害発生時の手順整理 |
システム理解
1日目の午前中は、リプレイスプロジェクトメンバーによるZMPフェーズ2の主要コンポーネント解説から始めました。リアルタイムマーケティングシステムとバッチシステムは複雑なアーキテクチャと処理フローを持つため、図表を用いながら丁寧に説明することで、非プロジェクトメンバーにも理解しやすい内容にできました。オフライン開催の利点を活かし、各コンポーネントについて活発な質疑応答が行われました。
座学の後は、実際に管理画面を操作してキャンペーン作成を体験しました。この作業は通常マーケターが担当する業務ですが、エンジニアが実際に操作することで、運用担当の視点からシステムを理解できました。
2日目の朝には、リアルタイムマーケティングシステムのピーク時間帯やログの追い方など、障害対応時に特に注意すべきポイントを共有しました。これにより、参加者は障害対応の際に重要な視点を持つことができました。
カオスエンジニアリング
2日間で合計9つの障害シナリオに取り組みました。シナリオは実際に起こりうる問題を再現しています。
シナリオ例
| 詳細 | |
|---|---|
| アラート | PubSubのサブスクリプションが滞留し、監視アラートから通知が届いた。 |
| 調査 | 滞留しているサブスクリプションのリクエスト先を特定した。 リクエスト先のCloud Runにてエラーログを見つけた。 エラーログを元にアプリケーションコードを確認した。 アプリケーションコードにデバッグ用のコードが混入していることを発見した。 |
| 原因 | Cloud Runのコードにデバッグ用のコードが混入しており、常に500エラーになってしまっていた。 |
| 対応 | 暫定対応: デバッグ用コードを削除し、Cloud Runを再デプロイする。 |
| 備考 | 該当のアプリケーションは毎分Cloud Schedulerから実行されるアプリである。 復旧後、Cloud Schedulerの次回実行が成功すれば、障害発生中の処理もリカバリーされることを確認した。 |
各シナリオの実施方法は以下の通りです。まずアラート情報のみを各ペアに共有し、30分間で原因特定から暫定対応まで取り組んでもらいました。
その後、リプレイスプロジェクトメンバーが模範解答を発表し、効果的な調査手順や原因特定のポイント、暫定対応と恒久対応の判断基準などを共有しました。
実践パートだけではペアごとの解決度にばらつきがあったため、全員が障害対応の手順を習得できるように配慮し、模範解答・解説までセットで実施しました。
実施成果
MA部全体の障害対応スキル向上
合宿の実施により、参加者の意識とスキルに明確な変化が見られました。安全な環境で障害シナリオを体験したことで、「まず調べてみる」という積極的な姿勢が醸成されました。また、メンバー間のコミュニケーションが活発化し、情報共有の重要性を改めて認識する機会となりました。これらの変化により、MA部全体が自信を持ってZMPフェーズ2のリリースを迎えることができました。
ZMPフェーズ2のドキュメント整備
合宿を通じて、障害シナリオの対応手順や最新のシステム構成図などのドキュメントが整備されました。これにより、特定のメンバーに依存しない障害対応の体制を構築できました。実際に、ZMPフェーズ2リリース後に発生した障害において、原因は異なるものの対応方法が合宿で扱ったシナリオと同様のケースがありました。その際、合宿で作成したドキュメントを活用して迅速な障害対応を実現でき、合宿の効果を実感しました。
フィードバックによるZMPフェーズ2の改善
合宿中の障害シナリオに対して、「このエラーはバッチシステムで発生しているが、前段の管理画面の登録時にチェックできるのではないか」といったフィードバックが寄せられました。この指摘を受けて、合宿後に管理画面でのバリデーション機能を強化しました。根本的にアラートが発生しないよう予防策を講じることができた点で、非常に大きな成果と言えます。また、管理画面の操作経験が少ないメンバーからの視点であったため、部全体でZMPに対する理解が深まっていることも確認できました。
今後の展開
現在（2025年9月時点）は、ZMPフェーズ2リリース直後ということもあり、リプレイスプロジェクトメンバーが最低1名は対応できるようオンコールシフトを組んでいます。今回の合宿により非プロジェクトメンバーもZMPフェーズ2への理解を深め、定期的な障害対応の振り返りを部全体で実施していることから、MA部全体にZMPフェーズ2の知見が着実に浸透していると感じています。
今後の目標は、非プロジェクトメンバーのみでもオンコール対応ができる体制の確立です。また、ZMPは継続的な機能追加・改善が予定されているため、ドキュメントの定期更新や部内勉強会の開催を通じて、最新のシステム理解と障害対応スキルの維持・向上を図っていく予定です。
まとめ
本記事では、ZMPフェーズ2リリース前に実施したカオスエンジニアリング合宿について紹介しました。実践的な学習を重視したアプローチにより、システム理解の向上と障害対応スキルの習得を実現し、MA部全体が自信を持ってリリースを迎えることができました。
合宿で整備されたドキュメントは、リリース後の実際の障害対応でもその価値を発揮しており、今後も継続的に活用していく予定です。カオスエンジニアリングを組織的な学習手法として検討されている方々の参考になれば幸いです。
ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。
