Anthos Service Mesh と Traffic Director は Cloud Service Mesh になりました。詳細については、Cloud Service Mesh の概要をご覧ください。

ハイブリッド接続ネットワークエンドポイントグループを使用してネットワークエッジサービスを設定する

Google は、オンプレミスのデータセンターや他のパブリッククラウドなどにある、Google Cloud 以外をベースとするサービス（オンプレミスとマルチクラウドサービス）の機能とセキュリティを強化する、さまざまなネットワークエッジサービスを提供しています。

これらのネットワークエッジサービスでは、次のことができます。

単一のエニーキャスト VIP を使用して、外部からのお客様のトラフィックを受け入れ、ルーティングする。
外部アプリケーションロードバランサと Google マネージド SSL 証明書を使用してエッジで TLS トラフィックを終了することで、サーバーの負荷を軽減する。
事前構成されたウェブアプリケーションファイアウォール（WAF）ルールを有効にし、Google Cloud Armor を使用して、受信トラフィックの許可リストと拒否リストを適用する。
Identity-Aware Proxy（IAP）でアプリケーションやリソースへのユーザーアクセスを制御する。
Cloud CDN を使用してコンテンツ配信とエンドユーザーのレイテンシを最適化する。

ネットワークエッジサービスの例。 — ネットワークエッジサービスの例（クリックして拡大）

こうしたメリットを、プライベート、オンプレミス、マルチクラウドのサービスで享受するために、公共のインターネットからトラフィックを受信する外部アプリケーションロードバランサをデプロイします。外部アプリケーションロードバランサは、Cloud Service Mesh が構成する中間プロキシにトラフィックを転送します。この中間プロキシは、Cloud VPN または Cloud Interconnect を使用して、オンプレミス環境または Google Cloud 以外の環境にトラフィックをルーティングします。

注: 外部アプリケーションロードバランサは、インターネットネットワークエンドポイントグループ（NEG）を使用して同様の機能を提供します。トラフィックは、Google Cloud の外部にある一般公開された IP アドレスと解決可能な完全修飾ドメイン名（FQDN）に直接送信でき、中間プロキシを必要としません。ただし、このトラフィックは、Virtual Private Cloud（VPC）ネットワークを通過せず、プライベート接続を使用してリモートエンドポイントにルーティングすることもできません。パブリックエンドポイントのサポートの詳細については、インターネットネットワークエンドポイントグループの概要をご覧ください。

このチュートリアルでは、Google のエッジで Google Cloud Armor を使用し、クライアントがオンプレミスサービスに非公開でアクセスすることを選択的に許可するためのエンドツーエンドの例について説明します。クライアントは IP アドレスに基づいてアクセスを許可されます。

次のタスクを実行します。

マネージドインスタンスグループ（MIG）に中間プロキシとして Envoy をデプロイします。この Envoy プロキシは自動的に Cloud Service Mesh に接続されます。
シミュレートされたプライベートのオンプレミス仮想マシン（VM）インスタンスを作成します。実際の例ではほとんどの場合、オンプレミス VM がすでに存在します。
中間プロキシに到達するすべてのリクエストがシミュレートされたオンプレミス VM に転送されるように Cloud Service Mesh を構成します。
公共のインターネットからトラフィックを受信して中間プロキシに転送する、外部アプリケーションロードバランサを作成します。
外部アプリケーションロードバランサに Google Cloud Armor セキュリティポリシーを接続します。

これらのタスクを完了したら、必要に応じて、追加のエッジサービスと高度なトラフィック管理機能を設定できます。

前提条件

中間プロキシを設定する前に、次の作業を行ってください。

Envoy を使用した Cloud Service Mesh の設定の準備を確認し、前提条件のタスクをすべて完了します。これには、必要な権限とロールの付与と Cloud Service Mesh API の有効化が含まれます。
プライベートのオンプレミスエンドポイントが、Cloud VPN や Cloud Interconnect を使用して Google Cloud Virtual Private Cloud（VPC）ネットワーク内から到達可能となるようにしてください。このチュートリアルの例では、単に Google Cloud 内のエンドポイントにトラフィックを転送するだけで、それに合わせてハイブリッド接続を構成する必要はありません。実際のデプロイシナリオでは、ハイブリッド接続を構成する必要があります。
VPC サブネットの CIDR 範囲がリモートの CIDR 範囲と競合しないようにしてください。IP アドレスが重複する場合、リモート接続よりもサブネットルートが優先されます。
このデモを行うため、Google Cloud Armor セキュリティポリシーの作成と更新に必要な権限を取得します。Cloud CDN など、別のサービスを使用する場合は、権限が異なる場合があります。

