サービス ディスカバリ

Cloud Service Mesh は、サービスとエンドポイントのディスカバリを行います。これらの機能を使用すると、コードをサービスのエンドポイントとして実行する仮想マシン(VM)インスタンスとコンテナ インスタンスをグループ化できます。

Cloud Service Mesh はこれらのサービスを監視し、最新のヘルスチェック情報をクライアントと共有できるようにします。そのため、いずれかのアプリケーションが Cloud Service Mesh クライアント(Envoy サイドカー プロキシやプロキシレス gRPC アプリケーションなど)を使用してリクエストを送信することで、サービスの最新情報を利用できます。

Cloud Service Mesh のコンテキストでは、クライアントは VM またはコンテナ上で動作するアプリケーション コードで、サーバーへ送信するリクエストを作成します。 サーバーは、このようなリクエストを受信するアプリケーション コードです。Cloud Service Mesh クライアントとは、Cloud Service Mesh に接続される Envoy や gRPC などの xDS クライアントで、データプレーンの一部になります。

データプレーンでは、Envoy や gRPC は次の処理を行います。

  1. リクエストを調べ、そのリクエストをバックエンド サービス(デプロイ時に構成したリソース)に一致させます。
  2. リクエストが一致すると、Envoy または gRPC は、以前に構成したトラフィックまたはセキュリティ ポリシーを適用し、バックエンドまたはエンドポイントを選択して、そのバックエンドまたはエンドポイントにリクエストを転送します。

サービス ディスカバリ

Cloud Service Mesh は、サービス ディスカバリを提供します。Cloud Service Mesh を構成するときに、バックエンド サービスを作成します。また、送信リクエスト(アプリケーション コードから送信され Cloud Service Mesh クライアントで処理されるリクエスト)を特定のサービスと照合する方法を指定するルーティング ルールも定義します。Cloud Service Mesh クライアントは、ルールと一致するリクエストを処理するときに、リクエストを受信するサービスを選択できます。

次に例を示します。

  • アプリケーションが動いている VM があるとします。この VM には Envoy サイドカー プロキシがあり、Cloud Service Mesh に接続されており、アプリケーションに代わって送信リクエストを処理しています。
  • バックエンド サービスは、payments という名前で構成しました。このバックエンド サービスには 2 つのネットワーク エンドポイント グループ(NEG)バックエンドがあり、payments サービスのコードを実行するさまざまなコンテナ インスタンスを指しています。
  • sidecar-mesh というメッシュを定義する Mesh リソースを構成しました。
  • バックエンド サービス payments とホスト名 helloworld-gce のトラフィックの宛先を定義する Route リソースを構成しました。

この構成を使用して、(VM 上の)アプリケーションが HTTP リクエストを payments.example.com に送信すると、Cloud Service Mesh クライアントは、このリクエストは payments サービスに向けられたものだということを認識します。

プロキシレス gRPC サービスで Cloud Service Mesh を使用する場合、サービス ディスカバリは同じように機能します。ただし、Cloud Service Mesh クライアントとして機能する gRPC ライブラリは、xDS リゾルバを指定するサービスに関する情報のみを取得します。デフォルトでは、Envoy は、Envoy ブートストラップ ファイルに指定された Virtual Private Cloud(VPC)ネットワークで構成されているすべてのサービスに関する情報を取得します。

エンドポイント ディスカバリ

サービス ディスカバリを使用すると、クライアントがサービスを認識できます。エンドポイント ディスカバリを使用すると、クライアントはコードを実行しているインスタンスを認識できます。

サービスを作成する際には、そのサービスのバックエンドも指定します。これらのバックエンドは、マネージド インスタンス グループ(MIG)の VM または NEG のコンテナです。Cloud Service Mesh では、こうした MIG と NEG をモニタリングして、インスタンスとエンドポイントが作成および削除されるタイミングを認識します。

Cloud Service Mesh は、これらのサービスに関する最新情報を継続的にクライアントと共有します。クライアントは、すでに存在しないエンドポイントに対するトラフィックの送信を避けることができます。また、新しいエンドポイントを認識し、そのエンドポイントが提供する追加の容量を利用できます。

MIG または NEG にエンドポイントを追加し、Cloud Service Mesh を設定する以外に、Cloud Service Mesh でサービス ディスカバリを有効にするための追加構成は必要ありません。

Cloud Service Mesh でのサイドカー プロキシによるトラフィック インターセプト

Cloud Service Mesh では、サイドカー プロキシ モデルをサポートしています。このモデルでは、アプリケーションがトラフィックを宛先に送信すると、トラフィックはインターセプトされ、アプリケーションが実行されているホスト上のサイドカー プロキシのポートにリダイレクトされます。サイドカー プロキシでは、トラフィックの負荷分散方法が決定され、トラフィックは宛先に送信されます。

Cloud Service Mesh とサービス ルーティング API を使用すると、トラフィック インターセプトが自動的に管理されます。

次のステップ

  • Cloud Service Mesh がサイドカー プロキシを使用して内部マイクロサービスのグローバルな負荷分散を行う方法については、Cloud Service Mesh の負荷分散をご覧ください。
  • Cloud Service Mesh の詳細については、Cloud Service Mesh の概要をご覧ください。