内部 TCP / UDP 負荷分散の設定

このガイドでは、サンプルを示しながら、Google Cloud の内部 TCP / UDP 負荷分散の基礎について解説します。このガイドに進む前に、次の内容を理解しておいてください。

権限

このガイドを使用する前に、インスタンスを作成し、プロジェクト内のネットワークを変更しておく必要があります。そのためにはプロジェクトの所有者または編集者であるか、または次の Compute Engine IAM の役割をすべて持っている必要があります。

タスク	必要な役割
ネットワーク、サブネット、負荷分散コンポーネントの作成	ネットワーク管理者
ファイアウォールルールの追加と削除	セキュリティ管理者
インスタンスの作成	インスタンス管理者

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

設定

このガイドでは、内部 TCP / UDP ロードバランサの構成とテストの方法を説明します。このセクションでは、以下の構成方法について説明します。

カスタムサブネットを持つ VPC ネットワークのサンプル
バックエンド VM への受信接続を許可するファイアウォールルール
4 つのバックエンド VM :
- ゾーン us-west1-a の非マネージドインスタンスグループ内の 2 つの VM
- ゾーン us-west1-c の非マネージドインスタンスグループ内の 2 つの VM
接続のテストに使用する 1 台のクライアント VM
次の内部 TCP / UDP ロードバランサコンポーネント:
- バックエンドサービスのヘルスチェック
- us-west1 リージョンの内部バックエンドサービス。2 つのゾーンインスタンスグループへの接続分散を管理します。
- ロードバランサのフロントエンドの内部転送ルールと内部 IP アドレス

この例のアーキテクチャは次のようになります。

ネットワーク、リージョン、サブネットの構成

少なくとも 1 つのサブネットを持つ VPC ネットワークが必要です。内部 TCP / UDP ロードバランサはリージョンで動作します。VPC ネットワーク内のトラフィックは、そのソースがロードバランサと同じリージョンのサブネットからのものである場合に、ロードバランサにルーティングされます。

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

ネットワーク: ネットワークは、lb-network という名前のカスタムモードの VPC ネットワークです。
リージョン: リージョンは、us-west1 です。
サブネット: サブネット lb-subnet は、10.1.2.0/24 の IP 範囲です。

サンプルのネットワークとサブネットを作成する手順は次のとおりです。

Console

Google Cloud Console で [VPC ネットワーク] ページに移動します。
[VPC ネットワーク] ページに移動
[VPC ネットワークを作成] をクリックします。
[名前] に「lb-network」を入力します。
[サブネット] セクションで次の設定を行います。
- [サブネット作成モード] を [カスタム] に設定します。
- [新しいサブネット] セクションに、次の情報を入力します。
  - 名前: lb-subnet
  - リージョン: us-west1
  - IP アドレス範囲: 10.1.2.0/24
  - [完了] をクリックします。
[作成] をクリックします。

gcloud

カスタム VPC ネットワークを作成します。

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

サブネットを us-west1 リージョン内の lb-network ネットワークに作成します。

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

api

networks.insert メソッドに POST リクエストを送信します。

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks
    {
      "routingConfig": {
        "routingMode": "REGIONAL"
      },
      "name": "lb-network",
      "autoCreateSubnetworks": false
    }

subnetworks.insert メソッドに POST リクエストを送信します。

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/subnetworks
    {
      "name": "lb-subnet",
      "network": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/lb-network",
      "ipCidrRange": "10.1.2.0/24",
      "privateIpGoogleAccess": false
    }

ファイアウォールルールの構成

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

fw-allow-lb-subnet: VPC ネットワーク内のすべてのターゲットに適用される上り（内向き）ルールで、10.1.2.0/24 の範囲の送信元からのトラフィックを許可します。このルールを使用すると、lb-subnet 内の送信元から負荷分散されているインスタンス（VM）への受信トラフィックが許可されます。
fw-allow-ssh: 負荷分散されたインスタンスに適用される内向きルール。任意のアドレスから TCP ポート 22 への SSH 接続が許可されます。このルールには、送信元 IP 範囲をより限定的に指定できます。たとえば、SSH セッションを開始するシステムの IP 範囲のみを許可するように指定できます。この例では、ターゲットタグ allow-ssh を使用して、適用する VM を識別させています。
fw-allow-health-check: 負荷分散されているインスタンスに適用される上り（内向き）ルール。Google Cloud ヘルスチェックシステム（130.211.0.0/22 と 35.191.0.0/16）からのトラフィックを許可します。この例では、ターゲットタグ allow-health-check を使用して、適用するインスタンスが識別されます。

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

Console

Google Cloud Console の [ファイアウォールルール] ページに移動します。
[ファイアウォールルール] ページに移動
[ファイアウォールルールを作成] をクリックして次の情報を入力し、サブネットトラフィックを許可するルールを作成します。
- 名前: fw-allow-lb-subnet
- ネットワーク: lb-network
- 優先度: 1000
- トラフィックの方向: 上り
- 一致したときのアクション: 許可
- ターゲット: ネットワーク内のすべてのインスタンス
- ソースフィルタ: IP ranges
- ソース IP の範囲: 10.1.2.0/24
- プロトコルとポート: すべて許可
[作成] をクリックします。
[ファイアウォールルールを作成] を再度クリックして、SSH 接続の受信を許可するルールを作成します。
- 名前: fw-allow-ssh
- ネットワーク: lb-network
- 優先度: 1000
- トラフィックの方向: 上り
- 一致したときのアクション: 許可
- ターゲット: 指定されたターゲットタグ
- ターゲットタグ: allow-ssh
- ソースフィルタ: IP ranges
- ソース IP の範囲: 0.0.0.0/0
- プロトコルとポート: 指定されたプロトコルとポートを選択してから、次のように入力します。tcp:22
[作成] をクリックします。
[ファイアウォールルールを作成] をもう一度クリックして、Google Cloud ヘルスチェックを許可するルールを作成します。
- 名前: fw-allow-health-check
- ネットワーク: lb-network
- 優先度: 1000
- トラフィックの方向: 上り
- 一致したときのアクション: 許可
- ターゲット: 指定されたターゲットタグ
- ターゲットタグ: allow-health-check
- ソースフィルタ: IP ranges
- 送信元 IP 範囲: 130.211.0.0/22 と 35.191.0.0/16
- プロトコルとポート: すべて許可
[作成] をクリックします。

