내부 프록시 네트워크 부하 분산기 개요

Google Cloud 내부 프록시 네트워크 부하 분산기는 오픈소스 Envoy 프록시 소프트웨어 및 Andromeda 네트워크 가상화 스택을 기반으로 하는 프록시 기반 부하 분산기입니다.

내부 프록시 네트워크 부하 분산기는 동일한 VPC 네트워크의 클라이언트나 VPC 네트워크에 연결된 클라이언트에만 액세스할 수 있는 리전 내부 IP 주소 뒤에서 TCP 서비스 트래픽을 실행하고 확장할 수 있는 Layer 4 부하 분산기입니다. 이 부하 분산기는 먼저 Envoy 프록시에서 클라이언트와 부하 분산기 간의 TCP 연결을 종료합니다. 프록시에서 Google Cloud, 온프레미스 또는 기타 클라우드 환경에서 호스팅되는 백엔드에 대한 두 번째 TCP 연결을 엽니다. 더 많은 사용 사례는 프록시 네트워크 부하 분산기 개요를 참조하세요.

작업 모드

내부 프록시 네트워크 부하 분산기는 다음 모드로 구성할 수 있습니다.

• 리전 내부 프록시 네트워크 부하 분산기. 오픈소스 Envoy 프록시를 기반으로 하는 관리형 서비스로 구현되는 리전별 부하 분산기입니다. 리전 모드에서는 모든 클라이언트와 백엔드가 지정된 리전에 있어 리전 규정 준수가 필요할 때 유용합니다.

• 교차 리전 내부 프록시 네트워크 부하 분산기. 오픈소스 Envoy 프록시를 기반으로 하는 관리형 서비스로 구현되는 멀티 리전 부하 분산기입니다. 리전 간 모드를 사용하면 트래픽을 가장 가까운 백엔드로 전달하는 트래픽 관리를 포함하여 여러 리전의 백엔드를 사용하여 전역으로 분산된 백엔드 서비스에 트래픽 부하를 분산할 수 있습니다. 또한 이 부하 분산기는 고가용성을 제공합니다. 백엔드를 여러 리전에 배치하면 단일 리전에서 발생하는 오류를 방지하는 데 도움이 됩니다. 한 리전의 백엔드가 다운되면 트래픽을 다른 리전으로 장애 조치할 수 있습니다. 항상 모든 리전에서 부하 분산기 전달 규칙 IP 주소에 액세스할 수 있습니다.

  다음 표에서는 리전 모드와 교차 리전 모드 간의 중요한 차이점을 설명합니다.

  기능	리전 내부 프록시 네트워크 부하 분산기	리전 간 내부 프록시 네트워크 부하 분산기
  부하 분산기의 가상 IP 주소(VIP)	특정 Google Cloud 리전의 서브넷에서 할당됩니다.	특정 Google Cloud 리전의 서브넷에서 할당됩니다. 여러 리전의 VIP 주소는 동일한 전역 백엔드 서비스를 공유할 수 있습니다.
  클라이언트 액세스	기본적으로 전역에서 액세스할 수 없습니다. 필요한 경우 전역 액세스를 사용 설정할 수 있습니다.	항상 전역에서 액세스할 수 있습니다. 모든 Google Cloud 리전의 클라이언트가 부하 분산기로 트래픽을 전송할 수 있습니다.
  부하 분산된 백엔드	리전 백엔드. 부하 분산기는 부하 분산기의 프록시와 동일한 리전에 있는 백엔드로만 트래픽을 전송할 수 있습니다.	전역 백엔드. 부하 분산기는 모든 리전의 백엔드로 트래픽을 전송할 수 있습니다.
  고가용성 및 장애 조치	동일한 리전의 정상 백엔드로 자동 장애 조치합니다.	동일한 리전 또는 다른 리전의 정상 백엔드로 자동 장애 조치합니다.

모드 식별

gcloud compute forwarding-rules describe FORWARDING_RULE_NAME

아키텍처

다음 다이어그램은 내부 프록시 네트워크 부하 분산기에 필요한 Google Cloud 리소스를 보여줍니다.

