Cloud Run でクロスリージョン内部アプリケーション ロードバランサを設定する

プレビュー

このプロダクトまたは機能には、サービス固有の利用規約の「一般的なサービス規約」の「pre-GA サービス規約」が適用されます。 一般提供前のプロダクトと機能は「現状のまま」ご利用いただけますが、サポートが制限される場合があります。 詳しくは、リリース ステージの説明をご覧ください。

このドキュメントでは、Cloud Run でクロスリージョン内部アプリケーション ロードバランサをデプロイする方法について説明します。この設定を行うため、ロードバランサにサーバーレス NEG バックエンドを使用します。

サーバーレス NEG を使用すると、ロードバランサで Cloud Run サービスを使用できます。サーバーレス NEG バックエンドを使用してロードバランサを構成した後は、そのロードバランサへのリクエストが Cloud Run バックエンドに転送されるようになります。

クロスリージョン ロード バランシングを使用すると、特定のリージョンがアクセス不能となった場合にトラフィックが別のリージョンに自動的に転送され、冗長性が確保されます。プロキシ トラフィックは、Envoy のロケーションに基づいて次のように Cloud Run サービスに分散されます。

• マルチリージョンの Cloud Run サービスが Envoy と同じリージョンに構成されている場合は、Envoy と同じリージョンにある NEG が優先されます。外れ値検出が有効で、ローカル NEG が異常な場合にのみ、トラフィックがフェイルオーバー リージョンに送信されます。
• マルチリージョンの Cloud Run サービスが Envoy と同じリージョンに構成されていない場合、トラフィックはすべての NEG に均等に分散されます。近くにある NEG は優先されません。
• Identity-Aware Proxy が有効になっている場合は、単一のサーバーレス NEG のみがサポートされます。追加の Cloud Run サービスを構成することは可能ですが、ロードバランサはそれらのサービスにトラフィックを送信しません。

始める前に

このガイドに進む前に、次の内容を理解しておいてください。

• 内部アプリケーション ロードバランサの概要（制限事項セクションを含む）
• VPC ファイアウォール ルール
• サーバーレス ネットワーク エンドポイント グループの概要

Cloud Run サービスをデプロイする

このページで説明する手順では、Cloud Run サービスをすでに実行中であることを前提としています。

このページの例では、Cloud Run クイックスタートを使用して Cloud Run サービスをデプロイしています。

インターネットから Cloud Run サービスにアクセスできないようにするには、上り（内向き）を internal に制限します。内部アプリケーション ロードバランサからのトラフィックは内部トラフィックとみなされます。

Cloud Run サービスを複数のリージョンに配置すると、1 つのリージョンでの障害を防ぐことができます。Cloud Run サービスを REGION_A リージョンと REGION_B リージョンにデプロイするには、次のコマンドを実行します。

gcloud

gcloud run deploy CLOUD_RUN_SERVICE_NAMEA \
   --platform=managed \
   --allow-unauthenticated \
   --ingress=internal \
   --region=REGION_A \
   --image=IMAGE_URLA

gcloud run deploy CLOUD_RUN_SERVICE_NAMEB \
   --platform=managed \
   --allow-unauthenticated \
   --ingress=internal \
   --region=REGION_B \
   --image=IMAGE_URLB

作成するサービスの名前をメモします。このページの残りの部分では、このサービスにリクエストを転送するロードバランサの設定方法について説明します。

SSL 証明書リソースを設定する

次のように Certificate Manager SSL 証明書リソースを作成します。

• グローバル セルフマネージド証明書をデプロイする
• Certificate Authority Service インスタンスによって発行された Google マネージド証明書を作成する
• DNS 認証を使用して Google マネージド証明書をデプロイする

Google マネージド証明書を使用することをおすすめします。

権限

このガイドに従うには、プロジェクト内でインスタンスを作成してネットワークを変更できる必要があります。そのためにはプロジェクトのオーナーまたは編集者であるか、または次の Compute Engine IAM のロールをすべて持っている必要があります。

タスク	必要なロール
ネットワーク、サブネット、ロードバランサ コンポーネントの作成	Compute ネットワーク管理者
ファイアウォール ルールの追加と削除	Compute セキュリティ管理者
インスタンスの作成	Compute インスタンス管理者

詳細については、次のガイドをご覧ください。

• ロールと権限
• 転送ルールの IAM 条件

設定の概要

クロスリージョン内部アプリケーション ロードバランサは、次の図のように構成できます。

Cloud Run をデプロイしたクロスリージョン内部アプリケーション ロードバランサ（クリックして拡大）

図に示すように、この例では、REGION_A と REGION_B リージョン内に 1 つのバックエンド サービスと 2 つの Cloud Run デプロイメントがある VPC ネットワークに、クロスリージョン内部アプリケーション ロードバランサを作成します。

クロスリージョン内部アプリケーション ロードバランサの設定は次のとおりです。

1. 次のサブネットを持つ VPC ネットワーク。

   • サブネット SUBNET_A と REGION_A のプロキシ専用サブネット
   • サブネット SUBNET_B と REGION_B のプロキシ専用サブネット

   クロスリージョン内部アプリケーション ロードバランサを使用する VPC ネットワークのリージョンごとにプロキシ専用サブネットを作成する必要があります。リージョンのプロキシ専用サブネットは、リージョン内のすべてのクロスリージョン内部アプリケーション ロードバランサで共有されます。ロードバランサからサービスのバックエンドに送信されるパケットのソースアドレスは、プロキシ専用サブネットから割り振られます。この例では、リージョン REGION_B のプロキシ専用サブネットのプライマリ IP アドレス範囲は 10.129.0.0/23 で、REGION_A のプライマリ IP アドレス範囲は 10.130.0.0/23 であり、これが推奨サブネット サイズです。

