Microservices マイクロサービス　 顧客デジタルエクスペリエンス 用語集 オムニチャネルコマース・D2Cブランドの成長のために

 

マイクロサービス アーキテクチャとは

モノリシック アーキテクチャとマイクロサービス アーキテクチャ

「この有名な大企業がそのテクノロジーを使用していて、それが彼らにとって良いことであれば、私たちもそれを使用することができ、そしてこれは私たちの会社にとっても良いことになるだろう」

と仮定していませんか。これは「カーゴカルトの精神」です。

他の人がそうしているからといって、システムをマイクロサービスとして設計するのは論理的な考えではありません。

Sam Newman 氏が著書『Monolith to Microservices 』で述べているように、既存のシステム アーキテクチャで現在実現できないことを実現するには、マイクロサービス アーキテクチャへの移行を検討する必要があります。
ただし、特定のジョブに適切なツールを使用するには、トレードオフを考慮する必要があります。ソフトウェア アーキテクチャで最適な設計を見つけようとしないでください。代わりに、トレードオフの最悪の組み合わせを最小限に抑えるように努めてください。

マイクロサービスとモノリス アーキテクチャのどちらを選択するかをトレードオフする場合、それは技術的な決定であるだけでなく、組織的な決定でもあることを忘れてはなりません。
チームは、選択したアーキテクチャを実装するのに適している必要があります。

この解説ガイドでは、モノリシック アーキテクチャ、マイクロサービス アーキテクチャ、マイクロサービスとモノリス、およびどちらをいつどのように選択するかについて、知っておくべきすべてのことを説明していきます。

モノリシックアーキテクチャ

システム内のすべての機能を一緒に展開する必要がある場合、それをモノリスとみなします。モノリシック アーキテクチャとは、すべてのコードが単一のプロセスとしてデプロイされることを意味します。

あらゆるものと同じように、モノリシック アーキテクチャにも利点と欠点があります。

モノリシックアーキテクチャの利点

業務フローが見える化

モノリシック アーキテクチャにより、開発者は 1 つのコードベースで 1 つのアプリケーションを保守できます。単一ユニットとして構築されています。この 1 つのコードベースにより、新しい開発の影響を確認しやすくなります。このようにして、新しい機能がアプリケーションの全体的なフローに適合するかどうかを理解し、エンドツーエンドのフローを迅速に検査できます。

簡単なモニタリング

モノリスは 1 つのアプリケーションだけであるため、監視は簡単です。監視するマシンの数が減り、ログを取得するのも簡単になります。範囲が 1 つのアプリケーションに限定されるため、問題のトラブルシューティングも容易になります。

サービス間の複雑な通信方法 (非同期など) に関心を持つ必要はありません。
たとえば、イベント駆動型アーキテクチャに基づくマイクロサービスでは、マイクロサービス間の非同期対話が原因で、エンドツーエンドのフローを迅速に検査することが困難になる場合があります。このアーキテクチャでは、全体像を把握するには、各サービス間のイベント フローを理解する必要があります。各マイクロサービスにはまったく異なる監視戦略が必要ですが、モノリスは簡単な監視を提供します。

コードの再利用

もう 1 つの利点は再利用可能です。モノリシック アーキテクチャでは、すべてのコードがアプリケーション内に存在するため、再利用したり、既存の機能の上に構築したりすることが簡単です。

シンプルな展開パイプライン

アプリケーションは 1 つだけであるため、デプロイメント パイプラインはそのアプリケーションのニーズのみを考慮する必要があります。
マイクロサービス アーキテクチャでは、ニーズが異なるため、さまざまな構成が必要なマイクロサービスをそれぞれデプロイする必要があります。モノリス アーキテクチャと比較した環境の多様性に応じて、パイプラインの円が小さくなったり大きくなったりすることがあります。多くの場合、デプロイメント トポロジは、マイクロサービス アーキテクチャよりもモノリスの方がはるかに簡単 (そして安価) です。

これらの利点のため、多くのスタートアップはモノリシック アーキテクチャから取り組みを開始します。資金が限られているため、彼らは自社の製品をできるだけ早く顧客ベースに適合させることに注意を払っています。彼らは最初の成功を達成することに重点を置いています。

マイクロサービスは、組織として最初の成功を収めた後に発生する上記のような問題を解決する優れた方法です。

モノリスアーキテクチャの欠点

ビジネスの成長を制限する可能性があるモノリスの一般的な問題について説明します。これらの欠点を考慮することで、自分が穴にいるかどうかを理解する必要があります。

結合と境界の欠如

モノシリックスは耐えられないほど複雑になり (大きな泥の塊)、結合することがあります。