리전

이 다이어그램은 프리미엄 등급의 리전 내부 프록시 네트워크 부하 분산기 배포 구성요소를 보여줍니다.

리전 간

이 다이어그램은 동일한 VPC 네트워크에 있는 프리미엄 등급의 리전 간 내부 프록시 네트워크 부하 분산기 배포 구성요소를 보여줍니다. 각 전역 전달 규칙에서 클라이언트가 연결하는 데 사용하는 리전 IP 주소를 사용합니다.

프록시 전용 서브넷

이전 다이어그램에서 프록시 전용 서브넷은 Google이 사용자를 대신하여 Envoy 프록시를 실행하는 데 사용하는 IP 주소 집합을 제공합니다. Envoy 기반 내부 프록시 네트워크 부하 분산기를 사용하는 VPC 네트워크의 각 리전에 프록시 전용 서브넷을 만들어야 합니다.

다음 표에서는 내부 프록시 네트워크 부하 분산기에 대한 프록시 전용 서브넷 요구사항을 설명합니다.

그 밖에도 다음과 같습니다.

• 프록시 전용 서브넷은 백엔드가 아닌 오로지 Envoy 프록시에만 사용됩니다.
• 리전 및 VPC 네트워크에서 모든 내부 프록시 네트워크 부하 분산기의 백엔드 가상 머신(VM) 인스턴스 또는 엔드포인트는 프록시 전용 서브넷에서 연결을 수신합니다.
• 내부 프록시 네트워크 부하 분산기의 IP 주소는 프록시 전용 서브넷에 있지 않습니다. 부하 분산기의 IP 주소는 내부 관리형 전달 규칙으로 정의됩니다.

전달 규칙 및 IP 주소

전달 규칙은 IP 주소, 포트, 프로토콜별로 트래픽을 대상 프록시와 백엔드 서비스로 구성된 부하 분산 구성으로 라우팅합니다.

IP 주소 사양. 각 전달 규칙은 애플리케이션의 DNS 레코드에 사용할 수 있는 단일 리전 IP 주소를 참조합니다. 사용할 수 있는 고정 IP 주소를 예약하거나 Cloud Load Balancing에서 IP 주소를 하나 할당하도록 할 수 있습니다. 고정 IP 주소를 예약하는 것이 좋습니다. 그렇지 않으면 전달 규칙을 삭제하고 새 규칙을 만들 때마다 DNS 레코드를 새로 할당된 임시 IP 주소로 업데이트해야 합니다.

클라이언트는 IP 주소와 포트를 사용하여 부하 분산기의 Envoy 프록시에 연결합니다. 전달 규칙의 IP 주소는 부하 분산기의 IP 주소입니다(가상 IP 주소 또는 VIP라고도 함). 부하 분산기에 연결하는 클라이언트는 TCP를 사용해야 합니다. 지원되는 전체 프로토콜 목록은 부하 분산기 기능 비교를 참조하세요.

전달 규칙에 연결된 내부 IP 주소는 백엔드와 동일한 네트워크 및 리전의 모든 서브넷에서 가져올 수 있습니다.

포트 사양. 내부 프록시 네트워크 부하 분산기에서 사용하는 각 전달 규칙은 1~65535 사이의 단일 포트를 참조할 수 있습니다. 여러 포트를 지원하려면 여러 개의 전달 규칙을 구성해야 합니다.

다음 표에는 내부 프록시 네트워크 부하 분산기의 전달 규칙 요구사항이 나와 있습니다.

전달 규칙 및 VPC 네트워크

이 섹션에서는 외부 애플리케이션 부하 분산기에서 사용하는 전달 규칙이 VPC 네트워크와 연결되는 방법을 설명합니다.

대상 프록시

내부 프록시 네트워크 부하 분산기는 클라이언트의 TCP 연결을 종료하고 백엔드에 새 연결을 만듭니다. 기본적으로 원래 클라이언트 IP 주소와 포트 정보는 유지되지 않습니다. 이 정보를 유지하려면 PROXY 프로토콜을 사용하면 됩니다. 대상 프록시는 들어오는 요청을 부하 분산기의 백엔드 서비스로 직접 라우팅합니다.

