VM インスタンス グループのバックエンドを使用してリージョン内部アプリケーション ロードバランサを設定する

このドキュメントでは、Compute Engine VM で実行するサービス用にリージョン内部アプリケーション ロードバランサを構成する手順について説明します。

Google Kubernetes Engine（GKE）Pod で実行するサービスのロード バランシングを構成するには、スタンドアロン NEG を使用したコンテナ ネイティブのロード バランシングとリージョン内部アプリケーション ロードバランサとスタンドアロン NEG の接続をご覧ください。

Private Service Connect を使用して Google API とサービスにアクセスできるようにロード バランシングを構成するには、コンシューマー HTTP(S) サービス コントロールを使用した Private Service Connect の構成をご覧ください。

内部アプリケーション ロードバランサの設定は、次の 2 つの部分に分かれます。

• 前提となる作業を行う（必要なアカウントに適切な権限を付与し、Virtual Private Cloud（VPC）ネットワークを準備するなど）。
• ロードバランサのリソースを設定する。

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

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

権限

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

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

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

• アクセス制御
• IAM の条件

設定の概要

内部アプリケーション ロードバランサは、次の構成フローの概要で説明されているように構成できます。図の中で番号の付いている項目については、図の後で簡単に説明します。

内部アプリケーション ロードバランサのコンポーネント - 番号付き（クリックして拡大）

この例では、1 つのバックエンド サービスと 2 つのバックエンド グループがある us-west1 リージョンの VPC ネットワークに、内部アプリケーション ロードバランサを作成しています。

この図は次のことを示しています。

1. 2 つのサブネットがある VPC ネットワーク:

   1. サブネットの 1 つは、バックエンド（インスタンス グループ）と転送ルールに使用されます。プライマリ IP アドレスの範囲は 10.1.2.0/24 です。

   2. もう一つのサブネットは、us-west1 リージョンのプロキシ専用サブネットです。内部アプリケーション ロードバランサを使用する VPC ネットワークのリージョンごとにプロキシ専用サブネットを 1 つ作成する必要があります。リージョンのプロキシ専用サブネットは、リージョン内のすべての内部アプリケーション ロードバランサで共有されます。内部アプリケーション ロードバランサからサービスのバックエンドに送信されるパケットのソースアドレスは、プロキシ専用サブネットから割り当てられます。この例では、リージョンのプロキシ専用サブネットのプライマリ IP アドレスの範囲は 10.129.0.0/23 であり、これが推奨サブネット サイズです。詳細については、プロキシ専用サブネットをご覧ください。

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

3. バックエンドの Compute Engine VM インスタンス。

4. Compute Engine VM デプロイのマネージド インスタンス グループまたは非マネージド インスタンス グループ

   各ゾーンで、デプロイ要件に基づいてバックエンド グループタイプを組み合わせることができます。

   注: この設定では、VM インスタンス グループのバックエンドのみにリクエストをロードバランスする方法を説明します。GKE Pod にリクエストをロードバランスする方法については、HTTP(S) ロード バランシング用 GKE Ingress をご覧ください。

5. バックエンドの準備状況を報告するリージョン ヘルスチェック。

6. バックエンドの使用状況と健全性をモニタリングするリージョン バックエンド サービス。

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

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

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

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

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

   この例では、エフェメラル内部 IP アドレスの割り振りを許可せずに、リージョン内部アプリケーション ロードバランサの転送ルールに予約済み内部 IP アドレスを使用しています。転送ルールの IP アドレスは予約しておくことをおすすめします。

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

ロードバランサのバックエンド用とロードバランサのプロキシ用の 2 つのサブネットが存在する VPC ネットワークが必要です。内部アプリケーション ロードバランサはリージョンごとです。VPC ネットワーク内のトラフィックは、送信元がロードバランサと同じリージョンのサブネット内にある場合、ロードバランサに転送されます。

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

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

• バックエンドのサブネット。us-west1 リージョンの backend-subnet という名前のサブネット。プライマリ IP 範囲として 10.1.2.0/24 を使用します。

• プロキシのサブネット。us-west1 リージョンの proxy-only-subnet という名前のサブネット。プライマリ IP 範囲として 10.129.0.0/23 を使用します。

グローバル アクセスを示すために、この例では別のリージョンとサブネットに 2 つ目のテスト クライアント VM も作成します。

• リージョン: europe-west1
• サブネット: europe-subnet（プライマリ IP アドレス範囲は 10.3.4.0/24）

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

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

コンソール

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

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

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

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

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

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

   • 名前: backend-subnet
   • リージョン: us-west1
   • IP アドレス範囲: 10.1.2.0/24

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

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

8. グローバル アクセスを示すためにサブネットを作成します。[新しいサブネット] セクションに、次の情報を入力します。

   • 名前: europe-subnet
   • リージョン: europe-west1
   • IP アドレス範囲: 10.3.4.0/24

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

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

gcloud

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

   gcloud compute networks create lb-network --subnet-mode=custom
   

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

   gcloud compute networks subnets create backend-subnet \
       --network=lb-network \
       --range=10.1.2.0/24 \
       --region=us-west1
   

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

   gcloud compute networks subnets create europe-subnet \
       --network=lb-network \
       --range=10.3.4.0/24 \
       --region=europe-west1
   

API

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

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

{
 "routingConfig": {
   "routingMode": "REGIONAL"
 },
 "name": "lb-network",
 "autoCreateSubnetworks": false
}

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

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/subnetworks

{
 "name": "backend-subnet",
 "network": "projects/PROJECT_ID/global/networks/lb-network",
 "ipCidrRange": "10.1.2.0/24",
 "region": "projects/PROJECT_ID/regions/us-west1",
}

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

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/europe-west1/subnetworks

{
 "name": "europe-subnet",
 "network": "projects/PROJECT_ID/global/networks/lb-network",
 "ipCidrRange": "10.3.4.0/24",
 "region": "projects/PROJECT_ID/regions/europe-west1",
}

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

このプロキシ専用サブネットは、lb-network の us-west1 リージョン内のすべてのリージョン Envoy ベースのロードバランサ用です。

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

コンソール

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

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

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

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

2. VPC ネットワークの名前 lb-network をクリックします。

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

4. [名前] に「proxy-only-subnet」と入力します。

5. [リージョン] で、us-west1 を選択します。

6. [目的] を [リージョン マネージド プロキシ] に設定します。

7. [IP アドレス範囲] に「10.129.0.0/23」と入力します。

8. [追加] をクリックします。

gcloud

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

gcloud compute networks subnets create proxy-only-subnet \
  --purpose=REGIONAL_MANAGED_PROXY \
  --role=ACTIVE \
  --region=us-west1 \
  --network=lb-network \
  --range=10.129.0.0/23

API

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

POST https://compute.googleapis.com/compute/projects/PROJECT_ID/regions/us-west1/subnetworks

{
  "name": "proxy-only-subnet",
  "ipCidrRange": "10.129.0.0/23",
  "network": "projects/PROJECT_ID/global/networks/lb-network",
  "region": "projects/PROJECT_ID/regions/us-west1",
  "purpose": "REGIONAL_MANAGED_PROXY",
  "role": "ACTIVE"
}

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

この例では、次のファイアウォール ルールを使用します。

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

• fw-allow-health-check。 ロードバランスされたインスタンスに適用される上り（内向き）ルール。これによって、Google Cloud ヘルスチェック システム（130.211.0.0/22 と 35.191.0.0/16）からのすべての TCP トラフィックが許可されます。この例では、ターゲットタグ load-balanced-backend を使用して、ファイアウォール ルールが適用される VM を識別しています。

