モノリシックとマイクロサービスの比較と移行のタイミング

オンラインストアを効率的に運営するためのシステム構造や設計であるECアーキテクチャにはいくつか種類があり、モノリシックやマイクロサービスもその一種です。

モノリシックは開発やテストがシンプルな一方、システムの巨大化に伴って複雑になる課題があります。一方、マイクロサービスは柔軟性を高められる反面、サービスを分割するほどシステムも複雑になるため、自社に適した構成を見極めることが重要です。

この記事では、エンタープライズECにおけるモノリシックとマイクロサービスの違いやメリットとデメリット、移行を考える際のポイントなどについて解説します。

モノリシックとマイクロサービスの違い

モノリシックとマイクロサービスの大きな違いは、システムを1つにまとめて構築するか、機能ごとに分割して構築するかにあります。

モノリシックではアプリケーションを1つのシステムとして構築するため、構成が比較的シンプルで、開発やテストを一元化して行えます。しかし、システムが大規模になるとコードの依存関係が複雑になり、変更の影響範囲が広がりやすくなります。

一方、マイクロサービスはアプリケーションを独立したサービスに分割する設計モデルで、システムの柔軟性を高められます。しかし、サービス間のAPI連携、統合テスト、フィードバックなどに時間やコストがかかります。

比較項目	モノリシック	マイクロサービス
データモデル	統合型	独立、分散型
機能の構築	1つのシステムにまとめて構築	サービスごとに構築と保守
主な目的	機能開発のスピード、TCO抑制	チームの自律性、システムの柔軟性

モノリシックのメリットと課題

モノリシックアーキテクチャは、古くから使われている従来型のアーキテクチャです。主なメリットは以下のとおりです。

• オーバーヘッドの削減： アプリケーションを1つにまとめることで、管理、調整、オーケストレーション（複数の自動化処理の連携）がシンプルになり、間接費や負担を削減できます。
• メンテナンスが容易： すべての構成要素（コンポーネント）が1つのコードにまとまっているため、デバッグやテストがしやすく、問題の原因、バグ、関連する部分を特定しやすくなります。
• シンプルさ：特に事業の初期段階において、コード管理や公開作業を低負担で行えます。

一方、システムが大規模化するとコンポーネント間の結び付きが強くなり、変更が全体に影響しやすいという課題があります。また、特定の機能だけを個別に拡張したり強化したりできず、共通の技術やツールへの依存が開発上の制約となる場合もあります。

マイクロサービスのメリットと課題

マイクロサービスアーキテクチャは、2015年以降に多くの企業に採用されるようになったアーキテクチャです。主なメリットは以下のとおりです。

• ビジネス機能ごとの自律性：ビジネス機能ごとに独立したサービスとして開発するため、チーム間の調整を最小限に抑えて効率化でき、必要な機能だけを柔軟に拡大縮小できます。
• 個別の技術スタック：各サービスをそれぞれ独立したコードで管理できるため、開発チームはより自律的に開発でき、チーム間の調整にかかる負担も軽減できます。
• APIを介したサービス間の連携：各サービスはAPIを介して通信するため、サービスやアプリケーションが増えてもそれぞれを独立させたまま連携できます。

一方、マイクロサービスのデメリットには、サービス数の増加に伴って運用負担やサービス間の調整が複雑になるというものもあります。また、サービスが独立していてもテスト環境を共有していれば個別にテストができず、メリットを十分に活かせません。そのため、規模が見合わない場合などにはモノリシックな設計やそのほかのアーキテクチャを採用する方がよい場合もあります。

移行のメリットとデメリット

マイクロサービスへの移行によって、チームごとの独立した開発や導入がしやすくなり作業効率が改善される場合があります。たとえば、学習プラットフォームCoursera（コーセラ）ではマイクロサービスモデルへの移行後、ソフトウェアの変更をシステムに反映する時間が数時間から数分に短縮されました。

また、高負荷環境下では、マイクロサービスはモノリシックと比較して平均レイテンシが25%低く、エラー発生率も減少することが実験（英語）でわかっています。そのため、システム要件や構成によっては、移行が処理性能や読み込み速度の改善につながる可能性もあります。

一方で、マイクロサービスに移行することで、システム全体の複雑性が増してしまう可能性もあります。Amazon（アマゾン）プライム・ビデオの事例（英語）では、マイクロサービスでは想定していた処理量のわずか5％程でパフォーマンスの上限に達してしまいました。その後、複数の機能を1つにまとめて動かす構成に変更したところ、90％以上のコスト削減と拡張性の向上が実現しています。

