ZOZO基幹システムリプレイスの軌跡 / Trajectory of ZOZO Core System Replacement

Transcript

1. ZOZO基幹システム リプレイスの軌跡 株式会社ZOZO
 基幹システム本部 物流開発部 基幹リプレイスブロック
 ブロック長
 矢部 佑磨 Copyright © ZOZO, Inc. 1
2. © ZOZO, Inc. 株式会社ZOZO 基幹システム本部 物流開発部 基幹リプレイスブロック ブロック長 矢部 佑磨 2019年6月入社。 入社後約3年間は基幹システムの開発・運用を担当の後 2022年頃から基幹システムのリプレイスプロジェクト に従事。 2025年2月に第一子が生まれ親バカ発動中。 2
3. © ZOZO, Inc. 3 基幹システムの抱える課題
4. © ZOZO, Inc. 4 ZOZO基幹システムが抱えている課題 ASPのサポート 終了 設計のレガシー化 基幹DBが重い UIが使いづらい データ補正の 常態化 調査・改修が しづらい テストの品質が バラバラ リリースが手動で 危険が多い スケールしづらい オブザーバビリ ティが不十分 同一ロジックの 分散 ※赤字はリプレイス検討開始当初、特に改善したいと考えていた課題
5. © ZOZO, Inc. 5 リプレイス検討開始
6. © ZOZO, Inc. 6 基幹システムリプレイス タイムライン 2021年 リプレイス 検討開始 2022年8月 発送リプレイス 開始 2023年5月 入荷リプレイ検 討開始 2023年10月 モジュラモノリ ス化開始 2034年頃 VBScriptサポー ト終了 2023年8月 入荷マイクロ サービス化断念 2024年10月 リプレイスエン ジニア育成開始 現在 2031年頃 脱VBScript 完了予定
7. © ZOZO, Inc. 7 検討開始当初のリプレイス想定 検討開始当初はマイクロサービスが相互に連携するマイクロサービスアーキテクチャを理想としていた。 マイクロサービスは銀の弾丸にはならないとわかりつつも、漠然とした期待(憧れ)があった。 基幹 サービス 割引 サービス TOWNコン テンツ サービス 会計 サービス ツール サービス 分析 サービス 外部モール サービス 発送 サービス ID基盤 サービス マイクロサービスアーキテクチャ(クラウド) モノリシックアーキテクチャ(オンプレミス) 基幹システム 発送 在庫 注文 会計 入荷 顧客 商品 セール クーポ ン 分析 委託返 却 抽選 コスメ レポー ト マス ター 返金 権限
8. © ZOZO, Inc. 8 データを基準に分析して現実的な分割境界を模索する すでに存在する大きなトランザクションを分離して、理想の境界を引き直す形でマイクロサービス化を 進めるのは現実的に思えなかった。そこで既存実装のトランザクションにおけるデータ同士の結合を可 視化して整理することで現実的なコストで分割可能な境界を模索した。 （そもそも当時は、イベントストーミングのような、問題空間と改めて向き合って解決空間を再定義す るような有効なアプローチを知らなかったというのもある。） TShipment TShipment Detail TShipment Temp etc... 発送 TStatement TStatement Detail TBarcodeRul e etc... 入荷 TGoods TSaleSettin g TStockShelf etc... 商品 TSalesRepor tDelivery TTaxReport TSalesMatc hing etc... 会計 ... ... ... ... etc
9. © ZOZO, Inc. 9 テーブル基準の境界探しで気づいたこと、決めたこと • データ的には分離コストが低かったとしても、その粒度でマイクロサービスとして独立させるのが 正しいとは限らないと気づいた。 ◦ 自然とできた境界なので何らかの意味はあるはずだが、一般的に適切なマイクロサービス境 界と言われる「境界付けられたコンテキスト」という観点に合致しないこともある。 • 在庫データが多くのドメインを跨いでいるためここを整理することがリプレイスの肝になると気づ いた。 • 発送は基幹におけるコアドメインの1つでもありデータも分離しやすい。尚且つここで分離を行う ことは障害分離という面でもメリットが大きいと気づいた。 ◦ オンプレの基幹DBに障害があったとしても発送作業は継続したい。 分離が難しい箇所のリプレイスに着手し足踏みするよりも 分離コストが低く効果も大きい発送機能のマイクロサービス化を進めて知見と実績を積んでいく と決めた。
10. © ZOZO, Inc. 10 発送リプレイス
11. © ZOZO, Inc. 11 発送リプレイスの進め方 発送機能 • 単数発送 • 複数発送 • 委託返却 • 発送準備 の4つに大別し1つずつJavaでビッグバンリライトする方針とした。 単数発送のリプレイスはすでに完了し運用中で現在は複数発送をリプレイスしている状態だが どのようなインフラ構成になったかというと・・・
12. © ZOZO, Inc. 12 発送マイクロサービスのインフラ構成 詳細は【イベントレポート】 「ZOZO物流システムリプレイス の旅〜序章〜これまでとこれか ら」を開催しました！ をご参照く ださい。
13. © ZOZO, Inc. 13 発送マイクロサービスを作った学び 1. ビッグバンリライトは社内システムであり現場作業者の協力があったからこそ実現できた a. ストラングラーパターンに比べ刻んでリリースできないが初めから最終系を目指せるメリットが ある 2. データを基準に考えた境界ではあったが、有識者が複数人集まり全員良いと判断できたのであればマ イクロサービスとして悪くない境界にできる(かもしれない) a. 再現性がなく、平準化もできないためオススメできないが、一視点として自信や学びにはなった 3. MSKは筋が良く、トランザクションを分割し結果整合性を保つツールとして拡大していけそう 4. 一つ新しいデータを基幹DBから吸い上げるにしても修正アプリケーションが多いため運用コストが上 がった側面がある 5. モノリス(モジュラモノリス含む)の維持が戦略として正しいこともある
14. © ZOZO, Inc. 14 入荷リプレイス
15. © ZOZO, Inc. 15 入荷マイクロサービス化の検討 • 発送をマイクロサービス化した経験をもとに入荷領域もマイクロサービス化することで基幹DB障害 時の損失回避を目指すこととなった。 ◦ 発送と入荷がマイクロサービス化されるとZOZOの競争優位性の1つである物流面を単一障害 点となっている基幹DBから分離することができる • ただ何度考えても参照データのリアルタイム性や基幹DBとの強い整合性を排除できず発送のように データの境界線を見つけられなかった。 • 開発・運用コストを上回るメリットがなかったため入荷のマイクロサービス化は(一旦)断念した。 基幹DB 商品 注文 入荷サービス リアルタイム性の 求められる参照 強い整合性の求められる更新
16. © ZOZO, Inc. 16 入荷リプレイスはどうするのか？ マイクロサービス化しなくてもモノリスのまま整理し、 大まかな境界を引くことで良い塩梅のメリットを享受できるのではないかと気づく 多くの組織にとって、モジュラーモノリスは優れた選択肢となる。 モジュールの境界が明確に定義されていれば、高度で並列な作業が 可能になる。その上、より分散されたマイクロサービスアーキテク チャの課題も回避でき、デプロイもよりシンプルになる。 出典: Sam Newman 著, 島田 浩二 訳 モノリスからマイクロサービスへ ―モノリスを進化させる実践移行ガイド（O'Reilly Japan, Inc）
17. © ZOZO, Inc. 17 基幹システムリプレイス 全体のアーキテクチャ戦略
18. © ZOZO, Inc. 18 基幹リプレイスのアーキテクチャ戦略 モジュラモノリス化はデータ境界がはっきり見えない中で 手探りながら境界を整理していく手法として現状の基幹システムにマッチしていると感じた。 そのためモジュラモノリス化を主方針としマイクロサービス化の開発・運用コスト以上の メリットがあれば必要に応じてマイクロサービス化もする方針とした。 モノリス モジュラモノリス マイクロサービス Must Nice to Have
19. © ZOZO, Inc. 19 基幹システムリプレイス 組織戦略
20. © ZOZO, Inc. 20 組織のスキル状況を踏まえたリプレイス戦略 • 既存のエンジニアの多くはほぼASPとSQLしか書いておらず処理もトランザクションスクリプトに なっている • Javaやオニオンアーキテクチャ、API設計などリプレイスに必要なスキルセットを持っている人が ほとんどいない • そのため一時的に開発スピードは下がるが、長期的にはリプレイススピードアップに寄与すると考 えリプレイスメンバーが基幹システムの他チームに週4時間程度モブプロ形式でリプレイス手順を 教えることとした
21. © ZOZO, Inc. 21 リプレイスメンバーの育成 リプレイススキルを保有しないメンバー リプレイススキルを保有するメンバー モブプロ前 モブプロ後 モブプロ及び自己学習 ※メンバーの数はイメージです
22. © ZOZO, Inc. 22 Java移行のリソース確保 既存の基幹システムが巨大なため言語リプレイスだけでも約7年かかる試算になっています。 またその7年というのも業務委託を大量に導入した上での年数になります。 膨大なタスク量ですが、VBScriptのサポート終了も見えているため最優先事項に置いています。 そしてまだリプレイスにおいてコーディング補助を超える明確な活用法は見出せていませんが、生成AI を活用することで極力業務委託に頼らずともこの年数を減らせるよう検討しています。 社員(設計・レビュー) 業務委託(実装) ChatGPT icon from: https://openai.com/brand/ GitHub Copilot icon from: https://github.com/features/copilot
23. © ZOZO, Inc. 23 まとめ
24. © ZOZO, Inc. 24 競争優位性を生み出す 基幹システム 我々の進む道 リプレイス暫定ゴール (技術負債の解消) 終わりはない、どこまでも続く... 低レイテンシ 良い UI/UX スケーラビリティ 圧倒的な 信頼性 開発速度 変更 容易性 CI/CD 採用 競争力 オブザーバビリ ティ
25. © ZOZO, Inc. 25 現在進めているリプレイスのゴール 「言語レガシー解消」及び「コンテキストの(論理|物理)線引き」 Java化しつつ、モノリスをモジュラモノリス(論理的線引き)またはマイクロサービス(物理的線引き)移行す るまでをリプレイスフェーズ1と区切り、ひとつのマイルストーンとしている。 フェーズ2以降についてはデータ不整合の解消など改善策が見えていないものもあるため、リプレイスの完 全なゴールは描けていない。
26. © ZOZO, Inc. 26 最後に とりあえず今は手を動かしながら見えている壁を全力で乗り越えています。 そして壁にぶつかることで成長しその時捻り出せる最大限の力で解決を試みるのが現状の基幹システムリ プレイスの実態だとも思っています。 モジュラモノリス化(ほぼ言語の置き換え)はビジネス成長を優先したことで抱えたレガシー的技術負債の 返済でしかなく、新たな価値のようなものは生み出せていません。 リプレイスという言葉には色々な期待が込められることが多くありますが、詰め込み過ぎて収集が付かな くなることこそ本末転倒なのでまずは全力で負債を返済します！ その過程で得た学びは引き続き発信していこうと考えていますので、ぜひご注目いただけると幸いです。