• fw-allow-proxies。ロードバランスされたインスタンスに適用される上り（内向き）ルール。内部 アプリケーション ロードバランサが管理するプロキシからポート 80、443、8080 への TCP トラフィックを許可します。この例では、ターゲットタグ load-balanced-backend を使用して、ファイアウォール ルールが適用される VM を識別します。

これらのファイアウォール ルールがない場合は、デフォルトの上り（内向き）拒否ルールによってバックエンド インスタンスへの受信トラフィックがブロックされます。

ターゲットタグは、バックエンド インスタンスを定義します。ターゲットタグがない場合、ファイアウォール ルールは VPC ネットワーク内のすべてのバックエンド インスタンスに適用されます。バックエンド VM を作成する場合は、マネージド インスタンス グループの作成の説明に沿って、指定したターゲットタグを忘れずに含めてください。

コンソール

1. Google Cloud コンソールで [ファイアウォール ポリシー] ページに移動します。

   [ファイアウォール ポリシー] に移動

2. [ファイアウォール ルールを作成] をクリックして、SSH 接続の受信を許可するルールを作成します。

   • 名前: fw-allow-ssh
   • ネットワーク: lb-network
   • トラフィックの方向: 上り（内向き）
   • 一致したときのアクション: 許可
   • ターゲット: 指定されたターゲットタグ
   • ターゲットタグ: allow-ssh
   • ソースフィルタ: IPv4 の範囲
   • 送信元 IPv4 範囲: 0.0.0.0/0
   • プロトコルとポート:
     • 指定されたプロトコルとポートを選択します。
     • [TCP] チェックボックスをオンにして、ポート番号に「22」と入力します。

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

4. [ファイアウォール ルールを作成] をもう一度クリックして、Google Cloud ヘルスチェックを許可するルールを作成します。

   • 名前: fw-allow-health-check
   • ネットワーク: lb-network
   • トラフィックの方向: 上り（内向き）
   • 一致したときのアクション: 許可
   • ターゲット: 指定されたターゲットタグ
   • ターゲットタグ: load-balanced-backend
   • ソースフィルタ: IPv4 の範囲
   • 送信元 IPv4 範囲: 130.211.0.0/22 と 35.191.0.0/16
   • プロトコルとポート:
     • 指定されたプロトコルとポートを選択します。
     • [TCP] チェックボックスをオンにして、ポート番号に「80」と入力します。
       このルールは、ヘルスチェックに使用されているプロトコルとポートのみに制限することをおすすめします。プロトコルとポートに tcp:80 を使用すると、Google Cloud はポート 80 で HTTP を使用して VM に接続できますが、ポート 443 では HTTPS を使用して VM に接続することはできません。

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

6. [ファイアウォール ルールを作成] をもう一度クリックをして、ロードバランサのプロキシ サーバーがバックエンドに接続できるようにするルールを作成します:

   • 名前: fw-allow-proxies
   • ネットワーク: lb-network
   • トラフィックの方向: 上り（内向き）
   • 一致したときのアクション: 許可
   • ターゲット: 指定されたターゲットタグ
   • ターゲットタグ: load-balanced-backend
   • ソースフィルタ: IPv4 の範囲
   • 送信元 IPv4 範囲: 10.129.0.0/23
   • プロトコルとポート:
     • 指定されたプロトコルとポートを選択します。
     • [TCP] チェックボックスをオンにして、ポート番号に「80, 443, 8080」と入力します。

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

gcloud

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

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

2. Google Cloud ヘルスチェックを許可する fw-allow-health-check ルールを作成します。この例では、ヘルスチェック プローブからのすべての TCP トラフィックを許可します。ただし、必要に応じてポートの範囲を狭く構成することもできます。

   gcloud compute firewall-rules create fw-allow-health-check \
       --network=lb-network \
       --action=allow \
       --direction=ingress \
       --source-ranges=130.211.0.0/22,35.191.0.0/16 \
       --target-tags=load-balanced-backend \
       --rules=tcp
   

3. 内部アプリケーション ロードバランサのプロキシがバックエンドに接続できるように fw-allow-proxies ルールを作成します。source-ranges を、プロキシ専用サブネットの割り振り範囲に設定します（例: 10.129.0.0/23）。

   gcloud compute firewall-rules create fw-allow-proxies \
     --network=lb-network \
     --action=allow \
     --direction=ingress \
     --source-ranges=source-range \
     --target-tags=load-balanced-backend \
     --rules=tcp:80,tcp:443,tcp:8080
   

API

firewalls.insert メソッドに POST リクエストを送り、fw-allow-ssh ファイアウォール ルールを作成します。PROJECT_ID は実際のプロジェクト ID に置き換えます。

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

{
 "name": "fw-allow-ssh",
 "network": "projects/PROJECT_ID/global/networks/lb-network",
 "sourceRanges": [
   "0.0.0.0/0"
 ],
 "targetTags": [
   "allow-ssh"
 ],
 "allowed": [
  {
    "IPProtocol": "tcp",
    "ports": [
      "22"
    ]
  }
 ],
"direction": "INGRESS"
}

firewalls.insert メソッドに POST リクエストを送り、fw-allow-health-check ファイアウォール ルールを作成します。PROJECT_ID は実際のプロジェクト ID に置き換えます。

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

{
 "name": "fw-allow-health-check",
 "network": "projects/PROJECT_ID/global/networks/lb-network",
 "sourceRanges": [
   "130.211.0.0/22",
   "35.191.0.0/16"
 ],
 "targetTags": [
   "load-balanced-backend"
 ],
 "allowed": [
   {
     "IPProtocol": "tcp"
   }
 ],
 "direction": "INGRESS"
}

firewalls.insert メソッドのプロキシ サブネット内で TCP トラフィックを許可する fw-allow-proxies ファイアウォール ルールを作成します。PROJECT_ID は、実際のプロジェクト ID に置き換えます。

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

{
 "name": "fw-allow-proxies",
 "network": "projects/PROJECT_ID/global/networks/lb-network",
 "sourceRanges": [
   "10.129.0.0/23"
 ],
 "targetTags": [
   "load-balanced-backend"
 ],
 "allowed": [
   {
     "IPProtocol": "tcp",
     "ports": [
       "80"
     ]
   },
 {
     "IPProtocol": "tcp",
     "ports": [
       "443"
     ]
   },
   {
     "IPProtocol": "tcp",
     "ports": [
       "8080"
     ]
   }
 ],
 "direction": "INGRESS"
}

ロードバランサの IP アドレスを予約する

デフォルトでは、各転送ルールに 1 つの IP アドレスが使用されます。共有 IP アドレスを予約すると、複数の転送ルールで同じ IP アドレスを使用できます。ただし、Private Service Connect を使用してロードバランサを公開する場合は、転送ルールに共有 IP アドレスを使用しないでください。

転送ルールの IP アドレスには、backend-subnet を使用します。プロキシ専用サブネットを使用すると、転送ルールの作成に失敗します。

コンソール

Google Cloud コンソールを使用してスタンドアロンの内部 IP アドレスを予約できます。

1. [VPC ネットワーク] ページに移動します。

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

