백엔드 서비스 이해

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

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

백엔드 서비스는 인스턴스 그룹 또는 네트워크 엔드포인트 그룹인 백엔드로 트래픽을 전달합니다.

백엔드 서비스는 다음과 같은 다양한 기능을 수행합니다.

  • 분산 모드에 따라 트래픽 전달. 분산 모드는 백엔드의 백엔드 서비스에 정의되어 있습니다.
  • 상태 확인에 따라 백엔드 상태 모니터링
  • 세션 어피니티 유지

아키텍처

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

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

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

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

백엔드 서비스 설정

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

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

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

백엔드

각 백엔드는 GCP 부하 분산기가 트래픽을 분산하는 리소스입니다. 백엔드로 사용할 수 있는 두 가지 유형의 리소스가 있습니다.

특정 백엔드 서비스의 경우 백엔드는 모두 인스턴스 그룹이거나 NEG(지원되는 경우)여야 합니다. 동일한 백엔드 서비스에서 인스턴스 그룹과 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 주소가 필요하지 않습니다.

트래픽 분산

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

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

다음에 유의하세요.

  • 동일한 백엔드 서비스에 연결된 백엔드 인스턴스 그룹의 모든 인스턴스에 대한 평균 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는 인그레스를 사용한 부하 분산에도 사용할 수 있습니다.

백엔드 서비스 및 리전

HTTP(S) 부하 분산은 글로벌 서비스입니다. 한 리전에 2개 이상의 백엔드 서비스가 존재할 수 있고 백엔드 서비스를 2개 이상의 리전에 할당할 수 있으며, 이러한 서비스는 모두 동일한 전역 부하 분산기에서 처리됩니다. 트래픽은 다음과 같이 백엔드 서비스에 할당됩니다.

  1. 사용자 요청이 수신되면 부하 분산 서비스가 소스 IP 주소에서 요청의 대략적인 출처를 확인합니다.
  2. 부하 분산 서비스는 백엔드 서비스가 소유한 인스턴스의 위치, 인스턴스의 전체 용량, 현재 총 사용량을 인식합니다.
  3. 사용자에게 가장 가까운 인스턴스에 이용 가능한 용량이 있으면 요청은 이 가장 가까운 인스턴스 세트로 전달됩니다.
  4. 한 리전에 수신되는 요청은 해당 리전의 이용 가능한 모든 백엔드 서비스와 인스턴스에 균등하게 분산됩니다. 하지만 부하가 아주 적은 경우에는 분산이 균등하지 않게 나타날 수 있습니다.
  5. 지정한 리전에 이용 가능한 용량이 있는 정상 인스턴스가 없는 경우, 부하 분산기는 이용 가능한 용량이 있는 그 다음으로 가까운 리전으로 요청을 전송합니다.

인스턴스 그룹

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

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

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

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

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

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

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

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

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

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

네트워크 엔드포인트 그룹

네트워크 엔드포인트는 다음 두 가지 방법 중 하나로 지정된 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 어피니티는 백엔드 서비스를 사용하는 모든 GCP 부하 분산기에 대한 옵션입니다.

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

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

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

Console


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

  1. Google Cloud Platform 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 참조를 참고하세요.

생성된 쿠키 어피니티가 설정되면 부하 분산기가 첫 번째 요청에서 이름이 GCLB인 쿠키를 생성한 다음 동일한 쿠키를 가진 모든 후속 요청을 동일한 인스턴스로 보냅니다. 쿠키에 기반한 어피니티를 사용하면 부하 분산기가 동일한 IP 주소를 사용하는 여러 클라이언트를 구별할 수 있으므로 이러한 클라이언트를 여러 인스턴스에 보다 균등하게 분산시킬 수 있습니다. 쿠키 기반의 어피니티는 클라이언트의 IP 주소가 변경되어도 부하 분산기가 인스턴스 어피니티를 유지할 수 있게 해줍니다.