다음 표에는 내부 프록시 네트워크 부하 분산기에 필요한 대상 프록시 API가 나와 있습니다.

백엔드 서비스

백엔드 서비스는 들어오는 트래픽을 연결된 백엔드 1개 이상에 전달합니다. 백엔드는 인스턴스 그룹 또는 네트워크 엔드포인트 그룹입니다. 백엔드에는 연결(또는 예를 들어 인스턴스 그룹 백엔드의 경우에는 사용률)을 기반으로 가득 찬 상태를 정의하는 분산 모드 정보가 포함됩니다.

각 내부 프록시 네트워크 부하 분산기에는 단일 백엔드 서비스 리소스가 포함됩니다.

다음 표에서는 내부 프록시 네트워크 부하 분산기의 백엔드 서비스 요구사항을 명시합니다.

지원되는 백엔드

백엔드 서비스는 다음 유형의 백엔드를 지원합니다.

모든 백엔드는 동일한 유형이어야 합니다(인스턴스 그룹 또는 NEG). 여러 유형의 인스턴스 그룹 백엔드를 동시에 사용하거나 다른 유형의 NEG 백엔드를 동시에 사용할 수 있지만 동일한 백엔드 서비스에서 인스턴스 그룹과 NEG 백엔드를 함께 사용할 수는 없습니다.

동일한 백엔드 서비스 내에서 영역별 NEG와 하이브리드 NEG를 혼합할 수 있습니다.

사용자에 대한 서비스 중단을 최소화하려면 백엔드 서비스에서 연결 드레이닝을 사용 설정합니다. 이러한 중단은 백엔드가 종료되거나 수동으로 삭제되거나 자동 확장 처리에 의해 삭제될 때 발생할 수 있습니다. 연결 드레이닝을 사용하여 서비스 중단을 최소화하는 방법에 대한 자세한 내용은 연결 드레이닝 사용 설정을 참조하세요.

백엔드 및 VPC 네트워크

• 인스턴스 그룹, 영역별 NEG, 하이브리드 연결 NEG의 경우 모든 백엔드는 백엔드 서비스와 동일한 프로젝트 및 리전에 있어야 합니다. 하지만 부하 분산기는 백엔드 서비스와 동일한 프로젝트에서 다른 VPC 네트워크를 사용하는 백엔드를 참조할 수 있습니다. 부하 분산기의 VPC 네트워크와 백엔드 VPC 네트워크 간의 연결은 VPC 네트워크 피어링, Cloud VPN 터널, Cloud Interconnect VLAN 연결 또는 Network Connectivity Center 프레임워크를 사용하여 구성할 수 있습니다.

  백엔드 네트워크 정의

  • 영역별 NEG 및 하이브리드 NEG의 경우 NEG를 만들 때 VPC 네트워크를 명시적으로 지정합니다.
  • 관리형 인스턴스 그룹의 경우 VPC 네트워크가 인스턴스 템플릿에 정의됩니다.
  • 비관리형 인스턴스 그룹의 경우 인스턴스 그룹의 VPC 네트워크는 인스턴스 그룹에 추가된 첫 번째 VM에 대한 nic0 인터페이스의 VPC 네트워크와 일치하도록 설정됩니다.

  백엔드 네트워크 요구사항

  백엔드 네트워크는 다음 네트워크 요구사항 중 하나를 충족해야 합니다.

  • 백엔드의 VPC 네트워크는 전달 규칙의 VPC 네트워크와 정확하게 일치해야 합니다.

  • 백엔드의 VPC 네트워크는 VPC 네트워크 피어링을 사용하여 전달 규칙의 VPC 네트워크에 연결되어야 합니다. 전달 규칙의 VPC 네트워크에 있는 프록시 전용 서브넷과 백엔드 인스턴스 또는 엔드포인트에서 사용하는 서브넷 간의 통신을 허용하도록 서브넷 경로 교환을 구성해야 합니다.

