モノリスからの脱却に向けた
 物流システムリプレイスの概要紹介
 株式会社ZOZO
 基幹システム本部 物流開発部 基幹リプレイスブロック
 ブロック長
 矢部 佑磨 Copyright © ZOZO, Inc. 1

© ZOZO, Inc. 株式会社ZOZO
 基幹システム本部 物流開発部 基幹リプレイスブロック
 ブロック長 矢部 佑磨
 2019年6月入社。
 入社後約3年間は基幹システムの開発・運用を担当の後
 2022年頃から基幹システムのリプレイスプロジェクトのマネ ジメントに従事。
 趣味は格闘技観戦。
 2

© ZOZO, Inc. 3 アジェンダ 1. リプレイスの目的 2. リプレイスの工程 3. ドメイン駆動設計導入理由と振り返り 4. リプレイス後のインフラ構成 5. まとめ

© ZOZO, Inc. 4 前提

© ZOZO, Inc. 5 前提 物流システムリプレイスに関してはTECH BLOGを公開しています。 リプレイスの全体の流れなどはTECH BLOGに記載していますので、そちらをご参照ください。 ここではTECH BLOGで拾えていないことの説明や技術選定、簡単な振り返りに注力します。 TECH BLOG モノリスからマイクロサービスへ-ZOZOBASEを支える発送システムリプレイスの取り組み

© ZOZO, Inc. 6 1.リプレイスの目的

© ZOZO, Inc. 7 リプレイスの目的 ● 課題 ○ 基幹システムはモノリスのためどこかに障害が起きるとすべてが止まる可能性がある(SPOF) ○ システムの規模が大きく複雑なドメインロジックのため開発コストが高い ○ ドメインロジックを共通化する仕組みがなく、類似ロジックが点在している(低凝集) ○ 手動デプロイのためデプロイコストが高くヒューマンエラーが発生しやすい ○ レガシー技術を採用しているため解決選択肢が少なく、エンジニアの採用も難しい

© ZOZO, Inc. 8 リプレイスの目的 ● 解決策 ○ 基幹システムを境界づけられたコンテキスト毎に分離しマイクロサービス化する ○ レイヤードアーキテクチャを導入する ○ CI/CDパイプラインを構築する ○ 全社ガイドラインに沿った(≒デファクトスタンダード)技術を採用する

© ZOZO, Inc. 9 リプレイスの目的 ● このリプレイスでは目指さないこと ○ ビッグバン・リリースはしない ■ 一般的にビッグバン・リリースはアンチパターンでありリプレイスのリスクを少しでも低減させられる手法を取る ○ Sagaパターンなどの分散トランザクションはしない ■ 便利ではある学習コストが非常に高いため分散トランザクションを採用せずに済む手法を取る ○ 大幅な仕様変更や機能追加は入れない ■ プロジェクトが大きくなりすぎて収束しなくなることを防ぐため基本的に既存システムと同等の機能を提供する(一部例 外あり) ○ すべての機能をマイクロサービス化しようとはしない ■ 結合度が高い多数のテーブルが存在するため無理にマイクロサービス化しようとせず、モノリスとしてオンプレに残る 機能やデータも許容する

© ZOZO, Inc. 10 2.リプレイスの工程

© ZOZO, Inc. 11 リプレイスの工程 ● リプレイスするにあたり取り組んだこと ○ コンテキストの洗い出し(コンテキストマップの簡易版)、リプレイス対象の決定 ■ 主要な機能とデータを洗い出しコンテキストを整理し、メリットや容易さの観点から対象を選定 ○ 業務フローの整理 ■ 現場、開発者の両方の目線から業務を整理することで考慮漏れを防ぎ、参加者の業務知識レベル差を縮小 し、整理の中でユビキタス言語も整備する ○ 大まかなデータフローとインフラ構成を検討 ■ データの流れや他サービスとの連携などどのような構成にすればリプレイス可能か検討する ■ モデリング後にインフラ構成として実現不可となり大幅な後戻りとなることを防ぐ ○ モデリング ■ 松岡幸一郎さんの提唱するsudoモデリングに沿ってドメインエキスパートとモデリング実施 ○ インフラ設計 ■ 具体的にどのAWSサービスを採用するのか、どのような形で他サービスと連携するのか詳細な構成を図示す る ○ 実装 ■ モデリングした内容をコードに落とし込む

© ZOZO, Inc. 12 リプレイスの工程 業務フロー整理 モデリング インフラ設計 実装 インフラ構成を検討していく中でモ デリングにも多少チューニングが 入ることは許容する コンテキストの洗い出し 大まかなインフラ設計 ホワイトボードツールを用いながら関 係者を集めたMTGでラフに図示して いく

© ZOZO, Inc. 13 リプレイスの工程 ● リプレイスに着手するために超えてきた障壁 ○ 技術習得は？ ■ ログ機能など小さなところをリプレイスを試みて知見を溜める ■ 社内で同様の技術の採用実績のあるチームに協力してもらう ○ 人員確保は？ ■ 社内エンジニアの育成とリプレイスエンジニアの中途採用の両輪 ○ 現行システム開発案件との兼ね合いは？ ■ リプレイス専任チームを立ち上げ既存システムの開発とリプレイスを並列化 ■ 基本方針としては既存システムの開発も極力止めない ■ 既存システム開発でリプレイスに大きく影響があるものは一時凍結できないか都度議論 ○ 現場の人の理解はどう得る？ ■ 仕様は変えない方針としたためUIを改善することでリプレイスにメリットを感じてもらう ■ 発送サービスが止まらない、中長期的な開発スピードアップを提示

