ブログ | CTO オフィス

マイクロサービス: マイクロサービスを減らしてサービスを増やす

ロリ・マクヴィッティ サムネイル
ロリ・マクヴィッティ
2018年10月1日公開

サービス指向アーキテクチャ (SOA) は、ほぼ 10 年前に廃止されたと宣言されました。 その終焉の一因となった(しかしほとんど議論されなかった)要因はネットワークであった。 サービス間の遅延により、アーキテクトは、再利用を促進し、最終的には構成可能なアプリケーションを実現するために必要な粒度でアプリケーションをサービスに完全に分解することができませんでした。

マイクロサービス アーキテクチャ (MSA) の登場です。 その原則では、アプリケーションを分割するための主な基準として、オブジェクト (名詞) よりも機能 (動詞) に重点を置き、さらに細分化することを要求します。 この一見微妙な焦点の変化により、サービスの粒度がさらに細かくなり、特定のシステム内のオブジェクトの数よりも多くの機能が存在します。

ネットワークの準備ができました。 物理ネットワークの速度とフィードは劇的に向上しました。 コンピューティングもムーアの法則に従って進歩し、ネットワークの遅延はほとんど問題ではなくなりました。

残念ながら、その代わりに通信遅延が発生します。

マイクロサービスを展開するために使用されるコンテナ環境の内部に、インターネットの複雑さを再現しました。  マイクロサービスは DNS を必要としないかもしれませんが、それでもインターネットを実行するのと同じ種類の名前ベースの解決に依存しています。 アプリケーション タグ (メタデータ) は IP アドレスに変換する必要があります。 サービス レジストリと複雑な IP テーブル エントリは、小型の DNS として機能し、タグをアドレスに変換して、サービス間の通信を可能にします。

このプロセスに関連するレイテンシを悪化させるのは、マイクロサービスとそれに関連するコンテナの一時的な性質です。 有効期間が時間や月ではなく秒や分単位で測定されるため、すべての呼び出しで名前解決を実行する必要があります。 コンテナの世界では、存続時間 (TTL) は実質的にゼロです。

通信遅延の最大の原因の 1 つであるこの再現を無視したとしても、TCP に関連するものが残ります。 TCP 接続を開始したり切断したりすることは、これまでも、これまでも、自由ではありません。 この遅延の原因は確かに小さいですが、間違いなく追加されます。 単一のトランザクションを実行するために必要な各接続 (各マイクロサービス) によってレイテンシが増加し、最終的には遅延の許容範囲を超えてしまいます。

HTTP/2 は、動作が劇的に変化したにもかかわらず、この問題には対処していません。 HTTP/2 は、同じ接続を介して複数のオブジェクトの転送を容易にするように設計されており、Web ページや Web ベースのアプリケーションなどの複数オブジェクト コンテンツの待ち時間を短縮します。 マイクロサービスは、各サービスが単一の応答を返すように理想的に設計されています。 確立された接続を介して複数のリクエストを行うと、通信のオーバーヘッドは確実に削減されますが、複数のリクエストが複数の個別のサービスに分散されるシステムでは、そうすることはできません。

つまり、問題はネットワーク遅延ではなく、通信遅延です。 接続は依然として重要であり、Web ベースのマルチトランザクション通信のパフォーマンスを向上させるように設計されたプロトコルの改善は、マルチサービス トランザクションには役立ちません。

その結果がSOMAです。 サービス指向のマイクロアーキテクチャ。 サービス指向アーキテクチャとマイクロサービス アーキテクチャの奇妙なハイブリッドであり、どちらが終わり、どちらが始まるのか疑問に思うほどです。 アプリケーションを複合機能ベースのサービスに分解することは、通信の遅延と、最終的にはコード ベースの持続可能性によって制約されます。 確かに、ネットワークの進歩により、分解を合理的に実行できる粒度は向上しましたが、制約は解消されていません。 また、アプリケーションにはオブジェクトよりも桁違いに多くの関数が存在することも要因の 1 つです。このため、純粋なマイクロサービス アーキテクチャのアプリケーションを管理するタスクは、アプリ開発者はもちろん、ネットワーク運用にとっても、ある種のロジスティックな悪夢となります。 通信遅延によって生じる固有の問題と相まって、組織は真の機能指向のマイクロサービスではなく、オブジェクト指向のマイクロサービスを開発するケースが増えています。 

これが、アプリケーションが従来の 3 層アーキテクチャを超えて分解される理由ですが、機能ベースの分解を忠実に表現するほどには至っていません。

接続ベース (TCP) 通信に固有の遅延の問題に、何か新しいもの、またはシステム レベルの実装に焦点を絞ることで対処するまでは、マイクロではなくサービスであるマイクロサービス アーキテクチャに制限され続けることになります。