백엔드 서비스 기반 외부 TCP/UDP 네트워크 부하 분산 개요

Google Cloud 외부 TCP/UDP 네트워크 부하 분산(이후 네트워크 부하 분산이라고 칭함)은 패스스루 리전 부하 분산기입니다. 네트워크 부하 분산기는 동일한 리전의 가상 머신(VM) 인스턴스 간에 외부 트래픽을 분산합니다.

TCP, UDP, ESP, GRE, ICMP, ICMPv6 트래픽에 대해 네트워크 부하 분산기를 구성할 수 있습니다.

네트워크 부하 분산기는 다음으로부터 트래픽을 수신할 수 있습니다.

  • 인터넷의 모든 클라이언트
  • 외부 IP가 있는 Google Cloud VM
  • Cloud NAT 또는 인스턴스 기반 NAT를 통해 인터넷에 액세스할 수 있는 Google Cloud VM

네트워크 부하 분산에는 다음과 같은 특성이 있습니다.

  • 네트워크 부하 분산은 관리형 서비스입니다.
  • 네트워크 부하 분산은 Andromeda 가상 네트워킹Google Maglev를 통해 구현됩니다.
  • 네트워크 부하 분산기는 프록시가 아닙니다.
    • 백엔드 VM은 패킷의 소스 및 대상 IP 주소, 프로토콜, 프로토콜이 포트 기반인 경우 소스 및 대상 포트가 변경되지 않은 상태로 부하 분산된 패킷을 수신합니다.
    • 부하 분산된 연결은 백엔드 VM에 의해 종료됩니다.
    • 백엔드 VM의 응답은 부하 분산기를 통하지 않고 클라이언트에 직접 전달됩니다. 업계에서는 이를 직접 서버 반환이라 합니다.

백엔드 서비스 기반 네트워크 부하 분산기의 특징은 다음과 같습니다.

  • 관리형 인스턴스 그룹 백엔드. 백엔드 서비스 기반 네트워크 부하 분산기는 관리형 인스턴스 그룹(MIG)을 백엔드로 사용할 수 있습니다. 관리형 인스턴스 그룹은 백엔드 관리의 특정 측면을 자동화하며 비관리형 인스턴스 그룹보다 우수한 확장성과 안정성을 제공합니다.
  • IPv6 연결 지원. 백엔드 서비스 기반 네트워크 부하 분산기는 IPv4 및 IPv6 트래픽을 모두 처리할 수 있습니다.
  • 세밀한 트래픽 분산 제어. 백엔드 서비스 구성에는 상태 확인, 세션 어피니티, 연결 추적, 연결 드레이닝, 장애 조치 정책과 같은 값 집합이 포함됩니다. 대부분의 설정에는 빠른 시작에 도움이 되는 기본값이 있습니다.
  • 상태 확인. 백엔드 서비스 기반 네트워크 부하 분산기에서는 분산 중인 트래픽 유형(TCP, SSL, HTTP, HTTPS 또는 HTTP/2)과 일치하는 상태 확인을 사용합니다.

아키텍처

다음 다이어그램에서는 네트워크 부하 분산기의 구성요소를 보여줍니다.

리전 백엔드 서비스를 사용하는 외부 TCP/UDP 네트워크 부하 분산기
리전 백엔드 서비스를 사용하는 네트워크 부하 분산

부하 분산기는 여러 가지 구성요소로 이루어집니다. 부하 분산기 하나에는 다음이 포함될 수 있습니다.

  • 리전 외부 IP 주소 한 개 이상
  • 리전 외부 전달 규칙 한 개 이상
  • 리전 외부 백엔드 서비스 한 개
  • 백엔드 인스턴스 그룹 한 개 이상
  • 백엔드 서비스와 연결된 상태 확인

또한 부하 분산 트래픽 및 상태 확인 프로브가 백엔드 VM에 연결하도록 허용하는 방화벽 규칙을 만들어야 합니다.

IP 주소

네트워크 부하 분산기에는 전달 규칙이 최소 한 개 이상 필요합니다. 전달 규칙은 인터넷 어디서나 액세스할 수 있는 리전 외부 IP 주소를 참조합니다.

  • IPv4 트래픽의 경우 전달 규칙은 단일 리전 외부 IPv4 주소를 참조하세요. 리전 외부 IPv4 주소는 고유한 풀에서 각 Google Cloud 리전에 가져옵니다. IP 주소는 예약된 고정 주소 또는 임시 주소일 수 있습니다.
  • IPv6 트래픽의 경우 전달 규칙은 서브넷의 /64 외부 IPv6 주소 범위에서 /96 IP 주소 범위를 참조합니다. 서브넷은 ipv6-access-typeEXTERNAL로 설정된 이중 스택 서브넷이어야 합니다. 고정 외부 IPv6 주소 예약은 아직 미리보기 상태이며 허용 목록에 추가된 프로젝트가 필요합니다. 이 기능에 프로젝트를 허용 목록에 추가하도록 요청하거나 임시 주소를 사용할 수 있습니다. 외부 IPv6 주소는 프리미엄 등급에서만 사용 가능합니다.

전달 규칙을 삭제한 후 다시 사용할 프로젝트와 연결된 주소를 유지해야 하거나 동일한 IP 주소를 참조하는 전달 규칙 여러 개가 필요하면 전달 규칙에 대해 예약된 IP 주소를 사용합니다.

네트워크 부하 분산은 리전 외부 IPv4 주소에 표준 등급과 프리미엄 등급을 모두 지원합니다. IP 주소와 전달 규칙 모두 동일한 네트워크 등급을 사용해야 합니다. 리전 외부 IPv6 주소는 프리미엄 등급에서만 사용할 수 있습니다.

전달 규칙

리전 외부 전달 규칙은 부하 분산기가 트래픽을 허용하는 프로토콜과 포트를 지정합니다. 네트워크 부하 분산기는 프록시가 아니기 때문에 패킷에 포트 정보가 포함된 경우 동일한 프로토콜 및 포트에서 백엔드로 트래픽을 전달합니다. IP 주소와 결합된 전달 규칙이 부하 분산기의 프런트엔드를 형성합니다.

부하 분산기는 수신 패킷의 소스 IP 주소를 유지합니다. 수신 패킷의 대상 IP 주소는 부하 분산기의 전달 규칙과 연결된 IP 주소입니다.

수신 트래픽은 특정 IP 주소(IPv4 주소 또는 IPv6 주소 범위), 프로토콜, 프로토콜이 포트 기반인 경우 1개 포트, 포트 범위 또는 모든 포트의 조합인 전달 규칙과 일치합니다. 그런 다음 전달 규칙은 트래픽을 부하 분산기의 백엔드 서비스로 전달합니다.

  • 전달 규칙이 IPv4 주소를 참조하는 경우 전달 규칙은 서브넷과 연결되지 않습니다. 즉, IP 해당 주소는 Google Cloud 서브넷 범위 밖에서 가져옵니다.

  • 전달 규칙이 IPv6 주소를 참조하는 경우 전달 규칙이 서브넷에 연결되어야 하며 해당 서브넷은 (a)이중 스택이고 (b)--ipv6-access-typeEXTERNAL로 설정되어야 합니다.

네트워크 부하 분산기에는 전달 규칙이 최소 한 개 이상 필요합니다. 특정 범위의 소스 IP 주소에서 들어오는 트래픽을 특정 백엔드 서비스(또는 대상 인스턴스)로 전달하도록 전달 규칙을 구성할 수 있습니다. 자세한 내용은 트래픽 조정을 참조하세요. 여러 전달 규칙에 설명된 대로 동일한 부하 분산기에 전달 규칙을 여러 개 정의할 수 있습니다.