• 백엔드의 VPC 네트워크와 전달 규칙의 VPC 네트워크 모두 같은 Network Connectivity Center 허브에 연결된 VPC 스포크여야 합니다. 가져오기 및 내보내기 필터는 전달 규칙의 VPC 네트워크에 있는 프록시 전용 서브넷과 백엔드 인스턴스 또는 엔드포인트에서 사용하는 서브넷 간의 통신을 허용해야 합니다.

• 다른 모든 백엔드 유형의 경우 모든 백엔드가 동일한 VPC 네트워크와 리전에 있어야 합니다.

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

인스턴스 그룹 백엔드를 사용하는 경우 패킷이 항상 nic0에 전달됩니다. nic0이 아닌 인터페이스(vNIC 또는 Dynamic Network Interface)로 패킷을 전송하려면 대신 NEG 백엔드를 사용합니다.

영역별 NEG 백엔드를 사용하는 경우 패킷은 NEG의 엔드포인트가 나타내는 네트워크 인터페이스로 전송됩니다. NEG 엔드포인트는 NEG의 명시적으로 정의된 VPC 네트워크와 동일한 VPC 네트워크에 있어야 합니다.

백엔드와의 통신에 사용되는 프로토콜

내부 프록시 네트워크 부하 분산기에 백엔드 서비스를 구성할 때 백엔드 서비스가 백엔드와 통신하는 데 사용할 프로토콜을 설정합니다. 부하 분산기는 개발자가 지정한 프로토콜만 사용하고 다른 프로토콜과의 연결 협상을 시도하지 않습니다. 내부 프록시 네트워크 부하 분산기는 백엔드와 통신할 때 TCP만 지원합니다.

상태 확인

각 백엔드 서비스는 부하 분산기에서 연결을 수신할 수 있도록 백엔드의 준비 상태를 주기적으로 모니터링하는 상태 점검을 지정합니다. 이러면 요청을 처리할 수 없는 백엔드로 요청이 전송될 위험이 줄어듭니다. 상태 점검은 애플리케이션 자체가 작동하는지 확인하지 않습니다.

상태 점검 프로토콜

필수는 아니며 항상 가능하지는 않지만 프로토콜이 백엔드 서비스의 프로토콜과 일치하는 상태 점검을 사용하는 것이 좋습니다. 예를 들어 TCP 상태 점검은 백엔드에 대한 TCP 연결을 가장 정확하게 테스트합니다. 지원되는 상태 점검 프로토콜 목록은 부하 분산기 기능 비교 페이지의 상태 점검 섹션을 참조하세요.

다음 표에서는 각 모드의 내부 프록시 네트워크 부하 분산기에서 지원하는 상태 점검 범위를 명시합니다.

상태 점검에 대한 자세한 내용은 다음을 참조하세요.

• 상태 확인 개요
• 상태 점검 사용

방화벽 규칙

내부 프록시 네트워크 부하 분산기에는 다음 방화벽 규칙이 필요합니다.

• Google 상태 점검 프로브의 트래픽을 허용하는 인그레스 허용 규칙 특정 상태 점검 프로브 IP 주소 범위와 트래픽을 허용해야 하는 이유에 대한 자세한 내용은 프로브 IP 범위 및 방화벽 규칙을 참조하세요.
• 프록시 전용 서브넷의 트래픽을 허용하는 인그레스 허용 규칙

이러한 방화벽 규칙의 포트를 다음과 같이 구성해야 합니다.

• 각 백엔드 서비스 상태 확인의 목적지 포트에 대한 트래픽을 허용합니다.

• 인스턴스 그룹 백엔드: 백엔드 서비스의 이름이 지정된 포트와 각 인스턴스 그룹의 이름이 지정된 포트에 연결된 포트 번호 간의 매핑에 따라 구성할 포트를 결정합니다. 동일한 백엔드 서비스에 할당된 인스턴스 그룹에서도 이 포트 번호가 다를 수 있습니다.

• GCE_VM_IP_PORT NEG 백엔드: 엔드포인트의 포트 번호에 대한 트래픽을 허용합니다.

