サービス メッシュ 101: Envoy の役割

サービス メッシュに関する記事を読んだことがある人なら、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 の概要、価格、およびライセンス体系などの詳細は、こちらを参照してください。


記事参照: 2021 年 8 月 26 日
Scott Lowe 
© Kong Inc. 2021
Service Mesh 101: The Role of Envoy

シェアする

  • このエントリーをはてなブックマークに追加

フォローする