アーキテクチャの模索

矢部：まず、リプレイス前の基幹システムの状況をお話しします。

リプレイス前のシステムは、現在ではレガシーなプログラミング言語となっているVBScriptで構築されております。事業成長を優先してきた結果、20年間にわたり機能を継ぎ足してきたものになっています。その結果、巨大なモノリスであり、かつ「巨大な泥団子」と呼ばれるような状態にもなってしまっています。

テストコードを書く文化もなかったため、リファクタリング耐性もありません。加えて、手続き的なトランザクションスクリプトのような記述になっているため、影響範囲を調査する際は全体をgrepするしかない状況です。さらに、MicrosoftからVBScriptのサポート終了が発表されつつあることもあり、本格的にリプレイスを進めていくことになりました。

矢部：このモノリスの基幹システムの機能を図に表すと、一般的な基幹システムによくある商品、在庫、カスタマーサポート、会計といった機能があります。ただ、ZOZOの特徴として、倉庫を自前で構えているため、発送や入荷といった物流の機能も基幹システムに含まれている点が挙げられます。

リプレイスの戦略としては、まず物流を切り離すことを考えました。発送と入荷の2つを切り離すことで、仮にオンプレミスのモノリス側に障害があったとしても、一定期間は物流業務を止めずに進められるというメリットがあります。この分離が実現できた後に、必要に応じて他のドメインもマイクロサービス化していくという戦略を立てました。

最初の挑戦は発送領域のマイクロサービス化でした。事前の見立てとしては、発送というドメインの特性上、注文が確定したデータを扱うことになりますので、発送外の領域からデータを更新されることも少なく、トランザクション境界が明確で、他ドメインとの結合度も低いということが有識者内で認識できていました。その結果、想定通り分離に成功しています。

矢部：発送をマイクロサービス化できたことで、発送は独立してデプロイできるようになり、モノリス側に障害があっても一定期間は発送業務を続けられる状態をつくることができました。これにより、マイクロサービス化に対するある種の成功体験を得ることができました。

この発送の成功体験を受けて、次は入荷領域のマイクロサービス化に挑戦しました。狙いは明確で、発送と同様に物流のメイン業務をモノリスの障害から切り離せることがメリットになっています。しかし、ここで大きな壁にぶつかりました。

イベントストーミングを行う中で直面した課題として、たとえば予約注文で入荷待ちしている商品がある場合、その商品が入ってきたら入荷待ちの注文より先に販売開始するわけにはいきません。入荷している段階で棚入れせずに注文と引き当てる必要があり、その際に在庫と注文をお互いに確保済みのステータスに更新する必要がありました。

注文と入荷は別のドメインに置きたかったのですが、在庫の整合性を保つためにはどうしても結果整合性を許容できないという事情がありました。他にも、商品データのリアルタイム性が必要であるなど、ドメインをまたいでの強い整合性が必要なことがイベントストーミングの段階でわかりました。結果として、検討段階でマイクロサービス化を断念せざるを得ない状況になりました。

矢部：このことから、いきなりマイクロサービス化するのはリスクが高いことがわかりました。そこで、まずは泥団子になっている状態からモジュール境界を徐々に見つけていきながら、モジュラーモノリスを経由するという判断を下しました。モジュラーモノリスとして整理しつつ、うまく境界が見つかったものに関しては、その時点でマイクロサービス化に移行するという戦略です。ただし、発送のように事前に境界が明確なのであれば、モジュラーモノリスを経由せずにマイクロサービス化することも許容しています。

ここからは、モジュラーモノリスにリプレイスする際に機能は等価にしたまま言語をVBScriptからJavaに置き換えるという方針について触れさせてください。言語を置き換えるだけでも、オニオンアーキテクチャを導入することで既存のトランザクションスクリプトのベタ書きソースコードよりも読みやすくなりますし、テストコードを書く文化によりリファクタリング耐性も向上します。また、CI/CDパイプラインを導入することで安全にデプロイできる環境が整います。

