내부 TCP/UDP 부하 분산 설정

이 가이드에서는 예시를 사용하여 Google Cloud Platform 내부 TCP/UDP 부하 분산의 기본 사항을 설명합니다. 이 가이드를 진행하기 전에 다음 사항을 숙지하세요.

권한

이 가이드를 진행하려면 프로젝트에서 인스턴스를 만들고 네트워크를 수정해야 합니다. 이렇게 하려면 프로젝트 소유자 또는 편집자이거나, 다음 Compute Engine IAM 역할을 모두 보유해야 합니다.

태스크	필요한 역할
네트워크, 서브넷, 부하 분산기 구성요소 만들기	네트워크 관리자
방화벽 규칙 추가 및 삭제	보안 관리자
인스턴스 생성	인스턴스 관리자

설정

이 가이드에서는 내부 TCP/UDP 부하 분산기를 구성하고 테스트하는 방법을 설명합니다. 이 섹션의 단계에서는 다음을 구성하는 방법을 설명합니다.

커스텀 서브넷이 있는 샘플 VPC 네트워크
백엔드 VM에 대한 수신 연결을 허용하는 방화벽 규칙
4개의 백엔드 VM:
- us-west1-a 영역의 비관리형 인스턴스 그룹에 있는 VM 2개
- us-west1-c 영역의 비관리형 인스턴스 그룹에 있는 VM 2개
연결을 테스트하기 위한 클라이언트 VM 1개
다음 내부 TCP/UDP 부하 분산기 구성요소:
- 백엔드 서비스의 상태 확인
- 2개의 영역 인스턴스 그룹에 대한 연결 분산을 관리하기 위한 us-west1 리전의 내부 백엔드 서비스
- 부하 분산기의 프런트엔드에 대한 내부 전달 규칙 및 내부 IP 주소

이 예시의 아키텍처는 다음과 같습니다.

네트워크, 리전, 서브넷 구성

하나 이상의 서브넷이 있는 VPC 네트워크가 필요합니다. 내부 TCP/UDP 부하 분산기는 리전에 따라 다릅니다. 트래픽 소스가 부하 분산기와 동일한 리전의 서브넷에 있는 경우 VPC 네트워크 내의 트래픽이 부하 분산기로 라우팅됩니다.

이 예시에서는 다음 VPC 네트워크, 리전, 서브넷을 사용합니다.

네트워크: 네트워크는 이름이 lb-network인 커스텀 모드 VPC 네트워크입니다.
리전: 리전은 us-west1입니다.
서브넷: 서브넷 lb-subnet은 10.1.2.0/24 IP 범위를 사용합니다.

네트워크 및 서브넷 예시를 만들려면 다음 단계를 따르세요.

Console

Google Cloud Platform 콘솔의 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

lb-network 리전의 us-west1 네트워크에 서브넷을 만듭니다.

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: 부하 분산되는 인스턴스에 적용되는 인그레스 규칙으로, GCP 상태 확인 시스템(130.211.0.0/22 및 35.191.0.0/16)의 트래픽을 허용합니다. 이 예시에서는 allow-health-check 대상 태그를 사용하여 적용 인스턴스를 식별합니다.

이러한 방화벽 규칙이 없으면 기본 거부 인그레스 규칙은 백엔드 인스턴스로 들어오는 트래픽을 차단합니다.

Console

Google Cloud Platform 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를 입력합니다.
만들기를 클릭합니다.
방화벽 규칙 만들기를 세 번째 클릭하여 GCP 상태 확인을 허용하는 규칙을 만듭니다.
- 이름: 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