부하 분산기가 IPv4 및 IPv6 트래픽을 모두 처리하게 하려면 두 개의 전달 규칙을 만듭니다. 하나는 IPv4(또는 이중 스택) 백엔드를 가리키는 IPv4 트래픽용 규칙이고 다른 하나는 이중 스택 백엔드만 가리키는 IPv6 트래픽에 대한 규칙입니다. IPv4 및 IPv6 전달 규칙이 동일한 백엔드 서비스를 참조하도록 할 수 있지만 백엔드 서비스는 이중 스택 백엔드를 참조해야 합니다.

전달 규칙 프로토콜

네트워크 부하 분산은 각 전달 규칙에 프로토콜 옵션 TCP, UDP, L3_DEFAULT를 지원합니다.

TCPUDP 옵션을 사용하여 TCP 또는 UDP 부하 분산을 구성합니다. L3_DEFAULT 프로토콜 옵션은 네트워크 부하 분산기가 TCP, UDP, ESP, GRE, ICMP, ICMPv6 트래픽을 부하 분산할 수 있게 해줍니다.

TCP 및 UDP 이외의 프로토콜을 지원하는 것 외에도 L3_DEFAULT는 단일 전달 규칙이 여러 프로토콜을 지원할 수 있게 해줍니다. 예를 들어 IPSec 서비스는 일반적으로 ESP 및 UDP 기반 IKE와 NAT-T 트래픽 조합을 처리합니다. L3_DEFAULT 옵션을 사용하면 이러한 모든 프로토콜을 처리하도록 단일 전달 규칙을 구성할 수 있습니다.

TCP 또는 UDP 프로토콜을 사용하는 전달 규칙은 해당 프로토콜이 UNSPECIFIED인 전달 규칙 또는 백엔드 서비스와 동일한 프로토콜을 사용하여 백엔드 서비스를 참조할 수 있습니다. L3_DEFAULT 전달 규칙은 UNSPECIFIED 프로토콜을 사용하는 백엔드 서비스만 참조할 수 있습니다.

L3_DEFAULT 프로토콜을 사용하는 경우 모든 포트에서 트래픽을 허용하도록 전달 규칙을 구성해야 합니다. 모든 포트를 구성하려면 Google Cloud CLI를 사용하여 --ports=ALL를 설정하거나 API를 사용하여 allPortsTrue로 설정합니다.

다음 표에서는 다양한 프로토콜에서 이러한 설정을 사용하는 방법을 요약합니다.

부하 분산되는 트래픽 전달 규칙 프로토콜 백엔드 서비스 프로토콜
TCP TCP TCP 또는 UNSPECIFIED
L3_DEFAULT UNSPECIFIED
UDP UDP UDP 또는 UNSPECIFIED
L3_DEFAULT UNSPECIFIED
ESP, GRE,
ICMP/ICMPv6(에코 요청만)
L3_DEFAULT UNSPECIFIED

여러 전달 규칙

동일한 네트워크 부하 분산기에 여러 리전 외부 전달 규칙을 구성할 수 있습니다. 각 전달 규칙마다 각기 다른 리전 외부 IP 주소가 있을 수 있으며 여러 전달 규칙이 동일한 리전 외부 IP 주소를 가질 수 있습니다.

여러 리전 외부 전달 규칙을 구성하면 다음과 같은 경우에 유용합니다.

  • 동일한 백엔드 서비스에 외부 IP 주소를 두 개 이상 구성해야 합니다.
  • 동일한 외부 IP 주소에 대해 다른 프로토콜이나 겹치지 않는 포트 또는 포트 범위를 구성해야 합니다.
  • 특정 소스 IP 주소에서 특정 부하 분산기 백엔드로 트래픽을 유도해야 합니다.

Google Cloud를 사용하려면 수신 패킷이 둘 이상의 전달 규칙과 일치해야 합니다. 다음 섹션에서 설명하는 조정 전달 규칙을 제외하면, 동일한 리전 외부 IP 주소를 사용하는 2개 이상의 전달 규칙은 다음과 같은 제약조건에 따라 고유한 프로토콜과 포트 조합을 포함해야 합니다.

  • 프로토콜의 모든 포트에 대하여 구성된 전달 규칙은 동일한 프로토콜 및 IP 주소를 사용하여 다른 전달 규칙을 만들 수 없습니다. TCP 또는 UDP 프로토콜을 사용하는 전달 규칙은 모든 포트를 사용하도록 구성하거나 특정 포트에 대해 구성할 수 있습니다. 예를 들어 IP 주소 198.51.100.1, TCP 프로토콜, 모든 포트를 사용하여 전달 규칙을 만드는 경우 IP 주소 198.51.100.1TCP 프로토콜을 사용한 다른 전달 규칙을 만들 수 없습니다. 고유한 포트 또는 중첩되지 않은 포트 범위가 있는 경우에는 IP 주소 198.51.100.1TCP 프로토콜을 사용하여 두 개의 전달 규칙을 만들 수 있습니다. 예를 들어 IP 주소 198.51.100.1 및 TCP 프로토콜을 사용하여 전달 규칙 2개를 만드는 것이 가능합니다. 이때 한 쪽 전달 규칙의 포트는 80,443이고 다른 하나의 전달 포트는 포트 범위 81-442를 사용합니다.
  • IP 주소당 L3_DEFAULT 전달 규칙을 하나만 만들 수 있습니다. 이는 정의에 따라 L3_DEFAULT 프로토콜이 모든 포트를 사용하기 때문입니다. 이 컨텍스트에서 모든 포트 용어는 포트 정보가 없는 프로토콜을 포함합니다.
  • 단일 L3_DEFAULT 전달 규칙은 특정 프로토콜(TCP 또는 UDP)을 사용하는 다른 전달 규칙과 공존할 수 있습니다. L3_DEFAULT 전달 규칙은 동일한 IP 주소를 사용하지만 더 구체적인 프로토콜이 있는 전달 규칙을 전달할 경우 최후의 수단으로 사용할 수 있습니다. L3_DEFAULT 전달 규칙은 패킷의 대상 IP 주소, 프로토콜, 대상 포트가 프로토콜별 전달 규칙과 일치하지 않는 경우에만 대상 IP 주소로 전송된 패킷을 처리합니다.

    이를 설명하기 위해 다음 두 시나리오를 가정해 보겠습니다. 두 시나리오의 전달 규칙은 동일한 IP 주소 198.51.100.1을 사용합니다.

    • 시나리오 1. 첫 번째 전달 규칙은 L3_DEFAULT 프로토콜을 사용합니다. 두 번째 전달 규칙은 TCP 프로토콜 및 모든 포트를 사용합니다. 198.51.100.1의 대상 포트로 전송된 TCP 패킷은 두 번째 전달 규칙에 의해 처리됩니다. 다른 프로토콜을 사용하는 패킷은 첫 번째 전달 규칙이 처리합니다.
    • 시나리오 2. 첫 번째 전달 규칙은 L3_DEFAULT 프로토콜을 사용합니다. 두 번째 전달 규칙은 TCP 프로토콜 및 포트 8080을 사용합니다. 198.51.100.1:8080으로 전송된 TCP 패킷은 두 번째 전달 규칙이 처리합니다. 다른 대상 포트로 전송된 TCP 패킷을 포함하여 다른 모든 패킷은 첫 번째 전달 규칙이 처리합니다.

