백엔드 서비스는 Cloud Load Balancing이 트래픽을 분산하는 방법을 정의합니다. 백엔드 서비스 구성에는 백엔드에 연결하는 데 사용되는 프로토콜, 다양한 배포 및 세션 설정, 상태 점검, 제한 시간 등의 다양한 값 집합이 포함됩니다. 이 설정은 부하 분산기의 동작을 세부적으로 제어할 수 있습니다. 시작하는 데 도움이 될 수 있도록 대부분의 설정은 빠른 구성을 위한 기본값을 포함합니다. 백엔드 서비스의 범위는 전역 또는리전입니다.
부하 분산기, Envoy 프록시, 프록시리스 gRPC 클라이언트는 백엔드 서비스 리소스의 구성 정보를 사용하여 다음을 수행합니다.
- 올바른 백엔드(인스턴스 그룹 또는 네트워크 엔드포인트 그룹(NEG))로 트래픽 전달.
- 각 백엔드의 설정인 분산 모드에 따라 트래픽을 분산.
- 백엔드 상태를 모니터링할 상태 점검 결정.
- 세션 어피니티 지정.
- 특정 부하 분산기에만 사용할 수 있는 다음 서비스를 포함하여 기타 서비스가 사용 설정되었는지 확인합니다.
- Cloud CDN
- Google Cloud Armor 보안 정책
- IAP(Identity-Aware Proxy)
- 리전 백엔드 서비스를 미리보기 버전인 App Hub에서 서비스로 지정합니다.
백엔드 서비스를 만들거나 백엔드 서비스에 백엔드를 추가할 때 이러한 값을 설정합니다.
참고: 외부 애플리케이션 부하 분산기 또는 기본 애플리케이션 부하 분산기를 사용 중이고 백엔드가 정적 콘텐츠를 제공하는 경우 백엔드 서비스 대신 백엔드 버킷을 사용하는 것이 좋습니다. 전역 외부 애플리케이션 부하 분산기의 백엔드 버킷 또는 기존 애플리케이션 부하 분산기의 백엔드 버킷을 참고하세요.다음 표에는 백엔드 서비스를 사용하는 부하 분산기가 요약되어 있습니다. 사용 중인 제품에 따라 백엔드 서비스의 최대 개수, 백엔드 서비스의 범위, 지원되는 백엔드 유형, 백엔드 서비스의 부하 분산 스키마도 결정됩니다. 부하 분산 스키마는 Google에서 전달 규칙과 백엔드 서비스를 분류하는 데 사용하는 식별자입니다. 각 부하 분산 제품은 전달 규칙과 백엔드 서비스에 하나의 부하 분산 스키마를 사용합니다. 일부 스키마는 제품 간에 공유됩니다.
| 제품 | 최대 백엔드 서비스 개수 | 백엔드 서비스 범위 | 지원되는 백엔드 유형 | 부하 분산 스키마 |
|---|---|---|---|---|
| 전역 외부 애플리케이션 부하 분산기 | 다수 | 전역 | 각 백엔드 서비스는 다음 백엔드 조합 중 하나를 지원합니다.
|
EXTERNAL_MANAGED |
| 기본 애플리케이션 부하 분산기 | 다수 | 전 세계‡ | 각 백엔드 서비스는 다음 백엔드 조합 중 하나를 지원합니다.
|
외부# |
| 리전 외부 애플리케이션 부하 분산기 | 다수 | 리전 | 각 백엔드 서비스는 다음 백엔드 조합 중 하나를 지원합니다.
|
EXTERNAL_MANAGED |
| 리전 간 내부 애플리케이션 부하 분산기 | 다수 | 전역 | 각 백엔드 서비스는 다음 백엔드 조합 중 하나를 지원합니다.
|
INTERNAL_MANAGED |
| 리전별 내부 애플리케이션 부하 분산기 | 다수 | 리전 | 각 백엔드 서비스는 다음 백엔드 조합 중 하나를 지원합니다.
|
INTERNAL_MANAGED |
| 전역 외부 프록시 네트워크 부하 분산기 | 1 | 전 세계‡ | 백엔드 서비스는 다음 백엔드 조합 중 하나를 지원합니다.
|
EXTERNAL_MANAGED |
| 기본 프록시 네트워크 부하 분산기 | 1 | 전 세계‡ | 백엔드 서비스는 다음 백엔드 조합 중 하나를 지원합니다.
|
외부 |
| 리전 외부 프록시 네트워크 부하 분산기 | 1 | 리전 | 백엔드 서비스는 다음 백엔드 조합 중 하나를 지원합니다. | EXTERNAL_MANAGED |
| 리전 내부 프록시 네트워크 부하 분산기 | 1 | 리전 | 백엔드 서비스는 다음 백엔드 조합 중 하나를 지원합니다. | INTERNAL_MANAGED |
| 리전 간 내부 프록시 네트워크 부하 분산기 | 다수 | 전역 | 백엔드 서비스는 다음 백엔드 조합 중 하나를 지원합니다.
|
INTERNAL_MANAGED |
| 외부 패스 스루 네트워크 부하 분산기 | 1 | 리전 | 백엔드 서비스는 다음 백엔드 조합 중 하나를 지원합니다.
|
외부 |
| 내부 패스 스루 네트워크 부하 분산기 | 1 | 리전이지만전역으로 액세스할 수 있도록 구성 가능 | 백엔드 서비스는 다음 백엔드 조합 중 하나를 지원합니다.
|
내부 |
| Cloud Service Mesh | 다수 | 전역 | 각 백엔드 서비스는 다음 백엔드 조합 중 하나를 지원합니다.
|
INTERNAL_SELF_MANAGED |
GCE_VM_IP_PORT 유형 엔드포인트에서만 이중 스택을 지원합니다.
- 전달 규칙 및 외부 IP 주소는 리전입니다.
- 백엔드 서비스에 연결된 모든 백엔드는 전달 규칙과 동일한 리전에 있어야 합니다.
EXTERNAL_MANAGED 백엔드 서비스를 EXTERNAL 전달 규칙에 연결할 수 있습니다. 그러나 EXTERNAL 백엔드 서비스는 EXTERNAL_MANAGED 전달 규칙에 연결할 수 없습니다.
전역 외부 애플리케이션 부하 분산기에서만 사용할 수 있는 새로운 기능을 활용하려면 기존 애플리케이션 부하 분산기에서 전역 외부 애플리케이션 부하 분산기로 리소스 이전에 설명된 이전 프로세스를 사용하여 기존 EXTERNAL 리소스를 EXTERNAL_MANAGED로 이전하는 것이 좋습니다.
백엔드
백엔드는 Google Cloud 부하 분산기, Cloud Service Mesh 구성 Envoy 프록시 또는 프록시리스 gRPC 클라이언트에서 트래픽을 수신하는 하나 이상의 엔드포인트입니다. 다음과 같이 여러 가지 유형의 백엔드가 있습니다.
- 가상 머신(VM) 인스턴스를 포함하는 인스턴스 그룹. 인스턴스 그룹은 자동 확장 여부에 관계없이 관리형 인스턴스 그룹(MIG)이거나 비관리형 인스턴스 그룹일 수 있습니다. 둘 이상의 백엔드 서비스에서 하나의 인스턴스 그룹을 참조할 수 있지만 인스턴스 그룹을 참조하는 모든 백엔드 서비스에서 동일한 분산 모드를 사용해야 합니다.
- 영역별 NEG
- 서버리스 NEG
- 인터넷 NEG
- 하이브리드 연결 NEG
- Private Service Connect NEG
- 포트 매핑 NEG
- 서비스 디렉터리 서비스 결합
백엔드 서비스와 연결된 백엔드 인스턴스 그룹 또는 NEG를 삭제할 수 없습니다. 인스턴스 그룹 또는 NEG를 삭제하기 전에 먼저 이를 참조하는 모든 백엔드 서비스에서 백엔드로 삭제해야 합니다.
인스턴스 그룹
이 섹션에서는 인스턴스 그룹이 백엔드 서비스와 작동하는 방식을 설명합니다.
백엔드 VM 및 외부 IP 주소
백엔드 서비스의 백엔드 VM에는 외부 IP 주소가 필요하지 않습니다.
- 전역 외부 애플리케이션 부하 분산기 및 외부 프록시 네트워크 부하 분산기: 클라이언트는 부하 분산기의 외부 IP 주소를 호스팅하는 Google 프런트엔드(GFE)와 통신합니다. GFE는 백엔드 VPC 네트워크의 식별자를 백엔드의 내부 IPv4 주소와 조인하여 생성된 내부 주소로 패킷을 전송하여 백엔드 VM 또는 엔드포인트와 통신합니다. 특수 경로를 통해 GFE와 백엔드 VM 또는 엔드포인트 간의 통신을 용이하게 합니다.
- 인스턴스 그룹 백엔드의 경우 내부 IPv4 주소는 항상 VM의
nic0인터페이스에 해당하는 기본 내부 IPv4 주소입니다. - 영역별 NEG의
GCE_VM_IP_PORT엔드포인트의 경우, 엔드포인트의 IP 주소를 VM의 네트워크 인터페이스와 연결된 기본 IPv4 주소로 지정하거나 VM의 네트워크 인터페이스와 연결된 별칭 IP 주소 범위의 모든 IPv4 주소로 지정할 수 있습니다.
- 인스턴스 그룹 백엔드의 경우 내부 IPv4 주소는 항상 VM의
리전별 외부 애플리케이션 부하 분산기의 경우: 클라이언트는 부하 분산기의 외부 IP 주소를 호스팅하는 Envoy 프록시와 통신합니다. Envoy 프록시는 백엔드 VPC 네트워크의 식별자를 백엔드의 내부 IPv4 주소와 조인하여 생성된 내부 주소로 패킷을 전송하여 백엔드 VM 또는 엔드포인트와 통신합니다.
- 인스턴스 그룹 백엔드의 경우 내부 IPv4 주소는 항상 VM의
nic0인터페이스에 해당하는 기본 내부 IPv4 주소이며,nic0은 부하 분산기와 동일한 네트워크에 있어야 합니다. - 영역별 NEG에 있는
GCE_VM_IP_PORT엔드포인트의 경우 네트워크 인터페이스가 부하 분산기와 동일한 네트워크에 있는 한 엔드포인트의 IP 주소를 VM의 네트워크 인터페이스와 연결된 기본 IPv4 주소로 지정하거나 VM의 네트워크 인터페이스와 연결된 별칭 IP 주소 범위의 IPv4 주소로 지정할 수 있습니다.
- 인스턴스 그룹 백엔드의 경우 내부 IPv4 주소는 항상 VM의
외부 패스 스루 네트워크 부하 분산기의 경우: 클라이언트는 Google의 Maglev 패스 스루 부하 분산 인프라를 통해 백엔드와 직접 통신합니다. 패킷이 원본 소스 및 대상 IP 주소가 보존된 백엔드로 라우팅 및 전달됩니다. 백엔드는 직접 서버 반환을 사용하여 클라이언트에 응답합니다. 백엔드를 선택하고 연결을 추적하는 데 사용되는 방법은 구성 가능합니다.
- 인스턴스 그룹 백엔드의 경우 패킷이 항상 VM의
nic0인터페이스에 전달됩니다. - 영역별 NEG에 있는
GCE_VM_IP엔드포인트의 경우 NEG와 연결된 서브네트워크에 있는 VM의 네트워크 인터페이스로 패킷이 전달됩니다.
- 인스턴스 그룹 백엔드의 경우 패킷이 항상 VM의
이름이 지정된 포트
백엔드 서비스의 이름이 지정된 포트 속성은 인스턴스 그룹 백엔드를 사용하는 프록시 기반 부하 분산기 (애플리케이션 부하 분산기 및 프록시 네트워크 부하 분산기)에만 적용됩니다. 이름이 지정된 포트는 프록시 (GFE 또는 Envoy)와 백엔드 인스턴스 간의 TCP 연결에 사용되는 대상 포트를 정의합니다.
이름이 지정된 포트는 다음과 같이 구성됩니다.
각 인스턴스 그룹 백엔드에서 키-값 쌍을 사용하여 이름이 지정된 포트를 하나 이상 구성해야 합니다. 키는 선택한 의미 있는 포트 이름을 나타내며 값은 이름에 할당한 포트 번호를 나타냅니다. 숫자에 대한 이름 매핑은 각 인스턴스 그룹 백엔드에 대해 개별적으로 수행됩니다.
백엔드 서비스에서 포트 이름(
--port-name)만 사용하여 이름이 지정된 단일 포트를 지정합니다.
인스턴스별 그룹 백엔드 기준에 따라 백엔드 서비스는 포트 이름을 포트 번호로 변환합니다. 인스턴스 그룹의 이름이 지정된 포트가 백엔드 서비스의 --port-name과 일치하는 경우, 백엔드 서비스는 인스턴스 그룹의 VM과 통신하기 위해 이 포트 번호를 사용합니다.
예를 들어 이름이 my-service-name이고 포트 8888인 인스턴스 그룹에 이름이 지정된 포트를 설정할 수 있습니다.
gcloud compute instance-groups unmanaged set-named-ports my-unmanaged-ig \
--named-ports=my-service-name:8888
그런 다음 백엔드 서비스의 --port-name이 my-service-name으로 설정된 백엔드 서비스 구성의 이름이 지정된 포트를 참조합니다.
gcloud compute backend-services update my-backend-service \
--port-name=my-service-name
각 인스턴스 그룹이 동일한 포트 이름에 대해 다른 포트 번호를 지정하는 경우 백엔드 서비스는 다른 인스턴스 그룹의 VM과 통신할 때 다른 포트 번호를 사용할 수 있습니다.
프록시 부하 분산기의 백엔드 서비스에서 사용하는 확인된 포트 번호는 부하 분산기의 전달 규칙에서 사용하는 포트 번호와 일치하지 않아도 됩니다. 프록시 부하 분산기는 전달 규칙의 IP 주소와 대상 포트로 전송된 TCP 연결을 리슨합니다. 프록시는 백엔드에 대한 두 번째 TCP 연결을 열기 때문에 두 번째 TCP 연결의 대상 포트는 다를 수 있습니다.
이름이 지정된 포트는 인스턴스 그룹 백엔드에만 적용됩니다. GCE_VM_IP_PORT 엔드포인트가 있는 영역별 NEG, NON_GCP_PRIVATE_IP_PORT 엔드포인트가 있는 하이브리드 NEG, 인터넷 NEG는 엔드포인트 자체에서 다른 메커니즘을 사용하여 포트를 정의합니다. 목적지 포트를 지정하지 않아도 되는 추상화를 사용하여 서버리스 NEG는 Google 서비스를 참조하고 PSC NEG는 서비스 연결을 참조합니다.
내부 패스 스루 네트워크 부하 분산기 및 외부 패스 스루 네트워크 부하 분산기는 이름이 지정된 포트를 사용하지 않습니다. 이는 새 연결을 만드는 대신 연결을 백엔드로 직접 라우팅하는 패스 스루 부하 분산기이기 때문입니다. 패킷이 부하 분산기 전달 규칙의 대상 IP 주소와 포트를 보존하는 백엔드로 전달됩니다.
이름이 지정된 포트를 만드는 방법은 다음 안내를 참조하세요.
- 비관리형 인스턴스 그룹: 이름이 지정된 포트 작업
- 관리형 인스턴스 그룹: 관리형 인스턴스 그룹에 이름이 지정된 포트 할당
인스턴스 그룹에 대한 제한 및 지침
부하 분산기의 인스턴스 그룹을 만들 때 다음과 같은 제한사항 및 안내 사항에 유의하세요.
VM을 두 개 이상의 부하 분산 인스턴스 그룹에 넣지 않습니다. VM이 2개 이상의 비관리형 인스턴스 그룹의 구성원이거나 하나의 관리형 인스턴스 그룹과 하나 이상의 비관리형 인스턴스 그룹의 구성원인 경우, Google Cloud에는 해당 인스턴스 그룹 중 하나만 특정 백엔드 서비스의 백엔드로 사용할 수 있는 제약이 있습니다.
VM이 여러 부하 분산기에 참여해야 하는 경우 각 백엔드 서비스의 백엔드와 동일한 인스턴스 그룹을 사용해야 합니다.
프록시 부하 분산기의 경우 트래픽을 다른 포트로 분산하려면 하나의 인스턴스 그룹에 필요한 이름이 지정된 포트를 지정하고 각 백엔드 서비스가 고유한 이름이 지정된 포트를 구독하도록 합니다.
백엔드 서비스 두 개 이상의 백엔드로 동일한 인스턴스 그룹을 사용할 수 있습니다. 이 경우 백엔드가 호환되는 분산 모드를 사용해야 합니다. 호환은 분산 모드가 동일하거나
CONNECTION과RATE의 조합이어야 함을 의미합니다.호환되지 않는 분산 모드 조합은 다음과 같습니다.
CONNECTION(UTILIZATION포함)RATE(UTILIZATION포함)
다음 예시를 참조하세요.
- 외부 애플리케이션 부하 분산기의 경우
external-https-backend-service, 내부 패스 스루 네트워크 부하 분산기의 경우internal-tcp-backend-service등 백엔드 서비스 두 개가 있습니다. internal-tcp-backend-service에서instance-group-a라고 하는 인스턴스 그룹을 사용하고 있습니다.- 내부 패스 스루 네트워크 부하 분산기는
CONNECTION분산 모드만 지원하므로internal-tcp-backend-service에서는CONNECTION분산 모드를 적용해야 합니다. external-https-backend-service에서RATE분산 모드를 적용하는 경우external-https-backend-service에서instance-group-a를 사용할 수도 있습니다.UTILIZATION분산 모드를 사용하면external-https-backend-service에서instance-group-a도 사용할 수 없습니다.
여러 백엔드 서비스의 백엔드 역할을 하는 인스턴스 그룹 하나의 분산 모드를 변경하려면 다음 안내를 따르세요.
- 하나 이외의 모든 백엔드 서비스에서 인스턴스 그룹을 삭제합니다.
- 남은 하나의 백엔드 서비스에서 백엔드의 분산 모드를 변경합니다.
- 새 분산 모드를 지원하는 경우 인스턴스 그룹을 나머지 백엔드 서비스에 백엔드로 다시 추가합니다.
인스턴스 그룹이 여러 백엔드 서비스와 연결된 경우 각 백엔드 서비스는 인스턴스 그룹의 동일한 이름이 지정된 포트 또는 다른 이름이 지정된 포트를 참조할 수 있습니다.
둘 이상의 백엔드 서비스에 자동 확장의 관리형 인스턴스 그룹을 추가하지 않는 것이 좋습니다. 추가하면 그룹의 인스턴스가 예측할 수 없거나 불필요하게 확장될 수 있습니다. 특히 HTTP 부하 분산 사용률 자동 확장 측정 항목을 사용하는 경우에는 더욱 그렇습니다.
- 권장되지는 않지만 이 시나리오는 자동 확장 측정항목이 부하 분산기의 제공 용량과 관련이 없는 CPU 사용률 또는 Cloud Monitoring 측정항목인 경우에는 사용될 수 있습니다. 이러한 자동 확장 측정항목 중 하나를 사용하면 불규칙한 확장을 방지할 수 있습니다.
영역별 네트워크 엔드포인트 그룹
네트워크 엔드포인트는 인스턴스 그룹에서 VM을 참조하는 대신 IP 주소 또는 IP 주소 및 포트 조합별로 서비스를 나타냅니다. 네트워크 엔드포인트 그룹(NEG)은 네트워크 엔드포인트의 논리적 그룹입니다.
영역별 네트워크 엔드포인트 그룹(NEG)은 IP 주소 컬렉션 및 단일 서브넷 내 Google Cloud 리소스의 IP 주소 및 포트 조합을 나타내는 영역별 리소스입니다.
영역별 NEG를 백엔드로 사용하는 백엔드 서비스는 VM 내에서 실행되는 애플리케이션 또는 컨테이너 간에 트래픽을 분산합니다.
영역별 NEG에 사용할 수 있는 네트워크 엔드포인트에는 다음과 같은 두 가지 유형이 있습니다.
GCE_VM_IP엔드포인트(내부 패스 스루 네트워크 부하 분산기 및 백엔드 서비스 기반의 외부 패스 스루 네트워크 부하 분산기에서만 지원됨)GCE_VM_IP_PORT엔드포인트
영역별 NEG 백엔드를 지원하는 제품을 확인하려면 표: 백엔드 서비스 및 지원되는 백엔드 유형을 참조하세요.
자세한 내용은 영역별 NEG 개요를 참조하세요.
인터넷 네트워크 엔드포인트 그룹
인터넷 NEG는 외부 백엔드를 정의하는 리소스입니다. 외부 백엔드는 온프레미스 인프라 또는 타사에서 제공하는 인프라에서 호스팅되는 백엔드입니다.
인터넷 NEG는 호스트 이름 또는 IP 주소와 선택적 포트의 조합입니다. 인터넷 NEG에 사용할 수 있는 네트워크 엔드포인트에는 INTERNET_FQDN_PORT 및 INTERNET_IP_PORT의 두 가지 유형이 있습니다.
자세한 내용은 인터넷 네트워크 엔드포인트 그룹 개요를 참조하세요.
서버리스 네트워크 엔드포인트 그룹
네트워크 엔드포인트 그룹(NEG)은 부하 분산기의 백엔드 엔드포인트 그룹을 지정합니다. 서버리스 NEG는 Cloud Run, App Engine, Cloud Run 함수 또는 API 게이트웨이 서비스를 가리키는 백엔드입니다.
서버리스 NEG는 다음 중 하나를 나타낼 수 있습니다.
- Cloud Run 서비스 또는 서비스 그룹
- Cloud Run 함수 또는 함수 그룹
- App Engine 앱(스탠더드 또는 플렉스), 앱 내의 특정 서비스, 앱의 특정 버전, 서비스 그룹
- 서비스 구현에 관계없이 모든 서비스에서 일관된 REST API를 통해 서비스에 액세스할 수 있는 API 게이트웨이. 이는 미리보기 버전에 있는 기능입니다.
URL 패턴을 공유하는 서버리스 애플리케이션에 서버리스 NEG를 설정하려면 URL 마스크를 사용합니다. URL 마스크는 URL 스키마의 템플릿입니다 (예: example.com/<service>). 서버리스 NEG는 이 템플릿을 사용하여 수신 요청의 URL에서 <service> 이름을 추출하고 요청을 동일한 이름의 일치하는 Cloud Run, Cloud Run 함수 또는 App Engine 서비스로 라우팅합니다.
서버리스 NEG 백엔드를 지원하는 부하 분산기를 확인하려면 표: 백엔드 서비스 및 지원되는 백엔드 유형을 참조하세요.
서버리스 NEG에 대한 자세한 내용은 서버리스 네트워크 엔드포인트 그룹 개요를 참조하세요.
서비스 결합
서비스 결합은 Cloud Service Mesh의 백엔드 서비스와 서비스 디렉터리에 등록된 서비스 간의 연결을 설정하는 백엔드입니다. 백엔드 서비스는 여러 서비스 결합을 참조할 수 있습니다. 서비스 결합이 있는 백엔드 서비스는 다른 유형의 백엔드를 참조할 수 없습니다.
혼합된 백엔드
단일 백엔드 서비스에 여러 유형의 백엔드를 추가할 때 다음 사용 고려사항을 적용합니다.
- 단일 백엔드 서비스는 인스턴스 그룹과 영역별 NEG를 동시에 사용할 수 없습니다.
- 동일한 백엔드 서비스에서는 다양한 인스턴스 그룹 유형의 조합을 사용할 수 있습니다. 예를 들어 단일 백엔드 서비스가 관리형 인스턴스 그룹과 비관리형 인스턴스 그룹의 조합을 참조할 수 있습니다. 어떤 백엔드가 어떤 백엔드 서비스와 호환되는지에 대한 자세한 내용은 이전 섹션의 표를 참조하세요.
- 특정 프록시 부하 분산기를 사용하면 영역별 NEG(
GCE_VM_IP_PORT엔드포인트 포함)와 하이브리드 연결 NEG(NON_GCP_PRIVATE_IP_PORT엔드포인트 포함)의 조합을 사용하여 하이브리드 부하 분산을 구성할 수 있습니다. 이 기능이 있는 부하 분산기를 확인하려면 표: 백엔드 서비스 및 지원되는 백엔드 유형을 참조하세요.
백엔드 프로토콜
백엔드 서비스를 만들 때는 백엔드의 통신에 사용되는 프로토콜을 지정해야 합니다. 백엔드 서비스당 하나의 프로토콜만 지정할 수 있으며 대체 프로토콜로 사용할 보조 프로토콜은 지정할 수 없습니다.
유효한 프로토콜은 부하 분산기 유형 또는 Cloud Service Mesh사용 여부에 따라 다릅니다.
| 제품 | 백엔드 서비스 프로토콜 옵션 |
|---|---|
| 애플리케이션 부하 분산기 | HTTP, HTTPS, HTTP/2 |
| 프록시 네트워크 부하 분산기 | TCP 또는 SSL 리전 프록시 네트워크 부하 분산기는 TCP만 지원합니다. |
| 패스 스루 네트워크 부하 분산기 | TCP, UDP 또는 미지정 |
| Cloud Service Mesh | HTTP, HTTPS, HTTP/2, gRPC, TCP |
백엔드 서비스의 프로토콜을 변경하면 부하 분산기를 통해 백엔드에 몇 분 동안 액세스할 수 없습니다.
IP 주소 선택 정책
이 필드는 프록시 부하 분산기에 적용됩니다. IP 주소 선택 정책을 사용하여 백엔드 서비스에서 백엔드로 전송되는 트래픽 유형을 지정해야 합니다.
IP 주소 선택 정책을 선택할 때 백엔드가 선택한 트래픽 유형을 지원하는지 확인합니다. 자세한 내용은 표: 백엔드 서비스 및 지원되는 백엔드 유형을 참고하세요.
IP 주소 선택 정책은 다른 트래픽 유형을 지원하도록 부하 분산기 백엔드 서비스를 변환하려는 경우에 사용됩니다. 자세한 내용은 단일 스택에서 이중 스택으로 변환을 참고하세요.
IP 주소 선택 정책에 다음 값을 지정할 수 있습니다.
| IP 주소 선택 정책 | 설명 |
|---|---|
| IPv4만 | 클라이언트에서 GFE로의 트래픽에 관계없이 IPv4 트래픽만 백엔드 서비스의 백엔드로 전송합니다. 백엔드 상태를 확인하는 데 IPv4 상태 점검만 사용됩니다. |
| IPv6 우선 사용 | IPv4 연결보다 백엔드의 IPv6 연결에 우선순위를 둡니다(IPv6 주소를 사용하는 정상 백엔드가 있는 경우). 상태 점검은 백엔드의 IPv6 및 IPv4 연결을 주기적으로 모니터링합니다. GFE가 먼저 IPv6 연결을 시도합니다. IPv6 연결이 끊어지거나 느리면 GFE는 Happy Eyeballs를 사용하여 IPv4로 대체 및 연결합니다. IPv6 또는 IPv4 연결 중 하나가 비정상적이더라도 백엔드는 여전히 정상 상태로 간주됩니다. GFE에서 두 연결을 모두 시도하고 Happy Eyeballs를 통해 최종적으로 사용할 연결을 선택합니다. |
| IPv6만 | 클라이언트에서 프록시로의 트래픽에 관계없이 IPv6 트래픽만 백엔드 서비스의 백엔드로 전송합니다. 백엔드 상태를 확인하는 데 IPv6 상태 점검만 사용됩니다. 백엔드 트래픽 유형이 IP 주소 선택 정책과 일치하는지 확인하기 위한 검증은 없습니다. 예를 들어 IPv4 전용 백엔드가 있고 |
부하 분산기와 백엔드 간의 암호화
부하 분산기와 백엔드 간의 암호화에 대한 자세한 내용은 백엔드 암호화를 참조하세요.
트래픽 분산
백엔드 서비스 리소스의 다음 필드 값에 따라 백엔드 동작의 몇 가지 측면이 결정됩니다.
- 분산 모드는 부하 분산기가 새 요청 또는 연결의 백엔드 준비 상태를 측정하는 방법을 정의합니다.
- 대상 용량은 대상 최대 연결 수, 대상 최대 속도 또는 대상 최대 CPU 사용률을 정의합니다.
- 용량 확장기는 대상 용량을 수정하지 않고 전체적인 사용 가능 용량을 조정하는 데 사용됩니다.
분산 모드
분산 모드는 부하 분산기 또는 Cloud Service Mesh 의 백엔드가 추가 트래픽을 처리할 수 있는지 아니면 완전히 로드되었는지를 결정합니다.
Google Cloud에는 세 가지 분산 모드가 있습니다.
CONNECTION: 백엔드에서 처리할 수 있는 총 연결 수를 기준으로 로드가 분산되는 방법을 결정합니다.RATE: 초당 최대 대상 요청(쿼리) 수(RPS, QPS)입니다. 모든 최대 백엔드가 용량에 도달하거나 용량을 초과할 경우 대상 최대 RPS/QPS를 초과할 수 있습니다.UTILIZATION: 인스턴스 그룹의 인스턴스 사용률에 따라 부하가 분산되는 방법을 결정합니다.
각 부하 분산기에 사용할 수 있는 분산 모드
백엔드 서비스에 백엔드를 추가할 때 분산 모드를 설정합니다. 부하 분산기에서 사용할 수 있는 분산 모드는 부하 분산기 유형과 백엔드 유형에 따라 다릅니다.
패스 스루 네트워크 부하 분산기에는 CONNECTION 분산 모드가 필요하지만 대상 용량 설정은 지원되지 않습니다.
애플리케이션 부하 분산기는 인스턴스 그룹 백엔드에 대해 RATE 또는 UTILIZATION 분산 모드를 지원하며, GCE_VM_IP_PORT 엔드포인트가 있는 영역별 NEG에 대해 RATE 분산 모드를 지원하며, 하이브리드 NEG(NON_GCP_PRIVATE_IP_PORT 엔드포인트)에 대해 RATE 분산 모드를 지원합니다. 다른 유형의 지원되는 백엔드의 경우 분산 모드를 생략해야 합니다.
기본 애플리케이션 부하 분산기의 경우 클라이언트의 위치와 리전에 사용 가능한 용량이 있는지 여부(부하 분산 모드의 대상 용량 기준)에 따라 리전이 선택됩니다. 그런 다음 리전 내에서 분산 모드의 대상 용량이 사용되어 리전의 각 백엔드로 전달해야 하는 요청 수의 비율이 계산됩니다. 요청 또는 연결은 백엔드 내의 인스턴스 또는 엔드포인트 간에 라운드 로빈 방식으로 분산됩니다.
전역 외부 애플리케이션 부하 분산기의 경우 클라이언트의 위치와 리전에 사용 가능한 용량이 있는지 여부(부하 분산 모드의 대상 용량 기준)에 따라 리전이 선택됩니다. 리전 내에서 분산 모드의 대상 용량이 사용되어 리전의 각 백엔드(인스턴스 그룹 또는 NEG)로 전달해야 하는 요청 수의 비율이 계산됩니다. 서비스 부하 분산 정책(
serviceLbPolicy) 및 선호 백엔드 설정을 사용하여 한 리전 내에서 선택한 특정 백엔드에 영향을 줄 수 있습니다. 각 인스턴스 그룹 또는 NEG 내에서 부하 분산 정책(LocalityLbPolicy)은 트래픽이 그룹 내 인스턴스 또는 엔드포인트에 분산되는 방식을 결정합니다.
- 리전 간 내부 애플리케이션 부하 분산기, 리전 외부 애플리케이션 부하 분산기, 리전 내부 애플리케이션 부하 분산기에서 분산 모드의 대상 용량은 리전의 각 백엔드(인스턴스 그룹 또는 NEG)로 전달해야 하는 요청 수의 비율을 계산하는 데 사용됩니다. 각 인스턴스 그룹 또는 NEG 내에서 부하 분산 정책(
LocalityLbPolicy)은 트래픽이 그룹 내 인스턴스 또는 엔드포인트에 분산되는 방식을 결정합니다. 리전 간 내부 애플리케이션 부하 분산기만 서비스 부하 분산 정책(serviceLbPolicy) 및 선호 백엔드 설정을 지원하여 리전 내 특정 백엔드 선택에 영향을 줍니다.
프록시 네트워크 부하 분산기는 VM 인스턴스 그룹 백엔드에 대해 CONNECTION 또는 UTILIZATION 분산 모드를 지원하며, GCE_VM_IP_PORT 엔드포인트가 있는 영역별 NEG에 대해 CONNECTION 분산 모드를 지원하며, 하이브리드 NEG(NON_GCP_PRIVATE_IP_PORT 엔드포인트)에 대해 CONNECTION 분산 모드를 지원합니다. 다른 유형의 지원되는 백엔드의 경우 분산 모드를 생략해야 합니다.
전역 외부 프록시 네트워크 부하 분산기의 경우 클라이언트의 위치와 리전에 사용 가능한 용량이 있는지 여부(부하 분산 모드의 대상 용량 기준)에 따라 리전이 선택됩니다. 리전 내에서 분산 모드의 대상 용량이 사용되어 리전의 각 백엔드(인스턴스 그룹 또는 NEG)로 전달해야 하는 요청 수의 비율이 계산됩니다. 서비스 부하 분산 정책(
serviceLbPolicy) 및 선호 백엔드 설정을 사용하여 한 리전 내에서 선택한 특정 백엔드에 영향을 줄 수 있습니다. 각 인스턴스 그룹 또는 NEG 내에서 부하 분산 정책(LocalityLbPolicy)은 트래픽이 그룹 내 인스턴스 또는 엔드포인트에 분산되는 방식을 결정합니다.리전 간 내부 프록시 네트워크 부하 분산기의 경우 구성된 리전이 먼저 선택됩니다. 리전 내에서 분산 모드의 대상 용량이 사용되어 리전의 각 백엔드(인스턴스 그룹 또는 NEG)로 전달해야 하는 요청 수의 비율이 계산됩니다. 서비스 부하 분산 정책(
serviceLbPolicy) 및 선호 백엔드 설정을 사용하여 한 리전 내에서 선택한 특정 백엔드에 영향을 줄 수 있습니다. 각 인스턴스 그룹 또는 NEG 내에서 부하 분산 정책(LocalityLbPolicy)은 트래픽이 그룹 내 인스턴스 또는 엔드포인트에 분산되는 방식을 결정합니다.기본 프록시 네트워크 부하 분산기의 경우 클라이언트의 위치와 리전에 사용 가능한 용량이 있는지 여부(부하 분산 모드의 대상 용량 기준)에 따라 리전이 선택됩니다. 그런 다음 리전 내에서 부하 분산 모드의 대상 용량이 사용되어 리전의 각 백엔드(인스턴스 그룹 또는 NEG)로 전달해야 하는 요청 또는 연결 수의 비율이 계산됩니다. 부하 분산기가 백엔드를 선택하면 요청 또는 연결이 각 백엔드 내의 VM 인스턴스 또는 네트워크 엔드포인트 간에 라운드 로빈 방식으로 분산됩니다.
- 리전 외부 프록시 네트워크 부하 분산기 및 리전 내부 프록시 네트워크 부하 분산기의 경우 부하 분산 모드의 대상 용량은 각 백엔드(인스턴스 그룹 또는 NEG)로 이동해야 하는 요청 수의 비율을 계산하는 데 사용됩니다. 각 인스턴스 그룹 또는 NEG 내에서 부하 분산 정책(
localityLbPolicy)은 트래픽이 그룹 내 인스턴스 또는 엔드포인트에 분산되는 방식을 결정합니다.
다음 표에는 각 부하 분산기와 백엔드 조합에 사용할 수 있는 부하 분산 모드가 요약되어 있습니다.
| 부하 분산기 | 백엔드 | 분산 모드 사용 가능 |
|---|---|---|
| 애플리케이션 부하 분산기 | 인스턴스 그룹 | RATE 또는 UTILIZATION |
영역별 NEG(GCE_VM_IP_PORT 엔드포인트) |
RATE |
|
하이브리드 NEG(NON_GCP_PRIVATE_IP_PORT 엔드포인트) |
RATE |
|
|
프록시 네트워크 부하 분산기
|
인스턴스 그룹 | CONNECTION 또는 UTILIZATION |
영역별 NEG(GCE_VM_IP_PORT 엔드포인트) |
CONNECTION |
|
하이브리드 NEG( |
CONNECTION |
|
| 패스 스루 네트워크 부하 분산기 | 인스턴스 그룹 | CONNECTION |
영역 NEG(GCE_VM_IP 엔드포인트) |
CONNECTION |
백엔드 서비스와 연결된 모든 VM의 평균 사용률이 10% 미만인 경우 Google Cloud에서 특정 영역을 우선 선택할 수 있습니다. 이러한 경우는 리전별 관리형 인스턴스 그룹, 다른 영역의 영역별 관리형 인스턴스 그룹, 영역별 비관리형 인스턴스 그룹을 사용하는 경우에 발생할 수 있습니다. 이러한 영역별 불균형은 부하 분산기에 더 많은 트래픽이 전송되면 자동으로 해결됩니다.
자세한 내용은 gcloud compute backend-services add-backend를 참조하세요.
대상 용량
각 분산 모드에는 다음 대상 최댓값 중 하나를 정의하는 해당 대상 용량이 있습니다.
- 연결 수
- 요율
- CPU 사용률
모든 분산 모드에서 대상 용량은 회선 차단기가 아닙니다. 모든 백엔드 VM 또는 엔드포인트가 최댓값에 이르는 등의 특정 조건에서 부하 분산기는 최댓값을 초과할 수 있습니다.
Connection 분산 모드
CONNECTION 분산 모드에서 대상 용량은 열린 연결이 가능한 대상 최대 수를 정의합니다. 내부 패스 스루 네트워크 부하 분산기 및 외부 패스 스루 네트워크 부하 분산기를 제외하고 다음 설정 중 하나를 사용하여 대상 최대 연결 수를 지정해야 합니다.
max-connections-per-instance(VM당): 단일 VM의 대상 평균 연결 수입니다.max-connections-per-endpoint(영역별 NEG의 엔드포인트당): 단일 엔드포인트의 대상 평균 연결 수입니다.max-connections(영역별 NEG 및 영역별 인스턴스 그룹당): 전체 NEG 또는 인스턴스 그룹의 대상 평균 연결 수입니다. 리전별 관리형 인스턴스 그룹의 경우max-connections-per-instance를 대신 사용합니다.
다음 표에서는 대상 용량 매개변수가 다음을 정의하는 방법을 보여줍니다.
- 전체 백엔드의 대상 용량
- 각 인스턴스 또는 엔드포인트의 예상 대상 용량
| 백엔드 유형 | 대상 용량 | ||
|---|---|---|---|
| 다음을 지정하는 경우 | 전체 백엔드 용량 | 인스턴스당 또는 엔드포인트당 예상 용량 | |
인스턴스 그룹N 인스턴스,H 정상 |
max-connections-per-instance=X
|
X × N
|
(X × N)/H
|
영역별 NEGN 엔드포인트,H 정상
|
max-connections-per-endpoint=X
|
X × N
|
(X × N)/H
|
| 인스턴스 그룹 (리전별 관리형 인스턴스 그룹 제외) H 정상 인스턴스
|
max-connections=Y
|
Y
|
Y/H
|
그림과 같이 max-connections-per-instance 및 max-connections-per-endpoint 설정은 전체 VM 인스턴스 그룹 또는 전체 영역별 NEG의 대상 최대 연결 수를 계산하는 프록시입니다.
N인스턴스가 있는 VM 인스턴스 그룹에서max-connections-per-instance=X설정은max-connections=X × N설정과 의미가 동일합니다.N엔드포인트가 있는 영역별 NEG에서max-connections-per-endpoint=X설정은max-connections=X × N설정과 의미가 동일합니다.
Rate 분산 모드
RATE 분산 모드의 경우 다음 매개변수 중 하나를 사용하여 대상 용량을 정의해야 합니다.
max-rate-per-instance(VM당): 단일 VM의 대상 평균 HTTP 요청 비율을 제공합니다.max-rate-per-endpoint(영역별 NEG의 엔드포인트당): 단일 엔드포인트의 대상 평균 HTTP 요청 비율을 제공합니다.max-rate(영역별 NEG 및 영역별 인스턴스 그룹당): 전체 NEG 또는 인스턴스 그룹의 대상 평균 HTTP 요청 비율을 제공합니다. 리전별 관리형 인스턴스 그룹의 경우max-rate-per-instance를 대신 사용합니다.
다음 표에서는 대상 용량 매개변수가 다음을 정의하는 방법을 보여줍니다.
- 전체 백엔드의 대상 용량
- 각 인스턴스 또는 엔드포인트의 예상 대상 용량
| 백엔드 유형 | 대상 용량 | ||
|---|---|---|---|
| 다음을 지정하는 경우 | 전체 백엔드 용량 | 인스턴스당 또는 엔드포인트당 예상 용량 | |
인스턴스 그룹N 인스턴스,H 정상 |
max-rate-per-instance=X
|
X × N
|
(X × N)/H
|
영역별 NEGN 엔드포인트,H 정상
|
max-rate-per-endpoint=X
|
X × N
|
(X × N)/H
|
| 인스턴스 그룹 (리전별 관리형 인스턴스 그룹 제외) H 정상 인스턴스
|
max-rate=Y
|
Y
|
Y/H
|
그림과 같이 max-rate-per-instance 및 max-rate-per-endpoint 설정은 전체 인스턴스 그룹 또는 전체 영역별 NEG의 HTTP 요청 최대 비율을 계산하는 프록시입니다.
N인스턴스가 있는 인스턴스 그룹에서max-rate-per-instance=X설정은max-rate=X × N설정과 의미가 동일합니다.N엔드포인트가 있는 영역별 NEG에서max-rate-per-endpoint=X설정은max-rate=X × N설정과 의미가 동일합니다.
Utilization 분산 모드
UTILIZATION 분산 모드에는 필수 대상 용량이 없습니다. 다음 섹션의 표에 요약된 것과 같이 백엔드 유형에 따라 다양한 옵션이 있습니다.
max-utilization 대상 용량은 인스턴스 그룹별로만 지정할 수 있으며 그룹의 특정 VM에는 적용할 수 없습니다.
UTILIZATION 분산 모드에는 필수 대상 용량이 없습니다. Google Cloud 콘솔을 사용하여 백엔드 인스턴스 그룹을 백엔드 서비스에 추가하면 Google Cloud 콘솔은 UTILIZATION 분산 모드가 선택된 경우에 max-utilization 값을 0.8(80%)로 설정합니다. max-utilization 외에도 UTILIZATION 분산 모드는 다음 섹션의 표에 요약된 것처럼 보다 복잡한 대상 용량을 지원합니다.
부하 분산기의 분산 모드 변경
일부 부하 분산기 또는 부하 분산기 구성의 경우 백엔드 서비스에 사용 가능한 분산 모드가 하나뿐이므로 분산 모드를 변경할 수 없습니다. 그 외의 경우 사용된 백엔드에 따라 두 개 이상의 모드를 백엔드 서비스에 사용할 수 있으므로 분산 모드를 변경할 수 있습니다.
각 부하 분산기에서 지원되는 분산 모드를 확인하려면 표: 각 부하 분산기에 사용 가능한 분산 모드를 참조하세요.
분산 모드 및 대상 용량 설정
타겟 용량 사양을 지원하는 제품의 경우 타겟 용량은 회선 차단기가 아닙니다. 지정된 영역에서 구성된 대상 용량 최대치에 도달하면 새 요청 또는 연결이 대상 용량으로 요청 또는 연결을 처리하지 않는 다른 영역으로 배포됩니다. 모든 영역이 타겟 용량에 도달하면 새 요청 또는 연결이 오버필링 방식으로 배포됩니다.
애플리케이션 부하 분산기 및 Cloud Service Mesh
이 표에는 애플리케이션 로드 밸런서 및 Cloud Service Mesh에 사용할 수 있는 분산 모드와 타겟 용량 조합이 나와 있습니다.
| 백엔드 유형 | 분산 모드 | 대상 용량 사양 |
|---|---|---|
인스턴스 그룹
|
RATE |
다음 중 하나를 반드시 지정해야 합니다.
|
UTILIZATION |
선택적으로 다음 중 하나를 지정할 수 있습니다.
|
|
|
영역별 NEG
하이브리드 NEG
|
RATE |
다음 중 하나를 반드시 지정해야 합니다.
|
프록시 네트워크 부하 분산기
이 표에는 프록시 네트워크 부하 분산기에 사용할 수 있는 분산 모드 및 대상 용량 조합이 나와 있습니다.
| 백엔드 유형 | 분산 모드 | 대상 용량 사양 |
|---|---|---|
인스턴스 그룹
|
CONNECTION |
다음 중 하나를 반드시 지정해야 합니다.
|
UTILIZATION |
선택적으로 다음 중 하나를 지정할 수 있습니다.
|
|
|
영역별 NEG
하이브리드 NEG
|
CONNECTION |
다음 중 하나를 반드시 지정해야 합니다.
|
패스 스루 네트워크 부하 분산기
이 표에는 패스 스루 네트워크 부하 분산기에 사용할 수 있는 분산 모드 및 대상 용량 조합이 나와 있습니다.
| 백엔드 유형 | 분산 모드 | 대상 용량 사양 |
|---|---|---|
인스턴스 그룹
|
CONNECTION |
대상 최대 연결 수를 지정할 수 없습니다. |
영역별 NEG
|
CONNECTION |
대상 최대 연결 수를 지정할 수 없습니다. |
용량 확장 처리
용량 확장 처리를 사용하여 대상 용량을 변경하지 않고 대상 용량(최대 사용률, 최대 속도 또는 최대 연결 수)을 확장합니다.
Google Cloud 참조 문서에 대해서는 아래를 참조하세요.
- Google Cloud CLI: capacity-scaler
- API:
--max-* 매개변수 중 하나를 명시적으로 변경하지 않고 용량 확장 처리를 조정하여 유효 대상 용량을 확장할 수 있습니다.
용량 확장 프로그램을 다음 값 중 하나로 설정할 수 있습니다.
- 기본값은
1이며 이 경우 그룹이 구성된 용량의 100% 까지 서비스를 제공합니다(balancingMode에 따라 다름). 0값은 그룹이 완전히 드레이닝되어 사용 가능한 용량의 0%를 제공한다는 의미입니다. 백엔드 서비스에 연결된 백엔드가 한 개뿐이면0설정을 구성할 수 없습니다.0.1(10%) ~1.0(100%) 사이의 값입니다.
다음 예시에서는 용량 확장기가 대상 용량 설정과 충돌하는 방법을 보여줍니다.
분산 모드가
RATE이면max-rate가80RPS로 설정되고 용량 확장기가1.0이면 사용 가능한 용량도80RPS입니다.분산 모드가
RATE이면max-rate가80RPS로 설정되고 용량 확장기가0.5이면 사용 가능한 용량이40RPS(0.5 times 80)에 대한 정보에 액세스해야 합니다.분산 모드가
RATE이면max-rate가80RPS로 설정되고 용량 확장기가0.0이면 사용 가능한 용량이 0(0)입니다.
서비스 부하 분산 정책
서비스 부하 분산 정책(serviceLbPolicy)은 부하 분산기의 백엔드 서비스와 연결된 리소스입니다. 이를 통해 백엔드 서비스와 연결된 백엔드 내에서 트래픽이 분산되는 방식에 영향을 주는 매개변수를 맞춤설정할 수 있습니다.
- 리전 또는 영역에 트래픽이 분산되는 방식을 결정하는 데 사용되는 부하 분산 알고리즘을 맞춤설정합니다.
- 부하 분산기가 비정상 백엔드로부터 트래픽을 빠르게 드레이닝할 수 있도록 자동 용량 드레이닝을 사용 설정합니다.
또한 특정 백엔드를 선호 백엔드로 지정할 수 있습니다. 나머지 백엔드로 요청을 전송하기 전에 이러한 백엔드의 가용 용량(즉, 백엔드의 분산 모드에서 지정된 대상 용량)을 모두 사용해야 합니다.
자세한 내용은 서비스 부하 분산 정책을 사용한 고급 부하 분산 최적화를 참조하세요.
부하 분산 지역 정책
백엔드 서비스의 경우 트래픽 분산은 분산 모드와 부하 분산 지역 정책을 기반으로 합니다. 분산 모드에 따라 각 백엔드 (인스턴스 그룹 또는 NEG)로 전송되어야 할 트래픽의 비율이 결정됩니다. 그런 다음 부하 분산 지역 정책 (LocalityLbPolicy)에 따라 각 영역 내 인스턴스 또는 엔드포인트에 트래픽이 분산되는 방식이 결정됩니다. 리전 관리형 인스턴스 그룹의 경우 지역 정책은 각 구성 영역에 적용됩니다.
부하 분산 지역 정책은 백엔드 서비스별로 구성됩니다. 다음 설정을 사용할 수 있습니다.
ROUND_ROBIN(기본값): 부하 분산기에서 라운드 로빈 순서로 정상 백엔드를 선택하는 기본 부하 분산 지역 정책 설정입니다.LEAST_REQUEST: 부하 분산기가 임의의 정상 호스트 2개를 선택하고 활성 요청이 적은 호스트를 선택하는O(1)알고리즘입니다.RING_HASH: 이 알고리즘은 백엔드에 일관된 해싱을 구현합니다. 이 알고리즘에는 N 호스트 집합에서 호스트를 추가하거나 삭제하면 요청의 1/N에만 영향을 미치는 속성이 있습니다.RANDOM: 부하 분산기에서 임의의 정상 호스트를 선택합니다.ORIGINAL_DESTINATION: 부하 분산기가 클라이언트 연결 메타데이터를 기반으로 백엔드를 선택합니다. 요청이 부하 분산기로 리디렉션되기 전에 수신 클라이언트 요청에 지정된 원래 대상 IP 주소로 연결이 열립니다.ORIGINAL_DESTINATION는 전역 및 리전 외부 애플리케이션 부하 분산기에서 지원되지 않습니다.MAGLEV: 백엔드에 일관된 해싱을 구현하며RING_HASH정책을 대체하는 데 사용할 수 있습니다. Maglev는RING_HASH만큼 안정적이지는 않지만 테이블 조회 빌드 시간과 호스트 선택 시간이 더 빠릅니다. Maglev에 관한 자세한 내용은 Maglev 워크페이퍼를 참고하세요.WEIGHTED_MAGLEV: 상태 점검에서 보고된 가중치를 사용하여 인스턴스별 가중치 부하 분산을 구현합니다. 이 정책을 사용하는 경우 백엔드 서비스는 기존이 아닌 HTTP 기반 상태 점검을 구성해야 하며, 상태 점검 응답에는 인스턴스별 가중치를 지정하기 위한 비표준 HTTP 응답 헤더 필드X-Load-Balancing-Endpoint-Weight가 포함되어야 합니다. 모든 인스턴스가 유효한 가중치를 보고하거나UNAVAILABLE_WEIGHT를 보고하는 한, 마지막으로 처리된 상태 점검 응답에 보고된 인스턴스별 가중치를 기반으로 부하 분산 결정이 내려집니다. 그렇지 않으면 부하 분산이 동일 가중치로 유지됩니다.WEIGHTED_MAGLEV는 외부 패스 스루 네트워크 부하 분산기에서만 지원됩니다. 예시는 외부 패스 스루 네트워크 부하 분산기에 가중치가 적용된 부하 분산 설정을 참고하세요.
부하 분산 지역 정책 구성은 다음 부하 분산기와 함께 사용되는 백엔드 서비스에서만 지원됩니다.
- 전역 외부 애플리케이션 부하 분산기
- 리전 외부 애플리케이션 부하 분산기
- 리전 간 내부 애플리케이션 부하 분산기
- 리전 내부 애플리케이션 부하 분산기
- 외부 패스 스루 네트워크 부하 분산기
부하 분산 지역 정책(localityLbPolicy)의 유효한 기본값은 세션 어피니티 설정에 따라 변경됩니다. 세션 어피니티가 구성되지 않은 경우, 즉 세션 어피니티가 기본값 NONE으로 유지되는 경우 localityLbPolicy의 기본값은 ROUND_ROBIN입니다. 세션 어피니티가 NONE 이외의 값으로 설정된 경우 localityLbPolicy의 기본값은 MAGLEV입니다.
로드 밸런싱 지역 정책을 구성하려면 Google Cloud 콘솔, gcloud(--locality-lb-policy) 또는 API(localityLbPolicy)를 사용하면 됩니다.
Cloud Service Mesh 및 트래픽 분산
Cloud Service Mesh도 백엔드 서비스 리소스를 사용합니다. 특히 Cloud Service Mesh는 부하 분산 스키마가 INTERNAL_SELF_MANAGED인 백엔드 서비스를 사용합니다. 내부 자체 관리형 백엔드 서비스의 경우 트래픽 분산은 부하 분산 모드와 부하 분산 정책의 조합을 기반으로 합니다. 백엔드 서비스는 백엔드의 분산 모드에 따라 백엔드로 트래픽을 전달합니다. 그런 다음 Cloud Service Mesh가 부하 분산 정책에 따라 트래픽을 분산합니다.
내부 자체 관리형 백엔드 서비스는 다음 분산 모드를 지원합니다.
UTILIZATION- 모든 백엔드가 인스턴스 그룹인 경우RATE- 모든 백엔드가 인스턴스 그룹 또는 영역별 NEG인 경우
RATE 분산 모드를 선택하면 최대 속도, 인스턴스당 최대 속도 또는 엔드포인트당 최대 속도를 지정해야 합니다.
Cloud Service Mesh에 대한 자세한 내용은 Cloud Service Mesh 개념을 참고하세요.
백엔드 하위 설정
백엔드 하위 설정은 백엔드 하위 집합을 각 프록시 인스턴스에 할당하여 성능과 확장성을 개선하는 선택적 기능입니다.
백엔드 하위 설정은 다음 항목에 지원됩니다.
- 리전별 내부 애플리케이션 부하 분산기
- 내부 패스 스루 네트워크 부하 분산기
리전별 내부 애플리케이션 부하 분산기에 대한 백엔드 하위 설정
리전 간 내부 애플리케이션 부하 분산기는 백엔드 하위 설정을 지원하지 않습니다.내부 애플리케이션 부하 분산기의 경우 백엔드 하위 설정은 리전별 백엔드 서비스 내의 백엔드 하위 집합만 각 프록시 인스턴스에 자동으로 할당합니다. 기본적으로 각 프록시 인스턴스는 백엔드 서비스 내의 모든 백엔드에 대한 연결을 엽니다. 프록시 인스턴스 및 백엔드의 수 모두 모든 백엔드에 열려 있는 경우 성능 문제가 발생할 수 있습니다.
하위 설정을 사용 설정하면 각 프록시에서 백엔드의 하위 집합에 대한 연결만 열기 때문에 각 백엔드에 열린 상태로 유지되는 연결 수가 줄어듭니다. 동시에 각 백엔드에 열려 있는 연결 수를 줄이면 백엔드와 프록시의 성능 모두 향상될 수 있습니다.
다음 다이어그램에서는 프록시가 2개 있는 부하 분산기를 보여줍니다. 백엔드 하위 집합이 없으면 두 프록시의 트래픽이 백엔드 서비스 1의 모든 백엔드로 분산됩니다. 백엔드 하위 설정을 사용 설정하면 각 프록시의 트래픽이 백엔드의 하위 집합에 분산됩니다. 프록시 1의 트래픽은 백엔드 1과 2에 분산되고 프록시 2의 트래픽은 백엔드 3과 4에 분산됩니다.
localityLbPolicy 정책을 설정하여 백엔드에 대한 부하 분산 트래픽을 추가로 미세 조정할 수 있습니다.
자세한 내용은 트래픽 정책을 참조하세요.
내부 애플리케이션 부하 분산기의 백엔드 하위 설정을 설정하는 방법에 대한 자세한 내용은 백엔드 하위 설정 구성을 참조하세요.
내부 애플리케이션 부하 분산기의 백엔드 하위 설정 관련 주의사항
- 백엔드 하위 설정은 모든 백엔드 인스턴스가 잘 활용되도록 설계되었지만 각 백엔드에서 수신하는 트래픽 양에 어느 정도 편향이 발생할 수 있습니다. 백엔드 부하 분산에 민감한 백엔드 서비스에서
localityLbPolicy를LEAST_REQUEST로 설정하는 것이 좋습니다. - 하위 집합을 사용 설정하거나 중지하면 기존 연결이 끊어집니다.
- 백엔드 하위 집합을 사용하려면 세션 어피니티가
NONE(5튜플 해시)이어야 합니다. 다른 세션 어피니티 옵션은 백엔드 하위 설정이 중지된 경우에만 사용 가능합니다.--subsetting-policy및--session-affinity플래그의 기본값은 모두NONE이며 한 번에 하나만 다른 값으로 설정할 수 있습니다.
내부 패스 스루 네트워크 부하 분산기의 백엔드 하위 설정
내부 패스 스루 네트워크 부하 분산기의 백엔드 하위 설정을 사용하면 내부 패스 스루 네트워크 부하 분산기를 확장하여 내부 백엔드 서비스당 더 많은 수의 백엔드 VM 인스턴스를 지원할 수 있습니다.
하위 설정이 이 한도에 미치는 영향에 대한 자세한 내용은 부하 분산 리소스 할당량 및 한도의 '백엔드 서비스' 섹션을 참조하세요.
기본적으로 하위 설정은 사용 중지되어 백엔드 서비스가 최대 250개의 백엔드 인스턴스 또는 엔드포인트로 배포되도록 제한합니다. 백엔드 서비스가 250개를 넘는 백엔드를 지원해야 하는 경우 하위 설정을 사용 설정할 수 있습니다. 하위 설정을 사용 설정하면 각 클라이언트 연결에서 백엔드 인스턴스의 하위 집합이 선택됩니다.
다음 다이어그램은 이 두 가지 작업 모드 간의 차이점의 축소 모델을 보여줍니다.
하위 설정을 하지 않으면 전체 정상 백엔드 집합이 더 효율적으로 사용되며 트래픽 분산에 따라 모든 정상 백엔드에 새로운 클라이언트 연결이 분산됩니다. 하위 설정을 사용하면 부하 분산 제한이 적용되지만, 부하 분산기가 250개를 넘는 백엔드를 지원할 수 있습니다.
구성 안내는 하위 설정을 참조하세요.
내부 패스 스루 네트워크 부하 분산기의 백엔드 하위 설정 관련 주의사항
- 하위 설정을 사용 설정하면 백엔드 수가 작더라도 모든 백엔드가 특정 발신자로부터 트래픽을 수신하는 것은 아닙니다.
- 하위 설정을 사용 설정하는 경우의 최대 백엔드 인스턴스 수는 할당량 페이지를 참조하세요 .
- 하위 설정에서는 5튜플의 세션 어피니티만 지원됩니다.
- 하위 설정을 사용하면 패킷 미러링이 지원되지 않습니다.
- 하위 집합을 사용 설정하거나 중지하면 기존 연결이 끊어집니다.
- 온프레미스 클라이언트가 내부 패스 스루 네트워크 부하 분산기에 액세스해야 하는 경우 하위 집합은 온프레미스 클라이언트에서 연결을 수신하는 백엔드 수를 크게 줄일 수 있습니다. 이는 Cloud VPN 터널이나 Cloud Interconnect VLAN 연결의 리전에 따라 부하 분산기의 백엔드 하위 집합이 결정되기 때문입니다. 특정 리전의 모든 Cloud VPN 엔드포인트와 Cloud Interconnect 엔드포인트는 같은 하위 집합을 사용합니다. 다른 하위 집합은 다른 리전에서 사용됩니다.
백엔드 하위 설정 가격 책정
백엔드 하위 설정을 사용하는 경우 요금이 부과되지 않습니다. 자세한 내용은 모든 네트워킹 가격 책정을 참조하세요.
세션 어피니티
세션 어피니티를 사용하면 정상적인 백엔드 수가 일정하게 유지되는 한, 부하 분산기가 예측 가능한 방식으로 새 연결을 위해 백엔드를 선택하는 방법을 제어할 수 있습니다. 이 기능은 특정 사용자의 여러 요청이 동일한 백엔드 또는 엔드포인트로 전달되어야 하는 애플리케이션에 유용합니다. 이러한 애플리케이션에는 일반적으로 광고 게재, 게임 또는 내부 캐싱이 많이 발생하는 서비스에서 사용하는 스테이트풀(Stateful) 서버가 포함됩니다.
Google Cloud 부하 분산기는 최선의 방식으로 세션 어피니티를 제공합니다. 백엔드 상태 점검 상태 변경, 백엔드 추가 또는 삭제, 백엔드 가중치 변경 (가중치 부하 분산 사용 설정 또는 사용 중지 포함), 분산 모드에서 측정되는 백엔드의 가득찬 상태 변경과 같은 요인으로 인해 세션 어피니티가 손상될 수 있습니다.
세션 어피니티가 있는 부하 분산은 고유한 연결이 비교적 크게 분산되어 있을 때 원활하게 작동합니다. 비교적 크다는 것은 백엔드 수의 최소 몇 배를 의미합니다. 적은 수의 연결로 부하 분산기를 테스트하면 백엔드 간의 클라이언트 연결 분산이 정확하게 표현되지 않습니다.
기본적으로 모든 Google Cloud 부하 분산기는 다음과 같이 5튜플 해시(--session-affinity=NONE)를 사용하여 백엔드를 선택합니다.
- 패킷의 소스 IP 주소
- 패킷의 소스 포트(패킷 헤더에 있는 경우)
- 패킷의 대상 IP 주소
- 패킷의 대상 포트(패킷 헤더에 있는 경우)
- 패킷의 프로토콜
패스 스루 부하 분산기의 경우 새 연결이 정상적인 백엔드 인스턴스 또는 엔드포인트(장애 조치 정책이 구성된 경우 활성 풀에 있음)에 배포됩니다. 다음을 제어할 수 있습니다.
- 설정된 연결이 비정상 백엔드에서 유지되는지 여부. 자세한 내용은 내부 패스 스루 네트워크 부하 분산기의 비정상 백엔드에 대한 연결 지속성 문서 및 백엔드 서비스 기반 외부 패스 스루 네트워크 부하 분산기의 비정상 백엔드에 대한 연결 지속성 문서를 참조하세요.
- 장애 조치 정책이 구성된 경우 설정된 연결이 장애 조치 및 장애 복구 중에 유지되는지 여부. 자세한 내용은 내부 패스 스루 네트워크 부하 분산기의 장애 조치 및 장애 복구 시 연결 드레이닝 문서 및 백엔드 서비스 기반 외부 패스 스루 네트워크 부하 분산기의 장애 조치 및 장애 복구 시 연결 드레이닝 문서를 참조하세요.
- 부하 분산기에서 백엔드를 삭제할 때 설정된 연결이 지속될 수 있는 시간. 자세한 내용은 연결 드레이닝 사용 설정을 참조하세요.
프록시 기반 부하 분산기의 경우: 정상 백엔드 인스턴스 또는 엔드포인트의 수가 일정하게 유지되고, 이전에 선택한 백엔드 인스턴스 또는 엔드포인트의 용량이 충분하면 후속 요청 또는 연결이 동일한 백엔드 VM 또는 엔드포인트로 이동합니다. 분산 모드의 대상 용량은 백엔드가 언제 용량에 도달하는지를 결정합니다.
다음 표에는 각 제품에 지원되는 세션 어피니티 옵션이 나와 있습니다.
| 제품 | 세션 어피니티 옵션 |
|---|---|
또한 다음을 참고하세요
|
|
| 기본 애플리케이션 부하 분산기 |
|
또한 다음을 참고하세요
|
|
| 내부 패스 스루 네트워크 부하 분산기 |
내부 패스 스루 네트워크 부하 분산기 및 세션 어피니티에 대한 구체적인 내용은 내부 패스 스루 네트워크 부하 분산기 개요를 참조하세요. |
| 외부 패스 스루 네트워크 부하 분산기* |
외부 패스 스루 네트워크 부하 분산기 및 세션 어피니티에 대한 구체적인 내용은 외부 TCP/UDP 외부 패스 스루 네트워크 부하 분산기 개요를 참조하세요. |
|
|
| Cloud Service Mesh |
|
* 이 표에는 백엔드 서비스 기반 외부 패스 스루 네트워크 부하 분산기에서 지원되는 세션 어피니티가 나와 있습니다.
대상 풀 기반 외부 패스 스루 네트워크 부하 분산기는 백엔드 서비스를 사용하지 않습니다. 대신 대상 풀의 sessionAffinity 매개변수를 통해 외부 패스 스루 네트워크 부하 분산기의 세션 어피니티를 설정합니다.
세션 어피니티를 구성할 때 다음 사항에 유의하세요.
인증 또는 보안 목적으로 세션 어피니티를 사용하지 않습니다. 스테이트풀(Stateful) 쿠키 기반 세션 어피니티를 제외한 세션 어피니티는 제공 및 정상 백엔드 수가 변경될 때마다 중단되도록 설계되었습니다. 자세한 내용은 세션 어피니티 손실을 참고하세요.
--session-affinity및--subsetting-policy플래그의 기본값은 모두NONE이며 한 번에 하나만 다른 값으로 설정할 수 있습니다.
세션 어피니티 유형
다음 섹션에서는 다양한 세션 어피니티 유형을 설명합니다.
클라이언트 IP, 대상 없음 어피니티
클라이언트 IP, 대상 없음 세션 어피니티 (CLIENT_IP_NO_DESTINATION)는 수신된 각 패킷의 소스 IP 주소만을 기반으로 하는 1튜플 해시입니다. 이 세션 어피니티는 내부 패스 스루 네트워크 부하 분산기에서만 사용할 수 있습니다.
이 옵션은 패킷 대상 IP 주소와 관계없이 패킷의 소스 IP 주소만을 기반으로 동일한 백엔드 VM이 클라이언트의 모든 패킷을 처리해야 하는 경우에 유용할 수 있습니다. 이러한 상황은 일반적으로 내부 패스 스루 네트워크 부하 분산기가 정적 경로의 다음 홉인 경우에 발생합니다. 자세한 내용은 세션 어피니티 및 다음 홉 내부 패스 스루 네트워크 부하 분산기를 참고하세요.
클라이언트 IP 어피니티
클라이언트 IP 세션 어피니티 (CLIENT_IP)는 패킷의 소스 및 대상 IP 주소에서 생성된 2튜플 해시입니다. 클라이언트 IP 세션 어피니티는 백엔드 서비스를 사용하는 모든 Google Cloud 부하 분산기에 사용할 수 있습니다.
외부 패스 스루 네트워크 부하 분산기는 이 세션 어피니티 옵션을 클라이언트 IP, 대상 IP라고 합니다.
클라이언트 IP 어피니티를 사용할 때는 다음 사항에 유의하세요.
패킷 대상 IP 주소는 패킷이 부하 분산기로 직접 전송되는 경우에만 부하 분산기 전달 규칙의 IP 주소와 동일합니다.
정적 경로에 의해 다음 홉 내부 패스 스루 네트워크 부하 분산기로 라우팅되는 패킷의 대상 IP 주소는 부하 분산기 전달 규칙의 IP 주소와 일치하지 않습니다. 중요한 세부정보는 세션 어피니티 및 다음 홉 내부 패스 스루 네트워크 부하 분산기를 참고하세요.
패킷이 Google Cloud 부하 분산기에 전송되기 전에 중간 NAT 또는 프록시 시스템에서 처리되는 경우 패킷 소스 IP 주소가 원래 클라이언트와 연결된 IP 주소와 일치하지 않을 수 있습니다. 여러 클라이언트가 동일한 유효 소스 IP 주소를 공유하는 경우 일부 백엔드 VM은 다른 VM보다 더 많은 연결 또는 요청을 수신할 수 있습니다.
생성된 쿠키 어피니티
생성된 쿠키 기반 어피니티를 사용하면 부하 분산기가 초기 HTTP 요청에 대한 응답으로 Set-Cookie 헤더에 HTTP 쿠키를 포함합니다.
생성된 쿠키의 이름은 부하 분산기 유형에 따라 다릅니다. 생성된 쿠키를 지원하는 제품은 다음과 같습니다.
| 제품 | 쿠키 이름 |
|---|---|
| 전역 외부 애플리케이션 부하 분산기 | GCLB |
| 기존 애플리케이션 부하 분산기 | GCLB |
| 리전 외부 애플리케이션 부하 분산기 | GCILB |
| 리전 간 내부 애플리케이션 부하 분산기 | GCILB |
| 리전 내부 애플리케이션 부하 분산기 | GCILB |
| Cloud Service Mesh | GCILB |
생성된 쿠키의 경로 속성은 항상 슬래시 (/)이므로 다른 백엔드 서비스도 생성된 쿠키 어피니티를 사용하는 경우 동일한 URL 맵의 모든 백엔드 서비스에 적용됩니다.
affinityCookieTtlSec 백엔드 서비스 매개변수를 사용하여 쿠키의 최대 전체 기간 (TTL) 값을 0~1,209,600초 (양 끝값 포함)로 구성할 수 있습니다.
affinityCookieTtlSec을 지정하지 않으면 기본 TTL 값은 0입니다.
클라이언트가 HTTP 요청의 Cookie 요청 헤더에 생성된 세션 어피니티 쿠키를 포함하면 세션 어피니티 쿠키가 유효한 한 부하 분산기는 이러한 요청을 동일한 백엔드 인스턴스 또는 엔드포인트로 전달합니다. 쿠키 값을 특정 백엔드 인스턴스 또는 엔드포인트를 참조하는 색인에 매핑하고 생성된 쿠키 세션 어피니티 요구사항이 충족되는지 확인하여 이 작업을 실행합니다.
생성된 쿠키 어피니티를 사용하려면 다음과 같은 균형 조정 모드와 localityLbPolicy 설정을 구성합니다.
- 백엔드 인스턴스 그룹의 경우
RATE분산 모드를 사용합니다. - 백엔드 서비스의
localityLbPolicy에는RING_HASH또는MAGLEV를 사용합니다.localityLbPolicy를 명시적으로 설정하지 않으면 부하 분산기는MAGLEV를 암시적 기본값으로 사용합니다.
자세한 내용은 세션 어피니티 손실을 참고하세요.
헤더 필드 어피니티
헤더 필드 어피니티를 사용하면 백엔드 서비스의 consistentHash.httpHeaderName 필드에 있는 HTTP 헤더의 값을 기반으로 요청이 백엔드로 라우팅됩니다. 사용 가능한 모든 백엔드에 요청을 배포하려면 각 클라이언트가 서로 다른 HTTP 헤더 값을 사용해야 합니다.
다음 부하 분산기에서 헤더 필드 어피니티를 사용합니다.
- Cloud Service Mesh
- 리전 간 내부 애플리케이션 부하 분산기
- 전역 외부 애플리케이션 부하 분산기
- 리전 외부 애플리케이션 부하 분산기
- 리전 내부 애플리케이션 부하 분산기
헤더 필드 어피니티는 다음 조건이 충족되는 경우에 지원됩니다.
- 부하 분산 지역 정책은 RING_HASH 또는 MAGLEV입니다.
- 백엔드 서비스의
consistentHash가 HTTP 헤더의 이름(httpHeaderName)을 지정합니다.
헤더 필드 어피니티를 지원하는 제품에 대해 알아보려면 표: 지원되는 세션 어피니티 설정을 참조하세요.
HTTP 쿠키 어피니티
HTTP 쿠키 기반 어피니티를 사용하면 부하 분산기는 초기 HTTP 요청에 대한 응답으로 Set-Cookie 헤더에 HTTP 쿠키를 포함합니다. 쿠키의 이름, 경로, TTL (수명)을 지정합니다.
HTTP 쿠키 기반 어피니티를 지원하는 제품은 다음과 같습니다.
- 모든 애플리케이션 부하 분산기
- Cloud Service Mesh
다음 백엔드 서비스 매개변수와 유효한 값을 사용하여 초, 초 단위(나노초), 초와 초 단위 (나노초)를 모두 사용하여 쿠키의 TTL 값을 구성할 수 있습니다.
consistentHash.httpCookie.ttl.seconds는0과315576000000사이의 값 (양 끝값 포함)으로 설정할 수 있습니다.consistentHash.httpCookie.ttl.nanos는0과999999999사이의 값 (양 끝값 포함)으로 설정할 수 있습니다. 단위는 나노초이므로999999999는.999999999초를 의미합니다.
consistentHash.httpCookie.ttl.seconds와 consistentHash.httpCookie.ttl.nanos가 모두 지정되지 않은 경우 affinityCookieTtlSec 백엔드 서비스 매개변수의 값이 대신 사용됩니다. affinityCookieTtlSec을 지정하지 않으면 기본 TTL 값은 0입니다.
클라이언트가 HTTP 요청의 Cookie 요청 헤더에 HTTP 세션 어피니티 쿠키를 포함하면 세션 어피니티 쿠키가 유효한 한 부하 분산기는 이러한 요청을 동일한 백엔드 인스턴스 또는 엔드포인트로 전달합니다. 쿠키 값을 특정 백엔드 인스턴스 또는 엔드포인트를 참조하는 색인에 매핑하고 생성된 쿠키 세션 어피니티 요구사항이 충족되는지 확인하여 이 작업을 실행합니다.
HTTP 쿠키 어피니티를 사용하려면 다음과 같은 균형 조정 모드 및 localityLbPolicy 설정을 구성합니다.
- 백엔드 인스턴스 그룹의 경우
RATE분산 모드를 사용합니다. - 백엔드 서비스의
localityLbPolicy에는RING_HASH또는MAGLEV를 사용합니다.localityLbPolicy를 명시적으로 설정하지 않으면 부하 분산기는MAGLEV를 암시적 기본값으로 사용합니다.
자세한 내용은 세션 어피니티 손실을 참고하세요.
스테이트풀(Stateful) 쿠키 기반 세션 어피니티
상태 저장 쿠키 기반 어피니티를 사용하면 부하 분산기는 초기 HTTP 요청에 대한 응답으로 Set-Cookie 헤더에 HTTP 쿠키를 포함합니다.
쿠키의 이름, 경로, TTL (수명)을 지정합니다.
기존 애플리케이션 부하 분산기를 제외한 모든 애플리케이션 부하 분산기는 상태 저장 쿠키 기반 어피니티를 지원합니다.
초, 초의 소수점 이하 자릿수(나노초), 또는 초와 초의 소수점 이하 자릿수 (나노초)를 모두 사용하여 쿠키의 TTL 값을 구성할 수 있습니다.
strongSessionAffinityCookie.ttl로 표시되는 기간은 2주 (1,209,600초)를 초과하는 값으로 설정할 수 없습니다.
쿠키의 값은 선택된 인스턴스 또는 엔드포인트를 값 자체에 인코딩하여 선택된 백엔드 인스턴스 또는 엔드포인트를 식별합니다. 쿠키가 유효한 한 클라이언트가 후속 HTTP 요청의 Cookie 요청 헤더에 세션 어피니티 쿠키를 포함하면 부하 분산기는 이러한 요청을 선택한 백엔드 인스턴스 또는 엔드포인트로 전달합니다.
다른 세션 어피니티 방법과 달리
상태 저장 쿠키 기반 어피니티에는 분산 모드 또는 부하 분산 지역 정책 (
localityLbPolicy)에 관한 구체적인 요구사항이 없습니다.자동 확장이 관리형 인스턴스 그룹에 새 인스턴스를 추가할 때 스테이트풀 쿠키 기반 어피니티는 영향을 받지 않습니다.
선택한 인스턴스가 삭제되지 않는 한 자동 확장이 관리형 인스턴스 그룹에서 인스턴스를 삭제할 때 스테이트풀 쿠키 기반 어피니티는 영향을 받지 않습니다.
선택한 인스턴스가 삭제되지 않는 한 자동 복구가 관리형 인스턴스 그룹에서 인스턴스를 삭제할 때 스테이트풀 쿠키 기반 어피니티는 영향을 받지 않습니다.
자세한 내용은 세션 어피니티 손실을 참고하세요.
쿠키 기반 어피니티의 TTL 0의 의미
생성된 쿠키 어피니티, HTTP 쿠키 어피니티, 스테이트풀(Stateful) 쿠키 기반 어피니티와 같은 모든 쿠키 기반 세션 어피니티에는 TTL 속성이 있습니다.
TTL이 0초이면 부하 분산기가 쿠키에 Expires 속성을 할당하지 않는다는 의미입니다. 이 경우 클라이언트는 쿠키를 세션 쿠키로 취급합니다. 세션의 정의는 클라이언트에 따라 다릅니다.
웹브라우저와 같은 일부 클라이언트는 전체 탐색 세션 동안 쿠키를 유지합니다. 즉, 쿠키는 애플리케이션이 닫힐 때까지 여러 요청에 걸쳐 유지됩니다.
다른 클라이언트는 세션을 단일 HTTP 요청으로 취급하여 쿠키를 즉시 삭제합니다.
세션 어피니티 상실
애플리케이션 부하 분산기 및 프록시 네트워크 부하 분산기의 모든 세션 어피니티 옵션에는 다음이 필요합니다.
선택한 백엔드 인스턴스 또는 엔드포인트는 백엔드로 구성된 상태로 유지되어야 합니다. 다음 이벤트 중 하나가 발생하면 세션 어피니티가 손상될 수 있습니다.
선택한 인스턴스를 인스턴스 그룹에서 삭제합니다.
관리형 인스턴스 그룹 자동 확장 또는 자동 복구로 인해 선택한 인스턴스가 관리형 인스턴스 그룹에서 삭제됩니다.
선택한 엔드포인트를 NEG에서 삭제합니다.
백엔드 서비스에서 선택한 인스턴스 또는 엔드포인트가 포함된 인스턴스 그룹 또는 NEG를 삭제합니다.
선택한 백엔드 인스턴스 또는 엔드포인트가 정상적으로 유지되어야 합니다. 선택한 인스턴스 또는 엔드포인트가 상태 점검에 실패하면 세션 어피니티가 손상될 수 있습니다.
전역 외부 애플리케이션 부하 분산기, 기존 애플리케이션 부하 분산기, 전역 외부 프록시 네트워크 부하 분산기, 기존 프록시 네트워크 부하 분산기의 경우 라우팅 경로가 변경된 후 후속 요청 또는 연결에 다른 첫 번째 레이어 Google 프런트엔드 (GFE)가 사용되면 세션 어피니티가 손상될 수 있습니다. 인터넷의 클라이언트에서 Google로의 라우팅 경로가 요청 또는 연결 간에 변경되면 다른 첫 번째 레이어 GFE가 선택될 수 있습니다.
스테이트풀 쿠키 기반 세션 어피니티를 제외하고 애플리케이션 부하 분산기 및 프록시 네트워크 부하 분산기의 모든 세션 어피니티 옵션에는 다음과 같은 추가 요구사항이 있습니다.
선택한 인스턴스 또는 엔드포인트가 포함된 인스턴스 그룹 또는 NEG가 타겟 용량으로 정의된 대로 가득 차서는 안 됩니다. 리전 관리형 인스턴스 그룹의 경우 선택한 인스턴스가 포함된 인스턴스 그룹의 영역 구성요소가 꽉 차서는 안 됩니다. 인스턴스 그룹 또는 NEG가 가득 차고 다른 인스턴스 그룹 또는 NEG가 가득 차지 않은 경우 세션 어피니티가 손상될 수 있습니다.
UTILIZATION분산 모드를 사용할 때는 가용성이 예측할 수 없는 방식으로 변경될 수 있으므로RATE또는CONNECTION분산 모드를 사용하여 세션 어피니티가 손상될 수 있는 상황을 최소화해야 합니다.구성된 백엔드 인스턴스 또는 엔드포인트의 총 개수는 일정하게 유지되어야 합니다. 다음 이벤트 중 하나 이상이 발생하면 구성된 백엔드 인스턴스 또는 엔드포인트 수가 변경되고 세션 어피니티가 중단될 수 있습니다.
새 인스턴스 또는 엔드포인트 추가:
- 백엔드 서비스의 기존 인스턴스 그룹에 인스턴스를 추가합니다.
- 관리형 인스턴스 그룹 자동 확장은 백엔드 서비스의 관리형 인스턴스 그룹에 인스턴스를 추가합니다.
- 백엔드 서비스의 기존 NEG에 엔드포인트를 추가합니다.
- 백엔드 서비스에 비어 있지 않은 인스턴스 그룹 또는 NEG를 추가합니다.
선택한 인스턴스 또는 엔드포인트뿐만 아니라 모든 인스턴스 또는 엔드포인트를 삭제합니다.
- 인스턴스 그룹 백엔드에서 인스턴스를 삭제합니다.
- 관리형 인스턴스 그룹 자동 확장 또는 자동 복구는 관리형 인스턴스 그룹 백엔드에서 인스턴스를 삭제합니다.
- NEG 백엔드에서 엔드포인트를 삭제합니다.
- 백엔드 서비스에서 비어 있지 않은 기존 백엔드 인스턴스 그룹 또는 NEG를 삭제합니다.
정상 백엔드 인스턴스 또는 엔드포인트의 총 개수는 일정하게 유지되어야 합니다. 다음 이벤트 중 하나 이상이 발생하면 정상 백엔드 인스턴스 또는 엔드포인트 수가 변경되고 세션 어피니티가 손상될 수 있습니다.
- 인스턴스 또는 엔드포인트가 상태 확인을 통과하여 비정상 상태에서 정상 상태로 전환됩니다.
- 인스턴스 또는 엔드포인트가 상태 확인에 실패하여 정상에서 비정상 또는 제한 시간으로 전환됩니다.
백엔드 서비스 제한 시간
대부분의 Google Cloud 부하 분산기에는 백엔드 서비스 제한 시간이 있습니다. 기본값은 30초입니다. 허용되는 제한 시간 값의 전체 범위는 1~2,147,483,647초입니다.
HTTP, HTTPS 또는 HTTP/2 프로토콜을 사용하는 외부 애플리케이션 부하 분산기 및 내부 애플리케이션 부하 분산기의 경우 백엔드 서비스 제한 시간은 HTTP(S) 트래픽의 요청 및 응답 제한 시간입니다.
각 부하 분산기의 백엔드 서비스 제한 시간에 대한 자세한 내용은 다음을 참조하세요.
- 전역 외부 애플리케이션 부하 분산기 및 리전 외부 애플리케이션 부하 분산기에 대한 내용은 제한 시간 및 재시도를 참조하세요.
- 내부 애플리케이션 부하 분산기에 대한 내용은 제한 시간 및 재시도를 참조하세요.
외부 프록시 네트워크 부하 분산기의 제한 시간은 유휴 제한 시간입니다. 연결이 삭제되기 전에 시간을 늘리거나 줄이려면 제한 시간 값을 변경합니다. 이 유휴 제한 시간은 WebSocket 연결에도 사용됩니다.
내부 패스 스루 네트워크 부하 분산기 및 외부 패스 스루 네트워크 부하 분산기의 경우
gcloud또는 API를 사용하여 백엔드 서비스 제한 시간 값을 설정할 수 있지만 값은 무시됩니다. 이러한 패스스루 부하 분산기에는 백엔드 서비스 제한 시간이 없습니다.
- Cloud Service Mesh에서는
timeoutSec을 사용하여 지정된 백엔드 서비스 제한 시간 필드가 프록시리스 gRPC 서비스에서 지원되지 않습니다. 이러한 서비스의 경우maxStreamDuration필드를 사용하여 백엔드 서비스 제한 시간을 구성합니다. 이것은 gRPC가 요청이 전송된 후 백엔드가 전체 응답을 반환할 때까지 기다릴 시간을 지정하는timeoutSec시맨틱스를 지원하지 않기 때문입니다. gRPC의 제한 시간은 모든 재시도를 포함하여 응답이 완전히 처리될 때까지 스트림 시작으로부터 기다릴 시간을 지정합니다.
상태 점검
백엔드가 인스턴스 그룹이거나 영역별 NEG인 각 백엔드 서비스에는 연결된 상태 확인이 있어야 합니다. 서버리스 NEG 또는 전역 인터넷 NEG를 백엔드로 사용하는 백엔드 서비스는 상태 점검을 참조해서는 안 됩니다.
Google Cloud 콘솔을 사용하여 부하 분산기를 만드는 경우 필요하면 부하 분산기를 만들 때 상태 점검을 만들거나 기존 상태 점검을 참조할 수 있습니다.
Google Cloud CLI 또는 API를 사용하여 인스턴스 그룹 또는 영역별 NEG 백엔드를 사용하는 백엔드 서비스를 만들 때 기존 상태 점검을 참조해야 합니다. 필요한 상태 점검 유형 및 범위에 대한 자세한 내용은 상태 점검 개요의 부하 분산기 가이드를 참조하세요.
자세한 내용은 다음 문서를 참조하세요.
백엔드 서비스 리소스에 사용 설정된 추가 기능
다음 선택적 기능은 일부 백엔드 서비스에서 지원됩니다.
Cloud CDN
Cloud CDN은 Google의 전역 에지 네트워크를 사용하여 사용자에게 더 가까운 곳에서 콘텐츠를 제공하므로 웹사이트와 애플리케이션 속도가 빨라집니다. Cloud CDN은 전역 외부 애플리케이션 부하 분산기에서 사용하는 백엔드 서비스에서 사용 설정됩니다. 부하 분산기는 요청을 수신하는 프런트엔드 IP 주소와 포트, 요청에 응답하는 백엔드를 제공합니다.
자세한 내용은 Cloud CDN 문서를 참고하세요.
Cloud CDN은 IAP와 호환되지 않습니다. 동일한 백엔드 서비스에서 사용 설정할 수 없습니다.
Google Cloud Armor
다음 부하 분산기 중 하나를 사용하는 경우 부하 분산기 생성 중에 백엔드 서비스에서 Google Cloud Armor를 사용 설정하여 애플리케이션 보안을 강화할 수 있습니다.
Google Cloud 콘솔을 사용하는 경우 다음 중 하나를 수행할 수 있습니다.
- 기존 Google Cloud Armor 보안 정책을 선택합니다.
- 맞춤설정 가능한 이름, 요청 수, 간격, 키, 비율 제한 매개변수를 사용하여 기본 Google Cloud Armor 비율 제한 보안 정책의 구성을 수락합니다. CDN 제공업체와 같은 업스트림 프록시 서비스와 함께 Google Cloud Armor를 사용하는 경우
Enforce_on_key를 XFF IP 주소로 설정해야 합니다. - 없음을 선택하여 Google Cloud Armor 보호를 선택 해제합니다.
IAP
IAP를 사용하면 HTTPS로 액세스할 수 있는 애플리케이션에 대해 중앙 승인 레이어를 설정할 수 있으므로, 네트워크 수준의 방화벽을 사용하는 대신 애플리케이션 수준의 액세스 제어 모델을 사용할 수 있습니다. IAP는 특정 애플리케이션 부하 분산기에서 지원됩니다.
IAP는 Cloud CDN과 호환되지 않습니다. 동일한 백엔드 서비스에서 사용 설정할 수 없습니다.
고급 트래픽 관리 기능
백엔드 서비스 및 부하 분산기와 연결된 URL 맵에 구성된 고급 트래픽 관리 기능에 대해 알아보려면 다음을 참고하세요.
API 및 gcloud 참조
백엔드 서비스 리소스의 속성에 대한 자세한 내용은 다음 참조를 확인하세요.
- 전역 백엔드 서비스 API 리소스
다음 단계
백엔드 서비스가 부하 분산에 사용되는 방법에 대한 관련 문서 및 정보를 보려면 다음을 검토합니다.
관련 동영상: