インターネット ネットワーク エンドポイント グループを使用して外部バックエンドを設定する

このドキュメントでは、完全修飾ドメイン名が必要なインターネット ネットワーク エンドポイント グループ（NEG）を使用して、Cloud Service Mesh の外部バックエンドを構成する手順について説明します。このドキュメントは、以下に関する中級から上級レベルの知識があるユーザーを対象としています。

この設定ガイドでは、次の基本的な手順について説明します。

  • アウトバウンド トラフィックに対してインターネット NEG と認証なしの TLS を使用するように Cloud Service Mesh を構成する
  • サービス メッシュから Cloud Run サービスにトラフィックをルーティングする

始める前に

インターネット ネットワーク エンドポイント グループを使用した Cloud Service Mesh の概要をお読みください。

このガイドで使用するサンプル構成では、以下のことを前提としています。

  • 中間プロキシ、Cloud Service Mesh リソース、Cloud DNS ゾーン、ハイブリッド接続などの関連するすべての Compute Engine リソースが、デフォルトの Virtual Private Cloud（VPC）ネットワークに接続している。
  • オンプレミス インフラストラクチャで example.com:443 サービスが実行されている。ドメイン example.com は、3 つのエンドポイント 10.0.0.100、10.0.0.101、10.0.0.102 によって提供されています。Envoy プロキシからこれらのリモート エンドポイントへの接続を保証するルートが存在します。

デプロイメントは次のようになります。

インターネット NEG を使用した設定例。
インターネット NEG を使用した設定例（クリックして拡大）

インターネット NEG と TLS SNI を使用したトラフィック ルーティング

インターネット NEG を使用し、アウトバウンド トラフィックに対して FQDN と TLS を使用するように Cloud Service Mesh を構成した場合、サンプルのデプロイメントは、次の図とトラフィックの説明に示すように動作します。

この例でのトラフィックのルーティング方法。
この例でのトラフィックのルーティング方法（クリックして拡大）

以下の表のステップは、前の図の番号に対応しています。

ステップ 説明
0 Envoy が xDS を通じて Cloud Service Mesh から FQDN バックエンド構成を受け取ります。
0 VM 内で実行されている Envoy が DNS に連続的にクエリを実行し、構成されている FQDN を取得します。
1 ユーザー アプリケーションがリクエストを開始します。
2 リクエストのパラメータ。
3 Envoy プロキシがリクエストを傍受します。この例では、転送ルールの仮想 IP アドレス（VIP）として 0.0.0.0 を使用していることを前提としています。0.0.0.0 が VIP の場合、Envoy がすべてのリクエストを傍受します。リクエストのルーティングは、アプリケーションによって生成された元のリクエストの宛先 IP アドレスに関係なく、レイヤ 7 パラメータのみに基づきます。
4 Envoy は、正常なリモート エンドポイントを選択し、クライアント TLS ポリシーから取得した SNI を使用して TLS handshake を実行します。
5 Envoy がリクエストをリモート エンドポイントにプロキシします。

この図にはありませんが、ヘルスチェックが構成されている場合、Envoy はリモート エンドポイントのヘルスチェックを継続的に行い、正常なエンドポイントにのみリクエストをルーティングします。

ハイブリッド接続を設定する

このドキュメントでは、ハイブリッド接続がすでに確立されていることを前提としています。

  • オンプレミス サービスまたはサードパーティのパブリック クラウドと VPC ネットワーク間のハイブリッド接続は、Cloud VPN または Cloud Interconnect で確立されています。
  • Envoy からプライベート サービス エンドポイント（および必要に応じてオンプレミス DNS サーバー）への双方向のネットワーク到達性を確立するために、VPC ファイアウォール ルールとルートが正しく構成されています。
  • リージョン HA フェイルオーバー シナリオが正常に機能するように、グローバル動的ルーティングが有効になっています。詳細については、動的ルーティング モードをご覧ください。

Cloud DNS 構成を設定する