すべての機能が単一のアプリケーション内にあります。
したがって、各ドメインの境界が侵害されるリスクが常に存在します。モノリシック アーキテクチャの 1 つの変更が、システムのいくつかの部分に影響を与え、さらにはシステム全体に影響を与える可能性があります。

アプリケーションが成長するにつれて、コードベースを保守したり、新しい機能を追加したりするのは悪夢のような作業になります。

新規導入の難しさ

ソフトウェアの世界では、コードベースは保守しやすく、拡張可能である必要があります。新しい機能を簡単に開発し、コードベース全体に対するその効果を確認する必要があります。

モノリス アーキテクチャでは 1 つのコードベースでその影響を監視およびデバッグするのは簡単ですが、リリース サイクルは通常、マイクロサービス アーキテクチャよりも長く、大きくなります。コマース企業が有用で動作するソフトウェアをできるだけ早くユーザーに提供するために継続的デリバリーを採用したとしても、アプリケーション全体を検証してデプロイする必要があり、それには巨大なテストスイートが必要になるため、かなりの時間がかかります。これは、小さな変更により展開がより制御可能になり、迅速なフィードバックが可能になることに同意するとしても、モノリス アプリケーションに新しい小さな機能を継続的に追加するのはマイクロサービスよりも簡単ではないことを意味します。

したがって、モノリスに依存する企業は、常にアプリケーション全体をデプロイするため、リスクを考慮してそれほど頻繁 (たとえば、毎日) にデプロイしません。デプロイを行わないと機能が蓄積されることが多く、継続的デリバリの考え方を持つことが難しくなります。それだけでも、モノリスからの脱却を求める一般的な議論となります。

単一障害点

モノリスを導入するリスクは、変更を加えるとアプリケーション全体がダウンする可能性があることです。アプリケーションのそれほど重要ではない部分のコードを変更した場合でも、アプリケーション全体に影響を与える可能性があります。

スケーリングのコストが高い

大規模なモノリス アーキテクチャは、アプリケーション全体を拡張する必要があるため、拡張することが難しく、コストがかかります。

モノリスでのスケーリングには、アプリケーションの一部ではなく全体をスケーリングする必要があります。ただし、ほとんどの場合、スケーリングが必要なのはモジュールの 1 つまたは一部だけです。モジュールは 1 つのアプリケーションにバインドされているため、アプリケーション全体をスケールする必要があります。

モノリスを拡張するには、そのアプリケーションの複数のインスタンスをロード バランサーの背後にインストールします。ここで重要な点は、多くの同時リクエストに対処できるようにすることです。

モノリスデータベースについてはどうでしょうか

データベースを拡張したい場合、状況はさらに難しくなります。データベースを拡張する唯一の方法は垂直方向の拡張であり、これはコストをさらに押し上げることを意味します。ただし、マイクロサービス ベースのアーキテクチャでは、すべてのマイクロサービスが、よりスケーラブルなデータの分散を提供する独自のデータベースを持つ必要があります。したがって、水平方向のスケーリングが必要なデータベースをスケーリングすることができます。

マイクロサービスのアプローチを使用すると、アーキテクチャのスケーリングが必要な部分のみをスケーリングし、残りの部分を最小限のリソースで残し、コストとリソースを最適化することができます。

マイクロサービスアーキテクチャ

マイクロサービス アーキテクチャを使用すると、独自のプロセスを持ち、軽量のメカニズムで相互に通信する多数の小さなサービスとして単一のアプリケーションを開発できます。これらのサービスはさまざまな言語で記述でき、さまざまなデータ ストレージ テクノロジを使用できます。異なるチームが管理することもできます。

このアーキテクチャの長所と短所を見てみましょう。

マイクロサービスとマイクロサービス アーキテクチャの利点

継続的な導入を可能にする

マイクロサービス アーキテクチャの最も重要な利点は、大規模で複雑なアプリケーションを独立して継続的にデプロイできることです。マイクロサービス アーキテクチャで継続的デプロイメントを実装するには、次の 3 つの方法があります。

テストの自動化

エクストリーム プログラミングのモットー(面倒ならもっと頻繁にやろう) に従って、論理的な極端な方法は、自動テストに合格するすべての変更を実稼働環境にデプロイすることです。

自動テストは継続的な展開に不可欠な部分です。 CD の背後にある考え方は、単に開発サイクルを最終段階、つまり運用環境への展開まで自動化することです。コードがすべての自動テストに合格すると、実稼働環境に自動的にデプロイされます。ただし、中断を引き起こさないように、アプリケーション全体をカバーするテストを作成することが重要です。

独立した展開可能性

独立した展開可能性について議論する前に、まず疎結合を定義する必要があります。