中間プロキシを Compute Engine VM にデプロイする

このセクションでは、Envoy を Compute Engine の中間プロキシとしてデプロイし、外部ロードバランサからトラフィックを受信してリモートの宛先に転送する方法について説明します。

中間プロキシのインスタンステンプレートを作成する

インスタンステンプレートは、マネージドインスタンスグループ（MIG）内の VM の構成を指定します。

次のテンプレートを使用して、Cloud Service Mesh に接続された Envoy プロキシを持つ VM インスタンスを作成します。
```
gcloud compute instance-templates create td-middle-proxy \
    --service-proxy=enabled \
    --tags=allow-hc
```
ネットワーク名の指定、ログパスの設定、トレースの有効化など、Envoy のデプロイをカスタマイズするには、Envoy の自動デプロイオプションガイドをご覧ください。

中間プロキシの MIG を作成する

テンプレートに基づく MIG を作成します。この例では、インスタンスグループのサイズを 1 に固定して、単一インスタンスをデプロイします。本番環境で使用する場合は、たとえば CPU 使用率に基づいて自動スケーリングを有効にすると、中間プロキシが大量のトラフィックを処理する必要がある場合にボトルネックを回避できます。
```
gcloud compute instance-groups managed create td-middle-proxy-us-central1-a \
    --zone=us-central1-a \
    --template=td-middle-proxy \
    --size=1
```

今後の構成と検証を行うために、インスタンスの内部 IP アドレスを特定して、MIDDLE_PROXY_IP に保存します。

MIDDLE_PROXY_IP=$(gcloud compute instances list \
    --filter="name~'td-middle-proxy-us-central1-a-.*'" \
    --zones=us-central1-a \
    --format="value(networkInterfaces.networkIP)")

この例では、us-central1-a で Envoy を実行している VM インスタンスを含む MIG を作成します。このチュートリアルの後半では、クライアントからの公共のインターネットトラフィックを処理する外部ロードバランサを作成します。

外部ロードバランサは、クライアントに最も近いリージョンと、そのリージョン内の MIG にトラフィックを自動的にルーティングできます。そのため、複数の MIG を作成することを検討してください。Google Cloud で使用可能なリージョンとゾーンの完全な一覧については、リージョンとゾーンをご覧ください。

シミュレートされたオンプレミスサービスをデプロイする

このセクションでは、ハイブリッド接続ネットワークエンドポイントグループ（NEG）のデプロイについて説明します。本番環境のデプロイでは、この NEG にはオンプレミスサーバーに解決されるエンドポイント（IP:port）が含まれます。この例では、IP:port で到達可能な Compute Engine VM を作成します。この VM はシミュレートされたオンプレミスサーバーとして機能します。

シミュレートされたオンプレミス VM を作成する

単一の VM インスタンスをデプロイして、プライベートのオンプレミスサーバーをシミュレートします。

gcloud compute instances create on-prem-vm \
    --zone=us-central1-a \
    --metadata startup-script='#! /bin/bash
## Installs apache and a custom homepage
sudo su -
apt-get update
apt-get install -y apache2
cat <<EOF > /var/www/html/index.html
<html><body><h1>Hello world from on-premises!</h1></body></html>
EOF'

今後の構成と検証のために、その内部 IP アドレスを特定して保存します。この VM 上のサーバーは、ポート 80 で受信リクエストをリッスンします。
```
ON_PREM_IP=$(gcloud compute instances describe on-prem-vm \
    --zone=us-central1-a \
    --format="value(networkInterfaces.networkIP)" | sed "s/['\[\]]*//g")
```

NEG を作成する

non-gcp-private-ip-port ネットワークエンドポイントタイプを指定して、デモ設定用に NEG を作成します。シミュレートされたオンプレミス VM の IP アドレスとポートを、この NEG のエンドポイントとして追加します。前述の手順を行うと、IP アドレスが ON_PREM_IP 環境変数に格納されます。