矢部：詳細な方針としては、リプレイス中に機能に変更が入ることを避けたかったので、ビジネスサイドと調整して、重要な案件でない限りはコードフリーズもさせていただきました。また、ドメイン知識のないメンバーでも正確かつテスト工数少なくリプレイスできる方法として、本番環境での等価性検証の仕組みも構築しました。こうした中で、まずは言語をリプレイスするだけでも一定の価値があると考えました。

機能等価リプレイスの罠

しかし、ここで大きな罠にはまりました。1つ目の罠は、既存組織に設計文化がなかったことです。VBScriptでもクラスを扱えるのですが、クラスを使わずにすべてトランザクションスクリプトで書かれていたため、ソフトウェアの設計概念がほぼ存在しない状態でした。

矢部：また、既存エンジニアのスキルセットにリプレイス後の環境で採用したJavaなどがなかったため、リプレイスを先導しているメンバーが各チームに技術を教えに行く機会をつくりました。しかし、効率的に教えようとするあまり、伝え方として手順が前面に出てしまった部分がありました。結果として、一部に「とりあえずJavaに置き換えればいい」という理解が蔓延してしまいました。

さらに、コードフリーズの副作用として、「早くリプレイスを終えることこそが正義」という大義名分のもとに、品質よりもスピード重視の風潮が一部で生まれてしまいました。設計文化のなさと相まって、設計に時間をかけるよりも早く終えたほうがいいという風潮になってしまったことは反省点です。

2つ目の罠は、巨大すぎるシステムという問題です。組織的に既存システムの内容に詳しいメンバーは多いのですが、どういう順序で各機能を使っているのか、システム外でユーザーがどういうことをしているのか、イレギュラー対応にはどういったものがあるのかまでは把握できていませんでした。事業部から依頼されたものはなんとか実現したいという思いで、機能は増加の一途をたどる状態になっていました。

矢部：また、機能がデプロイ後にどの程度売上やコストに貢献しているのかを定量的に測る体制がなく、そもそもどの程度使用されているかわからない機能も複数存在していました。前提として、リプレイス着手前にシステム全体の全体像は調査・整理したうえで規模感を算出していました。しかし、機能を増やすという文化を変えずに巨大なシステムをそのままつくり直すだけでは、同じ問題を引き継いでしまうことになりかねません。

このままでは、リプレイスが技術負債の一部返済だけで終わってしまうという重要な気づきを得ることになりました。

価値創造への転換

リプレイスを進めていく中で、想定どおりに進まない現実に直面し、改めてリプレイスを単なる言語変更ではなく、システムと組織を変革する契機とする重要性に気づきました。具体的には3つの観点があります。1つ目は、設計を通じて偶発的な技術負債を根本から解消すること。2つ目は、機能を整理して価値ある領域に集中し、生産性を上げること。3つ目は、それらを理解してもらい、組織文化にまで落とし込むことです。この「設計×機能整理×組織」で、リプレイスに付加価値をつけていこうと考えました。

まず、設計の重要性を組織に理解してもらう必要がありました。私たちが導入した設計として、オニオンアーキテクチャ、ドメインの分離、単一責任原則などがあります。これらの設計がもたらす効果として、影響範囲が局所化される、改修コストが削減できる、長期的な保守性が向上するといった点が挙げられます。これらを組織全体に浸透させることで、目先の対応で早くリプレイスを終わらせることよりも、長期的なメリットがあることを理解してもらうことが重要だと感じています。

矢部：次に、価値が不明瞭になっている機能を整理していきたいと思っています。その際は『ドメイン駆動設計をはじめよう』という書籍に記載のある考え方を機能整理のベースとしました。各機能を業務ロジックの複雑さと競合他社との差別化という2軸から考えて、中核、一般、補完、一般または補完の4つに分類しました。

矢部：リプレイス優先度としては、1つ目が中核で最優先です。設計思想を十分に反映させて、リソースと時間を最大限投資する領域になります。2つ目が一般で、競争優位性は生み出さない領域ですが、業務ロジックが複雑なことが多く利用頻度も高いため、購入するのか模倣でリプレイスするのかを比較的早い段階で決める必要があります。3つ目が補完で、必須な機能ではありますがロジックがほぼない更新処理などが該当するため、リプレイスの優先度は落としています。4つ目は一般または補完で、判断を一旦保留にして外部調達を模索しています。

