내부 패스 스루 네트워크 부하 분��기 개요

내부 패스 스루 네트워크 부하 분산기는 Andromeda 네트워크 가상화 스택에서 빌드된 리전별 부하 분산기입니다.

내부 패스 스루 네트워크 부하 분산기는 Virtual Private Cloud(VPC) 네트워크의 동일한 리전에 있는 내부 가상 머신(VM) 인스턴스에 트래픽을 분산합니다. 이 부하 분산을 사용하면 동일한 VPC 네트워크의 시스템 또는 VPC 네트워크에 연결된 시스템에만 액세스할 수 있는 내부 IP 주소를 기반으로 서비스를 실행하고 확장할 수 있습니다.

다음과 같은 경우 내부 패스 스루 네트워크 부하 분산기를 사용합니다.

TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH, GRE 프로토콜에 대해 고성능 패스스루 Layer 4 부하 분산기가 필요합니다.
TLS(SSL)를 통해 트래픽을 제공하는 경우 부하 분산기 대신 백엔드에서 SSL 트래픽을 종료할 수 있습니다. 내부 패스 스루 네트워크 부하 분산기는 SSL 트래픽을 종료할 수 없습니다.
프록시 해제된 상태의 원래 패킷을 전달해야 합니다. 예를 들어 클라이언트 소스 IP 주소를 보존해야 하는 경우가 이에 해당합니다.
패스스루 부하 분산기를 사용하는 기존 설정이 있으며 이 설정을 변경하지 않고 마이그레이션하려 합니다.

내부 패스 스루 네트워크 부하 분산기는 많은 사용 사례를 다룹니다. 몇 가지 개략적인 예시는 패스 스루 네트워크 부하 분산기 개요를 참조하세요.

내부 패스 스루 네트워크 부하 분산기 작동 방식

내부 패스 스루 네트워크 부하 분산기에는 프런트엔드(전달 규칙) 및 백엔드(백엔드 서비스)가 있습니다. 인스턴스 그룹 또는 GCE_VM_IP 영역 NEG를 백엔드 서비스에서 백엔드로 사용할 수 있습니다. 이 예시에서는 인스턴스 그룹 백엔드를 보여줍니다.

프록시 부하 분산기와 달리 내부 패스 스루 네트워크 부하 분산기는 클라이언트의 연결을 종료하지 않고 백엔드에서 새 연결을 엽니다. 대신 내부 네트워크 부하 분산기는 중단 없이 연결을 클라이언트에서 정상 백엔드로 직접 라우팅합니다. 정상 백엔드 VM의 응답은 부하 분산기를 통하지 않고 클라이언트에 직접 전달됩니다. TCP 응답에는 직접 서버 반환이 사용됩니다. 자세한 내용은 TCP 및 UDP 요청과 반환 패킷을 참조하세요.

부하 분산기는 상태 확인 프로브를 사용하여 백엔드 상태를 모니터링합니다. 자세한 내용은 상태 확인 섹션을 참조하세요.

Google Cloud Linux 게스트 환경, Windows 게스트 환경 또는 그에 해당하는 프로세스가 부하 분산기의 IP 주소를 사용하여 각 백엔드 VM을 구성합니다. Google Cloud 이미지에서 만든 VM의 경우 게스트 에이전트(이전의 Windows 게스트 환경 또는 Linux 게스트 환경)는 부하 분산기의 IP 주소에 대한 로컬 경로를 설치합니다. Container-Optimized OS를 기반으로 하는 Google Kubernetes Engine 인스턴스는 대신 iptables를 사용하여 이를 구현합니다.

Google Cloud 가상 네트워킹은 트래픽 전달을 관리하고, 필요에 따라 확장됩니다.

프로토콜, 스키마, 범위

각 내부 패스 스루 네트워크 부하 분산기는 다음을 지원합니다.

부하 분산 스키마 INTERNAL 및 지원되는 프로토콜이 있는 하나의 백엔드 서비스. 자세한 내용은 백엔드 서비스를 참조하세요.
다음 중 하나로 지정된 백엔드 VM:
- 하나의 리전 및 VPC 네트워크에 있는 관리형 및 비관리형 인스턴스 그룹
- 동일한 리전 및 VPC 네트워크에 위치한 GCE_VM_IP 유형의 엔드포인트가 있는 백엔드 영역 네트워크 엔드포인트 그룹(NEG). NEG의 엔드포인트는 NEG에서 사용하는 것과 동일한 서브넷 및 영역의 기본 내부 IP 주소여야 합니다.
인스턴스 그룹 백엔드를 사용할 때 IPv4 및 IPv6 트래픽 지원. GCE_VM_IP 엔드포인트가 있는 영역 네트워크 엔드포인트 그룹(NEG)은 IPv4 트래픽만 지원합니다.
각각 백엔드 서비스 프로토콜과 일치하여 TCP, UDP, 또는 L3_DEFAULT 프로토콜을 사용하는 하나 이상의 전달 규칙
자체 고유 IP 주소를 포함하는 전달 규칙 또는 공통 IP 주소를 공유하는 여러 전달 규칙
최대 5개 포트 또는 모든 포트를 포함하는 각 전달 규칙
전역 액세스가 사용 설정된 경우 모든 리전에 있는 클라이언트
전역 액세스가 사용 중지된 경우 부하 분산기와 동일한 리전에 있는 클라이언트

내부 패스 스루 네트워크 부하 분산기는 다음을 지원하지 않습니다.

여러 리전의 백엔드 VM
외부 부하 분산기로 사용하지 않는 한 인터넷에서 시작되는 트래픽의 분산
파편화된 헤더가 있는 IPv6 패킷

클라이언트 액세스

기본적으로 부하 분산기는 부하 분산기와 동일한 리전에 있는 클라이언트만 지원합니다. 클라이언트는 부하 분산기와 같은 네트워크 또는 VPC 네트워크 피어링을 사용하여 연결된 VPC 네트워크에 있을 수 있습니다. 모든 리전의 클라이언트가 내부 패스 스루 네트워크 부하 분산기에 액세스하도록 허용하려면 전역 액세스를 사용 설정하면 됩니다.

전역 액세스를 사용하는 내부 패스 스루 네트워크 부하 분산기(확대하려면 클릭)

다음 표에는 클라이언트 액세스가 요약되어 있습니다.

중지된 전역 액세스	사용 설정된 전역 액세스
클라이언트는 부하 분산기와 동일한 리전에 있어야 합니다. 또한 부하 분산기와 동일한 VPC 네트워크에 있거나 VPC 네트워크 피어링을 사용하여 부하 분산기의 VPC 네트워크에 연결된 VPC 네트워크에 있어야 합니다.	클라이언트는 어느 리전에나 있을 수 있습니다. 부하 분산기와 동일한 VPC 네트워크에 있거나 VPC 네트워크 피어링을 사용하여 부하 분산기의 VPC 네트워크에 연결된 VPC 네트워크에 있어야 합니다.
온프레미스 클라이언트는 Cloud VPN 터널이나 VLAN 연결을 통해 부하 분산기에 액세스할 수 있습니다. 이러한 터널 또는 연결은 부하 분산기와 동일한 리전에 있어야 합니다.	온프레미스 클라이언트는 Cloud VPN 터널이나 VLAN 연결을 통해 부하 분산기에 액세스할 수 있습니다. 이러한 터널 또는 연결은 어느 리전에나 있을 수 있습니다.

