サービスメッシュ

サービスメッシュでは，システムで実行している2つ以上のサービス間のコネクティビティを構築する方法を根本的に改善するパターンを特定します。サービスが別のサービス（例えば，データベースを利用するモノリスや別のマイクロサービスを利用するマイクロサービス）にネットワークリクエストを送信するたびに，リクエストを安全かつ観測可能にすることにより，そのネットワークリクエストに対処します。

パターンとしてのサービスメッシュは，（⁠モノリシックやマイクロサービス指向の）任意のアーキテクチャおよび任意のプラットフォーム（VM，コンテナ，Kubernetesなど）に適用できます。

この点で，サービスメッシュは新しいユースケースを追加しませんが，サービスメッシュを導入する前に管理していた既存のユースケースを適切に実装できます。サービスメッシュを実装する前も，アプリケーションチームはセキュリティ，可観測性，エラー処理などのトラフィックポリシーをアプリケーション内に実装して，アプリケーションが送信または受信するアウトバウンドまたはインバウンドのネットワークリクエストのコネクティビティを強化していました。アプリケーションチームは，自身のサービスで多くのコードを記述することにより，これらのユースケースを実装していました。つまり，異なるチームが異なるプログラミング言語で何度も繰り返して同じ機能を実装して，組織にネットワークコネクティビティの管理における断片化とセキュリティリスクをもたらしていたのです。

サービスメッシュパターンでは，任意のサービス（構築したサービスだけでなくデプロイしたサードパーティのサービスを含む）により行われたインバウンドまたはアウトバウンドのリクエストのネットワーク管理を，すべてのインバウンドおよびアウトバウンドのネットワークリクエストを管理するアウトプロセスアプリケーション（プロキシ）にアウトソーシングしています。プロキシはサービスの外部に存在するため，任意の言語またはフレームワークで記述された任意のサービスをサポートします。プロキシはすべてのリクエストの実行パス上にあるため，データプレーンプロセスです。ユースケースの1つはエンドツーエンドでmTLS暗号化と可観測性を実装するため，プロキシの1つのインスタンスをすべてのサービスとともに実行して，アプリケーションチームが余分な作業を行うことなく，これらの機能をシームレスに実装できるようにします。

データプレーンプロキシはすべてのサービスのすべてのレプリカとともに実行されるため，サービスメッシュを（集中型デプロイのAPIゲートウェイパターンと対比して）分散型デプロイと呼ぶ人もいます。ネットワークにホップを追加してレイテンシを最小限に抑えるため，実行しているサービスと同じマシン（VM，ホスト，Pod）でデータプレーンプロキシを実行します。理想的には，プロキシのメリットが十分あり，レイテンシが十分低い場合，組織にサービス間のネットワークコネクティビティの管理における断片化をもたらすよりも，プロキシを利用するほうを選択すべきです。

プロキシアプリケーションは，リクエストが発信の場合はプロキシとして機能し，リクエストが着信の場合はリバースプロキシとして機能します。サービスの各レプリカでプロキシアプリケーションの1つのインスタンスを実行するため，システムでは多くのプロキシを実行することになります。これらをすべて構成するには，施行する構成と動作の真実を語る資料として機能し，プロキシに接続して構成を動的に伝えるコントロールプレーンが必要です。コントロールプレーンはプロキシにのみ接続するため，サービス間のリクエストの実行パス上にはありません。

サービスメッシュパターンは，すべてのサービスの各インスタンスにデータプレーンプロキシをデプロイし，アプリケーションをデプロイするとき実質的にCI/CDジョブを更新する必要があるため，APIゲートウェイパターンよりも処理が多くなります。サービスメッシュには他のデプロイパターンもありますが，最高の可用性を保証し，すべてのサービスのすべてのレプリカに一意のIDを（mTLS証明書で）割り当てることができる上記のパターン（サービスレプリカあたり1つのプロキシ）が業界標準と見なされています。

サービスメッシュでは，基本的に1つの主要ユースケースに対処しています。

1．サービスコネクティビティ

ネットワーク管理をサードパーティのプロキシアプリケーションにアウトソーシングすることにより，チームは独自のサービスにネットワーク管理を実装する必要がなくなります。プロキシを利用して，組織が採用しているがゼロから構築していないデータベースなどのサードパーティのサービスを含む，デプロイするすべてのサービスとワークロードに，相互TLS暗号化，ID，ルーティング，ロギング，トレーシング，ロードバランシングなどの機能を実装できます。

組織内のサービスコネクティビティは多くのプロトコルで実行されるため，完全なサービスメッシュの実装はHTTPだけでなく他のTCPトラフィックも（North-SoutまたはEast-Westに関係なく）理想的にサポートします。サービスメッシュは広範なサービスをサポートしてL4/L7トラフィックポリシーを実装しますが，APIゲートウェイはこれまでL7ポリシーにのみ焦点を当ててきました。

概念的には，サービスメッシュはシステムで動作しているワークロードの非常に単純なビューですが，すべてがサービスであり，サービスは互いに対話できます。APIゲートウェイはリクエストを受信および送信するサービスでもあるため，APIゲートウェイはメッシュ内のサービス間の1つのサービスと言えます。

すべてのサービスのすべてのレプリカにはデータプレーンプロキシが必要です。データプレーンプロキシは実質的にロードバランサであり，他のプロキシ（他のサービス）への発信リクエストをルーティングできるため，L4/L7ルーティング機能を実行できるようにサービスメッシュのコントロールプレーンは各プロキシのアドレスを知っている必要があります。アドレスは，サービス名などの任意のメタデータに関連付けることができます。そうすることにより，サービスメッシュはサードパーティのソリューションを必要としないビルトインサービスを本質的に提供します。サービスディスカバリツールはメッシュの外部の通信には使用できますが，メッシュの内部のトラフィックには使用できません。