結合は、2 つのコンポーネントがどれだけ相互に認識しており、相互に依存しているかを示す尺度です。結合度が高い場合は、依存性が強いことを意味します。

疎結合とは、異なるコンポーネントが互いについて必要最小限しか知らないことを意味します。コンポーネント間に結合がない場合は、各コンポーネントが他のコンポーネントの存在を認識していないことを意味します。これは、マイクロサービス アーキテクチャに求められるものです。

分離のおかげで、1 つのサービスの変更がアプリケーション全体に影響することはほとんどありません。したがって、そのサービスを独立して簡単にデプロイできます。

変更が小さければ、潜在的なバグの検出と修正がはるかに簡単になります。

リリースが小さいほどリスクは少なくなります。小さな変更のおかげで、問題の内容と、それを修正またはロールバックする方法を簡単に見つけることができます。

CD の背後にある中心的なアイデアは、リリースのサイズを縮小する方法を見つけることです。 CD アプローチでは、迅速なフィードバックを取得し、いつでも好きなときに製品をリリースできます (リリース オン デマンド)。小さな変更があるたびに、製品を頻繁にデプロイして、迅速なフィードバックを得る必要があります。

ソフトウェアでは、何かに痛みを伴う場合、痛みを軽減する方法は、痛みを軽減するのではなく、より頻繁に行うことです[10]。これにより、欠陥を早期に発見でき、修正コストが安くなります。この方法を実践することで問題を解決し、将来発生する可能性のあるバグを可能な限り防ぎます。

これらのプラクティスにより、企業が顧客からのフィードバックに迅速に対応できるようになるため、変更を頻繁に本番環境に展開することがはるかに容易になり、市場投入までの時間が短縮されます。

ただし、次のことを覚えておく必要があります。「マイクロサービスを特定の順序で完全なセットとしてデプロイする必要がある場合は、マイクロサービスをモノリスに戻して手間を省いてください。」

自律的なチームと開発組織と有機的な関係

単一アプリケーションのコードを変更して保守するのではなく、チームは自律的にサービスを開発できます。マイクロサービスは分離されているため、各チームは他のチームと調整することなくサービスを開発、デプロイ、拡張できます。小規模なチームでは、これらの製品に緊密に取り組む人々によって意思決定がより迅速に下されます。したがって、プル リクエストが承認されるまで何週間も待つ必要はありません。

開発プロセス中に、サービスに影響を与える可能性のある条件について合意しました。新しい機能を他のサービスに反映する方法について合意する必要がある場合は、マイクロサービスを並行して開発できます。

開発組織はより拡張性が高くなります。チームを追加することで組織を成長させます。 1 つのチームが大きすぎる場合は、そのチームとそれに関連するサービスを分割します。チームは疎結合であるため、大規模なチームの通信オーバーヘッドを回避できます。その結果、生産性に影響を与えることなく人を追加できます。

マイクロサービス アーキテクチャは、サービス開発者とそのユーザーの間に個人的な関係を提供します。マイクロサービス アプローチは、チームが製品の全生涯にわたって製品を所有する必要があることをサポートします。前述したように、開発チームは本番環境のソフトウェアに対して全責任を負い、より粒度の高い構造によりそれが容易になります。開発者は、より簡単な方法でソフトウェアを最初から観察して保守できます。これにより、ユーザーと開発者の間に直接的な有機的な関係が生じます。

これらの点により、消火活動ではなく価値のある機能の提供に多くの時間が費やされるため、従業員の満足度は高くなります。

小規模なサービスと容易なメンテナンス

マイクロサービスが小さいほど、より迅速な開発 (アジャイル)、より迅速な反復 (リーン)、およびより頻繁なデプロイ (継続的デリバリー) が容易になります。ただし、モデリングの面では、「小さすぎる」サービスの作成を避けることが重要です。

サービスが小さい場合、開発者にとってコードは理解しやすく、保守しやすくなります。各マイクロサービスは、大規模なモノリスよりもはるかに高速に開始できます。これにより、開発者の生産性が向上し、展開時間が短縮されます。

分散型データベースとデータ所有権

従来のアプローチでは、すべてのサービスで共有される単一のデータベースがあります。たとえそれがより単純に見え、すべての一貫性を保つためにさまざまなサブシステム内のエンティティを再利用できるように見えたとしてもです。ただし、最終的には、ほとんどの場合には必要のない属性や列を含む巨大なテーブルが作成される可能性があります。さらに、結合関数のコストにより、データベースからデータを取得するトランザクション時間が長くなる可能性があります。