요청 및 반환 패킷의 IP 주소

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

소스: 클라이언트의 별칭 IPv4 범위 중 하나에서 가져온 클라이언트의 내부 IPv4, IPv6 또는 IPv4 주소입니다.
대상: 부하 분산기의 전달 규칙의 IP 주소입니다. 전달 규칙은 단일 내부 IPv4 주소 또는 내부 IPv6 범위를 사용합니다.

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

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

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

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

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

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

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

아키텍처

여러 개의 백엔드가 있는 내부 패스 스루 네트워크 부하 분산기는 모든 백엔드에 연결을 분산합니다. 분산 방법과 구성 옵션에 대한 자세한 내용은 트래픽 분산을 참조하세요.

인스턴스 그룹 또는 영역 NEG는 내부 패스 스루 네트워크 부하 분산기의 백엔드로 사용할 수 있지만 이 둘의 조합은 사용할 수 없습니다.

인스턴스 그룹을 선택할 경우 비관리형 인스턴스 그룹, 영역 관리형 인스턴스 그룹, 리전 관리형 인스턴스 그룹, 인스턴스 그룹 유형의 조합을 사용할 수 있습니다.
영역 NEG를 선택하는 경우 GCE_VM_IP 영역 NEG를 사용해야 합니다.

고가용성은 단일 영역에 종속되지 않는 내부 부하 분산기를 설계하는 방법을 설명합니다.

내부 패스 스루 네트워크 부하 분산기에 백엔드 VM으로 참여하는 인스턴스는 적절한 Linux 또는 Windows 게스트 환경이나 기타 동일한 기능을 제공하는 프로세스를 실행해야 합니다. 부하 분산기의 내부 IP 주소로 전송되는 트래픽을 수락하기 위해 로컬 경로를 생성할 수 있도록 인스턴스 메타데이터를 읽기 위해서는 이 게스트 환경이 메타데이터 서버(metadata.google.internal, 169.254.169.254)에 연락할 수 있어야 합니다.

이 다이어그램은 두 개의 개별 인스턴스 그룹에 위치한 VM 간의 트래픽 분산을 보여줍니다. 클라이언트 인스턴스에서 부하 분산기의 IP 주소(10.10.10.9)로 전송되는 트래픽이 한쪽 인스턴스 그룹에서 백엔드 VM 간에 분산됩니다. 서빙 백엔드 VM에서 전송된 응답은 클라이언트 VM에 직접 전달됩니다.

커스텀 모드 또는 자동 모드 VPC 네트워크에서 내부 패스 스루 네트워크 부하 분산기를 사용할 수 있습니다. 기존 레거시 네트워크에서 내부 패스 스루 네트워크 부하 분산기를 만들 수도 있습니다.

내부 패스 스루 네트워크 부하 분산기는 다음 Google Cloud 구성요소로 구성됩니다.

구성요소	용도	요구사항
내부 IP 주소	부하 분산기의 주소입니다.	내부 IP 주소는 내부 전달 규칙과 동일한 서브넷에 있어야 합니다. 서브넷은 백엔드 서비스와 동일한 리전 및 VPC 네트워크에 있어야 합니다.
내부 전달 규칙	내부 IP 주소와 조합된 내부 전달 규칙이 부하 분산기의 프런트엔드입니다. 부하 분산기가 수락하는 프로토콜과 포트를 정의하며 트래픽을 리전 내부 백엔드 서비스로 보냅니다.	내부 패스 스루 네트워크 부하 분산기의 전달 규칙은 다음과 같아야 합니다. • `load-balancing-scheme`으로 `INTERNAL`을 사용합니다. • `ip-protocol`로 백엔드 서비스의 `protocol`과 일치하는 `TCP` 또는 `UDP`를 사용합니다. • 백엔드 서비스와 동일한 VPC 네트워크 및 리전에 있는 `subnet`을 참조합니다.
리전 내부 백엔드 서비스	리전 내부 백엔드 서비스는 백엔드와 통신하는 데 사용되는 프로토콜을 정의하며 상태 확인을 지정합니다. 백엔드는 비관리형 인스턴스 그룹, 관리형 영역 인스턴스 그룹, 관리형 리전 인스턴스 그룹, `GCE_VM_IP` 엔드포인트가 있는 영역 NEG일 수 있습니다.	백엔드 서비스는 다음 조건을 충족해야 합니다. • `load-balancing-scheme`으로 `INTERNAL`을 포함합니다. • `protocol`로 전달 규칙의 `ip-protocol`과 일치하는 `TCP` 또는 `UDP`를 사용합니다. • 연결된 상태 확인을 포함합니다. • 연결된 리전을 포함합니다. 전달 규칙 및 모든 백엔드는 백엔드 서비스와 동일한 리전에 있어야 합니다. • 단일 VPC 네트워크와 연결됩니다. 지정되지 않은 경우 각 백엔드 VM의 기본 네트워크 인터페이스(`nic0`)에 사용되는 네트워크를 기반으로 네트워크가 유추됩니다. 백엔드 서비스가 특정 서브넷에 연결되지 않아도 전달 규칙의 서브넷은 백엔드 서비스와 동일한 VPC 네트워크에 있어야 합니다.
상태 점검	모든 백엔드 서비스에는 연관된 상태 확인이 있어야 합니다. 상태 확인은 Google Cloud에서 관리되는 백엔드가 트래픽을 수신할 수 있는지를 판단할 때 기준이 되는 매개변수를 정의합니다. 정상 백엔드 VM만 클라이언트 VM에서 부하 분산기의 IP 주소로 전송되는 트래픽을 수신합니다.	전달 규칙 및 백엔드 서비스가 `TCP` 또는 `UDP`를 사용할 수 있더라도 Google Cloud에는 UDP 트래픽에 대한 상태 확인이 없습니다. 자세한 내용은 상태 확인 및 UDP 트래픽을 참조하세요.

내부 패스 스루 네트워크 부하 분산기는 다음을 지원하지 않습니다.

여러 리전의 백엔드 VM
외부 부하 분산기로 사용하지 않는 한 인터넷에서 시작되는 트래픽의 분산
파편화된 헤더가 있는 IPv6 패킷

내부 IP 주소

내부 패스 스루 네트워크 부하 분산기는 IPv4 전용(단일 스택) 서브넷과 IPv4 및 IPv6(이중 스택) 서브넷을 지원합니다. 자세한 내용은 서브넷 유형을 참조하세요.

내부 패스 스루 네트워크 부하 분산기에는 전달 규칙이 최소 한 개 이상 필요합니다. 전달 규칙은 내부 IP 주소를 참조합니다.