전달 규칙 선택

Google Cloud는 이 삭제 프로세스를 사용하여 패킷의 대상 IP 주소와 일치하는 전달 규칙 후보 집합부터 시작하여 1개 또는 0개의 전달 규칙을 선택합니다.

  • L3_DEFAULT 전달 규칙을 제외하고, 프로토콜이 패킷의 프로토콜과 일치하지 않는 전달 규칙을 제거하세요. L3_DEFAULT 프로토콜을 사용하는 전달 규칙은 L3_DEFAULT가 모든 프로토콜과 일치하므로 이 단계를 통해 제거되지 않습니다. 예를 들어 패킷의 프로토콜이 TCP이면 UDP 프로토콜을 사용하는 전달 규칙만 삭제됩니다.

  • 포트가 패킷의 포트와 일치하지 않는 전달 규칙을 제거하세요. 모든 포트에서 구성된 전달 규칙은 모든 포트 전달 규칙이 모든 포트와 일치하므로 이 단계를 통해 제거되지 않습니다.

  • 나머지 전달 규칙 후보에 L3_DEFAULT 및 프로토콜별 전달 규칙이 모두 포함된 경우 L3_DEFAULT 전달 규칙을 제거합니다. 나머지 전달 규칙 후보가 모두 L3_DEFAULT 전달 규칙인 경우 이 단계에서 아무것도 제거되지 않습니다.

  • 이때 나머지 전달 규칙 후보는 다음 카테고리 중 하나에 해당합니다.

    • 패킷의 대상 IP 주소, 프로토콜 및 포트와 일치하는 단일 전달 규칙이 유지되며 패킷을 라우팅하는 데 사용됩니다.
    • 패킷의 대상 IP 주소, 프로토콜, 포트와 일치하는 전달 규칙 후보가 두 개 이상 유지됩니다. 즉, 나머지 전달 규칙 후보에는 조정 전달 규칙이 포함됩니다(다음 섹션에서 설명). 소스 범위에 패킷의 소스 IP 주소가 포함된 가장 구체적인(가장 긴 프리픽스 일치) CIDR이 포함된 조정 전달 규칙을 선택합니다. 조정 전달 규칙에 패킷의 소스 IP 주소를 포함한 소스 범위가 없으면 상위 전달 규칙을 선택합니다.
    • 전달 규칙 후보가 0개로 유지되며 패킷이 삭제됩니다.

전달 규칙 여러 개를 사용할 경우 백엔드 VM에서 실행 중인 소프트웨어가 부하 분산기 전달 규칙의 모든 외부 IP 주소에 바인딩되도록 구성해야 합니다.

트래픽 조정

네트워크 부하 분산기의 전달 규칙은 특정 범위의 소스 IP 주소에서 들어오는 트래픽을 특정 백엔드 서비스(또는 대상 인스턴스)로 전달하도록 구성할 수 있습니다.

트래픽 조정은 문제 해결과 고급 구성에 유용합니다. 트래픽 조정을 사용하면 특정 클라이언트를 다른 백엔드 집합, 다른 백엔드 서비스 구성 또는 둘 다에 전달할 수 있습니다. 예를 들면 다음과 같습니다.

  • 트래픽 조정을 사용하면 두 개의 백엔드 서비스를 통해 동일한 백엔드 인스턴스 그룹으로 트래픽을 전달하는 두 개의 전달 규칙을 만들 수 있습니다. 두 개의 백엔드 서비스는 다른 상태 확인, 다른 세션 어피니티 또는 다른 트래픽 분산 제어 정책(연결 추적, 연결 드레이닝, 장애 조치)으로 구성할 수 있습니다.
  • 트래픽 조정을 사용하면 서로 다른 백엔드 인스턴스 그룹과 함께 서로 다른 백엔드 서비스로 트래픽을 전달하는 두 가지 전달 규칙을 만들 수 있습니다. 예를 들어 특정 소스 IP 주소 집합의 트래픽을 보다 잘 처리하기 위해 다양한 머신 유형을 사용하여 하나의 인스턴스 그룹을 구성할 수 있습니다.

트래픽 조정은 sourceIPRanges라는 전달 규칙 API 매개변수로 구성됩니다. 소스 IP 범위가 하나 이상 구성된 전달 규칙을 조정 전달 규칙이라고 합니다.

조정 전달 규칙에는 최대 64개의 소스 IP 범위 목록이 있을 수 있습니다. 조정 전달 규칙에 구성된 소스 IP 범위 목록을 언제든지 업데이트할 수 있습니다.

각 전달 규칙에서는 먼저 상위 전달 규칙을 만들어야 합니다. 상위 및 조정 전달 규칙은 동일한 리전 외부 IP 주소, IP 프로토콜, 포트 정보를 공유합니다. 그러나 상위 전달 규칙에는 소스 IP 주소 정보가 없습니다. 예를 들면 다음과 같습니다.

  • 상위 전달 규칙: IP 주소: 198.51.100.1, IP 프로토콜: TCP, 포트: 80
  • 조정 전달 규칙: IP 주소: 198.51.100.1, IP 프로토콜: TCP, 포트: 80, sourceIPRanges: 203.0.113.0/24

백엔드 서비스를 가리키는 상위 전달 규칙은 백엔드 서비스 또는 대상 인스턴스를 가리키는 조정 전달 규칙과 연결할 수 있습니다.

지정된 상위 전달 규칙의 경우 두 개 이상의 조정 전달 규칙은 소스 IP 범위가 겹칠 수 있지만 동일하지는 않습니다. 예를 들어 하나의 조정 전달 규칙은 소스 IP 범위 203.0.113.0/24를 가질 수 있고, 동일한 상위 항목에 대한 또 다른 조정 전달 규칙은 소스 IP 범위 203.0.113.0을 가질 수 있습니다.

종속 상위 전달 규칙을 삭제하려면 먼저 모든 조정 전달 규칙을 삭제해야 합니다.

조정 전달 규칙이 사용되는 경우 수신 패킷이 처리되는 방식을 알아보려면 전달 규칙 선택을 참조하세요.

조정 변경사항에서 세션 어피니티 동작

이 섹션에서는 조정 전달 규칙의 소스 IP 범위가 업데이트될 때 세션 어피니티가 중단될 수 있는 조건을 설명합니다.

  • 조정 전달 규칙의 소스 IP 범위를 변경한 후 기존 연결이 동일한 전달 규칙과 계속 일치하면 세션 어피니티가 중단되지 않습니다. 변경으로 인해 기존 연결이 다른 전달 규칙과 일치하는 경우:
  • 세션 어피니티는 다음과 같은 상황에서 항상 중단됩니다.
    • 새로 일치하는 전달 규칙은 이전에 선택한 백엔드 VM을 참조하지 않는 백엔드 서비스(또는 대상 인스턴스)로 설정된 연결을 전달합니다.
    • 새로 일치하는 전달 규칙은 설정된 연결을 이전에 선택한 백엔드 VM을 참조하는 백엔드 서비스로 전달하지만, 백엔드 서비스는 백엔드가 비정상일 때 연결을 유지하도록 구성되어 있지 않으며, 백엔드 VM이 백엔드 서비스의 상태 확인에 실패합니다.
  • 새로 일치하는 전달 규칙이 설정된 연결을 백엔드 서비스로 전달하고 백엔드 서비스가 이전에 선택한 VM을 참조하는 경우 세션 어피니티가 중단될 수 있지만, 백엔드 서비스의 세션 어피니티와 연결 추적 모드의 조합으로 인해 다른 연결 추적 해시가 발생합니다.