NEG を作成します。

gcloud compute network-endpoint-groups create td-on-prem-neg \
    --network-endpoint-type=non-gcp-private-ip-port \
    --zone=us-central1-a

IP:port を新しい NEG に追加します。

gcloud compute network-endpoint-groups update td-on-prem-neg \
    --zone=us-central1-a \
    --add-endpoint="ip=$ON_PREM_IP,port=80"

Cloud Load Balancing コンポーネントを使用して Cloud Service Mesh を構成する

このセクションでは、Cloud Service Mesh を構成し、中間プロキシが非公開のオンプレミスサービスにトラフィックを転送できるようにする方法を説明します。次のコンポーネントを構成します。

ヘルスチェック。このヘルスチェックは、他の NEG タイプに構成されたヘルスチェックとは少し異なる動きをします。
バックエンドサービス。詳細については、バックエンドサービスの概要をご覧ください。
ルーティングルールマップ。このステップには、転送ルール、ターゲットプロキシ、URL マップの作成が含まれます。詳細については、ルーティングルールマップをご覧ください。

ヘルスチェックを作成する

ヘルスチェックは、エンドポイントが正常であり、リクエストを受信できることを確認します。このタイプの NEG のヘルスチェックでは、Envoy の分散ヘルスチェックメカニズムが使用されます。

他の NEG タイプでは、Google Cloud の一元化されたヘルスチェックシステムが使用されます。

gcloud compute health-checks create http td-on-prem-health-check

バックエンドサービスを作成する

Cloud Service Mesh で使用する INTERNAL_SELF_MANAGED ロードバランシング方式を使用してバックエンドサービスを作成します。このバックエンドサービスを作成するときに、先ほど作成したヘルスチェックを指定します。
```
gcloud compute backend-services create td-on-prem-backend-service \
    --global \
    --load-balancing-scheme=INTERNAL_SELF_MANAGED \
    --health-checks=td-on-prem-health-check
```

先ほど作成した NEG をこのバックエンドサービスのバックエンドとして追加します。

gcloud compute backend-services add-backend td-on-prem-backend-service \
    --global \
    --network-endpoint-group=td-on-prem-neg \
    --network-endpoint-group-zone=us-central1-a \
    --balancing-mode=RATE \
    --max-rate-per-endpoint=5

ルーティングルールマップを作成する

ルーティングルールマップは、Cloud Service Mesh がトラフィックをバックエンドサービスに転送する方法を定義します。

先ほど定義したバックエンドサービスを使用する URL マップを作成します。
```
gcloud compute url-maps create td-hybrid-url-map \
    --default-service=td-on-prem-backend-service
```
次の内容のファイルを、target_proxy.yaml という名前で作成します。
```
name: td-hybrid-proxy
proxyBind: true
urlMap: global/urlMaps/td-hybrid-url-map
```
import コマンドを使用してターゲット HTTP プロキシを作成します（詳細については、Cloud Service Mesh のターゲットプロキシをご覧ください）。
```
gcloud compute target-http-proxies import td-hybrid-proxy \
    --source=target_proxy.yaml
```
このターゲット HTTP プロキシを参照する転送ルールを作成します。転送ルールの IP アドレスを 0.0.0.0 に設定します。ルールの IP アドレスを 0.0.0.0 に設定すると、受信ポート、HTTP ホスト名、URL マップで構成されているパス情報に基づいてトラフィックがルーティングされます。HTTP リクエストで指定された IP アドレスは無視されます。
```
gcloud compute forwarding-rules create td-hybrid-forwarding-rule \
    --global \
    --load-balancing-scheme=INTERNAL_SELF_MANAGED \
    --address=0.0.0.0 \
    --target-http-proxy=td-hybrid-proxy \
    --ports=8080 \
    --network=default
```

シミュレートされたオンプレミスサービスに中間プロキシがリクエストをルーティングできることを確認する

Cloud Service Mesh は、中間プロキシを経由してシミュレートされたオンプレミスサービスにトラフィックを転送するように構成されました。この構成を確認するには、テストクライアント VM を作成して、その VM にログインし、Envoy を実行している中間プロキシにリクエストを送信します。構成を確認したら、テストクライアント VM を削除します。