fw-allow-ssh 방화벽 규칙을 만들어 allow-ssh 네트워크 태그를 사용해 VM으로 가는 SSH 연결을 허용합니다. source-ranges를 생략하면 GCP에서는 모든 소스를 의미하는 것으로 규칙을 해석합니다.
```
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 규칙을 만들어 GCP 상태 확인을 허용합니다.

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 부하 분산의 리전 특성을 설명하기 위해 두 인스턴스 그룹은 별도의 리전인 us-west1-a 및 us-west1-c에 배치됩니다.

인스턴스 그룹 ig-a에는 다음 두 VM이 포함됩니다.
- vm-a1
- vm-a2
인스턴스 그룹 ig-c에는 다음 두 VM이 포함됩니다.
- vm-c1
- vm-c2

4개의 모든 백엔드 VM에 대한 트래픽 부하가 분산됩니다. 4개의 백엔드 각각은 TCP 포트 80 및 443에서 Apache 웹 서버를 실행합니다. 각 IP 주소에는 lb-subnet의 내부 IP 주소와 임시 외부(공개) IP 주소가 할당됩니다. 나중에 외부 IP 주소를 삭제할 수 있습니다.

백엔드 VM의 외부 IP 주소는 필요하지 않습니다. 하지만 이 예시에서는 백엔드 VM이 인터넷에서 Apache를 다운로드하고 SSH를 통해 쉽게 연결할 수 있기 때문에 유용합니다.

기본적으로 Apache는 임의의 IP 주소에 바인딩되도록 구성됩니다. 내부 TCP/UDP 부하 분산기는 대상 IP를 보존하여 패킷을 전달합니다. 백엔드 VM에서 실행 중인 서버 소프트웨어가 부하 분산기의 내부 전달 규칙의 IP 주소에서 수신 대기하는지 확인합니다. 여러 내부 전달 규칙을 구성하는 경우 소프트웨어가 각기 연결된 내부 IP 주소를 수신하는지 확인합니다. 내부 TCP/UDP 부하 분산기가 백엔드 VM에 전달하는 패킷의 대상 IP 주소는 전달 규칙의 내부 IP 주소입니다.

설명의 편의를 위해 이러한 백엔드 VM은 Debian GNU/Linux 9를 실행합니다.

Console

백엔드 VM 만들기

Google Cloud Platform 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 GNU/Linux 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 Platform Console의 인스턴스 그룹 페이지로 이동합니다.
인스턴스 그룹 페이지로 이동
이러한 조합을 사용하여 각각 VM이 2개 있는 비관리형 인스턴스 그룹 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-NAME]의 vm-a1 및 [ZONE]의 us-west1-a
[VM-NAME]의 vm-a2 및 [ZONE]의 us-west1-a
[VM-NAME]의 vm-c1 및 [ZONE]의 us-west1-c
[VM-NAME]의 vm-c2 및 [ZONE]의 us-west1-c

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-NAME]의 vm-a1 및 [ZONE]의 us-west1-a
[VM-NAME]의 vm-a2 및 [ZONE]의 us-west1-a
[VM-NAME]의 vm-c1 및 [ZONE]의 us-west1-c
[VM-NAME]의 vm-c2 및 [ZONE]의 us-west1-c

instances.insert 메서드에 4개의 POST 요청을 수행하여 4개의 백엔드 VM을 만듭니다.

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(vm-client)을 만듭니다. 클라이언트는 부하 분산기의 구성을 검증하고 테스트 섹션에서 설명된 대로 예상되는 동작을 보여줍니다.

Console

Google Cloud Platform 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 200(OK) 응답만 확인하는 HTTP 상태 확인을 사용합니다. 자세한 내용은 내부 TCP/UDP 부하 분산 개요의 상태 확인 섹션을 참조하세요.
백엔드 서비스: 내부 부하 분산기를 통해 HTTP 트래픽을 전달해야 하므로 UDP가 아닌 TCP를 사용해야 합니다.
전달 규칙: 이 예시에서는 하나의 내부 전달 규칙을 만듭니다.
내부 IP 주소: 이 예시에서는 전달 규칙을 만들 때 내부 IP 주소 10.1.2.99를 지정합니다.

Console

부하 분산기 생성 및 백엔드 서비스 구성

Google Cloud Platform 콘솔의 부하 분산 페이지로 이동합니다.
부하 분산 페이지로 이동
부하 분산기 만들기를 클릭합니다.
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. 서브네트워크: ilb-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

백엔드 서비스에 두 인스턴스 그룹을 추가합니다.

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 주소 핑

이 테스트는 예상되는 동작을 보여줍니다. 부하 분산기의 IP 주소를 핑할 수 없습니다. 이는 내부 TCP/UDP 부하 분산기는 별도의 기기가 아닌 가상 네트워크 프로그래밍으로 구현되기 때문입니다.

클라이언트 VM 인스턴스에 연결합니다.
```
gcloud compute ssh vm-client --zone=us-west1-a
```
부하 분산기의 IP 주소에 대해 핑을 시도합니다. 응답이 없으며 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-a1과 같은 백엔드 VM에 연결합니다.
```
gcloud compute ssh vm-a1 --zone=us-west1-a
```
중요: 외부 IP 주소를 삭제한 경우 이러한 방식으로 백엔드 VM에 연결할 수 없습니다. 백엔드 VM에 외부 IP 주소가 없는 경우 연결 옵션에 외부 IP 주소가 없는 인스턴스에 연결을 참조하세요.
curl을 사용하여 부하 분산기에 IP 주소 또는 서비스 이름으로 웹 요청을 만듭니다. 요청을 반복하여 요청을 보낸 백엔드 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
```

추가 구성 옵션

이 섹션에서는 대체 및 추가 구성 옵션을 제공하는 구성 예시를 살펴봅니다. 모든 작업은 선택사항입니다. 원하는 순서대로 수행할 수 있습니다.

관리형 인스턴스 그룹 구성

예시 구성에서는 비관리형 인스턴스 그룹 2개를 만들었습니다. 그 대신 영역 및 리전 관리형 인스턴스 그룹을 포함한 관리형 인스턴스 그룹을 내부 TCP/UDP 부하 분산의 백엔드로 사용할 수 있습니다.