조정 변경사항에서 세션 어피니티 보존

이 섹션에서는 조정 전달 규칙의 소스 IP 범위가 업데이트될 때 세션 어피니티가 중단되는 것을 방지하는 방법을 설명합니다.

  • 백엔드 서비스를 가리키는 조정 전달 규칙. 상위 요소 및 조정 전달 규칙이 모두 백엔드 서비스를 가리키는 경우 세션 어피티니연결 추적 정책 설정이 동일한지 수동으로 확인해야 합니다. Google Cloud는 동일하지 않은 구성을 자동으로 거부하지 않습니다.
  • 대상 인스턴스를 가리키는 조정 전달 규칙. 백엔드 서비스를 가리키는 상위 전달 규칙은 대상 인스턴스를 가리키는 조정 전달 규칙과 연결할 수 있습니다. 이 경우 조정 전달 규칙은 상위 전달 규칙에서 세션 어피니티연결 추적 정책 설정을 상속합니다.

트래픽 조정을 구성하는 방법에 대한 안내는 트래픽 조정 구성을 참조하세요.

리전별 백엔드 서비스

각 네트워크 부하 분산기에는 부하 분산기 동작과 트래픽이 백엔드에 배포되는 방식을 정의하는 리전 백엔드 서비스 하나가 포함됩니다. 백엔드 서비스 이름은 Google Cloud Console에 표시된 네트워크 부하 분산기의 이름입니다.

각 백엔드 서비스는 다음과 같은 백엔드 매개변수를 정의합니다.

  • 프로토콜. 백엔드 서비스는 하나 이상의 리전 외부 전달 규칙에 지정된 IP 주소 및 포트(구성된 경우)에서 트래픽을 허용합니다. 백엔드 서비스는 패킷의 소스 및 대상 IP 주소, 프로토콜, 프로토콜이 포트 기반인 경우 소스 및 대상 포트를 보존하면서 백엔드 VM에 패킷을 전달합니다.

    네트워크 부하 분산 기에 사용되는 백엔드 서비스는 TCP, UDP, UNSPECIFIED 프로토콜 옵션을 지원합니다.

    UNSPECIFIED 프로토콜의 백엔드 서비스는 전달 규칙 프로토콜에 관계없이 모든 전달 규칙에 사용될 수 있습니다. 특정 프로토콜(TCP 또는 UDP)의 백엔드 서비스는 같은 프로토콜(TCP 또는 UDP)의 전달 규칙으로만 참조될 수 있습니다. L3_DEFAULT 프로토콜의 전달 규칙은 UNSPECIFIED 프로토콜의 백엔드 서비스만 참조할 수 있습니다.

    전달 규칙과 백엔드 서비스 프로토콜의 가능한 조합이 나와 있는 표는 전달 규칙 프로토콜 사양을 참조하세요.

  • 트래픽 분산. 백엔드 서비스는 구성 가능한 세션 어피니티연결 추적 정책에 따라 트래픽 분산을 허용합니다. 또한 백엔드 서비스에서 연결 드레이닝을 사용 설정하고 부하 분산기에 장애 조치 백엔드를 지정하도록 구성할 수 있습니다.

  • 상태 확인. 백엔드 서비스에는 연결된 리전 상태 확인이 있어야 합니다.

각 백엔드 서비스는 단일 리전에서 작동하며 트래픽을 백엔드 VM의 첫 번째 네트워크 인터페이스(nic0)에 분산합니다. 백엔드는 백엔드 서비스(및 전달 규칙)와 동일한 리전에 있는 인스턴스 그룹이어야 합니다. 백엔드는 영역 비관리형 인스턴스 그룹, 영역 관리형 인스턴스 그룹 또는 리전 관리형 인스턴스 그룹일 수 있습니다.

백엔드 서비스 기반 네트워크 부하 분산기는 VPC 네트워크가 백엔드 서비스와 같이 동일한 프로젝트에 있는 한 구성원 인스턴스가 동일한 리전에서 모든 VPC 네트워크를 사용하는 인스턴스 그룹을 지원합니다. (특정 인스턴스 그룹 내 모든 VM은 동일한 VPC 네트워크를 사용해야 합니다.)

부하 분산기가 IPv6 트래픽을 지원하도록 하려면 백엔드 서비스가 IPv6 트래픽 처리 요구사항을 충족하는 백엔드를 참조해야 합니다.

백엔드 인스턴스 그룹

네트워크 부하 분산기는 관리형 또는 비관리형 인스턴스 그룹 내에 포함된 백엔드 VM 간에 연결을 분산합니다. 인스턴스 그룹은 범위 내 리전이나 영역일 수 있습니다.

  • 리전 관리형 인스턴스 그룹 인스턴스 템플릿을 사용하여 소프트웨어를 배포할 수 있으면 리전 관리형 인스턴스 그룹을 사용합니다. 리전 관리형 인스턴스 그룹은 여러 영역 간에 트래픽을 자동으로 분산하므로 특정 영역에서 발생할 수 있는 문제를 방지하는 최고의 방법입니다.

    리전 관리형 인스턴스 그룹을 사용한 배포 예시는 다음과 같습니다. 인스턴스 그룹에는 인스턴스를 프로비저닝하는 방법을 정의하는 인스턴스 템플릿이 있으며 각 그룹은 us-central1 리전의 영역 세 개 내에 인스턴스를 배포합니다.

    리전 관리형 인스턴스 그룹이 있는 네트워크 부하 분산기
    리전 관리형 인스턴스 그룹을 사용하는 네트워크 부하 분산
  • 영역 관리형 또는 비관리형 인스턴스 그룹. 같은 리전 내 다른 영역에 있는 영역 인스턴스 그룹을 사용하여 특정 영역에서 문제가 발생하지 않도록 보호할 수 있습니다.

    영역 인스턴스 그룹을 사용한 배포 예시는 다음과 같습니다. 이 부하 분산기는 두 영역 간에 가용성을 제공합니다.

    영역 인스턴스 그룹이 있는 네트워크 부하 분산기
    영역 인스턴스 그룹을 사용하는 네트워크 부하 분산

부하 분산기가 IPv6 트래픽을 지원하기 위해서는 백엔드가 다음 요구사항을 충족해야 합니다.

  • 백엔드는 부하 분산기의 IPv6 전달 규칙과 동일한 리전에 있는 이중 스택 서브넷에서 구성되어야 합니다. 백엔드의 경우 ipv6-access-typeEXTERNAL 또는 INTERNAL로 설정된 서브넷을 사용할 수 있습니다. ipv6-access-typeINTERNAL로 설정된 서브넷을 사용하려면 부하 분산기의 외부 전달 규칙에 대해 ipv6-access-typeEXTERNAL로 설정된 별도의 이중 스택 서브넷을 사용해야 합니다. 자세한 내용은 이중 스택 서브넷 추가를 참조하세요.
  • 백엔드 인스턴스 그룹은 --ipv6-network-tierPREMIUM로 설정된 이중 스택으로 구성되어야 합니다. 자세한 내용은 IPv6 주소로 인스턴스 템플릿 만들기를 참조하세요.

상태 점검