IPv4 트래픽의 경우 전달 규칙은 기본 IPv4 서브넷 범위에서 IPv4 주소를 참조합니다.
IPv6 트래픽의 경우 전달 규칙은 서브넷의 /64 내부 IPv6 주소 범위에서 내부 IPv6 주소의 /96 범위를 참조합니다. 서브넷은 내부 IPv6 주소 범위(ipv6-access-type이 INTERNAL로 설정됨)가 있는 이중 스택 서브넷이어야 합니다.

방화벽 구성

내부 패스 스루 네트워크 부하 분산기에는 계층식 방화벽 정책과 VPC 방화벽 규칙에 대한 다음 구성이 필요합니다.

IPv4 또는 IPv6 상태 점검 소스 범위에서 인그레스를 허용합니다.
클라이언트 IPv4 또는 IPv6 주소 소스 범위에서 인그레스를 허용합니다.

자세한 내용은 방화벽 규칙 구성을 참조하세요.

전달 규칙

전달 규칙은 프로토콜과 ��하 분산기가 트래픽을 수락하는 포트를 지정합니다. 내부 패스 스루 네트워크 부하 분산기는 프록시가 아니기 때문에 동일한 프로토콜 및 포트에 있는 백엔드로 트래픽을 전달합니다.

내부 패스 스루 네트워크 부하 분산기에는 내부 전달 규칙이 한 개 이상 필요합니다. 동일한 부하 분산기에 대해 여러 개의 전달 규칙을 정의할 수 있습니다.

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

전달 규칙은 부하 분산기의 백엔드 구성요소와 동일한 VPC 네트워크 및 리전에 있는 특정 서브넷을 참조해야 합니다. 이 요구사항은 다음과 같은 의미를 갖습니다.

전달 규칙에 대해 지정하는 서브넷이 백엔드 VM에 사용되는 서브넷과 동일할 필요가 없지만, 서브넷이 전달 규칙과 동일한 리전에 있어야 합니다.
IPv4 트래픽의 경우 내부 전달 규칙은 선택한 서브넷의 기본 IPv4 주소 범위에 있는 리전별 내부 IPv4 주소를 참조합니다. 이 IPv4 주소는 자동으로 선택하거나 고정(예약된) IPv4 주소를 사용할 수 있습니다.
IPv6 트래픽의 경우 전달 규칙은 서브넷의 내부 IPv6 주소 범위에서 IPv6 주소의 /96 범위를 참조합니다. 서브넷은 ipv6-access-type이 INTERNAL로 설정된 이중 스택 서브넷이어야 합니다. /96 IPv6 주소 범위는 자동으로 할당됩니다. 또는 예약된 내부 IP 주소를 사용할 수 있습니다.

전달 규칙 프로토콜

내부 패스 스루 네트워크 부하 분산기는 각 전달 규칙에 대해 TCP, UDP, L3_DEFAULT IPv4 프로토콜 옵션을 지원합니다.

내부 패스 스루 네트워크 부하 분산기는 각 전달 규칙에 대해 TCP 또는 UDP IPv6 프로토콜 옵션을 지원합니다.

L3_DEFAULT 옵션을 사용하면 TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH, GRE 프로토콜의 부하를 분산할 수 있습니다.

TCP 및 UDP 이외의 프로토콜을 지원하는 것 외에도 L3_DEFAULT 옵션을 사용하면 단일 전달 규칙이 여러 프로토콜의 트래픽을 동시에 전달할 수 있습니다. 예를 들어 HTTP 요청을 수행하는 것 외에도 부하 분산기 IP 주소를 핑할 수 있습니다.

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

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

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

부하 분산되는 트래픽	전달 규칙 프로토콜	백엔드 서비스 프로토콜
TCP(IPv4 또는 IPv6)	`TCP`	`TCP or UNSPECIFIED`
UDP(IPv4 또는 IPv6)	`UDP`	`UDP or UNSPECIFIED`
TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH, GRE	`L3_DEFAULT`	`UNSPECIFIED`

전달 규칙 및 전역 액세스

내부 패스 스루 네트워크 부하 분산기의 전달 규칙은 전역 액세스가 사용 설정되어 있더라도 리전별로 적용됩니다. 전역 액세스를 사용 설정한 ��는 리전 내부 전달 규칙의 allowGlobalAccess 플래그가 true로 설정됩니다.

전달 규칙 및 포트 사양

내부 전달 규칙을 만들 때 다음 포트 사양 중 하나를 선택해야 합니다.

숫자로 1~5개의 포트 지정
ALL을 지정하여 모든 포트의 트래픽 전달

모든 TCP 포트 또는 모든 UDP 포트를 지원하는 내부 전달 규칙을 사용하면 백엔드 VM이 각각의 자체 고유 포트에서 여러 애플리케이션을 실행할 수 있습니다. 특정 포트로 전송된 트래픽은 해당 애플리케이션에 전달되고, 모든 애플리케이션은 동일한 IP 주소를 사용합니다.

6개 이상의 특정 포트에서 트래픽을 전달해야 할 경우 방화벽 규칙을 전달 규칙과 조합합니다. 전달 규칙을 만들 때는 모든 포트를 지정하고, 원하는 포트로만 트래픽을 허용하는 인그레스 allow 방화벽 규칙을 만듭니다. 백엔드 VM에 방화벽 규칙을 적용합니다.

전달 규칙을 만든 후에는 이를 수정할 수 없습니다. 내부 전달 규칙의 특정 포트 또는 내부 IP 주소를 변경해야 할 경우에는 이를 삭제하고 다시 만들어야 합니다.

단일 백엔드 서비스에 대한 여러 전달 규칙

모두 동일한 내부 백엔드 서비스를 참조하는 여러 내부 전달 규칙을 구성할 수 있습니다. 내부 패스 스루 네트워크 부하 분산기에는 내부 전달 규칙이 한 개 이상 필요합니다.

동일한 백엔드 서비스에 대해 여러 전달 규칙을 구성하면 다음을 수행할 수 있습니다.

부하 분산기에 여러 IP 주소를 할당합니다. 각각 고유한 IP 주소를 사용하는 여러 전달 규칙을 만들 수 있습니다. 각 전달 규칙은 모든 포트 또는 최대 5개까지 포트 집합을 지정할 수 있습니다.
동일한 IP 주소를 사용하여 특정 포트 집합을 부하 분산기에 할당합니다. 동일한 IP 주소를 공유하는 여러 전달 규칙을 만들 수 있습니다. 여기서 각 전달 규칙에는 최대 5개까지 특정 포트 집합이 사용됩니다. 이것은 모든 포트를 지정하는 단일 전달 규칙을 구성하는 것의 대안 방식입니다.

공통 내부 IP 주소를 공유하는 2개 이상의 내부 전달 규칙과 관련된 시나리오에 대해 자세히 알아보려면 동일한 IP 주소를 사용하는 여러 전달 규칙을 참조하세요.

