By Marco Fioretti
マイクロサービスは、 ソフトウェア開発者が高度にスケーラブルでフォールトトレラントなインターネットベースのアプリケーションを設計できるようにします。しかし、プラットフォームのマイクロサービスは実際にどのように通信するのでしょうか。彼らはどのように彼らの活動を調整するか、またはそもそも誰と協力するかを知っていますか？ここでは、これらの質問に対する主な回答と、それらの最も重要な機能と欠点を示します。このトピックを掘り下げる前に、このシリーズの以前のblog、 Microservices: Definition and Main Applications, APIs in Microservices、およびIntroduction to Microservices Securityを最初に読んでおくとよいでしょう。.
密結合、オーケストレーション、コレオグラフィー
すべてのマイクロサービスが、仲介なしですべてのパートナーマイクロサービスと直接通信できて、かつ通信しているとき、密結合と呼びます。密結合は非常に効率的ですが、すべてのマイクロサービスがより複雑になり、変更や拡張が困難になります。さらに、マイクロサービスの1つが機能しなくなると、すべてが機能しなくなります。
密結合のこれらの欠点を克服する１番目の方法は、オーケストラの指揮者のように、すべてのマイクロサービスのうち一つの中央コントローラを用意するか、または少なくともいくつかのマイクロサービスを用意して、あたかもオーケストラの指揮者のように同期して動作させることです。このオーケストラのような仕組みでは、 - 要求/応答とも呼ばれる – 要求を発行し、回答を受け取り、次に何をするかを決定するのは指揮者です。つまり、他のマイクロサービスにさらにリクエストを送信するか、その作業の結果を外部ユーザーまたはクライアントアプリケーションに渡すかを決定します。.
オーケストレーションの補完的なアプローチとして、コレオグラフィーと呼ばれる分散型アーキテクチャがあります。これは、一緒にバレエを踊るダンサーのように、独立して動作していますが、それぞれが責任を持つ複数のマイクロサービスで構成されています。コレオグラフィーでは、事前に定義された共通するルールに従って複数のマイクロサービス間を流れるメッセージを介して、中央の監視なしで調整が行われます。
これらのメッセージ交換、および利用可能なマイクロサービスと通信方法の検出は、イベントバスを介して行われます。これらを行うのは、イベントをサブスクライブおよびサブスクライブ解除し、イベントを公開するための明確に定義されたAPIを備えたソフトウェアコンポーネントです。これらのイベントバスは、XML, SOAP、または Webサービス記述言 語（WSDL）などの標準を使用してメッセージを交換するために、いくつかの方法で実装できます。
マイクロサービスがバス上でメッセージを送信すると、対応するイベントバスでリッスンするようにサブスクライブしたすべてのマイクロサービスはメッセージを確認し、非同期で応答すべきか、および応答する方法を、それぞれ個別に順不同に知るのです。このイベント駆動型アーキテクチャでは、すべての開発者がマイクロサービスをコーディングするときに、プラットフォームの残りの部分と対話できるようにする必要があります。具体的には、イベントバス上にイベントの生成、またイベントの待機をするサブスクリプションコマンドです。
オーケストレーションまたはコレオグラフィー？ それは場合によります
マイクロサービスで最も一般的な2つの調整の選択肢は、コレオグラフィーとオーケストレーションです。これらの基本的な違いは、制御をどこで行うか、にあります。一方は、非同期で通信するピアマイクロサービスに分散し、もう一方は、他のすべてのマイクロサービスを指揮する1つの中心になるコンダクターが制御します。
どちらが優れているかは、各プラットフォームの実際の使用の特性、ニーズ、およびパターンに依存します。すべての場合に適用されるルールは2つだけです。 1つ目は、マイクロサービスの考え方に反するため、実際の密結合はほとんどの場合回避する必要があるということです。一方、非同期通信を用いた疎結合は、デプロイメントの独立とスケーラビリティの最大化というマイクロサービスの基本的な利点とはるかによく一致します。ただし、現実の世界はもう少し複雑なので、各アプローチの長所と短所についてもう少し説明しましょう。
オーケストレーションに関する限り、その主な欠点は、集中制御が、同義語ではないにしても、少なくとも単一障害点へのショートカットであることが多いことです。オーケストレーションで、しばしばありえる欠点は、マイクロサービスとコンダクターが異なるサーバーまたはクラウド上にあり、パブリックインターネットを介してのみ接続されている場合、ネットワーク性能が本当に良くないと、パフォーマンスが予想外に低下する可能性があることです。違うレベルで見ると、オーケストレーションを使用すると、実質的にマイクロサービスを追加したり、ワークフローを変更したりする場合、コンダクターだけでなく、プラットフォームの多くの部分を変更する必要があります。同じことが障害にも当てはまります。オーケストレーションされたマイクロサービスに障害が発生すると、一般にカスケード効果が発生します。たとえば、コンダクターが障害のあるマイクロサービスからの応答を一時的に待機しているため、他のマイクロサービスがメッセージの受信待ち状態になってしまうことがおこります。プラス面としては、「コマンドのチェーン」と通信が明確に定義されており、柔軟性が低いため、何がどこで壊れたかを比較的簡単に見つけることができます。まったく同じ理由で、オーケストレーションは個別の機能の独立したテストを容易にします。したがって、マイクロサービスベースのプラットフォーム内の通信フローが明確に定義されており、比較的安定している場合は、オーケストレーションが最適な方法となる可能性があります。
他の多くの場合、コレオグラフィーは、個々のマイクロサービスの独立性、全体的な効率、および開発の単純さの間で最良のバランスを提供する可能性があります。
コレオグラフィーでは、サービスはイベント、つまり何かが起こった（たとえば、ログイ ン要求が受信された）通信のみを発行する必要があり、そのすべてのダウンストリームマ イクロサービスは自律的にそれに応答する必要があります。したがって、マイクロサービ スを変更しても、アップストリームのマイクロサービスには影響しません。マイクロサー ビスの追加または削除でさえ、オーケストレーションの場合よりも容易です。逆に見ると 、事前によく検討せずにそれ(マイクロサービスの追加、削除)を実行すると、より多くの 場所で、予測、テスト、またはデバッグが困難な形で、問題が発生する可能性が高くなる ことです。すべてがうまくいくことを期待してインターネットにメッセージを投げても、 すべての 受信者がうけとり、すべてのメッセージに正しく対応できることに確信を持てないばあい、システムインテグレータは大変な苦労をすることになります。
結論
特定のワークフローは、その性質上、高度に同期的で予測可能です。そうではないものもあります。このことは、両方のアプローチを組み合わせることで、多くの実際のマイクロサービスプラットフォームがパフォーマンスと障害またはピーク負荷に対する耐性を持たせるの最良の組み合わせを得ることができ、そうすべきであることを意味します。これは、一時的なピーク負荷（コレオグラフィーで最適に処理される可能性があります）がプラットフォームの特定の部分でのみ発生する可能性があり、最も深刻な結果を伴う障害が発生する可能性があるためです。(エンドカスタマーによる製品と、同じ製品をまとめて購入して倉庫に補充する注文との比較）。システムアーキテクトにとって、起こりうる最悪の事態は、オーケストレーションまたはコレオグラフィーのいずれかを用いて、アーキテクチャを設計するにせよ、 無意識のうちに （おそらく、既存のモノリシックプラットフォームをマイクロサービスに移植しているだけなので）、何かがうまくいかなかったり、新しい要件が設計やテストで予想よりもはるかに難しいことが判明した場合、厄介なことになることです。これは、上記の2つの一般的なルールの2番目につながります。マイクロサービスの実際の負荷と通信のニーズを可能な限り見積もってから、マイクロサービスのオーケストレーションとコレオグラフィーのどちらかを選択してください。
マイクロサービスの詳細については、次のような無料のトレーニングコースを検討してください。 Introduction to Cloud Infrastructure Technologies, Building Microservice Platforms with TARS、および WebAssemblyアクター：クラウドからエッジへ.