2. ネットワーク内のプロキシ専用サブネット トラフィック フローを許可するファイアウォール ルール。10.129.0.0/23 と 10.130.0.0/23（この例ではプロキシ専用サブネットの範囲）からの TCP ポート 80、443、8080 トラフィックを許可する 1 つのルールが追加されることになります。

3. ヘルスチェック プローブ用の別のファイアウォール ルール。

4. REGION_A リージョンと REGION_B リージョンに Cloud Run デプロイのサーバーレス バックエンドが存在する高可用性設定。一方のリージョンのバックエンドが停止した場合、トラフィックはもう一方のリージョンにフェイルオーバーされます。

5. バックエンドの使用状況と健全性をモニタリングするグローバル バックエンド サービス。バックエンド サービスで外れ値検出を有効にします。

6. グローバル URL マップはリクエストの URL を解析し、リクエスト URL のホストとパスに基づいて特定のバックエンド サービスにリクエストを転送します。

7. グローバル ターゲット HTTP または HTTPS プロキシ。ユーザーからリクエストを受け取り、URL マップに転送します。HTTPS の場合、リージョン SSL 証明書リソースを構成します。HTTPS 負荷分散を構成する場合、ターゲット プロキシは SSL 証明書を使用して SSL トラフィックを復号します。ターゲット プロキシは、HTTP または HTTPS を使用してトラフィックをインスタンスに転送できます。

8. ロードバランサの内部 IP アドレスを持つグローバル転送ルール。受信リクエストをターゲット プロキシに転送します。

   転送ルールに関連付けられた内部 IP アドレスは、同じネットワークとリージョンにある任意のサブネットから取得できます。次の条件に注意してください。

   • IP アドレスは、バックエンド インスタンス グループと同じサブネットから取得できます（必須ではありません）。
   • IP アドレスは、--purpose フラグが GLOBAL_MANAGED_PROXY に設定されている予約済みプロキシ専用サブネットからは取得しないでください。
   • 複数の転送ルールで同じ内部 IP アドレスを使用する場合は、IP アドレス --purpose フラグを SHARED_LOADBALANCER_VIP に設定します。

9. 省略可: クライアントに最も近いリージョンのロードバランサ VIP にクライアント トラフィックを転送するように、GEO タイプの DNS ルーティング ポリシーを構成します。

ネットワークとサブネットを構成する

VPC ネットワーク内で、バックエンドが構成されている各リージョンにサブネットを構成します。さらに、ロードバランサを構成する各リージョンに proxy-only-subnet を構成します。

この例では、次の VPC ネットワーク、リージョン、サブネットを使用します。

• ネットワーク。ネットワークは、NETWORK という名前のカスタムモードの VPC ネットワークです。

• バックエンドのサブネット。REGION_A リージョンの SUBNET_A という名前のサブネットは、プライマリ IP 範囲として 10.1.2.0/24 を使用します。REGION_B リージョンの SUBNET_A という名前のサブネットは、プライマリ IP 範囲として 10.1.3.0/24 を使用します。

• プロキシのサブネット。REGION_A リージョンの PROXY_SN_A という名前のサブネットは、プライマリ IP 範囲として 10.129.0.0/23 を使用します。REGION_B リージョンの PROXY_SN_B という名前のサブネットは、プライマリ IP 範囲として 10.130.0.0/23 を使用します。

クロスリージョン内部アプリケーション ロードバランサには、VPC 内の任意のリージョンからアクセスできます。これにより、任意のリージョンのクライアントがロードバランサのバックエンドにグローバルにアクセスできるようになります。

注: サブネットのネットワーク、リージョン、パラメータの名前は変更できます。ただし、このガイドの以降の手順では、上に示したネットワーク、リージョン、サブネットの各パラメータを使用します。

サブネットを構成する

コンソール

1. Google Cloud コンソールの [VPC ネットワーク] ページに移動します。

   [VPC ネットワーク] に移動

2. [VPC ネットワークを作成] をクリックします。

3. [名前] に「NETWORK」と入力します。

4. [サブネット] セクションで、[サブネット作成モード] を [カスタム] に設定します。

5. ロードバランサのバックエンド用のサブネットを作成します。[新しいサブネット] セクションに、次の情報を入力します。

   • 名前: SUBNET_A
   • リージョン: REGION_A
   • IP アドレス範囲: 10.1.2.0/24

6. [完了] をクリックします。

7. [サブネットを追加] をクリックします。

8. ロードバランサのバックエンド用のサブネットを作成します。[新しいサブネット] セクションに、次の情報を入力します。

   • 名前: SUBNET_B
   • リージョン: REGION_B
   • IP アドレス範囲: 10.1.3.0/24

9. [完了] をクリックします。

10. [作成] をクリックします。

gcloud

1. gcloud compute networks create コマンドを使用して、カスタム VPC ネットワークを作成します。

   gcloud compute networks create NETWORK --subnet-mode=custom
   

2. gcloud compute networks subnets create コマンドを使用して、REGION_A リージョンの NETWORK ネットワークにサブネットを作成します。

   gcloud compute networks subnets create SUBNET_A \
       --network=NETWORK \
       --range=10.1.2.0/24 \
       --region=REGION_A
   

3. gcloud compute networks subnets create コマンドを使用して、REGION_B リージョンの NETWORK ネットワークにサブネットを作成します。

   gcloud compute networks subnets create SUBNET_B \
       --network=NETWORK \
       --range=10.1.3.0/24 \
       --region=REGION_B
   

API

