ZOZOTOWNカート決済リプレイス ── モジュラモノリスという過渡期戦略

2025/11/15 に JJUG CCC 2025 Fall で発表した登壇資料です。
https://ccc2025fall.java-users.jp/

株式会社ZOZO
EC基盤開発本部
ECプラットフォーム部 マイクロサービス戦略ブロック
ブロック長・テックリード
半澤 詩織

#jjug_ccc

Transcript

1. ZOZOTOWN カート決済リプレイス モジュラモノリスという過渡期戦略 株式会社ZOZO EC基盤開発本部 ECプラットフォーム部 マイクロサービス戦略ブロック ブロック長・テックリード 半澤 詩織 Copyright © ZOZO, Inc. 1
2. © ZOZO, Inc. 2 理想と現実 20年物のVBScriptで書かれた 11万行 のコード これを 3年 でクラウド上のマイクロサービスにリプレイス しかもサービスは止められない 皆さんなら、どうしますか？ 私たちの答え：「モジュラモノリス」という過渡期戦略
3. © ZOZO, Inc. 株式会社ZOZO EC基盤開発本部 ECプラットフォーム部 マイクロサービス戦略ブロック ブロック長・テックリード 半澤 詩織 2021年〜：カートリプレイスを担当 2023-2024年：カート決済面リプレイスを担当 　　　　　　　⇨現在進行形でリプレイスは継続中 3
4. © ZOZO, Inc. 4 ZOZOTOWNリプレイスの目的 お客様に、いつでも快適に お買い物をしていただけるサービスを提供し、 ZOZOTOWNを成長させるため
5. © ZOZO, Inc. 5 全社的なリプレイス方針 • クラウド化 • マイクロサービス化 • 脱VBScript（以降VBSと省略）
6. © ZOZO, Inc. 6 既存システムの規模（カートに入れる〜注文履歴） • 画面数: 105画面 • VBSのコード: 11万行 • ストアドプロシージャ: 208個 • 接続するテーブル数: 173個
7. © ZOZO, Inc. 7 既存システムの技術スタックと構成 • Windows Server • VBS / ClassicASP ◦ 手動リリース ◦ テストコードなし • オンプレミスSQL Server ◦ カートDB、注文DB ◦ リンクサーバーで接続 ◦ 分散トランザクション ◦ ストアドプロシージャ
8. © ZOZO, Inc. 8 4つの大きな課題 1. 保守性の低さ • 複雑な仕様、テストコードがない • 11万行のコード 2. 開発生産性の低さ • VBSによる制約 • モダンツールが使えない 4. 拡張性の低さ • オンプレ SQL Server • スケールアップ限界 3. レガシー技術 • VBSの進化は20年以上停滞 • 事業継続性リスク
9. © ZOZO, Inc. 9 将来的な目標アーキテクチャ ✓ 3つのマイクロサービス ✓ Java / SpringBoot on AWS ✓ CI/CD ✓ Sagaパターン しかし、3年では到達困難
10. © ZOZO, Inc. 10 アプローチ1: DBの分解から進める • VBSはそのまま • データベースの責務分解 ◦ 173個のテーブル ◦ 208個のストアドプロシージャ ◦ リンクサーバーの分散トランザクショ ン分解 ▪ 在庫の整合性担保がとても大変 ✓データの責務明確化 ✓DBの負荷軽減（現状余裕あり） 技術的負債が長期間継続
11. © ZOZO, Inc. 11 アプローチ2: VBSのJava化から進める ✓ 採用 • VBS を Java に置き換え ◦ クラウド利用による自動スケール ◦ CI/CD ◦ モダンなライブラリ • DBは既存のまま ◦ ストアドプロシージャ ◦ 分散トランザクション ◦ 他データとのJOIN ✓ 技術的負債を早期に解消 DBの課題は、今後も継続改善
12. © ZOZO, Inc. 12 次の課題 私たちの選択：VBSのJava化から進める では、Java化を進める際、 アプリケーションコードをどう分割するか？ サービスベースアーキテクチャ vs モジュラモノリス
13. © ZOZO, Inc. 13 サービスベースアーキテクチャ vs モジュラモノリス 比較項目 サービスベース モジュラモノリス アプリ構成 3つに分割 1つ（モジュール分割） データベース 共有 共有 連携方法 HTTP通信 メソッド呼び出し デプロイ 各サービス独立 ✓ 全体に影響 △ 開発のシンプルさ 複雑 △ シンプル ✓ 将来の切り出し - 容易 ✓
14. © ZOZO, Inc. 14 直面した4つの制約 1. 既存仕様の複雑さ • 完璧な網羅・テストが困難 • → 品質担保が最優先 2. ドメイン境界の不明確さ • 責務や境界に確信を持てていない • → 再分割リスクあり 4. 限られた時間 • 3年、事業案件とのバランス • → 効率的に進める必要あり 3. 分散システムの複雑性 • 冪等性、テスト、開発・運用 • → コスト大幅増
15. © ZOZO, Inc. 15 簡単ではなかった判断 正直に言うと、この判断は簡単ではありませんでした。 議論の中では、 「今サービスを分けておかないと、 後で分離するのはもっと難しくなるのでは？」 という懸念もありました。
16. © ZOZO, Inc. 16 私たちの決断 さまざまな制約の中で、最も優先するべきことは何か？ ✓ 分散システムの複雑性を避ける ✓ 仕様の網羅性とテスト品質に集中 ✓ 3年で確実にVBSを脱却 モジュラモノリスを選択
17. © ZOZO, Inc. 17 採用した技術スタック 言語・フレームワーク • Java、SpringBoot ビルドツール • Gradle（マルチプロジェクト構成） • Gradle Version Catalog ソフトウェアアーキテクチャ • DDD + オニオンアーキテクチャ テストライブラリ • Spock、MockMvc、DBUnit、MockServer、WireMock
18. © ZOZO, Inc. 18 モジュラモノリス構成 モジュール間 = Javaのメソッド呼び出し ✓ ネットワークレイテンシなし ✓ エラーハンドリングもシンプル
19. © ZOZO, Inc. 19 モジュール構成の検討 検討プロセス • イベントストーミングで検討 決済モジュールの追加 • 過去に検討していたが、マイクロサービスとしては見送っていた • イベントストーミングを通じて決済コンテキストの重要性を再認識 • モジュールとしてなら低コストで追加できるため、決済モジュールを追加 ポイント • 低コストで試せる、これがモジュラモノリスの強み
20. © ZOZO, Inc. 20 Gradleマルチプロジェクトの依存管理 依存関係の管理 • オーケストレーター → カートモジュール、注文モジュール • カートと注文は互いに依存できないように build.gradle で定義 技術的な強制 • 定義されていない依存はコンパイルエラー • 技術的に強制できる メリット • 将来のマイクロサービス化を容易に • Gradle Version Catalog でライブラリバージョン一元管理
21. © ZOZO, Inc. 21 テスト戦略（Googleのテストサイズ分類を参考） APIテスト（MediumテストのAPI単位の結合テスト） • 複雑なビジネスロジックの仕様を担保 • 内部構造に変化があっても、APIレベルで振る舞いを保証 サイズ 対象 並列実行 重点ポイント Small 1クラス（モック使用） ✓ 可能 高速な単体テスト Medium Infrastructure層クラ ス △ 不可 DB・通信値の検証 API単位の結合テスト △ 不可 全APIで作成 Large 複数API統合テスト △ 不可 手動テスト・QAでカバー カバレッジ ：99%
22. © ZOZO, Inc. 22 モジュラモノリスのメリット 1. シンプルさ • メソッド呼び出しで完結 • 分散システムの複雑性を回避 2. リファクタしやすい • 処理移動や依存関係修正が簡単 • スピーディな改善が可能 4. 開発効率が高い • 1リポジトリで全体を見渡せる • 初期構築や共通処理の効率化 3. テストしやすい • 同一プロセス内で完結 • 結合テストが効率的にできる → 仕様の網羅性とテスト品質に集中できた
23. © ZOZO, Inc. 23 モジュラモノリスのデメリット 1. テスト時間増加 • 対処: Larger Runner、並列数 2. ValueObject重複 • 将来を見据えて冗長性を受け入れ 4. 並行開発難 • コミュニケーションコスト 3. モジュール毎スケール不可 • パス毎のpod分離で対応済み 5. アーキテクチャレベルの課題が残っている • DB分散TX、ストアド → Java環境で継続改善できる基盤を作った 過渡期の戦略として、受け入れられる範囲 →
24. © ZOZO, Inc. 24 大切なこと 完璧なアーキテクチャは存在しない 重要なのは ✓ 自分たちの制約を見極める ✓ 何を優先し、何を後回しにするか ✓ その判断基準を明確にすること アーキテクチャ選択は、サービスを成長させるための手段
25. © ZOZO, Inc. 25 後日談 2023年5月: カート決済システムにモジュラモノリス採用が決定 2024年5月: MicrosoftからVBSの廃止が発表 → VBSのJava化を優先した判断は正しかった ✓