네트워크 부하 분산에서는 리전 상태 확인을 사용하여 새 연결을 수신할 수 있는 인스턴스를 결정합니다. 각 네트워크 부하 분산기의 백엔드 서비스는 리전 상태 확인과 연결되어야 합니다. 부하 분산기는 상태 확인 상태를 사용하여 백엔드 인스턴스에 새 연결을 라우팅하는 방법을 결정합니다.

Google Cloud 상태 확인 작동 방식에 대한 자세한 내용은 상태 확인 작동 방식을 참조하세요.

네트워크 부하 분산에서는 다음 유형의 상태 확인을 지원합니다.

  • HTTP, HTTPS, HTTP/2. 백엔드 VM에서 HTTP, HTTPS 또는 HTTP/2를 사용하여 트래픽을 처리하는 경우에는 이러한 프로토콜과 일치하는 상태 확인을 사용하는 것이 가장 좋습니다. 자세한 내용은 HTTP, HTTPS, HTTP/2 상태 확인의 성공 기준을 참조하세요.
  • SSL 또는 TCP. 백엔드 VM에서 HTTP 유형 트래픽을 처리하지 않는 경우에는 SSL 또는 TCP 상태 확인을 사용해야 합니다. 자세한 내용은 SSL 및 TCP 상태 확인의 성공 기준을 참조하세요.

다른 프로토콜 트래픽 상태 확인

Google Cloud는 여기에 나열된 항목 외에는 프로토콜별 상태 확인을 제공하지 않습니다. 네트워크 부하 분산을 사용하여 TCP 이외의 프로토콜 부하를 분산하는 경우에도 백엔드 VM에서 TCP 기반 서비스를 실행하여 필요한 상태 확인 정보를 제공해야 합니다.

예를 들어 UDP 트래픽을 부하 분산하는 경우 UDP 프로토콜을 사용하여 클라이언트 요청이 부하 분산되며, TCP 서비스를 사용하여 Google Cloud 상태 확인 프로브에 정보를 제공해야 합니다. 이를 달성하기 위해서는 HTTP 200 응답을 상태 확인 프로브에 반환하는 각 백엔드 VM에서 간단한 HTTP 서버를 실행할 수 있습니다. UDP 서비스가 올바르게 구성되었고 실행될 경우에만 HTTP 서버가 200을 반환하는지 확인하기 위해 백엔드 VM에서 실행되는 고유 논리를 사용해야 합니다.

방화벽 규칙

네트워크 부하 분산은 패스스루 부하 분산기이므로 Google Cloud 방화벽 규칙을 사용하여 부하 분산기의 백엔드에 대한 액세스를 제어합니다. 인그레스 허용 방화벽 규칙 또는 인그레스 허용 계층식 방화벽 정책을 만들어 상태 확인 및 부하 분산을 수행하는 트래픽을 허용해야 합니다.

전달 규칙 및 인그레스는 방화벽 규칙 또는 계층적 방화벽 정책이 다음 방식으로 함께 작동하도록 허용합니다. 여기에서 전달 규칙은 프로토콜을 지정하고, 정의된 경우 백엔드 VM에 전달되기 위해 패킷이 충족시켜야 하는 포트 요구 사항을 지정합니다. 인그레스는 전달된 패킷이 VM에 전달되거나 삭제되는지 여부를 방화벽 규칙으로 제어할 수 있게 해줍니다. 모든 VPC 네트워크에는 소스에서 수신되는 패킷을 차단하는 묵시적 인그레스 거부 방화벽 규칙이 있습니다. Google Cloud 기본 VPC 네트워크에는 자동 입력된 인그레스 허용 방화벽 규칙이 일부 제한적으로 포함되어 있습니다.

  • 인터넷의 모든 IP 주소로부터 트래픽을 허용하려면 0.0.0.0/0 소스 범위로 인그레스 허용 방화벽 규칙을 만들어야 합니다. 특정 IP 주소 범위의 트래픽만 허용하려면 더 제한적인 소스 범위를 사용합니다.

  • 보안 권장사항에 따라 인그레스 허용 방화벽 규칙은 필요한 IP 프로토콜 및 포트만 허용해야 합니다. 프로토콜(및 가능한 경우 포트) 구성을 제한하는 것은 해당 프로토콜이 L3_DEFAULT로 설정된 전달 규칙을 사용할 때 특히 중요합니다. L3_DEFAULT 전달 규칙은(프로토콜과 패킷에 포트 정보가 포함된 경우에는 모든 포트에서) 지원되는 모든 IP 프로토콜의 패킷을 전달합니다.

  • 네트워크 부하 분산은 Google Cloud 상태 확인을 사용합니다. 따라서 항상 상태 확인 IP 주소 범위의 트래픽을 허용해야 합니다. 이러한 인그레스 허용 방화벽 규칙을 부하 분산기 상태 확인의 프로토콜과 포트에 따라 만들 수 있습니다.

요청 및 반환 패킷의 IP 주소

백엔드 VM이 클라이언트에서 부하 분산된 패킷을 수신하면 패킷의 소스 및 대상은 다음과 같습니다.

  • 소스: Google Cloud VM과 연결된 외부 IP 주소 또는 부하 분산기에 연결하는 시스템의 인터넷 라우팅이 가능한 IP 주소입니다.
  • 대상: 부하 분산기의 전달 규칙의 IP 주소입니다.

부하 분산기는 프록시가 아닌 패스스루 부하 분산기이므로 패킷은 부하 분산기 전달 규칙의 대상 IP 주소를 갖습니다. 백엔드 VM에서 실행되는 소프트웨어는 다음을 수행하도록 구성되어야 합니다.

  • 부하 분산기의 전달 규칙 IP 주소 또는 모든 IP 주소(0.0.0.0 또는 ::)에 리슨(결합)
  • 부하 분산기 전달 규칙의 프로토콜이 포트를 지원하는 경우: 부하 분산기의 전달 규칙에 포함된 포트를 리슨(결합)

반환 패킷은 부하 분산기의 백엔드 VM에서 클라이언트로 직접 전송됩니다. 반환 패킷의 소스 및 대상 IP 주소는 프로토콜에 따라 달라집니다.

  • TCP는 연결 지향적이므로 클라이언트가 적절한 TCP 연결로 응답 패킷을 연결할 수 있도록 백엔드 VM은 소스 IP 주소가 전달 규칙의 IP 주소와 일치하는 패킷으로 응답해야 합니다.
  • UDP, ESP, GRE, ICMP는 연결 지향적이지 않습니다. 백엔드 VM은 소스 IP 주소가 전달 규칙의 IP 주소와 일치하거나 VM에 할당된 외부 IP 주소와 일치하는 응답 패킷을 보낼 수 있습니다. 사실상 대부분의 클라이언트는 패킷을 전송한 IP 주소와 동일한 IP주소에서 응답을 받아야 합니다.

다음 표에는 응답 패킷에 대한 소스 및 대상이 요약되어 있습니다.

트래픽 유형 소스 목적지
TCP 부하 분산기의 전달 규칙에 해당하는 IP 주소 요청 패킷의 소스
UDP, ESP, GRE, ICMP 대부분의 사용 사례에서는 부하 분산기 전달 규칙의 IP 주소 요청 패킷의 소스