さらに、マイクロサービスへ移行すると、CI/CDパイプライン（コード変更からシステムへの反映までを自動化する仕組み）や監視体制の整備が必要となり、運用負荷や保守コストが増加する可能性があります。また、サービス間の依存関係やAPIのバージョン管理など、複数のサービスを連携させるための調整も課題となります。

こういったメリットとデメリットからも、モノリシックからマイクロサービスへ移行すべきかどうかは、ケースバイケースで判断する必要があります。

マイクロサービスへの移行を検討する際のポイント

• チーム間の調整がどの程度発生しているか把握する
• 開発者の生産性への影響を確認する
• チームが解決すべき課題を明確にする
• モジュール型モノリスで十分か検討する
• 柔軟性だけを目的に移行しない
• チーム体制に合わせた導入のタイミングを見極める
• リスクの低い移行方法を検討する

チーム間の調整がどの程度発生しているか把握する

システムを更新するたびにチーム間の事前調整や承認が必要な場合は、アーキテクチャを見直す必要があります。チーム同士の依存関係が業務効率に影響している状態なら、マイクロサービスへの移行を検討してみましょう。

開発者の生産性への影響を確認する

開発者が作業を中断する時間が長くなっている場合は、アーキテクチャの見直しによる効果が期待できます。共有環境で統合テストを待つ間、開発者がどの程度作業を中断しているか確認しましょう。

チームが解決すべき課題を明確にする

サービスを分割する理由がシステムの拡張性にあるのか、それとも企業内の連携にあるのかを確認しましょう。組織上の問題であれば、技術的な手間やコストをかけて解決する必要があるのかを検討します。

モジュール型モノリスで十分か検討する

マイクロサービス化の前に、モジュール型モノリスで課題を解決できないか検討しましょう。モジュール型モノリスとは、1つのアプリケーションとして構築しながら機能ごとに分離する設計で、ネットワーク負荷などを抑えながら、チームごとに担当領域を分けて管理できます。将来的なシステム連携や新機能の追加にも対応しやすくなります。

柔軟性だけを目的に移行しない

柔軟性だけを移行の目的にすると、適切な分割が行われず、個々のサービスが互いに強く依存している「分散モノリス」と呼ばれる状態になってしまいます。この状態になると、運用の複雑性だけが高まり、マイクロサービスのメリットを十分に得られなくなります。

また、適切な範囲を定めずシステムを細かく分けると、機能同士が依存し合う循環依存のほかに、処理の重複、不要な通信なども発生しやすくなります。移行によって解消したい課題を明確にすることが大切です。

チーム体制に合わせた導入のタイミングを見極める

チームの規模が小さい段階では、無理にマイクロサービス化する必要はありません。システムを細かく分割すると管理対象が増え、運用負荷が高くなるおそれがあります。導入の検討は事業や組織の拡大などチームの再編に合わせて行いましょう。

また、企業の構造がサービス範囲と一致していない場合、コードの依存関係がAPIを介した依存関係に替わるだけで、チーム間の調整負担は軽減されません。

リスクの低い移行方法を検討する

システム全体を一度に移行させるのではなく、段階的にサービスを切り出して移行させるようにしましょう。既存システムを停止してすべての機能を一気に切り替える一括移行方式（ビッグバン方式）は、障害などのリスクが特に高まります。そのため、既存システムを稼働させながら機能単位で段階的に移行することが大切です。

マイクロサービスへの移行が必要ないパターン

現在のシステムに問題があっても、次のような状況ではマイクロサービスへ移行するより先に既存システムや開発体制を改善した方が効果的です。

• テストや承認プロセスに時間がかかる：この場合、問題は開発プロセスにあります。マイクロサービス化してもデプロイパイプライン（コードの変更からテストや本番環境への反映までを自動化する仕組み）の数が増えるだけで、各プロセスの遅延は解消されません。
• コードが機能ごとに整理されていない：マイクロサービスへ移行しても、機能同士が密接に関連したままになり、依存関係が解消されません。
• 運用や障害対応の体制が整っていない：マイクロサービスの運用には開発チームと運用チームの連携が欠かせません。必要な環境の準備やシステムの反映を迅速に行い、問題が検知されたら早急に対応できる体制が必要です。
• 業務範囲や担当が十分に整理されていない：業務領域や各機能の担当が整理できていない状態でサービスを切り出すと、担当範囲を誤って分割してしまう可能性があります。分散システムで一度設定した境界を修正するには、大きなコストがかかります。