中間プロキシの IP アドレスを取得します。この情報は、確認の手順だけで必要になります。
```
gcloud compute instances list
```
td-middle-proxy-us-central1-a MIG 内のインスタンスの IP アドレスを書き留めるか、別の方法で記録します。

テストクライアントインスタンスを作成します。

gcloud compute instances create test-client \
    --zone=us-central1-a

ssh を使用して、テストクライアントにログインします。
```
gcloud compute ssh test-client
    --zone=us-central1-a
```
中間プロキシ VM にリクエストを送信します。MIDDLE_PROXY_IP は、先ほど取得した IP アドレスに置き換えます。
```
curl $MIDDLE_PROXY_IP:8080
```
次の出力が表示されます。
```
Hello world from on-premises!
```
テストクライアント VM を終了します。終了したら、VM を削除できます。
```
gcloud compute instances delete test-client \
    --zone=us-central1-a
```

外部アプリケーションロードバランサをデプロイする

このセクションでは、受信トラフィックを中間プロキシに送信する外部アプリケーションロードバランサをデプロイします。このデプロイは、標準の外部アプリケーションロードバランサの設定です。

外部 IP アドレスを予約する

外部クライアントがトラフィックを送信するグローバル静的外部 IP アドレス（external-lb-vip）を作成します。この外部 IP アドレスは、このチュートリアルの後半の確認手順で取得します。

gcloud compute addresses create external-lb-vip \
    --ip-version=IPV4 \
    --global

外部 HTTP ロードバランサを設定する

構成済みの中間プロキシにインターネットのお客様のトラフィックをルーティングするように外部ロードバランサを構成します。

中間プロキシを実行する MIG が正常で、かつ、トラフィックを受信できるかどうかを判断するために使用するヘルスチェックを作成します。
```
gcloud compute health-checks create tcp tcp-basic-check \
    --port=8080
```

ヘルスチェックを許可するファイアウォールルールを作成します。ここで allow-hc タグを再利用して、中間プロキシ VM にファイアウォールルールを適用します。

gcloud compute firewall-rules create fw-allow-health-checks \
    --network=default \
    --action=ALLOW \
    --direction=INGRESS \
    --source-ranges=35.191.0.0/16,130.211.0.0/22 \
    --target-tags=allow-hc \
    --rules=tcp

バックエンドサービスを作成します。

gcloud compute backend-services create td-middle-proxy-backend-service \
    --protocol=HTTP \
    --health-checks=tcp-basic-check \
    --global

中間プロキシ MIG をバックエンドとしてこのバックエンドサービスに追加します。

gcloud compute backend-services add-backend td-middle-proxy-backend-service \
    --instance-group=td-middle-proxy-us-central1-a \
    --instance-group-zone=us-central1-a \
    --global

デフォルトのバックエンドサービスとして中間プロキシに受信リクエストをルーティングする URL マップを作成します。
```
gcloud compute url-maps create lb-map-http \
    --default-service=td-middle-proxy-backend-service
```
外部ロードバランサの転送ルール仮想 IP アドレス（VIP）へのリクエストを URL マップに従って処理するように、ターゲット HTTP プロキシを作成します。
```
gcloud compute target-http-proxies create http-lb-proxy \
    --url-map=lb-map-http
```

受信リクエストをターゲット HTTP プロキシに転送するグローバル転送ルールを作成します。

gcloud compute forwarding-rules create http-forwarding-rule \
    --address=external-lb-vip\
    --global \
    --load-balancing-scheme=EXTERNAL \
    --target-http-proxy=http-lb-proxy \
    --ports=80

MIG の名前付きポートを設定する

インスタンスグループに名前付きポートを設定して、中間プロキシが外部ロードバランサから HTTP トラフィックを受信できるようにします。

gcloud compute instance-groups managed set-named-ports td-middle-proxy-us-central1-a \
    --named-ports=http:8080 \
    --zone=us-central1-a

外部アプリケーションロードバランサの構成を確認する

この手順では、外部ロードバランサが正しく設定されていることを確認します。