ドメイン（FQDN）example.com の Cloud DNS 限定公開ゾーンを設定するには、次のコマンドを使用します。A レコードは、エンドポイント 10.0.0.100、10.0.0.101、10.0.0.102、10.0.0.103 を参照しています。

gcloud

  1. DNS マネージド限定公開ゾーンを作成して、デフォルト ネットワークに接続します。
    gcloud dns managed-zones create example-zone \
        --description=test \
        --dns-name=example.com \
        --networks=default \
        --visibility=private
  1. DNS レコードを限定公開ゾーンに追加します。
    gcloud dns record-sets transaction start \
        --zone=example-zone

    gcloud dns record-sets transaction add 10.0.0.100 10.0.0.101 10.0.0.102 10.0.0.103 \
        --name=example.com \
        --ttl=300 \
        --type=A \
        --zone=example-zone

    gcloud dns record-sets transaction execute \
        --zone=example-zone

インターネット FQDN NEG を使用して Cloud Service Mesh を構成する

このセクションでは、インターネット FQDN NEG を使用して Cloud Service Mesh を構成します。

NEG、ヘルスチェック、バックエンド サービスを作成する

gcloud

  1. インターネット NEG を作成します。
    gcloud compute network-endpoint-groups create on-prem-service-a-neg \
        --global \
        --network-endpoint-type INTERNET_FQDN_PORT
  1. FQDN:Port エンドポイントをインターネット NEG に追加します。
    gcloud compute network-endpoint-groups update on-prem-service-a-neg \
        --global \
        --add-endpoint=fqdn=example.com,port=443
  1. グローバル ヘルスチェックを作成します。
    gcloud compute health-checks create http service-a-http-health-check \
        --global
  1. on-prem-service-a というグローバル バックエンド サービスを作成し、ヘルスチェックに関連付けます。
    gcloud compute backend-services create on-prem-service-a \
        --global \
        --load-balancing-scheme=INTERNAL_SELF_MANAGED \
        --health-checks service-a-http-health-check
  1. on-prem-service-a-neg という名前の NEG をバックエンド サービスのバックエンドとして追加します。
    gcloud compute backend-services add-backend on-prem-service-a \
        --global \
        --global-network-endpoint-group \
        --network-endpoint-group on-prem-service-a-neg

ルーティング ルール マップの作成

ルーティング ルール マップは、URL マップ、ターゲット HTTP プロキシ、転送ルールで構成されています。これにより、メッシュ内のトラフィックのルーティング情報が提供されます。

この URL マップには、すべての HTTP トラフィックを on-prem-service-a にルーティングするルールが含まれています。

gcloud

  1. URL マップを作成します。
    gcloud compute url-maps create td-url-map \
        --default-service on-prem-service-a
  1. ターゲット HTTP プロキシを作成し、URL マップをターゲット プロキシに関連付けます。
    gcloud compute target-http-proxies create td-proxy \
        --url-map td-url-map
  1. IP アドレス 0.0.0.0 を使用してグローバル転送ルールを作成します。この特別な IP アドレスを指定すると、データプレーンは宛先 IP アドレスを無視し、リクエストの HTTP パラメータのみに基づいてリクエストをルーティングします。
    gcloud compute forwarding-rules create td-forwarding-rule \
        --global \
        --load-balancing-scheme=INTERNAL_SELF_MANAGED \
        --address=0.0.0.0 \
        --target-http-proxy=td-proxy \
        --ports=443 \
        --network=default

認証なしの TLS と HTTPS を構成する

Envoy プロキシとオンプレミス サービスの間で認証なしの HTTPS を構成する場合は、次の手順を行います。ここでは、TLS handshake で SNI を構成する方法についても説明します。

クライアント TLS ポリシーでは、クライアントが特定のサービスにアウトバウンド リクエストを送信するときのクライアント ID と認証メカニズムを指定します。クライアント TLS ポリシーは、securitySettings フィールドを使用してバックエンド サービス リソースに接続されます。

