サービスメッシュに関する記事を読んだことがある人なら、Envoy というオープンソースプロジェクトの話題に触れたことがあるでしょう。また、Envoy について読んだことがある人は、サービスメッシュについての記述を目にしたことがあるでしょう。この 2 つの技術はどのように関連しているのでしょうか？また、これらの技術はどのように異なるのでしょうか？共存できるのでしょうか？このブログ記事では、これらの疑問に答えていきます。

サービスメッシュとは？

企業がアプリケーションを再構築し、マイクロサービスベースのアプローチを採用することが多くなるにつれ、トラフィック管理、観測性、セキュリティ、信頼性などの機能に対するソリューションの必要性が高まっています。サービスメッシュは、これらの機能を個々のアプリケーションやサービスではなく、基盤となるプラットフォームに追加するアプローチの 1 つです。

ここでいうトラフィック管理、観測性、セキュリティ、信頼性とはどのようなものでしょうか。いくつかの例を挙げてみましょう。

メッシュ上のサービス間における相互 TLS (mTLS) の実施。これは、低レベルのネットワーク構成でも対応可能な単なる暗号化ではありません。認証 (サービス A を名乗るサービスがサービス A であることを確認) や認可 (サービス A が他のサービスへの接続を許可されることを確認) も必要です。
高度なトラフィックパターンの実現。サービスメッシュでは、より高度なトラフィックのルーティングやステアリングを行うことができます。これにより、カナリアリリースを簡素化したり、上流のエラーを監視して特定のサービスの失敗したインスタンスを迂回して再ルーティングすることができます。
トラフィックのトレースが可能。サービスメッシュの運用方法により (詳細は後述)、メッシュ上のサービス間におけるトラフィックパターンについて、従来よりも高度なメトリクスを公開することができます。これにより、アプリケーションのパフォーマンスに影響を与える問題をより簡単に特定し、場合によっては修正することができます。

サービスメッシュは、基盤となるアプリケーションやサービスに手を加えることなく、これらの機能を実現することができます。これは重要なポイントで、この機能をサービスメッシュに任せることで、企業はアプリケーションにより集中することができます。

サービスメッシュの構成要素とは？

特定の実装の詳細は異なるかもしれませんが、大まかにいうと、すべてのサービスメッシュは 2 つの基本要素で構成されています。

コントロールプレーンは、1 つまたは複数のデータプレーンとの通信チャネルを介したインターフェースです。コントロールプレーンでは、mTLS、トラフィックルーティング、レート制限などのポリシーが定義されます。
データプレーンは、サービスやワークロードの前に置かれ、データプレーンを介して他のサービスやワークロードと通信します。データプレーンは、コントロールプレーンで定義されたポリシーを実行する責任を負っています。

コントロールプレーンとデータプレーンが
一体となってサービスメッシュを構成します。

図 1: 一般的なサービスメッシュアーキテクチャ

コントロールプレーンの詳細

サービスメッシュのコントロールプレーンは、「コマンド＆コントロール」の機能を担います。コントロールプレーンの代表的な機能には次のようなものがあります。

コントロールプレーンは、Kubernetes などの他のシステムと統合し、サービスディスカバリー (メッシュ上のサービスを把握) や設定の詳細を取得します。
メッシュ上のサービス間における、トラフィックの移動方法に関するすべてのポリシーを含むサービスメッシュの構成を管理します。
コントロールプレーンは、ポリシーを実行するためにデータプレーンのプログラムや設定を行います。

ここで重要なのは、コントロールプレーンはアウトオブバンドであり、通信している 2 つのワークロードの間には配置されないということです。これにより、コントロールプレーンがボトルネックにならず、コントロールプレーンが停止してもトラフィックには影響しないようになっています。

サービスメッシュでは、すべてのトラフィックがコントロールプレーンを経由してリダイレクトされるわけではありません。代わりに、データプレーンがメッシュ全体に分散して各ワークロードの近くに配置されます。データプレーンは、特定のワークロードに出入りするトラフィックの管理のみを行い、環境に配置されたワークロードの数に応じて直接拡張することができます。

データプレーンの詳細

コントロールプレーンとは異なり、データプレーンはインバンドであり、実際にワークロードへのトラフィックの出入りを担います。データプレーンは、ワークロード間で実際にパケットをやり取りする部分です。インバンドであるため、軽量 (多くのコンピューティングリソースを消費しないこと) で、パフォーマンスが高いこと (処理するトラフィックに大きな遅延や遅れを生じさせないこと) が求められます。

データプレーンはインバンドであることから、ワークロードのネットワークトラフィックに関するより詳細なメトリクスを公開できます。また、ワークロードに出入りするすべてのトラフィックを監視します。これにより、他の方法では実現が難しいオブザーバビリティ機能が可能となります。

余談ですが、サービスやワークロードの間でトラフィックが行き来するエンティティを指すのに、”data plane” (単数形) という言葉を使う場合があります。ここでは、単一のワークロードに出入りするトラフィックのみを管理する、より小さなエンティティの集合体を指すために “data planes” (複数形) という言葉を使用しています。

Envoy の役割とは？

Envoy は、もともとは Lyft 社で開発されたサービスメッシュアーキテクチャ向けの高性能データプレーンです。Lyft 社はこれをオープンソース化して CNCF (Cloud Native Computing Foundation: Linux Foundation のプロジェクトの 1 つ) に寄贈し、現在では CNCF によるオープンソースプロジェクトの 1 つとなっています。

Envoy がサービスメッシュのユースケースに適している理由は何でしょうか？Envoy は、サービスメッシュのデータプレーンとして非常に有効な機能をいくつか備えています。

Envoy は動的に構成することができます。単に設定ファイルを渡して起動させるだけではありません (それも可能ではありますが)。API を介して設定値を動的に渡すことができます。
Envoy には、複数のロードバランシングアルゴリズムがあります。これにより、さまざまなトラフィックパターンや、より幅広いアプリケーションをサポートできます。
Envoy は、リトライとサーキットブレーカーをサポートしています。Envoy はリクエストを再試行することができ、上流のサービスが十分な数のエラーを返した場合に「回線を切断」できます。そうすることで、分散したマイクロサービスベースのアプリケーションやシステムの残りの部分に影響を与えることなく、連鎖的な障害を防ぐことができます。
Envoy はまた、HTTP/2、HTTP/3、gRPC などを含む最新のプロトコルをサポートしています。

多くの異なるサービスメッシュが Envoy を使用しています。たとえば、Kongのオープンソースプロジェクトである Kuma と、そのエンタープライズ版である Kong Mesh は、データプレーンに Envoy を使用しています。

Kong Enterprise の概要、価格、およびライセンス体系などの詳細は、こちらを参照してください。