外部バックエンドを設定する

このドキュメントでは、インターネットの完全修飾ドメイン名（FQDN）ネットワーク エンドポイント グループ（NEG）を使用して、Traffic Director の外部バックエンドを構成する方法について説明します。以下の説明は、次のものについて中級から上級レベルの高度な知識があることを前提としています。

• 外部アプリケーション ロードバランサ
• Cloud DNS
• Traffic Director
• ハイブリッド接続

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

• 送信トラフィックにインターネット NEG と未認証の TLS を使用するように Traffic Director を構成する
• サービス メッシュから Cloud Run サービスにトラフィックをルーティングする

始める前に

インターネット ネットワーク エンドポイント グループを持つ Traffic Director の概要を確認します。

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

• 中間プロキシ、Traffic Director リソース、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 と TLS SNI を使用したトラフィック ルーティング

送信トラフィックに FQDN と TLS を使用して、Traffic Director でインターネット NEG を構成した後、デプロイメントは、以下の図とトラフィックの説明のようになります。

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

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

ステップ	説明
0	Envoy が xDS を通じて Traffic Director から 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
   

2. 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 を使用して Traffic Director を構成する

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

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

gcloud

1. インターネット NEG を作成します。

   gcloud compute network-endpoint-groups create on-prem-service-a-neg \
       --global \
       --network-endpoint-type INTERNET_FQDN_PORT
   

2. FQDN:Port エンドポイントをインターネット NEG に追加します。

   gcloud compute network-endpoint-groups update on-prem-service-a-neg \
       --global \
       --add-endpoint=fqdn=example.com,port=443
   

3. グローバル ヘルスチェックを作成します。

   gcloud compute health-checks create http service-a-http-health-check \
       --global
   

4. 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
   

5. 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
   

2. ターゲット HTTP プロキシを作成し、URL マップをターゲット プロキシに関連付けます。

   gcloud compute target-http-proxies create td-proxy \
       --url-map td-url-map
   

3. 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
   

2. 前のセクションでバックエンド サービスを使用して HTTP ヘルスチェックを構成した場合は、バックエンド サービスからヘルスチェックを切断します。

   gcloud compute backend-services update on-prem-service-a \
       --global \
       --no-health-checks
   

3. HTTPS ヘルスチェックを作成します。

   gcloud compute health-checks create https service-a-https-health-check \
       --global
   

4. 前に作成したバックエンド サービスにクライアント 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 レコードを設定し、次の手順で説明するように Traffic Director を構成することで、インターネット NEG に移行できます。

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

トラブルシューティング

デプロイメントの問題を解決するには、このセクションの手順を使用します。この情報で問題が解決されない場合は、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）に書き換えることで問題を回避できます。この処理を行うには、Traffic Director で URL 書き換えを使用します。ヘッダー書き換え機能がある場合はリモート エンドポイントで行うことも可能です。

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

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

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

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

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

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

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

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

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

Traffic Director で FQDN バックエンドを使用し、サーバーレス（Cloud Run、Cloud Functions、App Engine）サービスにトラフィックを送信できます。Envoy プロキシが外部 IP アドレスのない Compute Engine VM または限定公開 GKE クラスタで稼働している場合は、そのサブネットで限定公開の Google アクセスを構成し、Google API とサービスにアクセスできるようにします。

次のステップ

• クライアント TLS ポリシーの詳細については、Traffic Director サービス セキュリティと Network Security API をご覧ください。