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

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

始める前に

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

権限

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

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

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

設定の概要

次の図のようにロードバランサを構成できます。

クロスリージョン内部プロキシ ネットワーク ロードバランサの高可用性デプロイ。
クロスリージョン内部プロキシ ネットワーク ロードバランサの高可用性デプロイ（クリックして拡大）。

図に示すように、この例では、REGION_A と REGION_B リージョン内に 1 つのバックエンド サービスと 2 つのバックエンド マネージド インスタンス グループ（MIG）がある 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. 高可用性の設定では、REGION_A リージョンと REGION_B リージョンに Compute Engine VM デプロイ用のマネージド インスタンス グループ バックエンドがあります。一方のリージョンのバックエンドが停止した場合、トラフィックはもう一方のリージョンにフェイルオーバーされます。

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

  4. グローバル ターゲット TCP プロキシ。ユーザーからリクエストを受け取り、バックエンド サービスに転送します。

  5. グローバル転送ルール。ロードバランサのリージョン内部 IP アドレスを持ち、各受信リクエストをターゲット プロキシに転送できます。

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

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

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

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

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

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

  • バックエンドのサブネット。

    • REGION_A リージョンの SUBNET_A という名前のサブネットは、プライマリ IP 範囲として 10.1.2.0/24 を使用します。
    • REGION_B リージョンの SUBNET_B という名前のサブネットは、プライマリ 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. ネットワークの [名前] を指定します。

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

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

    • サブネットの [名前] を指定します。
    • [リージョン] では、[REGION_A] を選択します。
    • IP アドレス範囲には、「10.1.2.0/24」を入力します。

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

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

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

    • サブネットの [名前] を指定します。
    • [リージョン] では、[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

Terraform

VPC ネットワークを作成するには、google_compute_network リソースを使用します。

resource "google_compute_network" "default" {
  auto_create_subnetworks = false
  name                    = "lb-network-crs-reg"
  provider                = google-beta
}

lb-network-crs-reg ネットワークに VPC サブネットを作成するには、google_compute_subnetwork リソースを使用します。

resource "google_compute_subnetwork" "subnet_a" {
  provider      = google-beta
  ip_cidr_range = "10.1.2.0/24"
  name          = "lbsubnet-uswest1"
  network       = google_compute_network.default.id
  region        = "us-west1"
}
 
resource "google_compute_subnetwork" "subnet_b" {
  provider      = google-beta
  ip_cidr_range = "10.1.3.0/24"
  name          = "lbsubnet-useast1"
  network       = google_compute_network.default.id
  region        = "us-east1"
}

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/lb-network-crs-reg",
 "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 つだけの場合があります。

コンソール

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

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

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

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

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

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

  1. [サブネット] タブで [サブネットを追加] をクリックします。
  2. プロキシ専用サブネットの [名前] を指定します。
  3. [リージョン] には、REGION_B を選択します。
  4. [目的] リストで、[クロスリージョンのマネージド プロキシ] を選択します。
  5. [IP アドレス範囲] フィールドに「10.130.0.0/23」と入力します。
  6. [追加] をクリックします。

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

Terraform

lb-network-crs-reg ネットワークに VPC プロキシ専用サブネットを作成するには、google_compute_subnetwork リソースを使用します。

resource "google_compute_subnetwork" "proxy_subnet_a" {
  provider      = google-beta
  ip_cidr_range = "10.129.0.0/23"
  name          = "proxy-only-subnet1"
  network       = google_compute_network.default.id
  purpose       = "GLOBAL_MANAGED_PROXY"
  region        = "us-west1"
  role          = "ACTIVE"
  lifecycle {
    ignore_changes = [ipv6_access_type]
  }
}
 
resource "google_compute_subnetwork" "proxy_subnet_b" {
  provider      = google-beta
  ip_cidr_range = "10.130.0.0/23"
  name          = "proxy-only-subnet2"
  network       = google_compute_network.default.id
  purpose       = "GLOBAL_MANAGED_PROXY"
  region        = "us-east1"
  role          = "ACTIVE"
  lifecycle {
    ignore_changes = [ipv6_access_type]
  }
}

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"
    }

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

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

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

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

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

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

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