이러한 부하 분산기의 방화벽 규칙 요구사항에는 몇 가지 예외가 있습니다.

• 하이브리드 NEG에는 Google의 상태 점검 프로브 범위에서 오는 트래픽을 허용할 필요가 없습니다. 하지만 단일 백엔드 서비스에서 하이브리드 및 영역별 NEG 조합을 사용하는 경우 영역별 NEG에 대한 Google 상태 점검 프로브 범위의 트래픽을 허용해야 합니다.
• 리전 인터넷 NEG의 경우 상태 확인은 선택사항입니다. 리전별 인터넷 NEG를 사용하는 부하 분산기에서 오는 트래픽은 프록시 전용 서브넷에서 시작되며 수동 또는 자동으로 할당된 NAT IP 주소로 NAT 변환됩니다(Cloud NAT 사용). 이 트래픽에는 상태 확인 프로브와 부하 분산기에서 백엔드로의 사용자 요청이 포함됩니다. 자세한 내용은 리전 NEG: Cloud NAT 게이트웨이 사용을 참조하세요.

클라이언트 액세스

클라이언트는 같은 네트워크 또는 VPC 네트워크 피어링을 사용하여 연결된 VPC 네트워크에 있을 수 있습니다.

리전 내부 프록시 네트워크 부하 분산기의 경우 클라이언트가 기본적으로 부하 분산기와 동일한 리전에 있어야 합니다. 모든 리전의 클라이언트가 부하 분산기에 액세스하도록 허용하려면 전역 액세스를 사용 설정하면 됩니다.

리전 간 내부 프록시 네트워크 부하 분산기의 경우 전역 액세스가 기본적으로 사용 설정됩니다. 모든 리전의 클라이언트가 부하 분산기에 액세스할 수 있습니다.

다음 표에는 리전 내부 프록시 네트워크 부하 분산기에 대한 클라이언트 액세스가 요약되어 있습니다.

공유 VPC 아키텍처

내부 프록시 네트워크 부하 분산기는 공유 VPC를 사용하는 네트워크를 지원합니다. 공유 VPC를 사용하면 네트워크 관리자와 서비스 개발자 간의 책임을 명확하게 구분할 수 있습니다. 개발팀은 서비스 프로젝트에 서비스를 빌드하는 데 집중할 수 있으며 네트워크 인프라팀은 부하 분산을 프로비저닝하고 관리할 수 있습니다. 공유 VPC에 대해 잘 모른다면 공유 VPC 개요 문서를 참조하세요.

트래픽 분산

내부 프록시 네트워크 부하 분산기는 다음과 같이 백엔드에 트래픽을 분산합니다.

1. 단일 클라이언트에서 시작되는 연결은 해당 영역 내 정상 백엔드(인스턴스 그룹 또는 NEG)를 사용할 수 있고 분산 모드에 의해 결정된 용량을 가지는 경우 같은 영역에 전송됩니다. 리전 내부 프록시 네트워크 부하 분산기의 경우 분산 모드는 CONNECTION(인스턴스 그룹 또는 NEG 백엔드) 또는 UTILIZATION(인스턴스 그룹 백엔드만 해당)일 수 있습니다.
2. 세션 어피니티를 구성한 경우 클라이언트의 연결이 동일한 백엔드로 전송됩니다.
3. 백엔드가 선택되면 부하 분산 정책에 따라 인스턴스 그룹의 인스턴스 또는 NEG의 엔드포인트에서 트래픽이 분산됩니다. 지원되는 부하 분산 정책 알고리즘은 리전 백엔드 서비스 API 문서의 localityLbPolicy 설정을 참조하세요.

세션 어피니티

세션 어피니티를 사용하면 백엔드가 정상이고 용량이 있는 한 부하 분산기 백엔드 서비스에서 같은 클라이언트의 모든 요청을 같은 백엔드로 보내도록 구성할 수 있습니다.