여러 전달 규칙을 사용할 경우 백엔드 VM에서 실행 중인 소프트웨어가 모든 전달 규칙 IP 주소 또는 모든 주소(0.0.0.0/0 IPv4 또는::/0 IPv6의 경우)에 바인딩되도록 구성해야 합니다. 부하 분산기를 통해 전달되는 패킷의 대상 IP 주소는 해당 내부 전달 규칙과 연결된 내부 IP 주소입니다. 자세한 내용은 TCP 및 UDP 요청과 반환 패킷을 참조하세요.

백엔드 서비스

각 내부 패스 스루 네트워크 부하 분산기에는 백엔드 매개변수 및 동작을 정의하는 하나의 리전별 내부 백엔드 서비스가 포함됩니다. 백엔드 서비스 이름은 Google Cloud 콘솔에 표시된 내부 패스 스루 네트워크 부하 분산기 이름입니다.

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

프로토콜. 백엔드 서비스는 IPv4 및 IPv6 트래픽을 지원합니다. 프로토콜에 포트 개념(예: TCP 또는 UDP)이 포함된 경우 백엔드 서비스는 트래픽이 전송된 동일한 목적지 포트에 있는 백엔드 VM으로 패킷을 전달합니다.

백엔드 서비스는 TCP, UDP, UNSPECIFIED IPv4 프로토콜 옵션을 지원합니다.

백엔드 서비스는 TCP 또는 UDP IPv6 프로토콜 옵션을 지원합니다. 백엔드 서비스 프로토콜은 전달 규칙 프로토콜과 조정되어야 합니다.

전달 규칙과 백엔드 서비스 프로토콜의 가능한 조합이 있는 표는 전달 규칙 프로토콜 사양을 참조하세요.
트래픽 분산. 백엔드 서비스는 구성 가능한 세션 어피니티에 따라 트래픽이 분산되게 합니다.
상태 점검. 백엔드 서비스는 연결된 상태 확인을 포함해야 합니다.

각 백엔드 서비스는 단일 리전에서 작동하며 단일 VPC 네트워크의 백엔드 VM에 대해 트래픽을 분산합니다.

한 가지 유형의 백엔드, 하나의 리전. 백엔드는 백엔드 서비스 및 전달 규칙과 동일한 리전에 있는 인스턴스 그룹 또는 GCE_VM_IP 엔드포인트가 포함된 영역 NEG입니다. 인스턴스 그룹 백엔드는 비관리형 인스턴스 그룹, 영역 관리형 인스턴스 그룹, 리전 관리형 인스턴스 그룹일 수 있습니다. 영역 NEG 백엔드는 GCE_VM_IP 엔드포인트를 사용해야 합니다.
하나의 VPC 네트워크. 해당 인스턴스 그룹 또는 NEG가 백엔드 서비스에 아직 연결되지 않았어도 각 인스턴스 그룹 또는 NEG 백엔드에는 연관된 VPC 네트워크가 있습니다. 네트워크가 각 백엔드 유형과 연결되는 방식에 대한 자세한 내용은 인스턴스 그룹 백엔드 및 네트워크 인터페이스 및 영역 NEG 백엔드 및 네트워크 인터페이스를 참조하세요. 또한 백엔드 서비스 리소스 자체는 명시적 또는 암시적으로 정의될 수 있는 연결된 VPC 네트워크를 포함할 수 있습니다. 백엔드 서비스 네트워크에 대한 자세한 내용은 백엔드 서비스 네트워크 사양 및 백엔드 서비스 네트워크 규칙을 참조하세요.

인스턴스 그룹 백엔드 및 네트워크 인터페이스

인스턴스 그룹과 연결된 VPC 네트워크는 모든 구성원 VM의 nic0 네트워크 인터페이스에 사용되는 VPC 네트워크입니다.

관리형 인스턴스 그룹(MIG)의 경우 인스턴스 그룹에 대한 VPC 네트워크가 인스턴스 템플릿에 정의됩니다.
비관리형 인스턴스 그룹의 경우 인스턴스 그룹의 VPC 네트워크는 사용자가 비관리형 인스턴스 그룹에 추가하는 첫 번째 VM 인스턴스의 nic0 네트워크 인터페이스에 사용되는 VPC 네트워크로 정의됩니다.

지정된 관리형 또는 비관리형 인스턴스 그룹 내에서 모든 VM 인스턴스에는 해당 nic0 네트워크 인터페이스가 동일한 VPC 네트워크에 있어야 합니다. 각 구성원 VM에 추가적인 네트워크 인터페이스(nic1~nic7)가 포함될 수 있지만 각 네트워크 인터페이스가 다른 VPC 네트워크에 연결되어야 합니다. 이러한 네트워크는 또한 인스턴스 그룹과 연결된 VPC 네트워크와 달라야 합니다.

영역 NEG 백엔드 및 네트워크 인터페이스

GCE_VM_IP 엔드포인트와 함께 새로운 영역별 NEG를 만들 때는 NEG에 엔드포인트를 추가하기 전 NEG를 VPC 네트워크의 서브네트워크와 명시적으로 연결해야 합니다. NEG를 만든 후에는 서브넷 또는 VPC 네트워크를 변경할 수 없습니다.

지정된 NEG 내에서 각 GCE_VM_IP 엔드포인트는 실제로 네트워크 인터페이스를 나타냅니다. 네트워크 인터페이스가 NEG와 연결된 서브네트워크에 있어야 합니다. Compute Engine 인스턴스 관점에서 네트워크 인터페이스는 nic0부터 nic7까지 모든 식별자를 사용할 수 있습니다. NEG의 엔드포인트가 된다는 관점에서 인터페이스는 기본 IPv4 주소를 사용하여 식별됩니다.

NEG에 GCE_VM_IP 엔드포인트를 추가하는 방법은 두 가지입니다.

엔드포인트를 추가할 때 IP 주소 없이 VM 이름만 지정할 경우 Google Cloud에서는 해당 VM에 NEG와 연결된 서브네트워크의 네트워크 인터페이스가 있어야 합니다. Google Cloud가 엔드포인트에 대해 선택하는 IP 주소는 NEG와 연결된 서브네트워크에 있는 VM 네트워크 인터페이스의 기본 내부 IPv4 주소입니다.
엔드포인트를 추가할 때 VM 이름과 IP 주소를 모두 지정할 경우에는 제공하는 IP 주소가 VM의 네트워크 인터페이스 중 하나에 대한 기본 내부 IPv4 주소여야 합니다. 네트워크 인터페이스가 NEG와 연결된 서브네트워크에 있어야 합니다. NEG와 연결된 서브네트워크에 있는 단일 네트워크 인터페이스만 가능하므로 IP 주소 지정이 중복됩니다.

백엔드 서비스 네트워크 사양

백엔드 서비스를 만�� 때 --network 플래그를 사용하여 백엔드 서비스에 VPC 네트워크를 명시적으로 연결할 수 있습니다. 백엔드 서비스 네트워크 규칙은 즉시 적용됩니다.

백엔드 서비스를 만들 때 --network 플래그를 생략하면 Google Cloud가 다음 적격성 평가 이벤트 중 하나를 사용하여 백엔드 서비스의 연결된 VPC 네트워크를 암시적으로 설정합니다. 설정한 후에는 백엔드 서비스의 연결된 VPC 네트워크를 변경할 수 없습니다.

