ZOZOTOWN カート決済リプレイス モジュラモノリスという過渡期戦略 株式会社ZOZO EC基盤開発本部 ECプラットフォーム部 マイクロサービス戦略ブロック ブロック長・テックリード 半澤 詩織 Copyright © ZOZO, Inc. 1 

© ZOZO, Inc. 2 理想と現実 20年物のVBScriptで書かれた 11万行 のコード これを 3年 でクラウド上のマイクロサービスにリプレイス しかもサービスは止められない 皆さんなら、どうしますか？ 私たちの答え：「モジュラモノリス」という過渡期戦略 

© ZOZO, Inc. 株式会社ZOZO EC基盤開発本部 ECプラットフォーム部 マイクロサービス戦略ブロック ブロック長・テックリード 半澤 詩織 2021年〜：カートリプレイスを担当 2023-2024年：カート決済面リプレイスを担当 　　　　　　　⇨現在進行形でリプレイスは継続中 3 

© ZOZO, Inc. 4 ZOZOTOWNリプレイスの目的 お客様に、いつでも快適に お買い物をしていただけるサービスを提供し、 ZOZOTOWNを成長させるため 

© ZOZO, Inc. 5 全社的なリプレイス方針 ● クラウド化 ● マイクロサービス化 ● 脱VBScript（以降VBSと省略） 

© ZOZO, Inc. 6 既存システムの規模（カートに入れる〜注文履歴） ● 画面数: 105画面 ● VBSのコード: 11万行 ● ストアドプロシージャ: 208個 ● 接続するテーブル数: 173個 

© ZOZO, Inc. 7 既存システムの技術スタックと構成 ● Windows Server ● VBS / ClassicASP ○ 手動リリース ○ テストコードなし ● オンプレミスSQL Server ○ カートDB、注文DB ○ リンクサーバーで接続 ○ 分散トランザクション ○ ストアドプロシージャ 

© ZOZO, Inc. 8 4つの大きな課題 1. 保守性の低さ ● 複雑な仕様、テストコードがない ● 11万行のコード 2. 開発生産性の低さ ● VBSによる制約 ● モダンツールが使えない 4. 拡張性の低さ ● オンプレ SQL Server ● スケールアップ限界 3. レガシー技術 ● VBSの進化は20年以上停滞 ● 事業継続性リスク 

© ZOZO, Inc. 9 将来的な目標アーキテクチャ ✓ 3つのマイクロサービス ✓ Java / SpringBoot on AWS ✓ CI/CD ✓ Sagaパターン しかし、3年では到達困難 

© ZOZO, Inc. 10 アプローチ1: DBの分解から進める ● VBSはそのまま ● データベースの責務分解 ○ 173個のテーブル ○ 208個のストアドプロシージャ ○ リンクサーバーの分散トランザクショ ン分解 ■ 在庫の整合性担保がとても大変 ✓データの責務明確化 ✓DBの負荷軽減（現状余裕あり） 技術的負債が長期間継続 

© ZOZO, Inc. 11 アプローチ2: VBSのJava化から進める ✓ 採用 ● VBS を Java に置き換え ○ クラウド利用による自動スケール ○ CI/CD ○ モダンなライブラリ ● DBは既存のまま ○ ストアドプロシージャ ○ 分散トランザクション ○ 他データとのJOIN ✓ 技術的負債を早期に解消 DBの課題は、今後も継続改善 

© ZOZO, Inc. 12 次の課題 私たちの選択：VBSのJava化から進める では、Java化を進める際、 アプリケーションコードをどう分割するか？ サービスベースアーキテクチャ vs モジュラモノリス 

© ZOZO, Inc. 13 サービスベースアーキテクチャ vs モジュラモノリス 比較項目 サービスベース モジュラモノリス アプリ構成 3つに分割 1つ（モジュール分割） データベース 共有 共有 連携方法 HTTP通信 メソッド呼び出し デプロイ 各サービス独立 ✓ 全体に影響 △ 開発のシンプルさ 複雑 △ シンプル ✓ 将来の切り出し - 容易 ✓ 

© ZOZO, Inc. 14 直面した4つの制約 1. 既存仕様の複雑さ ● 完璧な網羅・テストが困難 ● → 品質担保が最優先 2. ドメイン境界の不明確さ ● 責務や境界に確信を持てていない ● → 再分割リスクあり 4. 限られた時間 ● 3年、事業案件とのバランス ● → 効率的に進める必要あり 3. 分散システムの複雑性 ● 冪等性、テスト、開発・運用 ● → コスト大幅増 