쿠키의 경로는 항상 이므로 동일한 호스트 이름에 쿠키 기반의 어피니티를 사용 설정하는 2개의 백엔드 서비스가 있는 경우 두 서비스 모두 동일한 쿠키에 의해 분산이 수행됩니다.

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

Console


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

  1. Google Cloud Platform 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으로 설정할 수 있습니다. 두 명령어 중 하나를 사용하여 쿠키 수명을 수정할 수도 있습니다.

콘솔


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

  1. Google Cloud Platform 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 참조를 참고하세요.

세션 어피니티 상실

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

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

시간 초과 설정 구성

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

Console


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

  1. Google Cloud Platform 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 부하 분산기는 프록시가 아닌 통과 부하 분산기이므로 백엔드 서비스는 이름이 지정된 포트 설정을 지원하지 않습니다.

상태 확인

각 백엔드 서비스에는 상태 확인이 연결되어 있어야 합니다. 상태 확인은 계속 실행되며 그 결과는 어떤 인스턴스가 새 요청을 수신해야 하는지 결정하는 데 도움이 됩니다.

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

상태 확인을 위한 권장사항

상태 확인을 구성할 때는 동일한 포트에서 상태를 확인하고 트래픽을 처리하는 것이 좋습니다. 하지만 한 포트에서 상태 확인을 수행하고 다른 포트에서 트래픽을 처리할 수도 있습니다. 2개의 다른 포트를 사용하는 경우 인스턴스에서 실행 중인 방화벽 규칙 및 서비스가 적절하게 구성되었는지 확인합니다. 동일한 포트에서 상태 확인을 실행하고 트래픽을 처리하지만 어느 시점에 포트를 전환하려는 경우에는 백엔드 서비스와 상태 확인을 모두 업데이트해야 합니다.

이를 참조하는 유효한 전달 규칙이 없는 백엔드 서비스는 상태 확인이 되지 않으므로 상태 확인 값이 없습니다.

상태 확인 만들기

백엔드 서비스를 만들려면 먼저 상태 확인을 만들어야 합니다. 부하를 분산할 트래픽과 동일한 프로토콜에 대하여 상태 확인을 만드는 것이 좋습니다.

Console

Console에서 백엔드 서비스를 만들 때 상태 확인을 만들 수 있습니다.

gcloud

gcloud 명령어의 경우 상태 확인 페이지를 참조하여 상태 확인을 만듭니다.

API

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

백엔드 서비스 만들기

Console