백엔드 서비스에 아직 연결된 백엔드가 없고 백엔드 서비스를 참조하도록 첫 번째 다음 규칙을 구성하면 Google Cloud가 백엔드 서비스의 연결된 VPC 네트워크를 이 전달 규칙에 사용된 서브넷이 포함된 VPC 네트워크로 설정합니다.
백엔드 서비스에 아직 이를 참조하는 전달 규칙이 없고 첫 번째 인스턴스 그룹 백엔드를 백엔드 서비스에 추가할 경우 Google Cloud가 백엔드 서비스의 VPC 네트워크를 이 첫 번째 인스턴스 그룹 백엔드와 연결된 VPC 네트워크로 설정합니다. 즉, 백엔드 서비스의 연결된 VPC 네트워크가 첫 번째 인스턴스 그룹 백엔드에 있는 각 VM의 nic0 네트워크 인터페이스에 사용되는 네트워크입니다.
백엔드 서비스에 아직 이를 참조하는 전달 규칙이 없고 GCE_VM_IP 엔드포인트를 사용하여 첫 번째 영역 NEG 백엔드를 백엔드 서비스에 추가하면 Google Cloud가 백엔드 서비스의 VPC 네트워크를 첫 번째 NEG 백엔드와 연결된 VPC 네트워크로 설정합니다.

백엔드 서비스의 VPC 네트워크가 적격성 평가 이벤트로 설정된 다음에는 추가적인 전달 규칙, 백엔드 인스턴스 그룹, 백엔드 영역 NEG가 백엔드 서비스 네트워크 규칙을 따라야 합니다.

백엔드 서비스 네트워크 규칙

다음 규칙은 백엔드 서비스가 특정 VPC 네트워크와 연결된 이후에 적용됩니다.

백엔드 서비스를 참조하도록 전달 규칙을 구성할 때는 전달 규칙이 백엔드 서비스의 VPC 네트워크 서브넷을 사용해야 합니다. 네트워크가 VPC 네트워크 피어링을 사용하여 연결되어 있더라도 전달 규칙 및 백엔드 서비스는 서로 다른 VPC 네트워크를 사용할 수 없습니다.
인스턴스 그룹 백엔드를 추가할 때는 다음 중 하나가 충족되어야 합니다.
- 인스턴스 그룹과 연결된 VPC 네트워크(인스턴스 그룹에서 각 VM의 nic0 네트워크 인터페이스에 사용되는 VPC 네트워크)는 백엔드 서비스의 연결된 VPC 네트워크와 일치해야 합니다.
- 각 백엔드 VM은 백엔드 서비스와 연결된 VPC 네트워크에서 nic0 이외의 인터페이스(nic1~nic7)를 포함해야 합니다.
GCE_VM_IP 엔드포인트로 영역 NEG 백엔드를 추가할 때 NEG와 연결된 VPC 네트워크는 백엔드 서비스와 연결된 VPC 네트워크와 일치해야 합니다.

백엔드 하위 설정

백엔드 하위 설정은 트래픽이 분산되는 백엔드 수를 제한하여 성능을 개선하는 선택적 기능입니다.

단일 부하 분산기에서 250개가 넘는 백엔드 VM을 지원해야 하는 경우에만 하위 설정을 사용 설정해야 합니다. 자세한 내용은 내부 패스 스루 네트워크 부하 분산기의 백엔드 하위 설정을 참조하세요.

상태 점검

부하 분산기의 백엔드 서비스는 전역 또는 리전 상태 확인과 연결되어야 합니다. VPC 네트워크 외부의 특수 경로는 상태 확인 시스템과 백엔드 사이의 통신을 쉽게 도와줍니다.

기존 상태 확인을 사용하거나 새로운 상태 확인을 정의할 수 있습니다. 트래픽 분산에 설명된 것처럼 내부 패스 스루 네트워크 부하 분산기는 상태 점검 상태를 사용하여 새 연결 경로 지정 방법을 결정합니다.

다음 상태 확인 프로토콜을 사용할 수 있습니다. 상태 확인의 프로토콜은 부하 분산기의 프로토콜과 일치할 필요가 없습니다.

HTTP, HTTPS, HTTP/2. 백엔드 VM이 HTTP, HTTPS, HTTP/2를 사용하여 트래픽을 처리하는 경우에는 해당 프로토콜과 일치하는 상태 확인을 사용하는 것이 가장 ��습니다. HTTP 기반 상태 확인이 해당 프로토콜에 적합한 옵션을 제공하기 때문입니다. 내부 패스 스루 네트워크 부하 분산기를 통해 HTTP 유형 트래픽을 처리하면 부하 분산기의 프로토콜이 TCP라는 의미입니다.
SSL 또는 TCP: 백엔드 VM이 HTTP 유형 트래픽을 처리하지 않는 경우에는 SSL 또는 TCP 상태 확인을 사용해야 합니다.

Google Cloud는 사용자가 만드는 상태 점검 유형에 관계없이 내부 패스 스루 네트워크 부하 분산기 전달 규칙의 IP 주소, 부하 분산기의 백엔드 서비스에서 선택한 VPC 네트워크의 네트워크 인터페이스로 상태 점검 프로브를 전송합니다. 이것은 부하 분산 트래픽의 전달 방법을 시뮬레이션합니다. 백엔드 VM에서 실행되는 소프트웨어는 각 전달 규칙의 IP 주소로 전송되는 부하 분산기 트래픽 및 상태 확인 프로브에 응답해야 합니다. 소프트웨어가 0.0.0.0:<port>로 리슨하고 네트워크 인터페이스에 할당된 특정 IP 주소는 리슨하지 않아야 합니다. 자세한 내용은 프로브 패킷 대상을 참조하세요.

상태 확인 및 UDP 트래픽

Google Cloud는 UDP 프로토콜을 사용하는 상태 확인을 제공하지 않습니다. UDP 트래픽에 내부 패스 스루 네트워크 부하 분산기를 사용하는 경우 백엔드 VM에서 TCP 기반 서비스를 실행하여 상태 점검 정보를 제공해야 합니다.

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

고가용성 아키텍처

내부 패스 스루 네트워크 부하 분산기는 고가용성을 우선으로 설계되었습니다. 단일 기기 또는 VM 인스턴스에 의존하는 메커니즘이 아니기 때문에 부하 분산기의 가용성을 높일 수 있는 특별 단계는 존재하지 않습니다.

백엔드 VM 인스턴스가 여러 영역에 배포되었는지 확인하려면 다음 배포 권장사항을 따르세요.

인스턴스 템플릿을 사용하여 소프트웨어를 배포할 수 있는 경우 리전 관리형 인스턴스 그룹을 사용합니다. 리전 관리형 인스턴스 그룹은 여러 영역 간에 트래픽을 자동으로 분산시킴으로써 특정 영역에서 발생할 수 있는 문제를 방지하는 최상의 방법입니다.
영역 관리형 인스턴스 그룹 또는 비관리형 인스턴스 그룹을 사용하는 경우 동일한 백엔드 서비스에 대해 동일한 리전의 서로 다른 영역에 있는 여러 인스턴스 그룹을 사용합니다. 여러 영역을 사용하면 특정 영역에서 잠재적 문제를 방지할 수 있습니다.