VM에 외부 IP 주소가 있거나 Cloud NAT를 사용할 때 응답 패킷의 소스 IP 주소를 VM NIC의 기본 내부 IPv4 주소로 설정할 수도 있습니다. Google Cloud 또는 Cloud NAT는 응답 패킷을 클라이언트의 외부 IP 주소로 전송하기 위해 응답 패킷의 소스 IP 주소를 NIC의 외부 IPv4 주소 또는 Cloud NAT 외부 IPv4 주소로 변경합니다. 전달 규칙의 IP 주소를 소스로 사용하지 않는 경우는 클라이언트가 요청 패킷을 전송한 IP 주소와 일치하지 않는 외부 IP 주소로부터 응답 패킷을 받으므로 고차원적 시나리오에 해당합니다.

반환 경로

네트워크 부하 분산에서는 VPC 네트워크 외부의 특수 경로를 사용하여 들어오는 요청과 상태 확인 프로브를 각 백엔드 VM에 전달합니다.

부하 분산기는 패킷의 소스 IP 주소를 유지합니다. 백엔드 VM의 응답은 부하 분산기를 통하지 않고 클라이언트에 직접 전달됩니다. 업계에서는 이를 직접 서버 반환이라 합니다.

공유 VPC 아키텍처

IP 주소를 제외한 네트워크 부하 분산기의 모든 구성요소는 동일한 프로젝트에 있어야 합니다. 다음 표에는 네트워크 부하 분산의 공유 VPC 구성요소가 요약되어 있습니다.

IP 주소 전달 규칙 백엔드 구성요소
리전 외부 IP 주소는 부하 분산기 또는 공유 VPC 호스트 프로젝트와 동일한 프로젝트에 정의되어야 합니다. 리전 외부 전달 규칙은 백엔드 서비스의 인스턴스와 동일한 프로젝트에 정의되어 있어야 합니다.

리전 백엔드 서비스는 백엔드 인스턴스 그룹의 인스턴스가 있는 동일한 프로젝트와 동일한 리전에서 정의되어야 합니다.

백엔드 서비스와 연결된 상태 확인은 백엔드 서비스와 동일한 프로젝트 및 동일한 리전에 정의되어야 합니다.

트래픽 분산

네트워크 부하 분산기가 새 연결을 분산하는 방식은 장애 조치 구성 여부에 따라 다릅니다.

  • 장애 조치를 구성하지 않은 경우 백엔드 VM이 최소 한 개 이상 정상이면 네트워크 부하 분산기가 정상 백엔드 VM에 새 연결을 분산합니다. 모든 백엔드 VM이 비정상인 경우에는 부하 분산기가 최후의 수단으로 새 연결을 모든 백엔드 간에 분산시킵니다. 이 경우 부하 분산기는 각 새 연결을 비정상 백엔드 VM으로 라우팅합니다.
  • 장애 조치를 구성한 경우 네트워크 부하 분산기는 구성한 장애 조치 정책에 따라 활성 풀의 정상적인 백엔드 VM 간에 새 연결을 분산합니다. 모든 백엔드 VM이 비정상인 경우에는 다음 동작 중 하나를 선택할 수 있습니다.
    • (기본값) 부하 분산기는 기본 VM에만 트래픽을 분산합니다. 이 작업은 최후의 수단으로 진행됩니다. 백업 VM은 이 최후의 연결 분산에서 제외됩니다.
    • 부하 분산기가 트래픽을 삭제합니다.

연결이 분산되는 방법에 대한 자세한 내용은 다음 섹션 백엔드 선택 및 연결 추적을 참조하세요.

장애 조치의 작동 방식에 대한 자세한 내용은 장애 조치 섹션을 참조하세요.

백엔드 선택 및 연결 추적

네트워크 부하 분산은 구성 가능한 백엔드 선택 및 연결 추적 알고리즘을 사용하여 트래픽이 백엔드 VM에 분산된 상태를 확인합니다.

네트워크 부하 분산은 다음 알고리즘을 사용하여 백엔드 VM(장애 조치를 구성한 경우 활성 풀의 백엔드 VM) 간에 패킷을 분산합니다.

  1. 부하 분산기의 연결 추적 테이블에 수신 패킷의 특성과 일치하는 항목이 있으면 연결 추적 테이블 항목에 지정된 백엔드로 패킷이 전송됩니다. 패킷은 이전에 설정된 연결의 일부로 간주되므로 부하 분산기가 이전에 결정하여 연결 추적 테이블에 기록한 백엔드 VM으로 패킷이 전송됩니다.
  2. 부하 분산기는 연결 추적 항목이 없는 패킷이 수신되면 다음을 수행합니다.

    1. 부하 분산기가 백엔드를 선택합니다. 부하 분산기는 구성된 세션 어피니티를 기준으로 해시를 계산합니다. 이 해시를 사용해서 현재 정상인 항목들 간에 백엔드를 선택합니다(장애 조치 정책이 이 상황에서 트래픽을 삭제하도록 구성되어 있지 않은 한 모든 백엔드가 고려되는, 모든 백엔드가 비정상이 아닌 경우). 기본 세션 어피니티 NONE은 다음 해시 알고리즘을 사용합니다.

      • TCP 및 조각화되지 않은 UDP 패킷: 패킷의 소스 IP 주소, 소스 포트, 대상 IP 주소, 대상 포트, 프로토콜의 5튜플 해시
      • 조각화된 UDP 패킷 및 다른 모든 프로토콜: 패킷의 소스 IP 주소, 대상 IP 주소, 프로토콜의 3튜플 해시

      백엔드 선택은 더 적은 정보를 사용하는 해시 알고리즘을 사용해서 맞춤설정될 수 있습니다. 지원되는 모든 옵션에 대해 세션 어피니티 옵션을 참조하세요.

    2. 부하 분산기가 연결 추적 테이블에 항목을 추가합니다. 이 항목은 이 연결의 모든 이후 패킷이 동일한 백엔드로 전송되도록 패킷 연결에 대해 선택된 백엔드를 기록합니다. 연결 추적 사용 여부는 프로토콜에 따라 달라집니다.

      • TCP 패킷. 연결 추적은 항상 사용 설정되며, 해제할 수 없습니다. 기본적으로 연결 추적은 5튜플이지만, 5튜플 미만으로 구성될 수 있습니다. 5튜플인 경우 TCP SYN 패킷이 다르게 취급됩니다. 비SYN 패킷과 달리 모든 일치하는 연결 추적 항목을 삭제하고 항상 새 백엔드를 선택합니다.

        기본 5튜플 연결 추적은 다음과 같은 경우에 사용됩니다.

        • 추적 모드가 PER_CONNECTION(모든 세션 어피니티)이거나,
        • 추적 모드가 PER_SESSION이고 세션 어피니티가 NONE이거나,
        • 추적 모드가 PER_SESSION이고 세션 어피니티가 CLIENT_IP_PORT_PROTO
      • UDP, ESP, GRE 패킷. 연결 추적은 세션 어피니티가 NONE 이외의 다른 항목으로 설정된 경우에만 사용 설정됩니다.

      • ICMP 패킷. 연결 추적을 사용할 수 없습니다.

      어떤 경우에 연결 추적이 사용 설정되는지 및 그러한 경우에 어떤 추적 방법이 사용되는지에 대한 자세한 내용은 연결 추적 모드를 참조하세요.

      또한 다음을 참조하세요.

      • 연결 추적 테이블의 항목은 부하 분산기가 항목과 일치한 마지막 패킷을 처리하고 나서 60초 후 만료됩니다. 이 60초 유휴 제한 시간 값은 구성할 수 없습니다.
      • 프로토콜에 따라서는 백엔드가 비정상이 될 때 부하 분산기가 연결 추적 테이블의 항목을 삭제할 수 있습니다. 이 동작을 맞춤설정하는 방법 등 자세한 내용은 비정상 백엔드의 연결 지속성을 참조하세요.