マイクロサービス アーキテクチャにおける重要な点の 1 つは、各マイクロサービスがそのドメイン データとロジックを所有する必要があるということです。データの所有権に関する一般的な経験則は、テーブルへの書き込み操作を実行するサービスがそのテーブルの所有者であるということです[15]。マイクロサービスを移行した後、どのサービスがどのデータを所有するかを決定する必要があります。

マイクロサービス アーキテクチャでは、概念モデルとデータ ストレージの両方に関する意思決定が分散化されます。したがって、各マイクロサービスには、必要なデータを保存する独自のデータベースが必要です。このアーキテクチャは、同じデータベース テクノロジの異なるインスタンスまたはまったく異なるデータベース システムのいずれかで、各サービスが独自のデータベースを管理できるようにすることを好みます。このようにして、サービスはユースケースに最も適切なデータ ストアを選択できます。

分散データベースを使用すると、各サービスのデータをカプセル化します。これにより、マイクロサービスが疎結合され、互いに独立して進化できることが保証されます。複数のサービスが同じデータにアクセスしている場合、スキーマの更新にはすべてのサービスに対する調整された更新が必要になります。これは、マイクロサービスのライフサイクルの自律性を壊すことになります。

サービスが別のサービスによって保存されたデータにアクセスしたい場合は、そのサービスに必要なデータを要求する必要があります。データ ストアに直接アクセスせずに、他のマイクロサービスからデータを取得できます。したがって、どのデータを共有するか非表示にするかを決定できます。

このようにして、各マイクロサービスが他のマイクロサービスについての知識をできる限り少なくすることで、疎結合が増加します。したがって、マイクロサービス アーキテクチャでは、本当に必要な場合を除き、データベースを共有しないでください。

独立してスケーラブル

マイクロサービス アーキテクチャの疎結合と独立した展開機能のおかげで、選択的またはオンデマンドのスケーリングを実行できます。 1 つのマイクロサービスで高負荷が発生し、すべてのリクエストの処理が困難な場合は、通常は大規模なエンタープライズ システム全体のハードウェア容量をスケールアップすることなく、そのマイクロサービスをより多くのリソースを持つ環境に再デプロイまたは移動できます。

より優れた障害分離

モノリス アーキテクチャにおける単一のエラーは、システム全体をダウンさせる可能性があります。可能な限り可用性のあるシステムを設計する必要があるため、マイクロサービス アーキテクチャではこれを回避する必要があります。

マイクロサービス エコシステムはいつかは失敗するため、失敗を受け入れる方法を学ぶ必要があります。年間を通じて晴天が続くという前提でシステムを設計しないでください。現実的になって、雨、雪、雷雨、その他の悪条件が発生する可能性を考慮してください。つまり、障害を念頭に置いてマイクロサービスを設計してください。物事は常に計画通りに進むわけではないため、最悪のシナリオに備える必要があります。

アーキテクチャには多数のマイクロサービスを含めることができます。これらのマイクロサービスは、ネットワーク経由で相互に通信し、要件を実行します。サービス間のやり取りの数が増えると、失敗する可能性も高くなります。したがって、マイクロサービスを可能な限りフォールトトレラントに設計する必要があります。

1 つのサービスに障害が発生しても、システム全体に障害が発生しないようにする必要があります。

これらの問題を考慮してマイクロサービス アーキテクチャを設計すると、マイクロサービスはモノリシック アプリケーションよりも耐障害性が高くなる傾向があります。これは、単一のアプリケーションではなく、分離された自律的なサービスが多数存在するためです。

Google や Netflix などの非常に有名な企業では、障害を引き起こすプログラムを作成し、それを Netflix の運用環境で日常的に実行することで、システムによって障害がシミュレートされています。Google は、毎年恒例の DiRT(災害復旧) の一環として大規模災害をシミュレートしています。テスト）演習。

シミュレーション用に Netflix によって作成されたいくつかのプログラム、Simian Army を見てみましょう:

• Chaos Monkey は、 1 日の特定の時間帯にランダムなマシンをオフにします。
• Chaos Gorilla は、可用性センター (AWS のデータセンターに相当) 全体を破壊するために使用されます。
• Latency Monkey は、マシン間の低速ネットワーク接続をシミュレートします。

彼らは何を提供してくれるのでしょうか

これらのシミュレートされた問題が本番環境でも発生する可能性があり、実際に発生することがわかっているということは、システムを作成する開発者が実際にその問題に備える必要があることを意味します。

重要な点は、起こり得る失敗を受け入れて引き起こし、これらの問題に対処するソフトウェアを構築する必要があるということです。システムを拡張してより適切に拡張するには、これらのシミュレートされた障害から教訓を学ぶことが非常に重要です。