새 백엔드 서비스를 만들려면 다음 안내를 따르세요.

  1. Google Cloud Platform Console의 HTTP(S) 부하 분산기 페이지에 있는 백엔드 구성 부분에서 백엔드 서비스를 만들 수 있습니다.
    부하 분산 페이지로 이동
  2. 부하 분산기의 수정(연필 모양)을 선택합니다.
  3. 백엔드 구성을 선택합니다.
  4. 백엔드 서비스 및 백엔드 버킷 만들기 또는 선택 드롭다운 메뉴에서 백엔드 서비스 -> 백엔드 서비스 만들기를 선택합니다.
  5. 백엔드 서비스의 이름을 입력합니다.
  6. (선택사항) 설명을 입력합니다.
  7. 프로토콜, 포트 및 시간 초과 설정을 위한 행에서 수정(연필 모양)을 선택합니다.
    • 프로토콜http, https, http2로 선택합니다.
    • 이름이 지정된 포트port name을 입력합니다.
    • (선택사항) 기본 시간 초과 설정을 변경합니다.
  8. BackendType에서 인스턴스 그룹 라디오 버튼을 선택합니다.
  9. 백엔드 대화 상자에서 하나 이상의 백엔드를 작성할 수 있습니다.
    1. 새 백엔드 대화 상자의 드롭다운 메뉴에서 기존 인스턴스 그룹을 선택합니다.
    2. 백엔드가 요청을 수신할 하나 이상의 포트 번호를 입력합니다.
      • 프로토콜http인 경우 이 필드는 80으로 설정됩니다.
      • 프로토콜https인 경우 이 필드는 443으로 설정됩니다.
      • 프로토콜http2인 경우 이 필드는 443으로 설정됩니다.
    3. 최대 CPU 사용률을 백분율로 설정합니다.
    4. (선택사항) 최대 RPS 필드를 비워 두어 unlimited로 설정합니다. 인스턴스당 RPS 또는 그룹당 RPS를 설정합니다.
    5. 용량의 백분율을 설정합니다.
    6. 완료 버튼을 클릭합니다.
  10. Cloud CDN 사용 설정 상자를 선택하거나 선택 취소합니다.
  11. 상태 확인 드롭다운 메뉴에서 기존 상태 확인을 선택하거나 다음 단계를 완료하여 다른 상태 확인 만들기를 수행합니다.
    1. 이름을 설정합니다.
    2. (선택사항) 설명을 설정합니다.
    3. 프로토콜포트를 설정합니다. 권장사항은 상태 확인 섹션을 참조하세요.
    4. 프록시 프로토콜을 설정합니다.
    5. (선택사항) 요청응답 값을 설정합니다.
    6. 상태 기준에서 다음 항목을 설정합니다.
      1. 확인 간격을 초 단위로 설정합니다.
      2. 시간 초과를 초 단위로 설정합니다.
      3. 정상 기준number of consecutive successes를 설정합니다.
      4. 비정상 기준number of consecutive failures를 설정합니다.
      5. 저장 후 계속을 클릭합니다.
    7. 고급 구성을 클릭하여 세션 어피니티, 연결 드레이닝 제한 시간, 커스텀 요청 헤더 또는 보안 정책을 수정합니다.
      1. 세션 어피니티를 설정하려면 클라이언트 IP 또는 생성된 쿠키를 선택합니다. *생성된 쿠키를 선택한 경우 어피니티 쿠키 TTL을 초 단위로 설정합니다.
      2. 연결 드레이닝 제한 시간을 설정하려면 인스턴스가 처리 중인 연결이 완료되기를 기다리는 시간을 초 단위로 입력합니다.
      3. 커스텀 요청 헤더를 만들려면 +헤더 추가를 클릭한 다음 헤더의 헤더 이름헤더 값을 추가합니다.
      4. 보안 정책을 사용 설정하려면 드롭다운 메뉴에서 하나를 선택합니다.
    8. 백엔드 서비스업데이트 버튼을 클릭합니다.
    9. 부하 분산기의 업데이트 버튼을 클릭합니다.

gcloud


gcloud 명령줄 도구를 사용하여 백엔드 서비스를 만들려면 Cloud SDK 문서를 참조하세요.

API


API 명령어의 경우 백엔드 서비스 페이지를 참조하여 백엔드 서비스를 만듭니다.

백엔드 서비스 수정

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

Console