コンソール

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

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

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

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

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

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

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

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

gcloud

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

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

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

    gcloud compute firewall-rules create fw-healthcheck \
    --network=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-backends ルールを作成します。source-ranges をプロキシ専用サブネットの割り振り範囲に設定します（例: 10.129.0.0/23、10.130.0.0/23）。

    gcloud compute firewall-rules create fw-backends \
    --network=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-ilb-to-backends ファイアウォール ルールを作成します。PROJECT_ID は実際のプロジェクト ID に置き換えます。

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

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

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

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

{
 "name": "fw-healthcheck",
 "network": "projects/PROJECT_ID/global/networks/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-backends ファイアウォール ルールを作成します。PROJECT_ID は、実際のプロジェクト ID に置き換えます。

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

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

マネージド インスタンス グループを作成する

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

コンソール

  1. Google Cloud コンソールで [インスタンス テンプレート] ページに移動します。

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

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

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

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

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

    8. [インスタンス テンプレートを作成] をクリックします。

    9. [名前] に「gil4-backendwest1-template」と入力します。

    10. [ブートディスク] が Debian GNU/Linux 12 (bookworm) などの Debian イメージに設定されていることを確認します。以降の手順では、apt-get などの Debian でのみ使用できるコマンドを使用します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    10. [インスタンス グループを作成] をクリックします。

    11. [新しいマネージド インスタンス グループ（ステートレス）] を選択します。詳細については、ステートレス MIG とステートフル MIG をご覧ください。

    12. [名前] に「gl4-ilb-migb」と入力します。

    13. [ロケーション] で [シングルゾーン] を選択します。

    14. [リージョン] で REGION_B を選択します。

    15. [ゾーン] で、[ZONE_B] を選択します。

    16. [インスタンス テンプレート] で [gil4-backendeast1-template] を選択します。

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

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

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

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

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

gcloud

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

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

    gcloud compute instance-templates create gil4-backendwest1-template \
   --region=REGION_A \
   --network=NETWORK \
   --subnet=SUBNET_A \
   --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://169.254.169.254/computeMetadata/v1/instance/name)"
     echo "Page served from: $vm_hostname" | \
     tee /var/www/html/index.html
     systemctl restart apache2'

    gcloud compute instance-templates create gil4-backendeast1-template \
    --region=REGION_B \
    --network=NETWORK \
    --subnet=SUBNET_B \
    --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://169.254.169.254/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 gl4-ilb-miga \
    --zone=ZONE_A \
    --size=2 \
    --template=gil4-backendwest1-template

    gcloud compute instance-groups managed create gl4-ilb-migb \
    --zone=ZONE_B \
    --size=2 \
    --template=gil4-backendeast1-template

API

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

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

{
  "name":"gil4-backendwest1-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://169.254.169.254/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/NETWORK",
         "subnetwork":"regions/REGION_A/subnetworks/SUBNET_A",
         "accessConfigs":[
           {
             "type":"ONE_TO_ONE_NAT"
           }
         ]
       }
     ],
     "disks":[
       {
         "index":0,
         "boot":true,
         "initializeParams":{
           "sourceImage":"projects/debian-cloud/global/images/family/debian-12"
         },
         "autoDelete":true
       }
     ]
  }
}

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

{
  "name":"gil4-backendeast1-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://169.254.169.254/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/NETWORK",
         "subnetwork":"regions/REGION_B/subnetworks/SUBNET_B",
         "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": "gl4-ilb-miga",
  "zone": "projects/PROJECT_ID/zones/ZONE_A",
  "instanceTemplate": "projects/PROJECT_ID/global/instanceTemplates/gil4-backendwest1-template",
  "baseInstanceName": "gl4-ilb-miga",
  "targetSize": 2
}

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/{zone}/instanceGroupManagers

{
  "name": "gl4-ilb-migb",
  "zone": "projects/PROJECT_ID/zones/ZONE_A",
  "instanceTemplate": "projects/PROJECT_ID/global/instanceTemplates/gil4-backendwest1-template",
  "baseInstanceName": "gl4-ilb-migb",
  "targetSize": 2
}

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

