Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

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

#jjug_ccc

Avatar for ZOZO Developers

ZOZO Developers PRO

November 15, 2025
Tweet

More Decks by ZOZO Developers

Other Decks in Technology

Transcript

  1. © ZOZO, Inc. 2 理想と現実 20年物のVBScriptで書かれた 11万行 のコード これを 3年

    でクラウド上のマイクロサービスにリプレイス しかもサービスは止められない 皆さんなら、どうしますか? 私たちの答え:「モジュラモノリス」という過渡期戦略
  2. © ZOZO, Inc. 株式会社ZOZO EC基盤開発本部 ECプラットフォーム部 マイクロサービス戦略ブロック ブロック長・テックリード 半澤 詩織

    2021年〜:カートリプレイスを担当 2023-2024年:カート決済面リプレイスを担当        ⇨現在進行形でリプレイスは継続中 3
  3. © ZOZO, Inc. 6 既存システムの規模(カートに入れる〜注文履歴) • 画面数: 105画面 • VBSのコード:

    11万行 • ストアドプロシージャ: 208個 • 接続するテーブル数: 173個
  4. © ZOZO, Inc. 7 既存システムの技術スタックと構成 • Windows Server • VBS

    / ClassicASP ◦ 手動リリース ◦ テストコードなし • オンプレミスSQL Server ◦ カートDB、注文DB ◦ リンクサーバーで接続 ◦ 分散トランザクション ◦ ストアドプロシージャ
  5. © ZOZO, Inc. 8 4つの大きな課題 1. 保守性の低さ • 複雑な仕様、テストコードがない •

    11万行のコード 2. 開発生産性の低さ • VBSによる制約 • モダンツールが使えない 4. 拡張性の低さ • オンプレ SQL Server • スケールアップ限界 3. レガシー技術 • VBSの進化は20年以上停滞 • 事業継続性リスク
  6. © ZOZO, Inc. 9 将来的な目標アーキテクチャ ✓ 3つのマイクロサービス ✓ Java /

    SpringBoot on AWS ✓ CI/CD ✓ Sagaパターン しかし、3年では到達困難
  7. © ZOZO, Inc. 10 アプローチ1: DBの分解から進める • VBSはそのまま • データベースの責務分解

    ◦ 173個のテーブル ◦ 208個のストアドプロシージャ ◦ リンクサーバーの分散トランザクショ ン分解 ▪ 在庫の整合性担保がとても大変 ✓データの責務明確化 ✓DBの負荷軽減(現状余裕あり) 技術的負債が長期間継続
  8. © ZOZO, Inc. 11 アプローチ2: VBSのJava化から進める ✓ 採用 • VBS

    を Java に置き換え ◦ クラウド利用による自動スケール ◦ CI/CD ◦ モダンなライブラリ • DBは既存のまま ◦ ストアドプロシージャ ◦ 分散トランザクション ◦ 他データとのJOIN ✓ 技術的負債を早期に解消 DBの課題は、今後も継続改善
  9. © ZOZO, Inc. 13 サービスベースアーキテクチャ vs モジュラモノリス 比較項目 サービスベース モジュラモノリス

    アプリ構成 3つに分割 1つ(モジュール分割) データベース 共有 共有 連携方法 HTTP通信 メソッド呼び出し デプロイ 各サービス独立 ✓ 全体に影響 △ 開発のシンプルさ 複雑 △ シンプル ✓ 将来の切り出し - 容易 ✓
  10. © ZOZO, Inc. 14 直面した4つの制約 1. 既存仕様の複雑さ • 完璧な網羅・テストが困難 •

    → 品質担保が最優先 2. ドメイン境界の不明確さ • 責務や境界に確信を持てていない • → 再分割リスクあり 4. 限られた時間 • 3年、事業案件とのバランス • → 効率的に進める必要あり 3. 分散システムの複雑性 • 冪等性、テスト、開発・運用 • → コスト大幅増
  11. © ZOZO, Inc. 17 採用した技術スタック 言語・フレームワーク • Java、SpringBoot ビルドツール •

    Gradle(マルチプロジェクト構成) • Gradle Version Catalog ソフトウェアアーキテクチャ • DDD + オニオンアーキテクチャ テストライブラリ • Spock、MockMvc、DBUnit、MockServer、WireMock
  12. © ZOZO, Inc. 19 モジュール構成の検討 検討プロセス • イベントストーミングで検討 決済モジュールの追加 •

    過去に検討していたが、マイクロサービスとしては見送っていた • イベントストーミングを通じて決済コンテキストの重要性を再認識 • モジュールとしてなら低コストで追加できるため、決済モジュールを追加 ポイント • 低コストで試せる、これがモジュラモノリスの強み
  13. © ZOZO, Inc. 20 Gradleマルチプロジェクトの依存管理 依存関係の管理 • オーケストレーター → カートモジュール、注文モジュール

    • カートと注文は互いに依存できないように build.gradle で定義 技術的な強制 • 定義されていない依存はコンパイルエラー • 技術的に強制できる メリット • 将来のマイクロサービス化を容易に • Gradle Version Catalog でライブラリバージョン一元管理
  14. © ZOZO, Inc. 21 テスト戦略(Googleのテストサイズ分類を参考) APIテスト(MediumテストのAPI単位の結合テスト) • 複雑なビジネスロジックの仕様を担保 • 内部構造に変化があっても、APIレベルで振る舞いを保証

    サイズ 対象 並列実行 重点ポイント Small 1クラス(モック使用) ✓ 可能 高速な単体テスト Medium Infrastructure層クラ ス △ 不可 DB・通信値の検証 API単位の結合テスト △ 不可 全APIで作成 Large 複数API統合テスト △ 不可 手動テスト・QAでカバー カバレッジ :99%
  15. © ZOZO, Inc. 22 モジュラモノリスのメリット 1. シンプルさ • メソッド呼び出しで完結 •

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

    Runner、並列数 2. ValueObject重複 • 将来を見据えて冗長性を受け入れ 4. 並行開発難 • コミュニケーションコスト 3. モジュール毎スケール不可 • パス毎のpod分離で対応済み 5. アーキテクチャレベルの課題が残っている • DB分散TX、ストアド → Java環境で継続改善できる基盤を作った 過渡期の戦略として、受け入れられる範囲 →
  17. © ZOZO, Inc. 24 大切なこと 完璧なアーキテクチャは存在しない 重要なのは ✓ 自分たちの制約を見極める ✓

    何を優先し、何を後回しにするか ✓ その判断基準を明確にすること アーキテクチャ選択は、サービスを成長させるための手段