세션 어피니티 옵션

세션 어피니티는 클라이언트에서 부하 분산기의 백엔드 VM으로의 새 연결 배포를 제어합니다. 세션 어피니티는 백엔드 인스턴스 그룹별이 아니라 리전 외부 백엔드 서비스 전체에 대해 지정됩니다.

네트워크 부하 분산은 다음 세션 어피니티 옵션을 지원합니다.

  • 없음(NONE). 소스 IP 주소, 소스 포트, 프로토콜, 대상 IP 주소, 대상 포트의 5튜플 해시
  • 클라이언트 IP, 대상 IP(CLIENT_IP). 소스 IP 주소와 대상 IP 주소의 2튜플 해시
  • 클라이언트 IP, 대상 IP, 프로토콜(CLIENT_IP_PROTO). 소스 IP 주소, 대상 IP 주소, 프로토콜의 3튜플 해시
  • 클라이언트 IP, 클라이언트 포트, 대상 IP, 대상 포트, 프로토콜(CLIENT_IP_PORT_PROTO). 소스 IP 주소, 소스 포트, 프로토콜, 대상 IP 주소, 대상 포트의 5튜플 해시

이러한 세션 어피니티 옵션이 백엔드 선택 및 연결 추적 방법에 주는 영향에 대해서는 이 표를 참조하세요.

연결 추적 모드

연결 추적의 사용 설정 여부는 부하 분산 트래픽의 프로토콜 및 세션 어피니티 설정에 따라서만 달라집니다. 추적 모드는 연결 추적을 사용 설정한 경우에 사용될 연결 추적 알고리즘을 지정합니다. 추적 모드는 PER_CONNECTION(기본값) 및 PER_SESSION 두 가지입니다.

  • PER_CONNECTION(기본값). 이는 기본 추적 모드입니다. 이 연결 추적 모드에서 TCP 트래픽은 세션 어피니티 설정에 관계없이 항상 5튜플마다 추적됩니다. UDP, ESP, GRE 트래픽의 경우 선택한 세션 어피니티가 NONE아닌 경우 연결 추적이 사용 설정됩니다. UDP, ESP, GRE 패킷은 이 테이블에 설명된 추적 방법을 사용하여 추적합니다.

  • PER_SESSION. 세션 어피니티가 CLIENT_IP 또는 CLIENT_IP_PROTO인 경우, 이 모드를 구성하면 모든 프로토콜에 대해 각각 2튜플 및 3튜플 연결 추적이 발생합니다(연결 추적이 불가능한 ICMP 제외). 다른 세션 어피니티 설정의 경우 PER_SESSION 모드가 PER_CONNECTION 모드와 동일하게 작동합니다.

각 프로토콜의 다양한 세션 어피니티 설정에 따라 이러한 추적 모드가 작동하는 방식은 다음 표를 참조하세요.

백엔드 선택 연결 추적 모드
세션 어피니티 설정 백엔드 선택을 위한 해시 방법 PER_CONNECTION(기본) PER_SESSION
기본값: 세션 어피니티 없음

(NONE)

TCP 및 조각화되지 않은 UDP: 5튜플 해시

조각화된 UDP 및 다른 모든 프로토콜: 3튜플 해시

  • TCP: 5튜플 연결 추적
  • 다른 모든 프로토콜: 연결 추적 사용 안함
  • TCP: 5튜플 연결 추적
  • 다른 모든 프로토콜: 연결 추적 사용 안함
클라이언트 IP, 대상 IP

(CLIENT_IP)

모든 프로토콜: 2튜플 해시
  • TCP 및 조각화되지 않은 UDP: 5튜플 연결 추적
  • 조각화된 UDP, ESP, GRE: 3튜플 연결 추적
  • 다른 모든 프로토콜: 연결 추적 사용 안함
  • TCP, UDP, ESP, GRE: 2튜플 연결 추적
  • 다른 모든 프로토콜: 연결 추적 사용 안함
클라이언트 IP, 대상 IP, 프로토콜

(CLIENT_IP_PROTO)

모든 프로토콜: 3튜플 해시
  • TCP 및 조각화되지 않은 UDP: 5튜플 연결 추적
  • 조각화된 UDP, ESP, GRE: 3튜플 연결 추적
  • 다른 모든 프로토콜: 연결 추적 사용 안함
  • TCP, UDP, ESP, GRE: 3튜플 연결 추적
  • 다른 모든 프로토콜: 연결 추적 사용 안함
클라이언트 IP, 클라이언트 포트, 대상 IP, 대상 포트, 프로토콜

(CLIENT_IP_PORT_PROTO)

TCP 및 조각화되지 않은 UDP: 5튜플 해시

조각화된 UDP 및 다른 모든 프로토콜: 3튜플 해시

  • TCP 및 조각화되지 않은 UDP: 5튜플 연결 추적
  • 조각화된 UDP, ESP, GRE: 3튜플 연결 추적
  • 다른 모든 프로토콜: 연결 추적 사용 안함
  • TCP 및 조각화되지 않은 UDP: 5튜플 연결 추적
  • 조각화된 UDP, ESP, GRE: 3튜플 연결 추적
  • 다른 모든 프로토콜: 연결 추적 사용 안함

연결 추적 모드를 변경하는 방법은 연결 추적 정책 구성을 참조하세요.

비정상 백엔드의 연결 지속성

연결 지속성 설정은 선택한 백엔드가 비정상이 된 후 해당 백엔드에서 기존 연결이 지속되는지 여부를 제어합니다. 단, 백엔드가 부하 분산기의 구성된 백엔드 인스턴스 그룹에 남아 있어야 합니다.

이 섹션에 설명된 동작은 해당 인스턴스 그룹에서 백엔드 VM을 삭제하거나 백엔드 서비스에서 인스턴스 그룹을 삭제하는 경우에 적용되지 않습니다. 이러한 경우 연결 드레이닝에 설명된 것처럼 설정된 연결만 지속됩니다.

다음 연결 지속성 옵션을 사용할 수 있습니다.

  • DEFAULT_FOR_PROTOCOL(기본)
  • NEVER_PERSIST
  • ALWAYS_PERSIST

다음 표에서는 연결 지속성 옵션을 보여주고 다양한 프로토콜, 세션 어피니티 옵션, 추적 모드에 대해 연결이 지속되는 방식을 요약합니다.

비정상 백엔드의 연결 지속성 옵션 연결 추적 모드
PER_CONNECTION PER_SESSION
DEFAULT_FOR_PROTOCOL

TCP: 비정상 백엔드에서 연결 지속(모든 세션 어피니티)

다른 모든 프로토콜: 비정상 백엔드에서 연결 지속 안함

TCP: 세션 어피니티가 NONE 또는 CLIENT_IP_PORT_PROTO이면 비정상 백엔드에서 연결 지속

다른 모든 프로토콜: 비정상 백엔드에서 연결 지속 안함

NEVER_PERSIST 모든 프로토콜: 비정상 백엔드에서 연결 지속 안함
ALWAYS_PERSIST

TCP: 비정상 백엔드에서 연결 지속(모든 세션 어피니티)

ESP, GRE, UDP: 세션 어피니티가 NONE이 아닌 경우 비정상 백엔드에서 연결 지속

