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

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

始める前に

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

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

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

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

権限

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

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

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

設定の概要

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

クロスリージョン内部アプリケーション ロードバランサの高可用性デプロイ。
クロスリージョン内部アプリケーション ロードバランサの高可用性デプロイ(クリックして拡大)

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

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

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

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

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

  2. 高可用性の設定では、REGION_A リージョンと REGION_B リージョンに Compute Engine VM デプロイ用のマネージド インスタンス グループ バックエンドがあります。一方のリージョンのバックエンドが停止した場合、トラフィックはもう一方のリージョンにフェイルオーバーされます。

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

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

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

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

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

    • IP アドレスは、バックエンド インスタンス グループと同じサブネットから取得できます(必須ではありません)。
    • IP アドレスは、--purpose フラグが GLOBAL_MANAGED_PROXY に設定されている予約済みプロキシ専用サブネットからは取得しないでください。
    • 複数の転送ルールで同じ内部 IP アドレスを使用する場合は、IP アドレス --purpose フラグを SHARED_LOADBALANCER_VIP に設定します。
  7. 省略可: クライアントに最も近いリージョンのロードバランサ VIP にクライアント トラフィックを転送するように、GEO タイプの DNS ルーティング ポリシーを構成します。

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

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/2235.191.0.0/16)からのすべての TCP トラフィックが許可されます。この例では、ターゲットタグ load-balanced-backend を使用して、ファイアウォール ルールが適用される VM を識別しています。

  • fw-backends。ロードバランスされたインスタンスに適用される上り(内向き)ルール。内部アプリケーション ロードバランサが管理するプロキシからポート 804438080 への 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/2235.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/2310.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/2310.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
    

Terraform

ファイアウォール ルールを作成するには、google_compute_firewall リソースを使用します。