この順番でリプレイスに着手することで、価値の高い領域からVBScriptのサポート終了が来ても確実に事業が継続できる形で進めていこうと考えています。

この4つの分類とは別の観点として、機能整理に3つの判断軸を加えました。1つ目が削除です。利用頻度が低くて事業価値の低い機能は削除対象になります。ユーザー分析ツールを導入してアクセス数を計測し、判断材料にしています。類似機能を統合したり、オーバースペックな機能を簡素化したり、事業貢献できていない機能はこれを機に削除するというものです。

2つ目は先送りです。対象は将来変化が予想される機能になります。弊社でいうと、倉庫の自動化などが挙げられます。近い将来、大きな変化が予想されるため、今の状態でつくり直すことはせず、優先度を下げるという方針です。詳細仕様が固まってから新形式で提供することを考えています。

3つ目は簡素化です。対象は主に中核以外の機能になります。具体例としては、レポート機能のSaaS化などを考えています。単純な検索などであれば外部サービスに出してしまい、事業部側で非エンジニアがエンジニアの力を借りずに変えたいところは変えてもらうという体制も整えていきたいと考えています。

矢部：最も重要になるのが、組織の理解です。綺麗な設計をすることが長期的に保守性を高めて改修を早くすることを理解してもらいつつ、リプレイス後も定量的な評価のもとに不要な機能は削除する文化を構築していく必要があります。

せっかくつくった機能を削除するのは気が引けるところはあるのですが、ミニマムなシステムを維持することで開発速度を上げ、価値ある領域に時間を割くことができるようになります。これらが結果的に生産性を向上させることを全員が理解している状態にしなければならないと思っています。

『単体テストの考え方/使い方』という書籍に「プログラミングにおいてコードは資産ではなく負債なのです。そのため、コードベースが大きくなると、より多くの潜在的なバグを抱えることになります」という一節があります。今の組織にはまさにこのエッセンスを取り込むことが重要だと考えています。

今まさに変革の途中

ここまで課題やそこから得た学びについてお話ししましたが、まだリプレイスは始まったばかりで、これは完成された成功事例ではありません。今まさに対話を通じて文化に根付くように、設計品質、機能削減の重要性を理解してもらう取り組みを始めています。

また、初めにモジュラーモノリスでいくという方針をお伝えしましたが、社内の他の開発組織も基幹システムリプレイスに参加し始めてくれていますので、改めてドメイン境界を探して、モジュラーモノリスを経由せずにマイクロサービス化できないか模索中です。試行錯誤を続けていますので、判断を誤ることは当然あるのですが、学び、軌道修正しながら前進しています。

私のパートのまとめになります。1つ目は、機能を等価にリプレイスする場合でも設計品質は重要ということです。2つ目は、機能整理で最小限のシステムにすることで生産性を向上させるということです。3つ目は、組織の理解が最重要ということです。説明するだけでは不十分で、全員が納得し、腹落ちし、文化になるところまで進める必要があると改めて感じています。4つ目は、リプレイスを価値創造の機会にするということを全員が理解している状態にすることです。技術刷新だけではなく、課題を抱えた組織文化なども併せて変革しなければ、リプレイスが単なる負債の一部返済だけの作業にとどまってしまいます。

正直、実践すると当たり前のことばかりではありますが、これが巨大モノリスをリプレイスしていく中で得た、組織文化や機能整理観点での学びになります。

背景：レガシースタックの限界

杉山：ここからは、インフラ観点から具体的なアーキテクチャの図などをお見せしながらお話しさせていただきます。

リプレイスが必要になった背景には、レガシースタックの限界があります。ZOZOTOWNのリプレイスは進んでいるのですが、基幹システムの方はClassic ASPのVBScriptとWindows IISで構成されたレガシースタックのままでした。