• 없음

  세션 어피니티를 NONE으로 설정한다고 해서 세션 어피니티가 없다는 의미는 아닙니다. 명시적으로 구성된 세션 어피니티 옵션이 없다는 의미입니다.

  해싱은 항상 백엔드를 선택하기 위해 수행됩니다. 세션 어피니티 설정이 NONE이면 부하 분산기에서 5튜플 해시를 사용하여 백엔드를 선택합니다. 5튜플 해시는 소스 IP 주소, 소스 포트, 프로토콜, 대상 IP 주소, 목적지 포트로 구성되어 있습니다.

  세션 어피니티 기본값은 NONE입니다.

• 클라이언트 IP 어피니티

  클라이언트 IP 세션 어피니티(CLIENT_IP)는 패킷의 소스 및 대상 IP 주소에서 생성된 2튜플 해시입니다. 클라이언트 IP 어피니티는 백엔드가 정상이고 용량이 충분한 경우 같은 클라이언트 IP 주소의 모든 요청을 같은 백엔드로 전달합니다.

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

  • 패킷 대상 IP 주소는 패킷이 부하 분산기로 직접 전송되는 경우에만 부하 분산기 전달 규칙 IP 주소와 동일합니다.
  • 패킷이 Google Cloud 부하 분산기에 전송되기 전에 중간 NAT 또는 프록시 시스템에서 처리되는 경우에는 패킷 소스 IP 주소가 원래 클라이언트와 연결된 IP 주소와 일치하지 않을 수 있습니다. 여러 클라이언트에서 같은 유효 소스 IP 주소를 공유하는 경우 일부 백엔드 VM은 다른 VM보다 더 많은 연결이나 요청을 수신할 수 있습니다.

세션 어피니티를 구성할 때 다음 사항에 유의하세요.

• 인증 또는 보안 목적으로 세션 어피니티를 사용하지 않습니다. 제공 및 정상 백엔드 수가 변경될 때마다 세션 어피니티가 중단될 수 있습니다. 자세한 내용은 세션 어피니티 손실을 참조하세요.

• --session-affinity 및 --subsetting-policy 플래그의 기본값은 모두 NONE이며 한 번에 하나만 다른 값으로 설정할 수 있습니다.

세션 어피니티 상실

모든 세션 어피니티 옵션에는 다음이 필요합니다.

• 선택한 백엔드 인스턴스나 엔드포인트는 백엔드로 구성된 상태를 유지해야 합니다. 다음 이벤트 중 하나가 발생하면 세션 어피니티가 중단될 수 있습니다.
  • 선택한 인스턴스를 인스턴스 그룹에서 삭제합니다.
  • 관리형 인스턴스 그룹 자동 확장 또는 자동 복구로 인해 선택한 인스턴스가 관리형 인스턴스 그룹에서 삭제됩니다.
  • 선택한 엔드포인트를 NEG에서 삭제합니다.
  • 선택한 인스턴스나 엔드포인트가 포함된 인스턴스 그룹 또는 NEG를 백엔드 서비스에서 삭제합니다.
• 선택한 백엔드 인스턴스나 엔드포인트가 정상 상태로 유지되어야 합니다. 선택한 인스턴스나 엔드포인트가 상태 점검에 실패하면 세션 어피니티가 손상될 수 있습니다.

• 선택한 인스턴스 또는 엔드포인트가 포함된 인스턴스 그룹 또는 NEG가 대상 용량에서 정의된 대로 가득 차서는 안 됩니다. 리전 관리형 인스턴스 그룹의 경우 선택한 인스턴스가 포함된 인스턴스 그룹의 영역 구성요소가 가득 차서는 안 됩니다. 인스턴스 그룹 또는 NEG가 가득 차고 다른 인스턴스 그룹 또는 NEG는 가득 차지 않은 경우 세션 어피니티가 손상될 수 있습니다. UTILIZATION 분산 모드를 사용할 때는 가득 찬 상태가 예측 불가능한 방식으로 변경될 수 있으므로 RATE 또는 CONNECTION 분산 모드를 사용하여 세션 어피니티가 손상될 수 있는 상황을 최소화해야 합니다.