© ZOZO, Inc. 14 3.ドメイン駆動設計導入の理由と振り返り

© ZOZO, Inc. 15 ドメイン駆動設計導入の理由と振り返り ● ドメイン駆動設計を導入した理由 ○ ZOZOでは物流システムを自前で構築しているため複雑で膨大なドメインロジックがある ○ ドメイン駆動設計の学習コストを鑑みても取り入れた方が総合的な開発コストは下がると判断 ○ 社内でドメイン駆動設計を取り入れたチームがあるため実績があるため協力を得ることもできる

© ZOZO, Inc. 16 ドメイン駆動設計導入の理由と振り返り ● ドメイン駆動設計を導入した振り返り ○ 本当にドメイン駆動設計になっているのか？ ■ 単純なオブジェクト指向との差としては開発の目的や設計の視点にあると考えている。 ■ 複雑なビジネスドメインを解決することに重きを置き、それをコードで表現するという工程を踏み、またコンテキ ストやユビキタス言語を意識しているためドメイン駆動設計なのだと思っている。 ○ ドメイン駆動設計を導入したメリットはあったのか？ ■ ビジネスドメインを紐解き重要なことをコードで表現できたため、既存よりも大幅に読み易くすることができた。 ■ これからさらに規模が大きくなってみないとわからない部分はあるが、現時点では学習コストを払うだけのメ リットがあったと感じている。 ○ ドメイン駆動設計を部署内へ周知するために取り組んだことは？ ■ 正直まだまだこれからの部分が多いが、書籍を読んだ内容を要約し社内wikiに整理したり、リプレイス設計 MTGの中で徐々に他チームへ展開していっている。

© ZOZO, Inc. 17 4.リプレイス後のインフラ構成

© ZOZO, Inc. 18 リプレイス後のインフラ構成 ● リプレイス後のインフラ構成全体図 ○ インフラ構成としてオンプレとマイクロサービスの連携は下記の図のようになっている。 ○ この図の詳細についてはTECH BLOGの「発送システムリプレイス」の章を参照。

© ZOZO, Inc. 19 リプレイス後のインフラ構成 ● Change Data Captcha(CDC)について ○ マイクロサービス間のデータ連携方法は複数あるが、今回のリプレイスではoutboxパターンを採用した ○ outboxパターンを実現するインフラ構成を検討する上でどのような技術選定を行ったのか共有する

© ZOZO, Inc. 20 リプレイス後のインフラ構成 ● Change Data Captcha(CDC)導入にあたり検討したインフラ構成 ○ ダブルライト ■ Aurora MySQL × SQL Server(OnPremise) ● 不採用 ■ Aurora MySQL × Kinesis Data Streams ● 不採用 ○ CDC ■ Aurora MySQL × AWS Database Migration Server × Kinesis Data Strems ● 不採用 ■ Aurora MySQL × Amazon DynamoDB × Kinesis Data Streams ● 不採用 ■ Aurora MySQL × Debezuin × Amazon Managed Stream for Apache Kafka ● 採用

© ZOZO, Inc. 21 リプレイス後のインフラ構成 マイクロサービス側がオンプレDBの影響をダイレクトに受け、リプレイスの主目的に置いていたオンプレDBが止まっても発送業務 が続けられるという点が危ぶまれるため不採用とした。

© ZOZO, Inc. 22 リプレイス後のインフラ構成 CDCのような構成を自前で組む必要があり、外部サービスを取り入れた方が安全性、安定性が高いと判断し不採用とした。

© ZOZO, Inc. 23 リプレイス後のインフラ構成 構成としては実現可能だが、AWS DMSはオンプレからクラウドへのマイグレーションなど一時的な利用を想定しているため長期利 用に対する不安要素が多く不採用とした。

© ZOZO, Inc. 24 リプレイス後のインフラ構成 コマンドとクエリでDBを分けることによる管理コスト増加と分割によるコマンドからクエリ側への同期ラグの懸念から不採用とした。

© ZOZO, Inc. 25 リプレイス後のインフラ構成 社内に導入実績はなかったが、Aurora MySQLからKafkaへのストリーミングをマネージドで行うことができ、管理コスト・実装コスト の面から見てもバランスが取れており要件を満たせていたため導入を決定した。

© ZOZO, Inc. 26 5.まとめ

© ZOZO, Inc. 27 まとめ 開発メンバーの技術力向上は図りたかったが、学習コストを上げ過ぎるべきではないとも考えていた。 Debezium×Kafkaでのoutboxパターンやドメイン駆動設計の導入など比較的学習コストが高い技術も採用することとなった が、sagaパターンの非採用など最低限のラインは守れたため実現したいことから考えれば悪くない技術選定だったと思って いる。 マイクロサービス化にしてもドメイン駆動設計にしても20年近く蓄積されてきたシステムを置き換えるため書籍などで学習し た一般解では解決できなかったことが多かった。 そのため自分たちなりの解を出すことでしか前に進まないことを改めて感じた。 まだ本運用が始まっていないため解になっているのかは分からないが、正解にしていく努力をしつつ 間違っていると感じたら勇気を持って方向転換することが重要だと考えている。 今回はソースコードを紹介できなかったが、Kafkaコンシューマーの実装やGradleでのマルチプロジェクト管理など紹介でき ることはまだまだあるので今後何らかの媒体で共有していく。

No content