공유 VPC 아키텍처

다음 표에는 공유 VPC 네트워크에 사용되는 내부 패스 스루 네트워크 부하 분산기의 구성요소 요구사항이 요약되어 있습니다. 예시를 보려면 공유 VPC 프로비저닝 페이지에서 내부 패스 스루 네트워크 부하 분산기 만들기를 참조하세요.

IP 주소	전달 규칙	백엔드 구성요소
내부 IP 주소는 백엔드 VM과 동일한 프로젝트에 정의되어야 합니다. 공유 VPC 네트워크에서 부하 분산기를 사용하려면 Google Cloud 내부 IP 주소가 반드시 백엔드 VM이 있는 서비스 프로젝트와 동일한 서비스 프로젝트에 정의되어야 하고 또한 호스트 프로젝트에 있는 원하는 공유 VPC 네트워크의 서브넷을 참조해야 합니다. 주소 자체는 참조된 서브넷의 기본 IP 범위에서 가져옵니다. 서비스 프로젝트에 내부 IP 주소를 만들고 IP 주소 서브넷이 서비스 프로젝트의 VPC 네트워크에 있는 경우, 내부 패스 스루 네트워크 부하 분산기는 서비스 프로젝트에 대해 로컬입니다. 모든 공유 VPC 호스트 프로젝트에 대해서는 로컬이 아닙니다.	내부 전달 규칙은 백엔드 VM과 동일한 프로젝트에 정의되어야 합니다. 공유 VPC 네트워크에서 부하 분산기를 사용하려면 내부 전달 규칙이 반드시 백엔드 VM이 있는 서비스 프로젝트와 동일한 서비스 프로젝트에 정의되어야 하고 또한 연결된 내부 IP 주소가 참조하는 것과 동일한 서브넷(공유 VPC 네트워크의)을 참조해야 합니다. 서비스 프로젝트에 내부 전달 규칙을 만들고 전달 규칙의 서브넷이 서비스 프로젝트의 VPC 네트워크에 있는 경우, 내부 패스 스루 네트워크 부하 분산기는 서비스 프로젝트에 대해 로컬입니다. 모든 공유 VPC 호스트 프로젝트에 대해서는 로컬이 아닙니다.	공유 VPC 시나리오에서 백엔드 VM은 서비스 프로젝트에 있습니다. 바로 이 서비스 프로젝트에 리전 내부 백엔드 서비스와 상태 확인이 정의되어야 합니다.

트래픽 분산

내부 패스 스루 네트워크 부하 분산기가 새 연결을 분산하는 방식은 장애 조치를 구성했는지 여부에 따라 달라집니다.

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

새 연결을 분산하는 방법은 부하 분산기의 세션 어피니티 설정에 따라 다릅니다.

상태 확인은 새 연결의 분산을 제어합니다. 기본적으로 TCP 연결은 비정상 백엔드에서 지속됩니다. 자세한 내용과 이 동작을 변경하는 방법은 비정상 백엔드의 연결 지속성을 참조하세요.

백엔드 선택 및 연결 추적

내부 패스 스루 네트워크 부하 분산기는 구성 가능한 백엔드 선택 및 연결 추적 알고리즘을 사용하여 트래픽이 백엔드 VM에 분산된 상태를 확인합니다. 내부 패스 스루 네트워크 부하 분산기는 다음 알고리즘을 사용하여 백엔드 VM(장애 조치를 구성한 경우 활성 풀의 백엔드 VM) 간에 패킷을 분산합니다.

부하 분산기의 연결 추적 테이��에 수신 패킷의 특성과 일치하는 항목이 있으면 연결 추적 테이블 항목에 지정된 백엔드로 패킷이 전송됩니다. 패킷은 이전에 설정된 연결의 일부로 간주되므로 부하 분산기가 이전에 결정하여 연결 추적 테이블에 기록한 백엔드 VM으로 패킷이 전송됩니다.
부하 분산기는 연결 추적 항목이 없는 패킷이 수신되면 다음을 수행합니다.
1. 부하 분산기가 백엔드를 선택합니다. 부하 분산기는 구성된 세션 어피니티를 기준으로 해시를 계산합니다. 이 해시를 사용하여 백엔드를 선택합니다.
  - 하나 이상의 백엔드가 정상이면 해시가 정상 백엔드 중 하나를 선택합니다.
  - 모든 백엔드가 비정상이고 장애 조치 정책이 구성되어 있지 않으면 해시는 백엔드 중 하나를 선택합니다.
  - 모든 백엔드가 비정상이고 장애 조치 정책이 구성되어 있으며 이 상황에서 트래픽을 삭제하도록 장애 조치 정책이 구성되어 있지 않으면 해시가 기본 VM 백엔드 중 하나를 선택합니다.
  기본 세션 어피니티 NONE은 패킷의 소스 IP 주소, 소스 포트, 대상 IP 주소, 대상 포트, 프로토콜로 이루어진 5튜플 해시를 사용합니다.
  
  백엔드 선택은 더 적은 정보를 사용하는 해시 알고리즘을 사용해서 맞춤설정될 수 있습니다. 지원되는 모든 옵션에 대해 세션 어피니티 옵션을 참조하세요.
2. 부하 분산기가 연결 추적 테이블에 항목을 추가합니다. 이 항목은 이 연결의 모든 이후 패킷이 동일한 백엔드로 전송되도록 패킷 연결에 대해 선택된 백엔드를 기록합니다. 연결 추적 사용 여부는 프로토콜에 따라 달라집니다.
  
  TCP 및 UDP 패킷의 경우 연결 추적이 항상 사용 설정되며 해제할 수 없습니다. 기본적으로 연결 추적은 5튜플이지만 5튜플 미만으로 구성될 수도 있습니다.
  
  연결 추적 해시가 5-튜플인 경우 TCP SYN 패킷에�� 항상 연결 추적 테이블에 새 항목을 만듭니다.
  
  기본 5튜플 연결 추적은 다음 경우에 사용됩니다.
  - 추적 모드가 PER_CONNECTION(모든 세션 어피니티)이거나,
  - 추적 모드가 PER_SESSION이고 세션 어피니티가 NONE이거나,
  - 추적 모드가 PER_SESSION이고 세션 어피니티가 CLIENT_IP_PORT_PROTO
  어떤 경우에 연결 추적이 사용 설정되는지 및 그러한 경우에 어떤 추적 방법이 사용되는지에 대한 자세한 내용은 연결 추적 모드를 참조하세요.
  
  또한 다음을 참조하세요.
  - 기본적으로 연결 추적 테이블의 항목은 부하 분산기가 항목과 일치한 마지막 패킷을 처리하고 나서 600초 후 만료됩니다. 유휴 제한 시간을 맞춤설정하는 자세한 방법은 유휴 제한 시간을 참조하세요.
  - 프로토콜에 따라서는 백엔드가 비정상이 될 때 부하 분산기가 연결 추적 테이블의 항목을 삭제할 수 있습니다. 이 동작을 맞춤설정하는 방법 등 자세한 내용은 비정상 백엔드의 연결 지속성을 참조하세요.