長年の運用で安定はしていたものの技術的な老朽化が進んでいて、特に問題だったのがVBScriptの廃止がMicrosoftから発表されたことです。すでにサポートは段階的に縮小されてきており、2027年にはデフォルトで無効化され、その先では完全に削除される予定です。つまり、動いている今のうちに変えないと手遅れになってしまう、事業が止まってしまうという危機感がある状況でした。

杉山：加えて、保守性と拡張性にも限界・課題がありました。オンプレミス環境のリソースは限られており、内部のロードバランサーがないため、拠点ごとに割り当てたサーバーを立てて、ドメインを設定して動かしていくという構成になっています。オンプレのインフラ拡張にも限界があり、成長するサービスをこのままでは支えきれない状況でした。

また、データセンターの各拠点のWebサーバーがデータベースに直接アクセスしている状況があります。各拠点ごとのWebサーバーが特定のDBだけでなく、すべてのデータベースに相互にアクセスしている非常に密結合な状態になっています。そのため、一部のデータベースの障害や高負荷が発生すると、障害が起きたところの拠点だけでなく、他の全拠点にも影響が波及してしまうリスクを抱えています。

技術的な老朽化、拡張の限界、そしてサポート終了という期限、これらの課題が重なったことで、是が非でもリプレイスを進めなければならないという状況になりました。

課題：ステートフル／データベース構造の複雑さ

杉山：このような背景があってリプレイスプロジェクトが始まったわけですが、簡単にリプレイスは進みません。リプレイスを進めるための調査の中で、大きな課題に直面しました。

当初は、すべてマイクロサービス化すれば理想的な構成になると考えていたのですが、実際に設計していくと、そもそもリプレイスをする前に事前にやらなければいけないことが見えてきました。リプレイスを進めるためには、ステートフル構成という課題と、データベース構造の複雑さという課題、これらを解決しないとそもそもリプレイスがなかなか進めにくいという状況でした。

まず1つ目の課題はステートフル構成です。現在リプレイスを進めている基幹システムでは、IISのセッション管理やサーバーのローカルにある作業データファイルに依存しています。セッションや業務処理に必要なデータファイルがサーバーのローカルにあってサーバー間で共有できない、いわゆるステートフルな構成になっています。

杉山：これらの要因により、セッションを固定しないロードバランシング、すなわちクッキーパーシステンスやスティッキーセッションを用いず、ラウンドロビンやリーストコネクションで振り分けるような完全にステートレスな構成を採ることができない状態になっています。このままリプレイスを進めると、Kubernetesなどへ移行してコンテナとして動作させる際に、そもそも対応が難しい状況です。そのため、まずは現行構成のアプリケーションをステートレス化していく必要がありました。

続いて2つ目の課題として、データベース構造の複雑さがあります。現行のアーキテクチャでは、複数の業務ドメインが同じテーブルを共用しています。業務ドメインに関係なくデータが入り乱れた、いわゆるスパゲッティ状態になっています。各業務機能がさまざまなテーブルを相互に参照しており、機能とデータの関係性が非常に密結合になっています。

杉山：さらに、トランザクション依存が非常に強い点も課題です。1つの処理が複数のテーブルをまたいで更新するケースも多く、ドメインごとにテーブルを分離することがなかなか難しい状況になっています。結果として、マイクロサービス化のために調査はするものの、ドメイン分割が容易ではない領域もあれば、できる領域もあるという状況です。特定のデータベースに集中してしまっているため、リプレイスでバックエンドをマイクロサービス化していくにしても、これをなんとかしていかなければならないという課題がありました。

そもそもスタートラインに立つために解決しなければいけない課題があったということです。

解決アプローチ：ステートレス化／判断基準

杉山：ここからは、それらの課題に対してどのように解決アプローチを取っていったのかをご紹介します。

1つ目はステートレス化で、アプリケーションをステートレス化してクラウド環境やKubernetesへ移行できるようにすることです。2つ目は業務ドメインの特性を踏まえて判断するための分割の判断基準をつくることです。