gcloud

fw-allow-lb-subnet ファイアウォールルールを作成して、サブネットとの通信を許可します。

    gcloud compute firewall-rules create fw-allow-lb-subnet \
        --network=lb-network \
        --action=allow \
        --direction=ingress \
        --source-ranges=10.1.2.0/24 \
        --rules=tcp,udp,icmp

ネットワークタグ allow-ssh を使用して、VM との SSH 接続を許可する fw-allow-ssh ファイアウォールルールを作成します。source-ranges を省略すると、Google Cloud は任意の送信元としてルールを解釈します。
```
    gcloud compute firewall-rules create fw-allow-ssh \
        --network=lb-network \
        --action=allow \
        --direction=ingress \
        --target-tags=allow-ssh \
        --rules=tcp:22
    
```

fw-allow-health-check ルールを作成して Google Cloud ヘルスチェックを許可します。

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

api

firewalls.insertメソッドに POST リクエストを送信して、fw-allow-lb-subnet ファイアウォールルールを作成します。

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/firewalls
    {
      "name": "fw-allow-lb-subnet",
      "network": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/lb-network",
      "priority": 1000,
      "sourceRanges": [
        "10.1.2.0/24"
      ],
      "allowed": [
        {
          "IPProtocol": "tcp"
        },
        {
          "IPProtocol": "udp"
        },
        {
          "IPProtocol": "icmp"
        }
      ],
      "direction": "INGRESS",
      "logConfig": {
        "enable": false
      },
      "disabled": false
    }

firewalls.insertメソッドに POST リクエストを送信して、fw-allow-ssh ファイアウォールルールを作成します。

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/firewalls
    {
      "name": "fw-allow-ssh",
      "network": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/lb-network",
      "priority": 1000,
      "sourceRanges": [
        "0.0.0.0/0"
      ],
      "targetTags": [
        "allow-ssh"
      ],
      "allowed": [
       {
         "IPProtocol": "tcp",
         "ports": [
           "22"
         ]
       }
      ],
     "direction": "INGRESS",
     "logConfig": {
       "enable": false
     },
     "disabled": false
    }

firewalls.insertメソッドに POST リクエストを送信して、fw-allow-health-check ファイアウォールルールを作成します。

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/firewalls
    {
      "name": "fw-allow-health-check",
      "network": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/lb-network",
      "priority": 1000,
      "sourceRanges": [
        "130.211.0.0/22",
        "35.191.0.0/16"
      ],
      "targetTags": [
        "allow-health-check"
      ],
      "allowed": [
        {
          "IPProtocol": "tcp"
        },
        {
          "IPProtocol": "udp"
        },
        {
          "IPProtocol": "icmp"
        }
      ],
      "direction": "INGRESS",
      "logConfig": {
        "enable": false
      },
      "disabled": false
    }

バックエンド VM とインスタンスグループの作成

この例では、2 つのバックエンド（サーバー）VM を持つ 2 つの非マネージドインスタンスを使用しています。内部 TCP / UDP 負荷分散のリージョン特性を示すために、2 つのインスタンスグループが別々のゾーン（us-west1-a と us-west1-c）に配置されています。

インスタンスグループ ig-a には、次の 2 つの VM が含まれています。
- vm-a1
- vm-a2
インスタンスグループ ig-c には、次の 2 つの VM が含まれています。
- vm-c1
- vm-c2

4 つのバックエンド VM へのトラフィックがすべて負荷分散されます。4 つはそれぞれ TCP ポート 80 と 443 で Apache ウェブサーバーを実行します。lb-subnet の内部 IP アドレスと外部（公開）エフェメラル IP アドレスがそれぞれ割り当てられます。外部 IP アドレスは後で削除できます。

バックエンド VM がインターネットから Apache をダウンロードできる、および SSH 経由で接続しやすいという理由からこの例では使用していますが、バックエンド VM の外部 IP アドレスは必須ではありません。

デフォルトでは、Apache は任意の IP アドレスにバインドされます。内部 TCP / UDP ロードバランサは、宛先 IP を保持してパケットを配信します。バックエンド VM で実行中のサーバーソフトウェアが、ロードバランサの内部転送ルールの IP アドレスをリッスンしていることを確認してください。複数の内部転送ルールを構成している場合、ソフトウェアによってそれぞれに関連付けられた内部 IP アドレスがリッスンされます。内部 TCP / UDP ロードバランサによってバックエンド VM に配信されるパケットの宛先 IP アドレスは、転送ルールの内部 IP アドレスです。

これらのバックエンド VM では、説明を簡単にするため、Debian GNU/Linux 9 を実行します。

Console

バックエンド VM の作成