何か問題が発生する可能性が常にあることを認識することが重要です。システムがネットワーク (信頼性が低くなります) を介して複数のマシン (障害が発生する可能性があり、障害が発生する可能性があります) に分散しているという事実は、システムの脆弱性を軽減するどころか、さらに脆弱にする可能性があります。より分散されたアーキテクチャで発生する種類の障害に備えることは非常に重要です。

新しいテクノロジーを採用する

マイクロサービス アーキテクチャにより、テクノロジー スタックへの長期的な取り組みが不要になります[24]。各サービスは自律しているため、開発者はビジネス ニーズに最適な言語を自由に使用できます。

マイクロサービスの欠点

特効薬となるテクノロジーはありません。マイクロサービス アーキテクチャには、多くの重大な欠点があります。

より複雑な

マイクロサービス アーキテクチャを設計する際、開発者はさらなる複雑さに対処する必要があります。

モノリスでのメソッド呼び出しの代わりに、マイクロサービスはプロセス間通信メカニズムを使用する必要があります。これは、ネットワーク上での通話の送受信には、モノリス内の通話よりも多くの時間が必要であることを意味します。

マイクロサービスは、HTTP ベースの REST や gRPC などの同期リクエスト/レスポンス ベースの通信メカニズムを使用できます。あるいは、AMQP や STOMP などの非同期のメッセージベースの通信メカニズムを使用することもできます。

同期通信では、あるマイクロサービスがリクエストを送信し、指定された時間枠内の応答を期待することによって、別のマイクロサービスを呼び出します。サービスを呼び出し、呼び出されたサービスからの応答を待機すると、実行がブロックされ、呼び出されるサービスへの暗黙的な依存関係が作成されます。したがって、より同期的な要求と応答の対話が行われると、マイクロサービス間の結合が強化されます。

既存のサービスの数が少ないため、同期依存関係の影響を感じられない場合があります。ただし、要求/応答パターンで通信するサービスの数が増えると、依存するサービスのチェーンが大きくなるため、実行の遅延が増加します。可用性を最大化したい場合は、同期通信の量を最小限に抑える必要があります。

同期アプローチの強力な代替手段として、非同期通信では、あるマイクロサービスが応答を期待せずにメッセージを送信することによって別のマイクロサービスと通信します。ここで、2 つのマイクロサービスは、メッセージ ブローカーやイベント ブローカーなどのサードパーティ コンポーネントを介して相互に通信します。このコンポーネントは、ソース/プロデューサー マイクロサービスからメッセージを受信し、コンシューマーに送信します。コンシューマーは、メッセージ ブローカーを介して、関心のあるメッセージを消費します。

非同期通信では、サービスが別のジョブを続行できるため、ブロックや応答の待機が発生しません。ここで重要な点は、別のサービスの問題によってこのサービスが中断されるわけではなく、他のサービスが一時的に中断された場合、呼び出し側のサービスはプロセスを完全に完了できない可能性がありますが、呼び出し側のサービス自体は中断されていないということです[25]。したがって、非同期メッセージングを使用すると、サービスがより分離され、より自律的になります。

ただし、非同期メッセージングの欠点に注目すると、メッセージを送信して処理するためのメカニズムが必要となるため、システムのインフラストラクチャが複雑になります[26]。ドメイン イベントのフローの設計が不可欠になり、問題の監視とデバッグが困難になります。

現実の世界では、これらの通信パターンを同時に一緒に使用できます。

マイクロサービスは、相互に通信するためにネットワークに大きく依存します。これにより、応答時間 (ネットワーク遅延) が遅くなり、ネットワーク トラフィックが増加する可能性があります。さらに、複数のマイクロサービスが相互に通信しているときに発生するエラーを追跡するのが難しい場合があります。

監視とデバッグの難しさ

モニタリングについて深く掘り下げる前に、可観測性とモニタリングは近い概念であるため、これらを定義することをお勧めします。

ソフトウェア アプリケーションのコンテキストにおける可観測性とは、新しいコードをデプロイすることなくシステムの状態を理解して説明できる能力を指します。

モニタリングとは、システムの状態を認識するプロセスを指します。
適切に監視すると、システム障害が発生する前に問題を検出できます。

したがって、監視はシステムの状態を追跡することだけに焦点を当てていますが、可観測性はシステムを理解してデバッグするためのツールも提供します。たとえば、監視自体は障害の兆候を検出するのには優れていますが、その根本を説明するのにはそれほど役立ちません。

障害が予測できることはほとんどなく、本番環境での複雑なアプリケーション エラーの正確な原因を検出することは非常に困難です。アプリケーションの開発中は、アプリケーションがダウンしてデータ損失の危険が生じる可能性のあるシナリオを予測しようとします。したがって、アプリケーションを観察および監視して、できるだけ早く障害を検出できることが重要です。

