ハイブリッド接続ネットワーク エンドポイント グループを使用した Cloud Service Mesh

Cloud Service Mesh では、オンプレミス データセンターや、ハイブリッド接続を使用して到達可能な他のパブリック クラウドなど、Google Cloud の枠を越えた環境をサポートします。

サービス メッシュが Google Cloud の外部にあるエンドポイントにトラフィックを送信できるように、Cloud Service Mesh を構成します。このエンドポイントには、次に挙げるものが含まれます。

  • オンプレミスのロードバランサ。
  • 別のクラウドの仮想マシン（VM）インスタンス上のサーバー アプリケーション。
  • ハイブリッド接続を使用して、IP アドレスとポートで到達可能な他の宛先。

各エンドポイントの IP アドレスとポートをハイブリッド接続のネットワーク エンドポイント グループ（NEG）に追加します。ハイブリッド接続 NEG のタイプは NON_GCP_PRIVATE_IP_PORT です。

オンプレミス サービスとマルチクラウド サービスに対する Cloud Service Mesh のサポートにより、次のことが可能になります。

  • オンプレミス サービスとマルチクラウド サービスのエンドポイントを含めて、グローバルにトラフィックをルーティングする。
  • Cloud Service Mesh とサービス メッシュのメリット（サービス ディスカバリや高度なトラフィック管理などの機能を含む）が、Google Cloud の外部にある既存のインフラストラクチャで実行されているサービスでも得られるようにする。
  • Cloud Service Mesh の機能と Cloud Load Balancing を組み合わせて、Google Cloud ネットワーキング サービスをマルチ環境まで拡げる。

ハイブリッド接続 NEG（NON_GCP_PRIVATE_IP_PORT NEG）は、プロキシレス gRPC クライアントではサポートされていません。

ユースケース

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

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

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

この機能の最も簡単なユースケースは、トラフィックのルーティングです。アプリケーションが Cloud Service Mesh Envoy プロキシを実行しているとします。Cloud Service Mesh は、サービスと各サービスのエンドポイントについてクライアントに伝えます。

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

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

エンドポイントをさらに追加する必要がある場合は、Cloud Service Mesh を更新してサービスに追加します。アプリケーション コードを変更する必要はありません。

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

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

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

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

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

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

最後に、この機能を Google Cloud の既存のネットワーキング ソリューションと組み合わせることもできます。Google Cloud では、分散型サービス拒否攻撃（DDoS）対策のために Google Cloud Armor を使用したグローバルな外部ロード バランシングなど、幅広いネットワーク サービスを提供します。これを Cloud Service Mesh とともに使用することで、新しい機能がオンプレミスやマルチクラウド サービスにもたらされます。また、このようなオンプレミス サービスやマルチクラウド サービスを公共のインターネットに公開する必要のないことが、最大のメリットです。

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

上の図では、公共のインターネット上のクライアントからのトラフィックが、Google Cloud のロードバランサ（グローバルな外部アプリケーション ロードバランサなど）から Google Cloud のネットワークに入っています。トラフィックがロードバランサに到達すると、Google Cloud Armor DDoS 対策や Identity-Aware Proxy（IAP）のユーザー認証などのネットワーク エッジサービスを適用できます。詳細については、マルチ環境デプロイ向けのネットワーク エッジ サービスをご覧ください。

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

Google Cloud のリソースとアーキテクチャ

このセクションでは、オンプレミス環境とマルチクラウド環境で Cloud Service Mesh によるマネージド サービス メッシュを提供する際に使用できる Google Cloud リソースの背景情報について説明します。

次の図は、Cloud Service Mesh のオンプレミス サービスとマルチクラウド サービスのサポート可能にする Google Cloud リソースを示しています。主要なリソースは、NEG とそのネットワーク エンドポイントです。他のリソースは、標準の Cloud Service Mesh 設定の一環として構成するリソースです。わかりやすくするため、この図では複数のグローバル バックエンド サービスなどのオプションは表示されていません。

オンプレミスとマルチクラウド サービス用の Compute Engine リソース。
オンプレミス サービスとマルチクラウド サービス用の Compute Engine リソース（クリックして拡大）

Cloud Service Mesh を構成するときに、グローバル バックエンド サービス API リソースを使用してサービスを作成します。サービスは、次のものを組み合わせた論理的な構成です。

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

オンプレミス サービスとマルチクラウド サービスは、Cloud Service Mesh が構成する他のサービスと同じように機能します。主な違いは、ハイブリッド接続 NEG を使用してこれらのサービスのエンドポイントを構成することです。これらの NEG のネットワーク エンドポイント タイプは NON_GCP_PRIVATE_IP_PORT に設定されています。ハイブリッド接続 NEG に追加するエンドポイントは、クライアントがアクセスできる有効な IP:port の組み合わせ（Cloud VPN や Cloud Interconnect などのハイブリッド接続など）にする必要があります。

各 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 の分散ヘルスチェック メカニズムを使用します。詳細については、制限事項とその他の考慮事項をご覧ください。

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

Envoy プロキシなどの Cloud Service Mesh クライアントは、trafficdirector.googleapis.com:443 で Cloud Service Mesh に接続できる必要があります。Cloud Service Mesh コントロール プレーンとの接続が失われると、次のようになります。

  • 既存の Cloud Service Mesh クライアントは、Cloud Service Mesh から構成の更新を受信できなくなります。現在の構成に基づいて動作が継続されます。
  • 新しい Cloud Service Mesh クライアントは Cloud Service Mesh に接続できません。接続が再度確立されるまで、サービス メッシュを使用できません。

Google Cloud と、オンプレミス環境またはマルチクラウド環境との間でトラフィックを送信する場合は、両環境をハイブリッド接続で接続する必要があります。Cloud VPN または Cloud Interconnect による高可用接続をおすすめします。

オンプレミス、他のクラウド、Google Cloud サブネットの IP アドレスと IP アドレス範囲は、重複しないようにする必要があります。

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

ハイブリッド接続 NEG を使用する場合は、以下の制限事項があります。

proxyBind の設定

targetHttpProxy を作成するときは、proxyBind の値のみ設定できます。既存の 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 NEG REST API または Google Cloud CLI を使用して自動化することもできます。

サービスの新しいインスタンスが開始されると、Google Cloud APIs を使用して、構成した NEG にインスタンスを登録できます。Compute Engine マネージド インスタンス グループ（MIG）または GKE（Google Cloud）を使用する場合、MIG コントローラまたは NEG コントローラがエンドポイントの登録をそれぞれ自動的に処理します。

ヘルスチェック

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

  • NON_GCP_PRIVATE_IP_PORT タイプのネットワーク エンドポイントの場合、Cloud Service Mesh は、データプレーンを使用してヘルスチェックを処理するようにクライアントを構成します。正常でないバックエンドにリクエストが送信されないようにするため、Envoy インスタンスは、独自のヘルスチェックを実行し、独自の仕組みを使用します。
  • データプレーンがヘルスチェックを処理するため、Google Cloud Console、API、Google Cloud CLI を使用してヘルスチェックのステータスを取得することはできません。

実際には、NON_GCP_PRIVATE_IP_PORT を使用すると次のようになります。

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

VPC ネットワーク

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

サービス アカウント

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

次のステップ