백엔드 서비스 이해

백엔드 서비스는 다음 Google Cloud 부하 분산 서비스의 구성 값을 포함하는 필드가 있는 리소스입니다.

  • 외부 HTTP(S) 부하 분산
  • 내부 HTTP(S) 부하 분산
  • SSL 프록시 부하 분산
  • TCP 프록시 부하 분산
  • 내부 TCP/UDP 부하 분산

네트워크 부하 분산은 백엔드 서비스를 사용하지 않습니다.

부하 분산기는 백엔드 서비스 리소스의 구성 정보를 다음 기능에 사용합니다.

  • 올바른 백엔드(인스턴스 그룹 또는 네트워크 엔드포인트 그룹)로 트래픽 전달
  • 분산 모드에 따라 트래픽 분산 분산 모드는 백엔드의 백엔드 서비스에 정의되어 있습니다.
  • 백엔드 서비스에 지정된 상태 확인을 사용하여 백엔드 상태 모니터링
  • 세션 어피니티 유지

아키텍처

부하 분산기당 백엔드 서비스의 수는 부하 분산기 유형에 따라 다릅니다.

부하 분산기 유형 백엔드 서비스 수
외부 HTTP(S) 부하 분산 복수
내부 HTTP(S) 부하 분산 복수
SSL 프록시 부하 분산 1
TCP 프록시 부하 분산 1
내부 TCP/UDP 부하 분산 1

각 백엔드 서비스에는 백엔드가 하나 이상 포함됩니다.

어떤 백엔드 서비스건 간에 모든 백엔드는 인스턴스 그룹 또는 네트워크 엔드포인트 그룹이어야 합니다. 여러 유형의 인스턴스 그룹(예: 관리형 및 비관리형 인스턴스 그룹)을 동일한 백엔드 서비스와 연결할 수 있지만 인스턴스 그룹과 네트워크 엔드포인트 그룹은 동일한 백엔드 서비스와 연결할 수 없습니다.

백엔드 서비스 설정

각 백엔드 서비스에는 다음과 같은 구성 가능한 설정이 있습니다.

  • 세션 어피니티(선택사항). 일반적으로 부하 분산기는 해시 알고리즘을 사용하여 요청을 사용 가능한 인스턴스에 분산합니다. 일반적으로 해시는 소스 IP 주소, 대상 IP 주소, 소스 포트, 대상 포트, 프로토콜(5-튜플 해시)을 기반으로 합니다. 세션 어피니티는 해시에 포함된 항목을 조정하고 동일한 클라이언트의 모든 요청을 동일한 가상 머신 인스턴스로 보내려고 시도합니다.
  • 백엔드 서비스 제한 시간. 이 값은 사용되는 부하 분산기 및 프로토콜의 유형에 따라 다양한 방식으로 해석됩니다.
    • HTTP(S) 부하 분산기의 경우 백엔드 서비스 제한 시간은 요청/응답 제한 시간입니다(WebSocket 프로토콜을 사용하도록 업그레이드된 연결은 제외).
    • WebSocket 트래픽을 HTTP(S) 부하 분산기로 전송할 때 백엔드 서비스 제한 시간은 유휴 또는 활성 WebSocket이 열린 상태로 유지될 수 있는 최대 시간으로 해석됩니다.
    • SSL 프록시 또는 TCP 프록시 부하 분산기의 경우 백엔드 서비스 제한 시간은 모든 트래픽에 대한 유휴 시간 제한으로 해석됩니다.
    • 내부 TCP/UDP 부하 분산기의 경우 백엔드 서비스 시간 제한 매개 변수는 무시됩니다.
  • 상태 확인. 상태 확인기는 백엔드 서비스에 연결된 인스턴스를 구성된 간격으로 폴링합니다. 상태 확인을 통과한 인스턴스는 새로운 요청을 수신하도록 허용됩니다. 비정상적인 인스턴스는 다시 정상이 될 때까지 요청이 전송되지 않습니다.

백엔드 서비스를 사용할 때 이용 가능한 속성의 설명은 백엔드 서비스 API 리소스 또는gcloud 명령줄 도구 사용자 가이드를 참조하세요.

백엔드

백엔드 서비스 하나에 백엔드를 여러 개 추가할 수 있습니다. 각 백엔드는 Google Cloud 부하 분산기가 트래픽을 분산하는 리소스입니다. 백엔드로 사용할 수 있는 리소스에는 다음과 같은 세 가지 유형이 있습니다.