2. 環境間のハイブリッド接続の構成に使用したネットワークをクリックします。
3. [静的内部 IP アドレス] をクリックして、[静的アドレスを予約] をクリックします。
4. [名前] に「l7-ilb-ip-address」と入力します。
5. [サブネット] で [backend-subnet] を選択します。
6. 予約する IP アドレスを指定する場合は、[静的 IP アドレス] の下で、[自分で選択] を選択し、[カスタム IP アドレス] に入力します。それ以外の場合、サブネットの IP アドレスは自動的に割り当てられます。
7. この IP アドレスを複数の転送ルールで使用する場合は、[目的] で [共有] を選択します。
8. [予約] をクリックして、プロセスを終了します。

gcloud

1. gcloud CLI を使用して compute addresses create コマンドを実行します。

   gcloud compute addresses create l7-ilb-ip-address \
     --region=us-west1 \
     --subnet=backend-subnet
   

   複数の転送ルールで同じ IP アドレスを使用する場合は、--purpose=SHARED_LOADBALANCER_VIP を指定します。

2. 割り振られた IP アドレスを表示するには、compute addresses describe コマンドを使用します。

   gcloud compute addresses describe l7-ilb-ip-address \
     --region=us-west1
   

マネージド VM インスタンス グループのバックエンドを作成する

このセクションでは、インスタンス グループ テンプレートとマネージド インスタンス グループの作成方法について説明します。このマネージド インスタンス グループには、サンプルのリージョン内部アプリケーション ロードバランサのバックエンド サーバーを実行する VM インスタンスが用意されています。インスタンス グループに HTTP サービスを定義し、ポート名を適切なポートにマッピングできます。ロードバランサのバックエンド サービスは、名前付きポートにトラフィックを転送します。クライアントからのトラフィックは、バックエンド サーバーにロードバランスされます。わかりやすく説明するために、バックエンド サーバーはそれぞれのホスト名をコンテンツとして提供します。

コンソール

1. インスタンス テンプレートを作成します。Google Cloud Console で、[インスタンス テンプレート] ページに移動します。

   [インスタンス テンプレート] に移動

   1. [インスタンス テンプレートを作成] をクリックします。
   2. [名前] に「l7-ilb-backend-template」と入力します。
   3. [ブートディスク] が Debian GNU/Linux 12 (bookworm) などの Debian イメージに設定されていることを確認します。以降の手順では、apt-get などの Debian でのみ使用できるコマンドを使用します。
   4. [詳細オプション] をクリックします。
   5. [ネットワーキング] をクリックして次のフィールドを構成します。
      1. [ネットワーク タグ] に「allow-ssh」と「load-balanced-backend」を入力します。
      2. [ネットワーク インターフェース] で、次のように選択します。
         • ネットワーク: lb-network
         • サブネット: backend-subnet

   6. [管理] をクリックします。[起動スクリプト] フィールドに次のスクリプトを入力します。

      #! /bin/bash
      apt-get update
      apt-get install apache2 -y
      a2ensite default-ssl
      a2enmod ssl
      vm_hostname="$(curl -H "Metadata-Flavor:Google" \
      http://metadata.google.internal/computeMetadata/v1/instance/name)"
      echo "Page served from: $vm_hostname" | \
      tee /var/www/html/index.html
      systemctl restart apache2
      

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

2. マネージド インスタンス グループを作成します。Google Cloud コンソールで、[インスタンス グループ] ページに移動します。

   [インスタンス グループ] に移動

   1. [インスタンス グループを作成] をクリックします。
   2. [新しいマネージド インスタンス グループ（ステートレス）] を選択します。詳細については、ステートレス MIG とステートフル MIG をご覧ください。
   3. [名前] に「l7-ilb-backend-example」と入力します。
   4. [ロケーション] で [シングルゾーン] を選択します。
   5. [リージョン] で、us-west1 を選択します。
   6. [ゾーン] で、[us-west1-a] を選択します。
   7. [インスタンス テンプレート] で [l7-ilb-backend-template] を選択します。

   8. グループ内に作成するインスタンスの数を指定します。

      この例では、[自動スケーリング] で次のオプションを指定します。

      • [自動スケーリング モード] で [Off:do not autoscale] を選択します。
      • [インスタンスの最大数] に「2」と入力します。

      オプションとして、UI の [自動スケーリング] セクションで、インスタンスの CPU 使用率に基づいてインスタンスを自動的に追加または削除するようにインスタンス グループを構成できます。

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

gcloud

このガイドの gcloud の手順は、Cloud Shell または bash がインストールされた別の環境を使用していることを前提としています。

1. gcloud compute instance-templates create コマンドを使用して、HTTP サーバーで VM インスタンス テンプレートを作成します。

   gcloud compute instance-templates create l7-ilb-backend-template \
   --region=us-west1 \
   --network=lb-network \
   --subnet=backend-subnet \
   --tags=allow-ssh,load-balanced-backend \
   --image-family=debian-12 \
   --image-project=debian-cloud \
   --metadata=startup-script='#! /bin/bash
     apt-get update
     apt-get install apache2 -y
     a2ensite default-ssl
     a2enmod ssl
     vm_hostname="$(curl -H "Metadata-Flavor:Google" \
     http://metadata.google.internal/computeMetadata/v1/instance/name)"
     echo "Page served from: $vm_hostname" | \
     tee /var/www/html/index.html
     systemctl restart apache2'
   

2. gcloud compute instance-groups managed create コマンドを使用して、ゾーンにマネージド インスタンス グループを作成します。

   gcloud compute instance-groups managed create l7-ilb-backend-example \
       --zone=us-west1-a \
       --size=2 \
       --template=l7-ilb-backend-template
   

API

instanceTemplates.insert メソッドを使用してインスタンス テンプレートを作成します。PROJECT_ID は実際のプロジェクト ID に置き換えます。

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/instanceTemplates
{
  "name":"l7-ilb-backend-template",
  "properties":{
     "machineType":"e2-standard-2",
     "tags":{
       "items":[
         "allow-ssh",
         "load-balanced-backend"
       ]
     },
     "metadata":{
        "kind":"compute#metadata",
        "items":[
          {
            "key":"startup-script",
            "value":"#! /bin/bash\napt-get update\napt-get install
            apache2 -y\na2ensite default-ssl\na2enmod ssl\n
            vm_hostname=\"$(curl -H \"Metadata-Flavor:Google\"
            \\\nhttp://metadata.google.internal/computeMetadata/v1/instance/name)\"\n
            echo \"Page served from: $vm_hostname\" | \\\ntee
            /var/www/html/index.html\nsystemctl restart apache2"
          }
        ]
     },
     "networkInterfaces":[
       {
         "network":"projects/PROJECT_ID/global/networks/lb-network",
         "subnetwork":"regions/us-west1/subnetworks/backend-subnet",
         "accessConfigs":[
           {
             "type":"ONE_TO_ONE_NAT"
           }
         ]
       }
     ],
     "disks":[
       {
         "index":0,
         "boot":true,
         "initializeParams":{
           "sourceImage":"projects/debian-cloud/global/images/family/debian-12"
         },
         "autoDelete":true
       }
     ]
  }
}

instanceGroupManagers.insert メソッドを使用して、各ゾーンにマネージド インスタンス グループを作成します。PROJECT_ID は実際のプロジェクト ID に置き換えます。

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/{zone}/instanceGroupManagers
{
  "name": "l7-ilb-backend-example",
  "zone": "projects/PROJECT_ID/zones/us-west1-a",
  "instanceTemplate": "projects/PROJECT_ID/global/instanceTemplates/l7-ilb-backend-template",
  "baseInstanceName": "l7-ilb-backend-example",
  "targetSize": 2
}

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