Google Cloud Console の [VM インスタンス] ページに移動します。
[VM インスタンス] ページに移動
次の手順を繰り返し、4 つの VM を作成します。次のような名前とゾーンの組み合わせを使用します。
- 名前: vm-a1、ゾーン: us-west1-a
- 名前: vm-a2、ゾーン: us-west1-a
- 名前: vm-c1、ゾーン: us-west1-c
- 名前: vm-c2、ゾーン: us-west1-c
[インスタンスを作成] をクリックします。
ステップ 2 に示したように [名前] を設定します。
[リージョン] には、us-west1 を選択し、手順 2 に示したゾーンを選択します。
[ブートディスク] セクションで、ブートディスクオプションに Debian オペレーティングシステムと 9 Stretch バージョンが選択されていることを確認します。必要に応じてイメージを変更するには、[選択] をクリックします。
[管理、セキュリティ、ディスク、ネットワーク、単一テナンシー] をクリックして、次のように変更します。
- [ネットワーク] をクリックして、ネットワークタグ allow-ssh と allow-health-check を追加します。
- [ネットワークインターフェース] にある編集ボタンをクリックして、次の変更を行い、[完了] をクリックします。
  - ネットワーク: lb-network
  - サブネット: lb-subnet
  - プライマリ内部 IP: エフェメラル（自動）
  - 外部 IP: エフェメラル
- [管理] をクリックします。[起動スクリプト] フィールドに、次のスクリプトの内容をコピーして貼り付けます。スクリプトの内容は 4 つの VM ですべて同じです。
```
#! /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
    
```
[作成] をクリックします。

インスタンス·グループの作成

Google Cloud Console の [インスタンスグループ] ページに移動します。
[インスタンスグループ] ページに移動
次の手順を繰り返し、それぞれが 2 つの VM を持つ 2 つの非マネージドインスタンスグループを作成します。以下のような組み合わせを使用します。
- インスタンスグループ: ig-a、ゾーン: us-west1-a、VM: vm-a1 と vm-a2
- インスタンスグループ: ig-c、ゾーン: us-west1-c、VM: vm-c1 と vm-c2
[インスタンスグループを作成] をクリックします。
ステップ 2 に示したように [名前] を設定します。
[ロケーション] セクションで、[シングルゾーン] を選択して、[リージョン] には us-west1 を選択し、手順 2 に示したゾーンを選択します。
[グループタイプ] セクションで [非マネージドインスタンスグループ] を選択します。
[ネットワーク] に「lb-network」と入力します。
[サブネットワーク] に「lb-subnet」と入力します。
[VM インスタンス] セクションに、ステップ 2 で示した VM を追加します。
[作成] をクリックします。

gcloud

[VM-NAME] と [ZONE] の 4 つの組み合わせを使用して、次のコマンドを 4 回実行して 4 つの VM を作成します。スクリプトの内容は 4 つの VM ですべて同じです。

vm-a1 の [VM-NAME] と us-west1-a の [ZONE]
vm-a2 の [VM-NAME] と us-west1-a の [ZONE]
vm-c1 の [VM-NAME] と us-west1-c の [ZONE]
vm-c2 の [VM-NAME] と us-west1-c の [ZONE]

    gcloud compute instances create [VM-NAME] \
        --zone=[ZONE] \
        --image-family=debian-9 \
        --image-project=debian-cloud \
        --tags=allow-ssh,allow-health-check \
        --subnet=lb-subnet \
        --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 unmanaged create ig-a \
        --zone=us-west1-a
    gcloud compute instance-groups unmanaged create ig-c \
        --zone=us-west1-c

適切なインスタンスグループに VM を追加します。

    gcloud compute instance-groups unmanaged add-instances ig-a \
        --zone=us-west1-a \
        --instances=vm-a1,vm-a2
    gcloud compute instance-groups unmanaged add-instances ig-c \
        --zone=us-west1-c \
        --instances=vm-c1,vm-c2

api

4 つの VM の場合は、次の VM 名とゾーンを使用します。

vm-a1 の [VM-NAME] と us-west1-a の [ZONE]
vm-a2 の [VM-NAME] と us-west1-a の [ZONE]
vm-c1 の [VM-NAME] と us-west1-c の [ZONE]
vm-c2 の [VM-NAME] と us-west1-c の [ZONE]

4 つのバックエンド VM を作成するには、instances.insert メソッドに 4 つの POST リクエストを送信します。

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instances
    {
      "name": "[VM-NAME]",
      "tags": {
        "items": [
          "allow-health-check",
          "allow-ssh"
        ]
      },
      "machineType": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/machineTypes/n1-standard-1",
      "canIpForward": false,
      "networkInterfaces": [
        {
          "network": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/lb-network",
          "subnetwork": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/subnetworks/lb-subnet",
          "accessConfigs": [
            {
              "type": "ONE_TO_ONE_NAT",
              "name": "external-nat",
              "networkTier": "PREMIUM"
            }
          ]
        }
      ],
      "disks": [
        {
          "type": "PERSISTENT",
          "boot": true,
          "mode": "READ_WRITE",
          "autoDelete": true,
          "deviceName": "[VM-NAME]",
          "initializeParams": {
            "sourceImage": "projects/debian-cloud/global/images/debian-9-stretch-v20190618",
            "diskType": "projects/[PROJECT_ID]/zones/us-west1-a/diskTypes/pd-standard",
            "diskSizeGb": "10"
          }
        }
      ]
      "metadata": {
        "items": [
          {
            "key": "startup-script",
            "value": "#! /bin/bash\napt-get update\napt-get install apache2 -y\na2ensite default-ssl\na2enmod ssl\nvm_hostname=\"$(curl -H \"Metadata-Flavor:Google\" \\\nhttp://169.254.169.254/computeMetadata/v1/instance/name)\"\necho \"Page served from: $vm_hostname\" | \\\ntee /var/www/html/index.html\nsystemctl restart apache2"
          }
        ]
      },
      "scheduling": {
        "preemptible": false
      },
      "deletionProtection": false
    }

