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