可観測性と監視は、マイクロサービスの世界では重要な概念です。マイクロサービスアーキテクチャではサービスが多くなり、エラーの検出が困難になります。システムをよく観察して監視しないと、既存のすべての殺人が発見できない殺人者を生み出してしまいます。殺人を犯した犯人を見つけるには、優れた探偵である必要があります。

アプリケーションは複数のサーバーとデバイスに分散しているため、マイクロサービス ベースのアプリケーションの監視とデバッグは困難になる場合があります。

コードの限定的な再利用

マイクロサービスでは、コードを再利用する機能も限られています。

「同じことを繰り返さない」という重要なクリーンコード原則に対する視点を更新する必要があります。

あなたの新しい友達を紹介しましょう: WET (毎回書くか、すべてを 2 回書く)。

WET の重要な点は、共有コードの量を減らすことです。マイクロサービスは通常、結合を避けるためにコードを再利用するよりも複製することを好みます。各マイクロサービスは小規模で専用に構築されており、組織の特定のビジネス目標に役立ちます。これは、独立したビジネス ロジックを含む独自のドメインを持っていることを意味します。

たとえば、各マイクロサービスがビジネス環境のニーズに基づいて独立して進化するときに、異なる問題を解決するために異なるビジネス ロジックを持つマイクロサービスで同じ機能を使用すると、同じ機能を共有するためアプリケーションが破損します。この機能は、両方のマイクロサービスのビジネス ロジックのニーズを満たすことができません。共有関数で考えられるすべてのユースケースに対処するのは非常に難しいため、コードの再利用はあまり役に立ちません。

DevOps への依存

マイクロサービスで成功するには、組織は強力な DevOps チームを配置する必要があります。これは、DevOps がマイクロサービスのデプロイと管理を担当しているためです。

優れた DevOps チームがなければ、マイクロサービス ベースのアプリケーションを適切に実装して管理することが困難になる可能性があります。

モノリシック アーキテクチャとマイクロサービス アーキテクチャの概要

モノリスからマイクロサービスへの移行

「穴の法則」について聞いたことがありますか
それは単に「穴にはまったことに気づいたら、掘るのをやめなさい」と述べているだけです。

これは、モノリシック アプリケーションが管理できなくなったときに従うべき非常に優れたアドバイスです。大規模で複雑なモノリシック アプリケーションがある場合は、新しい機能を実装しないでください。そんなことをすると、すでに複雑なシステムがさらに複雑になってしまいます。

したがって、アプリケーションはさらに大きくなり、管理できなくなります。代わりに、新しい機能をサービスとして実装できます。

モノリスからマイクロサービスへの移行を検討する必要がある状況がいくつかあります。

小型化と素早いリリース

お客様やステークホルダーの要望に終わりはありません。

彼らは常に新しい機能を求めています。

これらの変更を迅速かつ確実に開発する必要があります。モノリスでは、アプリケーション全体を巨大なテスト スイートで検証してデプロイする必要があるため、アーキテクチャで新機能をリリースするのは非常に困難です。

リリースが小さいほどリスクは少なくなります。

小さな変更を加えると、発生した問題を見つけて修正するのがはるかに簡単になります。マイクロサービス アーキテクチャにより、小さな変更でアプリケーションを簡単にデプロイできます。マイクロサービスを毎晩デプロイすると想像してください。この定期的かつ自動的な導入により、問題や機会に迅速に対応できるため、顧客と関係者との間により深い関係が得られます。アプリケーションをデプロイするために、もうブルームーンを待つ必要はありません。ソフトウェアのリリースは迅速であるべきであり、多額の費用がかかるものであってはなりません。

スケーラビリティ

あなたの顧客は増えています。それはあなたの会社の利益にとって非常に良いことです。

ただし、モノリス システムでは顧客のすべての要求を処理できるわけではありません。顧客への対応が非常に遅く、顧客からの苦情が増えています。システムを拡張する必要があります。よりコスト効率の高い方法でシステムを拡張したいと考えています。

マイクロサービスを使用すると、サービスを個別にスケールできます。これは、高負荷時のサービスのみをスケールアップできることを意味します。また、負荷が低いサービスをスケールダウンできることも意味します。これが、SaaS 製品を構築する多くの企業がマイクロサービス アーキテクチャを採用している理由の 1 つです。これにより、運用コストをより細かく制御できるようになります。

新しいテクノロジーを採用する

通常、モノリスはテクノロジーの選択肢を制限します。

1 つの展開プラットフォーム、1 つのオペレーティング システム、および 1 種類のデータベースに固定されています。