instanceGroups.insert メソッドに POST リクエストを送信して、2 つのインスタンスグループを作成します。

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-a/instanceGroups
    {
      "name": "ig-a",
      "network": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/lb-network",
      "subnetwork": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/subnetworks/lb-subnet"
    }

    POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-c/instanceGroups
    {
      "name": "ig-c",
      "network": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/lb-network",
      "subnetwork": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/subnetworks/lb-subnet"
    }

instanceGroups.addInstances メソッドに POST リクエストを送信して、各インスタンスグループにインスタンスを追加します。

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-a/instanceGroups/ig-a/addInstances
    {
      "instances": [
        {
          "instance": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-a/instances/vm-a1",
          "instance": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-a/instances/vm-a2"
        }
      ]
    }

    POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-c/instanceGroups/ig-c/addInstances
    {
      "instances": [
        {
          "instance": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-c/instances/vm-c1",
          "instance": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-c/instances/vm-c2"
        }
      ]
    }

クライアント VM の作成

この例では、クライアント VM（vm-client）を、バックエンド（サーバー）VM と同じリージョンに作成します。クライアントは、ロードバランサの構成を検証し、テストセクションで説明されている想定される動作を示すために使用します。

Console

Google Cloud Console の [VM インスタンス] ページに移動します。
[VM インスタンス] ページに移動
[インスタンスを作成] をクリックします。
[名前] を vm-client に設定します。
[ゾーン] を us-west1-a に設定します。
[管理、セキュリティ、ディスク、ネットワーク、単一テナンシー] をクリックして、次のように変更します。
- [ネットワーキング] をクリックして allow-ssh を ネットワークタグに追加します。
- [ネットワークインターフェース] にある編集ボタンをクリックして、次の変更を行い、[完了] をクリックします。
  - ネットワーク: lb-network
  - サブネット: lb-subnet
  - プライマリ内部 IP: エフェメラル（自動）
  - 外部 IP: エフェメラル
[作成] をクリックします。

gcloud

クライアント VM はロードバランサと同じリージョン内の任意のゾーンにあり、そのリージョン内の任意のサブネットを使用できます。この例では、クライアントは us-west1-a ゾーンにあり、バックエンド VM と同じサブネットを使用しています。

    gcloud compute instances create vm-client \
        --zone=us-west1-a \
        --image-family=debian-9 \
        --image-project=debian-cloud \
        --tags=allow-ssh \
        --subnet=lb-subnet

api

instances.insert メソッドに POST リクエストを送信します。

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-a/instances
    {
      "name": "vm-client",
      "tags": {
        "items": [
          "allow-ssh"
        ]
      },
      "machineType": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-a/machineTypes/n1-standard-1",
      "canIpForward": false,
      "networkInterfaces": [
        {
          "network": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/lb-network",
          "subnetwork": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/subnetworks/lb-subnet",
          "accessConfigs": [
            {
              "type": "ONE_TO_ONE_NAT",
              "name": "external-nat",
              "networkTier": "PREMIUM"
            }
          ]
        }
      ],
      "disks": [
        {
          "type": "PERSISTENT",
          "boot": true,
          "mode": "READ_WRITE",
          "autoDelete": true,
          "deviceName": "[VM-NAME]",
          "initializeParams": {
            "sourceImage": "projects/debian-cloud/global/images/debian-9-stretch-v20190618",
            "diskType": "projects/[PROJECT_ID]/zones/us-west1-a/diskTypes/pd-standard",
            "diskSizeGb": "10"
          }
        }
      ]
      "scheduling": {
        "preemptible": false
      },
      "deletionProtection": false
    }

ロードバランサのコンポーネントを構成する

この手順では、ヘルスチェックとバックエンドサービス、フロントエンドコンポーネントなどの内部 TCP / UDP ロードバランサコンポーネントを構成します。

ヘルスチェック: この例では、HTTP ヘルスチェックで HTTP 200（OK）レスポンスを確認します。詳細については、内部 TCP / UDP 負荷分散の概要のヘルスチェックのセクションをご覧ください。
バックエンドサービス: HTTP トラフィックが内部ロードバランサに渡されるため、UDP ではなく TCP を指定します。
転送ルール: この例では、内部転送ルールを 1 つ作成します。
内部 IP アドレス: この例では、転送ルールを作成する際に内部 IP アドレス（10.1.2.99）を指定しています。

Console

ロードバランサの作成とバックエンドサービスの構成

Google Cloud Console で [負荷分散] ページに移動します。
[負荷分散] ページに移動
[ロードバランサを作成] をクリックします。
[TCP 負荷分散] で [構成を開始] をクリックします。
[インターネット接続または内部専用] で [VM 間のみ] を選択します。
[続行] をクリックします。
[名前] を be-ilb に設定します。
[バックエンドの構成] をクリックして、次の変更を行います。
1. リージョン: us-west1
2. ネットワーク: lb-network
3. [バックエンド] の [新しいアイテム] セクションで、ig-a インスタンスグループを選択し、[完了] をクリックします。
4. [バックエンドを追加] をクリックします。[新しいアイテム] セクションが表示されたら、ig-c インスタンスグループを選択して、[完了] をもう一度クリックします。
5. [ヘルスチェック] で [別のヘルスチェックを作成] を選択し、次の情報を入力して [保存して次へ] をクリックします。
  - 名前: hc-http-80
  - プロトコル: HTTP
  - ポート: 80
  - プロキシプロトコル: NONE
  - リクエストパス: /
6. 続行する前に、[バックエンドの構成] の隣に青いチェックマークがあることを確認します。ない場合は、この手順を確認します。
[フロントエンドの構成] をクリックします。[新しいフロントエンドの IP とポート] セクションで、次の変更を行います。
1. 名前: fr-ilb
2. サブネットワーク: lb-subnet
3. [内部 IP] から、[静的内部 IP アドレスの予約] を選択し、次の情報を入力して [予約] をクリックします。
  - 名前: ip-ilb
  - 静的 IP アドレス: 選択を許可
  - カスタム IP アドレス: 10.1.2.99
