マルチ環境デプロイ向け Traffic Director

Traffic Director は、ハイブリッド接続を使用して到達できるオンプレミス データセンターや他のパブリック クラウドなど、Google Cloud を越えて広がる環境をサポートします。サービス メッシュが Google Cloud の外部のエンドポイントにトラフィックを送信できるように Traffic Director を構成します。これらのエンドポイントには、オンプレミス ロードバランサ、別のクラウドの仮想マシン上のサーバー アプリケーションなどがあり、ハイブリッド接続を使用して到達可能、かつ IP アドレスとポートで表現されます。各エンドポイントの IP アドレスとポートを、ハイブリッド接続ネットワーク エンドポイント グループ(NEG)に単に追加します。

Traffic Director のオンプレミス サポートとマルチクラウド サービスのサポートにより、次のことが可能です。

  • オンプレミスとマルチクラウド サービスのエンドポイントを含めて、グローバルにトラフィックをルーティングする
  • Traffic Director とサービス メッシュのメリット(サービス ディスカバリや高度なトラフィック管理などの機能を含む)を、Google Cloud の外部にある既存のインフラストラクチャで実行されているサービスで享受する
  • Traffic Director の機能と Cloud Load Balancing を組み合わせることで、Google Cloud ネットワーキング サービスをマルチ環境に持ち込む

ユースケース

Traffic Director は、次のような複数の環境で、VM ベースのサービスとコンテナベースのサービスの間にネットワークを構成できます。

  • Google Cloud
  • オンプレミスのデータセンター
  • その他のパブリック クラウド

オンプレミスの場所、または別のクラウドにメッシュ トラフィックをルーティングする

この機能の最も簡単なユースケースは、トラフィックのルーティングです。アプリケーションでは、Traffic Director クライアント(Envoy プロキシまたはプロキシレス gRPC)が実行されています。Traffic Director は、サービスと各サービスのエンドポイントをそのクライアントに伝えます。

メッシュ トラフィックをオンプレミスの場所または他のクラウドにルーティングする(クリックして拡大)
メッシュ トラフィックをオンプレミスの場所または他のクラウドにルーティングする(クリックして拡大)

上の図では、アプリケーションが on-prem サービスにリクエストを送信すると、Traffic Director クライアントが送信リクエストを調べて宛先を更新します。宛先は、on-prem サービスに関連付けられたエンドポイントに設定されます(この場合は 10.2.0.1)。続いて、Cloud VPN または Cloud Interconnect 経由で、目的の宛先にリクエストが送信されます。

エンドポイントをさらに追加する必要が生じた場合は、Traffic Director を更新してエンドポイントをサービスに追加するだけでよく、アプリケーションのコードに変更を加える必要はありません。

既存のオンプレミス サービスを Google Cloud に移行する

Google Cloud 以外のエンドポイントにトラフィックを送信すると、他の環境にトラフィックを転送できます。この機能と高度なトラフィック管理を組み合わせると、環境間(他のユースケース間)でサービスを移行できます。

オンプレミスの場所から Google Cloud への移行(クリックして拡大)
オンプレミスの場所から Google Cloud への移行(クリックして拡大)

上の図は以前のパターンを拡張したものです。すべてのトラフィックを on-prem サービスに送信するように Traffic Director を構成する代わりに、重み付けベースのトラフィック分割を使用して 2 つのサービス間でトラフィックを分割するように Traffic Director を構成します。

トラフィック分割は、トラフィックの 0% を cloud サービスに送信し、100% を on-prem サービスに送信することから始めることができます。その後、cloud サービス宛てのトラフィックの割合を徐々に増やしていきます。最終的には、トラフィックの 100% が cloud サービスに送信され、on-prem サービスは廃止できます。

オンプレミスとマルチクラウドのデプロイ向け Google Cloud ネットワーク エッジサービス

最後に、この機能を Google Cloud の既存のネットワーキング ソリューションと組み合わせることもできます。Google Cloud は、DDoS 保護に Google Cloud Armor によるグローバル外部負荷分散など、幅広いネットワーク サービスを提供します。これを Traffic Director と組み合わせて使用し、オンプレミスおよびマルチ クラウドサービスに新しい機能を取り込みます。何にもまして、このようなオンプレミス サービスまたはマルチクラウド サービスを公共のインターネットに公開する必要はありません。

複数の環境にまたがるデプロイ(クリックして拡大)
複数の環境にまたがるデプロイ(クリックして拡大)

上の図では、パブリック インターネット上のクライアントからのトラフィックが、Google Cloud のロードバランサ(グローバルな外部 HTTP(S) ロードバランサなど)から Google Cloud のネットワークに入ります。Google Cloud Armor DDoS 保護や Identity-Aware Proxy のユーザー認証などのネットワーク エッジサービスは、トラフィックがロードバランサに到達したときに適用できます。詳細については、マルチ環境デプロイ向けのネットワーク エッジ サービスをご覧ください。