관리형 인스턴스 그룹을 사용하려면 인스턴스 템플릿을 만들어야 합니다. 이 절차에서는 예시의 비관리형 영역 인스턴스 그룹 두 개를 단일 영역 관리형 인스턴스 그룹으로 대체하는 방법을 보여줍니다. 리전 관리형 인스턴스 그룹은 리전의 여러 영역에 VM을 자동으로 생성하므로 영역 간 프로덕션 트래픽을 더 쉽게 배포할 수 있습니다.

관리형 인스턴스 그룹은 자동 확장 및 자동 복구도 지원합니다. 내부 TCP/UDP 부하 분산과 함께 자동 확장을 사용하면 부하 분산을 기준으로 확장할 수 없습니다.

이 절차에서는 예시로 든 내부 TCP/UDP 부하 분산기의 백엔드 서비스를 수정하여 리전 관리형 인스턴스 그룹을 사용하는 방법을 보여줍니다.

Console

인스턴스 템플릿

Google Cloud Platform Console의 VM 인스턴스 템플릿 페이지로 이동합니다.
VM 인스턴스 템플릿 페이지로 이동
인스턴스 템플릿 만들기를 클릭합니다.
이름을 template-vm-ilb로 설정합니다.
머신 유형을 선택합니다.
부팅 디스크의 경우 변경을 클릭하고 Debian GNU/Linux 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 Platform 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'

템플릿을 사용하여 리전 관리형 인스턴스 그룹을 한 개 만듭니다.

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 Platform Console의 VM 인스턴스 페이지로 이동합니다.
VM 인스턴스 페이지로 이동
각 백엔드 VM에 대해 다음 단계를 반복합니다.
VM 인스턴스 세부정보 페이지를 보려면 백엔드 VM의 이름(예: vm-a1)을 클릭합니다.
수정을 클릭합니다.
네트워크 인터페이스 섹션에서 수정 버튼을 클릭합니다.
외부 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의 vm-a1 메서드에 us-west1-a 요청을 만들어 POST을 VM의 이름으로 바꾸고 VM의 영역을 instances.deleteAccessConfig으로 바꿉니다.

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

여러 포트에서 트래픽 허용

수신 트래픽 포트를 제어하는 구성요소가 내부 전달 규칙입니다. 이 절차에서는 포트 80 및 포트 443에서 트래픽을 허용하는 포트 80으로 대체하는 방법을 보여줍니다. 백엔드 VM을 만들면 Apache를 설치하고 구성하는 시작 스크립트도 443 포트에서 HTTPS 트래픽을 제공하도록 구성합니다. GCP는 전달 규칙 업데이트를 지원하지 않으므로 전달 규칙을 바꿔야 합니다.

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
```
- (포트 80에서의) HTTP 요청과 (포트 443에서의) HTTPS 요청은 모든 백엔드 VM에서 처리됩니다.

세션 어피니티 사용하기

구성 예시는 세션 어피니티 없이 백엔드 서비스를 만듭니다.

이 절차에서는 클라이언트 IP 주소를 기반으로 세션 어피니티를 사용하도록 내부 TCP/UDP 부하 분산기 예시의 백엔드 서비스를 업데이트하는 방법을 보여줍니다.

부하 분산기는 클라이언트의 IP 주소와 부하 분산기의 IP 주소(내부 전달 규칙의 내부 IP 주소)에서 생성된 해시를 기반으로 특정 클라이언트의 요청을 동일한 백엔드 VM에 전달합니다.

Console

Google Cloud Platform 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"
}

세션 어피니티를 사용하여 트래픽 분산에 영향을 주는 방법에 대한 자세한 내용과 각 옵션에 대한 설명은 트래픽 분산을 참조하세요.

다른 서브넷에서 전달 규칙 만들기

이 절차에서는 하나의 내부 TCP/UDP 부하 분산기에 대해 여러 전달 규칙을 만들 수 있음을 보여주기 위해 다른 서브넷에 두 번째 IP 주소 및 전달 규칙을 만듭니다. 전달 규칙의 리전은 백엔드 서비스의 리전과 일치해야 합니다.

방화벽 규칙에 따라 리전의 모든 서브넷에 있는 클라이언트는 내부 TCP/UDP 부하 분산기 IP 주소에 연결할 수 있습니다.

us-west1 리전의 lb-network 네트워크에 두 번째 서브넷을 만듭니다.

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

포트 80 및 443에 대해 두 번째 전달 규칙을 만듭니다. 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 Logging 및 Monitoring 구성은 내부 TCP/UDP 부하 분산 로깅 및 모니터링을 참조하세요.
VPC 네트워크에 연결된 피어 네트워크에서 내부 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 주소 핑

부하 분산된 VM에서 요청 전송

추가 구성 옵션

관리형 인스턴스 그룹 구성

Console

gcloud

백엔드 VM에서 외부 IP 주소 제거

Console

gcloud

api

여러 포트에서 트래픽 허용

gcloud

세션 어피니티 사용하기

Console

gcloud

api

다른 서브넷에서 전달 규칙 만들기

다음 단계

다음에 대한 의견 보내기...