4. ポート: [単一] を選択して、ポート番号に 80 と入力します。
5. 続行する前に、[フロントエンドの構成] の隣に青いチェックマークがあることを確認します。ない場合は、この手順を確認します。
[確認と完了] をクリックします。設定を再度確認します。
[作成] をクリックします。

gcloud

新しい HTTP ヘルスチェックを作成して、ポート 80 で VM との TCP 接続をテストします。
```
    gcloud compute health-checks create http hc-http-80 \
        --port=80
    
```

HTTP トラフィックのバックエンドサービスを作成します。

    gcloud compute backend-services create be-ilb \
        --load-balancing-scheme=internal \
        --protocol=tcp \
        --region=us-west1 \
        --health-checks=hc-http-80

バックエンドサービスに、2 つのインスタンスグループを追加します。

    gcloud compute backend-services add-backend be-ilb \
        --region=us-west1 \
        --instance-group=ig-a \
        --instance-group-zone=us-west1-a
    gcloud compute backend-services add-backend be-ilb \
        --region=us-west1 \
        --instance-group=ig-c \
        --instance-group-zone=us-west1-c

バックエンドサービスの転送ルールを作成します。転送ルールを作成するときは、サブネット内の内部 IP アドレスに 10.1.2.99 を指定します。

    gcloud compute forwarding-rules create fr-ilb \
        --region=us-west1 \
        --load-balancing-scheme=internal \
        --network=lb-network \
        --subnet=lb-subnet \
        --address=10.1.2.99 \
        --ip-protocol=TCP \
        --ports=80 \
        --backend-service=be-ilb \
        --backend-service-region=us-west1

api

healthChecks.insert メソッドに POST リクエストを送信してヘルスチェックを作成します。

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/healthChecks
    {
      "name": "hc-http-80",
      "type": "HTTP",
      "httpHealthCheck": {
        "port": 80
      }
    }

regionBackendServices.insert メソッドに POST リクエストを送信してリージョンバックエンドサービスを作成します。

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/backendServices
    {
      "name": "be-ilb",
      "backends": [
        {
          "group": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-a/instanceGroups/ig-a",
          "balancingMode": "CONNECTION"
        }
        {
          "group": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-c/instanceGroups/ig-c",
          "balancingMode": "CONNECTION"
        }
      ],
      "healthChecks": [
        "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/healthChecks/hc-http-80"
      ],
      "loadBalancingScheme": "INTERNAL",
      "connectionDraining": {
        "drainingTimeoutSec": 0
      }
    }

forwardingRules.insertメソッドに POST リクエストを送信して転送ルールを作成します。

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/forwardingRules
    {
      "name": "fr-ilb",
      "IPAddress": "10.1.2.99",
      "IPProtocol": "TCP",
      "ports": [
        "80"
      ],
      "loadBalancingScheme": "INTERNAL",
      "subnetwork": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/subnetworks/lb-subnet",
      "network": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/lb-network",
      "backendService": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/backendServices/be-ilb",
      "networkTier": "PREMIUM"
    }

テスト

これらのテストでは、ロードバランサの構成を検証し、想定される動作を確認する方法を示します。

負荷分散のテスト

このテストでは、ロードバランサのバックエンド VM からではなく、個別のクライアント VM からロードバランサに接続します。セッションアフィニティが構成されていないため、トラフィックは 4 つのバックエンド VM に分散されます。

クライアント VM インスタンスに接続します。

    gcloud compute ssh vm-client --zone=us-west1-a

curl を使用して IP アドレスに接続するロードバランサへのウェブリクエストを作成します。レスポンスが異なるバックエンド VM から返ってくることを確認するために、このリクエストを繰り返します。レスポンスを生成する VM の名前が、各バックエンド VM 上で、/var/www/html/index.html のコンテンツによる HTML レスポンスのテキストとして表示されます。想定されるレスポンスは、Page served from: vm-a1、Page served from: vm-a2 などです。
```
    curl http://10.1.2.99
    
```
- 内部転送ルールにサービスラベルを追加すると、内部 DNS サービス名を使用してロードバランサに接続できます。
```
    curl http://web-test.fr-ilb.il4.us-west1.lb.[PROJECT_ID].internal
    
```

ロードバランサの IP アドレスに対する ping の実行

このテストでは、ロードバランサの IP アドレスに対して ping を実行することはできません。このテストではこの想定される動作が示されます。これは、内部 TCP / UDP ロードバランサが、別々のデバイスではなく、仮想ネットワークプログラミングで実装されているためです。

クライアント VM インスタンスに接続します。

    gcloud compute ssh vm-client --zone=us-west1-a

ロードバランサの IP アドレスに対して ping を試行します。レスポンスが返されず、ping コマンドがこの例では 10 秒後にタイムアウトすることに注意してください。
```
    timeout 10 ping 10.1.2.99
    
```

負荷分散された VM からのリクエストの送信

このテストでは、負荷分散されているサーバー VM のバックエンド VM からのロードバランサへのリクエストが、常に同じ VM によって応答されることが示されます。

内部 TCP / UDP 負荷分散は、ゲスト OS の仮想ネットワークプログラミングと VM 構成を使用して実装されます。Linux VM では、Linux ゲスト環境によってゲスト OS ルーティングテーブルにルートをインストールしてローカル構成が実行されます。ローカルルートのため、ロードバランサの IP アドレスへのトラフィックは、負荷分散された VM 自体に残ります（このローカルルートは VPC ネットワークのルートとは異なるルートです）。

