巨大モノリスのリプレイス──機能整理とハイブリッドアーキテクチャで挑んだ再構築戦略

2025/11/20 に アーキテクチャConference 2025 で発表した登壇資料です。
https://architecture-con.findy-tools.io/2025

既存のモノリシックなシステムを全面的にマイクロサービス化するのは理想的に見えますが、現実には多くの制約やリスクが伴います。
本セッションでは、巨大な基幹システムのリプレイスにおいて、業務機能を整理し、機能ごとに適材適所の技術選定を行いながら、モノリスとマイクロサービスのハイブリッドアーキテクチャを採用した再構築戦略を紹介します。
モノリスの技術モダナイズとマイクロサービス化を両立したい方、段階的なアーキテクチャ移行に現実的な手法を探している方におすすめの内容です。

株式会社ZOZO
基幹システム本部　物流開発部　基幹リプレイスブロック　ブロック長
矢部 佑磨
EC基盤開発本部　SRE部　基幹プラットフォームSREブロック　テックリード
杉山 弘二

#アーキテクチャcon_findy

Transcript

1. 巨大モノリスのリプレイス 機能整理とハイブリッドアーキテクチャで挑んだ 再構築戦略 株式会社ZOZO 基幹システム本部　物流開発部　基幹リプレイスブロック　ブロック長 矢部 佑磨 EC基盤開発本部　SRE部　基幹プラットフォームSREブロック　テックリード 杉山 弘二 Copyright © ZOZO, Inc. 1
2. © ZOZO, Inc. 2 事業紹介
3. © ZOZO, Inc. https://zozo.jp/ 3 • ファッションEC • 1,600以上のショップ、9,000以上のブランドの取り扱い • 常時107万点以上の商品アイテム数と毎日平均2,700点以上の新着 商品を掲載（2025年6月末時点） • ブランド古着のファッションゾーン「ZOZOUSED」や コスメ専門モール「ZOZOCOSME」、シューズ専門ゾーン 「ZOZOSHOES」、ラグジュアリー＆デザイナーズゾーン 「ZOZOVILLA」を展開 • 即日配送サービス • ギフトラッピングサービス • ツケ払い など
4. © ZOZO, Inc. 株式会社ZOZO 基幹システム本部 物流開発部 基幹リプレイスブロック ブロック長 矢部 佑磨 2019年6月入社。 入社後約3年間は基幹システムの開発・運用を担当の後 2022年頃から基幹システムのリプレイスプロジェクトに 従事。 4
5. © ZOZO, Inc. 5 アジェンダ 前半 • アーキテクチャの模索 • 機能等価リプレイスの罠 • 価値創造への転換 • 今まさに変革の途中 後半 • 背景：レガシースタックの限界 • 課題：ステートフル／データベース構造の複雑さ • 解決アプローチ：ステートレス化／判断基準 • 事例：コアサービス・発送サービス・会計サービス
6. © ZOZO, Inc. 6 6 ZOZOの基幹システム • VBScriptで構築 • 20年間機能継ぎ足し • 巨大なモノリス　 • テストコードなし • 影響範囲が追えない • VBScriptのサポート切れが視野に • 保守・拡張が困難 • 改修コストが高騰 • 技術的負債の蓄積 リプレイス前 リプレイスの背景
7. © ZOZO, Inc. 7 7 巨大モノリスの課題と戦略 Before After 在庫 セール 商品 CS 発送 入荷 会計 クーポン 注文 ポイント 予約 レポート すべてが一体化 まずは物流を切り離す それぞれ独立したサービスに 在庫 セール 商品 CS 会計 クーポン 注文 ポイント 予約 レポート 発送 入荷
8. © ZOZO, Inc. 8 8 第１の挑戦：発送領域のマイクロサービス化 • トランザクション境界が明確 • 他ドメインとの結合度が低い • 有識者内で事前に分割可能と 判断 • 想定通り分離に成功 • クラウド環境へ移行 • 独立したデプロイが可能に 見立て 結果 成功体験を得た 詳細はTECH BLOG「【イベントレポート】「ZOZO物流システムリプレイスの旅〜序章〜これまでとこれから」を開催しました！ 」を参照
9. © ZOZO, Inc. 9 9 第２の挑戦：入荷領域のマイクロサービス化 • 発送と同様に分離できるはず • 成功すれば物流のメイン作業 がモノリスDBの単一障害点か ら分離 • 更新が結果整合性を許容で きない • 別ドメインへの参照もリア ルタイム性が重要 狙い 直面した課題 検討段階でマイクロサービス化を断念
10. © ZOZO, Inc. 10 10 学び：段階的アプローチへ いきなりマイクロサービス化するのはかなりリスクが高い まずモジュラーモノリスで徐々にドメイン境界を探す 境界が見つかったらマイクロサービス化へ移行 モノリス モジュラーモノリス マイクロサービス Must Nice To Have Nice To Have
11. © ZOZO, Inc. 11 11 機能等価リプレイスを選択 • オニオンアーキテクチャ導入 • テストコード • CI/CD • … ※言語変更だけでも価値がある • 既存機能を等価で移行 • コードフリーズで集中 • テスト工数削減のため本番環境で の等加性検証の仕組みを構築 メリット 方針 機能等価リプレイスだけでも価値があると考えた VBScript→Javaへ機能は等価で言語変更する 詳細はTECH BLOG「本番環境における等価比較を活用した言語リプレイス 」を参照
12. © ZOZO, Inc. 12 12 罠①：設計文化の不在 ⚫既存がVBScript ・クラス設計なし、トランザクションスクリプト で手続き的に記述 ・設計の概念がほぼ存在しない ⚫伝え方の問題 ・Java／WebAPI開発の経験がないメンバーに教 える際、伝え方として手順が前面に出てしまった 結果として「とりあえずJavaに書き変えれば良 い」という理解に ⚫コードフリーズの副作用 ・「早くリプレイスを終えることこそが正 義」という大義名分 品質よりもスピード重視の風潮
13. © ZOZO, Inc. 13 13 罠②：巨大すぎるシステム • 事業部の依頼は何とか実現した いという文化から機能は増加の 一途 • 売り上げに貢献しているかわから ない • そもそも使用されているかもわか らない機能が複数存在 機能の増加 不明瞭な機能価値 巨大なシステムを作り直すだけではまた同じ問題が起きる 等価でリプレイスしても終わらない
14. © ZOZO, Inc. 14 14 重要な気づき このままではリプレイスが 技術負債の一部返済だけで 終わってしまう
15. © ZOZO, Inc. 15 15 転換：価値創造の機会に リプレイスを価値創造の機会に変える 単なる言語変更ではなく、システムと組織を変革する契機とする 設計 技術負債を 根本から解消 機能整理 価値ある領域に 集中 組織 文化と理解を 変える 設計✕ 機能整理✕ 組織＝付加価値
16. © ZOZO, Inc. 16 16 設計の重要性 • オニオンアーキテクチャ • ドメイン分離 • 単一責任の原則 • etc... • 影響範囲が局所化 • 改修コストが削減 • 長期的な保守性向上 • 結果的に開発速度も向上 導入した設計 設計がもたらす効果 設計の重要性を理解してもらう 偶発的な技術負債は設計不足から
17. © ZOZO, Inc. 17 17 機能整理のベースの考え方 出典：『ドメイン駆動設計をはじめよう - ソフトウェアの実装と事業戦略を結びつける実践技法』 （Vlad Khononov　著、増田 亨、綿引 琢磨　訳） 機能整理の第一ステップとして 基幹システムの各機能を左記4つに分類
18. © ZOZO, Inc. 18 18 リプレイス優先度 ①中核 最優先。設計リソースと時間を最大限投資 ②一般 購入・模倣を検討。中核の次に方針決定 ③補完 必須だがロジックが簡素なため優先度低 ④一般または補完 判断を保留。外部調達を模索 下記順番でリプレイスに着手
20. © ZOZO, Inc. 20 20 組織の理解 • 綺麗な設計が長期的には保守性 を高め、改修を早くすることを 理解してもらう • ミニマムなシステムを目指すこと が、結果的に開発速度を上げるこ とを納得してもらう • リプレイス後も定量的な評価のも と不要な機能は削除する文化を作 る 設計の重要性 機能削減の必要性 ”プログラミングにおいて、コードは資産ではなく負債なのです。 そのため、コードベースが大きくなると、より多くの潜在的なバグを抱えることになりま す。” 出典：『単体テストの考え方/使い方 プロジェクトの持続可能な成長を実現するための戦略』 （Vladimir Khorikov　著、須田智之　訳）
21. © ZOZO, Inc. 21 21 今まさに変革の途中 対話を通じて文化を変えようとしている 設計品質・機能削減の重要性を理解してもらう 取り組みは続いている 他開発本部も参加して境界を探している 改めてドメイン境界をマイクロサービス化のメリットを模索中 試行錯誤を続けている 判断を誤ることもあるが、学び、軌道修正し、前進している これは完成された成功事例ではありません。
22. © ZOZO, Inc. 22 22 まとめ 1.等価リプレイスでも設計品質 は必要 「とりあえず変換する」では長 期的な保守性は得られない 3.組織の理解が最重要 設計品質・機能整理の重要性を 対話を通じて理解してもらう 4.リプレイスを価値創造の機会に 技術だけでなく課題を抱えた組織 文化なども併せて変革する 2.機能整理で最小限のシステムに 利用頻度を定量化し、価値ある機 能に集中する
23. © ZOZO, Inc. 23 後半：インフラ観点
24. © ZOZO, Inc. 株式会社ZOZO EC基盤開発本部 SRE部 基幹プラットフォームSREブロック テックリード 杉山 弘二 2007年よりフリーランスとして多数の受託開発に従事。 2017年に株式会社スタートトゥデイ工務店（現ZOZO）へ入社。ZOZOTOWNのリプレ イス、Javaへの言語モダン化、マルチクラウド対応、オンプレ/AWSのハイブリッド 化、Sessionオフロードなど、数多くのプロジェクトに携わる。 現在はSRE部門のテックリードとして、インフラ設計、アーキテクチャ設計、PoCなどを 中心に担当。 趣味で独自開発したiOSアプリを全世界に向けて配信中。 24
25. © ZOZO, Inc. 25 後半アジェンダ（再掲） • 背景：レガシースタックの限界 • 課題：ステートフル／データベース構造の複雑さ • 解決アプローチ：ステートレス化／判断基準 • 事例：コアサービス・発送サービス・会計サービス • まとめ
26. © ZOZO, Inc. 26 巨大モノリスの現実 ─ リプレイスの背景
27. © ZOZO, Inc. 27 背景：レガシースタックの限界 • Classic ASP（VBScript） / IIS ◦ VBScriptの廃止が迫っている • 保守性・拡張性の限界 ◦ オンプレリソースは有限 ◦ 拠点別サーバの拡張の限界 2027 デフォルトで無効 2024 FODで残存 20xx 完全削除 2025 現在位置 ※ EOLタイムライン（補足）
28. © ZOZO, Inc. 28 理想と現実 ─ リプレイスが直面した2つの課題
29. © ZOZO, Inc. 29 リプレイスが直面した2つの課題 課題①：ステートフル構成 課題②：データベース構造の複雑さ
30. © ZOZO, Inc. 30 課題①：ステートフル構成 • 現状：サーバー内で保持している「IISセッション管理」および「作業用データファイル」に依存 ◦ セッションやファイルがローカルにあり、スケールアウトやKubernetes移行が困難 ◦ クラウドネイティブ環境ではステートレスが基本、段階的リプレースも難しい構成 セッションやローカルのファイルは、サーバーごとに別々
31. © ZOZO, Inc. 31 課題②：データベースの複雑さ • 複数ドメインが複数テーブルを共用 ◦ 業務ドメイン関係なくスパゲッティ状態 • トランザクション依存が強い ◦ テーブルをまたがるトランザクション多数 • ドメイン分離に苦戦 ◦ 特定データベースに様々なテーブルが集まり 共用化されている ◦ ドメイン分離が容易ではない ◦ すぐに変えられない ◦ マイクロサービス化への壁となっている
32. © ZOZO, Inc. 32 解決アプローチ ─ ステートレス化と分離判断
33. © ZOZO, Inc. 33 解決の方向性 方向性①：ステートレス化 方向性②：分離判断の基準を作る
34. © ZOZO, Inc. 34 解決アプローチ • 課題①：ステートフル構成 ◦ アプローチ：ステートレス化 ▪ IISセッションを独自ライブラリでRedisにオフロード • 全Webサーバーのセッションを集中管理 ▪ サーバー内データファイルをFileServer／FSxに外出し • ネットワークマウントによりステートレス化
35. © ZOZO, Inc. 35 解決アプローチ • セッションおよび作業データファイルを「Redis／外部ストレージ」へオフロード ◦ アプリケーションをステートレス化し、段階的移行でもセッション維持を可能に ◦ ロードバランシング対応とKubernetes運用を見据えたステートレス構成へ Kubernetes Icons © Kubernetes Authors. Licensed under Apache-2.0 or CC-BY-4.0. Kubernetes は The Linux Foundation の登録商標です。
36. © ZOZO, Inc. 36 ステートレス化後のフロントアーキテクチャ（予定） • Kubernetes基盤上で、Ingress＋Istioによりストラングラーパターンを構築 ◦ 既存システムとの共存を保ちながら段階的に置き換えを実施 ◦ 機能ごとにパスルーティングで切り替え Kubernetes Icons © Kubernetes Authors. Licensed under Apache-2.0 or CC-BY-4.0. Kubernetes は The Linux Foundation の登録商標です。
37. © ZOZO, Inc. 37 フロントは現在設計中 • フロント領域は現在設計中 ◦ マイクロフロントエンド構想を含めた再設計を進行中 Kubernetes Icons © Kubernetes Authors. Licensed under Apache-2.0 or CC-BY-4.0. Kubernetes は The Linux Foundation の登録商標です。
38. © ZOZO, Inc. 38 解決アプローチ • 課題②：データベース構造の複雑さ ◦ アプローチ：分離判断の基準を作る ▪ 業務ドメインに基づいてコンテキスト境界を定義 ▪ 結合度が高く分離が難しい領域はモノリス（core-service）で集約 • トランザクション整合性を維持してサービス化 ▪ 分離できる領域はマイクロサービス化
39. © ZOZO, Inc. 39 判断基準：モノリス vs マイクロサービス サービス分割時の４つの判断観点 判断観点 モノリス（core-service） マイクロサービス トランザクション結合度 結合が強い領域を集約 結合が弱く独立可能な領域を分離 データ量／整合性要求 大量データ・強整合性が必要な領域を管理 最終整合でも問題ない領域を分離 アーキテクチャ独立性／技術要件 共通基盤で運用する構成 独自アーキテクチャを採用する領域 ドメイン境界の分離難易度 分離難易度が高い領域。当面はモノリスで 集約し、境界整理後に段階的に切り出し 分離容易な領域から段階的に マイクロサービス化
40. © ZOZO, Inc. 40 3つの実践事例 ─ ドメイン特性に応じたアーキテクチャ選択
41. © ZOZO, Inc. 41 ドメイン特性に応じたアーキテクチャ選択 事例①：コアサービス（モノリス） 事例②：発送サービス（マイクロサービス） 事例③：会計サービス（マイクロサービス）
42. © ZOZO, Inc. 42 事例① コアサービス（モノリス） 図が入る “密結合なDBアクセスを共通APIに集約”──整合性を保ちながら技術基盤をモダナイズ • VBScriptから直接行っていたDB呼び出しを、共通API（core-service）に切り出し共通化 • トランザクション整合性が求められる領域をAPIに集約、基幹DBアクセスを一元管理 • フロントリプレイスでは、BFFから API を呼び出す予定 Kubernetes Icons © Kubernetes Authors. Licensed under Apache-2.0 or CC-BY-4.0. Kubernetes は The Linux Foundation の登録商標です。
43. © ZOZO, Inc. 図が入る 43 事例② 発送サービス（マイクロサービス） “発送は止められない” ─ だからDBを分離し、イベント駆動に • SQSメッセージングとDebezium（アウトボックス）で安全なイベント連携を実現 • イベント駆動アーキテクチャで疎結合化と独立処理を実現 • 基幹DB障害の影響を最小化し「止まらない発送システム」を実現 Kubernetes Icons © Kubernetes Authors. Licensed under Apache-2.0 or CC-BY-4.0. Kubernetes は The Linux Foundation の登録商標です。
44. © ZOZO, Inc. 図が入る 44 事例③ 会計サービス（マイクロサービス） “すべての取引を再現できる” ─ イベントソーシングによる売上と入金のマッチング • イベントを時系列で蓄積。すべての取引履歴を記録し、再計算・監査に対応 • イベントソーシングのフレームワークであるSpringのAxon Frameworkを採用 Kubernetes Icons © Kubernetes Authors. Licensed under Apache-2.0 or CC-BY-4.0. Kubernetes は The Linux Foundation の登録商標です。
45. © ZOZO, Inc. 45 まとめ
46. © ZOZO, Inc. 46 まとめ 巨大モノリスの再構築戦略でやったこと • ステートレス化で、フロントリプレイスを進めるための土台を整備 ◦ Kubernetes移行・ストラングラーパターンによる段階的移行を実現可能に • ドメイン特性を踏まえた構成選定 ◦ 結合度が高い領域はモノリス（core-service）に集約し、トランザクション整合性を維持 ◦ 独立性が高い領域はマイクロサービス化、特性に適したアーキテクチャを採用 すべてを一律にマイクロサービス化するのではなく、ドメイン特性を踏まえて 見極める
47. © ZOZO, Inc. 47 モノリスとマイクロサービスを 適材適所で使い分ける これが、モノリスを現実的に再構築するための 基幹リプレイスの“ハイブリッド戦略”です