gcloud

  1. クライアント TLS ポリシーを作成してインポートします。SNI を NEG で構成した FQDN に設定します。
    cat << EOF > client_unauthenticated_tls_policy.yaml
    name: "client_unauthenticated_tls_policy"
    sni: "example.com"
    EOF

    gcloud beta network-security client-tls-policies import client_unauthenticated_tls_policy \
        --source=client_unauthenticated_tls_policy.yaml \
        --location=global
  1. 前のセクションでバックエンド サービスを使用して HTTP ヘルスチェックを構成した場合は、バックエンド サービスからヘルスチェックを切断します。
    gcloud compute backend-services update on-prem-service-a \
        --global \
        --no-health-checks
  1. HTTPS ヘルスチェックを作成します。
    gcloud compute health-checks create https service-a-https-health-check \
        --global
  1. 前に作成したバックエンド サービスにクライアント TLS ポリシーを接続します。これにより、クライアントからこのバックエンド サービスへのすべての送信リクエストに、未認証の HTTPS が適用されます。
    gcloud compute backend-services export on-prem-service-a \
        --global \
        --destination=on-prem-service-a.yaml

    cat << EOF >> on-prem-service-a.yaml
    securitySettings:
      clientTlsPolicy: projects/${PROJECT_ID}/locations/global/clientTlsPolicies/client_unauthenticated_tls_policy
    healthChecks:
      - projects/${PROJECT_ID}/global/healthChecks/service-a-https-health-check
    EOF

    gcloud compute backend-services import on-prem-service-a \
        --global \
        --source=on-prem-service-a.yaml

インターネット FQDN NEG を使用すると、FQDN を介して到達可能な任意のサービス（DNS で解決可能な外部サービスと内部サービス、Cloud Run サービスなど）にトラフィックをルーティングできます。

IP:Port NEG から FQDN:Port NEG に移行する

NON_GCP_PRIVATE_IP_PORT NEG では、サービス エンドポイントを静的な IP:PORT ペアとして NEG にプログラミングする必要がありますが、INTERNET_FQDN_NEG では DNS を使用してエンドポイントを動的に解決できます。オンプレミス サービス エンドポイントの DNS レコードを設定し、次の手順に沿って Cloud Service Mesh を構成することで、インターネット NEG に移行できます。

  1. FQDN の DNS レコードを設定します。
  2. FQDN を使用して新しいインターネット NEG を作成します。
  3. ステップ 2 で作成したインターネット NEG をバックエンドとして、新しいバックエンド サービスを作成します。ハイブリッド接続 NEG バックエンド サービスで使用したヘルスチェックを新しいバックエンド サービスに関連付けます。新しいリモート エンドポイントが正常であることを確認します。
  4. ルーティング ルール マップで、ハイブリッド接続 NEG を含む古いバックエンドを置き換えて新しいバックエンド サービスを参照するように更新します。
  5. 本番環境へのデプロイでライブ マイグレーション中にダウンタイムをゼロにするには、重み付けベースのトラフィック分割を使用します。最初はトラフィックの一部（たとえば 5%）だけを受信するように新しいバックエンド サービスを構成します。トラフィック分割の設定手順をご覧ください。
    1. 新しいリモート エンドポイントでトラフィックが正しく処理されていることを確認します。
  6. 重み付けベースのトラフィック分割を使用している場合は、すべて（100%）のバックエンド トラフィックを受信するように新しいバックエンド サービスを構成します。これにより、古いバックエンド サービスがドレインされます。
  7. 新しいバックエンドでトラフィックが問題なく処理されていることを確認したら、古いバックエンド サービスを削除します。

トラブルシューティング

デプロイメントの問題を解決するには、このセクションの手順を使用します。この情報で問題が解決されない場合は、Envoy を使用したデプロイのトラブルシューティングをご覧ください。

オンプレミス エンドポイントがトラフィックを受信しない

エンドポイントがトラフィックを受信していない場合は、エンドポイントがヘルスチェックに合格し、Envoy クライアントからの DNS クエリでその IP アドレスが常に返されていることを確認してください。