© ZOZO, Inc. 15 簡単ではなかった判断 正直に言うと、この判断は簡単ではありませんでした。 議論の中では、 「今サービスを分けておかないと、 後で分離するのはもっと難しくなるのでは？」 という懸念もありました。 

© ZOZO, Inc. 16 私たちの決断 さまざまな制約の中で、最も優先するべきことは何か？ ✓ 分散システムの複雑性を避ける ✓ 仕様の網羅性とテスト品質に集中 ✓ 3年で確実にVBSを脱却 モジュラモノリスを選択 

© ZOZO, Inc. 17 採用した技術スタック 言語・フレームワーク ● Java、SpringBoot ビルドツール ● Gradle（マルチプロジェクト構成） ● Gradle Version Catalog ソフトウェアアーキテクチャ ● DDD + オニオンアーキテクチャ テストライブラリ ● Spock、MockMvc、DBUnit、MockServer、WireMock 

© ZOZO, Inc. 18 モジュラモノリス構成 モジュール間 = Javaのメソッド呼び出し ✓ ネットワークレイテンシなし ✓ エラーハンドリングもシンプル 

© ZOZO, Inc. 19 モジュール構成の検討 検討プロセス ● イベントストーミングで検討 決済モジュールの追加 ● 過去に検討していたが、マイクロサービスとしては見送っていた ● イベントストーミングを通じて決済コンテキストの重要性を再認識 ● モジュールとしてなら低コストで追加できるため、決済モジュールを追加 ポイント ● 低コストで試せる、これがモジュラモノリスの強み 

© ZOZO, Inc. 20 Gradleマルチプロジェクトの依存管理 依存関係の管理 ● オーケストレーター → カートモジュール、注文モジュール ● カートと注文は互いに依存できないように build.gradle で定義 技術的な強制 ● 定義されていない依存はコンパイルエラー ● 技術的に強制できる メリット ● 将来のマイクロサービス化を容易に ● Gradle Version Catalog でライブラリバージョン一元管理 

© ZOZO, Inc. 21 テスト戦略（Googleのテストサイズ分類を参考） APIテスト（MediumテストのAPI単位の結合テスト） ● 複雑なビジネスロジックの仕様を担保 ● 内部構造に変化があっても、APIレベルで振る舞いを保証 サイズ 対象 並列実行 重点ポイント Small 1クラス（モック使用） ✓ 可能 高速な単体テスト Medium Infrastructure層クラ ス △ 不可 DB・通信値の検証 API単位の結合テスト △ 不可 全APIで作成 Large 複数API統合テスト △ 不可 手動テスト・QAでカバー カバレッジ ：99% 

© ZOZO, Inc. 22 モジュラモノリスのメリット 1. シンプルさ ● メソッド呼び出しで完結 ● 分散システムの複雑性を回避 2. リファクタしやすい ● 処理移動や依存関係修正が簡単 ● スピーディな改善が可能 4. 開発効率が高い ● 1リポジトリで全体を見渡せる ● 初期構築や共通処理の効率化 3. テストしやすい ● 同一プロセス内で完結 ● 結合テストが効率的にできる → 仕様の網羅性とテスト品質に集中できた 

© ZOZO, Inc. 23 モジュラモノリスのデメリット 1. テスト時間増加 ● 対処: Larger Runner、並列数 2. ValueObject重複 ● 将来を見据えて冗長性を受け入れ 4. 並行開発難 ● コミュニケーションコスト 3. モジュール毎スケール不可 ● パス毎のpod分離で対応済み 5. アーキテクチャレベルの課題が残っている ● DB分散TX、ストアド → Java環境で継続改善できる基盤を作った 過渡期の戦略として、受け入れられる範囲 → 

© ZOZO, Inc. 24 大切なこと 完璧なアーキテクチャは存在しない 重要なのは ✓ 自分たちの制約を見極める ✓ 何を優先し、何を後回しにするか ✓ その判断基準を明確にすること アーキテクチャ選択は、サービスを成長させるための手段 

© ZOZO, Inc. 25 後日談 2023年5月: カート決済システムにモジュラモノリス採用が決定 2024年5月: MicrosoftからVBSの廃止が発表 → VBSのJava化を優先した判断は正しかった ✓ 

No content