マイクロサービス アーキテクチャでは、サービスごとにこれらの選択を変更するオプションが得られます。新しいテクノロジーを安全な方法で試せる柔軟性は、顧客により良い結果を提供するという点でも、開発者が新しいスキルを習得する際に満足感を維持できるという点でも、競争上の優位性をもたらします。

結論:

モノリシック アプリケーションとマイクロサービス アプリケーションのどちらを選択するか、いつどのように選択するか

スタートアップは資金が限られていることと、できるだけ早く最初の成功を収めたいという欲求から、モノリシック アプリケーションで開発を開始することがあります。

モノリシック アーキテクチャでは:

• ビジネスフローがより可視化される
• モノリシックアプリケーションを簡単に監視できます
• 問題を簡単に検出できます

これらすべてが、最初の成功を達成する上で大きな利点となります。

さらに、コードの再利用を有効にすることで、異なるモジュールで同じコードを使用できます。これにより、コードの重複が減り、効率が向上します。したがって、1 つのアプリケーションのニーズのみを考慮してパイプラインを簡単にセットアップできます。

ただし、穴が深くならないように、掘るのをやめたほうがよい場合もあります。コードが巨大になると、アプリケーションをデプロイするたびに、リリース サイクルが長くなるために作業がより困難になります。ここで、マイクロサービスベースのアーキテクチャを考慮する必要があります。

アプリケーションが大きな泥の団子にならないようにすることが非常に重要です。1 つの小さな変更でアプリケーション全体がダウンするリスクが増大するためです。

• アプリケーションが増加するリクエストを処理できなくなったらどうしますか。
• モノリス アプリケーションのスケーリングについて考えていますか。

申し訳ありませんが、悪いお知らせがあります。スケーリングが必要なモジュールの一部ではなく、アプリケーション全体をスケーリングする必要があるため、より困難でコストがかかります。

モノリス アーキテクチャをマイクロサービス アーキテクチャに移行することをまだ考えていますか。それを行う前に、マイクロサービスのメリットとデメリットを考慮してトレードオフを行う必要があります。

マイクロサービス アーキテクチャを使用すると、大規模で複雑なアプリケーションを独立して継続的にデプロイできます。

自動テストがあり、小さな変更を加えるたびに、すべての自動テストに合格すれば、アプリケーションを簡単にデプロイできます。そうでない場合でも、フィードバックが迅速に得られるため、バグを簡単に検出できます。

覚えて！リリースが小さいほどリスクは少なくなります。

さらに、チームは自律的にサービスを開発できます。これにより、チームを簡単に拡張でき、他のチームと調整することなくサービスを開発、デプロイ、拡張できるようになります。

各マイクロサービスのコードベースが小さいため、コードの理解と保守が容易になります。チームの生産性が向上します。各マイクロサービスには独自のデータベースがあり、各マイクロサービスは独自のデータベースにアクセスできるため、マイクロサービスは独立して進化できます。

こうすることで、マイクロサービスのライフサイクルの自律性が損なわれることはありません。自律性と独立した展開が可能であるため、アプリケーション全体をスケールする必要はありません。これは、高負荷下でサービスを拡張する場合にのみ効率的な方法になります。

優れた障害分離を備えたシステムを設計する機会もあります。したがって、1 つのサービスが失敗してもシステム全体が失敗しないようにする必要があります。失敗を受け入れ、これらの失敗に対処できるシステムを設計すれば、マイクロサービス アーキテクチャの最も重要な利点がわかります。それは、単一のバグでシステムがダウンすることがなくなることです。

単一のテクノロジーだけに依存する必要はもうありません。ビジネス ニーズに応じて、任意のプログラミング言語を使用してマイクロサービスを開発できます。

しかし、繰り返しになりますが、大きな力には大きな責任が伴います。マイクロサービスを使用してアプリケーションを開発する場合は、問題に対処するために最善を尽くす必要があります。

単一のコードベースがなくなるため、アーキテクチャはより複雑になります。ネットワークを介したマイクロサービス間の通信により、アーキテクチャがより複雑になります。同期通信と非同期通信、およびその利点と欠点に関する包括的な知識が必要です。ネットワークを介した通信のため、複数のマイクロサービスが相互に通信しているときに発生するエラーを追跡するのが難しい場合があります。アプリケーションの監視とこれらのエラーのデバッグはより複雑になります。

殺人事件を引き起こしたり、見つからない殺人者を生み出したりすることは望ましくありません。