バックエンド VM に接続します（たとえば、vm-a1）。
```
    gcloud compute ssh vm-a1 --zone=us-west1-a
    
```
重要: 外部 IP アドレスを削除した場合は、この方法でバックエンド VM に接続することはできません。バックエンド VM に外部 IP アドレスが割り当てられない場合の接続オプションについては、外部 IP アドレスを持たないインスタンスに接続するをご覧ください。
IP アドレスまたはサービス名を指定し curl を使用して、ロードバランサにウェブリクエストを送信します。リクエストを繰り返します。その際、リクエストを処理するバックエンド VM からレスポンスが送信されることに注意してください。vm-a1 からテストするときに想定されるレスポンスは常に次のとおりです。 Page served from: vm-a1
```
    curl http://10.1.2.99
    
```
ローカルのルーティングテーブルを調べて、ロードバランサ自体の IP アドレス（10.1.2.99）に一致する宛先を探します。このルートは内部 TCP / UDP 負荷分散に必須の部分です。これにより、ロードバランサの背後にある VM からのリクエストが常に同じ VM によって応答される理由がわかります。
```
    ip route show table local | grep 10.1.2.99
    
```

追加の構成オプション

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

グローバルアクセスの有効化

グローバルアクセスを有効にすると、任意のリージョンのクライアント VM インスタンスが内部 TCP / UDP ロードバランサにアクセスできるようになります。

次の例では、europe-west1 リージョンのクライアント VM が、us-west1 リージョンの内部 TCP / UDP ロードバランサにアクセスします。

グローバルアクセスを構成した内部 TCP / UDP 負荷分散（クリックして拡大）

デフォルトでは、VPC ネットワークの送信元のクライアント VM は、内部転送ルールの IP アドレスと関連のバックエンドと同じリージョンに存在する必要があります。このデフォルトの動作を変更するには、グローバルアクセスを有効にします。これにより、任意のリージョンのクライアントがロードバランサのバックエンドにアクセスできるようになります。バックエンドインスタンスはすべてロードバランサと同じ単一リージョンに存在する必要があります。

グローバルアクセスを有効にして、VPC ネットワークピアリングで接続している VPC ネットワークから内部 TCP / UDP ロードバランサにアクセスすることで、デプロイメントを拡張できます。詳細については、内部負荷分散と接続ネットワークをご覧ください。

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

Console

ロードバランサの転送ルールを編集する

Google Cloud Console で [負荷分散] ページに移動します。
[負荷分散] ページに移動
[名前] 列で、内部 TCP / UDP ロードバランサをクリックします。
[編集] をクリックします。
[フロントエンドの構成] をクリックします。
鉛筆のアイコンをクリックします。
[グローバルアクセス] で [有効] を選択します。
[完了] をクリックします。
[更新] をクリックします。

[ロードバランサの詳細] ページで、フロントエンドの構成がリージョン region で、グローバルアクセスが有効になっていることを確認します。

gcloud

既存の転送ルール fr-ilb を更新し、--allow-global-access フラグを追加します。
```
    gcloud compute forwarding-rules update fr-ilb \
       --allow-global-access
    
```
転送ルールでグローバルアクセスが許可されていることを確認します。
```
    gcloud compute forwarding-rules describe fr-ilb
    
```
出力は次のようになります。allowGlobalAccess: true

ロードバランサとは別のリージョンにクライアント VM を作成します。この例では、クライアントは europe-west1 リージョンにあります。

    gcloud compute instances create vm-client2 \
       --zone=europe-west1-a \
       --image-family=debian-9 \
       --image-project=debian-cloud \
       --tags=allow-ssh \
       --subnet=lb-subnet

クライアント VM インスタンスに接続して、接続をテストします。

    gcloud compute ssh vm-client2 --zone=europe-west1-a

    curl http://10.1.2.99

api

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

PATCH https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/forwardingRules/fr-ilb
    {
      "allowGlobalAccess": true
    }

マネージドインスタンスグループの構成

この構成例では、非マネージドインスタンスグループが作成されています。内部 TCP / UDP 負荷分散のバックエンドとして、マネージドインスタンスグループ（ゾーンまたはリージョンのマネージドインスタンスグループなど）を使用できます。

マネージドインスタンスグループを使用するには、インスタンステンプレートを作成する必要があります。この例では、ゾーンの 2 つの非マネージドインスタンスグループを 1 つのリージョンマネージドインスタンスグループに置き換える方法を示しています。リージョンのマネージドインスタンスグループは、複数のゾーンに VM を自動的に作成し、ゾーン間で本番環境トラフィックを分散するのが容易になります。

マネージドインスタンスグループは、自動スケーリングと自動修復をサポートします。内部 TCP / UDP 負荷分散で自動スケーリングを使用する場合、負荷分散に基づいてスケーリングすることはできません。

この手順では、内部 TCP / UDP ロードバランサのバックエンドサービスを、リージョンのマネージドインスタンスグループを使用して変更する方法を示します。

Console

インスタンステンプレート

Google Cloud Console で VM インスタンスのテンプレートページに移動します。
VM インスタンステンプレートページに移動
[インスタンステンプレートを作成] をクリックします。
[名前] を template-vm-ilb に設定します。
マシンタイプを選択します。
[ブートディスク] で、[変更] をクリックして、オペレーティングシステムに Debian を選択し、バージョンに 9 Stretch を選択します。
[保存] をクリックして、このブートディスクのオプションを保存します。
[管理、セキュリティ、ディスク、ネットワーク、単一テナンシー] をクリックします。
- [ネットワーキング] をクリックして、次の変更を行います。
  - ネットワーク: lb-network
  - サブネット: lb-subnet
  - ネットワークタグ: allow-ssh と allow-health-check