networks.insert メソッドに POST リクエストを送信します。PROJECT_ID は実際のプロジェクト ID に置き換えます。

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks

{
 "routingConfig": {
   "routingMode": "regional"
 },
 "name": "NETWORK",
 "autoCreateSubnetworks": false
}

subnetworks.insert メソッドに POST リクエストを送信します。PROJECT_ID は実際のプロジェクト ID に置き換えます。

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/subnetworks

{
 "name": "SUBNET_A",
 "network": "projects/PROJECT_ID/global/networks/NETWORK",
 "ipCidrRange": "10.1.2.0/24",
 "region": "projects/PROJECT_ID/regions/REGION_A",
}

subnetworks.insert メソッドに POST リクエストを送信します。PROJECT_ID は実際のプロジェクト ID に置き換えます。

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/subnetworks

{
 "name": "SUBNET_B",
 "network": "projects/PROJECT_ID/global/networks/NETWORK",
 "ipCidrRange": "10.1.3.0/24",
 "region": "projects/PROJECT_ID/regions/REGION_B",
}

プロキシ専用サブネットを構成する

プロキシ専用サブネットには、Google Cloud がユーザーに代わって Envoy プロキシを実行する際に使用する一連の IP アドレスが用意されています。このプロキシは、クライアントからの接続を終端し、バックエンドへの接続を作成します。

このプロキシ専用サブネットは、VPC ネットワークの同じリージョン内のすべての Envoy ベースのロードバランサで使用されます。特定の目的では、リージョンごと、ネットワークごとにアクティブなプロキシ専用サブネットが 1 つだけの場合があります。

重要: プロキシ専用サブネットのアドレスをロードバランサの転送ルールまたはバックエンドに割り当てないでください。転送ルールの IP アドレスとバックエンド インスタンスの IP アドレスは、このサブネット範囲とは異なるサブネット範囲から割り当てます。このサブネット範囲は、Google Cloud が Google Cloud マネージド プロキシ用に予約します。

コンソール

Google Cloud コンソールを使用している場合は、しばらく待ってから、[ロード バランシング] ページでプロキシ専用サブネットを作成できます。

プロキシ専用サブネットを今すぐ作成する場合は、次の操作を行います。

1. Google Cloud コンソールの [VPC ネットワーク] ページに移動します。

   [VPC ネットワーク] に移動

2. VPC ネットワークの名前 NETWORK をクリックします。
3. [サブネットを追加] をクリックします。
4. [名前] ボックスに「PROXY_SN_A」と入力します。
5. [リージョン] リストで [REGION_A] を選択します。
6. [目的] リストで、[クロスリージョンのマネージド プロキシ] を選択します。
7. [IP アドレス範囲] に「10.129.0.0/23」と入力します。
8. [追加] をクリックします。

REGION_B にプロキシ専用サブネットを作成します。

1. VPC ネットワークの名前 NETWORK をクリックします。
2. [サブネットを追加] をクリックします。
3. [名前] ボックスに「PROXY_SN_B」と入力します。
4. [リージョン] リストで [REGION_B] を選択します。
5. [目的] リストで、[クロスリージョンのマネージド プロキシ] を選択します。
6. [IP アドレス範囲] に「10.130.0.0/23」と入力します。
7. [追加] をクリックします。

gcloud

gcloud compute networks subnets create コマンドを使用して、プロキシ専用サブネットを作成します。

    gcloud compute networks subnets create PROXY_SN_A \
        --purpose=GLOBAL_MANAGED_PROXY \
        --role=ACTIVE \
        --region=REGION_A \
        --network=NETWORK \
        --range=10.129.0.0/23
    

    gcloud compute networks subnets create PROXY_SN_B \
        --purpose=GLOBAL_MANAGED_PROXY \
        --role=ACTIVE \
        --region=REGION_B \
        --network=NETWORK \
        --range=10.130.0.0/23
    

API

subnetworks.insert メソッドを使用してプロキシ専用サブネットを作成します。PROJECT_ID は実際のプロジェクト ID に置き換えます。

    POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/subnetworks

    {
      "name": "PROXY_SN_A",
      "ipCidrRange": "10.129.0.0/23",
      "network": "projects/PROJECT_ID/global/networks/NETWORK",
      "region": "projects/PROJECT_ID/regions/REGION_A",
      "purpose": "GLOBAL_MANAGED_PROXY",
      "role": "ACTIVE"
    }
   

    POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/subnetworks

    {
      "name": "PROXY_SN_B",
      "ipCidrRange": "10.130.0.0/23",
      "network": "projects/PROJECT_ID/global/networks/NETWORK",
      "region": "projects/PROJECT_ID/regions/REGION_B",
      "purpose": "GLOBAL_MANAGED_PROXY",
      "role": "ACTIVE"
    }
   

サーバーレス NEG を作成する

1. Cloud Run サービスにサーバーレス NEG を作成します。

   gcloud compute network-endpoint-groups create gl7ilb-serverless-neg-a \
      --region=REGION_A \
      --network-endpoint-type=serverless  \
      --cloud-run-service=CLOUD_RUN_SERVICE_NAMEA
   

   gcloud compute network-endpoint-groups create gl7ilb-serverless-neg-b \
      --region=REGION_B \
      --network-endpoint-type=serverless  \
      --cloud-run-service=CLOUD_RUN_SERVICE_NAMEB
   

ロードバランサを構成する

ロードバランサからサーバーレス NEG バックエンドへのトラフィックは、ファイアウォール ルールの対象外である VPC の外部で定義された特別なルートを使用します。したがって、ロードバランサにサーバーレス NEG バックエンドしかない場合は、プロキシ専用サブネットからサーバーレス バックエンドへのトラフィックを許可するファイアウォール ルールを作成する必要はありません。