この例では、次のリージョン内部アプリケーション ロードバランサ リソースの作成方法を示します。

• HTTP ヘルスチェック
• マネージド インスタンス グループをバックエンドとして使用するバックエンド サービス
• URL マップ
  • リージョンがターゲット HTTP(S) プロキシに定義されている場合は、必ずリージョン URL マップを参照してください。リージョン URL マップは、受信 URL のホストとパスに定義したルールに基づいて、リクエストをリージョン バックエンド サービスにルーティングします。リージョン URL マップを参照できるのは、同じリージョン内のリージョン ターゲット プロキシのルールのみです。
• SSL 証明書（HTTPS の場合）
• ターゲット プロキシ
• 転送ルール

プロキシの可用性

Google Cloud リージョンによっては、新しいロードバランサに対応するのに十分なプロキシ容量がない場合があります。その場合、ロードバランサの作成時に Google Cloud コンソールでプロキシの可用性に関する警告メッセージが表示されます。この問題を解決するには、次のいずれかを行います。

• ロードバランサに別のリージョンを選択します。これは、別のリージョンにバックエンドがある場合には現実的な選択肢となります。
• プロキシ専用サブネットがすでに割り当てられている VPC ネットワークを選択します。

• 容量の問題が解決するまで待ちます。

コンソール

構成を開始する

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

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

2. [ロードバランサを作成] をクリックします。
3. [ロードバランサの種類] で [アプリケーション ロードバランサ（HTTP / HTTPS）] を選択し、[次へ] をクリックします。
4. [インターネット接続または内部] で [内部] を選択し、[次へ] をクリックします。
5. [クロスリージョンまたはシングル リージョンのデプロイ] で [リージョン ワークロードに最適] を選択し、[次へ] をクリックします。
6. [構成] をクリックします。

基本構成

1. ロードバランサの名前に「l7-ilb-map」と入力します。
2. [リージョン] で、us-west1 を選択します。
3. [ネットワーク] で lb-network を選択します。

プロキシ専用サブネットを予約する

注: 準備段階の設定の説明に従ってプロキシ専用サブネットの予約を済ませている場合、[サブネットの予約] ボタンは表示されません。その場合は、このセクションをスキップして、バックエンド サービスの構成手順に進んでください。

プロキシ専用サブネットを予約します。

1. [サブネットの予約] をクリックします。
2. [名前] に「proxy-only-subnet」と入力します。
3. [IP アドレス範囲] に「10.129.0.0/23」と入力します。
4. [Add（追加）] をクリックします。

バックエンド サービスの構成

1. [バックエンドの設定] をクリックします。
2. [バックエンド サービスの作成または選択] メニューから [バックエンド サービスを作成] を選択します。
3. バックエンド サービスの名前を l7-ilb-backend-service に設定します。
4. [バックエンド タイプ] をインスタンス グループに設定します。
5. [新しいバックエンド] セクションで、次の操作を行います。
   1. [インスタンス グループ] を l7-ilb-backend-example に設定します。
   2. [ポート番号] を 80 に設定します。
   3. [分散モード] を [使用率] に設定します。
   4. [完了] をクリックします。
6. [ヘルスチェック] リストで、次のパラメータを指定して [ヘルスチェックを作成] をクリックします。
   1. 名前: l7-ilb-basic-check
   2. プロトコル: HTTP
   3. ポート: 80
   4. [保存] をクリックします。
7. [作成] をクリックします。

URL マップを構成する

1. [ホストとパスのルール] をクリックします。

2. [モード] で、[単純なホストとパスのルール] を選択します。

3. l7-ilb-backend-service が、ホストとパスが一致しなかった場合に使用される唯一のバックエンド サービスであることを確認します。

トラフィック管理の詳細については、トラフィック管理の設定をご覧ください。

フロントエンドを構成する

HTTP の場合:

1. [フロントエンドの構成] をクリックします。
2. 転送ルールの名前を l7-ilb-forwarding-rule に設定します。
3. [プロトコル] を HTTP に設定します。
4. [サブネットワーク] を backend-subnet に設定します。
5. [ポート] を 80 に設定します。
6. [IP アドレス] リストから [l7-ilb-ip-address] を選択します。
7. [完了] をクリックします。

HTTPS の場合:

1. [フロントエンドの構成] をクリックします。
2. 転送ルールの名前を l7-ilb-forwarding-rule に設定します。
3. [プロトコル] を HTTPS (includes HTTP/2) に設定します。
4. [サブネットワーク] を backend-subnet に設定します。
5. HTTPS トラフィックを許可するように、[ポート] が 443 に設定されていることを確認します。
6. [IP アドレス] リストから [l7-ilb-ip-address] を選択します。
7. [証明書] プルダウン リストをクリックします。
   1. プライマリ SSL 証明書として使用しようとしているセルフマネージド SSL 証明書リソースがすでにある場合は、リストから選択します。
   2. そうでない場合は、[新しい証明書を作成] を選択します。
      1. 証明書の名前を l7-ilb-cert に設定します。
      2. 該当するフィールドに PEM 形式のファイルをアップロードします。
         • 公開鍵証明書
         • 証明書チェーン
         • 秘密鍵
      3. [作成] をクリックします。
8. プライマリ SSL 証明書リソースに加えて証明書リソースを追加するには、次の手順に沿って操作します。
   1. [証明書を追加] をクリックします。
   2. [証明書] リストから証明書を選択するか、[新しい証明書の作成] をクリックし、上記の操作を行います。

9. [SSL ポリシー] リストから SSL ポリシーを選択します。必要に応じて、SSL ポリシーを作成します。手順は次のとおりです。

   1. [SSL ポリシー] リストで、[ポリシーを作成] を選択します。
   2. SSL ポリシーの名前を入力します。
   3. TLS の最小バージョンを選択します。デフォルト値は TLS 1.0 です。
   4. 事前構成された Google マネージド プロファイルのいずれかを選択するか、SSL 機能を個別に選択できるカスタム プロファイルを選択します。[有効な機能] と [無効な機能] が表示されます。
   5. [保存] をクリックします。

   SSL ポリシーを作成していない場合は、デフォルトの Google Cloud SSL ポリシーが適用されます。

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

構成を確認する

1. [確認と完了] をクリックします。
2. ロードバランサの構成を確認します。
3. 省略可: [同等のコード] をクリックして、ロードバランサの作成に使用する REST API リクエストを表示します。
4. [作成] をクリックします。

gcloud