기존 백엔드 서비스를 수정하려면 다음 안내를 따르세요.

  1. Google Cloud Platform Console의 HTTP(S) 부하 분산기 페이지에 있는 백엔드 구성 부분에서 백엔드 서비스를 수정할 수 있습니다.
    부하 분산 페이지로 이동
  2. 부하 분산기의 수정 연필을 선택합니다.
  3. 백엔드 구성을 선택합니다.
  4. 백엔드 서비스 아래에서 백엔드 서비스의 수정 연필을 선택합니다. 다음 필드를 수정할 수 있습니다.
    1. 백엔드 아래에서 새로운 백엔드를 추가하거나 기존 백엔드의 수정(연필 모양)을 선택합니다.
    2. 프로토콜, 포트 및 시간 초과 설정을 위한 행에서 수정(연필 모양)을 선택합니다.
    3. 기존의 상태 확인을 선택하거나 앞에 나온 상태 확인 생성 단계를 따라 새로운 상태 확인을 만듭니다.
    4. 세션 어피니티를 수정하고 필요하면 어피니티 쿠키 TTL을 수정합니다.
    5. 고급 구성을 클릭하여 연결 드레이닝 제한 시간을 수정합니다.
    6. Cloud CDN 사용 설정 상자를 선택하거나 선택 취소합니다.
  5. 고급 구성을 클릭하여 세션 어피니티, 연결 드레이닝 제한 시간, 커스텀 요청 헤더 또는 보안 정책을 수정합니다.
    1. 세션 어피니티를 설정하려면 클라이언트 IP 또는 생성된 쿠키를 선택합니다. *생성된 쿠키를 선택한 경우 어피니티 쿠키 TTL을 초 단위로 설정합니다.
    2. 연결 드레이닝 제한 시간을 설정하려면 인스턴스가 처리 중인 연결이 완료되기를 기다리는 시간을 초 단위로 입력합니다.
    3. 커스텀 요청 헤더를 만들려면 +헤더 추가를 클릭한 다음 헤더의 헤더 이름헤더 값을 추가합니다.
    4. 보안 정책을 사용 설정하려면 드롭다운 메뉴에서 하나를 선택합니다.
    5. 백엔드 서비스업데이트 버튼을 클릭합니다.
    6. 부하 분산기의 업데이트 버튼을 클릭합니다.

gcloud


gcloud 명령줄 도구를 사용하여 백엔드 서비스를 수정하려면 Cloud SDK 문서를 참조하세요.

API


API를 사용하여 백엔드 서비스를 수정하려면 API 문서를 참조하세요.

백엔드 서비스에 인스턴스 그룹 추가

백엔드 서비스에 포함된 인스턴스를 정의하려면 백엔드를 추가하고 백엔드에 인스턴스 그룹을 할당해야 합니다. 인스턴스 그룹을 백엔드에 추가하기 전에 먼저 인스턴스 그룹을 만들어야 합니다.

인스턴스 그룹을 백엔드에 추가할 때는 매개변수도 정의해야 합니다.

Console


백엔드 서비스에 인스턴스 그룹을 추가하려면 다음 안내를 따르세요.

  1. Google Cloud Platform Console의 HTTP(S) 부하 분산기 페이지에 있는 백엔드 구성 부분에서 백엔드에 인스턴스 그룹을 추가할 수 있습니다.
    부하 분산 페이지로 이동
  2. 부하 분산기의 수정(연필 모양)을 선택합니다.
  3. 백엔드 구성을 선택합니다.
  4. 백엔드 구성편집 연필을 선택합니다.
  5. 백엔드수정(연필 모양)을 선택합니다.
  6. 백엔드 수정 대화 상자의 인스턴스 그룹 드롭다운 메뉴에서 Instance group을 선택합니다.
  7. 백엔드 수정완료 버튼을 클릭합니다.
  8. 백엔드 서비스업데이트 버튼을 클릭합니다.
  9. 부하 분산기의 업데이트 버튼을 클릭합니다.

gcloud


gcloud 명령줄 도구를 사용하여 백엔드 서비스에 인스턴스 그룹을 추가하려면 Cloud SDK 문서를 참조하세요.

API


API를 사용하여 백엔드 서비스에 인스턴스 그룹을 추가하려면 API 문서를 참조하세요.

백엔드 서비스에 네트워크 엔드포인트 그룹 추가

네트워크 엔드포인트 그룹을 백엔드 서비스에 추가하려면 백엔드 서비스에 네트워크 엔드포인트 그룹 추가를 참조하세요.

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

상태 확인 및 백엔드 서비스를 만든 후에는 상태 확인 결과를 볼 수 있습니다.

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 명령의 경우 상태 확인 페이지를 참조하세요.

기타 참고사항

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

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

다음 단계

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

이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

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