어떤 백엔드 서비스건 간에 백엔드는 모두 인스턴스 그룹이거나 지원되는 경우 NEG 또는 백엔드 버킷이어야 합니다. 동일한 백엔드 서비스에는 여러 유형의 백엔드를 사용할 수 없습니다. 추가 사항:

  • 내부 TCP/UDP 부하 분산기의 백엔드는 인스턴스 그룹 백엔드만 지원합니다.
  • HTTP(S) 부하 분산기에 2개 이상의 백엔드 서비스가 있는 경우 한 백엔드 서비스의 백엔드로는 인스턴스 그룹을, 다른 백엔드 서비스의 백엔드로는 NEG를 사용할 수 있습니다.

백엔드 및 외부 IP 주소

백엔드 VM에는 외부 IP 주소가 필요하지 않습니다.

  • HTTP(S), SSL 프록시, TCP 프록시 부하 분산기: 클라이언트는 부하 분산기의 외부 IP 주소를 사용하여 Google 프런트 엔드(GFE)와 통신합니다. GFE는 기본 네트워크 인터페이스의 내부 IP 주소를 사용하여 백엔드 VM과 통신합니다. GFE는 프록시이므로 백엔드 VM 자체에는 외부 IP 주소가 필요하지 않습니다.

  • 네트워크 부하 분산기: 네트워크 부하 분산기는 양방향 네트워크 주소 변환(NAT)을 사용하여 패킷을 라우팅합니다. 백엔드 VM은 클라이언트에 응답을 보낼 때 부하 분산기 전달 규칙의 외부 IP 주소를 소스 IP 주소로 사용합니다.

  • 내부 부하 분산기: 내부 부하 분산기의 백엔드 VM에는 외부 IP 주소가 필요하지 않습니다.

트래픽 분산

백엔드 서비스 리소스의 다음 필드 값에 따라 백엔드 동작의 몇 가지 측면이 결정됩니다.

  • 분산 모드. 이 모드는 부하 분산 시스템에 백엔드가 전체 사용 상태에 도달한 때를 확인하는 방법을 알려줍니다. 한 리전에 있는 백엔드 서비스의 모든 백엔드가 모두 사용 중이면 새로운 요청은 요청을 처리할 수 있는 가장 가까운 리전으로 자동으로 라우팅됩니다. 분산 모드는 연결, 백엔드 사용률, 초당 요청(속도)을 기준으로 합니다.
  • 용량 설정. 용량은 분산 모드 설정과 상호작용하는 추가 관리 옵션입니다. 예를 들어 일반적으로 인스턴스가 최대 80%의 백엔드 사용률로 작동하도록 하려면 분산 모드를 백엔드 사용률로 설정하고 용량을 80%로 설정합니다. 인스턴스 사용률을 절반으로 줄이려면 용량을 80% 백엔드 사용률로 유지하고 용량 확장 처리를 0.5로 설정합니다. 백엔드 서비스를 드레이닝하려면 용량 확장 처리를 0으로 설정하고 용량은 그대로 유지합니다. 용량 및 백엔드 사용률에 대한 자세한 내용은 CPU 또는 부하 분산 제공 용량을 기준으로 확장을 참조하세요.

다음에 유의하세요.

  • 동일한 백엔드 서비스에 연결된 백엔드 인스턴스 그룹의 모든 인스턴스에 대한 평균 사용률이 10% 미만인 경우 GCP에서 특정 영역을 우선 선택할 수 있습니다. 이는 관리형 리전 인스턴스 그룹, 관리형 영역 인스턴스 그룹, 비관리형 영역 인스턴스 그룹을 사용하는 경우에 발생할 수 있습니다. 부하 분산기로 더 많은 트래픽이 전송되면 이 영역 불균형은 자동으로 해결됩니다. 다른 리전의 백엔드 서비스는 영향을 주지 않습니다.

Traffic Director도 백엔드 서비스 리소스를 사용합니다. 특히 Traffic Director는 부하 분산 스키마가 INTERNAL_SELF_MANAGED인 백엔드 서비스를 사용합니다. 내부 자체 관리형 백엔드 서비스의 경우 부하 분산 모드부하 분산 정책을 함께 사용하여 트래픽 분산을 수행합니다. 백엔드 서비스는 백엔드의 분산 모드에 따라 백엔드(인스턴스 그룹 또는 NEG)로 트래픽을 전달합니다. 이후 백엔드가 선택되면 Traffic Director가 부하 분산 정책에 따라 트래픽을 분산합니다.