Shopifyの機能を活用して必要な機能だけを拡張する

Shopifyには、既存のモノリシックなシステムを維持しながら、特定の機能だけを追加したり強化したりできる仕組みがあります。以下のような機能を活用することで、マイクロサービスへ移行しなくても、システムの柔軟性を高められます。

• Commerce Components（コマースコンポーネンツ）：エンタープライズ向けに必要な機能だけを選んで既存のシステムに組み込めます。決済や商品管理などの機能を一から開発するのではなく、Shopifyが提供する機能と既存のシステムをAPI経由で連携できます。
• Shopify Functions（ショッピファイファンクション）：新たにマイクロサービスを構築することなく、割引、決済方法、配送ルールなどをカスタマイズできます。自社独自のルールや処理も、別のサービスとして構築、監視するのではなくShopifyのインフラ上で実行できます。
• Hydrogen（ハイドロゲン）：Shopifyのヘッドレスコマース向け開発ツールです。顧客に表示されるストアフロントをバックエンドから分離して開発、運用できるため、デザインやUXを柔軟にカスタマイズできます。ホスティングサービスのOxygenと組み合わせれば、自社でインフラを構築、運用する必要もありません。

モノリシックからマイクロサービスへ段階的に移行する方法

1. 業務領域とサービスの範囲を明確にする
2. ストラングラーフィグパターンを使って段階的に移行する
3. 移行中のシステム連携とロールバックを計画する
4. データベースの分割方法とデータの整合性を維持する方法を検討する

1. 業務領域とサービスの範囲を明確にする

MicrosoftのAzure（アジュール）アーキテクチャセンターでも推奨されているように、マイクロサービスへ移行する前に、業務領域ごとの機能や責任範囲を整理し、どの機能をどのサービスが担当するのか明確にしましょう。その境界をもとに、マイクロサービスの分割単位を検討します。重要な点は以下のとおりです。

• 業務領域ごとの責任範囲を明確にする：同じ「決済」でも、請求管理と不正検知では扱う情報や求められる機能が異なります。異なる業務領域を1つのサービスにまとめると、本来分けるべき責任範囲が混在し、分散モノリスになるおそれがあります。
• モノリス内部でも機能を整理する：サービスを分割する前に、モジュール間の関係や連携方法を明確にし、モノリス内部でも機能ごとの役割を整理しておきます。

2. ストラングラーフィグパターンを使って段階的に移行する

ストラングラーフィグパターンとは、既存システムを稼働させたまま新しいサービスで段階的に機能を置き換えていく移行手法です。既存システムを停止せずに移行できるため、一括移行方式（ビッグバン方式）と比べて移行リスクを抑えられます。

3. 移行中のシステム連携とロールバックを計画する

マイクロサービスへの移行では、新旧システムを並行して運用するための仕組みと、問題発生時に元に戻せる仕組みをあらかじめ設計しておきましょう。

ストラングラーフィグパターンでは、クライアントとシステムの間に設けたファサード（窓口となる仕組み）を通じて既存のシステムと新しいシステムに振り分けます。移行初期は大部分を既存のシステムで処理します。新しいサービスの動作が検証できたら徐々にリクエストの振り分け先を切り替えていきます。

モノリス内の機能から移行したマイクロサービスを呼び出す場合は、腐敗防止層（ACL：既存システムと新サービスの橋渡しを行う仕組み）を利用します。ACLが既存システム側の呼び出し方法を新しいサービスに合わせて変換することで、移行中でも両者が連携して動作できるようになります。

また、問題が発生した場合に以前の状態へ戻せるよう、ロールバック（処理を取り消して、以前の状態に戻すこと）もあらかじめ計画しておきましょう。サービスを移行するたびに動作を確認し、問題があれば元の状態に戻せるようにすることで、安全に移行を進められます。

4. データベースの分割方法とデータの整合性を維持する方法を検討する

マイクロサービスへ移行しても、サービス間でデータベースを共有すると、拡張や障害への対応、独立した運用が難しくなるおそれがあります。そのため、データベースの分割方法とデータの整合性を維持する方法を検討しておきましょう。