Envoy は strict_dns モードを使用して接続を管理します。トラフィックは、正常なすべての解決済みエンドポイントの間でロード バランシングされます。strict_dns モードでは、エンドポイントの解決順序は重要ではありませんが、Envoy は、返された IP アドレスのリストに含まれなくなったエンドポイントへのトラフィックをドレインします。

リクエストがオンプレミス サーバーに到達したときに HTTP ホストヘッダーが FQDN と一致しない

ドメイン example.com が 10.0.0.1（転送ルールの IP アドレス）に解決され、altostrat.com が 10.0.0.100（オンプレミス サービス エンドポイント）に解決される例について考えます。この環境で、NEG に構成されているドメイン altostrat.com にトラフィックを送信する必要があるとします。

Compute Engine または GKE のアプリケーションが HTTP Host ヘッダーを example.com（Host: example.com）に設定し、それがオンプレミス エンドポイントに転送される可能性があります。HTTPS を使用している場合、Envoy は TLS handshake 中に SNI を altostrat.com に設定します。Envoy は、SNI をクライアント TLS ポリシー リソースから取得します。

この競合が原因で、リクエストがオンプレミス エンドポイントに到達したときのリクエストの処理またはルーティングに問題が発生した場合は、Host ヘッダーを altostrat.com（Host: altostrat.com）に書き換えることで問題を回避できます。そのためには、Cloud Service Mesh で URL 書き換えを使用します。リモート エンドポイントにヘッダー書き換え機能がある場合は、リモート エンドポイントでこれを行うこともできます。

また、別の回避策として、Host ヘッダーを altostrat.com（Host: altostrat.com）に設定し、転送ルールの IP アドレスとして特別なアドレス 0.0.0.0 を使用する方法もあります。こちらのほうが簡単です。

Envoy が多数の 5xx エラーを返す

Envy が大量の 5xx エラーを返す場合は、次のようにします。

  • Envoy ログで、レスポンスがバックエンド（オンプレミスのバックエンド）から返されたものかどうかを確認し、5xx エラーの理由を特定します。
  • DNS クエリが正常に終了し、SERVFAIL または NXDOMAIN エラーがないことを確認します。
  • すべてのリモート エンドポイントがヘルスチェックに合格していることを確認します。
  • ヘルスチェックが構成されていない場合は、すべてのエンドポイントが Envoy から到達可能であることを確認してください。Google Cloud 側とオンプレミス側でファイアウォール ルールとルートを確認します。

サービス メッシュから公共のインターネット経由で外部サービスに到達できない

Cloud Service Mesh で FQDN バックエンドを使用することにより、公共のインターネットに存在するサービスにトラフィックを送信できます。最初に、Envoy クライアントと外部サービスとの間のインターネット接続を確立する必要があります。外部サービスへの接続中に 502 エラーが発生した場合は、次の手順を行います。

  • 適切なルート（特にデフォルト ルート 0.0.0.0/0）とファイアウォール ルールが構成されていることを確認します。
  • DNS クエリが正常に終了し、SERVFAIL または NXDOMAIN エラーがないことを確認します。
  • Envoy プロキシが外部 IP アドレスを持たない Compute Engine VM または限定公開 GKE クラスタ内で稼働している場合は、Cloud NAT または他の方法を構成して、送信インターネット接続を確立する必要があります。

エラーが解決しない場合、または他の 5xx エラーが発生した場合は、Envoy のログでエラーの原因を絞り込みます。

サービス メッシュからサーバーレス サービスに到達できない

Cloud Service Mesh で FQDN バックエンドを使用することにより、サーバーレス（Cloud Run、Cloud Run functions、App Engine）サービスにトラフィックを送信できます。Envoy プロキシが、外部 IP アドレスを持たない Compute Engine VM またはプライベート GKE クラスタで稼働している場合は、サブネットでプライベート Google アクセスを構成して Google API とサービスにアクセスできるようにする必要があります。

次のステップ