まずステートフル構成に対する解決のアプローチは、もちろんステートレス化です。IISには標準でセッションオフロードする仕組みがないため、独自ライブラリを用いてIISのセッションをRedisにオフロードする手法を取っています。それによって、すべてのWebサーバーでセッションを集中管理することができるようになります。

サーバーローカルで扱っていた作業データファイルについては、ファイルサーバーやAWSであればFSxを使って外出し、ネットワークマウント化することで、オンプレミス環境のADとも統合しながらステートレス化を実現しています。

杉山：このセッションオフロードで使った独自ライブラリは、基幹システムではなくZOZOTOWNのほうで既に使っている実績のある方法で、数年の本番稼働実績がありました。このライブラリ自体、私が数年前に手がけたこともあって、自信を持って導入できました。ここが整うとオンプレとクラウドでセッション維持が可能になり、フロントの段階的なリプレイスが進められます。

現時点では、Kubernetes基盤上でIngressとIstioを組み合わせた構成のリプレイスを構築イメージとして持っています。外部からのリクエストをIngressで受けて、IstioのVirtualServiceを使ってパスごとにクラウドとオンプレにパスルーティングできるようにします。いわゆるストラングラーパターンと呼ばれる手法で、パスベースで機能を切り替えながら段階的に進めていくことができる構成になっています。既存システムとリプレイス環境でセッションやデータの共有を維持しながら、段階的に置き換えていくことが可能になります。

杉山：フロント領域においては、今まさに設計を進めている状況で、機能ごとに独立したフロント開発・展開ができるようにマイクロフロントエンドにするのか、Webコンポーネントを用いて分離するのか、デプロイメント分割をして開発組織に合わせた分割をしていくのか、そういった技術選定を本格的に進めている段階です。

続いて、課題2のデータベース構造の複雑さへの対応についてです。アプローチは分離判断の基準をつくるというものです。業務ドメインに基づいてコンテキスト境界を定義する際に、これはどうだろう、あれはどうだろうと迷うことがあると思います。その迷う原因は基準がないからではないかと考え、このような場合にはこうする、別のケースではこうする、という対応方針を、ある程度明確に定義してみました。

業務ドメインに基づいてコンテキスト境界を定義する際の判断基準を設けました。結合度が高くて分離が難しい領域はモノリスとして集約する。独立性が高くて分離しやすい領域はマイクロサービス化する。このような基準があることで、データを見れば「これはマイクロサービスでいけそう」「これはモノリスにしておいた方がいいのでは」という判断が、隅から隅まで調べなくともある程度想像できる状況をつくりました。スピードアップも図れて判断も早くできると考えて取り組みました。

具体的な判断基準として、4つの観点を設けています。トランザクションの結合度、データ量と整合性の要求、アーキテクチャの独立性と技術要件、ドメイン境界の分離難易度の4つです。

杉山：トランザクション結合が高くて整合性を重視する領域、現状では分離難易度が難しいという領域については、技術をモダナイズ化することを前提にモノリス（コアサービス）に集約するという判断ができます。一方で、独立性が高くアーキテクチャを柔軟に変えたいという領域においてはマイクロサービス化すると定めています。このような判断基準を設けることで、領域ごとに特性を見極めながら、無理のない分離と移行の判断ができるようになっています。

事例：コアサービス・発送サービス・会計サービス

杉山：ここからは、それぞれの判断を実際のシステムにどう落とし込んだかを、具体的な事例を交えてお話しします。具体的には、整合性を重視して技術をモダナイズするためにモノリスとして再構築したコアサービス、止まらないことを最優先にイベント駆動で設計した発送サービス、そしてすべての取引を再現できることを目的にイベントソーシングを採用した会計サービス、この3つの事例になります。

杉山：まず1つ目はコアサービスです。こちらでは密結合になっていたDBアクセスを共通APIに集約し、トランザクション整合性を保ちながら技術基盤をモダナイズしました。もともとVBScriptから直接データベースを呼び出す構成だったので、各機能が独自にSQLを発行するバラバラなデータアクセスになっていました。そのため、スキーマ変更の影響が広く、メンテナンス性や拡張性にも大きな問題がありました。これを共通APIとして切り出し、クラウドで動かすという形で集約しています。