내부 자체 관리형 백엔드 서비스는 다음 분산 모드를 지원합니다.

  • UTILIZATION - 모든 백엔드가 인스턴스 그룹인 경우
  • RATE - 모든 백엔드가 인스턴스 그룹 또는 NEG인 경우

RATE 분산 모드를 선택하는 경우 백엔드, 인스턴스, 엔드포인트당 최대 속도를 지정해야 합니다.

백엔드 프로토콜

백엔드 서비스를 만들 때는 백엔드와의 통신에 사용되는 프로토콜을 지정해야 합니다. 백엔드 서비스는 프로토콜을 하나만 사용할 수 있습니다. 대체 프로토콜로 사용할 보조 프로토콜을 지정할 수 없습니다.

사용 가능한 프로토콜은 다음과 같습니다.

  • HTTP
  • HTTPS
  • HTTP/2
  • SSL
  • TCP
  • UDP

유효한 프로토콜은 부하 분산 스키마를 포함하여 만드는 부하 분산기의 유형에 따라 다릅니다. 백엔드 서비스에 사용할 수 있는 프로토콜에 대한 자세한 내용은 부하 분산기 유형별 설명서를 참조하세요.

백엔드 프로토콜인 HTTP/2는 인그레스를 사용한 부하 분산에도 사용할 수 있습니다.

백엔드 서비스의 프로토콜을 변경하면 로드 밸런서를 통해 백엔드에 몇 분 동안 액세스할 수 없습니다.

인스턴스 그룹

백엔드 서비스 및 자동 확장되는 관리형 인스턴스 그룹

자동 확장되는 관리형 인스턴스 그룹은 같은 방식으로 구성된 많은 수의 머신이 필요하고 필요에 따라 인스턴스를 자동으로 추가하거나 삭제하려는 경우에 유용합니다.

자동 확장 비율은 백엔드 서비스 분산 모드에서 작동합니다. 예를 들어 분산 모드를 백엔드 사용률 80%로 설정하고 용량 확장 처리를 100%로 둔 상태에서 자동 확장 처리의 대상 부하 분산 사용량을 80%로 설정한다고 가정해 보겠습니다. 그룹의 백엔드 사용률이 64%(80%의 80%)를 넘어 상승할 때마다 사용량이 약 64%로 감소할 때까지 자동 확장 처리가 템플릿에서 새로운 인스턴스를 인스턴스화합니다. 전체 사용량이 64% 미만으로 떨어지면 사용량이 64%로 되돌아 올 때까지 자동 확장 처리가 인스턴스를 삭제합니다.

새 인스턴스는 그룹의 일부로 간주되기 전에 휴지 시간이 있으므로 이 시간 동안 트래픽이 백엔드 서비스의 80% 백엔드 사용량을 초과할 수 있으며, 이로 인해 초과 트래픽이 다음으로 사용 가능한 백엔드 서비스로 라우팅됩니다. 인스턴스를 사용할 수 있게 되면 새 트래픽이 이 인스턴스로 라우팅됩니다. 또한 인스턴스 수가 자동 확장 처리의 설정에서 허용하는 최댓값에 도달하면 자동 확장 처리는 사용량에 관계없이 인스턴스 추가를 중지합니다. 이 경우, 추가 트래픽은 다음으로 사용 가능한 리전에 부하 분산됩니다.

자동 확장되는 관리형 인스턴스 그룹 구성

자동 확장되는 관리형 인스턴스 그룹을 구성하려면 다음 안내를 따르세요.

  1. 인스턴스 그룹의 인스턴스 템플릿을 만듭니다.
  2. 관리형 인스턴스 그룹을 만들고 여기에 템플릿을 할당합니다.
  3. 부하 분산 제공 용량을 기준으로 자동 확장 기능을 설정합니다.

인스턴스 그룹에 대한 제한 및 지침

