Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
一歩ずつ成長しながら進める ZOZOの基幹システムリプレイス/Growing Stap by ...
Search
takumi.okamoto
March 11, 2025
Technology
2
170
一歩ずつ成長しながら進める ZOZOの基幹システムリプレイス/Growing Stap by Stap ZOZO BackOffice System Replacement
ファインディ株式会社が主催した「アーキテクチャ選定の事例と学び ~モノリス、マイクロサービス、モジュラーモノリスの共生と最適化~」というイベントでの発表スライドです。
takumi.okamoto
March 11, 2025
Tweet
Share
More Decks by takumi.okamoto
See All by takumi.okamoto
ZOZO基幹システムリプレイス ハイライト(2025年3月版) / zozo-backoffice-system-replacement-highlight-202503
cocet33000
0
12
ZOZO基幹システムリプレイスの歩み ~マイクロサービス?モジュラモノリス?~ / ZOZO BackOffice System Replacement Project History
cocet33000
1
330
Other Decks in Technology
See All in Technology
目標と時間軸 〜ベイビーステップでケイパビリティを高めよう〜
kakehashi
PRO
8
1.1k
OSSの実装を参考にBedrockエージェントを作る
moritalous
2
330
“常に進化する”開発現場へ! SHIFTが語るアジャイルQAの未来/20250306 Yuma Murase
shift_evolve
0
160
RaspberryPi CM4(CM5も)面白いぞ!
nonnoise
1
260
QAエンジニアが スクラムマスターをすると いいなぁと思った話
____rina____
0
230
AWSアカウントのセキュリティ自動化、どこまで進める? 最適な設計と実践ポイント
yuobayashi
7
2k
エンジニア主導の企画立案を可能にする組織とは?
recruitengineers
PRO
1
350
DevinでAI AWSエンジニア製造計画 序章 〜CDKを添えて〜/devin-load-to-aws-engineer
tomoki10
0
260
入門 PEAK Threat Hunting @SECCON
odorusatoshi
0
190
人生を左右する「即答」のススメ: 一瞬の判断を間違えないためにするべきこと
takasyou
9
1.1k
完璧を捨てろ! “攻め”のQAがもたらすスピードと革新/20250306 Hiroki Hachisuka
shift_evolve
0
170
AWSではじめる Web APIテスト実践ガイド / A practical guide to testing Web APIs on AWS
yokawasa
8
830
Featured
See All Featured
Art, The Web, and Tiny UX
lynnandtonic
298
20k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Testing 201, or: Great Expectations
jmmastey
42
7.2k
We Have a Design System, Now What?
morganepeng
51
7.4k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
30
4.6k
Java REST API Framework Comparison - PWX 2021
mraible
29
8.4k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
46
2.4k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
A better future with KSS
kneath
238
17k
StorybookのUI Testing Handbookを読んだ
zakiyama
28
5.5k
It's Worth the Effort
3n
184
28k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Transcript
一歩ずつ成長しながら進める ZOZOの基幹システムリプレイス アーキテクチャ選定の事例と学び ~モノリス、マイクロサービス、モジュラーモノリスの共生と最適化~ 株式会社ZOZO 基幹システム本部 物流開発部 基幹リプレイスブロック 岡本拓実・作田航平
Copyright © ZOZO, Inc. 1
© ZOZO, Inc. 株式会社ZOZO 基幹システム本部 物流開発部 基幹リプレイスブロック 岡本 拓実 2020年4月に株式会社ZOZOに新卒入社
レガシー環境での開発・運用を経て 現在はリプレイスプロジェクトに従事 趣味は不要不急の買い物で散財すること 2
© ZOZO, Inc. 3 これから話すこと • 本日のテーマ「モノリス・モジュラーモノリス・マイクロサービス」 を独自の視点で整理してみる。 • ZOZOの基幹システムリプレイスの事例を紹介する。
◦ 事例①: 大きな泥団子からモジュラーモノリスへ ◦ 事例②: 大きな泥団子からマイクロサービスに切り出す
© ZOZO, Inc. 4 モノリス モジュラーモノリス マイクロサービス を整理する
© ZOZO, Inc. 5
© ZOZO, Inc. 6 アーキテクチャ選定の文脈で モノリス・マイクロサービス・モジュラーモノリスが並ぶ
© ZOZO, Inc. 7 並列に並んでいるがそもそもモジュラーモノリスってモノリスのサブセットでは?
© ZOZO, Inc. 8 「うまくいっているか?」でモノリス※1 を考えてみる モジュラー モノリス 戦略的 モノリス※2
うまく いっている 大きな泥団子 不健康な モジュラーモノリス※2 うまく いっていない モジュール化 しない モジュール化 する ※1 単一プロセスとしてデプロイされているシステム。※2 本発表のために独自に定義した用語。
© ZOZO, Inc. 9 「うまくいっているか?」でモノリス※1 を考えてみる モジュラー モノリス 戦略的 モノリス※2
大きな泥団子 不健康な モジュラーモノリス※2 モジュール化 しない モジュール化 する ※1 単一プロセスとしてデプロイされているシステム。※2 本発表のために独自に定義した用語。 うまく いっている うまく いっていない 目指すべき選択肢 アンチパターン
© ZOZO, Inc. 10 モジュラーモノリス 「うまくいっている」ケース 戦略的モノリス 小規模/スピード感を重視 /モジュール境界が変わりやすい モジュール境界がある程度
安定している 多くの組織にとって、モジュラー モノリスは優れた選択肢となる。 Shopifyの例※が有名。 大きな泥団子 不健康な モジュラーモノリス スタートアップにとってモノリス は良い選択肢 ※ Deconstructing the Monolith (Shopify Unite Track 2019) https://bit.ly/2oauZ29
© ZOZO, Inc. 11 モジュラーモノリス 「うまくいっていない」要因に応じて解決策を選ぶ 戦略的モノリス 大きな泥団子 不健康なモジュラーモノリス 時期尚早
設計ミス モノリス の限界 分散 システム etc
© ZOZO, Inc. 分散システム モノリス 12 弱い モジュール化 モノリス・モジュラーモノリス・マイクロサービス うまく
いっている うまく いっていない 強い 大きな泥団子 不健康な モジュラー モノリス 戦略的 モノリス モジュラー モノリス 物理的に分離 ※イベントの主題に合わせて作成。マイクロサービスが分散システムにおける唯一の選択肢ではない。 分散モノリス マイクロ サービス※
© ZOZO, Inc. モノリス 分散システム 13 弱い モジュール化 モノリス・モジュラーモノリス・マイクロサービス うまく
いっている うまく いっていない 強い 大きな泥団子 不健康な モジュラー モノリス 戦略的 モノリス 分散モノリス モジュラー モノリス マイクロ サービス※ 物理的に分離 ※イベントの主題に合わせて作成。マイクロサービスが分散システムにおける唯一の選択肢ではない。 分散システムにかかるコスト
© ZOZO, Inc. 14 まとめ • モノリス、モジュラーモノリス、マイクロサービスを「モジュール化 の強弱」と「うまくいっているか?」の2軸であえて単純に捉えてみ るのも役立つ(かも)。 •
「うまくいっていない」の原因を特定して、コストに見合うのであれ ば、解決するための変化を選ぶべき。 ◦ コストを完璧に予想できない。変更の副作用で、うまくいっていた部分がうま くいかなくなることもある。これが本当の難しさ。 • 「うまくいっている」のであればそれが一番。変える必要はない。 • ずっと「うまくいっている」は不可能。「うまくいっている」期間を 最長化するのがアーキテクチャ選定の目指すところ。
© ZOZO, Inc. 15 ZOZOの基幹システム リプレイスの事例
© ZOZO, Inc. 16 • 2004年からZOZOTOWNの成長と共に、大きなアーキテクチャ変更なく成長してきた。 • VBScriptという2025年においてはレガシーな言語製のWebアプリケーション。 • 論理分割もない単一のデータベースに接続するモノリシックな構成。
• トランザクションスクリプト形式でドメインモデルは存在しない。 ZOZOの基幹システム リプレイス前夜 ZOZOの社員やZOZOTOWN出店者様が利用するバックオフィス業務のためのシステム全般 大きな泥団子 発送準 備 発送 在庫 注文 会計 商品 セール クーポン 分析 委託返却 コスメ マスター 権限 入荷 顧客 抽選 レポート 返金
© ZOZO, Inc. 17 どこが「うまくいっていない」のか? 現状はうまくいっていない、大きな泥団子 • 開発生産性の低下 ◦ 技術のレガシー化(VBScriptのサポート終了も迫る)
◦ 影響範囲がわかりづらく調査時間とリリース後の不具合発見も増加 ◦ 自動テストが存在せず、大規模なリファクタリングの実施はほとんど博打 ◦ 改修する度に変更容易性と開発体験が悪化しがち(良くて現状維持) • 障害リスクの増大 ◦ DBが単一障害点でありDBのパフォーマンスが全ての機能に影響 ◦ 慢性的に発生するエラーや手動クエリ実行による補正が常態化
© ZOZO, Inc. 株式会社ZOZO 基幹システム本部 物流開発部 基幹リプレイスブロック 作田 航平 2022年に株式会社ZOZOに新卒入社。
現在は、物流システムのリプレイスに従事。 趣味は、旅行、漫画、フットサル。 18
© ZOZO, Inc. 19 事例① 大きな泥団子からモジュラーモノリスへ
© ZOZO, Inc. モノリス 分散システム 20 弱い モジュール化 事例①の方針: 大きな泥団子からモジュラーモノリスへ
うまく いっている うまく いっていない 強い 大きな泥団子 不健康な モジュラー モノリス 分散モノリス 戦略的 モノリス モジュラー モノリス マイクロ サービス コンテキスト境界の発見と分割 技術刷新
© ZOZO, Inc. 21 (現場に向き合い続けた歴史が自然と形作った)境界の発見 • DBの全テーブルの依存関係を整理したり、イベントストーミングを開 催したり、様々な観点から分析し、議論を重ねて、参加者全員が「こ こだ」とある程度、納得できるコンテキスト境界を見つけた。 •
これは長年の組織改編でも変わることがなかった自然な分割境界。 • 基幹システムのエンジニア組織は現場の知識を重視し、現場に寄り添 い価値を最大化するために組織の形を変えてきた。自然と逆コンウェ イ戦略が取れていたとも解釈できる。 • 良くも悪くもこれまでの地続き。未来予想からの逆算はできていない 感覚もあるが、これが現実的でベストの選択だと考えている。
© ZOZO, Inc. 22 大きな泥団子 発送準 備 発送準備 在庫 注文
会計 商品 ピック クーポン 分析 委託返却 コスメ マスター 権限 棚入れ 顧客 抽選 レポート 返金 モジュラーモノリス 入荷 発送 販売管理 顧客サポート 荷受け 検品 「境界づけられたコンテキスト」ごとにモジュールを作成。 宙に浮いてしまった機能は暫定的に「その他」にまとめる。 モジュラーモノリス基盤を新規作成する モノリス その他
© ZOZO, Inc. 23 大きな泥団子 発送準 備 発送準備 在庫 注文
会計 商品 ピック クーポン 分析 委託返却 コスメ マスター 権限 棚入れ 顧客 抽選 レポート 返金 モジュラーモノリス 入荷 発送 販売管理 顧客サポート 荷受け 検品 機能単位でモノリスからモジュラーモノリスへ移行し、API として機能を提供する。 機能単位で徐々に移行する モノリス その他 荷受け 棚入れ 返金 発送準備 クーポン DBは変更しない。 トランザクション境界の見直しは後回し。 素早く安全に移行して技術の刷新を実現する。 詳細:本番環境における等価比較を活用した言語リプレイス
© ZOZO, Inc. 24 大きな泥団子 発送準 備 発送準備 在庫 注文
会計 商品 ピック クーポン 分析 委託返却 コスメ マスター 権限 棚入れ 顧客 抽選 レポート 返金 モジュラーモノリス 入荷 発送 販売管理 顧客サポート 荷受け 検品 開発チームは1つの境界づけられたコンテキストと紐づき、 そのうちの1つ以上の機能を担当する。 機能単位で徐々に移行する モノリス その他 荷受け 棚入れ 返金 発送準備 クーポン
© ZOZO, Inc. 25 大きな泥団子 発送準 備 発送準備 在庫 注文
会計 商品 ピック クーポン 分析 委託返却 コスメ マスター 権限 棚入れ 顧客 抽選 レポート 返金 モジュラーモノリス 入荷 発送 販売管理 顧客サポート 荷受け 検品 コンテキスト外部と強い整合性が不要な場合、DBの物理分離 も可能。 機能単位で徐々に移行する モノリス その他 荷受け 棚入れ 返金 発送準備 クーポン
© ZOZO, Inc. 26 大きな泥団子 発送準 備 発送準備 在庫 注文
会計 商品 ピック 分析 委託返却 コスメ マスター 権限 棚入れ 顧客 抽選 レポート 返金 モジュラーモノリス 入荷 発送 販売管理 顧客サポート 荷受け 検品 「うまくいっていない」部分はあるが分割のコストを鑑みて、 暫定的に境界をまたがる概念として残すことにした。 在庫 機能やコンテキスト境界を横断する在庫 モノリス その他 荷受け 棚入れ 返金 発送準備 クーポン クーポン 複数のコンテキストから更新されている。 まずは認知から。
© ZOZO, Inc. モノリス 分散システム 27 弱い モジュール化 (訂正版) 事例①の方針:
うまく いっている うまく いっていない 強い 大きな泥団子 不健康な モジュラー モノリス 分散モノリス 戦略的 モノリス モジュラー モノリス マイクロ サービス 技術スタックの刷新 境界にあった形へ改善 境界の発見
© ZOZO, Inc. 28 事例② 大きな泥団子からマイクロサービスに切り出す
© ZOZO, Inc. モノリス 分散システム 29 弱い モジュール化 障害分離のためにサービスを分割する うまく
いっている うまく いっていない 強い 大きな泥団子 不健康な モジュラー モノリス 分散モノリス 戦略的 モノリス モジュラー モノリス マイクロ サービス DBを分割する・デプロイも独立させる
© ZOZO, Inc. • モノリスからマイクロサービスを切り出す際にはその対象内で強い整合 性(トランザクション)が閉じているか否かでコストが大きく変わる。 • 業務理解の深い人たちが集まって議論した結果、障害分離したい範囲内 で全てのトランザクションが閉じていることを確信できたので移行を決 定した。
30 トランザクション境界を見極めサービス分割に踏み出す 分割コストが高い △ 分割コストが低い ◎
© ZOZO, Inc. 31 大きな泥団子 発送準 備 在庫 注文 会計
商品 ピック 分析 委託返却 コスメ マスター 権限 梱包 顧客 抽選 レポート モジュラーモノリス 発送 検品 発送 非同期メッセージングでサービス間を疎結合にする モノリス 発送準備 ・・・ 発送マイクロ サービス 発送 ピック 梱包 発送完了 発送完了 詳細:モノリスからマイクロサービスへ-ZOZOBASEを支える発送システムリプレイスの取り組み 基幹DB 発送依頼 発送完了etc
© ZOZO, Inc. 32 ZOZOの事例まとめ
© ZOZO, Inc. 33 マイクロ サービス モジュラー モノリス マイクロ サービス
マイクロ サービス 全体としてはマイクロサービス アーキテクチャになっている が、境界づけられたコンテキス トを跨ぐ粒度のモジュラーモノ リスも存在する デプロイを独立したい、障害分 離したいなどの必要な要件がな い限りはサービス分割をしない 我々が(暫定的に)目指しているシステム構造
© ZOZO, Inc. 34 ZOZOの事例 まとめ • ZOZOリプレイス前夜は「開発生産性の低下」「障害リスクの増大」な どの課題を抱えた(うまくいっていない)大きな泥団子だった。 •
「開発生産性の向上」を目指して、定義したコンテキスト境界に沿っ て、モノリスの機能群をモジュラーモノリスへと移行した(している)。 • 「障害リスクの低減」を目指して、モノリスのトランザクション境界を 見極めてマイクロサービス化を行った。
© ZOZO, Inc. モノリス 分散 35 弱い モジュール化 ZOZOの基幹リプレイスの方針 まとめ
うまく いっている うまく いっていない 強い 大きな泥団子 不健康な モジュラー モノリス 分散モノリス 戦略的 モノリス モジュラー モノリス マイクロ サービス
© ZOZO, Inc. 36 最後に • 本発表はZOZOの基幹システムリプレイスの約3年間の歩みを振り返り、 20分で伝わるように綺麗なストーリーに再構成してお届けしました。本 当はもっと紆余曲折ありました。 •
当時は認識できなかったが今なら分かることもたくさんあります。設計 における引き出しも増えました。 • 立ち止まって考え抜くことは大切だが、歩みを進めることも同じくらい 大切だと思います。これからも既存システムに敬意を払いつつ、組織ま るごと成長しながらリプレイスを楽しんで進めていきます。
None