세션 어피니티 옵션

세션 어피니티는 클라이언트에서 부하 분산기의 백엔드 VM으로의 새 연결 배포를 제어합니다. 백엔드 VM이 해당 클라이언트의 상태 정보를 추적해야 할 경우 세션 어피니티를 설정합니다. 이것은 웹 애플리케이션의 일반적인 요구사항입니다.

세션 어피니티는 최선의 방식으로 작동합니다.

내부 패스 스루 네트워크 부하 분산기는 백엔드 인스턴스 그룹별로 지정하는 것이 아니라 전체 내부 백엔드 서비스에 대해 지정하는 다음과 같은 세션 어피니티 옵션을 지원합니다.

없음(NONE). 소스 IP 주소, 소스 포트, 프로토콜, 대상 IP 주소, 대상 포트의 5튜플 해시
클라이언트 IP, 대상 없음(CLIENT_IP_NO_DESTINATION). 소스 IP 주소에서만 ��성된 1튜플 해시입니다.
클라이언트 IP(CLIENT_IP). 소스 IP 주소와 대상 IP 주소의 2튜플 해시. 외부 패스 스루 네트워크 부하 분산기는 이 세션 어피니티 옵션인 클라이언트 IP, 대상 IP를 호출합니다.
클라이언트 IP, 대상 IP, 프로토콜(CLIENT_IP_PROTO). 소스 IP 주소, 대상 IP 주소, 프로토콜의 3튜플 해시
클라이언트 IP, 클라이언트 포트, 대상 IP, 대상 포트, 프로토콜(CLIENT_IP_PORT_PROTO). 소스 IP 주소, 소스 포트, 프로토콜, 대상 IP 주소, 대상 포트의 5튜플 해시

커스텀 정적 경로의 다음 홉으로 부하 분산기를 사용하지 않는 한, 패킷의 대상 IP 주소는 패킷이 부하 분산기로 전달되는 부하 분산기 전달 규칙의 IP 주소와 일치해야 합니다. 부하 분산기를 커스텀 정적 경로의 다음 홉으로 사용할 때 세션 어피니티 및 다음 홉 내부 패스 스루 네트워크 부하 분산기를 참조하세요.

세션 어피니티 및 다음 홉 내부 패스 스루 네트워크 부하 분산기

내부 패스 스루 네트워크 부하 분산기를 커스텀 정적 경로의 다음 홉으로 사용할 때는 패킷의 대상이 부하 분산기 전달 규칙의 IP 주소가 아닐 가능성이 큽니다.

패킷의 대상이 커스텀 정적 경로의 대상 범위에 속하고 커스텀 정적 경로가 적용 가능한 경로인 경우 패킷이 부하 분산기로 전달됩니다.

클라이언트 IP, 대상 없음을 제외한 모든 세션 어피니티 옵션은 패킷의 대상 IP 주소를 사용합니다. 다음 홉이 내부 패스 스루 네트워크 부하 분산기인 커스텀 정적 경로를 사용하는 경우:

부하 분산기에 백엔드가 하나만 있는 경우(장애 조치를 구성한 경우의 활성 풀에 있음) 모든 세션 어피니티 옵션은 해당 백엔드를 선택합니다. 활성 풀에 단일 백엔드가 있는 경우 세션 어피니티 선택은 차이가 없습니다.
부하 분산기에 백엔드가 두 개 이상 있는 경우(장애 조치를 구성한 경우 활성 풀에 있음) 클라이언트 IP, 대상 없음을 제외한 세션 어피니티 옵션을 선택한 경우, 동일한 클라이언트에서 경로의 대상 위치에 있는 모든 IP 주소로 전송되는 패킷은 동일한 백엔드에서 처리되지 않을 수 있습니다. 세션 어피니티 해시는 패킷의 대상 IP 주소(경로의 대상 범위에 있는 주소일 수 있음)도 포함하는 정보에서 계산되기 때문입니다.
동일한 백엔드가 동일한 클라이언트에서 경로의 대상 IP 주소로 전송되는 모든 패킷을 처리하도록 해야 하는 경우 클라이언트 IP, 대상 없음 세션 어피니티 옵션을 사용해야 합니다.

연결 추적 모드

추적 모드에서는 사용할 연결 추적 알고리즘을 지정합니다. 추적 모드는 PER_CONNECTION(기본값) 및 PER_SESSION 등 두 가지입니다.

PER_CONNECTION(기본값). 이 모드에서는 TCP 및 UDP 트래픽이 세션 어피니티 설정에 관계없이 항상 5-튜플마다 추적됩니다. 이는 연결 추적(5튜플) 키가 구성된 세션 어피니티 설정(예: CLIENT_IP_PROTO 설정이 있는 3튜플)과 다를 수 있음을 의미합니다. 그 결과 세션 어피니티가 분할될 수 있고 백엔드 집합 또는 상태가 변경되는 경우 세션의 새 연결이 다른 백엔드를 선택할 수 있습니다.
PER_SESSION. 이 모드에서는 구성된 세션 어피니티에 따라 TCP 및 UDP 트래픽을 추적합니다. 즉, 세션 어피니티가 CLIENT_IP 또는 CLIENT_IP_PROTO인 경우 이 모드를 구성하면 각각 2튜플과 3튜플 연결 추적이 적용됩니다. 이 방식은 어피니티 손상 비용이 높고 백엔드가 추가된 후에도 어피니티 손상을 피해야 하는 경우에 적합할 수 있습니다.

세션 어피니티가 NONE 또는 CLIENT_IP_PORT_PROTO로 설정된 경우 연결 추적 모드 설정이 ��복됩니다. 각 프로토콜의 다양한 세션 어피니티 설정에 따라 이러한 추적 모드가 작동하는 방식은 다음 표를 참조하세요.

백엔드 선택		연결 추적 모드
세션 어피니티 설정	백엔드 선택을 위한 해시 방법	`PER_CONNECTION`(기본)	`PER_SESSION`
기본값: 세션 어피니티 없음 `NONE`	5튜플 해시	5튜플 연결 추적	5튜플 연결 추적
클라이언트 IP, 대상 없음 `CLIENT_IP_NO_DESTINATION`	1튜플 해시	5튜플 연결 추적	1튜플 연결 추적
클라이언트 IP `CLIENT_IP` (클라이언트 IP와 동일, 외부 패스 스루 네트워크 부하 분산기의 대상 IP)‏	2튜플 해시	5튜플 연결 추적	2튜플 연결 추적
클라이언트 IP, 대상 IP, 프로토콜 `CLIENT_IP_PROTO`	3튜플 해시	5튜플 연결 추적	3튜플 연결 추적
클라이언트 IP, 클라이언트 포트, 대상 IP, 대상 포트, 프로토콜 `CLIENT_IP_PORT_PROTO`	5튜플 해시	5튜플 연결 추적	5튜플 연결 추적

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

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

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

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

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