これらのサービスを適用すると、トラフィックは Google Cloud で一時停止され、アプリケーションまたはスタンドアロンのプロキシ(Traffic Director で構成)が、トラフィックを Cloud VPN または Cloud Interconnect を介してオンプレミス サービスに転送します。

アーキテクチャとリソース

このセクションでは、オンプレミス環境とマルチクラウド環境向けに Traffic Director マネージド サービス メッシュを提供するために使用する Google Cloud リソースの背景情報を説明します。

Google Cloud のリソース

次の図は、オンプレミスおよびマルチクラウド サービスで Traffic Director のサポートを可能にする Google Cloud リソースを示しています。なお、主要なリソースは、NEG とそのネットワーク エンドポイントです。他のリソースは、標準の Traffic Director 構成の一部として構成するリソースです。

オンプレミスおよびマルチクラウド サービス用の Compute Engine リソース(クリックして拡大)
オンプレミスおよびマルチクラウド サービス用の Compute Engine リソース(クリックして拡大)

わかりやすくするため、図には、複数のグローバル バックエンド サービスなどのオプションが示されていません。

Traffic Director を構成するには、グローバル バックエンド サービス API リソースを使用してサービスを作成します。サービスは、単に以下を組み合わせる論理構造です。

  1. クライアントがサービスにトラフィックを送信しようとしたときに適用するポリシー
  2. サービス宛てのトラフィックを処理する 1 つ以上のバックエンドまたはエンドポイント

オンプレミスおよびマルチクラウド サービスは、Traffic Director で構成された他のサービスと同じように構成されます。主な違いは、これらのサービスのエンドポイントをハイブリッド接続 NEG を使用して構成することです。これらは、ネットワーク エンドポイント タイプnon-gcp-private-ip-port に設定されている NEG です。ハイブリッド接続 NEG に追加するエンドポイントは、たとえば Cloud VPN や Cloud Interconnect などのハイブリッド接続を介してクライアントから到達可能(有効)な IP:port の組み合わせである必要があります。

NEG にはネットワーク エンドポイント タイプがあり、各 NEG には同じタイプのネットワーク エンドポイントのみを含めることができます。このタイプは、以下を決定します。

  • サービスがトラフィックを送信できる宛先
  • ヘルスチェックの動作

NEG を作成する場合は、オンプレミスまたはマルチクラウドの宛先にトラフィックを送信できるように、次のように構成します。

  • ネットワーク エンドポイント タイプを non-gcp-private-ip-port に設定します。これは到達可能な IP アドレスを表します。この IP アドレスがオンプレミスまたは別のクラウド プロバイダにある場合は、Cloud VPN や Cloud Interconnect が提供する接続などのハイブリッド接続を使用して、Google Cloud から到達可能である必要があります。
  • Google Cloud と、オンプレミス環境やマルチクラウド環境との間の地理的距離が最短になる Google Cloud ゾーンを指定します。たとえば、ドイツのフランクフルトのオンプレミス環境でサービスをホストする場合、NEG を作成する際、europe-west3-a の Google Cloud ゾーンを指定します。

このタイプのネットワーク エンドポイントのヘルスチェック動作は、他の種類のネットワーク エンドポイントのヘルスチェック動作とは異なります。他のネットワーク エンドポイント タイプでは Google Cloud の一元化されたヘルスチェック システムを使用していますが、non-gcp-private-ip-port ネットワーク エンドポイントは Envoy の分散ヘルスチェック メカニズムを使用します。詳細については、制限事項とその他の考慮事項をご覧ください。

接続とネットワーキングに関する考慮事項

  • Traffic Director のクライアント(Envoy プロキシ、プロキシレス gRPC ライブラリなど)は、trafficdirector.googleapis.com:443 で Traffic Director に接続できる必要があります。Traffic Director のコントロール プレーンとの接続が失われると、次のようになります。
    • 既存の Traffic Director のクライアントは、Traffic Director から構成の更新を受信できません。現在の構成に基づいて動作が継続されます。
    • 新しい Traffic Director クライアントは、Traffic Director に接続できません。接続が再度確立されるまで、サービス メッシュは使用できません。
  • Google Cloud と、オンプレミス環境またはマルチクラウド環境との間でトラフィックを送信する場合は、両環境をハイブリッド接続で接続する必要があります。その接続は、Cloud Interconnect や Cloud VPN による高可用接続にすることをおすすめします。
  • オンプレミス、他のクラウド、Google Cloud サブネットの IP アドレスと IP アドレス範囲は、重複しないようにする必要があります。

制限事項とその他の考慮事項

proxyBind を設定する

proxyBind の値は、targetHttpProxy を作成するときにのみ設定できます。既存の targetHttpProxy は、更新できません。

接続と接続の中断

接続要件と制限の詳細については、接続とネットワーキングに関する考慮事項をご覧ください。

混合バックエンド タイプ