resource "google_compute_firewall" "fw_healthcheck" {
  name          = "gl7-ilb-fw-allow-hc"
  provider      = google-beta
  direction     = "INGRESS"
  network       = google_compute_network.default.id
  source_ranges = ["130.211.0.0/22", "35.191.0.0/16", "35.235.240.0/20"]
  allow {
    protocol = "tcp"
  }
}
resource "google_compute_firewall" "fw_ilb_to_backends" {
  name          = "fw-ilb-to-fw"
  provider      = google-beta
  network       = google_compute_network.default.id
  source_ranges = ["0.0.0.0/0"]
  allow {
    protocol = "tcp"
    ports    = ["22", "80", "443", "8080"]
  }
}
resource "google_compute_firewall" "fw_backends" {
  name          = "gl7-ilb-fw-allow-ilb-to-backends"
  direction     = "INGRESS"
  network       = google_compute_network.default.id
  source_ranges = ["10.129.0.0/23", "10.130.0.0/23"]
  target_tags   = ["http-server"]
  allow {
    protocol = "tcp"
    ports    = ["80", "443", "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. [名前] に「gil7-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. [名前] に「gil7-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. [名前] に「gl7-ilb-mig-a」と入力します。
    4. [ロケーション] で [シングルゾーン] を選択します。
    5. [リージョン] で、REGION_A を選択します。
    6. [ゾーン] で、[ZONE_A] を選択します。
    7. [インスタンス テンプレート] で [gil7-backendwest1-template] を選択します。
    8. グループ内に作成するインスタンスの数を指定します。

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

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

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

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

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

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

    12. [名前] に「gl7-ilb-mig-b」と入力します。

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

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

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

    16. [インスタンス テンプレート] で [gil7-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 gil7-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 gil7-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 gl7-ilb-mig-a \
        --zone=ZONE_A \
        --size=2 \
        --template=gil7-backendwest1-template
    
    gcloud compute instance-groups managed create gl7-ilb-mig-b \
        --zone=ZONE_B \
        --size=2 \
        --template=gil7-backendeast1-template
    

Terraform

インスタンス テンプレートを作成するには、google_compute_instance_template リソースを使用します。

resource "google_compute_instance_template" "instance_template_a" {
  name         = "gil7-backendwest1-template"
  provider     = google-beta
  machine_type = "e2-small"
  region       = "us-west1"
  tags         = ["http-server"]

  network_interface {
    network    = google_compute_network.default.id
    subnetwork = google_compute_subnetwork.subnet_a.id
    access_config {
      # add external ip to fetch packages
    }
  }
  disk {
    source_image = "debian-cloud/debian-11"
    auto_delete  = true
    boot         = true
  }

  # install nginx and serve a simple web page
  metadata = {
    startup-script = <<-EOF1
      #! /bin/bash
      set -euo pipefail

      export DEBIAN_FRONTEND=noninteractive
      apt-get update
      apt-get install -y nginx-light jq

      NAME=$(curl -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/hostname")
      IP=$(curl -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/network-interfaces/0/ip")
      METADATA=$(curl -f -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/attributes/?recursive=True" | jq 'del(.["startup-script"])')

      cat <<EOF > /var/www/html/index.html
      <pre>
      Name: $NAME
      IP: $IP
      Metadata: $METADATA
      </pre>
      EOF
    EOF1
  }
  lifecycle {
    create_before_destroy = true
  }
}
resource "google_compute_instance_template" "instance_template_b" {
  name         = "gil7-backendeast1-template"
  provider     = google-beta
  machine_type = "e2-small"
  region       = "us-east1"
  tags         = ["http-server"]

  network_interface {
    network    = google_compute_network.default.id
    subnetwork = google_compute_subnetwork.subnet_b.id
    access_config {
      # add external ip to fetch packages
    }
  }
  disk {
    source_image = "debian-cloud/debian-11"
    auto_delete  = true
    boot         = true
  }

  # install nginx and serve a simple web page
  metadata = {
    startup-script = <<-EOF1
      #! /bin/bash
      set -euo pipefail

      export DEBIAN_FRONTEND=noninteractive
      apt-get update
      apt-get install -y nginx-light jq

      NAME=$(curl -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/hostname")
      IP=$(curl -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/network-interfaces/0/ip")
      METADATA=$(curl -f -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/attributes/?recursive=True" | jq 'del(.["startup-script"])')

      cat <<EOF > /var/www/html/index.html
      <pre>
      Name: $NAME
      IP: $IP
      Metadata: $METADATA
      </pre>
      EOF
    EOF1
  }
  lifecycle {
    create_before_destroy = true
  }
}

マネージド インスタンス グループを作成するには、google_compute_instance_group_manager リソースを使用します。

resource "google_compute_region_instance_group_manager" "mig_a" {
  name     = "gl7-ilb-miga"
  provider = google-beta
  region   = "us-west1"
  version {
    instance_template = google_compute_instance_template.instance_template_a.id
    name              = "primary"
  }
  base_instance_name = "vm"
  target_size        = 2
}
resource "google_compute_region_instance_group_manager" "mig_b" {
  name     = "gl7-ilb-migb"
  provider = google-beta
  region   = "us-east1"
  version {
    instance_template = google_compute_instance_template.instance_template_b.id
    name              = "primary"
  }
  base_instance_name = "vm"
  target_size        = 2
}

API

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

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

{
  "name":"gil7-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
       }
     ]
  }
}

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

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

{
  "name": "gl7-ilb-mig-a",
  "zone": "projects/PROJECT_ID/zones/ZONE_A",
  "instanceTemplate": "projects/PROJECT_ID/global/instanceTemplates/gil7-backendwest1-template",
  "baseInstanceName": "gl7-ilb-mig-b",
  "targetSize": 2
}
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/instanceTemplates

{
  "name":"gil7-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": "gl7-ilb-mig-b",
  "zone": "projects/PROJECT_ID/zones/ZONE_B",
  "instanceTemplate": "projects/PROJECT_ID/global/instanceTemplates/gil7-backendwest1-template",
  "baseInstanceName": "gl7-ilb-mig-b",
  "targetSize": 2
}

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

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

  • グローバル HTTP ヘルスチェック。
  • バックエンドとしてマネージド インスタンス グループを使用するグローバル バックエンド サービス。
  • URL マップ。ターゲット HTTP(S) プロキシのグローバル URL マップを必ず参照してください。グローバル URL マップは、受信 URL のホストとパスに定義したルールに基づいて、リクエストをグローバル バックエンド サービスに転送します。グローバル URL マップは、グローバル ターゲット プロキシ ルールから参照できます。
  • グローバル SSL 証明書(HTTPS の場合)。
  • グローバル ターゲット プロキシ。
  • リージョン IP アドレスを持つ 2 つのグローバル転送ルール。転送ルールの IP アドレスには、SUBNET_A または SUBNET_B の IP アドレス範囲を使用します。プロキシ専用サブネットを使用すると、転送ルールの作成に失敗します。

コンソール

構成を開始する

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

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

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

基本構成

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

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

HTTP の場合:

  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. [完了] をクリックします。

HTTPS の場合:

クライアントとロードバランサ間で HTTPS を使用する場合は、プロキシを構成するために 1 つ以上の SSL 証明書リソースが必要になります。all-regions Google マネージド証明書を作成するには、次のドキュメントをご覧ください。

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

all-regions セルフマネージド証明書を作成するには、リージョンのセルフマネージド証明書をデプロイするをご覧ください。

  1. [フロントエンドの構成] をクリックします。
    1. 転送ルールの [名前] を指定します。
    2. [プロトコル] フィールドで HTTPS (includes HTTP/2) を選択します。
    3. [ポート] が 443 に設定されていることを確認します。
    4. [サブネットワークのリージョン] リストで、[REGION_A] を選択します。

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

    5. [サブネットワーク] リストで、[SUBNET_A] を選択します。
    6. [IP アドレス] リストで、[IP アドレスを作成] をクリックします。[静的内部 IP アドレスの予約] ページが開きます。
      • 静的 IP アドレスの [名前] を指定します。
      • [静的 IP アドレス] リストで、[ユーザー指定] を選択します。
      • [カスタム IP アドレス] フィールドに、「10.1.3.99」と入力します。
      • [予約] を選択します。
    7. [証明書の追加] セクションで、証明書を選択します。
    8. 省略可: プライマリ SSL 証明書に加えて証明書を追加するには:
      1. [証明書を追加] をクリックします。
      2. リストから証明書を選択します。
    9. [SSL ポリシー] リストから SSL ポリシーを選択します。SSL ポリシーを作成していない場合は、デフォルトの Google Cloud SSL ポリシーが適用されます。
    10. [完了] をクリックします。

    2 番目のフロントエンド構成を追加します。

    1. フロントエンド構成の [名前] に、名前を入力します。
    2. [プロトコル] フィールドで HTTPS (includes HTTP/2) を選択します。
    3. [ポート] が 443 に設定されていることを確認します。
    4. [サブネットワークのリージョン] リストで、[REGION_B] を選択します。

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

    5. [サブネットワーク] リストで、[SUBNET_B] を選択します。
    6. [IP アドレス] リストで、[IP アドレスを作成] をクリックします。[静的内部 IP アドレスの予約] ページが開きます。
      • 静的 IP アドレスの [名前] を指定します。
      • [静的 IP アドレス] リストで、[ユーザー指定] を選択します。
      • [カスタム IP アドレス] フィールドに、「10.1.3.99」と入力します。
      • [予約] を選択します。
    7. [証明書の追加] セクションで、証明書を選択します。
    8. 省略可: プライマリ SSL 証明書に加えて証明書を追加するには:
      1. [証明書を追加] をクリックします。
      2. リストから証明書を選択します。
    9. [SSL ポリシー] リストから SSL ポリシーを選択します。SSL ポリシーを作成していない場合は、デフォルトの Google Cloud SSL ポリシーが適用されます。
    10. [完了] をクリックします。
    バックエンド サービスを構成する
    1. [バックエンドの構成] をクリックします。
    2. [バックエンド サービスの作成または選択] リストで、[バックエンド サービスを作成] をクリックします。
    3. [名前] に、バックエンド サービスの名前を入力します。
    4. [プロトコル] で [HTTP] を選択します。
    5. [名前付きポート] に「http」と入力します。
    6. [バックエンド タイプ] リストで、[インスタンス グループ] を選択します。
    7. [新しいバックエンド] セクションで、次の操作を行います。
      • [インスタンス グループ] リストで、REGION_Agl4-ilb-miga を選択します。
      • [ポート番号] を 80 に設定します。
      • [完了] をクリックします。
      • 別のバックエンドを追加するには、[バックエンドを追加] をクリックします。
      • [インスタンス グループ] リストで、REGION_Bgl4-ilb-migb を選択します。
      • [ポート番号] を 80 に設定します。
      • [完了] をクリックします。
    8. [ヘルスチェック] リストで [ヘルスチェックを作成] をクリックします。
      • [名前] フィールドに「global-http-health-check」と入力します。
      • [プロトコル] を HTTP に設定します。
      • [ポート] を 80 に設定します。
      • [保存] をクリックします。

    ルーティング ルールを構成する

    1. [ルーティング ルール] をクリックします。
    2. [モード] で、[単純なホストとパスのルール] を選択します。
    3. 一致しないホストとパスに対してバックエンド サービスが 1 つしかないことを確認します。

    構成を確認する

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

gcloud

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

    gcloud compute health-checks create http global-http-health-check \
       --use-serving-port \
       --global
    
  2. gcloud compute backend-services create コマンドを使用してバックエンド サービスを定義します。

    gcloud compute backend-services create BACKEND_SERVICE_NAME \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --protocol=HTTP \
      --enable-logging \
      --logging-sample-rate=1.0 \
      --health-checks=global-http-health-check \
      --global-health-checks \
      --global
    
  3. gcloud compute backend-services add-backend コマンドを使用して、バックエンド サービスにバックエンドを追加します。

    gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
      --balancing-mode=UTILIZATION \
      --instance-group=gl7-ilb-mig-a \
      --instance-group-zone=ZONE_A \
      --global
    
    gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
      --balancing-mode=UTILIZATION \
      --instance-group=gl7-ilb-mig-b \
      --instance-group-zone=ZONE_B \
      --global
    
  4. gcloud compute url-maps create コマンドを使用して、URL マップを作成します。

    gcloud compute url-maps create gl7-gilb-url-map \
      --default-service=BACKEND_SERVICE_NAME \
      --global
    
  5. ターゲット プロキシを作成します。

    HTTP の場合:

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

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

    HTTPS の場合:

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

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

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

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

    export LB_CERT=PATH_TO_PEM_FORMATTED_FILE
    
    export LB_PRIVATE_KEY=PATH_TO_LB_PRIVATE_KEY_FILE
    

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

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

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

    gcloud compute target-https-proxies create gil7-https-proxy \
      --url-map=gl7-gilb-url-map \
      --certificate-manager-certificates=gilb-certificate \
      --global
    
  6. 2 つの転送ルールを作成します。1 つは REGION_B リージョンの VIP(10.1.2.99)、もう 1 つは REGION_A リージョンの VIP(10.1.3.99)です。詳細については、静的内部 IPv4 アドレスを予約するをご覧ください。

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

    HTTP の場合:

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

    gcloud compute forwarding-rules create FWRULE_A \
      --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
    
    gcloud compute forwarding-rules create FWRULE_B \
      --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
    

    HTTPS の場合:

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

    gcloud compute forwarding-rules create FWRULE_A \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --network=NETWORK \
      --subnet=SUBNET_A \
      --subnet-region=REGION_A \
      --address=10.1.2.99 \
      --ports=443 \
      --target-https-proxy=gil7-https-proxy \
      --global
    
    gcloud compute forwarding-rules create FWRULE_B \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --network=NETWORK \
      --subnet=SUBNET_B \
      --subnet-region=REGION_B \
      --address=10.1.3.99 \
      --ports=443 \
      --target-https-proxy=gil7-https-proxy \
      --global
    

Terraform

ヘルスチェックを作成するには、google_compute_health_check リソースを使用します。

resource "google_compute_health_check" "default" {
  provider = google-beta
  name     = "global-http-health-check"
  http_health_check {
    port_specification = "USE_SERVING_PORT"
  }
}

バックエンド サービスを作成するには、google_compute_backend_service リソースを使用します。

resource "google_compute_backend_service" "default" {
  name                  = "gl7-gilb-backend-service"
  provider              = google-beta
  protocol              = "HTTP"
  load_balancing_scheme = "INTERNAL_MANAGED"
  timeout_sec           = 10
  health_checks         = [google_compute_health_check.default.id]
  backend {
    group           = google_compute_region_instance_group_manager.mig_a.instance_group
    balancing_mode  = "UTILIZATION"
    capacity_scaler = 1.0
  }
  backend {
    group           = google_compute_region_instance_group_manager.mig_b.instance_group
    balancing_mode  = "UTILIZATION"
    capacity_scaler = 1.0
  }
}

URL マップを作成するには、google_compute_url_map リソースを使用します。

resource "google_compute_url_map" "default" {
  name            = "gl7-gilb-url-map"
  provider        = google-beta
  default_service = google_compute_backend_service.default.id
}

ターゲット HTTP プロキシを作成するには、google_compute_target_http_proxy リソースを使用します。

resource "google_compute_target_http_proxy" "default" {
  name     = "gil7target-http-proxy"
  provider = google-beta
  url_map  = google_compute_url_map.default.id
}

ファイアウォール ルールを作成するには、google_compute_forwarding_rule リソースを使用します。

resource "google_compute_global_forwarding_rule" "fwd_rule_a" {
  provider              = google-beta
  depends_on            = [google_compute_subnetwork.proxy_subnet_a]
  ip_address            = "10.1.2.99"
  ip_protocol           = "TCP"
  load_balancing_scheme = "INTERNAL_MANAGED"
  name                  = "gil7forwarding-rule-a"
  network               = google_compute_network.default.id
  port_range            = "80"
  target                = google_compute_target_http_proxy.default.id
  subnetwork            = google_compute_subnetwork.subnet_a.id
}
resource "google_compute_global_forwarding_rule" "fwd_rule_b" {
  provider              = google-beta
  depends_on            = [google_compute_subnetwork.proxy_subnet_b]
  ip_address            = "10.1.3.99"
  ip_protocol           = "TCP"
  load_balancing_scheme = "INTERNAL_MANAGED"
  name                  = "gil7forwarding-rule-b"
  network               = google_compute_network.default.id
  port_range            = "80"
  target                = google_compute_target_http_proxy.default.id
  subnetwork            = google_compute_subnetwork.subnet_b.id
}

Terraform 構成を適用または削除する方法については、基本的な Terraform コマンドをご覧ください。

API

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

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

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

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

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

{
"name": "BACKEND_SERVICE_NAME",
"backends": [
  {
    "group": "projects/PROJECT_ID/zones/ZONE_A/instanceGroups/gl7-ilb-mig-a",
    "balancingMode": "UTILIZATION"
  },
  {
    "group": "projects/PROJECT_ID/zones/ZONE_B/instanceGroups/gl7-ilb-mig-b",
    "balancingMode": "UTILIZATION"
  }
],
"healthChecks": [
  "projects/PROJECT_ID/regions/global/healthChecks/global-http-health-check"
],
"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/BACKEND_SERVICE_NAME"
}

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

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

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

{
"name": "FWRULE_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": "gil7forwarding-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 でこの処理を行います。

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

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": "FWRULE_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": "FWRULE_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 インスタンスを作成して接続をテストする

  1. クライアント VM を作成します。

    gcloud compute instances create l7-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 l7-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 l7-ilb-client-a --zone=ZONE_A
    
    gcloud compute ssh l7-ilb-client-b --zone=ZONE_B
    
  3. IP アドレスがホスト名を提供していることを確認します。

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

      curl 10.1.2.99
      
      curl 10.1.3.99
      

      HTTPS テストの場合、curl は次のコマンドラインに置き換えます。

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

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

    • 省略可: 構成された DNS レコードを使用して、クライアント VM に最も近い IP アドレスを解決します。たとえば、DNS_NAMEservice.example.com です。

      curl DNS_NAME
      

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 BACKEND_SERVICE_NAME \
       --balancing-mode=UTILIZATION \
       --instance-group=gl7-ilb-mig-b \
       --instance-group-zone=ZONE_B
    
  2. SSH を使用して REGION_B のクライアント VM に接続します。

    gcloud compute ssh l7-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
    }
    

追加の構成オプション

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

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

これらの手順は、バックエンド サービスが生成された 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. gil7-backend-service」(この例で作成したバックエンド サービスの名前)をクリックして、[編集] をクリックします。
  4. [バックエンド サービスの詳細] ページで、[詳細構成] をクリックします。
  5. [セッション アフィニティ] で、必要なセッション アフィニティのタイプを選択します。
  6. [更新] をクリックします。

gcloud

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

    gcloud compute backend-services update gil7-backend-service \
        --session-affinity=[GENERATED_COOKIE | HEADER_FIELD | HTTP_COOKIE | CLIENT_IP] \
        --global
    

API

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

    PATCH https://compute.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/backendServices/gil7-backend-service
    {
    "sessionAffinity": ["GENERATED_COOKIE" | "HEADER_FIELD" | "HTTP_COOKIE" | "CLIENT_IP" ]
    }
    

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

これらのクライアントで下り(外向き)ファイアウォール ルールを構成することで、クライアントが内部アプリケーション ロードバランサ転送ルール 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 \
      --global \
      --target-http-proxy=gil7-http-proxy
    
  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
    

複数の内部転送ルールで同じ 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="REGION_A=gil7-forwarding-rule-a@global;REGION_B=gil7-forwarding-rule-b@global" \
  --enable-health-checking

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

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

    例: service.example.com

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

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": "REGION_A",
          "healthCheckedTargets": {
            "internalLoadBalancers": [
              {
                "loadBalancerType": "globalL7ilb",
                "ipAddress": "IP_ADDRESS",
                "port": "80",
                "ipProtocol": "tcp",
                "networkUrl": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
                "project": "PROJECT_ID"
              }
            ]
          }
        },
        {
          "location": "REGION_B",
          "healthCheckedTargets": {
            "internalLoadBalancers": [
              {
                "loadBalancerType": "globalL7ilb",
                "ipAddress": "IP_ADDRESS_B",
                "port": "80",
                "ipProtocol": "tcp",
                "networkUrl": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
                "project": "PROJECT_ID"
              }
            ]
          }
        }
      ]
    }
  }
}

クライアント 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 \
        --global
    

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

    gcloud compute target-https-proxies update TARGET_HTTPS_PROXY_NAME \
        --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \
        --global
    

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

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

外れ値検出を有効にする

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

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

  • consecutiveErrors メソッド(outlierDetection.consecutiveErrors)。このメソッドでは 5xx シリーズの HTTP ステータス コードがエラーとみなされます
  • consecutiveGatewayFailure メソッド(outlierDetection.consecutiveGatewayFailure)。このメソッドは、502503504 の 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. outlierDetection セクションの次の 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_AREGION_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
    

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

次のステップ