DEFAULT_FOR_PROTOCOL(기본)
NEVER_PERSIST
ALWAYS_PERSIST

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

비정상 백엔드의 연결 지속성 옵션	연결 추적 모드
비정상 백엔드의 연결 지속성 옵션	`PER_CONNECTION`	`PER_SESSION`
`DEFAULT_FOR_PROTOCOL`	TCP: 비정상 백엔드에서 연결 지속(모든 세션 어피니티) UDP: 비정상 백엔드에서 연결이 지속되지 않음	TCP: 세션 어피니티가 `NONE` 또는 `CLIENT_IP_PORT_PROTO`이면 비정상 백엔드에서 연결 지속 UDP: 비정상 백엔드에서 연결이 지속되지 않음
`NEVER_PERSIST`	TCP, UDP: 비정상 백엔드에서 연결이 지속되지 않음
`ALWAYS_PERSIST`	TCP, UDP: 비정상 백엔드에서 연결 지속(모든 세션 어피니티) 이 옵션은 고급 사용 사례에서만 사용해야 합니다.	구성할 수 없음

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

유휴 제한 시간

기본적으로 연결 추적 테이블의 항목은 부하 분산기가 항목과 일치한 마지막 패킷을 처리하고 나서 600초 후 만료됩니다. 이 기본 유휴 제한 시간 값은 연결 추적이 5튜플보다 작을 때만(즉, 세션 어피니티가 CLIENT_IP 또는 CLIENT_IP_PROTO로 구성되어 있고 추적 모드가 PER_SESSION인 경우에만) 수정할 수 있습니다.

구성 가능한 최대 유휴 제한 시간 값은 57,600초(16시간)입니다.

유휴 제한 시간 값을 변경하는 방법은 연결 추적 정책 구성을 참조하세요.

단일 클라이언트에서 연결 테스트

단일 클라이언트 시스템에서 내부 패스 스루 네트워크 부하 분산기의 IP 주소에 대한 연결을 테스트할 때는 다음을 염두에 두어야 합니다.

클라이언트 시스템이 부하 분산되는 VM, 즉 백엔드 VM이 아닌 경우에는 새 연결이 부하 분산기의 정상 백엔드 VM에 전달됩니다. 하지만 모든 세션 어피니티 옵션은 적어도 클라이언트 시스템의 IP 주소에 달려 있기 때문에 동일한 클라이언트의 연결이 예상보다 더 자주 동일한 백엔드 VM으로 분산될 수 있습니다.

즉, 단일 클라이언트에서 연결하면 내부 패스 스루 네트워크 부하 분산기를 통해 트래픽 분산을 정확하게 모니터링할 수 없다는 의미입니다. 트래픽 분산을 모니터링하는 데 필요한 클라이언트 수는 부하 분산기 유형, 트래픽 유형, 정상 백엔드 수에 따라 다릅니다.
클라이언트 VM이 부하 분산기의 백엔드 VM인 경우, 부하 분산기의 전달 규칙에 해당하는 IP 주소로 전송되는 연결은 항상 클라이언트/백엔드 VM의 응답을 받습니다. 이 작업은 백엔드 VM이 정상 상태인지 여부에 관계없이 수행됩니다. 부하 분산기의 내부 전달 규칙에 지정된 프로토콜 및 포트의 트래픽 뿐만 아니라 부하 분산기의 IP 주소에 전송되는 모든 트래픽에 대해 수행됩니다.

자세한 내용은 부하 분산된 VM에서 요청 전송을 참조하세요.

UDP 조각화

내부 패스 스루 네트워크 부하 분산기는 파편화된 UDP 패킷과 파편화되지 않은 UDP 패킷을 모두 처리할 수 있습니다. 애플리케이션에 조각화된 UDP 패킷이 사용될 경우 다음을 염두에 두어야 합니다.

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

조각화된 UDP 패킷이 전달되어 동일한 백엔드로 라우팅해야 하는 경우 다음 전달 규칙 및 백엔드 서비스 구성 매개변수를 사용합니다.

전달 규칙 구성: 부하 분산 IP 주소당 UDP 전달 규칙 하나만 사용하고 모든 포트에서 트래픽을 허용하도록 전달 규칙을 구성합니다. 이렇게 하면 모든 조각이 동일한 전달 규칙에 의해 도달합니다. 조각화된 패킷(첫 번째 조각 제외)에 대상 포트가 없더라도 모든 포트에서 트래픽을 처리하도록 전달 규칙을 구성하면 포트 정보가 없는 UDP 조각도 수신하도록 구성됩니다. 모든 포트를 구성하려면 Google Cloud CLI를 사용하여 --ports=ALL을 ��정하거나 API를 사용하여 allPorts를 True로 설정합니다.
백엔드 서비스 구성: 포트 정보가 포함된 UDP 패킷과 포트 정보가 없는 UDP 조각(첫 번째 조각 제외)에 대해 동일한 백엔드가 선택되도록 백엔드 서비스의 세션 어피니티를 CLIENT_IP(2튜플 해시) 또는 CLIENT_IP_PROTO(3튜플)로 설정합니다. 동일한 2튜플 또는 3튜플 해시를 사용하여 연결 추적 테이블 항목이 빌드되도록 백엔드 서비스의 연결 추적 모드를 PER_SESSION으로 설정합니다.

장애 조치

내부 패스 스루 네트워크 부하 분산기를 사용하면 일부 백엔드를 장애 조치 백엔드로 지정할 수 있습니다. 이러한 백엔드는 기본 백엔드 인스턴스 그룹의 정상 VM 수가 구성 가능한 기준값 미만인 경우에만 사용됩니다. 기본적으로 모든 기본 및 장애 조치 VM이 비정상적인 경우 Google Cloud는 최후의 수단으로 새 연결을 모든 기본 VM에만 배포합니다.

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

내부 패스 스루 네트워크 부하 분산기의 장애 조치 개념에 대한 자세한 내용은 내부 패스 스루 네트워크 부하 분산기의 장애 조치를 참조하세요.

할당량 및 한도

할당량 및 한도에 대한 자세한 내용은 리소스 할당량 부하 분산을 참조하세요.

제한사항

Google Cloud 콘솔을 사용하여 영역별 NEG 백엔드가 있는 내부 패스 스루 네트워크 부하 분산기를 만들 수 없습니다.

다음 단계

내부 패스 스루 네트워크 부하 분산기를 구성하고 테스트하려면 내부 패스 스루 네트워크 부하 분산기 설정을 참조하세요.
내부 패스 스루 네트워크 부하 분산기에 대해 Cloud Monitoring을 구성하려면 내부 패스 스루 네트워크 부하 분산기 로깅 및 모니터링을 참조하세요.
내부 패스 스루 네트워크 부하 분산기 관련 문제를 해결하려면 내부 패스 스루 네트워크 부하분산기 문제 해결을 참조하세요.