Cloud Service Mesh との Service Directory のインテグレーション
このドキュメントでは、Cloud Service Mesh で Service Directory のサービス レジストリを使用する方法の概要を説明します。これにより、Cloud Service Mesh で Service Directory に登録されたサービスにトラフィックを転送して、トラフィック ポリシーを適用できるようになります。このドキュメントは、アプリケーションを Google Cloud の他のサービスと統合する Cloud Service Mesh のデベロッパーを対象としています。
Service Directory は、登録されているネットワーク サービスに関する情報（名前、ロケーション、属性など）を保存するサービス レジストリです。サービスを自動的に登録して、すべての詳細情報を取得できます。インフラストラクチャに関係なく、すべてのサービスを登録できます。
レジストリには、Google Cloud サービスだけでなく、オンプレミスまたは他のパブリック クラウドで実行されているハイブリッド サービスも保存されます。このドキュメントの内容をよく理解するため、Service Directory のオペレーションの基本を理解しておくことをおすすめします。
Cloud Service Mesh で Service Directory のサービス レジストリを使用すると、メッシュ内のアプリケーションと Cloud Service Mesh によって構成されたゲートウェイで、サービス レジストリのサービスが使用できるようになります。Service Directory と内部パススルー ネットワーク ロードバランサ、内部アプリケーション ロードバランサ、および L4 Private Service Connect とのインテグレーションの場合、Cloud Service Mesh と Service Directory のインテグレーションは、Envoy とプロキシレス gRPC でサポートされています。
サービスを統合するには、サービスを Service Directory に登録して、Cloud Service Mesh のバックエンド サービスにバインドします。バインディングが確立されると、Cloud Service Mesh は Service Directory にクエリを送信し、登録済みサービスとそのサービスへの到達方法に関する情報を取得します。Cloud Service Mesh はサービスに対する変更も追跡します。統合を使用すると、サービス メッシュとセルフマネージド ゲートウェイからこれらのサービスにトラフィックを送信できます。また、Cloud Service Mesh で構成するポリシー（高度なトラフィック管理ポリシーなど）も適用できます。
この統合を使用すると、サービス自体で使用されるバックエンドの種類に関係なく、サービス バインディングがバックエンドとして機能します。Cloud Service Mesh は、バックエンドの種類に関係なく、トラフィックをサービスに送信できるため、このインテグレーションにより Cloud Service Mesh のデプロイが簡単になります。
サービスが Service Directory に登録されていれば、必要なサービスにアクセスするためにインスタンス グループやさまざまな種類のネットワーク エンドポイント グループ（NEG）を構成する必要はありません。Google Kubernetes Engine、内部ロードバランサ、Private Service Connect を Service Directory に自動的に登録することで、Cloud Service Mesh からサービスへのアクセスをさらに簡素化できます。
統合で使用するリソース
Cloud Service Mesh と Service Directory のインテグレーションでは、次のリソースが使用されます。
Service Directory サービス
Service Directory はサービス レジストリです。Service Directory には、Google Cloud やその他の環境（オンプレミス データセンターなど）を基盤とするサービスなど、さまざまなサービスを登録できます。各サービスは、一意の名前と 0 個以上のサービス エンドポイントで構成されます。サービス エンドポイントは、アドレス、ポート、プロパティ、メタデータで構成されます。エンドポイントが 1 つもない場合、トラフィックをサービスに転送することはできません。
サービス バインディング
サービス バインディングは、Service Directory サービスの完全修飾ドメイン名（FQDN）を含むリソースです。たとえば、projects/test-proj/locations/us-east1/namespaces/test-namespace/services/test-service は Service Directory サービスの FQDN です。
バックエンド サービス
バックエンド サービスは Cloud Service Mesh に情報を提供する構成リソースです。これには、バックエンド サービスによるトラフィックの転送先となるバックエンド（マネージド インスタンス グループなど）を含まれます。サービス バインディングを参照するバックエンド サービスにバックエンドを含めることはできません。Cloud Service Mesh と Service Directory のインテグレーションを使用するには、サービス バインディングを参照する新しいバックエンド サービスを作成します。
バックエンド サービスには、複数のサービス バインディングを設定できます。この構成は、同じアプリケーションに複数のリージョン デプロイメントがある場合に役立ちます。各リージョン デプロイを、リージョン サービス 1 とリージョン サービス 2 として Service Directory のリージョン インスタンスに登録できます。これらのリージョン Service Directory サービスは、2 つのサービス バインディングを使用して同じバックエンド サービスに関連付けることができます。グローバル サービス バインディング 1 はリージョン A のリージョン サービス 1 に関連付けられ、グローバル サービス バインディング 2 はリージョン B のリージョン サービス 2 に関連付けられます。
ユースケース
Cloud Service Mesh のデプロイを Service Directory と統合することは、他のチームや組織が所有または公開しているサービスに依存する場合に便利です。
Cloud Service Mesh で既存のサービスを使用できるようにする
Service Directory は、GKE、内部パススルー ネットワーク ロードバランサ、内部アプリケーション ロードバランサなどの Google Cloud プロダクトと統合されます。サービス プロデューサーは、GKE サービスまたはロードバランサを作成する際に、Service Directory にサービスを登録できます。
サービスを Service Directory に登録したら、そのサービスと通信するように Cloud Service Mesh を構成できます。これにより、Cloud Service Mesh クライアントは、内部パススルー ネットワーク ロードバランサと内部アプリケーション ロードバランサの背後で実行されているサービスと通信できます。
サービス プロデューサーとコンシューマ間の連携を改善する
大規模な組織の場合、複数のデベロッパー チームが存在することが少なくありません。自分のサービスを他のチームが利用できるようにすることで、共有サービスが提供する機能をより多くのチームで使用できるようになります。これにより、チーム間に依存関係が作成されます。この依存関係により、チームで作業を共有できるようになりますが、依存関係によって調整のオーバーヘッドも発生します。
Service Directory を使用する場合、1 つのチーム（プロデューサー）がサービスを登録し、他のチームや組織（コンシューマー）で利用できるようにします。プロデューサーは、このサービスへの参照をコンシューマと共有します。コンシューマは、この参照を使用して Service Directory でプロデューサーのサービスを検索し、サービスのエンドポイントを検出できます。たとえば、エンドポイントは、プロデューサーのサービスがトラフィックの受信を想定している仮想 IP アドレス（VIP）になります。
Cloud Service Mesh と Service Directory のインテグレーションにより、Service Directory サービスを Cloud Service Mesh バックエンド サービスにバインドして、このプロセスを自動化できます。これには、次の利点があります。
- Cloud Service Mesh は、サービスのエンドポイントを Service Directory から同期して自動的に解決します。Service Directory サービスのエンドポイントが更新されると、Cloud Service Mesh が自動的にこれらの変更を同期します。
- Cloud Service Mesh で、タイムアウトなどのさまざまなルーティング ポリシーとトラフィック管理ポリシーを設定できます。これらのポリシーを使用すると、アプリケーションが Service Directory サービスにリクエストを発行する方法を微調整できます。Cloud Service Mesh でのルーティングとトラフィック管理については、高度なトラフィック管理をご覧ください。
- Cloud Service Mesh は、近接性ベースのロード バランシングなどのトラフィック管理機能を使用して、アプリケーションからエンドポイントにトラフィックを最適に転送します（ラウンドトリップ時間を最小限に抑えるなど）。
コンシューマが Cloud Service Mesh を使用してバックエンド サービスを Service Directory サービスに接続することで、チーム間の調整オーバーヘッドを削減できます。
- サービス
Paymentsを名前で接続します。 Cloud Service Mesh は、
Paymentsサービスに関する情報をクライアントと共有します。- たとえば、サービス メッシュで実行されているサイドカー プロキシは、サービスに到達できるエンドポイント（
10.0.0.1:80など）を認識します。
- たとえば、サービス メッシュで実行されているサイドカー プロキシは、サービスに到達できるエンドポイント（
アプリケーションは、ユーザーまたはアプリケーションで外部サービスのエンドポイントについて何も認識する必要がなく、名前でこのサービスを呼び出すことができます。この図では、サービスは
Paymentsサービスです。サービス プロデューサーが外部サービスを更新すると（エンドポイントの変更など）、Cloud Service Mesh が更新を取得し、クライアントとシームレスに共有します。
Ingress ポイントを使用して境界内のサービスにアクセスする
VPC Service Controls の境界内のサービスのコレクションをグループ化し、これらのサービスを 1 つの上り（内向き）ポイントで公開できます。この上り（内向き）ポイントを Service Directory に登録すると、ユーザーが境界内のサービスにアクセスできるようになります。VPC Service Controls の境界の詳細については、サービス境界の詳細と構成をご覧ください。
たとえば、あるチームがクラスタ内の Kubernetes Service のコレクションにリクエストを分散する内部アプリケーション ロードバランサを使用して、Ingress ゲートウェイを作成するとします。この Ingress ゲートウェイは、サービスとして Service Directory に自動的に登録されます。Kubernetes Service にアクセスするコンシューマは、この Ingress ゲートウェイを Service Directory で検索できます。コンシューマは、ゲートウェイ経由で境界内のサービスにアクセスするように Cloud Service Mesh メッシュを構成できます。
ドメイン間でサービスを接続する
接続する必要があるサービスが異なるドメインにある場合があります。
組織間でサービスを接続する
Google API（Cloud SQL など）やサードパーティのマネージド サービスなど、別の組織が所有するサービスへのアクセスが必要になる場合があります。
Service Directory は Private Service Connect をサポートしています。ネットワークで Private Service Connect エンドポイントを作成すると、そのエンドポイントを Service Directory にサービスとして登録できます。このサービスを Cloud Service Mesh に接続して、Envoy や gRPC クライアントなどのメッシュ クライアントと、Apigee などのセルフマネージド ゲートウェイがこれらのサービスを呼び出せるようにします。
前述の Cloud Storage を使用した例は、Private Service Connect を使用し、Virtual Private Cloud ネットワークのエンドポイントを使用して Google API を呼び出す方法を示しています。
VPC ネットワーク間でサービスを接続する
Google Cloud のデプロイの一環として複数の VPC ネットワークを使用している企業もあります。その場合、VPC ネットワークのサービスから別の VPC ネットワーク内のサービスへのアクセスが必要になることがあります。別の VPC ネットワーク内のサービスにアクセスするように VPC ピアリングを構成できますが、ピアリングされるネットワーク間で重複する IP アドレス範囲があると、構成が複雑になります。
Private Service Connect により、1 つの IP:port エンドポイントを使用して、ある VPC ネットワーク内のサービスが、別の VPC ネットワーク内のサービスに安全かつ限定的にアクセスできます。
ドメイン全体にわたるその他の例
前の 2 つの例は、ドメインを越える必要がある場合を示していますが、このほかにも多くの例があります。たとえば、2 つの Google Cloud リージョンの交差部分に存在するゲートウェイを作成します。あるリージョンのサービスは、このゲートウェイ経由で別のリージョンのサービスにアクセスできます。ゲートウェイを Service Directory にサービスとして登録し、このドキュメントの説明に沿って Cloud Service Mesh でゲートウェイを使用します。
サービスへのアクセス時にポリシーを適用する
Cloud Service Mesh は、ポリシーで構成可能な高度なトラフィック管理などの機能をサポートしています。たとえば、クライアントがリクエストを特定のバックエンド サービスに送信するたびに、そのトラフィックが 2 番目のバックエンド サービスに送信されるように、トラフィックのミラーリング ポリシーを設定できます。
Service Directory サービスを Cloud Service Mesh のバックエンド サービスにバインドすると、Cloud Service Mesh でこれらのタイプのポリシーを構成できます。サイドカー プロキシ、ミドルまたはエッジプロキシ、プロキシレス クライアントがこれらのポリシーを学習して適用します。
例:
- 重み付けに基づくトラフィック分割（2 つの Service Directory サービス間の分割など）
- トラフィックのミラーリング（監査サービスへのミラーリングなど）
users サービスのリクエストが audit サービスにミラーリングされる（クリックして拡大）Cloud Service Mesh と既存のクライアントのサポート
Cloud Service Mesh が組織にデプロイされている場合でも、Cloud Service Mesh を使用しないクライアントが存在する可能性があります。たとえば、サービス メッシュの一部ではない仮想マシンがサービスにアクセスする場合があります。
Service Directory サービスを Cloud Service Mesh のバックエンド サービスにバインドすると、Cloud Service Mesh のクライアントは、そのサービスに関する最新情報を自動的に取得します。Cloud Service Mesh を使用しないクライアントは、Service Directory でサービス情報を検索して使用できます。
制限事項
Cloud Service Mesh は、Service Directory のインテグレーションで FQDN NEG（INTERNET_FQDN_PORT NEG）をサポートしていません。
次のステップ
- 統合の設定について確認します。
- この統合によるオブザーバビリティの詳細については、Service Directory によるオブザーバビリティとデバッグをご覧ください。