この例では、次のクロスリージョン内部プロキシ ネットワーク ロードバランサ リソースを作成する方法を示します。

  • グローバル TCP ヘルスチェック。
  • バックエンドと同じ MIG を持つグローバル バックエンド サービス。
  • グローバル ターゲット プロキシ。
  • リージョン IP アドレスを持つ 2 つのグローバル転送ルール。転送ルールの IP アドレスには、SUBNET_A または SUBNET_B の IP アドレス範囲を使用します。プロキシ専用サブネットを使用すると、転送ルールの作成に失敗します。

プロキシの可用性

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

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

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

コンソール

構成を開始する

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

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

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

基本構成

  1. ロードバランサの [名前] を入力します。
  2. [ネットワーク] で [NETWORK] を選択します。

2 つの転送ルールを使用してフロントエンドを構成する

  1. [フロントエンドの構成] をクリックします。
    1. 転送ルールの [名前] を指定します。
    2. [サブネットワークのリージョン] リストで、[REGION_A] を選択します。

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

    3. [サブネットワーク] リストで、[SUBNET_A] を選択します。
    4. [IP アドレス] リストで、[IP アドレスを作成] をクリックします。[静的内部 IP アドレスの予約] ページが開きます。
      • 静的 IP アドレスの [名前] を指定します。
      • [静的 IP アドレス] リストで、[ユーザー指定] を選択します。
      • [カスタム IP アドレス] フィールドに、「10.1.2.99」と入力します。
      • [予約] を選択します。
  2. [完了] をクリックします。
  3. 2 番目の転送ルールを追加するには、[フロントエンドの IP とポートを追加] をクリックします。
    1. 転送ルールの [名前] を指定します。
    2. [サブネットワークのリージョン] リストで、[REGION_B] を選択します。

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

    3. [サブネットワーク] リストで、[SUBNET_B] を選択します。
    4. [IP アドレス] リストで、[IP アドレスを作成] をクリックします。[静的内部 IP アドレスの予約] ページが開きます。
      • 静的 IP アドレスの [名前] を指定します。
      • [静的 IP アドレス] リストで、[ユーザー指定] を選択します。
      • [カスタム IP アドレス] フィールドに、「10.1.3.99」と入力します。
      • [予約] を選択します。
  4. [完了] をクリックします。
バックエンド サービスを構成する
  1. [バックエンドの構成] をクリックします。
  2. [バックエンド サービスの作成または選択] リストで、[バックエンド サービスを作成] をクリックします。
  3. バックエンド サービスの [名前] を入力します。
  4. [プロトコル] で、[TCP] を選択します。
  5. [名前付きポート] に「http」と入力します。
  6. [バックエンド タイプ] リストで、[インスタンス グループ] を選択します。
  7. [新しいバックエンド] セクションで、次の操作を行います。
    • [インスタンス グループ] リストで、REGION_A の gl4-ilb-miga を選択します。
    • [ポート番号] を 80 に設定します。
    • [完了] をクリックします。
    • 別のバックエンドを追加するには、[バックエンドを追加] をクリックします。
    • [インスタンス グループ] リストで、REGION_B の gl4-ilb-migb を選択します。
    • [ポート番号] を 80 に設定します。
    • [完了] をクリックします。
  8. [ヘルスチェック] リストで [ヘルスチェックを作成] をクリックします。
    • [名前] フィールドに「global-http-health-check」と入力します。
    • [プロトコル] を HTTP に設定します。
    • [ポート] を 80 に設定します。
    • [保存] をクリックします。

構成を確認する

  1. [確認と完了] をクリックします。
  2. ロードバランサの構成を確認します。
  3. [作成] をクリックします。