gcloud

1. gcloud compute backend-services create コマンドを使用してバックエンド サービスを定義します。

   gcloud compute backend-services create gil7-backend-service \
     --load-balancing-scheme=INTERNAL_MANAGED \
     --protocol=HTTP \
     --global
   

2. gcloud compute backend-services add-backend コマンドを使用して、バックエンド サービスにバックエンドを追加します。

   gcloud compute backend-services add-backend gil7-backend-service \
     --network-endpoint-group=gl7ilb-serverless-neg-a \
     --network-endpoint-group-region=REGION_A \
     --global
   

   gcloud compute backend-services add-backend gil7-backend-service \
     --network-endpoint-group=gl7ilb-serverless-neg-b \
     --network-endpoint-group-region=REGION_B \
     --global
   

3. gcloud compute url-maps create コマンドを使用して、URL マップを作成します。

   gcloud compute url-maps create gil7-map \
     --default-service=gil7-backend-service \
     --global
   

4. ターゲット プロキシを作成します。

   HTTP の場合:

   gcloud compute target-http-proxies create コマンドを使用して、ターゲット プロキシを作成します。

   gcloud compute target-http-proxies create gil7-http-proxy \
     --url-map=gil7-map \
     --global
   

   HTTPS の場合:

   Google マネージド証明書を作成するには、次のドキュメントをご覧ください。

   • Certificate Authority Service インスタンスによって発行された Google マネージド証明書を作成する
   • DNS 認証を使用して Google マネージド証明書をデプロイする

   Google マネージド証明書を作成したら、証明書をターゲット プロキシに直接関連付けます。証明書マップは、クロスリージョン内部アプリケーション ロードバランサでサポートされていません。

   セルフマネージド証明書を作成するには、次のドキュメントをご覧ください。

   • 秘密鍵と証明書を作成する

   ファイルパスを変数名に割り当てます。

   export LB_CERT=PATH_TO_PEM_FORMATTED_FILE
   

   export LB_PRIVATE_KEY=PATH_TO_LB_PRIVATE_KEY_FILE
   

   gcloud certificate-manager certificates create コマンドを使用して、すべてのリージョン SSL 証明書を作成します。

   gcloud certificate-manager certificates create gilb-certificate \
     --private-key-file=$LB_CERT \
     --certificate-file=$LB_PRIVATE_KEY \
     –-scope=all-regions
   

   SSL 証明書を使用して、gcloud compute target-https-proxies create コマンドでターゲット プロキシを作成します。

   gcloud compute target-https-proxies create gil7-https-proxy \
     --url-map=gil7-map \
     --certificate-manager-certificates=gilb-certificate
   

5. 2 つの転送ルールを作成します。1 つのルールでは、REGION_B の VIP 10.1.2.99 を使用します。もう 1 つのルールでは、REGION_A の VIP 10.1.3.99 を使用します。

   カスタム ネットワークでは、転送ルールでサブネットを参照する必要があります。これは、プロキシ サブネットではなく、仮想マシン（VM）インスタンスのサブネットです。

   HTTP の場合:

   適切なフラグを設定して gcloud compute forwarding-rules create コマンドを実行します。

   gcloud compute forwarding-rules create gil7-forwarding-rule-a \
     --load-balancing-scheme=INTERNAL_MANAGED \
     --network=NETWORK \
     --subnet=SUBNET_B \
     --subnet-region=REGION_B \
     --address=10.1.3.99 \
     --ports=80 \
     --target-http-proxy=gil7-http-proxy \
     --global
   

   gcloud compute forwarding-rules create gil7-forwarding-rule-b \
     --load-balancing-scheme=INTERNAL_MANAGED \
     --network=NETWORK \
     --subnet=SUBNET_A \
     --subnet-region=REGION_A \
     --address=10.1.2.99 \
     --ports=80 \
     --target-http-proxy=gil7-http-proxy \
     --global
   

   HTTPS の場合:

   適切なフラグを設定して gcloud compute forwarding-rules create コマンドを実行し、転送ルールを作成します。

   gcloud compute forwarding-rules create gil7-forwarding-rule-a \
     --load-balancing-scheme=INTERNAL_MANAGED \
     --network=NETWORK \
     --subnet=SUBNET_B \
     --address=10.1.3.99 \
     --ports=443 \
     --target-https-proxy=gil7-https-proxy \
     --global
   

   gcloud compute forwarding-rules create gil7-forwarding-rule-b \
     --load-balancing-scheme=INTERNAL_MANAGED \
     --network=NETWORK \
     --subnet=SUBNET_A \
     --address=10.1.2.99 \
     --ports=443 \
     --target-https-proxy=gil7-https-proxy \
     --global
   

API

backendServices.insert メソッドに POST リクエストを送り、グローバル バックエンド サービスを作成します。PROJECT_ID は実際のプロジェクト ID に置き換えます。

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices

{
"name": "gil7-backend-service",
"backends": [
  {
    "group": "projects/PROJECT_ID/zones/ZONE_A/instanceGroups/gl7ilb_serverless_negwest",
    "balancingMode": "UTILIZATION"
  },
  {
    "group": "projects/PROJECT_ID/zones/ZONE_B/instanceGroups/gl7ilb_serverless_negeast",
  }
],
"loadBalancingScheme": "INTERNAL_MANAGED"
}

urlMaps.insert メソッドに POST リクエストを送り、URL マップを作成します。PROJECT_ID は実際のプロジェクト ID に置き換えます。

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/urlMaps