Cloud Load Balancing은 부하 분산을 구성하는 방법에 유연성을 제공하므로 제대로 작동하지 않는 구성을 만들 개연성이 있습니다. 부하 분산과 함께 사용할 인스턴스 그룹을 만들 때는 다음과 같은 제한 및 지침에 유의하세요.

  • 가상 머신 인스턴스를 2개 이상의 인스턴스 그룹에 두지 마세요.
  • 인스턴스 그룹이 백엔드에서 사용 중인 경우 인스턴스 그룹을 삭제하지 마세요.
  • 서로 다른 두 개의 백엔드에 동일한 인스턴스 그룹을 추가하지 않으면 구성이 더 간단해집니다. 2개의 백엔드에 동일한 인스턴스 그룹을 추가하는 경우에는 다음 지침을 따르세요.
    • 두 개의 백엔드가 모두 UTILIZATION 또는 RATE와 같은 부하 분산 모드를 사용해야 합니다.
    • maxRatePerInstancemaxRatePerGroup를 함께 사용할 수 있습니다. 백엔드 중 하나는 maxRatePerInstance를 사용하도록 설정하고 다른 하나는 maxRatePerGroup을 사용하도록 설정할 수 있습니다.
    • 인스턴스 그룹이 여러 개의 백엔드에 각각 두 개 이상의 포트를 제공하는 경우에는 인스턴스 그룹에서 포트 이름을 서로 다르게 지정해야 합니다.
  • 관리형 인스턴스 그룹 또는 비관리형 인스턴스 그룹 내의 모든 인스턴스는 동일한 VPC 네트워크에 있어야 하며, 적용 가능한 경우 동일한 서브넷에 있어야 합니다.
  • 자동 확장 기능이 있는 관리형 인스턴스 그룹을 사용하는 경우 백엔드 서비스에서 maxRate 분산 모드를 사용하지 마세요. maxUtilization 또는 maxRatePerInstance 모드를 사용하세요.
  • 자동 확장되는 관리형 인스턴스 그룹을 서로 다른 두 개의 부하 분산기의 대상으로 설정하지 마세요.
  • 관리형 인스턴스 그룹의 크기를 조정할 때 그룹의 최대 크기는 서브넷 크기보다 작거나 같아야 합니다.

네트워크 엔드포인트 그룹

네트워크 엔드포인트는 다음 두 가지 방법 중 하나로 지정된 IP 주소와 포트의 조합입니다.

  • 10.0.1.1:80과 같은 IP address:port 쌍을 지정합니다.
  • 네트워크 엔드포인트 IP 주소만 지정합니다. NEG의 기본 포트는 자동으로 IP address:port 쌍의 포트로 사용됩니다.

네트워크 엔드포인트는 특정 VM을 참조하는 대신 IP 주소 및 포트별로 서비스를 나타냅니다. 네트워크 엔드포인트 그룹(NEG)은 네트워크 엔드포인트의 논리적 그룹입니다.

네트워크 엔드포인트 그룹을 백엔드로 사용하는 백엔드 서비스는 VM 인스턴스 내에서 실행되는 애플리케이션 또는 컨테이너 간에 트래픽을 분산합니다. 자세한 내용은 부하 분산의 네트워크 엔드포인트 그룹 개념을 참조하세요.

세션 어피니티

세션 어피니티가 없으면 부하 분산기는 백엔드 인스턴스 그룹 또는 NEG의 분산 모드에 따라 새 요청을 분산합니다. 내부 캐싱이 많이 이루어지는 광고 게재, 게임, 서비스에서 사용하는 스테이트풀(Stateful) 서버와 같은 일부 애플리케이션은 특정 사용자의 여러 요청을 동일한 인스턴스로 전달해야 합니다.

세션 어피니티는 클라이언트의 IP 주소나 쿠키의 값과 같은 매개변수를 기반으로 동일한 클라이언트의 TCP 트래픽을 식별하고 백엔드가 정상이고 용량이 있는 동일한 백엔드 인스턴스로 해당 요청을 전달하여 이를 가능하게 합니다.

UDP 세션은 단일 요청 및 응답이므로 세션 어피니티가 UDP 트래픽에 미치는 유의미한 영향은 거의 없습니다.

인스턴스가 정상이 아니거나 과부하 상태면 세션 어피니티가 손상될 수 있으므로 완벽한 어피니티를 가정해서는 안 됩니다.

HTTP(S) 부하 분산의 경우 세션 어피니티는 RATE 분산 모드에서 가장 잘 작동합니다.