• 구성된 백엔드 인스턴스 또는 엔드포인트의 총 개수는 일정하게 유지되어야 합니다. 다음 이벤트 중 하나 이상이 발생하면 구성된 백엔드 인스턴스 또는 엔드포인트 수가 변경되고 세션 어피니티가 손상될 수 있습니다.

  • 새 인스턴스나 엔드포인트를 추가합니다.

    • 백엔드 서비스의 기존 인스턴스 그룹에 인스턴스를 추가합니다.
    • 관리형 인스턴스 그룹 자동 확장으로 인해 백엔드 서비스의 관리형 인스턴스 그룹에 인스턴스가 추가됩니다.
    • 백엔드 서비스의 기존 NEG에 엔드포인트를 추가합니다.
    • 백엔드 서비스에 비어 있지 않은 백엔드 인스턴스 그룹 또는 NEG를 추가합니다.

  • 선택한 인스턴스 또는 엔드포인트뿐만 아니라 모든 인스턴스 또는 엔드포인트 삭제:

    • 인스턴스 그룹 백엔드에서 인스턴스를 삭제합니다.
    • 관리형 인스턴스 그룹 자동 확장 또는 자동 복구로 인해 관리형 인스턴스 그룹 백엔드에서 인스턴스가 삭제됩니다.
    • NEG 백엔드에서 엔드포인트를 삭제합니다.
    • 백엔드 서비스에서 비어 있지 않은 기존 백엔드 인스턴스 그룹이나 NEG를 삭제합니다.

• 정상 백엔드 인스턴스나 엔드포인트의 총개수는 일정하게 유지되어야 합니다. 다음 이벤트 중 하나 이상이 발생하면 정상적인 백엔드 인스턴스 또는 엔드포인트 수가 변경되고 세션 어피니티가 손상될 수 있습니다.

  • 인스턴스 또는 엔드포인트가 상태 점검을 통과하여 비정상 상태에서 정상 상태로 전환됩니다.
  • 인스턴스 또는 엔드포인트가 상태 점검에 실패하여 정상 상태에서 비정상 상태 또는 시간 초과로 전환됩니다.

장애 조치

백엔드가 비정상이 되면 트래픽은 자동으로 정상 백엔드로 리디렉션됩니다.

다음 표에서는 내부 프록시 네트워크 부하 분산기의 장애 조치 동작을 설명합니다.

GKE 애플리케이션을 위한 부하 분산

Google Kubernetes Engine(GKE)에서 애플리케이션을 빌드하는 경우 독립형 영역별 NEG를 사용하여 컨테이너로 직접 트래픽 부하를 분산할 수 있습니다. 독립형 NEG에서는 개발자가 직접 영역별 NEG를 만드는 서비스 객체를 만든 후 NEG를 백엔드 서비스와 연결하여 부하 분산기를 포드에 연결해야 합니다.

관련 GKE 문서:

• 독립형 NEG를 통한 컨테이너 기반 부하 분산

할당량 및 한도

할당량 및 한도에 대한 자세한 내용은 할당량 및 한도를 참조하세요.

제한사항

• 내부 프록시 네트워크 부하 분산기는 IPv6 트래픽을 지원하지 않습니다.
• 내부 프록시 네트워크 부하 분산기는 부하 분산기의 프런트엔드가 한 호스트나 서비스 프로젝트에 있고 백엔드 서비스와 백엔드가 다른 서비스 프로젝트에 있는 공유 VPC 배포(프로젝트 간 서비스 참조라고도 함)를 지원하지 않습니다.

다음 단계

• VM 인스턴스 그룹 백엔드로 리전 간 내부 애플리케이션 부하 분산기 설정

• 하이브리드 연결로 리전 간 내부 애플리케이션 부하 분산기 설정

• 인스턴스 그룹 백엔드로 리전 내부 프록시 네트워크 부하 분산기 설정

• 영역별 NEG 백엔드로 리전 내부 프록시 네트워크 부하 분산기 설정

• 하이브리드 NEG 백엔드로 리전 내부 프록시 네트워크 부하 분산기 설정

• 인터넷 NEG 백엔드로 리전 내부 프록시 네트워크 부하 분산기 설정

• Cloud Monitoring으로 측정항목 보기