1. gcloud compute health-checks create http コマンドを使用して HTTP ヘルスチェックを定義します。

   gcloud compute health-checks create http l7-ilb-basic-check \
      --region=us-west1 \
      --use-serving-port
   

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

   gcloud compute backend-services create l7-ilb-backend-service \
     --load-balancing-scheme=INTERNAL_MANAGED \
     --protocol=HTTP \
     --health-checks=l7-ilb-basic-check \
     --health-checks-region=us-west1 \
     --region=us-west1
   

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

   gcloud compute backend-services add-backend l7-ilb-backend-service \
     --balancing-mode=UTILIZATION \
     --instance-group=l7-ilb-backend-example \
     --instance-group-zone=us-west1-a \
     --region=us-west1
   

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

   gcloud compute url-maps create l7-ilb-map \
     --default-service=l7-ilb-backend-service \
     --region=us-west1
   

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

   HTTP の場合:

   内部 HTTP ロードバランサの場合は、gcloud compute target-http-proxies create コマンドを使用してターゲット プロキシを作成します。

   gcloud compute target-http-proxies create l7-ilb-proxy \
     --url-map=l7-ilb-map \
     --url-map-region=us-west1 \
     --region=us-west1
   

   HTTPS の場合:

   Compute Engine または Certificate Manager の証明書を作成できます。Certificate Manager を使用して証明書を作成するには、次のいずれかの方法を使用します。

   • リージョン セルフマネージド証明書。リージョン セルフマネージド証明書の作成と使用については、リージョン セルフマネージド証明書をデプロイするをご覧ください。証明書マップはサポートされていません。

   • リージョンの Google マネージド証明書。証明書マップはサポートされていません。

     Certificate Manager では、次のタイプのリージョン Google マネージド証明書がサポートされています。

     • プロジェクトごとの DNS 認証を使用するリージョン Google マネージド証明書。詳細については、リージョン Google マネージド証明書をデプロイするをご覧ください。
     • Certificate Authority Service を使用するリージョン Google マネージド（プライベート）証明書。詳細については、CA Service を使用してリージョン Google マネージド証明書をデプロイするをご覧ください。

   証明書を作成したら、証明書をターゲット プロキシに直接関連付けます。

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

   export LB_CERT=path to PEM-formatted file
   

   export LB_PRIVATE_KEY=path to PEM-formatted file
   

   gcloud compute ssl-certificates create コマンドを使用してリージョン SSL 証明書を作成します。

   gcloud compute ssl-certificates create l7-ilb-cert \
     --certificate=$LB_CERT \
     --private-key=$LB_PRIVATE_KEY \
     --region=us-west1
   

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

   gcloud compute target-https-proxies create l7-ilb-proxy \
     --url-map=l7-ilb-map \
     --region=us-west1 \
     --ssl-certificates=l7-ilb-cert
   

   • 転送ルールを作成します。

     カスタム ネットワークでは、転送ルールでサブネットを参照する必要があります。このサブネットは、VM サブネットでありプロキシ専用サブネットではありません。

     HTTP の場合:

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

     gcloud compute forwarding-rules create l7-ilb-forwarding-rule \
       --load-balancing-scheme=INTERNAL_MANAGED \
       --network=lb-network \
       --subnet=backend-subnet \
       --address=l7-ilb-ip-address \
       --ports=80 \
       --region=us-west1 \
       --target-http-proxy=l7-ilb-proxy \
       --target-http-proxy-region=us-west1
     

     HTTPS の場合:

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

     gcloud compute forwarding-rules create l7-ilb-forwarding-rule \
       --load-balancing-scheme=INTERNAL_MANAGED \
       --network=lb-network \
       --subnet=backend-subnet \
       --address=l7-ilb-ip-address \
       --ports=443 \
       --region=us-west1 \
       --target-https-proxy=l7-ilb-proxy \
       --target-https-proxy-region=us-west1
     

API

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

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/{region}/healthChecks

{
"name": "l7-ilb-basic-check",
"type": "HTTP",
"httpHealthCheck": {
  "portSpecification": "USE_SERVING_PORT"
}
}

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

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/backendServices

{
"name": "l7-ilb-backend-service",
"backends": [
  {
    "group": "projects/PROJECT_ID/zones/us-west1-a/instanceGroups/l7-ilb-backend-example",
    "balancingMode": "UTILIZATION"
  }
],
"healthChecks": [
  "projects/PROJECT_ID/regions/us-west1/healthChecks/l7-ilb-basic-check"
],
"loadBalancingScheme": "INTERNAL_MANAGED"
}

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

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/urlMaps

{
"name": "l7-ilb-map",
"defaultService": "projects/PROJECT_ID/regions/us-west1/backendServices/l7-ilb-backend-service"
}

HTTP の場合:

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

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/targetHttpProxy

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

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

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/forwardingRules

{
"name": "l7-ilb-forwarding-rule",
"IPAddress": "IP_ADDRESS",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/regions/us-west1/targetHttpProxies/l7-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/us-west1/subnetworks/backend-subnet",
"network": "projects/PROJECT_ID/global/networks/lb-network",
"networkTier": "PREMIUM"
}

HTTPS の場合:

Compute Engine または Certificate Manager の証明書を作成できます。Certificate Manager を使用して証明書を作成するには、次のいずれかの方法を使用します。

• リージョン セルフマネージド証明書。リージョン セルフマネージド証明書の作成と使用については、リージョン セルフマネージド証明書をデプロイするをご覧ください。証明書マップはサポートされていません。

• リージョンの Google マネージド証明書。証明書マップはサポートされていません。

  Certificate Manager では、次のタイプのリージョン Google マネージド証明書がサポートされています。

  • プロジェクトごとの DNS 認証を使用するリージョン Google マネージド証明書。詳細については、リージョン Google マネージド証明書をデプロイするをご覧ください。
  • Certificate Authority Service を使用するリージョン Google マネージド（プライベート）証明書。詳細については、CA Service を使用してリージョン Google マネージド証明書をデプロイするをご覧ください。

証明書を作成したら、証明書をターゲット プロキシに直接関連付けます。

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

from pathlib import Path
from pprint import pprint
from typing import Union

from googleapiclient import discovery


def create_regional_certificate(
    project_id: str,
    region: str,
    certificate_file: Union[str, Path],
    private_key_file: Union[str, Path],
    certificate_name: str,
    description: str = "Certificate created from a code sample.",
) -> dict:
    """
    Create a regional SSL self-signed certificate within your Google Cloud project.

    Args:
        project_id: project ID or project number of the Cloud project you want to use.
        region: name of the region you want to use.
        certificate_file: path to the file with the certificate you want to create in your project.
        private_key_file: path to the private key you used to sign the certificate with.
        certificate_name: name for the certificate once it's created in your project.
        description: description of the certificate.

        Returns:
        Dictionary with information about the new regional SSL self-signed certificate.
    """
    service = discovery.build("compute", "v1")

    # Read the cert into memory
    with open(certificate_file) as f:
        _temp_cert = f.read()

    # Read the private_key into memory
    with open(private_key_file) as f:
        _temp_key = f.read()

    # Now that the certificate and private key are in memory, you can create the
    # certificate resource
    ssl_certificate_body = {
        "name": certificate_name,
        "description": description,
        "certificate": _temp_cert,
        "privateKey": _temp_key,
    }
    request = service.regionSslCertificates().insert(
        project=project_id, region=region, body=ssl_certificate_body
    )
    response = request.execute()
    pprint(response)

    return response

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

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/regionTargetHttpsProxy

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

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

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/forwardingRules

{
"name": "l7-ilb-forwarding-rule",
"IPAddress": "IP_ADDRESS",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/regions/us-west1/targetHttpsProxies/l7-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/us-west1/subnetworks/backend-subnet",
"network": "projects/PROJECT_ID/global/networks/lb-network",
"networkTier": "PREMIUM",
}

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

ロードバランサをテストするには、クライアント VM を作成します。VM との SSH セッションを確立して、VM からロードバランサにトラフィックを送信します。

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

コンソール

1. Google Cloud コンソールの [VM インスタンス] ページに移動します。

   [VM インスタンス] に移動

2. [インスタンスを作成] をクリックします。

3. [名前] を l7-ilb-client-us-west1-a に設定します。

4. [ゾーン] を us-west1-a に設定します。

5. [詳細オプション] をクリックします。