ロードバランサの VIP にリクエストを送信すると、シミュレートされたオンプレミス VM からレスポンスを受信できるはずです。
```
PUBLIC_VIP=gcloud compute addresses describe external-lb-vip \
    --format="get(address)" \
    --global
```
外部 IP アドレスに curl リクエストを送信して（PUBLIC_VIP）、Hello world メッセージを受信することを確認します。
```
curl $PUBLIC_VIP
```
次の出力が表示されます。
```
Hello world from on-premises!
```

Google Cloud Armor を有効にする

Google Cloud Armor セキュリティポリシーを構成して、CLIENT_IP_RANGE からサービスへのアクセスのみを許可します。これには、テスト対象のクライアントデバイスの外部 IP アドレス（例: "192.0.2.0/24"）を含める必要があります。

これらのポリシーは、外部ロードバランサのバックエンドサービス（この例では、中間プロキシを指す td-hybrid-backend-service）に適用されます。これらのルールの設定に必要な権限については、Google Cloud Armor セキュリティポリシーの構成をご覧ください。

Google Cloud Armor セキュリティポリシーを作成します。

gcloud compute security-policies create external-clients-policy \
    --description="policy for external clients"

セキュリティポリシーのデフォルトルールを更新し、すべてのトラフィックを拒否します。

gcloud compute security-policies rules update 2147483647 \
    --security-policy=external-clients-policy \
    --action="deny-404"

特定の IP 範囲からのトラフィックを許可するために、優先度の高いルールを追加します。

gcloud compute security-policies rules create 1000 \
    --security-policy=external-clients-policy \
    --description="allow traffic from CLIENT_IP_RANGE" \
    --src-ip-ranges="CLIENT_IP_RANGE" \
    --action="allow"

Google Cloud Armor セキュリティポリシーをバックエンドサービスに接続します。

gcloud compute backend-services update td-middle-proxy-backend-service \
    --security-policy=external-clients-policy

最終確認

外部アプリケーションロードバランサのパブリック仮想 IP アドレスに curl リクエストを発行します。クライアントデバイスの IP アドレスが、先ほど指定された CLIENT_IP_RANGE の範囲内にあれば、想定されるレスポンスが返されます。
```
curl $PUBLIC_VIP
```
次の出力が表示されます。
```
Hello world from on-premises!
```
IP アドレスが CLIENT_IP_RANGE の外部にある別のクライアントデバイスに同じ curl リクエストを発行するか、セキュリティポリシーのルールを更新してクライアント IP アドレスを含めないようにします。今度は、404 Not Found エラーが返されるはずです。

トラブルシューティング

以下の手順では、構成に関する問題を解決する方法について説明します。

オンプレミスサービスに、グローバル外部アプリケーションロードバランサの IP アドレスを介してアクセスできない

Envoy が実行されている Google Cloud VM でオンプレミスサービスにすでにアクセスできる場合は、次の手順に沿って設定のトラブルシューティングを行います。

Google Cloud Envoy MIG が正常と報告されていることを確認します。Google Cloud Console で [ネットワークサービス] > [ロードバランシング] に移動し、[url-map lb-map-http] をクリックして詳細を表示します。td-middle-proxy-us-central1-a で 1/1 のインスタンスが正常であることを確認できるはずです。
正常な状態でない場合は、Envoy を実行している Google Cloud VM への上り（内向き）トラフィックを許可するようにファイアウォールルールが構成されているかどうかを確認します。
```
gcloud compute firewall-rules describe fw-allow-health-check
```
次の出力が表示されます。
```
allowed:
‑ IPProtocol: tcp
...
direction: INGRESS
disabled: false
...
...
sourceRanges:
‑ 130.211.0.0/22
‑ 35.191.0.0/16
targetTags:
‑ allow-hc
```

次のステップ

オンプレミスまたはマルチクラウドサービス用の、より複雑なルーティングポリシーを確認するには、Cloud Service Mesh の高度なトラフィック管理機能をご覧ください。
Cloud Service Mesh をデプロイするには、セットアップガイドの概要をご覧ください。
他のネットワークエッジサービスを有効にするには、次のガイドをご覧ください。
- Compute Engine の IAP の有効化
- マネージドインスタンスグループを使用した Cloud CDN の設定