分割する方法は、データベースを先に分割する方法と、コードを先に分割する方法があり、移行の状況に応じて選択します。特徴は以下のとおりです。

• データベースファースト：データベースを先に分割することでデータ関連の問題を早期に把握できます。しかし、マイクロサービス化のメリットを得るまでに時間がかかる可能性があります。
• コードファースト：コードを先に分割することで早くサービス化できます。しかし、データベースを共有したままではサービス間の依存関係が残るおそれがあります。

また、サービスを分離しても、データを別々に管理すると整合性を維持するための仕組みが必要になります。たとえば、オンラインストアと店舗のPOSで別々のデータを管理している場合、サービス間でデータを同期しなければなりません。

Shopifyでは、オンラインストアとPOSで作成されたカートを同じデータモデルで管理することで、こうしたデータの分断を防げます。

モノリスからマイクロサービスへの移行が失敗する要因

• 業務範囲が不明確なままサービスを分割した
• システムの状態を把握する仕組みや体制が不十分だった
• 共有データベースとチーム間の依存関係が肥大化した

業務範囲が不明確なままサービスを分割した

サービスの担当範囲が不明確なまま分割すると、APIの変更やデータ移行のたびにチーム間で調整が必要になります。その結果、開発や運用が複雑になってしまいます。

また、業務領域への理解が十分でない段階でシステムを分割すると、サービスの担当範囲を何度も見直すことになり、そのたびに分散システムの構成を変更するためのコストが発生します。

サービスを分割したにも関わらず、変更のたびに他のチームとの調整が必要な状態であれば、サービスの分割が早すぎた可能性があります。

システムの状態を把握する仕組みや体制が不十分だった

システムの異常や障害の発生箇所を特定する仕組みが整っていないと、マイクロサービスの運用は難しくなります。オブザーバビリティプラットフォームを提供するLogz.ioの調査（英語）でも、チームの知識不足がクラウドを活用したシステムにおいて大きな課題となるとされています。

また、サービスを単独でテストできない状態では、サービスを独立して管理することも難しくなります。テストのためにシステム全体を動かす必要があると、インフラだけでなく障害の影響範囲もチーム間で共有することになります。

共有データベースとチーム間の依存関係が肥大化した

サービス間の依存関係が複雑に絡み合い、1つのサービスへの変更が数十のサービスに連鎖的な影響を及ぼす状態になると、システム全体の管理が複雑化し、変更による影響範囲を把握しづらくなります。

また、データベースを移行する際に、そのデータベースを利用するすべてのサービスを同時に更新しなければならない場合もあります。このように共有データベースがサービス間の依存関係を生み出し、更新のたびに他のチームとの調整が必要になるのであれば、サービスを分割していても実質的には独立したマイクロサービスとして機能していません。

自社に適したコマースアーキテクチャを見極める

Shopifyのマーチャントの場合、自社の要件に合わせてプラットフォーム構成を選択できます。それぞれの状況に適した構成は以下のとおりです。

• チームの成熟度が低く独自要件が多い場合：分散インフラを構築せずShopify Plus（ショッピファイプラス）とShopify Functionsを利用して、必要な機能単位でモジュール化する構成が適しています。
• チームの成熟度が高く複数ブランド対応などの大規模運用が必要な場合：Commerce Componentsの利用を検討しましょう。既存のシステムにShopifyのチェックアウトや商品カタログなどの機能を組み込めます。
• 多くのB2B企業の場合：純粋なマイクロサービスよりもコンポーザブルコマースが適しています。複数のサービスを個別に管理することなく柔軟なモジュール構成とシステム連携が実現できます。

まとめ

モノリシックとマイクロサービスにはそれぞれ利点と課題があり、どちらが適しているかはシステムの要件や企業体制によって異なります。新機能の追加や基幹システム連携を見据える場合は、拡張性や運用負荷も含めて比較することが重要です。マイクロサービスのデメリットである運用やシステム連携の複雑化も考慮し、必要に応じてモジュール型モノリスなども検討しましょう。Shopifyでは、モジュール型モノリスを実現できる機能を複数提供しています。Commerce ComponentsやShopify Functionsのほか、Shopify Plusを活用してより複雑なカスタマイズをすることも可能です。

モノリシックからマイクロサービスへの移行を検討している企業は、この記事を参考に自社に合ったアーキテクチャを見極めてください。