6. [ネットワーキング] をクリックして次のフィールドを構成します。

   1. [ネットワーク タグ] に「allow-ssh」と入力します。
   2. [ネットワーク インターフェース] で、次のように選択します。
      1. ネットワーク: lb-network
      2. サブネット: backend-subnet

7. [Create（作成）] をクリックします。

gcloud

gcloud compute instances create l7-ilb-client-us-west1-a \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --network=lb-network \
    --subnet=backend-subnet \
    --zone=us-west1-a \
    --tags=allow-ssh

ロードバランサにトラフィックを送信する

作成したインスタンスにログインし、リージョン内部アプリケーション ロードバランサの転送ルールの IP アドレスを介してバックエンドの HTTP(S) サービスに到達可能であることと、バックエンド インスタンス間でトラフィックのロード バランシングが行われていることをテストします。

SSH を介して各クライアント インスタンスに接続する

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

ロードバランサの IP アドレスを取得する

割り振られた IP アドレスを表示するには、gcloud compute addresses describe コマンドを使用します。

gcloud compute addresses describe l7-ilb-ip-address \
    --region=us-west1

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

IP_ADDRESS は、ロードバランサの IP アドレスに置き換えます。

curl IP_ADDRESS

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

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

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

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

IP_ADDRESS は、ロードバランサの IP アドレスに置き換えます。

HTTP の場合:

{
  RESULTS=
  for i in {1..100}
  do
      RESULTS="$RESULTS:$(curl --silent IP_ADDRESS)"
  done
  echo "***"
  echo "*** Results of load-balancing: "
  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:IP_ADDRESS:443)"
  done
  echo "***"
  echo "*** Results of load-balancing: "
  echo "***"
  echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
  echo
}

追加の構成オプション

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

グローバル アクセスを有効にする

リージョン内部アプリケーション ロードバランサとリージョン内部プロキシ ネットワーク ロードバランサのグローバル アクセスを有効にして、すべてのリージョンのクライアントがアクセスできるようにします。サンプルのロードバランサのバックエンドは、引き続き 1 つのリージョン（us-west1）に配置する必要があります。

グローバル アクセスを有効にしたリージョン内部アプリケーション ロードバランサ（クリックして拡大）

既存のリージョン転送ルールを変更して、グローバル アクセスを有効にすることはできません。この目的のために新しい転送ルールを作成し、以前の転送ルールを削除する必要があります。また、グローバル アクセスを有効にして転送ルールを作成した後に、これを変更することはできません。グローバル アクセスを無効にするには、新しいリージョン アクセス転送ルールを作成し、以前のグローバル アクセス転送ルールを削除する必要があります。

グローバル アクセスを構成するには、次の変更を行います。

コンソール

ロードバランサの新しい転送ルールを作成します。

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

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

2. [名前] 列で、ロードバランサをクリックします。

3. [フロントエンドの構成] をクリックします。

4. [フロントエンド IP とポートの追加] をクリックします。

5. 新しい転送ルールの名前とサブネットの詳細を入力します。

6. [サブネットワーク] で [backend-subnet] を選択します。

7. [IP アドレス] では、既存の転送ルールと同じ IP アドレスを選択するか、新しい IP アドレスを予約するか、エフェメラル IP アドレスを使用することができます。複数の転送ルールで同じ IP アドレスを共有するには、IP アドレスの作成時に IP アドレス --purpose フラグを SHARED_LOADBALANCER_VIP に設定します。

8. [ポート番号] に「110」と入力します。

9. [グローバル アクセス] で [有効] を選択します。

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

11. [更新] をクリックします。

gcloud

1. --allow-global-access フラグを使用してロードバランサの新しい転送ルールを作成します。

   HTTP の場合:

   gcloud compute forwarding-rules create l7-ilb-forwarding-rule-global-access \
     --load-balancing-scheme=INTERNAL_MANAGED \
     --network=lb-network \
     --subnet=backend-subnet \
     --address=10.1.2.99 \
     --ports=80 \
     --region=us-west1 \
     --target-http-proxy=l7-ilb-proxy \
     --target-http-proxy-region=us-west1 \
     --allow-global-access
   

   HTTPS の場合:

   gcloud compute forwarding-rules create l7-ilb-forwarding-rule-global-access \
     --load-balancing-scheme=INTERNAL_MANAGED \
     --network=lb-network \
     --subnet=backend-subnet \
     --address=10.1.2.99 \
     --ports=443 \
     --region=us-west1 \
     --target-https-proxy=l7-ilb-proxy \
     --target-https-proxy-region=us-west1 \
     --allow-global-access
   

2. gcloud compute forwarding-rules describe コマンドを使用すると、転送ルールでグローバル アクセスが有効になっているかどうかを確認できます。次に例を示します。

   gcloud compute forwarding-rules describe l7-ilb-forwarding-rule-global-access \
     --region=us-west1 \
     --format="get(name,region,allowGlobalAccess)"
   

   グローバル アクセスが有効になっている場合、転送ルールの名前とリージョンの出力の後に True という単語が表示されます。

クライアント VM を作成してグローバル アクセスをテストする

コンソール

1. Google Cloud コンソールの [VM インスタンス] ページに移動します。

   [VM インスタンス] に移動

2. [インスタンスを作成] をクリックします。

3. [名前] を europe-client-vm に設定します。

4. [ゾーン] を europe-west1-b に設定します。

5. [詳細オプション] をクリックします。

6. [ネットワーキング] をクリックして次のフィールドを構成します。

   1. [ネットワーク タグ] に「allow-ssh」と入力します。
   2. [ネットワーク インターフェース] で、次のように選択します。
      • ネットワーク: lb-network
      • サブネット: europe-subnet

7. [Create（作成）] をクリックします。

gcloud

europe-west1-b ゾーンにクライアント VM を作成します。

gcloud compute instances create europe-client-vm \
    --zone=europe-west1-b \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --tags=allow-ssh \
    --subnet=europe-subnet

VM クライアントに接続して接続性をテストする

1. ssh を使用してクライアント インスタンスに接続します。

   gcloud compute ssh europe-client-vm \
       --zone=europe-west1-b
   

2. us-west1 リージョンの vm-client からと同じように、ロードバランサへの接続をテストします。

   curl http://10.1.2.99
   

セッション アフィニティを有効にする

これらの手順は、バックエンド サービスが生成された Cookie アフィニティ、ヘッダー フィールド アフィニティ、HTTP Cookie アフィニティを使用できるように、サンプルのリージョン内部アプリケーション ロードバランサまたはクロスリージョン内部アプリケーション ロードバランサのバックエンド サービスを更新する方法を示しています。

生成された Cookie アフィニティが有効な場合、ロードバランサは最初のリクエストで Cookie を発行します。同じ Cookie を持つ後続のリクエストは、ロードバランサによって同じバックエンド仮想マシン（VM）インスタンスまたはエンドポイントに送信されます。この例では、Cookie の名前は GCILB です。

ヘッダー フィールド アフィニティが有効になっている場合、ロードバランサは、--custom-request-header フラグで指定された HTTP ヘッダーの値に基づいて、ネットワーク エンドポイント グループ（NEG）のバックエンド VM またはエンドポイントにリクエストをルーティングします。ヘッダー フィールド アフィニティは、ロード バランシングの局所性ポリシーが RING_HASH または MAGLEV であり、バックエンド サービスのコンシステント ハッシュが HTTP ヘッダーの名前を指定している場合にのみ有効です。