{
"name": "l7-ilb-map",
"defaultService": "projects/PROJECT_ID/global/backendServices/gil7-backend-service"
}

HTTP の場合:

targetHttpProxies.insert メソッドに POST リクエストを送り、ターゲット HTTP プロキシを作成します。PROJECT_ID は、実際のプロジェクト ID に置き換えます。

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/targetHttpProxy

{
"name": "l7-ilb-proxy",
"urlMap": "projects/PROJECT_ID/global/urlMaps/l7-ilb-map"
}

globalforwardingRules.insert メソッドに POST リクエストを送り、転送ルールを作成します。PROJECT_ID は実際のプロジェクト ID に置き換えます。

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules

{
"name": "gil7-forwarding-rule-a",
"IPAddress": "10.1.2.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetHttpProxies/l7-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_A/subnetworks/SUBNET_A",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules

{
"name": "gil7-forwarding-rule-b",
"IPAddress": "10.1.3.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetHttpProxies/l7-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_B/subnetworks/SUBNET_B",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}

HTTPS の場合:

証明書と秘密鍵ファイルを読み取り、SSL 証明書を作成します。次の例では、Python でこの処理を行います。

targetHttpsProxies.insert メソッドに POST リクエストを送り、ターゲット HTTPS プロキシを作成します。PROJECT_ID は、実際のプロジェクト ID に置き換えます。

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/targetHttpsProxy

{
"name": "l7-ilb-proxy",
"urlMap": "projects/PROJECT_ID/global/urlMaps/l7-ilb-map",
"sslCertificates": /projects/PROJECT_ID/global/sslCertificates/SSL_CERT_NAME
}

globalForwardingRules.insert メソッドに POST リクエストを送り、転送ルールを作成します。PROJECT_ID は実際のプロジェクト ID に置き換えます。

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules

{
"name": "gil7-forwarding-rule-a",
"IPAddress": "10.1.2.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetHttpsProxies/l7-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_A/subnetworks/SUBNET_A",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules

{
"name": "gil7-forwarding-rule-b",
"IPAddress": "10.1.3.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetHttpsProxies/l7-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_B/subnetworks/SUBNET_B",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}

ロードバランサをテストする

ロード バランシング サービスが稼働中になったので、転送ルールへトラフィックを送信できます。また、各インスタンスに分散されるトラフィックを監視できます。

ファイアウォール ルールを構成する

この例では、テスト クライアント VM に fw-allow-ssh ファイアウォール ルールが必要です。fw-allow-ssh は、テスト クライアント VM に適用される上り（内向き）ルールであり、任意のアドレスから TCP ポート 22 への SSH 接続の受信を許可します。このルールには、送信元の IP アドレス範囲をより限定的に指定できます。たとえば、SSH セッションを開始するシステムの IP アドレス範囲を指定できます。この例では、ターゲットタグ allow-ssh を使用しています。

gcloud

1. ネットワーク タグ allow-ssh を使用して、VM との SSH 接続を許可する fw-allow-ssh ファイアウォール ルールを作成します。source-ranges を省略すると、Google Cloud は任意の送信元を対象とするものとしてルールを解釈します。

   gcloud compute firewall-rules create fw-allow-ssh \
       --network=NETWORK \
       --action=allow \
       --direction=ingress \
       --target-tags=allow-ssh \
       --rules=tcp:22
   

VM インスタンスを作成して接続をテストする

1. REGION_B リージョンと REGION_A リージョンにクライアント VM を作成します。

   gcloud compute instances create l7-ilb-client-us-west1-a \
       --image-family=debian-10 \
       --image-project=debian-cloud \
       --network=NETWORK \
       --subnet=SUBNET_A \
       --zone=ZONE_A \
       --tags=allow-ssh
   

   gcloud compute instances create l7-ilb-client-us-east1-b \
       --image-family=debian-10 \
       --image-project=debian-cloud \
       --network=NETWORK \
       --subnet=SUBNET_B \
       --zone=ZONE_B \
       --tags=allow-ssh
   

2. 各クライアント インスタンスに SSH を介して接続します。

   gcloud compute ssh l7-ilb-client-us-west1-a \
      --zone=ZONE_A
   

   gcloud compute ssh l7-ilb-client-us-east1-b \
      --zone=ZONE_B
   

3. IP アドレスがホスト名を提供していることを確認します。

   • クライアント VM が両方の IP アドレスに到達できることを確認します。コマンドが成功し、リクエストを処理したバックエンド VM の名前が返されます。

     curl 10.1.2.99
     

     curl 10.1.3.99
     

     HTTPS テストの場合、curl は次のもので置き換えます。

     curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.2.99:443
     

     curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.3.99:443
     

     -k フラグを指定すると、curl は証明書の検証をスキップします。

   • 省略可: 構成済みの DNS レコードを使用して IP アドレスを解決します。

     curl service.example.com
     

100 個のリクエストを実行してロードバランスされていることを確認する

HTTP の場合:

  {
    RESULTS=
    for i in {1..100}
    do
      RESULTS="$RESULTS:$(curl --silent 10.1.2.99)"
    done
    echo ""
    echo " Results of load-balancing to 10.1.2.99: "
    echo "***"
    echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
    echo
  }
  

  {
    RESULTS=
    for i in {1..100}
    do
      RESULTS="$RESULTS:$(curl --silent 10.1.3.99)"
    done
    echo ""
    echo " Results of load-balancing to 10.1.3.99: "
    echo "***"
    echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
    echo
  }
  

HTTPS の場合:

  {
    RESULTS=
    for i in {1..100}
    do
      RESULTS="$RESULTS:$(curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.2.99:443)"
    done
    echo ""
    echo " Results of load-balancing to 10.1.2.99: "
    echo "***"
    echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
    echo
  }
  

  {
    RESULTS=
    for i in {1..100}
    do
        RESULTS="$RESULTS:$(curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.3.99:443)"
    done
    echo ""
    echo " Results of load-balancing to 10.1.3.99: "
    echo "***"
    echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
    echo
  }
  

フェイルオーバーをテストする

1. REGION_B リージョンのバックエンドが異常な状態またはアクセス不能になった場合は、REGION_A リージョンのバックエンドへのフェイルオーバーを確認します。REGION_B からすべてのバックエンドを削除してシミュレーションを行います。

   gcloud compute backend-services remove-backend gil7-backend-service \
      --network-endpoint-group=gl7ilb-serverless-neg-b \
      --network-endpoint-group-zone=ZONE_B
   

2. SSH を使用して REGION_A のクライアント VM に接続します。

   gcloud compute ssh l7-ilb-client-us-east1-b \
      --zone=ZONE_B
   

3. REGION_B リージョンでロードバランスされた IP アドレスにリクエストを送信します。コマンド出力に、REGION_A のバックエンド VM からのレスポンスが表示されます。

   {
   RESULTS=
   for i in {1..100}
   do
     RESULTS="$RESULTS:$(curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.3.99:443)"
   done
   echo "***"
   echo "*** Results of load-balancing to 10.1.3.99: "
   echo "***"
   echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
   echo
   }
   

追加の構成オプション

このセクションでは、代替および追加の構成オプションを提供する構成例を示します。これらのタスクはすべて省略可です。また、任意の順序で行うことができます。

URL マスクを使用する

サーバーレス NEG を作成する際に、特定の Cloud Run サービスを選択するのではなく、URL マスクを使用して、同じドメインでリクエストを処理する複数のサービスを指定できます。URL マスクは、URL スキーマのテンプレートです。サーバーレス NEG はこのテンプレートを使用して、受信リクエストの URL からサービス名を抽出し、そのリクエストを適切なサービスにマッピングします。

URL マスクが特に役立つのは、サービスが Google Cloud からデプロイ済みサービスに割り当てられるデフォルトのアドレスではなく、カスタム ドメインにマッピングされている場合です。URL マスクを使用すると、アプリケーションでカスタム URL パターンを使用していても、1 つのルールで複数のサービスとバージョンをターゲットにできます。

サーバーレス NEG の概要: URL マスクをまだ読んでいない場合は、必ずお読みください。

URL マスクを作成する

ロードバランサの URL マスクを作成するには、まず、サービスの URL から取り掛かります。この例では、https://example.com/login で実行されているサーバーレス アプリのサンプルを使用します。この URL で、アプリの login サービスが提供されることになります。

1. URL から http または https を削除します。これで、example.com/login だけが残ります。
2. サービス名を URL マスクのプレースホルダに置き換えます。
   • Cloud Run: Cloud Run サービス名をプレースホルダ <service> に置き換えます。Cloud Run サービスにタグが関連付けられている場合は、そのタグ名をプレースホルダ <tag> に置き換えます。この例では、URL マスクが example.com/<service> になります。

3. 省略可: URL のパスの部分からサービス名を抽出できる場合は、ドメインを省略できます。URL マスクのパスの部分は、最初のスラッシュ（/）文字で区別されます。スラッシュ（/）が URL マスクに存在しない場合、マスクはホストのみを表していると見なされます。したがって、この例では URL マスクを /<service> に短縮できます。

   同様に、URL のホストの部分から <service> を抽出できる場合は、URL マスクからパスを完全に省略できます。

   最初のプレースホルダの前にあるホストまたはサブドメインの部分と、最後のプレースホルダの後にあるパスの部分も省略できます。このような場合、プレースホルダにその部分に必要な情報が取り込まれます。

以下に、これらのルールを説明する例をいくつか示します。

この表では、example.com という名前のカスタム ドメインがあり、すべての Cloud Run サービスがこのドメインにマッピングされていることを前提としています。

サービス、タグ名	Cloud Run のカスタム ドメイン URL	URL マスク
サービス: login	https://login-home.example.com/web	<service>-home.example.com
サービス: login	https://example.com/login/web	example.com/<service> or /<service>
サービス: login、タグ: test	https://test.login.example.com/web	<tag>.<service>.example.com
サービス: login、タグ: test	https://example.com/home/login/test	example.com/home/<service>/<tag> または /home/<service>/<tag>
サービス: login、タグ: test	https://test.example.com/home/login/web	<tag>.example.com/home/<service>

URL マスクを使用してサーバーレス NEG を作成する

コンソール

新しいロードバランサの場合、このドキュメントで説明したものと同じエンドツーエンドのプロセスを使用できます。バックエンド サービスを構成する場合は、特定のサービスを選択する代わりに、URL マスクを入力します。

既存のロードバランサがある場合は、バックエンド構成を編集し、サーバーレス NEG に特定のサービスの代わりに URL マスクを指定できます。

URL マスクベースのサーバーレス NEG を既存のバックエンド サービスに追加するには、次の操作を行います。

1. Google Cloud コンソールで、[ロード バランシング] ページに移動します。
   [ロード バランシング] に移動
2. 編集するバックエンド サービスがあるロードバランサの名前をクリックします。
3. [ロードバランサの詳細] ページで、[編集] をクリックします。
4. [Edit global external Application Load Balancer] ページで、[バックエンドの構成] をクリックします。
5. [バックエンドの構成] ページで、変更するバックエンド サービスの [編集] をクリックします。
6. [バックエンドを追加] をクリックします。
7. [サーバーレス ネットワーク エンドポイント グループの作成] を選択します。
1. [名前] に「helloworld-serverless-neg」と入力します。
2. [リージョン] に、ロードバランサのリージョンが表示されます。
3. [サーバーレス ネットワーク エンドポイント グループの種類] で、サポートされているネットワーク エンドポイント グループの種類は Cloud Run のみです。
1. [URL マスクを使用] を選択します。
2. URL マスクを入力します。URL マスクの作成方法については、URL マスクの作成をご覧ください。
3. [作成] をクリックします。
8. [新しいバックエンド] で、[完了] をクリックします。
9. [更新] をクリックします。

gcloud

example.com/<service> のサンプル URL マスクを使用してサーバーレス NEG を作成するには:

gcloud compute network-endpoint-groups create SERVERLESS_NEG_MASK_NAME \
    --region=REGION \
    --network-endpoint-type=serverless \
    --cloud-run-url-mask="example.com/<service>"

複数の内部転送ルールで同じ IP アドレスを使用する

複数の内部転送ルールで同じ内部 IP アドレスを共有するには、IP アドレスを予約して --purpose フラグを SHARED_LOADBALANCER_VIP に設定する必要があります。

gcloud

gcloud compute addresses create SHARED_IP_ADDRESS_NAME \
    --region=REGION \
    --subnet=SUBNET_NAME \
    --purpose=SHARED_LOADBALANCER_VIP

HTTP トラフィックを HTTPS にリダイレクトする必要がある場合は、共通の IP アドレスを持つ 2 つの転送ルールを作成できます。詳細については、内部ロードバランサに HTTP から HTTPS へのリダイレクトを設定するをご覧ください。

DNS ルーティング ポリシーを構成する

クライアントが複数のリージョンにある場合は、これらのリージョンの VIP を使用して、クロスリージョン内部アプリケーション ロードバランサにアクセスできるようにすることをおすすめします。このマルチリージョンを設定することで、レイテンシとネットワーク転送の費用を最小限に抑えることができます。さらに、リージョンの停止に対する耐障害性を確保するため、DNS ベースのグローバル ロード バランシング ソリューションを設定することもできます。詳細については、DNS ルーティング ポリシーとヘルスチェックを管理するをご覧ください。

gcloud

30 秒の TTL の DNS エントリを作成するには、gcloud dns record-sets create コマンドを使用します。

gcloud dns record-sets create DNS_ENTRY --ttl="30" \
  --type="A" --zone="service-zone" \
  --routing-policy-type="GEO" \
  --routing-policy-data="REGION1=gil7-forwarding-rule-a@global;REGION2=gil7-forwarding-rule-b@global" \
  --enable-health-checking

次のように置き換えます。

• DNS_ENTRY: レコードセットの DNS またはドメイン名

  例: service.example.com

• REGION1 と REGION2: ロードバランサを構成したリージョン

API

ResourceRecordSets.create メソッドに POST リクエストを送信して DNS レコードを作成します。PROJECT_ID は実際のプロジェクト ID に置き換えます。

POST https://www.googleapis.com/dns/v1/projects/PROJECT_ID/managedZones/SERVICE_ZONE/rrsets
{
  "name": "DNS_ENTRY",
  "type": "A",
  "ttl": 30,
  "routingPolicy": {
    "geo": {
      "items": [
        {
          "location": "REGION1",
          "healthCheckedTargets": {
            "internalLoadBalancers": [
              {
                "loadBalancerType": "globalL7ilb",
                "ipAddress": "gil7-forwarding-rule-a",
                "port": "80",
                "ipProtocol": "tcp",
                "networkUrl": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
                "project": "PROJECT_ID"
              }
            ]
          }
        },
        {
          "location": "REGION2",
          "healthCheckedTargets": {
            "internalLoadBalancers": [
              {
                "loadBalancerType": "globalL7ilb",
                "ipAddress": "gil7-forwarding-rule-b",
                "port": "80",
                "ipProtocol": "tcp",
                "networkUrl": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
                "project": "PROJECT_ID"
              }
            ]
          }
        }
      ]
    }
  }
}

外れ値検出を有効にする

グローバル バックエンド サービスで外れ値検出を有効にすると、正常でないサーバーレス NEG を識別し、正常でないサーバーレス NEG に送信されるリクエストの数を減らすことができます。

外れ値検出は、次のいずれかの方法を使用して、バックエンド サービスで有効になります。

• consecutiveErrors メソッド（outlierDetection.consecutiveErrors）。このメソッドでは 5xx シリーズの HTTP ステータス コードがエラーとみなされます
• consecutiveGatewayFailure メソッド（outlierDetection.consecutiveGatewayFailure）。このメソッドは、502、503、504 の HTTP ステータス コードのみエラーとみなされます。

既存のバックエンド サービスで外れ値検出を有効にするには、次の操作を行います。外れ値検出を有効にした後でも、一部のリクエストが正常でないサービスに送信され、5xx ステータス コードがクライアントに返される場合があることに注意してください。エラー率をさらに低減するには、外れ値検出パラメータ用により積極的な値を構成します。詳しくは、outlierDetection フィールドをご覧ください。

コンソール

1. Google Cloud コンソールの [ロード バランシング] ページに移動します。

   [ロード バランシング] に移動

2. バックエンド サービスを編集するロードバランサの名前をクリックします。

3. [ロードバランサの詳細] ページで、[編集] をクリックします。

4. [Edit cross-region internal Application Load Balancer] ページで、[バックエンドの構成] をクリックします。

5. [バックエンドの構成] ページで、変更するバックエンド サービスの [編集] をクリックします。

6. 下にスクロールして [高度な構成] セクションを開きます。

7. [外れ値検出] セクションで、[有効にする] チェックボックスをオンにします。

8. [編集] をクリックして外れ値検出を構成します。

   以下のオプションが次の値で構成されていることを確認します。

   プロパティ	値
   連続するエラー	5
   間隔	1000
   ベースの排出時間	30000
   最大排出率	50
   連続するエラーの適用	100

   この例では、外れ値検出分析が 1 秒ごとに実行されます。Envoy プロキシが連続して受信した HTTP 5xx ステータス コードの数が 5 以上の場合、バックエンド エンドポイントは Envoy プロキシのロード バランシング プールから 30 秒間除外されます。適用の割合が 100% に設定されている場合、バックエンド サービスでは、外れ値検出分析が実行されるたびに、これらの特定の Envoy プロキシのロード バランシング プールから正常でないエンドポイントが排出されます。除外条件が満たされると、ロード バランシング プールからバックエンド エンドポイントの最大 50% が排出されます。

9. [保存] をクリックします。

10. バックエンド サービスを更新するには、[更新] をクリックします。

11. ロードバランサを更新するには、[Edit cross-region internal Application Load Balancer] ページで [更新] をクリックします。

gcloud

1. バックエンド サービスを YAML ファイルにエクスポートします。

   gcloud compute backend-services export BACKEND_SERVICE_NAME \
     --destination=BACKEND_SERVICE_NAME.yaml --global
   

   BACKEND_SERVICE_NAME は、バックエンド サービスの名前に置き換えます。

2. 以下の YAML 構成でハイライト表示されているように、バックエンド サービスの YAML 構成を編集して、外れ値検出のフィールドを追加します。

   この例では、外れ値検出分析が 1 秒ごとに実行されます。Envoy プロキシが連続して受信した HTTP 5xx ステータス コードの数が 5 以上の場合、バックエンド エンドポイントは Envoy プロキシのロード バランシング プールから 30 秒間除外されます。適用の割合が 100% に設定されている場合、バックエンド サービスでは、外れ値検出分析が実行されるたびに、これらの特定の Envoy プロキシのロード バランシング プールから正常でないエンドポイントが排出されます。除外条件が満たされると、ロード バランシング プールからバックエンド エンドポイントの最大 50% が排出されます。

   name: BACKEND_SERVICE_NAME
   backends:
   - balancingMode: UTILIZATION
     capacityScaler: 1.0
     group: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/networkEndpointGroups/SERVERLESS_NEG_NAME
   - balancingMode: UTILIZATION
     capacityScaler: 1.0
     group: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/networkEndpointGroups/SERVERLESS_NEG_NAME_2
   outlierDetection:
     baseEjectionTime:
       nanos: 0
       seconds: 30
     consecutiveErrors: 5
     enforcingConsecutiveErrors: 100
     interval:
       nanos: 0
       seconds: 1
     maxEjectionPercent: 50
   port: 80
   selfLink: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_NAME
   sessionAffinity: NONE
   timeoutSec: 30
   ...
   

   次のように置き換えます。

   • BACKEND_SERVICE_NAME: バックエンド サービスの名前
   • PROJECT_ID: オブジェクトの ID
   • REGION_A と REGION_B: ロードバランサを構成したリージョン
   • SERVERLESS_NEG_NAME: 最初のサーバーレス NEG の名前
   • SERVERLESS_NEG_NAME_2: 2 番目のサーバーレス NEG の名前

3. 最新の構成をインポートして、バックエンド サービスを更新します。

   gcloud compute backend-services import BACKEND_SERVICE_NAME \
     --source=BACKEND_SERVICE_NAME.yaml --global
   

   バックエンド サービスで外れ値検出が有効になりました。

サーバーレス NEG の削除

バックエンド サービスに接続しているネットワーク エンドポイント グループは削除できません。NEG を削除する前に、NEG がバックエンド サービスから接続解除されていることを確認してください。

コンソール

1. 削除するサーバーレス NEG がバックエンド サービスによって使用されていないことを確認するには、[ロード バランシングのコンポーネント] ページの [バックエンド サービス] タブに移動します。
   [バックエンド サービス] に移動
2. サーバーレス NEG が使用中の場合は、次の操作を行います。
1. サーバーレス NEG を使用しているバックエンド サービスの名前をクリックします。
2. [編集] をクリックします。
3. [バックエンド] のリストで をクリックし、バックエンド サービスからサーバーレス NEG バックエンドを削除します。
4. [保存] をクリックします。
3. Google Cloud コンソールの [ネットワーク エンドポイント グループ] ページに移動します。
   [ネットワーク エンドポイント グループ] に移動
4. 削除するサーバーレス NEG のチェックボックスをオンにします。
5. [削除] をクリックします。
6. もう一度 [削除] をクリックして確定します。

gcloud

バックエンド サービスからサーバーレス NEG を削除するには、NEG が作成されたリージョンを指定する必要があります。

gcloud compute backend-services remove-backend BACKEND_SERVICE_NAME \
    --network-endpoint-group=SERVERLESS_NEG_NAME \
    --network-endpoint-group-region=REGION \
    --region=REGION

サーバーレス NEG を削除するには:

gcloud compute network-endpoint-groups delete SERVERLESS_NEG_NAME \
    --region=REGION

次のステップ

• Terraform を使用して Cloud Run で内部アプリケーション ロードバランサをデプロイする
• ロード バランシングの設定をクリーンアップする
• 共有 VPC のプロビジョニングを解除する
• 内部アプリケーション ロードバランサのロギングとモニタリング
• 内部アプリケーション ロードバランサに関する問題のトラブルシューティング