ICMP: ICMP는 연결 추적이 불가능하므로 해당 없음

이 옵션은 고급 사용 사례에서만 사용해야 합니다.

구성할 수 없음

비정상 백엔드의 TCP 연결 지속성 동작

5튜플 추적의 TCP 연결이 비정상 백엔드에서 지속될 때마다 다음이 적용됩니다.

  • 비정상 백엔드가 패킷에 계속 응답하는 경우 비정상 백엔드 또는 클라이언트에 의해 연결이 재설정되거나 닫힐 때까지 연결이 계속됩니다.
  • 비정상 백엔드가 TCP 재설정(RST) 패킷을 전송하거나 패킷에 응답하지 않는 경우 클라이언트가 새 연결로 재시도하여, 부하 분산기가 다른 정상 백엔드를 선택하도록 허용합니다. TCP SYN 패킷은 항상 새로운 정상 백엔드를 선택합니다.

연결 지속성 동작 변경 방법은 연결 추적 정책 구성을 참조하세요.

연결 드레이닝

연결 드레이닝은 설정된 연결에 대해 다음과 같은 경우에 적용되는 프로세스입니다.

  • 백엔드 VM이 인스턴스 그룹에서 삭제되는 경우
  • 관리형 인스턴스 그룹에서 교체, 중단, 롤링 업그레이드 또는 축소로 백엔드 VM을 삭제하는 경우
  • 인스턴스 그룹이 백엔드 서비스에서 삭제되는 경우

기본적으로 연결 드레이닝은 사용 중지되어 있습니다. 사용 중지된 경우 기존 연결이 가능한 한 빠르게 종료됩니다. 연결 드레이닝이 사용 설정되었으면 백엔드 VM 인스턴스가 종료된 후 기존 연결이 구성 가능한 제한 시간 동안 지속되도록 허용합니다.

연결 드레이닝이 트리거되는 방법과 연결 드레이닝을 사용 설정하는 방법에 대한 자세한 내용은 연결 드레이닝 사용 설정을 참조하세요.

UDP 조각화

네트워크 부하 분산은 조각화된 및 조각화되지 않은 UDP 패킷을 모두 처리합니다. 조각화되지 않은 패킷은 모든 구성에서 정상적으로 처리됩니다. 애플리케이션에 조각화된 UDP 패킷이 사용될 경우 다음을 염두에 두어야 합니다.

  • UDP 패킷은 Google Cloud VPC 네트워크에 도달하기 전에 조각화될 수 있습니다.
  • Google Cloud VPC 네트워크는 모든 조각이 도착하기를 기다리지 않고 UDP 조각을 전달합니다.
  • Google Cloud 이외의 네트워크 및 온프레미스 네트워크 장비는 UDP 조각을 도착 즉시 전달하거나, 조각화된 UDP 패킷을 모든 조각이 도착할 때까지 지연시키거나, 조각화된 UDP 패킷을 삭제할 수 있습니다. 자세한 내용은 다른 네트워크 제공업체 또는 네트워크 장비에 대한 문서를 참조하세요.

조각화된 UDP 패킷이 수신될 것으로 예상되면 다음을 수행합니다.

  • 부하 분산된 IP 주소당 UDP 또는 L3_DEFAULT 전달 규칙 하나만 사용하고 전달 규칙이 모든 포트의 트래픽을 수락하도록 구성합니다. 이렇게 하면 대상 포트가 동일하지 않은 경우에도 모든 프래그먼트가 동일한 전달 규칙으로 이동합니다. 모든 포트를 구성하려면 Google Cloud CLI를 사용하여 --ports=ALL를 설정하거나 API를 사용하여 allPortsTrue로 설정합니다.

  • 다음 방법 중 하나를 사용하여 백엔드 서비스를 구성합니다.

    • 세션 어피니티 및 연결 추적을 사용 중지합니다. 세션 어피니티를 NONE으로 설정합니다. 부하 분산기는 5튜플 해시를 사용하여 조각화되지 않은 패킷(포트 정보 포함)에 대해 백엔드를 선택하고, 조각화된 패킷(포트 정보 없음)에 대해 3튜플 해시를 사용합니다. 이 설정에서 동일한 클라이언트의 조각화된 및 조각화되지 않은 UDP 패킷은 다른 백엔드로 전달될 수 있습니다.
    • 2튜플 또는 3튜플 세션 어피니티 및 연결 추적을 사용 설정합니다. 세션 어피니티를 CLIENT_IP 또는 CLIENT_IP_PROTO로 설정하고 연결 추적 모드를 PER_SESSION으로 설정합니다. 이 설정에서 동일한 클라이언트의 조각화된 및 조각화되지 않은 UDP 패킷은 포트 정보를 포함하지 않는 동일한 백엔드로 전달됩니다.

대상 인스턴스를 백엔드로 사용

네트워크 부하 분산기의 백엔드로 대상 인스턴스를 사용 중이며 조각화된 UDP 패킷이 필요한 경우 IP 주소당 UDP 또는 L3_DEFAULT 전달 규칙을 하나만 사용하고 모든 포트에서 트래픽을 허용하도록 전달 규칙을 구성합니다. 이렇게 하면 대상 포트가 동일하지 않은 경우에도 모든 프래그먼트가 동일한 전달 규칙으로 이동합니다. 모든 포트를 구성하려면 gcloud를 사용하여 --ports=ALL을 설정하거나 API를 사용하여 allPortsTrue 설정합니다.

장애 조치

네트워크 부하 분산기를 구성하여 기본 백엔드 인스턴스 그룹의 가상 머신(VM) 인스턴스 간에 연결을 배포한 다음 필요한 경우 장애 조치 백엔드 인스턴스 그룹을 사용하도록 전환할 수 있습니다. 장애 조치는 가용성을 높이는 또 다른 방법을 제공하는 동시에 기본 백엔드 VM이 비정상인 경우 워크로드 관리 방법에 대한 더 많은 통제권을 제공합니다.

기본적으로 백엔드를 네트워크 부하 분산기의 백엔드 서비스에 추가하면 이 백엔드가 기본 백엔드가 됩니다. 백엔드를 부하 분산기의 백엔드 서비스에 추가하거나 나중에 백엔드 서비스를 편집하여 백엔드를 장애 조치 백엔드로 지정할 수 있습니다.

장애 조치 작동 방식에 대한 자세한 내용은 네트워크 부하 분산의 장애 조치 개요를 참조하세요.

제한사항

  • 네트워크 엔드포인트 그룹(NEG)은 네트워크 부하 분산기의 백엔드로 지원되지 않습니다.
  • 백엔드 서비스 기반 네트워크 부하 분산기는 Google Kubernetes Engine에서 지원되지 않습니다.
  • Google Cloud Console을 사용하면 다음 태스크를 수행할 수 없습니다.

    • 전달 규칙에 L3_DEFAULT 프로토콜이 사용되는 네트워크 부하 분산기를 만들거나 수정합니다.
    • 백엔드 서비스 프로토콜이 UNSPECIFIED로 설정된 네트워크 부하 분산기를 만들거나 수정합니다.
    • 연결 추적 정책을 구성하는 네트워크 부하 분산기를 만들거나 수정합니다.
    • 전달 규칙의 소스 IP 기반 트래픽 조정을 만들거나 수정합니다.

    대신 Google Cloud CLI 또는 REST API를 사용하세요.

  • 네트워크 부하 분산기는 VPC 네트워크 피어링을 지원하지 않습니다.

다음 단계