バックエンド サービスには、VM または NEG バックエンドを設定できます。バックエンド サービスに NEG バックエンドがある場合は、すべての NEG に同じネットワーク エンドポイント タイプを含める必要があります。それぞれに異なるエンドポイント タイプを持つ複数の NEG があるバックエンド サービスを持つことはできません。

URL マップには、異なるバックエンド サービスを解決するホストルールを設定できます。ハイブリッド接続 NEG のみのバックエンド サービス(オンプレミス エンドポイントを含む)と、スタンドアロン NEG(GKE エンドポイントを含む)を使用するバックエンド サービスがあります。URL マップには、各バックエンド サービス間でトラフィックを分割するルール(重み付けベースのトラフィック分割など)を含めることができます。

Google Cloud バックエンドで non-gcp-private-ip-port 型のエンドポイントの NEG を使用する

バックエンド サービスは、Google Cloud のバックエンドを指すハイブリッド接続 NEG を使用して作成できます。ただし、ハイブリッド接続 NEG では一元化されたヘルスチェックのメリットを得られないため、このパターンはおすすめしません。一元化されたヘルスチェックと分散されたヘルスチェックの説明については、ヘルスチェックをご覧ください。

エンドポイントの登録

NEG にエンドポイントを追加する場合は、NEG を更新する必要があります。これは、手動で行うか、Google Cloud ネットワーク エンドポイント グループの REST API や gcloud コマンドライン ツールを使用して自動化できます。サービスの新しいインスタンスが開始されると、Google Cloud APIs を使用して、構成済みの NEG にインスタンスを登録できます。Compute Engine MIG または GKE(Google Cloud を使用)を使用する場合、エンドポイント登録は MIG または NEG コントローラによって自動的に処理されます。

ヘルスチェック

ハイブリッド接続 NEG を使用する場合のヘルスチェックの動作は、標準の集中型ヘルスチェックの動作とは異なります。

  • gce-vm-ip-port タイプのネットワーク エンドポイントの場合、Traffic Director は Google Cloud の一元化されたヘルスチェック システムからエンドポイントのヘルス情報を受け取ります。この情報を Traffic Director が Traffic Director クライアントに提供することで、高額になる可能性があるデータプレーン ベースのヘルスチェックは不要になります。
  • non-gcp-private-ip-port タイプのネットワーク エンドポイントの場合、Traffic Director はデータプレーンを使用してヘルスチェックを処理するようにクライアントを構成します。Envoy インスタンスは、独自のヘルスチェックを実行し、独自の仕組みを使用して、異常なバックエンドにリクエストを送信しないようにします。
  • データプレーンがヘルスチェックを処理するため、Google Cloud Console、API、gcloud を使用してヘルスチェックのステータスを取得することはできません。

実際には、non-gcp-private-ip-port を使用することは、次を意味します。

  • HTTP ヘルスチェックと TCP ヘルスチェックのみがサポートされます。
  • Traffic Director のクライアントは、それぞれ分散された方法でヘルスチェックを処理するため、ヘルスチェックが原因でネットワーク トラフィックが増加することがあります。その増加量は、Traffic Director クライアントの数と、各クライアントがヘルスチェックに必要とするエンドポイントの数によって異なります。例:
    • ハイブリッド接続 NEG に別のエンドポイントを追加すると、既存の Traffic Director クライアントは、ハイブリッド接続 NEG 内のエンドポイントのヘルスチェックを開始する可能性があります。
    • サービス メッシュに別のインスタンスを追加すると(たとえば、アプリケーション コードを実行する仮想マシン インスタンスと Traffic Director クライアントなど)、新しいインスタンスが、ハイブリッド接続 NEG でエンドポイントのヘルスチェックを開始することがあります。
    • ヘルスチェックによるネットワーク トラフィックは、二次関数(O(n^2))の割合で増加します。

Virtual Private Cloud ネットワーク

サービス メッシュは、その VPC ネットワーク名で一意に識別されます。Traffic Director クライアントは、ブートストラップ構成で指定された VPC ネットワークに基づいて Traffic Director から構成を受け取ります。したがって、メッシュ全体が Google Cloud データセンターの外にある場合でも、ブートストラップ構成には有効な VPC ネットワーク名を指定する必要があります。

サービス アカウント

Google Cloud 内では、デフォルトの Envoy ブートストラップは、Compute Engine と GKE の一方または両方のデプロイ サービスからサービス アカウント情報を読み取るように構成されます。Google Cloud の外部で実行する場合は、Envoy ブートストラップにサービス アカウント、ネットワーク名、プロジェクト番号を明示的に指定する必要があります。このサービス アカウントには、Traffic Director API に接続するための十分な権限が必要です。

次のステップ

オンプレミス デプロイとマルチクラウド デプロイ用に Traffic Director を構成する手順については、マルチ環境(オンプレミス、マルチクラウド)のデプロイ向けネットワーク エッジサービスをご覧ください。