다음 표에 요약된 것처럼 부하 분산기마다 지원하는 세션 어피니티 옵션이 다릅니다.

부하 분산기 세션 어피니티 옵션
내부 • 없음
• 클라이언트 IP
• 클라이언트 IP 및 프로토콜
• 클라이언트 IP, 프로토콜 및 포트
TCP 프록시
SSL 프록시
• 없음
• 클라이언트 IP
HTTP(S) • 없음
• 클라이언트 IP
• 생성된 쿠키
네트워크 네트워크 부하 분산은 백엔드 서비스를 사용하지 않습니다. 대신 대상 풀을 통해 네트워크 부하 분산기의 세션 어피니티를 설정합니다. 대상 풀sessionAffinity 매개변수를 참조하세요.

다음 섹션에서는 세션 어피니티의 두 가지 일반적인 유형에 대해 설명합니다.

클라이언트 IP 어피니티 사용

클라이언트 IP 어피니티는 클라이언트 IP 주소의 해시를 기반으로 동일한 클라이언트 IP 주소의 요청을 동일한 백엔드 인스턴스로 전달합니다. 클라이언트 IP 어피니티는 백엔드 서비스를 사용하는 모든 Google Cloud 부하 분산기에 대한 옵션입니다.

클라이언트 IP 어피니티를 사용할 때는 다음 사항에 유의하세요.

  • 부하 분산기에 표시되는 클라이언트 IP 주소는 NAT 뒤에 있거나 프록시를 통해 요청하는 경우 발신 클라이언트가 아닐 수 있습니다. NAT 또는 프록시를 통한 요청은 NAT 라우터 또는 프록시의 IP 주소를 클라이언트 IP 주소로 사용합니다. 이로 인해 수신 트래픽이 불필요하게 동일한 백엔드 인스턴스에 집중될 수 있습니다.

  • 클라이언트가 기존 네트워크에서 다른 네트워크로 이동하면 IP 주소가 변경되어 어피니티가 손상될 수 있습니다.

Console


클라이언트 IP 어피니티를 설정하려면 다음 안내를 따르세요.

  1. Google Cloud Console에서 부하 분산기 페이지의 백엔드 구성 부분으로 이동합니다.
    부하 분산 페이지로 이동
  2. 부하 분산기의 편집 연필을 선택합니다.
  3. 백엔드 구성을 선택합니다.
  4. 백엔드 서비스편집 연필을 선택합니다.
  5. 백엔드 서비스 편집 대화상자의 세션 어피니티 드롭다운 메뉴에서 Client IP를 선택합니다.
    이렇게 하면 클라이언트 IP 세션 어피니티를 사용하도록 설정됩니다. 어피니티 쿠키 TTL 필드는 클라이언트 IP 어피니티와 관련하여 의미가 없으므로 회색으로 표시됩니다.
  6. 백엔드 서비스업데이트 버튼을 클릭합니다.
  7. 부하 분산기의 업데이트 버튼을 클릭합니다.

gcloud


create 명령어를 사용하여 새로운 백엔드 서비스의 세션 어피니티를 설정하거나, update 명령어를 사용하여 기존 백엔드 서비스의 세션 어피니티를 설정할 수 있습니다. 다음 예시는 update 명령어를 사용하는 방법을 보여줍니다.

gcloud compute backend-services update [BACKEND_SERVICE_NAME] \
        --session-affinity client_ip
    

API


백엔드 서비스의 API 참조를 참고하세요.

생성된 쿠키 어피니티가 설정되면 부하 분산기가 첫 번째 요청에서 쿠키를 생성합니다. 로드 밸런서는 동일한 쿠키를 사용하는 각 후속 요청에서 같은 백엔드 VM 또는 엔드포인트로 요청을 전달합니다.

  • 외부 HTTP(S) 부하 분산기의 경우 쿠키 이름은 GCLB입니다.
  • 내부 HTTP 부하 분산기 및 Traffic Director의 경우 쿠키 이름은 GCILB입니다.