現在は、このコアサービスで一元管理することを目的として、どんどん機能をAPIに移し替えている形になります。ここはドメイン分割が難しい領域を集約して、技術のモダナイズを優先的に進めるための基盤として位置付けています。VBScriptからの直接アクセスを排除して共通化することで、整合性を維持しながらも、今後の拡張や移行がしやすい構成になっています。

杉山：2つ目のサービスは発送、マイクロサービスです。発送業務は止められない領域になります。基幹DBがなんらかの障害で止まってしまうと、そのあおりを受けて発送処理全体が止まってしまうことがありました。そこで、この領域を基幹DBから分離し、イベント駆動で処理する構成にしています。

この仕組みでは、SQSメッセージングとDebeziumによるアウトボックスパターンを組み合わせて、安全で一貫性のあるイベント連携を実現しています。DBのデータ更新とメッセージブローカーへのイベント送信を、通常のダブルライトで起こりうる問題を避けながらイベントを配信できる構成になっています。

基幹DBで発送準備データが作成されると、プロデューサーがSQSにメッセージを送信します。コンシューマーは発送準備イベントを受け取って、発送サービス側の独立したMySQLに書き込みます。作業者がピッキング、梱包、出荷といった発送業務を行っていくごとに、ピッキング完了、梱包完了、出荷完了というイベントがどんどん流れて処理されていきます。そのイベントはDebeziumのCDCでKafkaに流れるようになっていて、コンシューマーが次の工程のデータを書き込みます。発送作業が完了した際には、発送完了を最終的な基幹のデータベース側にコンシューマーが戻すことができるようになっています。

このようにイベント駆動アーキテクチャでシステム間を疎結合化することで、基幹データベースの障害や多少のトランザクション遅延があっても、連携済みの発送処理が止まらないことを実現できています。

杉山：最後の事例は会計サービスです。会計業務の中には、発送とは異なった「正確に再現できること」が求められる領域があります。すべての取引を再現できるようにするために、イベントソーシングを採用しています。インフラ構成自体はすごくシンプルなのですが、アプリケーションレイヤーでAxonフレームワークというものを利用してイベントソーシングを実現しています。これは開発チームからの提案と検証を受けて、イベントソーシングのフレームワークとして最適だろうということで採用したものになります。現在のフェーズでは、会計ドメインの中の売上と入金のマッチング処理の領域で採用しています。

発送が「止めない構成」だったのに対して、会計では「いつでも再現できる構成」になっています。

まとめ

杉山：まとめとして、巨大モノリスの再構築戦略でやったことをお話しします。

ステートレス化によって、フロントリプレイスを進めるための土台を整備しています。これによって将来的なKubernetes移行やコンテナ化が可能になり、ストラングラーパターンで安全に段階的な移行を実現しています。

ドメイン特性を踏まえた4つの判断観点を作成することで、できるだけ素早い意思決定ができるように心がけています。結合度が高い領域はモノリスに集約し、トランザクションの整合性を維持しながら技術のモダナイズを進める。独立性が高い部分はマイクロサービス化して、それぞれ特性に合わせたアーキテクチャを採用するという形です。

すべてを一律にマイクロサービス化するのではなく、ドメイン特性を踏まえて効果の高い領域を見極めることが重要です。

締めになりますが、モノリスとマイクロサービスを適材適所で使い分けるということです。本講演のお題の通り、それぞれに強みと役割があり、どちらか一方が正解というわけではありません。この2つをうまく目的に合わせて使い分けて、どこをどう変えるかを見極めながら進めていくというのが、ZOZOにおけるモノリスを現実的に再構築するための基幹リプレイスの「ハイブリッド戦略」です。ご静聴ありがとうございました。

アーカイブ動画・発表資料

イベント本編は、アーカイブ動画を公開しています。また、当日の発表資料も掲載しています。あわせてご覧ください。

▼動画・資料はこちら
アーキテクチャConference 2025

※動画の視聴にはFindyへのログインが必要です。