- [管理] をクリックします。[起動スクリプト] フィールドに、次のスクリプトの内容をコピーして貼り付けます。
```
#! /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
    
```
[作成] をクリックします。

マネージドインスタンスグループ

Google Cloud Console で VM インスタンスグループのページに移動します。
VM インスタンスグループのページに移動
[インスタンスグループを作成] をクリックします。
[名前] を ig-ilb に設定します。
[ロケーション] で [マルチゾーン] を選択し、[リージョン] を us-west1 に設定します。
[インスタンステンプレート] を template-vm-ilb に設定します。
（省略可）自動スケーリングを構成します。インスタンスグループは内部 TCP / UDP 負荷分散のバックエンドであるため、HTTP 負荷分散の使用に基づいたインスタンスグループの自動スケーリングはできません。
[インスタンスの最小数] を 1、[インスタンスの最大数] を 6 にそれぞれ設定します。
（省略可）自動修復を構成します。自動修復を構成する場合、内部 TCP / UDP ロードバランサのバックエンドサービスで使用されるのと同じヘルスチェックを使用します。この例では、hc-http-80 を使用します。
[作成] をクリックします。

gcloud

インスタンステンプレートを作成します。必要に応じて、その他のパラメータを設定します。たとえば、イメージテンプレートには、マシンタイプを設定します。

    gcloud compute instance-templates create template-vm-ilb \
        --image-family=debian-9 \
        --image-project=debian-cloud \
        --tags=allow-ssh,allow-health-check \
        --subnet=lb-subnet \
        --region=us-west1 \
        --network=lb-network \
        --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'

次のテンプレートを使用して、リージョンのマネージドインスタンスグループを 1 つ作成します。

    gcloud compute instance-groups managed create ig-ilb \
        --template=template-vm-ilb \
        --region=us-west1 \
        --size=6

リージョンのマネージドインスタンスグループをバックエンドとして作成済みのバックエンドサービスに追加します。

    gcloud compute backend-services add-backend be-ilb \
        --region=us-west1 \
        --instance-group=ig-ilb \
        --instance-group-region=us-west1

ゾーンの 2 つの非マネージドインスタンスグループをバックエンドサービスから切断します。

    gcloud compute backend-services remove-backend be-ilb \
        --region=us-west1 \
        --instance-group=ig-a \
        --instance-group-zone=us-west1-a
    gcloud compute backend-services remove-backend be-ilb \
        --region=us-west1 \
        --instance-group=ig-c \
        --instance-group-zone=us-west1-c

バックエンド VM から外部 IP アドレスを削除する

バックエンド VM を作成したときに、起動スクリプトを介して Apache をダウンロードできるように、それぞれにエフェメラル外部 IP アドレスが割り当てられました。バックエンド VM は内部ロードバランサのみで使用されるため、外部 IP アドレスは削除できます。外部 IP アドレスを削除すると、バックエンド VM から直接インターネットにアクセスできなくなります。

Console

Google Cloud Console の [VM インスタンス] ページに移動します。
[VM インスタンス] ページに移動
各バックエンド VM に対して以下の手順を繰り返します。
バックエンド VM の名前をクリックします。たとえば、vm-a1 をクリックすると、VM インスタンスの詳細ページが表示されます。
[編集] をクリックします。
[ネットワークインターフェース] セクションで、[編集] ボタンをクリックします。
[外部 IP] ポップアップで [なし] を選択して、[完了] をクリックします。
[保存] をクリックします。

gcloud

インスタンスのゾーンを検索する。たとえば、リージョンのマネージドインスタンスグループを使用している場合、インスタンスごとに次のコマンドを実行してゾーンを判別します。[SERVER-VM] を検索する VM の名前に置き換えます。
```
    gcloud compute instances list --filter="name=[SERVER-VM]"
    
```
各バックエンド VM に対して次の手順を繰り返します。[SERVER-VM] を VM の名前、[ZONE] を VM のゾーンにそれぞれ置き換えます。
```
    gcloud compute instances delete-access-config [SERVER-VM] \
        --zone=[ZONE] \
        --access-config-name=external-nat
    
```

api

各バックエンド VM の instances.deleteAccessConfig メソッドに POST リクエストを送信します。vm-a1 は VM の名前、us-west1-a は VM のゾーンにそれぞれ置き換えます

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-a/instances/v1-a1/deleteAccessConfig?accessConfig=external-nat&networkInterface=None

複数のポートでトラフィックを受信する

受信トラフィックのポートを制御するコンポーネントは内部転送ルールです。この手順では、ポート 80 の転送ルールをポート 80 とポート 443 でトラフィックを受け入れるルールに置き換えます。バックエンド VM を作成すると、Apache をインストールして構成する起動スクリプトもポート 443 で HTTPS トラフィックを処理するように構成されます。Google Cloud では転送ルールの更新がサポートされていないため、転送ルールを置き換える必要があります。

gcloud

既存の転送ルール fr-ilb を削除してください。

    gcloud compute forwarding-rules delete fr-ilb \
        --region=us-west1

ポート 80 と 443 に同じ名前の置換転送ルールを作成します。IP アドレスとバックエンドサービスを含む、このルールのその他のパラメータは同じです。

    gcloud compute forwarding-rules create fr-ilb \
        --region=us-west1 \
        --load-balancing-scheme=internal \
        --network=lb-network \
        --subnet=lb-subnet \
        --address=10.1.2.99 \
        --ip-protocol=TCP \
        --ports=80,443 \
        --backend-service=be-ilb \
        --backend-service-region=us-west1