쿠키 기반 어피니티는 클라이언트 IP 기반 어피니티와 비교하여 부하 분산기에 대한 클라이언트를 더 정확하게 식별할 수 있습니다. 예를 들면 다음과 같습니다.

  1. 쿠키 기반 어피니티를 통해 부하 분산기는 동일한 소스 IP 주소를 공유하는 두 개 이상의 클라이언트 시스템을 고유하게 식별할 수 있습니다. 클라이언트 IP 기반 어피니티를 사용하는 부하 분산기는 동일한 소스 IP 주소의 모든 연결을 동일한 클라이언트 시스템의 연결처럼 처리합니다.

  2. 클라이언트가 IP 주소를 변경하는 경우(예: 네트워크 간에 이동하는 휴대기기) 쿠키 기반 어피니티는 연결을 새 연결으로 취급하는 대신 부하 분산기가 클라이언트의 후속 연결을 인식할 수 있도록 설정할 수 있습니다.

부하 분산기가 생성된 쿠키 기반 어피니티에 대한 쿠키를 생성하면 쿠키의 path 속성을 /로 설정합니다. 부하 분산기의 URL 맵에 지정된 호스트 이름에 대해 둘 이상의 백엔드 서비스를 지정하는 경로 일치자가 있는 경우 쿠키 기반 세션 어피니티를 사용하는 모든 백엔드 서비스가 동일한 세션 쿠키를 공유합니다.

부하 분산기에 의해 생성된 HTTP 쿠키의 수명은 구성이 가능합니다. 쿠키를 0(기본값)인 세션 쿠키로만 설정하거나 쿠키의 수명을 1 ~ 86400초(24시간 포함) 사이의 값으로 설정할 수 있습니다.

Console


생성된 쿠키 어피니티를 설정하려면 다음 안내를 따르세요.

  1. Google Cloud Console에서 HTTP(S) 부하 분산기 페이지의 백엔드 구성 부분에서 생성된 쿠키 어피니티를 편집할 수 있습니다.
    부하 분산 페이지로 이동
  2. 부하 분산기의 편집 연필을 선택합니다.
  3. 백엔드 구성을 선택합니다.
  4. 백엔드 서비스편집 연필을 선택합니다.
  5. 세션 어피니티 드롭다운 메뉴에서 Generated cookie를 선택하여 생성된 쿠키 어피니티를 선택합니다.
  6. 어피니티 쿠키 TTL 필드에서 쿠키의 수명을 초 단위로 설정합니다.
  7. 백엔드 서비스업데이트 버튼을 클릭합니다.
  8. 부하 분산기의 업데이트 버튼을 클릭합니다.

gcloud


--session-affinitygenerated_cookie로 설정하고 --affinity-cookie-ttl을 쿠키 수명(초)으로 설정하여 생성된 쿠키 어피니티를 사용하도록 설정합니다. create 명령어를 사용하여 새로운 백엔드 서비스의 세션 어피니티를 설정하거나, update 명령어를 사용하여 기존 백엔드 서비스의 세션 어피니티를 설정할 수 있습니다. 다음 예시는 update 명령어를 사용하는 방법을 보여줍니다.

gcloud compute backend-services update [BACKEND_SERVICE_NAME] \
        --session-affinity generated_cookie \
        --affinity-cookie-ttl 86400
    

API


백엔드 서비스의 API 참조를 참고하세요.

세션 어피니티 사용 중지

백엔드 서비스를 업데이트하고 세션 어피니티를 none으로 설정하여 세션 어피니티의 사용을 해제하거나, 텍스트 편집기에서 백엔드 서비스를 편집하고 세션 어피니티를 none으로 설정할 수 있습니다. 두 명령어 중 하나를 사용하여 쿠키 수명을 편집할 수도 있습니다.

Console


세션 어피니티의 사용을 중지하려면 다음 안내를 따르세요.

  1. Google Cloud Console에서 부하 분산기 페이지의 백엔드 구성 부분에서 세션 어피니티를 사용 중지할 수 있습니다.
    부하 분산 페이지로 이동
  2. 부하 분산기의 편집 연필을 선택합니다.
  3. 백엔드 구성을 선택합니다.
  4. 백엔드 서비스편집 연필을 선택합니다.
  5. 세션 어피니티 드롭다운 메뉴에서 None을 선택하여 세션 어피니티의 사용을 해제합니다.
  6. 백엔드 서비스업데이트 버튼을 클릭합니다.
  7. 부하 분산기의 업데이트 버튼을 클릭합니다.

gcloud


세션 어피니티의 사용을 중지하도록 설정하려면 다음 명령어를 실행하세요.

      gcloud compute backend-services update [BACKEND_SERVICE_NAME] \
      --session-affinity none
    