gcloud

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

    gcloud compute health-checks create tcp global-health-check \
   --use-serving-port \
   --global

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

    gcloud compute backend-services create gl4-gilb-backend-service \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --protocol=TCP \
  --enable-logging \
  --logging-sample-rate=1.0 \
  --health-checks=global-health-check \
  --global-health-checks \
  --global

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

    gcloud compute backend-services add-backend gl4-gilb-backend-service \
  --balancing-mode=CONNECTION \
  --max-connections=50 \
  --instance-group=gl4-ilb-miga \
  --instance-group-zone=ZONE_A \
  --global

    gcloud compute backend-services add-backend gl4-gilb-backend-service \
  --balancing-mode=CONNECTION \
  --max-connections=50 \
  --instance-group=gl4-ilb-migb \
  --instance-group-zone=ZONE_B \
  --global

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

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

    gcloud compute target-tcp-proxies create gilb-tcp-proxy \
  --backend-service=gl4-gilb-backend-service \
  --global

  5. 2 つの転送ルールを作成します。REGION_B には VIP（10.1.2.99）の転送ルールを作成し、REGION_A には VIP（10.1.3.99）の転送ルールを作成します。詳細については、静的内部 IPv4 アドレスを予約するをご覧ください。

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

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

    gcloud compute forwarding-rules create gil4forwarding-rule-a \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=NETWORK \
  --subnet=SUBNET_A \
  --subnet-region=REGION_A \
  --address=10.1.2.99 \
  --ports=80 \
  --target-tcp-proxy=gilb-tcp-proxy \
  --global

    gcloud compute forwarding-rules create gil4forwarding-rule-b \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=NETWORK \
  --subnet=SUBNET_B \
  --subnet-region=REGION_B \
  --address=10.1.3.99 \
  --ports=80 \
  --target-tcp-proxy=gilb-tcp-proxy \
  --global

API

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

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

{
"name": "global-health-check",
"type": "TCP",
"httpHealthCheck": {
  "portSpecification": "USE_SERVING_PORT"
}
}

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

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

{
"name": "gl4-gilb-backend-service",
"backends": [
  {
    "group": "projects/PROJECT_ID/zones/ZONE_A/instanceGroups/gl4-ilb-miga",
    "balancingMode": "CONNECTION"
  },
  {
    "group": "projects/PROJECT_ID/zones/ZONE_B/instanceGroups/gl4-ilb-migb",
    "balancingMode": "CONNECTION"
  }
],
"healthChecks": [
  "projects/PROJECT_ID/regions/global/healthChecks/global-health-check"
],
"loadBalancingScheme": "INTERNAL_MANAGED"
}

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

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

{
"name": "l4-ilb-proxy",
}

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

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

{
"name": "gil4forwarding-rule-a",
"IPAddress": "10.1.2.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetTcpProxies/l4-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": "gil4forwarding-rule-b",
"IPAddress": "10.1.3.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetTcpProxies/l4-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_B/subnetworks/SUBNET_B",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}

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

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

{
"name": "gil4forwarding-rule-a",
"IPAddress": "10.1.2.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetTcpProxies/l4-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": "gil4forwarding-rule-b",
"IPAddress": "10.1.3.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetTcpProxies/l4-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 インスタンスを作成して接続をテストする

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

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

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

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

    gcloud compute ssh l4-ilb-client-a --zone=ZONE_A

    gcloud compute ssh l4-ilb-client-b --zone=ZONE_B

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

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

      curl 10.1.2.99

      curl 10.1.3.99

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

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

    gcloud compute backend-services remove-backend gl4-gilb-backend-service \
  --instance-group=gl4-ilb-migb \
  --instance-group-zone=ZONE_B \
  --global

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

    gcloud compute ssh l4-ilb-client-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
}

追加の構成オプション

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

クライアント接続情報を保持するための PROXY プロトコル

内部プロキシ ネットワーク ロードバランサは、クライアントからの TCP 接続を終端して、VM インスタンスへの新しい接続を作成します。デフォルトでは、元のクライアント IP とポート情報は保持されません。

元の接続情報を保持してインスタンスに送信するには、PROXY プロトコル（バージョン 1）を有効にします。このプロトコルは、送信元 IP アドレス、宛先 IP アドレス、ポート番号を含む追加ヘッダーをインスタンスへリクエストの構成部分として送信します。