HTTP Cookie アフィニティが有効になっている場合、ロードバランサは、HTTP_COOKIE フラグ（およびオプションの --affinity-cookie-ttl フラグ）で指定された HTTP Cookie に基づいて、NEG のバックエンド VM またはエンドポイントにリクエストをルーティングします。クライアントが HTTP リクエストで Cookie を提供しない場合、プロキシは Cookie を生成し、それを Set-Cookie ヘッダーでクライアントに返します。HTTP Cookie アフィニティは、ロード バランシングの局所性ポリシーが RING_HASH または MAGLEV であり、バックエンド サービスのコンシステント ハッシュが HTTP Cookie を指定している場合にのみ有効です。

コンソール

バックエンド サービスのためのセッション アフィニティを有効化または変更するには、次に示す手順を行ってください。

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

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

2. [バックエンド] をクリックします。
3. l7-ilb-backend-service（この例で作成したバックエンド サービスの名前）をクリックし、[編集] をクリックします。
4. [バックエンド サービスの詳細] ページで、[詳細構成] をクリックします。
5. [セッション アフィニティ] で、必要なセッション アフィニティのタイプを選択します。
6. [更新] をクリックします。

gcloud

バックエンド サービスを別のタイプのセッション アフィニティに更新するには、次の Google Cloud CLI コマンドを使用します。

    gcloud compute backend-services update l7-ilb-backend-service \
        --session-affinity=[GENERATED_COOKIE | HEADER_FIELD | HTTP_COOKIE | CLIENT_IP] \
        --region=us-west1
    

API

セッション アフィニティを設定するには、backendServices/patch メソッドに PATCH リクエストを行います。

    PATCH https://compute.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/regionBackendServices/l7-ilb-backend-service
    {
      "sessionAffinity": ["GENERATED_COOKIE" | "HEADER_FIELD" | "HTTP_COOKIE" | "CLIENT_IP" ]
    }
    

ロードバランサにトラフィックを送信できるクライアントを制限する

注: このセクションでは、ファイアウォール ルールを使用してリージョン内部アプリケーション ロードバランサへのクライアント アクセスを制限する方法について説明します。Google Cloud Armor を使用して、ロードバランサへのクライアント アクセスを制限することもできます。詳細については、Google Cloud Armor のドキュメントのセキュリティ ポリシーの概要をご覧ください。

これらのクライアントで下り（外向き）ファイアウォール ルールを構成することで、クライアントが内部アプリケーション ロードバランサ転送ルール VIP に接続できないように制限できます。サービス アカウントまたはタグに基づいて、これらのファイアウォール ルールを特定のクライアント VM に設定します。

ファイアウォール ルールを使用して、受信トラフィックを特定の内部アプリケーション ロードバランサ転送ルール VIP に制限することはできません。同じ VPC ネットワーク上で、転送ルール VIP と同じリージョンにあるクライアントは通常、転送ルール VIP にトラフィックを送信できます。

さらに、バックエンドへのすべてのリクエストは、プロキシ専用サブネットの範囲内の IP アドレスを使用するプロキシから送信されます。クライアントが使用する転送ルール VIP に基づいて、これらのバックエンドでの上り（内向き）トラフィックを許可または拒否するファイアウォール ルールを作成することはできません。

下り（外向き）ファイアウォール ルールを使用して、ロードバランサの転送ルール VIP へのトラフィックを制限する方法の例を次に示します。

コンソール

クライアント VM を特定するには、制限する特定の VM にタグを付けます。これらのタグは、ファイアウォール ルールをタグ付けされたクライアント VM に関連付けるために使用されます。次の手順で TARGET_TAG フィールドにタグを追加します。

これを行うには、単一のファイアウォール ルールまたは複数のルールを使用します。

単一の下り（外向き）ファイアウォール ルール

タグ付けされたクライアント VM からロードバランサの VIP へのすべての下り（外向き）トラフィックを拒否する 1 つの下りファイアウォール ルールを構成できます。

1. Google Cloud コンソールで [ファイアウォール ルール] ページに移動します。

   ファイアウォール ルールに移動

2. [ファイアウォール ルールを作成] をクリックして、タグ付けされたクライアント VM からロードバランサの VIP への下り（外向き）トラフィックを拒否するルールを作成します。

   • 名前: fr-deny-access
   • ネットワーク: lb-network
   • 優先度: 100
   • トラフィックの方向: 下り（外向き）
   • 一致したときのアクション: 拒否
   • ターゲット: 指定されたターゲットタグ
   • ターゲットタグ: TARGET_TAG
   • 送信先フィルタ: IP 範囲
   • 送信先 IP 範囲: 10.1.2.99
   • プロトコルとポート:
     • 指定されたプロトコルとポートを選択します。
     • [tcp] チェックボックスをオンにして、ポート番号に「80」と入力します。

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

複数の下り（外向き）ファイアウォール ルール

よりスケーラブルなアプローチでは 2 つのルールを設定します。デフォルトの優先度の低いルールは、すべてのクライアントによるロードバランサの VIP へのアクセスを制限します。2 番目の優先度の高いルールは、タグ付けされたクライアントのサブセットによるロードバランサの VIP へのアクセスを許可します。タグ付けされた VM のみが VIP にアクセスできます。

1. Google Cloud コンソールで [ファイアウォール ルール] ページに移動します。

   ファイアウォール ルールに移動

2. [ファイアウォール ルールを作成] をクリックして、デフォルトでアクセスを拒否する優先度の低いルールを作成します。

   • 名前: fr-deny-all-access-low-priority
   • ネットワーク: lb-network
   • 優先度: 200
   • トラフィックの方向: 下り（外向き）
   • 一致したときのアクション: 拒否
   • ターゲット: 指定されたターゲットタグ
   • ターゲットタグ: TARGET_TAG
   • 送信先フィルタ: IP 範囲
   • 送信先 IP 範囲: 10.1.2.99
   • プロトコルとポート:
     • 指定されたプロトコルとポートを選択します。
     • [TCP] チェックボックスをオンにして、ポート番号に「80」と入力します。

3. [Create（作成）] をクリックします。

4. [ファイアウォール ルールを作成] をクリックして、特定のタグ付けされたインスタンスからのトラフィックを許可する優先度の高いルールを作成します。

   • 名前: fr-allow-some-access-high-priority
   • ネットワーク: lb-network
   • 優先度: 100
   • トラフィックの方向: 下り（外向き）
   • 一致したときのアクション: 許可
   • ターゲット: 指定されたターゲットタグ
   • ターゲットタグ: TARGET_TAG
   • 送信先フィルタ: IP 範囲
   • 送信先 IP 範囲: 10.1.2.99
   • プロトコルとポート:
     • 指定されたプロトコルとポートを選択します。
     • [TCP] チェックボックスをオンにして、ポート番号に「80」と入力します。

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

gcloud

クライアント VM を特定するには、制限する特定の VM にタグを付けます。次に、これらの手順の TARGET_TAG フィールドにタグを追加します。

これを行うには、単一のファイアウォール ルールまたは複数のルールを使用します。

単一の下り（外向き）ファイアウォール ルール

タグ付けされたクライアント VM からロードバランサの VIP へのすべての下り（外向き）トラフィックを拒否する 1 つの下りファイアウォール ルールを構成できます。

gcloud compute firewall-rules create fr-deny-access \
  --network=lb-network \
  --action=deny \
  --direction=egress \
  --rules=tcp \
  --priority=100 \
  --destination-ranges=10.1.2.99 \
  --target-tags=TARGET_TAG

複数の下り（外向き）ファイアウォール ルール