또는

gcloud compute backend-services edit [BACKEND_SERVICE_NAME]

API


백엔드 서비스의 API 참조를 참고하세요.

세션 어피니티 상실

선택한 어피니티 유형에 관계없이 클라이언트는 다음 시나리오에서 인스턴스와의 어피니티를 상실할 수 있습니다.

  • 인스턴스 그룹의 용량이 부족하여 트래픽을 다른 영역으로 라우팅해야 합니다. 이 경우 기존 세션의 트래픽이 새로운 영역으로 전송되어 어피니티가 상실될 수 있습니다. 인스턴스 그룹에 모든 로컬 사용자를 처리할 수 있는 충분한 용량이 있도록 설정하여 이 문제를 완화할 수 있습니다.
  • 자동 확장은 인스턴스 그룹에 인스턴스를 추가하거나 인스턴스 그룹에서 인스턴스를 삭제합니다. 두 경우 모두 백엔드 서비스가 부하를 재할당하며, 대상은 이동할 수 있습니다. 자동 확장으로 프로비저닝된 인스턴스의 최소 개수가 예상 부하를 처리하기에 충분한지 확인한 다음 부하의 예상치 않은 증가를 자동 확장만으로 처리하는 방법으로 이 문제를 완화할 수 있습니다.
  • 대상 인스턴스가 상태 확인에 실패합니다. 세션이 정상적인 인스턴스로 이동함에 따라 어피니티가 상실됩니다.
  • 분산 모드가 백엔드 사용률로 설정됩니다. 이로 인해 영역 간 계산된 용량이 변경되어 일부 트래픽이 리전 내의 다른 영역으로 전송될 수 있습니다. 이러한 경우는 계산된 용량이 덜 안정적인 낮은 트래픽 상황에서 발생 가능성이 더 높습니다.
  • 백엔드가 여러 클라우드 리전에 있고 클라이언트 라우팅이 연결 이그레스의 첫 번째 요청과 후속 요청이 다른 지리적 위치에서 발생하도록 설계된 경우, 세션 어피니티가 상실될 수 있습니다. 이는 추가 요청이 새 이그레스 위치에 의해 결정되는 다른 클라우드 리전으로 라우팅될 수 있기 때문입니다.

시간 초과 설정 구성

부하 분산기에서 백엔드 서비스로의 연결 중 수명이 더 긴 연결은 시간 초과 설정을 기본값인 30초보다 더 길게 구성하세요.

Console


시간 초과 설정을 구성하려면 다음 안내를 따르세요.

  1. Google Cloud Console에서 HTTP(S) 부하 분산기 페이지의 백엔드 구성 부분에서 시간 초과 설정을 수정할 수 있습니다.
    부하 분산 페이지로 이동
  2. 부하 분산기의 편집 연필을 선택합니다.
  3. 백엔드 구성을 선택합니다.
  4. 백엔드 서비스편집 연필을 선택합니다.
  5. 프로토콜 포트 및 시간 초과 설정 행에서 편집 연필을 선택합니다.
  6. 새로운 시간 초과 설정을 초 단위로 입력합니다.
  7. 백엔드 서비스업데이트 버튼을 클릭합니다.
  8. 부하 분산기의 업데이트 버튼을 클릭합니다.

gcloud