内部プロキシ ネットワーク ロードバランサのバックエンド インスタンスが、PROXY プロトコル ヘッダーをサポートする HTTP または HTTPS サーバーを実行していることを確認します。HTTP または HTTPS サーバーが PROXY プロトコル ヘッダーをサポートするように構成されていない場合、バックエンド インスタンスは空のレスポンスを返します。たとえば、PROXY プロトコルは Apache HTTP Server ソフトウェアでは動作しません。Nginx など、別のウェブサーバー ソフトウェアを使用できます。

ユーザー トラフィックに PROXY プロトコルを設定する場合は、ヘルスチェックにも設定する必要があります。同じポートでヘルスチェックとコンテンツの処理を行う場合は、ヘルスチェックの --proxy-header がロードバランサの設定と一致するように設定します。

通常、PROXY プロトコルのヘッダーは、ユーザーが読み取り可能な次の形式の 1 行のテキストです。

PROXY TCP4 <client IP> <load balancing IP> <source port> <dest port>\r\n

次に PROXY プロトコルの例を示します。

PROXY TCP4 192.0.2.1 198.51.100.1 15221 110\r\n

上の例では、クライアント IP は 192.0.2.1、ロード バランシング IP は 198.51.100.1、クライアント ポートは 15221、宛先ポートは 110 です。

クライアント IP が不明な場合、ロードバランサは次の形式で PROXY プロトコル ヘッダーを生成します。

PROXY UNKNOWN\r\n

ターゲット TCP プロキシの PROXY プロトコル ヘッダーを更新する

このページのロードバランサの設定例では、内部プロキシ ネットワーク ロードバランサの作成中に PROXY プロトコル ヘッダーを有効にする方法について説明します。既存のターゲット TCP プロキシの PROXY プロトコル ヘッダーを変更するには、次の手順を使用します。

コンソール

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

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

  2. ロードバランサの [編集] をクリックします。

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

  4. [プロキシのプロトコル] フィールドの値を [オン] に変更します。

  5. [更新] をクリックして、変更を保存します。

gcloud

次のコマンドで、--proxy-header フィールドを編集し、必要に応じて NONE または PROXY_V1 に設定します。

gcloud compute target-ssl-proxies update int-tcp-target-proxy \
    --proxy-header=[NONE | PROXY_V1]

複数の内部転送ルールで同じ 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

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

構成例では、バックエンド サービスをセッション アフィニティなしで作成しています。

これらの手順は、バックエンド サービスがクライアント IP アフィニティまたは生成された Cookie アフィニティを使用するように、サンプルのロードバランサのバックエンド サービスを更新する方法を示しています。

クライアント IP アフィニティが有効になっている場合、ロードバランサは、クライアントの IP アドレスとロードバランサの IP アドレス（内部転送ルールの内部 IP アドレス）から作成されたハッシュに基づいて、特定のクライアントのリクエストを同じバックエンド VM に送信します。

コンソール

クライアント IP セッション アフィニティを有効にするには:

  1. Google Cloud コンソールの [ロード バランシング] ページに移動します。
    [ロード バランシング] に移動
  2. [バックエンド] をクリックします。
  3. この例で作成したバックエンド サービスの名前をクリックし、[編集] をクリックします。
  4. [バックエンド サービスの詳細] ページで、[詳細構成] をクリックします。
  5. [セッション アフィニティ] で、メニューから [クライアント IP] を選択します。
  6. [更新] をクリックします。

gcloud

クライアント IP セッション アフィニティを指定して、バックエンド サービスを更新するには、次の BACKEND_SERVICE コマンドを使用します。

gcloud compute backend-services update BACKEND_SERVICE \
    --global \
    --session-affinity=CLIENT_IP

コネクション ドレインを有効にする

バックエンド サービスでコネクション ドレインを有効にすると、トラフィックを処理しているインスタンスの停止、手動削除、オートスケーラーによる削除が発生した場合に、ユーザーに対する中断を最小限に抑えることができます。コネクション ドレインの詳細については、コネクション ドレインの有効化のドキュメントをご覧ください。

次のステップ