이 문서에서는 외부 애플리케이션 부하 분산기가 연결을 처리하고, 트래픽을 라우팅하고, 세션 어피니티를 유지하는 방법을 자세히 설명합니다.
연결 작동 방식
Trusted Cloud의 외부 애플리케이션 부하 분산기(전역 및 리전)는 분산 프록시(GFE) 또는 Envoy 관리 서브넷을 사용하여 라우팅을 간소화합니다. 구성 가능한 제한 시간, TLS 종료, 기본 제공 보안을 통해 전 세계 또는 리전에서 규정을 준수하는 확장 가능한 애플리케이션 제공을 보장합니다.
리전 외부 애플리케이션 부하 분산기 연결
리전 외부 애플리케이션 부하 분산기는 Envoy 프록시에 구현되는 관리형 서비스입니다.
리전 외부 애플리케이션 부하 분산기는 프록시 전용 서브넷이라는 공유 서브넷을 사용하여 Google에서 사용자를 대신하여 Envoy 프록시를 실행하는 데 사용하는 IP 주소 집합을 프로비저닝합니다. 이 프록시 전용 서브넷의 --purpose 플래그는 REGIONAL_MANAGED_PROXY로 설정됩니다. 특정 네트워크와 리전의 모든 리전 Envoy 기반 부하 분산기가 이 서브넷을 공유합니다.
클라이언트는 부하 분산기의 IP 주소와 포트를 사용하여 부하 분산기에 연결합니다. 클라이언트와 동일한 리전에 있는 프록시 전용 서브넷으로 클라이언트 요청이 전달됩니다. 부하 분산기에서 클라이언트 요청을 종료한 후 프록시 전용 서브넷에서 백엔드로 새 연결을 엽니다. 따라서 부하 분산기에서 전송된 패킷에는 프록시 전용 서브넷의 소스 IP 주소가 포함됩니다.
백엔드 서비스 구성에 따라 Envoy 프록시에서 백엔드에 연결하는 데 사용하는 프로토콜은 HTTP, HTTPS 또는 HTTP/2일 수 있습니다. HTTP 또는 HTTPS이면 HTTP 버전은 HTTP 1.1입니다. HTTP 연결 유지는 HTTP 1.1 사양에서 지정된 대로 기본적으로 사용 설정됩니다. Envoy 프록시는 클라이언트 HTTP 연결 유지 제한 시간과 백엔드 연결 유지 제한 시간을 기본 값인 각각 600초로 설정합니다. 클라이언트 HTTP 연결 유지 제한 시간을 업데이트할 수 있지만 백엔드 연결 유지 제한 시간 값은 고정되어 있습니다. 백엔드 서비스 제한 시간을 설정하여 요청/응답 제한 시간을 구성할 수 있습니다. 자세한 내용은 제한 시간 및 재시도를 참조하세요.
부하 분산기와의 클라이언트 통신
- 클라이언트는 HTTP 1.1 또는 HTTP/2 프로토콜을 사용하여 부하 분산기와 통신할 수 있습니다.
- HTTPS를 사용하면 최신 클라이언트는 HTTP/2로 기본 설정됩니다. 이는 HTTPS 부하 분산기가 아니라 클라이언트에서 제어됩니다.
- 부하 분산기에서 구성을 변경하여 HTTP/2를 사용 중지할 수는 없습니다. 하지만 일부 클라이언트는 HTTP/2 대신 HTTP 1.1을 사용하도록 구성할 수 있습니다. 예를 들어
curl과 함께--http1.1매개변수를 사용합니다. - 외부 애플리케이션 부하 분산기는
HTTP/1.1 100 Continue응답을 지원합니다.
각 모드의 외부 애플리케이션 부하 분산기 전달 규칙에서 지원하는 프로토콜의 전체 목록은 부하 분산기 기능을 참조하세요.
클라이언트 패킷의 소스 IP 주소
백엔드에서 인식하는 패킷의 소스 IP 주소는 부하 분산기의Trusted Cloud 외부 IP 주소가 아닙니다. 다시 말해 TCP 연결이 두 개 있습니다.
원래 클라이언트에서 부하 분산기(프록시 전용 서브넷)로의 연결 1:
- 소스 IP 주소: 원래 클라이언트 (또는 클라이언트가 NAT 게이트웨이 또는 전달 프록시 뒤에 있는 경우 외부 IP 주소)입니다.
- 대상 IP 주소: 부하 분산기의 IP 주소입니다.
부하 분산기(프록시 전용 서브넷)에서 백엔드 VM 또는 엔드포인트로의 연결 2:
소스 IP 주소: 동일한 리전 및 네트워크에 부하 분산기로 배포된 모든 Envoy 기반 부하 분산기에서 공유되는 프록시 전용 서브넷의 IP 주소입니다.
대상 IP 주소: VPC 네트워크의 백엔드 VM 또는 컨테이너의 내부 IP 주소입니다.
특수 라우팅 경로
Trusted Cloud 는 VPC 네트워크에 정의되지 않은 특수 경로를 사용해서 다음 유형의 트래픽에 대한 패킷을 라우팅합니다.
- 상태 확인의 경우 분산 Envoy 상태 확인을 제외합니다. 자세한 내용은 상태 확인 경로를 참조하세요.
Trusted Cloud 는 프록시 전용 서브넷에 대한 서브넷 경로를 사용하여 다음 유형의 트래픽에 대한 패킷을 라우팅합니다.
- 분산된 Envoy 상태 확인을 사용하는 경우
리전 외부 애플리케이션 부하 분산기에서는 Trusted Cloud 가 오픈소스 Envoy 프록시를 사용하여 부하 분산기에 대한 클라이언트 요청을 종료합니다. 부하 분산기가 TCP 세션을 종료하고 리전의 프록시 전용 서브넷에서 백엔드로 새 TCP 세션을 엽니다. VPC 네트워크 내에 정의된 경로가 Envoy 프록시와 백엔드의 상호 통신을 지원합니다.
TLS 종료
다음 표에서는 외부 애플리케이션 부하 분산기가 TLS 종료를 처리하는 방법을 요약해서 보여줍니다.
| 부하 분산기 모드 | TLS 종료 |
|---|---|
| 리전 외부 애플리케이션 부하 분산기 | TLS는 사용자가 선택한 리전의 프록시 전용 서브넷에 있는 Envoy 프록시에서 종료됩니다. TLS가 종료되는 리전을 지리적으로 제어해야 하는 경우 이 부하 분산기 모드를 사용합니다. |
제한 시간 및 재시도
백엔드 서비스 제한 시간
구성 가능한 백엔드 서비스 제한 시간은 부하 분산기에서 백엔드가 HTTP 요청을 처리하고 해당 HTTP 응답을 반환할 때까지 기다리는 최대 시간을 나타냅니다. 서버리스 NEG를 제외하고 백엔드 서비스 제한 시간의 기본값은 30초입니다.
예를 들어 500MB 파일을 다운로드하려는데 백엔드 서비스 제한 시간이 90초라면 부하 분산기는 백엔드가 500MB 파일 전체를 90초 이내에 전송할 것으로 예상합니다. 백엔드가 전체 HTTP 응답을 보내지 못할 정도로 짧게 백엔드 서비스 제한 시간을 구성할 수 있습니다. 이 경우 부하 분산기에 백엔드로부터의 HTTP 응답 헤더가 최소한 한 개 이상 있으면 부하 분산기가 전체 응답 헤더와 백엔드 서비스 제한 시간 내에 가능할 만큼 응답 본문을 반환합니다.
백엔드 서비스 제한 시간을 백엔드가 HTTP 응답을 처리하는 데 필요한 가장 긴 시간으로 설정하는 것이 좋습니다. 백엔드에서 실행 중인 소프트웨어가 HTTP 요청을 처리하고 전체 응답을 반환하는 데 더 많은 시간이 필요한 경우 백엔드 서비스 제한 시간을 늘리는 것이 좋습니다.
백엔드 서비스 제한 시간은 1~2,147,483,647초 사이의 값을 허용하지만 큰 값은 실용적인 구성 옵션이 아닙니다.
Trusted Cloud 는 기본 TCP 연결이 백엔드 서비스 제한 시간 값 전체에 대해 열린 상태로 유지된다고 보장하지 않습니다.
클라이언트 시스템은 TCP 연결을 사용하여 장시간 열어 두는 대신 재시도 로직을 구현해야 합니다.
백엔드 서비스 제한 시간을 구성하려면 다음 방법 중 하나를 사용하세요.
콘솔
부하 분산기의 백엔드 서비스의 제한 시간 필드를 수정합니다.
gcloud
gcloud compute backend-services update 명령어를 사용하여 백엔드 서비스 리소스의 --timeout 파라미터를 수정합니다.
클라이언트 HTTP 연결 유지 제한 시간
부하 분산기의 클라이언트 HTTP 연결 유지 제한 시간은 다운스트림 클라이언트 또는 프록시에서 사용하는 HTTP 연결 유지 (TCP 유휴 상태) 제한 시간보다 커야 합니다. 다운스트림 클라이언트의 HTTP 연결 유지(TCP 유휴 상태) 제한 시간이 부하 분산기의 클라이언트 HTTP 연결 유지 제한 시간보다 길면 경합 상태가 발생할 수 있습니다. 다운스트림 클라이언트의 관점에서 설정된 TCP 연결은 부하 분산기에서 허용하는 것보다 유휴 상태를 더 오랫동안 허용됩니다. 즉, 부하 분산기가 TCP 연결이 종료된 것으로 간주하면 다운스트림 클라이언트는 패킷을 전송할 수 있습니다. 이 경우 부하 분산기는 TCP 재설정(RST) 패킷으로 응답합니다.
클라이언트 HTTP 연결 유지 제한 시간이 만료되면 GFE 또는 Envoy 프록시가 클라이언트로 TCP FIN을 보내어 연결을 정상적으로 종료합니다.
백엔드 HTTP 연결 유지 제한 시간
각 요청 후 부하 분산기의 보조 TCP 연결이 닫히지 않을 수 있습니다. 개방형 상태로 유지하여 여러 HTTP 요청 및 응답을 처리할 수 있습니다. 백엔드 HTTP 연결 유지 제한 시간 제한은 TCP 부하 분산기와 백엔드 간의 TCP 유휴 상태 제한 시간을 정의합니다. 백엔드 HTTP 연결 유지 제한 시간은 WebSocket에 적용되지 않습니다.
백엔드 연결 유지 제한 시간은 10분(600초)으로 고정되며 변경할 수 없습니다. 따라서 부하 분산기가 최소 10분 동안 연결을 유휴 상태로 유지할 수 있습니다. 이 기간이 지나면 부하 분산기가 언제든지 백엔드에 종료 패킷을 보낼 수 있습니다.
부하 분산기의 백엔드 연결 유지 제한 시간은 백엔드에서 실행되는 소프트웨어에서 사용하는 연결 유지 제한 시간보다 짧아야 합니다. 이렇게 하면 백엔드의 운영체제가 TCP 재설정(RST)으로 TCP 연결을 종료할 가능성이 있는 경합 상태가 방지됩니다. 부하 분산기의 백엔드 연결 유지 제한 시간을 구성할 수 없으므로 HTTP 연결 유지 (TCP 유휴 상태) 제한 시간 값이 600초를 초과하도록 백엔드 소프트웨어를 구성해야 합니다.
백엔드 HTTP 연결 유지 제한 시간이 만료되면 GFE 또는 Envoy 프록시가 백엔드 VM으로 TCP FIN을 보내어 연결을 정상적으로 종료합니다.
다음 표에서는 일반적인 웹 서버 소프트웨어의 연결 유지 제한 시간 값을 수정할 때 필요한 변경사항을 보여줍니다.
| 웹 서버 소프트웨어 | 매개변수 | 기본 설정 | 권장 설정 |
|---|---|---|---|
| Apache | KeepAliveTimeout | KeepAliveTimeout 5 |
KeepAliveTimeout 620 |
| nginx | keepalive_timeout | keepalive_timeout 75s; |
keepalive_timeout 620s; |
WebSocket 프로토콜은 GKE 인그레스를 사용하여 지원됩니다.
잘못된 요청 및 응답 처리
부하 분산기는 여러 가지 이유로 클라이언트 요청과 백엔드 응답이 각각 백엔드 또는 클라이언트에 도달하지 못하도록 차단합니다. 이러한 이유로는 HTTP/1.1 준수를 위한 이유도 있고 예기치 않은 데이터가 백엔드로 또는 백엔드에서 전달되는 것을 방지하기 위한 이유도 있습니다. 사용 중지할 수 있는 검사가 없습니다.
부하 분산기는 HTTP/1.1 규정 준수를 위해 다음 요청과 같은 경우 차단을 수행합니다.
- 요청의 첫 번째 줄을 파싱할 수 없습니다.
- 헤더에 콜론(
:) 구분 기호가 없습니다. - 헤더 또는 첫 번째 줄에 잘못된 문자가 있습니다.
- 콘텐츠 길이가 유효한 숫자가 아니거나 콘텐츠 길이 헤더가 여러 개입니다.
- 전송 인코딩 키가 여러 개 있거나 인식할 수 없는 전송 인코딩 값이 존재합니다.
- 분할되지 않은 본문이 있으며 콘텐츠 길이가 지정되지 않았습니다.
- 본문 단위를 파싱할 수 없습니다. 이는 일부 데이터가 백엔드에 도달하는 유일한 경우입니다. 부하 분산기는 파싱할 수 없는 청크를 수신하면 클라이언트 및 백엔드와의 연결을 닫습니다.
요청 처리
다음 중 하나라도 해당하면 부하 분산기가 요청을 차단합니다.
- 요청 헤더와 요청 URL의 총 크기가 외부 애플리케이션 부하 분산기의 최대 요청 헤더 크기 한도를 초과합니다.
- 요청 메서드가 본문을 허용하지 않지만 요청에 본문이 존재합니다.
- 요청에
Upgrade헤더가 포함되어 있고 WebSocket 연결을 사용 설정하기 위해Upgrade헤더가 사용되지 않습니다. - HTTP 버전을 알 수 없습니다.
응답 처리
다음 중 하나라도 해당하면 부하 분산기가 백엔드의 응답을 차단합니다.
- 응답 헤더의 총 크기가 외부 애플리케이션 부하 분산기의 최대 응답 헤더 크기 한도를 초과합니다.
- HTTP 버전을 알 수 없습니다.
요청과 응답을 모두 처리할 때 부하 분산기는 HTTP/1.1에서 홉별 헤더를 삭제하거나 덮어쓰기한 후 대상에 전달할 수 있습니다.
트래픽 분산
백엔드 인스턴스 그룹 또는 NEG를 백엔드 서비스에 추가할 때 백엔드 로드 및 대상 용량을 측정하는 방법을 정의하는 분산 모드를 지정합니다. 외부 애플리케이션 부하 분산기는 두 가지 분산 모드를 지원합니다.
인스턴스 그룹 또는 NEG의 경우
RATE는 초당 최대 대상 요청(쿼리) 수(RPS, QPS)입니다. 모든 최대 백엔드가 용량에 도달하거나 용량을 초과할 경우 대상 최대 RPS/QPS를 초과할 수 있습니다.UTILIZATION은 인스턴스 그룹에 있는 VM의 백엔드 사용률입니다.
백엔드 간에 트래픽이 분산되는 방식은 부하 분산기의 모드에 따라 다릅니다.
리전 외부 애플리케이션 부하 분산기
리전 외부 애플리케이션 부하 분산기의 경우 트래픽 분산은 부하 분산 모드 및 부하 분산 지역 정책을 기반으로 합니다.
분산 모드에 따라 각 그룹 (인스턴스 그룹 또는 NEG)으로 전송되는 트래픽의 가중치 및 비율이 결정됩니다. 부하 분산 지역 정책(LocalityLbPolicy)에 따라 그룹 내 백엔드의 부하 분산 방식이 결정됩니다.
백엔드 서비스가 트래픽을 수신하면 백엔드의 분산 모드에 따라 백엔드(인스턴스 그룹 또는 NEG)로 트래픽을 전달합니다. 백엔드가 선택되면 부하 분산 지역 정책에 따라 해당 백엔드 그룹의 인스턴스 또는 엔드포인트 간에 트래픽이 분산됩니다.
자세한 내용은 다음을 참조하세요.
세션 어피니티
애플리케이션 부하 분산기의 백엔드 서비스에 구성된 세션 어피니티는 정상 백엔드 인스턴스 또는 엔드포인트의 수가 일정하게 유지되고 이전에 선택한 백엔드 인스턴스 또는 엔드포인트의 용량이 충분한 경우 특정 클라이언트의 요청을 동일한 백엔드로 전송하려고 합니다. 분산 모드의 대상 용량은 백엔드가 언제 용량에 도달하는지를 결정합니다.
다음 표에는 다양한 애플리케이션 부하 분산기에서 지원되는 다양한 세션 어피니티 옵션이 나와 있습니다. 다음 섹션인 세션 어피니티 유형에서는 각 세션 어피니티 유형을 자세히 설명합니다.
| 제품 | 세션 어피니티 옵션 |
|---|---|
또한 다음을 참고하세요
|
세션 어피니티를 구성할 때 다음 사항에 유의하세요.
인증 또는 보안 목적으로 세션 어피니티를 사용하지 않습니다. 스테이트풀(Stateful) 쿠키 기반 세션 어피니티를 제외한 세션 어피니티는 제공 및 정상 백엔드 수가 변경될 때마다 중단될 수 있습니다. 자세한 내용은 세션 어피니티 손실을 참조하세요.
--session-affinity및--subsetting-policy플래그의 기본값은 모두NONE이며 한 번에 하나만 다른 값으로 설정할 수 있습니다.
세션 어피니티 유형
외부 애플리케이션 부하 분산기의 세션 어피니티는 다음 카테고리 중 하나로 분류할 수 있습니다.- 해시 기반 세션 어피니티 (
NONE,CLIENT_IP) - HTTP 헤더 기반 세션 어피니티 (
HEADER_FIELD) - 쿠키 기반 세션 어피니티 (
GENERATED_COOKIE,HTTP_COOKIE,STRONG_COOKIE_AFFINITY)
해시 기반 세션 어피니티
해시 기반 세션 어피니티의 경우 부하 분산기는 일관된 해싱 알고리즘을 사용하여 적격한 백엔드를 선택합니다. 세션 어피니티 설정은 해시를 계산하는 데 사용되는 IP 헤더의 필드를 결정합니다.
해시 기반 세션 어피니티는 다음 유형 중 하나일 수 있습니다.
없음
세션 어피니티를 NONE으로 설정한다고 해서 세션 어피니티가 없다는 의미는 아닙니다. 명시적으로 구성된 세션 어피니티 옵션이 없음을 의미합니다.
해싱은 항상 백엔드를 선택하기 위해 실행됩니다. 세션 어피니티 설정이 NONE이면 부하 분산기가 5튜플 해시를 사용하여 백엔드를 선택합니다. 5-튜플 해시는 소스 IP 주소, 소스 포트, 프로토콜, 대상 IP 주소, 대상 포트로 구성되어 있습니다.
세션 어피니티의 기본값은 NONE입니다.
클라이언트 IP 어피니티
클라이언트 IP 세션 어피니티 (CLIENT_IP)는 패킷의 소스 및 대상 IP 주소에서 생성된 2튜플 해시입니다. 클라이언트 IP 어피니티는 백엔드가 정상이고 용량이 있는 한 동일한 클라이언트 IP 주소의 모든 요청을 동일한 백엔드로 전달합니다.
클라이언트 IP 어피니티를 사용할 때는 다음 사항에 유의하세요.
- 패킷 대상 IP 주소는 패킷이 부하 분산기로 직접 전송되는 경우에만 부하 분산기 전달 규칙의 IP 주소와 동일합니다.
- 패킷이 Trusted Cloud 부하 분산기에 전송되기 전에 중간 NAT 또는 프록시 시스템에서 처리되는 경우 패킷 소스 IP 주소가 원래 클라이언트와 연결된 IP 주소와 일치하지 않을 수 있습니다. 여러 클라이언트가 동일한 유효 소스 IP 주소를 공유하는 경우 일부 백엔드 VM은 다른 VM보다 더 많은 연결 또는 요청을 수신할 수 있습니다.
HTTP 헤더 기반 세션 어피니티
헤더 필드 어피니티 (HEADER_FIELD)를 사용하면 백엔드 서비스의 consistentHash.httpHeaderName 필드에 있는 HTTP 헤더의 값을 기반으로 요청이 백엔드로 라우팅됩니다. 사용 가능한 모든 백엔드에 요청을 분산하려면 각 클라이언트가 서로 다른 HTTP 헤더 값을 사용해야 합니다.
헤더 필드 어피니티는 다음 조건이 충족되는 경우에 지원됩니다.
- 부하 분산 지역 정책이
RING_HASH또는MAGLEV입니다. - 백엔드 서비스의
consistentHash가 HTTP 헤더의 이름(httpHeaderName)을 지정합니다.
쿠키 기반 세션 어피니티
쿠키 기반 세션 어피니티는 다음 유형 중 하나일 수 있습니다.
생성된 쿠키 어피니티
생성된 쿠키 기반 어피니티 (GENERATED_COOKIE)를 사용하면 부하 분산기가 초기 HTTP 요청에 대한 응답의 Set-Cookie 헤더에 HTTP 쿠키를 포함합니다.
생성된 쿠키의 이름은 부하 분산기 유형에 따라 다릅니다.
| 제품 | 쿠키 이름 |
|---|---|
| 전역 외부 애플리케이션 부하 분산기 | GCLB |
| 기존 애플리케이션 부하 분산기 | GCLB |
| 리전 외부 애플리케이션 부하 분산기 | GCILB |
생성된 쿠키의 경로 속성은 항상 슬래시 (/)이므로 다른 백엔드 서비스도 생성된 쿠키 어피니티를 사용하는 경우 동일한 URL 맵의 모든 백엔드 서비스에 적용됩니다.
affinityCookieTtlSec 백엔드 서비스 파라미터를 사용하여 쿠키의 TTL (수명) 값을 0~1,209,600초 (양 끝값 포함)로 구성할 수 있습니다. affinityCookieTtlSec이 지정되지 않은 경우 기본 TTL 값은 0입니다.
클라이언트가 HTTP 요청의 Cookie 요청 헤더에 생성된 세션 어피니티 쿠키를 포함하면 세션 어피니티 쿠키가 유효한 경우 부하 분산기가 이러한 요청을 동일한 백엔드 인스턴스 또는 엔드포인트로 전달합니다. 쿠키 값을 특정 백엔드 인스턴스 또는 엔드포인트를 참조하는 색인에 매핑하고 생성된 쿠키 세션 어피니티 요구사항이 충족되는지 확인하여 이 작업을 실행합니다.
생성된 쿠키 어피니티를 사용하려면 다음과 같은 균형 조정 모드와 localityLbPolicy 설정을 구성합니다.
- 백엔드 인스턴스 그룹의 경우
RATE분산 모드를 사용합니다. - 백엔드 서비스의
localityLbPolicy에는RING_HASH또는MAGLEV를 사용합니다.localityLbPolicy를 명시적으로 설정하지 않으면 부하 분산기는MAGLEV를 암시적 기본값으로 사용합니다.
자세한 내용은 세션 어피니티 손실을 참조하세요.
HTTP 쿠키 어피니티
HTTP 쿠키 기반 어피니티 (HTTP_COOKIE)를 사용하면 부하 분산기가 초기 HTTP 요청에 대한 응답의 Set-Cookie 헤더에 HTTP 쿠키를 포함합니다. 쿠키의 이름, 경로, TTL(수명)을 지정합니다.
모든 애플리케이션 부하 분산기는 HTTP 쿠키 기반 어피니티를 지원합니다.
다음 백엔드 서비스 파라미터와 유효한 값을 사용하여 초, 1초 미만의 값(나노초) 또는 초와 1초 미만의 값(나노초) 모두를 사용하여 쿠키의 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) 쿠키 기반 세션 어피니티
상태 저장 쿠키 기반 어피니티 (STRONG_COOKIE_AFFINITY)를 사용하면 부하 분산기가 초기 HTTP 요청에 대한 응답의 Set-Cookie 헤더에 HTTP 쿠키를 포함합니다. 쿠키의 이름, 경로, TTL (수명)을 지정합니다.
다음 부하 분산기는 스테이트풀(Stateful) 쿠키 기반 어피니티를 지원합니다.
- 리전 외부 애플리케이션 부하 분산기
- 리전 내부 애플리케이션 부하 분산기
초, 1초 미만의 값(나노초) 또는 초와 1초 미만의 값(나노초) 모두를 사용하여 쿠키의 TTL 값을 구성할 수 있습니다.
strongSessionAffinityCookie.ttl로 표시되는 기간은 2주(1,209,600초)를 초과하는 값으로 설정할 수 없습니다.
쿠키의 값은 선택된 인스턴스 또는 엔드포인트를 값 자체에 인코딩하여 선택된 백엔드 인스턴스 또는 엔드포인트를 식별합니다. 쿠키가 유효한 한 클라이언트가 후속 HTTP 요청의 Cookie 요청 헤더에 세션 어피니티 쿠키를 포함하면 부하 분산기는 이러한 요청을 선택한 백엔드 인스턴스 또는 엔드포인트로 전달합니다.
다른 세션 어피니티 방법과의 차이점:
스테이트풀(Stateful) 쿠키 기반 어피니티에는 분산 모드 또는 부하 분산 지역 정책(
localityLbPolicy)에 관한 특정한 요구사항이 없습니다.자동 확장이 관리형 인스턴스 그룹에 새 인스턴스를 추가할 때 스테이트풀(Stateful) 쿠키 기반 어피니티는 영향을 받지 않습니다.
선택한 인스턴스가 삭제되지 않는 한 자동 확장이 관리형 인스턴스 그룹에서 인스턴스를 삭제할 때 스테이트풀(Stateful) 쿠키 기반 어피니티는 영향을 받지 않습니다.
선택한 인스턴스가 삭제되지 않는 한 자동 복구가 관리형 인스턴스 그룹에서 인스턴스를 삭제할 때 스테이트풀(Stateful) 쿠키 기반 어피니티는 영향을 받지 않습니다.
자세한 내용은 세션 어피니티 손실을 참조하세요.
쿠키 기반 어피니티 TTL 0의 의미
생성된 쿠키 어피니티, HTTP 쿠키 어피니티, 스테이트풀 쿠키 기반 어피니티와 같은 모든 쿠키 기반 세션 어피니티에는 TTL 속성이 있습니다.
TTL이 0초이면 부하 분산기가 쿠키에 Expires 속성을 할당하지 않습니다. 이 경우 클라이언트는 쿠키를 세션 쿠키로 취급합니다. 세션의 정의는 클라이언트에 따라 다릅니다.
웹브라우저와 같은 일부 클라이언트는 전체 탐색 세션 동안 쿠키를 유지합니다. 즉, 애플리케이션이 닫힐 때까지 여러 요청에 걸쳐 쿠키가 유지됩니다.
세션을 단일 HTTP 요청으로 취급하여 쿠키를 즉시 삭제하는 클라이언트도 있습니다.
세션 어피니티 상실
모든 세션 어피니티 옵션에는 다음이 필요합니다.
- 선택한 백엔드 인스턴스 또는 엔드포인트는 백엔드로 구성된 상태를 유지해야 합니다. 다음 이벤트 중 하나가 발생하면 세션 어피니티가 중단될 수 있습니다.
- 선택한 인스턴스를 인스턴스 그룹에서 삭제합니다.
- 관리형 인스턴스 그룹 자동 확장 또는 자동 복구로 인해 선택한 인스턴스가 관리형 인스턴스 그룹에서 삭제됩니다.
- 선택한 엔드포인트를 NEG에서 삭제합니다.
- 선택한 인스턴스 또는 엔드포인트가 포함된 인스턴스 그룹 또는 NEG를 백엔드 서비스에서 삭제합니다.
- 선택한 백엔드 인스턴스 또는 엔드포인트가 정상 상태로 유지되어야 합니다. 선택한 인스턴스 또는 엔드포인트가 상태 점검에 실패하면 세션 어피니티가 손상될 수 있습니다.
- 전역 외부 애플리케이션 부하 분산기 및 기본 애플리케이션 부하 분산기의 경우 라우팅 경로가 변경된 후 후속 요청 또는 연결에 다른 첫 번째 레이어 Google 프런트엔드 (GFE)가 사용되면 세션 어피니티가 중단될 수 있습니다. 인터넷의 클라이언트에서 Google로의 라우팅 경로가 요청 또는 연결 간에 변경되면 다른 첫 번째 레이어 GFE가 선택될 수 있습니다.
선택한 인스턴스 또는 엔드포인트가 포함된 인스턴스 그룹 또는 NEG가 대상 용량에서 정의된 대로 가득 차서는 안 됩니다. (리전 관리형 인스턴스 그룹의 경우 선택한 인스턴스가 포함된 인스턴스 그룹의 영역 구성요소가 가득 차서는 안 됩니다.) 인스턴스 그룹 또는 NEG가 가득 차고 다른 인스턴스 그룹 또는 NEG는 가득 차지 않은 경우 세션 어피니티가 손상될 수 있습니다.
UTILIZATION분산 모드를 사용할 때는 가득 찬 상태가 예측 불가능한 방식으로 변경될 수 있으므로RATE또는CONNECTION분산 모드를 사용하여 세션 어피니티가 손상될 수 있는 상황을 최소화해야 합니다.구성된 백엔드 인스턴스 또는 엔드포인트의 총 개수는 일정하게 유지되어야 합니다. 다음 이벤트 중 하나 이상이 발생하면 구성된 백엔드 인스턴스 또는 엔드포인트 수가 변경되고 세션 어피니티가 손상될 수 있습니다.
새 인스턴스 또는 엔드포인트 추가:
- 백엔드 서비스의 기존 인스턴스 그룹에 인스턴스를 추가합니다.
- 관리형 인스턴스 그룹 자동 확장으로 인해 백엔드 서비스의 관리형 인스턴스 그룹에 인스턴스가 추가됩니다.
- 백엔드 서비스의 기존 NEG에 엔드포인트를 추가합니다.
- 백엔드 서비스에 비어 있지 않은 백엔드 인스턴스 그룹 또는 NEG를 추가합니다.
선택한 인스턴스 또는 엔드포인트뿐만 아니라 모든 인스턴스 또는 엔드포인트 삭제:
- 인스턴스 그룹 백엔드에서 인스턴스를 삭제하는 경우
- 관리형 인스턴스 그룹 자동 확장 또는 자동 복구로 인해 관리형 인스턴스 그룹 백엔드에서 인스턴스가 삭제됩니다.
- NEG 백엔드에서 엔드포인트를 삭제합니다.
- 백엔드 서비스에서 비어 있지 않은 기존 백엔드 인스턴스 그룹 또는 NEG를 삭제합니다.
정상 백엔드 인스턴스 또는 엔드포인트의 총 개수는 일정하게 유지되어야 합니다. 다음 이벤트 중 하나 이상이 발생하면 정상적인 백엔드 인스턴스 또는 엔드포인트 수가 변경되고 세션 어피니티가 손상될 수 있습니다.
- 인스턴스 또는 엔드포인트가 상태 점검을 통과하여 비정상 상태에서 정상 상태로 전환됩니다.
- 인스턴스 또는 엔드포인트가 상태 점검에 실패하여 정상 상태에서 비정상 상태 또는 시간 초과로 전환됩니다.