리전별 내부 프록시 네트워크 부하 분산기는 같은 VPC 네트워크의 클라이언트나 VPC 네트워크에 연결된 클라이언트에만 액세스할 수 있는 내부 IP 주소 뒤에서 TCP 서비스 트래픽을 실행하고 확장할 수 있게 해주는 프록시 기반 리전별 Layer 4 부하 분산기입니다.
이 가이드에서는 관리형 인스턴스 그룹(MIG) 백엔드를 사용하여 리전 내부 프록시 네트워크 부하 분산기를 설정하는 방법을 설명합니다.
시작하기 전에 리전 내부 프록시 네트워크 부하 분산기 개요를 읽어보세요.
개요
이 예시에서는 부하 분산기를 사용하여 REGION_A
리전의 두 영역 관리형 인스턴스 그룹에 있는 백엔드 VM에 TCP 트래픽을 분산합니다. 이 예시에서 서비스는 포트 110
에서 응답하도록 구성된 Apache 서버 세트입니다.
대부분의 브라우저는 포트 110
을 허용하지 않으므로 테스트 섹션에서는 curl
을 사용합니다.
이 예시에서는 다음 배포를 구성합니다.
리전 내부 프록시 네트워크 부하 분산기는 리전 부하 분산기입니다. 모든 부하 분산기 구성요소(백엔드 인스턴스 그룹, 백엔드 서비스, 대상 프록시, 전달 규칙)는 같은 리전에 있어야 합니다.
권한
이 가이드를 진행하려면 프로젝트에서 인스턴스를 만들고 네트워크를 수정할 수 있어야 합니다. 이렇게 하려면 프로젝트 소유자 또는 편집자이거나, 다음 Compute Engine IAM 역할을 모두 보유해야 합니다.
작업 | 필요한 역할 |
---|---|
네트워크, 서브넷, 부하 분산기 구성요소 만들기 | 네트워크 관리자 |
방화벽 규칙 추가 및 삭제 | 보안 관리자 |
인스턴스 만들기 | Compute 인스턴스 관리자 |
자세한 내용은 다음 가이드를 참조하세요.
네트워크 및 서브넷 구성
부하 분산기의 백엔드를 위한 서브넷 한 개와 부하 분산기의 프록시를 위한 서브넷 한 개, 총 두 개 서브넷이 있는 VPC 네트워크가 필요합니다. 리전 내부 프록시 네트워크 부하 분산기는 리전 기준입니다. 트래픽 소스가 부하 분산기와 동일한 리전의 서브넷에 있는 경우 VPC 네트워크 내의 트래픽이 부하 분산기로 라우팅됩니다.
이 예시에서는 다음 VPC 네트워크, 리전 및 서브넷을 사용합니다.
네트워크. 네트워크는 커스텀 모드 VPC 네트워크이며 이름은
lb-network
입니다.백엔드 서브넷.
REGION_A
리전에 있는backend-subnet
이라는 이름의 서브넷은 기본 IP 범위로10.1.2.0/24
를 사용합니다.프록시 서브넷:
REGION_A
리전에 있는proxy-only-subnet
이라는 이름의 서브넷은 기본 IP 범위로10.129.0.0/23
을 사용합니다.
전역 액세스를 보여주기 위해 이 예시에서는 다른 리전(REGION_B)과 기본 IP 주소가 10.3.4.0/24
인 서브넷에 두 번째 테스트 클라이언트 VM을 만듭니다.
네트워크 및 서브넷 만들기
콘솔
Google Cloud 콘솔에서 VPC 네트워크 페이지로 이동합니다.
VPC 네트워크 만들기를 클릭합니다.
이름에
lb-network
를 입력합니다.서브넷 섹션에서 서브넷 생성 모드를 커스텀으로 설정합니다.
부하 분산기의 백엔드에 대한 서브넷을 만듭니다. 새 서브넷 섹션에 다음 정보를 입력합니다.
- 이름:
backend-subnet
- 리전:
REGION_A
- IP 주소 범위:
10.1.2.0/24
- 이름:
완료를 클릭합니다.
서브넷 추가를 클릭합니다.
전역 액세스를 보여주는 서브넷을 만듭니다. 새 서브넷 섹션에 다음 정보를 입력합니다.
- 이름:
test-global-access-subnet
- 리전:
REGION_B
- IP 주소 범위:
10.3.4.0/24
- 이름:
완료를 클릭합니다.
만들기를 클릭합니다.
gcloud
gcloud compute networks create
명령어를 사용하여 커스텀 VPC 네트워크를 만듭니다.gcloud compute networks create lb-network --subnet-mode=custom
gcloud compute networks subnets create
명령어를 사용하여REGION_A
리전의lb-network
네트워크에 서브넷을 만듭니다.gcloud compute networks subnets create backend-subnet \ --network=lb-network \ --range=10.1.2.0/24 \ --region=REGION_A
REGION_A를 대상 Google Cloud 리전의 이름으로 바꿉니다.
gcloud compute networks subnets create
명령어를 사용하여REGION_B
리전의lb-network
네트워크에 서브넷을 만듭니다.gcloud compute networks subnets create test-global-access-subnet \ --network=lb-network \ --range=10.3.4.0/24 \ --region=REGION_B
REGION_B를 전역 액세스를 테스트하기 위해 두 번째 서브넷을 만들 Google Cloud 리전의 이름으로 바꿉니다.
프록시 전용 서브넷 만들기
프록시 전용 서브넷은 Google이 사용자를 대신하여 Envoy 프록시를 실행하는 데 사용하는 IP 주소 집합을 제공합니다. 프록시는 클라이언트의 연결을 종료하고 백엔드에 새 연결을 만듭니다.
이 프록시 전용 서브넷은 lb-network
VPC 네트워크의 REGION_A
리전에 있는 모든 Envoy 기반 부하 분산기에서 사용됩니다.
콘솔
Google Cloud 콘솔을 사용하는 경우에는 기다렸다가 나중에 부하 분산 페이지에서 프록시 전용 서브넷을 만들 수 있습니다.
지금 프록시 전용 서브넷을 만들려면 다음 단계를 사용합니다.
- Google Cloud 콘솔에서 VPC 네트워크 페이지로 이동합니다.
VPC 네트워크로 이동 - 공유 VPC 네트워크의 이름인
lb-network
를 클릭합니다. - 서브넷 추가를 클릭합니다.
- 이름에
proxy-only-subnet
를 입력합니다. - 리전에서
REGION_A
을 선택합니다. - 용도를 리전별 관리형 프록시로 설정합니다.
- IP 주소 범위에
10.129.0.0/23
을 입력합니다. - 추가를 클릭합니다.
gcloud
gcloud compute networks subnets
create
명령어로 프록시 전용 서브넷을 만듭니다.
gcloud compute networks subnets create proxy-only-subnet \ --purpose=REGIONAL_MANAGED_PROXY \ --role=ACTIVE \ --region=REGION_A \ --network=lb-network \ --range=10.129.0.0/23
방화벽 규칙 만들기
이 예시에서는 다음과 같은 방화벽 규칙이 필요합니다.
fw-allow-ssh
. 부하 분산되는 인스턴스에 적용되는 인그레스 규칙으로 TCP 포트22
에 임의의 주소로부터 수신되는 SSH 연결을 허용합니다. 이 규칙에 더 제한적인 소스 IP 범위를 선택할 수 있습니다. 예를 들어 SSH 세션을 시작할 시스템의 IP 범위만 지정할 수도 있습니다. 이 예시에서는 대상 태그allow-ssh
를 사용합니다.fw-allow-health-check
. 부하 분산되는 인스턴스에 적용되는 인그레스 규칙으로,130.211.0.0/22
및35.191.0.0/16
에서 Google Cloud 상태 점검 시스템의 모든 TCP 트래픽을 허용합니다. 이 예시에서는 대상 태그allow-health-check
를 사용합니다.fw-allow-proxy-only-subnet
. 프록시 전용 서브넷의 연결이 백엔드에 도달하도록 허용하는 인그레스 규칙입니다.
이러한 방화벽 규칙이 없으면 기본 거부 인그레스 규칙은 백엔드 인스턴스로 들어오는 트래픽을 차단합니다.
대상 태그는 백엔드 인스턴스를 정의합니다. 대상 태그가 없으면 VPC 네트워크의 모든 백엔드 인스턴스에 방화벽 규칙이 적용됩니다. 백엔드 VM을 만들 때는 관리형 인스턴스 그룹 만들기에 나온 대로 지정된 대상 태그를 포함해야 합니다.
콘솔
- Google Cloud 콘솔에서 방화벽 정책 페이지로 이동합니다.
방화벽 정책으로 이동 - 방화벽 규칙 만들기를 클릭하여 수신 SSH 연결을 허용하는 규칙을 만듭니다.
- 이름:
fw-allow-ssh
- 네트워크:
lb-network
- 트래픽 방향: 인그레스
- 일치 시 작업: 허용
- 대상: 지정된 대상 태그
- 대상 태그:
allow-ssh
- 소스 필터: IPv4 범위
- 소스 IPv4 범위:
0.0.0.0/0
- 프로토콜 및 포트:
- 지정된 프로토콜 및 포트를 선택합니다.
- TCP 체크박스를 선택한 후 포트 번호에
22
을 입력합니다.
- 이름:
- 만들기를 클릭합니다.
- 방화벽 규칙 만들기를 다시 한 번 클릭하여 Google Cloud 상태 점검을 허용하는 규칙을 만듭니다.
- 이름:
fw-allow-health-check
- 네트워크:
lb-network
- 트래픽 방향: 인그레스
- 일치 시 작업: 허용
- 대상: 지정된 대상 태그
- 대상 태그:
allow-health-check
- 소스 필터: IPv4 범위
- 소스 IPv4 범위:
130.211.0.0/22
및35.191.0.0/16
- 프로토콜 및 포트:
- 지정된 프로토콜 및 포트를 선택합니다.
- TCP 체크박스를 선택한 후 포트 번호에
80
을 입력합니다.
권장사항에 따라서 상태 점검에 사용되는 것과 일치하는 프로토콜 및 포트로 이러한 규칙을 제한합니다. 프로토콜 및 포트에tcp:80
을 사용하면 Google Cloud가 포트80
에서 HTTP를 사용하여 VM에 연결할 수 있지만 포트443
에서 HTTPS를 사용하여 연결할 수는 없습니다.
- 이름:
- 만들기를 클릭합니다.
- 방화벽 규칙 만들기를 세 번째로 클릭하여 부하 분산기의 프록시 서버를 백엔드에 연결하도록 허용하는 규칙을 만듭니다.
- 이름:
fw-allow-proxy-only-subnet
- 네트워크:
lb-network
- 트래픽 방향: 인그레스
- 일치 시 작업: 허용
- 대상: 지정된 대상 태그
- 대상 태그:
allow-proxy-only-subnet
- 소스 필터: IPv4 범위
- 소스 IPv4 범위:
10.129.0.0/23
- 프로토콜 및 포트:
- 지정된 프로토콜 및 포트를 선택합니다.
- TCP 체크박스를 선택한 다음 포트 번호로
80
을 입력합니다.
- 이름:
- 만들기를 클릭합니다.
gcloud
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 상태 점검을 허용합니다. 이 예시에서는 상태 점검 프로버의 모든 TCP 트래픽을 허용합니다. 그러나 필요에 따라 더 좁은 포트 집합을 구성할 수 있습니다.gcloud compute firewall-rules create fw-allow-health-check \ --network=lb-network \ --action=allow \ --direction=ingress \ --source-ranges=130.211.0.0/22,35.191.0.0/16 \ --target-tags=allow-health-check \ --rules=tcp:80
리전의 Envoy 프록시가 백엔드에 연결하도록 허용하는
fw-allow-proxy-only-subnet
규칙을 만듭니다.--source-ranges
를 프록시 전용 서브넷의 할당된 범위로 설정합니다(예:10.129.0.0/23
).gcloud compute firewall-rules create fw-allow-proxy-only-subnet \ --network=lb-network \ --action=allow \ --direction=ingress \ --source-ranges=10.129.0.0/23 \ --target-tags=allow-proxy-only-subnet \ --rules=tcp:80
부하 분산기의 IP 주소 예약
부하 분산기에 고정 내부 IP 주소를 예약하려면 새 고정 내부 IPv4 또는 IPv6 주소 예약을 참조하세요.
관리형 인스턴스 그룹 만들기
이 섹션에서는 부하 분산기의 REGION_A
리전에 2개의 관리형 인스턴스 그룹(MIG) 백엔드를 만드는 방법을 보여줍니다. MIG는 이 예시 리전 내부 프록시 네트워크 부하 분산기의 백엔드 Apache 서버를 실행하는 VM 인스턴스를 제공합니다.
일반적으로 리전 내부 프록시 네트워크 부하 분산기는 HTTP 트래픽에 사용되지 않지만 Apache 소프트웨어는 일반적으로 테스트용으로 사용됩니다.
콘솔
인스턴스 템플릿을 만듭니다. Google Cloud 콘솔에서 인스턴스 템플릿 페이지로 이동합니다.
- 인스턴스 템플릿 만들기를 클릭합니다.
- 이름에
int-tcp-proxy-backend-template
를 입력합니다. - 부팅 디스크가 Debian GNU/Linux 10(stretch)과 같은 Debian 이미지로 설정되었는지 확인합니다. 이 안내에서는
apt-get
처럼 Debian에서만 사용할 수 있는 명령어를 사용합니다. - 고급 옵션을 클릭합니다.
- 네트워킹을 클릭하고 다음 필드를 구성합니다.
- 네트워크 태그에
allow-ssh
,allow-health-check
,allow-proxy-only-subnet
을 입력합니다. - 네트워크 인터페이스에 다음을 선택합니다.
- 네트워크:
lb-network
- 서브넷:
backend-subnet
- 네트워크:
- 네트워크 태그에
관리를 클릭합니다. 시작 스크립트 필드에 다음 스크립트를 입력합니다.
#! /bin/bash apt-get update apt-get install apache2 -y a2ensite default-ssl a2enmod ssl vm_hostname="$(curl -H "Metadata-Flavor:Google" \ http://metadata.google.internal/computeMetadata/v1/instance/name)" echo "Page served from: $vm_hostname" | \ tee /var/www/html/index.html systemctl restart apache2
만들기를 클릭합니다.
관리형 인스턴스 그룹을 만듭니다. Google Cloud 콘솔에서 인스턴스 그룹 페이지로 이동합니다.
- 인스턴스 그룹 만들기를 클릭합니다.
- 새 관리형 인스턴스 그룹(스테이트리스(Stateless))을 선택합니다. 자세한 내용은 스테이트리스(Stateless) 또는 스테이트풀(Stateful) MIG를 참조하세요.
- 이름에
mig-a
를 입력합니다. - 위치에서 단일 영역을 선택합니다.
- 리전에서
REGION_A
을 선택합니다. - 영역에서
ZONE_A1
를 선택합니다. - 인스턴스 템플릿에서
int-tcp-proxy-backend-template
을 선택합니다. 그룹에 만들 인스턴스의 수를 지정합니다.
이 예시에서는 자동 확장에서 다음 옵션을 지정합니다.
- 자동 확장 모드에서
Off:do not autoscale
을 선택합니다. - 최대 인스턴스 수에
2
를 입력합니다.
- 자동 확장 모드에서
포트 매핑에서 포트 추가를 클릭합니다.
- 포트 이름에
tcp80
을 입력합니다. - 포트 번호에
80
을 입력합니다.
- 포트 이름에
만들기를 클릭합니다.
2단계를 반복하여 다음 설정으로 두 번째 관리형 인스턴스 그룹을 만듭니다.
- 이름:
mig-c
- 영역:
ZONE_A2
다른 모든 설정은 동일하게 유지합니다.
- 이름:
gcloud
이 가이드의 gcloud
안내에서는 Cloud Shell 또는 bash가 설치된 다른 환경을 사용한다고 가정합니다.
gcloud compute instance-templates create
명령어로 HTTP 서버가 포함된 VM 인스턴스 템플릿을 만듭니다.gcloud compute instance-templates create int-tcp-proxy-backend-template \ --region=REGION_A \ --network=lb-network \ --subnet=backend-subnet \ --tags=allow-ssh,allow-health-check,allow-proxy-only-subnet \ --image-family=debian-12 \ --image-project=debian-cloud \ --metadata=startup-script='#! /bin/bash apt-get update apt-get install apache2 -y a2ensite default-ssl a2enmod ssl vm_hostname="$(curl -H "Metadata-Flavor:Google" \ http://metadata.google.internal/computeMetadata/v1/instance/name)" echo "Page served from: $vm_hostname" | \ tee /var/www/html/index.html systemctl restart apache2'
ZONE_A1
영역에 관리형 인스턴스 그룹을 만듭니다.gcloud compute instance-groups managed create mig-a \ --zone=ZONE_A1 \ --size=2 \ --template=int-tcp-proxy-backend-template
ZONE_A1을 대상 Google Cloud 리전의 영역 이름으로 바꿉니다.
ZONE_A2
영역에 관리형 인스턴스 그룹을 만듭니다.gcloud compute instance-groups managed create mig-c \ --zone=ZONE_A2 \ --size=2 \ --template=int-tcp-proxy-backend-template
ZONE_A2를 대상 Google Cloud 리전의 다른 영역 이름으로 바꿉니다.
부하 분산기 구성
콘솔
구성 시작
Google Cloud 콘솔에서 부하 분산 페이지로 이동합니다.
- 부하 분산기 만들기를 클릭합니다.
- 부하 분산기 유형에 네트워크 부하 분산기(TCP/UDP/SSL)를 선택하고 다음을 클릭합니다.
- 프록시 또는 패스 스루에 프록시 부하 분산기를 선택하고 다음을 클릭합니다.
- 공개 또는 내부에 내부를 선택하고 다음을 클릭합니다.
- 리전 간 또는 단일 리전 배포에 리전 워크로드에 적합을 선택하고 다음을 클릭합니다.
- 구성을 클릭합니다.
기본 구성
- 이름에
my-int-tcp-lb
을 입력합니다. - 리전에서
REGION_A
을 선택합니다. - 네트워크에서
lb-network
를 선택합니다.
프록시 전용 서브넷 예약
프록시 전용 서브넷을 예약하려면 다음 안내를 따르세요.
- 서브넷 예약을 클릭합니다.
- 이름에
proxy-only-subnet
를 입력합니다. - IP 주소 범위에
10.129.0.0/23
을 입력합니다. - 추가를 클릭합니다.
백엔드 구성
- 백엔드 구성을 클릭합니다.
- 백엔드 유형에서 인스턴스 그룹을 선택합니다.
- 프로토콜에서 TCP를 선택합니다.
- 이름이 지정된 포트에
tcp80
를 입력합니다. - 첫 번째 백엔드를 구성합니다.
- 새 백엔드에서 인스턴스 그룹
mig-a
을 선택합니다. - 포트 번호에
80
을 입력합니다. - 남은 기본값은 그대로 두고 완료를 클릭합니다.
- 새 백엔드에서 인스턴스 그룹
- 두 번째 백엔드를 구성합니다.
- 백엔드 추가를 클릭합니다.
- 새 백엔드에서 인스턴스 그룹
mig-c
을 선택합니다. - 포트 번호에
80
을 입력합니다. - 남은 기본값은 그대로 두고 완료를 클릭합니다.
- 상태 점검을 구성합니다.
- 상태 점검에서 상태 점검 만들기를 선택합니다.
- 상태 점검 이름을
tcp-health-check
로 설정합니다. - 프로토콜에서 TCP를 선택합니다.
- 포트를
80
으로 설정합니다.
- 남은 기본값은 그대로 두고 저장을 클릭합니다.
- Google Cloud 콘솔에서 백엔드 구성 옆에 체크표시가 있는지 확인합니다. 없으면 모든 단계를 완료했는지 다시 확인합니다.
프런트엔드 구성
- 프런트엔드 구성을 클릭합니다.
- 이름에
int-tcp-forwarding-rule
를 입력합니다. - 서브네트워크에서 backend-subnet을 선택합니다.
- IP 주소에서 이전에 예약한 IP 주소를 선택합니다. LB_IP_ADDRESS
- 포트 번호에
110
을 입력합니다. 전달 규칙은 목적지 포트가 일치하는 패킷만 전달합니다. - 이 예시에서는 프록시 프로토콜이 Apache HTTP 서버 소프트웨어에서 작동하지 않으므로 프록시 프로토콜을 사용 설정하지 마세요. 자세한 내용은 프록시 프로토콜을 참조하세요.
- 완료를 클릭합니다.
- Google Cloud 콘솔에서 프런트엔드 구성 옆에 체크표시가 있는지 확인합니다. 없으면 이전 단계를 모두 완료했는지 다시 확인합니다.
검토 및 완료
- 검토 및 완료를 클릭합니다.
- 부하 분산기 구성 설정을 검토합니다.
- 선택사항: 부하 분산기를 만드는 데 사용되는 REST API 요청을 보려면 상응하는 코드를 클릭합니다.
- 만들기를 클릭합니다.
gcloud
리전 상태 점검을 만듭니다.
gcloud compute health-checks create tcp tcp-health-check \ --region=REGION_A \ --use-serving-port
백엔드 서비스를 만듭니다.
gcloud compute backend-services create internal-tcp-proxy-bs \ --load-balancing-scheme=INTERNAL_MANAGED \ --protocol=TCP \ --region=REGION_A \ --health-checks=tcp-health-check \ --health-checks-region=REGION_A
백엔드 서비스에 인스턴스 그룹을 추가합니다.
gcloud compute backend-services add-backend internal-tcp-proxy-bs \ --region=REGION_A \ --instance-group=mig-a \ --instance-group-zone=ZONE_A1 \ --balancing-mode=UTILIZATION \ --max-utilization=0.8
gcloud compute backend-services add-backend internal-tcp-proxy-bs \ --region=REGION_A \ --instance-group=mig-c \ --instance-group-zone=ZONE_A2 \ --balancing-mode=UTILIZATION \ --max-utilization=0.8
내부 대상 TCP 프록시를 만듭니다.
gcloud compute target-tcp-proxies create int-tcp-target-proxy \ --backend-service=internal-tcp-proxy-bs \ --proxy-header=NONE \ --region=REGION_A
프록시 헤더를 사용 설정하려면
NONE
대신PROXY_V1
로 설정합니다. 이 예시에서는 프록시 프로토콜이 Apache HTTP 서버 소프트웨어에서 작동하지 않으므로 프록시 프로토콜을 사용 설정하지 마세요. 자세한 내용은 프록시 프로토콜을 참조하세요.전달 규칙을 만듭니다.
--ports
의 경우 1~65535에서 단일 포트 번호를 지정합니다. 이 예시에서는 포트110
을 사용합니다. 전달 규칙은 대상 포트가 일치하는 패킷만 전달합니다.gcloud compute forwarding-rules create int-tcp-forwarding-rule \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=lb-network \ --subnet=backend-subnet \ --region=REGION_A \ --target-tcp-proxy=int-tcp-target-proxy \ --target-tcp-proxy-region=REGION_A \ --address=int-tcp-ip-address \ --ports=110
부하 분산기 테스트
부하 분산기를 테스트하려면 부하 분산기와 동일한 리전에 클라이언트 VM을 만듭니다. 그런 다음 클라이언트에서 부하 분산기로 트래픽을 전송합니다.
클라이언트 VM 만들기
부하 분산기와 동일한 리전에서 클라이언트 VM(client-vm
)을 만듭니다.
콘솔
Google Cloud 콘솔에서 VM 인스턴스 페이지로 이동합니다.
인스턴스 만들기를 클릭합니다.
이름을
client-vm
으로 설정합니다.영역을
ZONE_A1
로 설정합니다.고급 옵션을 클릭합니다.
네트워킹을 클릭하고 다음 필드를 구성합니다.
- 네트워크 태그에
allow-ssh
를 입력합니다. - 네트워크 인터페이스에 다음을 선택합니다.
- 네트워크:
lb-network
- 서브넷:
backend-subnet
- 네트워크:
- 네트워크 태그에
만들기를 클릭합니다.
gcloud
클라이언트 VM은 부하 분산기와 동일한 VPC 네트워크 및 리전에 있어야 합니다. 동일한 서브넷 또는 영역에는 있지 않아도 됩니다. 클라이언트는 백엔드 VM과 동일한 서브넷을 사용합니다.
gcloud compute instances create client-vm \ --zone=ZONE_A1 \ --image-family=debian-12 \ --image-project=debian-cloud \ --tags=allow-ssh \ --subnet=backend-subnet
부하 분산기로 트래픽 전송
부하 분산기를 구성했으므로 부하 분산기의 IP 주소로 트래픽 전송을 테스트할 수 있습니다.
SSH를 사용하여 클라이언트 인스턴스에 연결합니다.
gcloud compute ssh client-vm \ --zone=ZONE_A1
부하 분산기가 백엔드 호스트 이름을 정상적으로 제공하고 있는지 확인합니다.
compute addresses describe
명령어를 사용하여 부하 분산기의 IP 주소를 확인합니다.gcloud compute addresses describe int-tcp-ip-address \ --region=REGION_A
IP 주소를 기록해 둡니다.
부하 분산기로 트래픽 전송 IP_ADDRESS를 부하 분산기의 IP 주소로 바꿉니다.
curl IP_ADDRESS:110
추가 구성 옵션
이 섹션에서는 대체 및 추가 구성 옵션을 제공하는 구성 예시를 살펴봅니다. 모든 태스크는 선택사항입니다. 원하는 순서대로 수행할 수 있습니다.
전역 액세스 사용 설정
부하 분산기의 전역 액세스를 사용 설정하여 모든 리전의 클라이언트가 액세스할 수 있게 할 수 있습니다. 예시 부하 분산기의 백엔드는 계속 리전 하나(REGION_A
)에 있어야 합니다.
전역 액세스를 사용 설정하기 위해 기존 리전 전달 규칙을 수정할 수 없습니다. 이 용도의 새 전달 규칙을 만들어야 합니다. 또한 전역 액세스가 사용 설정된 전달 규칙을 만든 후에는 이 규칙을 수정할 수 없습니다. 전역 액세스를 중지하려면 새 리전 액세스 전달 규칙을 만들고 이전 전역 액세스 전달 규칙을 삭제해야 합니다.
전역 액세스를 구성하려면 다음과 같이 구성을 변경합니다.
콘솔
부하 분산기에 새로운 전달 규칙을 만듭니다.
Google Cloud 콘솔에서 부하 분산 페이지로 이동합니다.
이름 열에서 부하 분산기를 클릭합니다.
프런트엔드 구성을 클릭합니다.
프런트엔드 IP 및 포트 추가를 클릭합니다.
새 전달 규칙의 이름과 서브넷 세부정보를 입력합니다.
서브네트워크에서 backend-subnet을 선택합니다.
IP 주소에서 기존 전달 규칙과 동일한 IP 주소를 선택하거나 새 IP 주소를 예약하거나 임시 IP 주소를 사용할 수 있습니다. IP 주소를 만드는 동안 IP 주소
--purpose
플래그를SHARED_LOADBALANCER_VIP
로 설정한 경우에만 여러 전달 규칙에서 동일한 IP 주소를 공유할 수 있습니다.포트 번호에
110
을 입력합니다.전역 액세스에 사용 설정을 선택합니다.
완료를 클릭합니다.
업데이트를 클릭합니다.
gcloud
--allow-global-access
플래그를 사용하여 부하 분산기의 새 전달 규칙을 만듭니다.gcloud compute forwarding-rules create int-tcp-forwarding-rule-global-access \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=lb-network \ --subnet=backend-subnet \ --region=REGION_A \ --target-tcp-proxy=int-tcp-target-proxy \ --target-tcp-proxy-region=REGION_A \ --address=int-tcp-ip-address \ --ports=110 \ --allow-global-access
gcloud compute forwarding-rules describe
명령어를 사용하여 전달 규칙에 전역 액세스가 사용 설정되어 있는지 확인할 수 있습니다. 예를 들면 다음과 같습니다.gcloud compute forwarding-rules describe int-tcp-forwarding-rule-global-access \ --region=REGION_A \ --format="get(name,region,allowGlobalAccess)"
전역 액세스가 사용 설정되면 출력에서 전달 규칙의 이름과 리전 뒤에
True
단어가 표시됩니다.
전역 액세스를 테스트하도록 클라이언트 VM 만들기
콘솔
Google Cloud 콘솔에서 VM 인스턴스 페이지로 이동합니다.
인스턴스 만들기를 클릭합니다.
이름을
test-global-access-vm
으로 설정합니다.영역을
ZONE_B1
로 설정합니다.고급 옵션을 클릭합니다.
네트워킹을 클릭하고 다음 필드를 구성합니다.
- 네트워크 태그에
allow-ssh
를 입력합니다. - 네트워크 인터페이스에 다음을 선택합니다.
- 네트워크:
lb-network
- 서브넷:
test-global-access-subnet
- 네트워크:
- 네트워크 태그에
만들기를 클릭합니다.
gcloud
ZONE_B1
영역에 클라이언트 VM을 만듭니다.
gcloud compute instances create test-global-access-vm \ --zone=ZONE_B1 \ --image-family=debian-12 \ --image-project=debian-cloud \ --tags=allow-ssh \ --subnet=test-global-access-subnet
ZONE_B1을 REGION_B 리전의 영역 이름으로 바꿉니다.
클라이언트 VM에 연결 및 연결 테스트
ssh
를 사용하여 클라이언트 인스턴스에 연결합니다.gcloud compute ssh test-global-access-vm \ --zone=ZONE_B1
gcloud compute addresses describe
명령어를 사용하여 부하 분산기의 IP 주소를 가져옵니다.gcloud compute addresses describe int-tcp-ip-address \ --region=REGION_A
IP 주소를 기록해 둡니다.
트래픽을 부하 분산기로 전송하고 IP_ADDRESS를 부하 분산기의 IP 주소로 바꿉니다.
curl IP_ADDRESS:110
클라이언트 연결 정보를 유지하기 위한 프록시 프로토콜
프록시 네트워크 부하 분산기는 클라이언트의 TCP 연결을 종료하고 인스턴스에 새 연결을 만듭니다. 기본적으로 원래 클라이언트 IP와 포트 정보는 유지되지 않습니다.
원래 연결 정보를 유지하고 인스턴스로 보내려면 PROXY 프로토콜 버전 1을 사용 설정합니다. 이 프로토콜은 요청의 일부로 소스 IP 주소, 대상 IP 주소, 포트 번호가 포함된 추가 헤더를 인스턴스에 보냅니다.
프록시 네트워크 부하 분산기의 백엔드 인스턴스에서 PROXY 프로토콜 헤더를 지원하는 서버를 실행하고 있는지 확인합니다. 서버가 PROXY 프로토콜 헤더를 지원하도록 구성되지 않았으면 백엔드 인스턴스에서 빈 응답을 반환합니다.
사용자 트래픽에 PROXY 프로토콜을 설정한 경우 상태 점검에도 이 프로토콜을 설정할 수 있습니다. 동일한 포트에서 상태를 점검하고 콘텐츠를 제공하는 경우 상태 점검의 --proxy-header
를 부하 분산기 설정에 맞게 설정합니다.
일반적으로 PROXY 프로토콜 헤더는 다음 형식의 사용자가 읽을 수 있는 한 줄 텍스트입니다.
PROXY TCP4 <client IP> <load balancing IP> <source port> <dest port>\r\n
다음 예시에서는 PROXY 프로토콜을 보여줍니다.
PROXY TCP4 192.0.2.1 198.51.100.1 15221 110\r\n
앞의 예시에서 클라이언트 IP는 192.0.2.1
, 부하 분산 IP는 198.51.100.1
, 클라이언트 포트는 15221
, 목적지 포트는 110
입니다.
클라이언트 IP를 모르는 경우 부하 분산기는 다음 형식으로 PROXY 프로토콜 헤더를 생성합니다.
PROXY UNKNOWN\r\n
대상 프록시의 PROXY 프로토콜 헤더 업데이트
기존 대상 프록시에서 PROXY 프로토콜 헤더를 업데이트할 수 없습니다. PROXY 프로토콜 헤더에 필요한 설정으로 새 대상 프록시를 만들어야 합니다. 다음 단계를 따라 필요한 설정으로 새 프런트엔드를 만듭니다.
콘솔
Google Cloud 콘솔에서 부하 분산 페이지로 이동합니다.
- 수정할 부하 분산기의 이름을 클릭합니다.
- 부하 분산기의 편집을 클릭합니다.
- 프런트엔드 구성을 클릭합니다.
- 이전 프런트엔드 IP 및 포트를 삭제합니다.
- 프런트엔드 IP 및 포트 추가를 클릭합니다.
- 이름에
int-tcp-forwarding-rule
을 입력합니다. - 서브네트워크에서 backend-subnet을 선택합니다.
- IP 주소에서 이전에 예약한 IP 주소를 선택합니다. LB_IP_ADDRESS
- 포트 번호에
110
을 입력합니다. 전달 규칙은 목적지 포트가 일치하는 패킷만 전달합니다. - 프록시 프로토콜 필드 값을 켜기로 변경합니다.
- 완료를 클릭합니다.
- 이름에
- 업데이트를 클릭하여 변경사항을 저장합니다.
gcloud
다음 명령어에서
--proxy-header
필드를 수정하고 요구사항에 따라NONE
또는PROXY_V1
로 설정합니다.gcloud compute target-tcp-proxies create TARGET_PROXY_NAME \ --backend-service=BACKEND_SERVICE \ --proxy-header=[NONE | PROXY_V1] \ --region=REGION
기존 전달 규칙을 삭제합니다.
gcloud compute forwarding-rules delete int-tcp-forwarding-rule \ --region=REGION
새 전달 규칙을 만들어 대상 프록시와 연결합니다.
gcloud compute forwarding-rules create int-tcp-forwarding-rule \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=lb-network \ --subnet=backend-subnet \ --region=REGION \ --target-tcp-proxy=TARGET_PROXY_NAME \ --target-tcp-proxy-region=REGION \ --address=LB_IP_ADDRESS \ --ports=110
세션 어피니티 사용 설정
구성 예시는 세션 어피니티 없이 백엔드 서비스를 만듭니다.
이 절차에서는 백엔드 서비스가 클라이언트 IP 어피니티 또는 생성된 쿠키 어피니티를 사용하도록 예시 리전 내부 프록시 네트워크 부하 분산기의 백엔드 서비스를 업데이트하는 방법을 보여줍니다.
클라이언트 IP 어피니티가 사용 설정되면 부하 분산기는 클라이언트의 IP 주소 및 부하 분산기의 IP 주소(내부 전달 규칙의 내부 IP 주소)에서 생성된 해시를 기반으로 특정 클라이언트의 요청을 동일한 백엔드 VM에 전달합니다.
콘솔
클라이언트 IP 세션 어피니티를 사용 설정하려면 다음 안내를 따르세요.
- Google Cloud 콘솔에서 부하 분산 페이지로 이동합니다.
부하 분산으로 이동 - 백엔드를 클릭합니다.
- internal-tcp-proxy-bs(이 예시에서 만든 백엔드 서비스 이름)를 클릭하고 수정을 클릭합니다.
- 백엔드 서비스 세부정보 페이지에서 고급 구성을 클릭합니다.
- 세션 어피니티의 메뉴에서 클라이언트 IP를 선택합니다.
- 업데이트를 클릭합니다.
gcloud
다음 Google Cloud CLI 명령어를 사용해서 internal-tcp-proxy-bs
백엔드 서비스를 업데이트하고 클라이언트 IP 세션 어피니티를 지정합니다.
gcloud compute backend-services update internal-tcp-proxy-bs \ --region=REGION_A \ --session-affinity=CLIENT_IP
연결 드레이닝 사용 설정
백엔드 서비스에서 연결 드레이닝을 사용 설정하면 트래픽을 제공하는 인스턴스가 종료되거나 수동으로 삭제되거나 자동 확장 처리를 통해 삭제되는 경우 사용자에 대한 방해를 최소화할 수 있습니다. 연결 드레이닝에 대한 자세한 내용은 연결 드레이닝 사용 설정 문서를 참조하세요.