マイクロサービス ベースのアーキテクチャでは、マイクロサービス間の結合を防ぐためにコードを共有すべきではないことに留意する必要があります。マイクロサービスベースのアーキテクチャには、強力な DevOps チームが必要です。複数のマイクロサービスのニーズに対応するパイプラインを作成する必要があります。これは、すべてのマイクロサービスに独自のリリース サイクルがあることを意味します。 DevOps チームはそれを提供する責任があります。

アプリケーションを構築するときは、この包括的なガイドで説明されているすべての利点と欠点を考慮して、アーキテクチャを慎重に選択する必要があります。トレードオフを行うことはソフトウェア開発の中心です。

忘れないで！この世に特効薬はありません。

---

顧客デジタルエクスペリエンス ソリューション [オムニチャネル発送代行]

オムニチャネルコマースビジネスに適した顧客の購入（購買）体験ニーズ に添ったオペレーションを設計・構築するツールを選定したら、 富士ロジテックホールディングスの EC物流サービス ・物流・発送代行 ・返品・交換 サービスをその施策の一部として活用することを検討してください。

富士ロジテックホールディングスがDNVBとその一カテゴリーDTC/D2C 3.0 コマースビジネスに提供するものには

• 全国のフルフィルメント センターからの D2C（DTC） および B2B注文の EC:eコマース フルフィルメント
  (ビジネスに最適なフルフィルメント センターを選択使用可能)
• 標準および 配達予定日 指定のeコマース配送サービス
• eコマースの商品の 配送情報 の提供と、 注文/追跡情報 と返品対応
• 思い出に残る 開梱体験：Unboxing を提供するキッティングおよびカスタマイズ サービス
• データ分析により、顧客のe コマースの配送方法、顧客の支出金額、配送方法ごとの平均コスト、配送方法ごとの注文の配達にかかる時間、返品理由などについての顧客のインサイト：洞察の提供
• 越境ECに伴う、国際 eコマース配送 (米国、カナダ、英国、欧州連合、オーストラリ、アジアなど、その他の国へ)

富士ロジテックホールディングスが連携、推奨するコマースソフトウェアは、 プラットフォームシステム、 マーケットプレイス、EDI ソリューション (小売業者の Webサイトや店舗での注文を処理するため)、およびその他の販売チャネルと統合して、e コマース、 オムニチャネルの フルフィルメントを自動化します。

富士ロジテックホールディングスを利用・活用すると、日本中に フルフィルメント センター のネットワークを通じて、 小売・製造事業者 は、商品在庫を 分散保管・分散出荷 サービスを活用して、e コマースの配送コストと配達時間を削減することができます。

D2Cビジネスサポート：相談・問い合わせ

 

オムニチャネルコマースシステム＆フルフィルメント戦略:

オムニチャネルコマースシステム＆フルフィルメント は、購入・販売チャネルとフルフィルメントセンターを統合して、顧客にまとまりのある ショッピングエクスペリエンス を提供します。

次世代オムニチャネルサービスを通じて、 成功する D2C チャレンジャー ブランド をはじめとして、 購入後の体験（Post-Purchase ポストパーチェス） の向上に注力すると、エンゲージメントと 顧客ロイヤルティ が向上し、リピート購入と顧客維持の可能性が高まります。

 

AOV・CLVを向上させる多彩なサービスを提供します。

• Lexica オムニチャネルコマースから、再販・リコマースまで対応するMACH・コンポーザブルコマースシステム
• E-Aspro 通販からEコマース向け ERP: 定義、機能、メリット（通販基幹システム）　
• エスキュービズム「EC-ORANGE」
• 店舗販促・EC販促専用のCRM・MAツール「EC Intelligence」

お気軽にご相談ください。Shopifyなどのフィット＆ギャップ　アドバイスをします。

商品追跡情報・配送予定日設定・返品・交換・修理、特別問い合わせ/ご相談

 

通販・ D2C・ Eコマース 事業者の EC物流代行・発送代行 ・オムニチャネル コマースでの流通加工から店舗物流までを、
一般社団法人 通販エキスパート協会 ：「通販CXマネジメント」・「フルフィルメントCX」認定スペシャリスト メンバーとスタッフがサポート致します。

全国11拠点のDC/FCから、先進 RaaSマテハンロボット ・RFID などと、注文管理システム（OMS）・倉庫管理システム（WMS）とコマースシステム をAPIで連携して、 物流・発送代行サービス を「スタートアップ特別限定プラン から、100億円を超える事業者に最適な 分散保管・分散出荷、 返品・交換 サービスまでを一貫でデザインする「 顧客購買後体験 」によって、LTVの向上が実現できる「 感動物流サービス 」を提供中です。物流業界の最新トレンドを盛り込んだ お役立ち資料 も無料でご提供しています。

購入後体験（ポストパーチェス）　顧客中心のエクスペリエンスのために