よりスケーラブルなアプローチとして 2 つのルールを設定するという方法もあります。1 つのルールはデフォルトの優先度の低いルールで、すべてのクライアントに対してロードバランサの VIP へのアクセスを制限します。もう 1 つは優先度の高いルールで、タグ付きのクライアントのサブセットに対してロードバランサの VIP へのアクセスを許可します。タグ付けされた VM のみが VIP にアクセスできます。

1. 優先度の低いルールを作成します。

   gcloud compute firewall-rules create fr-deny-all-access-low-priority \
     --network=lb-network \
     --action=deny \
     --direction=egress \
     --rules=tcp \
     --priority=200 \
     --destination-ranges=10.1.2.99
   

2. 優先度の高いルールを作成します。

   gcloud compute firewall-rules create fr-allow-some-access-high-priority \
     --network=lb-network \
     --action=allow \
     --direction=egress \
     --rules=tcp \
     --priority=100 \
     --destination-ranges=10.1.2.99 \
     --target-tags=TARGET_TAG
   

タグの代わりにサービス アカウントを使用してアクセスを制御するには、ファイアウォール ルールの作成時に --target-tags フラグの代わりに --target-service-accounts オプションを使用します。

サブネットに基づく内部アプリケーション ロードバランサのバックエンドへのアクセス制限をスケーリングする

前のセクションで説明したように、転送ルールの数が増えるにつれ、個別のファイアウォール ルールの維持や、ロードバランスされた新しい IP アドレスの既存ルールへの追加が行いにくくなります。これを防ぐ 1 つの方法は、予約済みサブネットから転送ルールの IP アドレスを割り振ることです。タグ付けされたインスタンスまたはサービス アカウントからのトラフィックは、ファイアウォール ルールの宛先範囲として予約済みサブネットを使用することで、許可またはブロックできます。これにより、VIP ごとの下り（外向き）ファイアウォール ルールを維持しなくても、転送ルール VIP のグループへのアクセスを効果的に制御できます。

その他の必要なロードバランサ リソースをすべて個別に作成することを前提として、手順の概要は次のとおりです。

gcloud

1. 転送ルールに負荷分散された IP アドレスを割り振るために使用するリージョン サブネットを作成します。

   gcloud compute networks subnets create l7-ilb-restricted-subnet \
     --network=lb-network \
     --region=us-west1 \
     --range=10.127.0.0/24
   

2. サブネットからアドレスを取得する転送ルールを作成します。次の例では、前の手順で作成したサブネットのアドレス 10.127.0.1 を使用します。

   gcloud compute forwarding-rules create l7-ilb-forwarding-rule-restricted \
     --load-balancing-scheme=INTERNAL_MANAGED \
     --network=lb-network \
     --subnet=l7-ilb-restricted-subnet \
     --address=10.127.0.1 \
     --ports=80 \
     --region=us-west1 \
     --target-http-proxy=l7-ilb-proxy \
     --target-http-proxy-region=us-west1
   

3. 転送ルールのサブネット（l7-ilb-restricted-subnet）内の IP アドレス範囲を宛先とするトラフィックを制限するファイアウォール ルールを作成します。

   gcloud compute firewall-rules create restrict-traffic-to-subnet \
     --network=lb-network \
     --action=deny \
     --direction=egress \
     --rules=tcp:80 \
     --priority=100 \
     --destination-ranges=10.127.0.0/24 \
     --target-tags=TARGET_TAG
   

バックエンドのサブセット化を構成する

プレビュー

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

バックエンドのサブセット化は、各プロキシ インスタンスにバックエンドのサブセットを割り当てることで、パフォーマンスとスケーラビリティを向上させます。バックエンド サービスに対して有効にすると、次のように、各プロキシ インスタンスが使用するバックエンドの数がバックエンドのサブネット化によって調整されます。

• ロードバランサに参加するプロキシ インスタンスの数が増えると、サブセットのサイズは減少します。

• ネットワーク内のバックエンドの合計数が単一のプロキシ インスタンスの容量を超えると、バックエンドのサブセット化が有効になっているサービスごとにサブセットのサイズが自動的に縮小されます。

注: REST API では、subsetting.subsetSize の設定は Cloud Service Mesh でのみ使用できます。この設定は、リージョン内部アプリケーション ロードバランサには使用できません。

この例では、リージョン内部アプリケーション ロードバランサリソースを作成し、バックエンドのサブセット化を有効にする方法を示しています。

1. 構成例を使用して、リージョン バックエンド サービス l7-ilb-backend-service を作成します。

2. バックエンドのサブセット化を有効にするには、--subsetting-policy フラグを CONSISTENT_HASH_SUBSETTING として指定します。ロード バランシング スキームを INTERNAL_MANAGED に設定します。

   gcloud

   バックエンドのサブセット化で l7-ilb-backend-service を更新するには、次の gcloud コマンドを使用します。

   gcloud beta compute backend-services update l7-ilb-backend-service \
      --region=us-west1 \
      --subsetting-policy=CONSISTENT_HASH_SUBSETTING
   

   API

   regionBackendServices/patch メソッドに PATCH リクエストを送信します。

   PATCH https://compute.googleapis.com/compute/beta/projects/PROJECT_ID/regions/us-west1/backendServices/l7-ilb-backend-service
   
   {
    "subsetting":
   {
    "policy": CONSISTENT_HASH_SUBSETTING
   }
   }
   

localityLbPolicy ポリシーを設定して、バックエンド ロード バランシングを調整することもできます。詳細については、トラフィック ポリシーをご覧ください。

複数の内部転送ルールで同じ 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 へのリダイレクトを設定するをご覧ください。

クライアント HTTP キープアライブ タイムアウトを更新する

前の手順で作成したロードバランサは、クライアント HTTP キープアライブ タイムアウトのデフォルト値で構成されています。

クライアントの HTTP キープアライブ タイムアウトを更新するには、次の操作を行います。

コンソール

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

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

2. 変更するロードバランサの名前をクリックします。
3. [編集] をクリックします。
4. [フロントエンドの構成] をクリックします。
5. [高度な機能] を開きます。[HTTP キープアライブ タイムアウト] にタイムアウト値を入力します。
6. [更新] をクリックします。
7. 変更を確認するには、[確認と完了] をクリックして、[更新] をクリックします。

gcloud

HTTP ロードバランサの場合は、gcloud compute target-http-proxies update コマンドを使用してターゲット HTTP プロキシを更新します。

      gcloud compute target-http-proxies update TARGET_HTTP_PROXY_NAME \
         --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \
         --region=REGION
      

HTTPS ロードバランサの場合は、gcloud compute target-https-proxies update コマンドを使用してターゲット HTTPS プロキシを更新します。

      gcloud compute target-https-proxies update TARGET_HTTP_PROXY_NAME \
         --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \
         --region REGION
      

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

• TARGET_HTTP_PROXY_NAME: ターゲット HTTP プロキシの名前。
• TARGET_HTTPS_PROXY_NAME: ターゲット HTTPS プロキシの名前。
• HTTP_KEEP_ALIVE_TIMEOUT_SEC: HTTP キープアライブ タイムアウト値（5～600 秒）。

次のステップ

• アプリケーション ロードバランサを IPv6 に変換する
• リージョン内部アプリケーション ロードバランサの概要
• Envoy ベースのロードバランサ向けプロキシ専用サブネット
• セルフマネージド SSL 証明書の使用
• ロードバランサの設定をクリーンアップする