クライアント VM インスタンスに接続し、HTTP 接続と HTTPS 接続をテストします。
- クライアント VM に接続します。
```
    gcloud compute ssh vm-client --zone=us-west1-a
    
```
- HTTP 接続をテストします。
```
    curl http://10.1.2.99
    
```
- HTTPS 接続をテストします。サンプルの設定の Apache サーバー構成では自己署名証明書を使用するため、--insecure フラグが必要です。
```
    curl https://10.1.2.99 --insecure
    
```
- HTTP リクエスト（ポート 80）と HTTPS リクエスト（ポート 443）がすべてのバックエンド VM で処理されることを確認します。

セッションアフィニティの使用

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

この手順では、クライアント IP アドレスに基づいてセッションアフィニティを使用するように、内部 TCP / UDP ロードバランサのバックエンドサービスを更新する方法を示します。

クライアントの IP アドレスとロードバランサの IP アドレス（内部転送ルールの内部 IP アドレス）から作成されたハッシュに基づいて、特定のクライアントのリクエストが同じバックエンド VM に転送されます。

Console

Google Cloud Console で [負荷分散] ページに移動します。
[負荷分散] ページに移動
[be-ilb]（この例で作成したバックエンドサービスの名前）をクリックし、[編集] をクリックします。
内部ロードバランサの編集ページで、バックエンドの構成をクリックします。
[セッションアフィニティ] ポップアップメニューからクライアント IP を選択します。
[更新] をクリックします。

gcloud

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

    gcloud compute backend-services update be-ilb \
        --session-affinity CLIENT_IP

api

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

PATCH https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/backendServices/be-ilb
    {
      "sessionAffinity": "CLIENT_IP"
    }

トラフィック分散に影響するセッションアフィニティと各オプションの詳細については、トラフィック分散をご覧ください。

別のサブネットで転送ルールを作成する

この手順では、1 つの内部 TCP / UDP ロードバランサに対して複数の転送ルールを作成できることを示すために、2 つ目の IP アドレスと転送ルールを別のサブネットに作成します。転送ルールのリージョンは、バックエンドサービスのリージョンと一致する必要があります。

ファイアウォールルールに従うと、リージョン内のサブネット内のクライアントは、内部 TCP / UDP ロードバランサの IP アドレスに接続できます。

us-west1 リージョン内の lb-network ネットワークに 2 つ目のサブネットを作成します。

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

ポート 80 と 443 に 2 つ目の転送ルールを作成します。IP アドレスやバックエンドサービスなど、このルールのその他のパラメータは、プライマリ転送ルール fr-ilb と同じです。

    gcloud compute forwarding-rules create fr-ilb-2 \
        --region=us-west1 \
        --load-balancing-scheme=internal \
        --network=lb-network \
        --subnet=second-subnet \
        --address=10.5.6.99 \
        --ip-protocol=TCP \
        --ports=80,443 \
        --backend-service=be-ilb \
        --backend-service-region=us-west1

クライアント VM インスタンスに接続し、IP アドレスへの HTTP 接続と HTTPS 接続をテストします。
- クライアント VM に接続します。
```
    gcloud compute ssh vm-client --zone=us-west1-a
    
```
- IP アドレスへの HTTP 接続をテストします。
```
    curl http://10.1.2.99
    curl http://10.5.6.99
    
```
- HTTPS 接続をテストします。サンプル設定の Apache サーバー構成では自己署名証明書を使用するため、--insecure を使用する必要があります。
```
    curl https://10.1.2.99 --insecure
    curl https://10.5.6.99 --insecure
    
```
- リクエストは、使用されているプロトコル（HTTP または HTTPS）や IP アドレスに関係なく、すべてのバックエンド VM で処理されることを確認してください。

次のステップ

基礎知識については、内部 TCP / UDP 負荷分散のコンセプトをご覧ください。
フェイルオーバーに関する重要な情報については、内部 TCP / UDP 負荷分散のフェイルオーバーのコンセプトをご覧ください。
ロードバランサで使用できる DNS 名オプションについては、内部負荷分散と DNS 名をご覧ください。
内部 TCP / UDP ロードバランサのフェイルオーバーの構成の手順と例について詳しくは、内部 TCP / UDP 負荷分散のフェイルオーバーの構成をご覧ください。
内部 TCP / UDP 負荷分散に関する Stackdriver のロギングとモニタリングの構成については、内部 TCP / UDP 負荷分散のロギングとモニタリングをご覧ください。
VPC ネットワークに接続されたピアネットワークから内部 TCP / UDP ロードバランサにアクセスする方法については、内部 TCP / UDP 負荷分散と接続ネットワークをご覧ください。
内部 TCP / UDP ロードバランサの問題のトラブルシューティング方法については、内部 TCP / UDP 負荷分散のトラブルシューティングをご覧ください。

内部 TCP / UDP 負荷分散の設定

権限

設定

ネットワーク、リージョン、サブネットの構成

Console

gcloud

api

ファイアウォール ルールの構成

Console

gcloud

api

バックエンド VM とインスタンス グループの作成

Console

gcloud

api

クライアント VM の作成

Console

gcloud

api

ロードバランサのコンポーネントを構成する

Console

gcloud

api

テスト

負荷分散のテスト

ロードバランサの IP アドレスに対する ping の実行

負荷分散された VM からのリクエストの送信

追加の構成オプション

グローバル アクセスの有効化

Console

gcloud

api

マネージド インスタンス グループの構成

Console

gcloud

バックエンド VM から外部 IP アドレスを削除する

Console

gcloud

api

複数のポートでトラフィックを受信する

gcloud

セッション アフィニティの使用

Console

gcloud

api

別のサブネットで転送ルールを作成する

次のステップ

ファイアウォールルールの構成

バックエンド VM とインスタンスグループの作成

グローバルアクセスの有効化

マネージドインスタンスグループの構成

セッションアフィニティの使用