시간 제한 설정을 변경하려면 gcloud 명령줄 도구에서 `gcloud compute backend-services update' 명령을 사용합니다. 자세한 정보를 보려면 명령어에 --help를 추가하세요.

gcloud compute backend-services update [BACKEND_SERVICE] [--timeout=TIMEOUT]
    

API


백엔드 서비스의 REST API 참조를 참고하세요.

이름이 지정된 포트

내부 HTTP(S), 외부 HTTP(S), SSL 프록시, TCP 프록시 부하 분산기의 경우 백엔드가 인스턴스 그룹이면 백엔드 서비스에는 이름이 지정된 포트가 연결되어 있어야 합니다. 이름이 지정된 포트는 백엔드 인스턴스 그룹에 구성된 이름이 지정된 해당 포트를 사용하여 포트 번호로 변환하도록 부하 분산기에 알립니다. 이는 부하 분산기가 백엔드 VM에 연결하는 데 사용하는 포트이며 클라이언트가 부하 분산기 자체를 연결하는 데 사용하는 포트와 다를 수 있습니다.

이름이 지정된 포트는 서비스가 실행되는 포트 번호와 서비스 이름을 나타내는 키-값 쌍입니다. 키-값 쌍은 인스턴스 그룹에 정의됩니다. 백엔드 서비스가 해당 인스턴스 그룹을 백엔드로 사용하면 이름이 지정된 포트를 '구독'할 수 있습니다.

  • 각 인스턴스 그룹에는 최대 5개의 이름이 지정된 포트(키-값 쌍)를 정의할 수 있습니다.
  • 인스턴스 그룹 백엔드를 사용하는 HTTP(S), SSL 프록시 또는 TCP 프록시 부하 분산기의 각 백엔드 서비스는 이름이 지정된 단일 포트만 '구독'할 수 있습니다.
  • 백엔드 서비스에 이름이 지정된 포트를 지정하면 모든 백엔드 인스턴스 그룹에 동일한 이름을 사용하는 이름이 지정된 포트가 하나 이상 정의되어야 합니다.

다음과 같은 경우에는 이름이 지정된 포트를 사용할 수 없습니다.

  • NEG 백엔드: NEG는 엔드포인트당 포트를 정의하며 NEG와 연결된 포트 키-값 쌍이 없습니다.
  • 내부 TCP/UDP 부하 분산기: 내부 TCP/UDP 부하 분산기는 프록시가 아닌 통과 부하 분산기이므로 백엔드 서비스는 이름이 지정된 포트 설정을 지원하지 않습니다.

상태 확인

각 백엔드 서비스에는 상태 확인이 연결되어 있어야 합니다. 백엔드 서비스를 만들려면 상태 확인이 있어야 합니다.

상태 확인은 계속 실행되며 그 결과는 어떤 인스턴스가 새 요청을 수신할 수 있는지 결정하는 데 도움이 됩니다.

비정상적인 인스턴스는 새로운 요청을 수신하지 않고 계속 폴링됩니다. 비정상적인 인스턴스가 상태 확인을 통과하면 정상으로 간주되어 새로운 연결을 수신하기 시작합니다.

자세한 내용은 다음 문서를 참조하세요.

백엔드 서비스 상태 확인의 결과 보기

상태 확인 및 백엔드 서비스를 만들면 상태 확인 결과를 볼 수 있습니다.

Console


백엔드 서비스의 상태 확인 결과를 보려면 다음 안내를 따르세요.

  1. 부하 분산 요약 페이지로 이동합니다.
    부하 분산 페이지로 이동
  2. 부하 분산기의 이름을 클릭합니다.
  3. 백엔드 아래에서 백엔드 서비스인스턴스 그룹 표에 있는 정상 열을 확인합니다.

gcloud


최신 상태 확인 결과를 보려면 gcloud 명령줄 도구에서 backend-services get-health 명령을 실행합니다.

gcloud compute backend-services get-health [BACKEND_SERVICE]
    

이 명령어는 지정된 백엔드 서비스의 모든 인스턴스에 대한 healthState 값이며, 값은 HEALTHY 또는 UNHEALTHY입니다.

      healthStatus:
        - healthState: UNHEALTHY
          instance: us-central1-b/instances/www-video1
        - healthState: HEALTHY
          instance: us-central1-b/instances/www-video2
      kind: compute#backendServiceGroupHealth
      

API


API 명령의 경우 상태 확인 페이지를 참조하세요.

백엔드 서비스 리소스에서 사용 가능한 추가 기능

백엔드 서비스 리소스를 사용하여 활성화되는 다음 선택적 Google Cloud 기능은 이 문서에서 다루지 않습니다.

기타 참고사항

백엔드 서비스에 대한 변경은 즉시 적용되지 않습니다. 변경사항이 네트워크 전체에 전파되려면 몇 분이 걸릴 수 있습니다.

다음 Traffic Director 기능은 Google Cloud 부하 분산기에서 지원되지 않습니다.

  • 회로 차단
  • 이상점 감지
  • 부하 분산 정책
  • HTTP 쿠키 기반 세션 어피니티
  • HTTP 헤더 기반 세션 어피니티

다음 단계

백엔드 서비스가 부하 분산에 사용되는 방법에 대한 관련 문서 및 정보를 보려면 다음을 검토합니다.