내부 TCP/UDP 부하 분산 개요

Google Cloud 내부 TCP/UDP 부하 분산은 내부 가상 머신(VM) 인스턴스에만 액세스할 수 있는 내부 부하 분산 IP 주소를 기반으로 서비스를 실행 및 확장할 수 있게 해주는 리전별 부하 분산기입니다.

내부 TCP/UDP 부하 분산은 내부 IP 주소를 사용하여 Virtual Private Cloud(VPC) 네트워크의 동일 리전에 있는 VM 인스턴스 간에 트래픽을 분산합니다.

다음의 대략적인 다이어그램에서 볼 수 있듯이 내부 TCP/UDP 부하 분산 서비스에는 프런트엔드(전달 규칙) 및 백엔드(백엔드 서비스 및 인스턴스 그룹)가 있습니다.

대략적인 내부 TCP/UDP 부하 분산기 예시(확대하려면 클릭)
대략적인 내부 TCP/UDP 부하 분산기 예시(확대하려면 클릭)

Google Cloud 부하 분산기의 차이점에 대한 자세한 내용은 다음 문서를 참조하세요.

프로토콜, 스키마, 범위

각 내부 TCP/UDP 부하 분산기에서 지원되는 항목은 다음과 같습니다.

  • TCP 또는 UDP 트래픽(둘 중 하나만 지원)
  • 부하 분산 체계를 포함하는 하나의 백엔드 서비스: internal
  • 하나의 VPC 네트워크에 있는 백엔드 VM
  • 한 리전 내의 모든 영역에 있는 백엔드 VM
  • 전역 액세스가 사용 설정된 경우 모든 리전의 클라이언트

내부 TCP/UDP 부하 분산기에서 지원되지 않는 항목은 다음과 같습니다.

클라이언트 액세스

모든 리전의 클라이언트 VM 인스턴스가 내부 TCP/UDP 부하 분산기에 액세스하도록 허용하기 위해 전역 액세스를 사용 설정할 수 있습니다. 클라이언트 VM은 동일한 네트워크에 있거나 VPC 네트워크 피어링을 사용하여 연결된 VPC 네트워크에 있어야 합니다.

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

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

사용 사례

내부 TCP/UDP 부하 분산기는 여러 사용 사례를 지원합니다. 이 섹션에서는 몇 가지 상위 수준의 예를 설명합니다.

액세스 예시

다음을 사용하여 연결된 네트워크에서 VPC 네트워크의 내부 TCP/UDP 부하 분산기에 액세스할 수 있습니다.

  • VPC 네트워크 피어링
  • Cloud VPN 및 Cloud Interconnect

자세한 예시는 내부 부하 분산 및 연결된 네트워크를 참조하세요.

3계층 웹 서비스 예시

내부 TCP/UDP 부하 분산을 다른 부하 분산기와 함께 사용할 수 있습니다. 예를 들어 외부 HTTP(S) 부하 분산기가 사용된 경우 외부 부하 분산기가 웹 계층이며 내부 부하 분산기를 기반으로 하는 서비스를 사용합니다.

다음 다이어그램은 외부 HTTP(S) 부하 분산기 및 내부 TCP/UDP 부하 분산기를 사용하는 3계층 구성 예시를 보여줍니다.

HTTP(S) 부하 분산 및 내부 TCP/UDP 부하 분산을 사용하는 3계층 웹 앱(확대하려면 클릭)
HTTP(S) 부하 분산 및 내부 TCP/UDP 부하 분산을 사용하는 3계층 웹 앱(확대하려면 클릭)

전역 액세스 권한이 있는 3계층 웹 서비스 예시

전역 액세스를 사용 설정하면 다음 다이어그램에 표시된 것처럼 웹 계층 VM이 어느 리전에나 있을 수 있습니다.

이 다중 계층 애플리케이션 예시는 다음 항목을 보여줍니다.

  • HTTP(S) 부하 분산으로 트래픽을 부하 분산하는 전역적으로 사용 가능한 인터넷 연결 웹 계층
  • 전역 웹 계층으로 액세스되는 us-east1 리전에 있는 내부 백엔드의 부하 분산된 데이터베이스
  • us-east1에 있는 내부 부하 분산된 데이터베이스 계층에 액세스하는 europe-west1 리전의 웹 계층에 속하는 클라이언트 VM
HTTP(S) 부하 분산, 전역 액세스, 내부 TCP/UDP 부하 분산을 사용하는 3계층 웹 앱(확대하려면 클릭)
HTTP(S) 부하 분산, 전역 액세스, 내부 TCP/UDP 부하 분산을 사용하는 3계층 웹 앱(확대하려면 클릭)

내부 TCP/UDP 부하 분산 작동 방식

내부 TCP/UDP 부하 분산기는 다음과 같은 특징을 갖습니다.

  • 관리형 서비스입니다.
  • 프록시가 아닙니다.
  • 가상 네트워킹에서 구현됩니다.

기기 기반 또는 VM 인스턴스 기반의 부하 분산기와 달리 내부 TCP/UDP 부하 분산기는 클라이언트의 연결을 종료하지 않습니다. 트래픽을 부하 분산기로 전송하고 나서 백엔드로 전송하는 대신 클라이언트가 백엔드로 직접 트래픽을 전송합니다.

  • 중간 기기 또는 단일 장애점이 없습니다.
  • 부하 분산기의 IP 주소에 대한 클라이언트 요청이 백엔드 VM으로 직접 이동합니다.
  • 백엔드 VM의 응답은 부하 분산기를 통하지 않고 클라이언트에 직접 전달됩니다. TCP 응답에 직접 서버 반환이 사용됩니다. 자세한 내용은 TCP 및 UDP 요청과 반환 패킷을 참조하세요.

Google Cloud Linux 게스트 환경, Windows 게스트 환경 또는 그에 해당하는 프로세스가 부하 분산기의 IP 주소를 사용하여 각 백엔드 VM을 구성합니다. Google Cloud 가상 네트워킹은 트래픽 전달을 관리하고, 필요에 따라 확장됩니다.

아키텍처

여러 개의 백엔드 인스턴스 그룹이 있는 내부 TCP/UDP 부하 분산기는 해당 인스턴스 그룹 모두에서 백엔드 VM 간에 연결을 분산시킵니다. 분산 방법과 구성 옵션에 대한 자세한 내용은 트래픽 분산을 참조하세요.

비관리형 인스턴스 그룹, 관리형 영역별 인스턴스 그룹, 관리형 리전별 인스턴스 그룹 등 모든 유형의 인스턴스 그룹을 사용할 수 있지만, 네트워크 엔드포인트 그룹(NEG)은 부하 분산기의 백엔드로 사용할 수 없습니다.

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

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

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

커스텀 모드 또는 자동 모드 VPC 네트워크에서 내부 TCP/UDP 부하 분산을 사용할 수 있습니다. 기존 레거시 네트워크에서 내부 TCP/UDP 부하 분산기를 생성할 수도 있습니다.

고가용성

내부 TCP/UDP 부하 분산기는 기본적으로 가용성이 높습니다. 단일 기기 또는 VM 인스턴스에 의존하는 메커니즘이 아니기 때문에 부하 분산기의 가용성을 높일 수 있는 특별 단계는 존재하지 않습니다.

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

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

  • 영역 관리형 인스턴스 그룹 또는 비관리형 인스턴스 그룹을 사용하는 경우 동일한 백엔드 서비스에 대해 동일한 리전의 서로 다른 영역에 있는 여러 인스턴스 그룹을 사용합니다. 여러 영역을 사용하면 특정 영역에서 잠재적 문제를 방지할 수 있습니다.

구성요소

내부 TCP/UDP 부하 분산기는 다음 Google Cloud 구성요소로 구성됩니다.

구성요소 목적 요구사항
내부 IP 주소 부하 분산기의 주소입니다. 내부 IP 주소는 내부 전달 규칙과 동일한 서브넷에 있어야 합니다. 서브넷은 백엔드 서비스와 동일한 리전 및 VPC 네트워크에 있어야 합니다.
내부 전달 규칙 내부 IP 주소와 조합된 내부 전달 규칙이 부하 분산기의 프런트엔드입니다. 부하 분산기가 수락하는 프로토콜과 포트를 정의하며 트래픽을 리전 내부 백엔드 서비스로 보냅니다. 내부 TCP/UDP 부하 분산기의 전달 규칙은 다음 조건을 충족해야 합니다
load-balancing-scheme으로 INTERNAL을 포함합니다.
ip-protocol로 백엔드 서비스의 protocol과 일치하는 TCP 또는 UDP를 사용합니다.
• 백엔드 서비스와 동일한 VPC 네트워크 및 리전에 있는 subnet을 참조합니다.
리전 내부 백엔드 서비스 리전 내부 백엔드 서비스는 백엔드(인스턴스 그룹)와 통신하는 데 사용되는 프로토콜을 정의하며 상태 확인을 지정합니다. 백엔드는 비관리형 인스턴스 그룹, 관리형 영역 인스턴스 그룹 또는 관리형 리전 인스턴스 그룹일 수 있습니다. 백엔드 서비스는 다음 조건을 충족해야 합니다.
load-balancing-scheme으로 INTERNAL을 포함합니다.
protocol로 전달 규칙의 ip-protocol과 일치하는 TCP 또는 UDP를 사용합니다.
• 연결된 상태 확인을 포함합니다.
• 연결된 리전을 포함합니다. 전달 규칙 및 모든 백엔드 인스턴스 그룹의 리전은 백엔드 서비스의 리전과 동일해야 합니다.
• 단일 VPC 네트워크와 연결됩니다. 지정되지 않은 경우 각 백엔드 VM의 기본 네트워크 인터페이스(nic0)에 사용되는 네트워크를 기반으로 네트워크가 유추됩니다.

백엔드 서비스가 특정 서브넷에 연결되지 않아도 전달 규칙의 서브넷은 백엔드 서비스와 동일한 VPC 네트워크에 있어야 합니다.
상태 확인 모든 백엔드 서비스에는 연관된 상태 확인이 있어야 합니다. 상태 확인은 Google Cloud에서 관리되는 백엔드가 트래픽을 수신할 수 있는지를 판단할 때 기준이 되는 매개변수를 정의합니다. 백엔드 인스턴스 그룹에 있는 정상 상태의 VM만 클라이언트 VM에서 부하 분산기의 IP 주소로 전송되는 트래픽을 수신합니다. 전달 규칙 및 백엔드 서비스가 TCP 또는 UDP를 사용할 수 있더라도 Google Cloud에는 UDP 트래픽에 대한 상태 확인이 없습니다. 자세한 내용은 상태 확인 및 UDP 트래픽을 참조하세요.

내부 IP 주소

내부 TCP/UDP 부하 분산은 내부 전달 규칙을 만들 때 선택하는 서브넷의 기본 IP 범위에 있는 내부 IPv4 주소를 사용합니다. IP 주소는 서브넷의 보조 IP 범위에서 가져온 것일 수 없습니다.

전달 규칙을 만들 때 내부 TCP/UDP 부하 분산기의 IP 주소를 지정합니다. 임시 IP 주소를 받거나 예약된 IP 주소를 사용할 수 있습니다.

전달 규칙

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

내부 TCP/UDP 부하 분산기에는 내부 전달 규칙이 한 개 이상 필요합니다. 동일한 부하 분산기에 대해 여러 개의 전달 규칙을 정의할 수 있습니다.

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

  • 전달 규칙에 대해 지정하는 서브넷이 백엔드 VM에 사용되는 서브넷과 동일할 필요가 없지만, 서브넷이 전달 규칙과 동일한 리전에 있어야 합니다.
  • 내부 전달 규칙을 만들 때 Google Cloud는 사용자가 선택한 서브넷의 기본 IP 주소 범위로부터 사용 가능한 내부 리전별 IP 주소를 선택합니다. 또는 서브넷의 기본 IP 범위에서 내부 IP 주소를 지정할 수 있습니다.

전달 규칙 및 전역 액세스

내부 TCP/UDP 부하 분산기의 전달 규칙은 전역 액세스가 사용 설정되어 있더라도 리전별로 적용됩니다. 전역 액세스를 사용 설정한 후에는 리전별 내부 전달 규칙의 allowGlobalAccess 플래그가 true로 설정됩니다.

전달 규칙 및 포트 사양

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

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

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

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

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

여러 전달 규칙

동일한 내부 부하 분산기에 대해 여러 개의 내부 전달 규칙을 구성할 수 있습니다. 각 전달 규칙은 고유 IP 주소를 포함해야 하며, 단일 백엔드 서비스만 참조할 수 있습니다. 여러 전달 규칙이 동일한 백엔드 서비스를 참조할 수 있습니다.

동일한 내부 TCP/UDP 부하 분산기에 대해 여러 개의 IP 주소가 필요하거나 특정 포트를 다른 IP 주소와 연결해야 하는 경우 여러 내부 전달 규칙을 구성하는 것이 유용할 수 있습니다. 여러 전달 규칙을 사용할 경우 백엔드 VM에서 실행 중인 소프트웨어가 모든 필수 IP 주소에 결합되도록 구성해야 합니다. 부하 분산기를 통해 전달되는 패킷의 대상 IP 주소는 해당 내부 전달 규칙과 연결된 내부 IP 주소입니다.

보조 전달 규칙을 만들려면 다른 서브넷에서 전달 규칙 만들기를 참조하세요.

이 예시에서는 10.1.2.99를 사용하는 전달 규칙과 10.5.6.99를 사용하는 전달 규칙을 동일 부하 분산기에 대해 구성합니다. 백엔드 VM은 이 두 IP 주소 중 하나에서 패킷을 수신하도록 구성되어야 합니다. 한 가지 방법은 모든 IP 주소(0.0.0.0/0)에 바인딩되도록 백엔드를 구성하는 것입니다.

백엔드 서비스

각 내부 TCP/UDP 부하 분산기에는 백엔드 매개변수 및 동작을 정의하는 하나의 리전별 내부 백엔드 서비스가 포함됩니다. 백엔드 서비스의 이름은 Google Cloud Console에 표시된 내부 TCP/UDP 부하 분산기 이름입니다.

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

  • 프로토콜. 백엔드는 하나 이상의 내부 전달 규칙으로 지정된 포트에서 TCP 또는 UDP 트래픽을 둘 중 하나만 수락합니다. 백엔드 서비스는 트래픽이 전송되는 것과 동일한 포트에서 백엔드 VM으로 트래픽 전달을 허용합니다. 백엔드 서비스 프로토콜은 전달 규칙의 프로토콜과 일치해야 합니다.

  • 트래픽 분산. 백엔드 서비스는 구성 가능한 세션 어피니티에 따라 트래픽이 분산되게 합니다.

  • 상태 확인. 백엔드 서비스는 연결된 상태 확인을 포함해야 합니다.

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

  • 리전성. 백엔드는 백엔드 서비스(및 전달 규칙)와 동일한 리전에 있는 인스턴스 그룹입니다. 백엔드는 비관리형 인스턴스 그룹이거나, 영역별 관리형 인스턴스 그룹이거나, 리전별 관리형 인스턴스 그룹일 수 있습니다.

  • VPC 네트워크 모든 백엔드 VM은 백엔드 서비스와 연결된 VPC 네트워크의 네트워크 인터페이스를 포함해야 합니다. 명시적으로 백엔드 서비스의 네트워크를 지정하거나 암시적 네트워크를 사용할 수 있습니다. 어느 경우든지 모든 내부 전달 규칙의 서브넷이 백엔드 서비스의 VPC 네트워크에 있어야 합니다.

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

각 백엔드 서비스는 단일 VPC 네트워크 및 Google Cloud 리전에서 작동합니다. VPC 네트워크는 암시적으로 지정되거나 gcloud compute backend-services create 명령어의 --network 플래그로 명시적으로 지정될 수 있습니다.

  • 명시적으로 지정된 경우, 백엔드 서비스의 VPC --network 플래그는 트래픽이 부하 분산되는 각 백엔드 VM에서 네트워크 인터페이스를 식별합니다. 각 백엔드 VM은 지정된 VPC 네트워크의 네트워크 인터페이스를 포함해야 합니다. 이 경우 네트워크 인터페이스 식별자(nic0 ~ nic7)는 백엔드 VM마다 다를 수 있습니다. 예를 들면 다음과 같습니다.

    • 동일한 비관리형 인스턴스 그룹의 서로 다른 백엔드 VM에서는 지정된 VPC 네트워크의 인터페이스가 각 VM에 포함된 경우 서로 다른 인터페이스 식별자가 사용될 수 있습니다.
    • 인터페이스 식별자는 모든 백엔드 인스턴스 그룹 간에 동일할 필요가 없습니다. 하나의 백엔드 인스턴스 그룹에서는 nic0이고, 다른 백엔드 인스턴스 그룹의 백엔드 VM에서는 nic2일 수 있습니다.
  • 백엔드 서비스를 만들 때 --network 플래그를 포함하지 않으면 백엔드 서비스가 모든 백엔드 VM에 사용되는 최초(또는 유일한) 네트워크 인터페이스의 네트워크를 기반으로 네트워크를 선택합니다. 즉, nic0이 모든 백엔드 인스턴스 그룹의 모든 VM에 대해 동일한 VPC 네트워크에 있어야 합니다.

상태 확인

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

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

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

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

사용자가 만드는 상태 확인 유형에 관계없이 Google Cloud는 내부 TCP/UDP 부하 분산기의 IP 주소로 상태 확인 프로브를 전송하여, 부하 분산된 트래픽의 전달 방법을 시뮬레이션합니다. 백엔드 VM에서 실행되는 소프트웨어는 부하 분산기의 IP 주소로 전송되는 부하 분산 트래픽 및 상태 확인 프로브에 응답해야 합니다. 자세한 내용은 프로브 패킷 대상을 참조하세요.

상태 확인 및 UDP 트래픽

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

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

TCP 및 UDP 요청과 반환 패킷

클라이언트 시스템이 TCP 또는 UDP 패킷을 내부 TCP/UDP 부하 분산기에 전송할 때, 패킷의 소스 및 대상은 다음과 같습니다.

  • 소스: 클라이언트의 기본 내부 IP 주소 또는 클라이언트의 별칭 IP 범위 중 하나의 IP 주소입니다.
  • 대상: 부하 분산기의 전달 규칙의 IP 주소입니다.

부하 분산기가 응답 패킷을 전송할 때 해당 패킷의 소스 및 대상은 프로토콜에 따라 달라집니다.

  • TCP는 연결 지향적이며 내부 TCP/UDP 부하 분산기에는 직접 서버 반환이 사용됩니다. 즉, 응답 패킷이 부하 분산기의 전달 규칙에 해당하는 IP 주소로부터 전송됩니다.
  • 반면에 UDP는 연결 지향적이지 않습니다. 기본적으로 반환 패킷은 백엔드 인스턴스의 네트워크 인터페이스에 해당하는 기본 내부 IP 주소로부터 전송됩니다. 하지만 이 동작은 변경 가능합니다. 예를 들어 전달 규칙의 IP 주소에 바인딩되도록 UDP 서버를 구성하면 응답 패킷이 전달 규칙의 IP 주소로부터 전송됩니다.

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

트래픽 유형 소스 목적지
TCP 부하 분산기의 전달 규칙에 해당하는 IP 주소 요청 패킷의 소스
UDP UDP 서버 소프트웨어에 따라 다름 요청 패킷의 소스

트래픽 분산

내부 TCP/UDP 부하 분산기가 새 연결을 분산하는 방식은 장애 조치가 구성되었는지 여부에 따라 달라집니다.

  • 장애 조치를 구성하지 않았으면 적어도 하나의 백엔드 VM이 정상인 경우 내부 TCP/UDP 부하 분산기가 새 연결을 모든 정상 백엔드 VM 간에 분산시킵니다. 모든 백엔드 VM이 비정상인 경우에는 부하 분산기가 최후의 수단으로 새 연결을 모든 백엔드 간에 분산합니다.

  • 장애 조치를 구성한 경우 내부 TCP/UDP 부하 분산기는 사용자가 구성한 장애 조치 정책에 따라 활성 풀 내에서 VM 간에 새 연결을 분산합니다. 모든 백엔드 VM이 비정상이면 트래픽을 삭제할 수 있습니다.

기본적으로 새 연결을 분산하는 메서드는 클라이언트의 IP 주소, 소스 포트, 부하 분산기의 내부 전달 규칙 IP 주소, 대상 포트, 프로토콜이라는 5가지 정보로부터 계산된 해시를 사용합니다. 세션 어피니티 옵션을 지정하여 TCP 트래픽의 트래픽 분산 메서드를 수정할 수 있습니다.

상태 확인은 새 연결의 분산을 제어합니다. 비정상 백엔드 VM이 여전히 연결을 처리 중인 경우에는 비정상 VM에서 설정된 TCP 세션이 유지됩니다.

세션 어피니티 옵션

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

세션 어피니티는 TCP 트래픽에 대해 최선의 방식으로 작동합니다. UDP 프로토콜은 세션을 지원하지 않으므로 세션 어피니티는 UDP 트래픽에 영향을 미치지 않습니다.

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

  • 없음: 기본 설정으로, 클라이언트 IP 프로토콜 및 포트와 사실상 동일합니다.
  • 클라이언트 IP: 클라이언트의 IP 주소와 대상 IP 주소로부터 생성된 해시를 기반으로 특정 클라이언트의 요청을 동일한 백엔드 VM에 전달합니다.
  • 클라이언트 IP 및 프로토콜: 클라이언트의 IP 주소, 대상 IP 주소, 부하 분산기의 프로토콜(TCP 또는 UDP)이라는 3가지 정보로부터 생성된 해시를 기반으로 특정 클라이언트의 요청을 동일한 백엔드 VM에 전달합니다.
  • 클라이언트 IP, 프로토콜 및 포트: 다음의 5가지 정보로부터 생성된 해시를 기반으로 특정 클라이언트의 요청을 동일한 백엔드 VM에 전달합니다.

    • 요청을 보내는 클라이언트의 소스 IP 주소
    • 요청을 보내는 클라이언트의 소스 포트
    • 대상 IP 주소
    • 대상 포트
    • 프로토콜(TCP 또는 UDP)

    대상 IP 주소는 커스텀 정적 경로로 인해 패킷이 부하 분산기로 전달되는 경우를 제외하고는 부하 분산기 전달 규칙의 IP 주소입니다. 내부 TCP/UDP 부하 분산기가 경로의 다음 홉인 경우 이 문서의 다음 섹션인 세션 어피니티 및 다음 홉 내부 TCP/UDP 부하 분산기를 참조하세요.

세션 어피니티 및 다음 홉 내부 TCP/UDP 부하 분산기

선택한 세션 어피니티 옵션에 관계없이 Google Cloud는 패킷의 대상을 사용합니다. 패킷을 부하 분산기로 직접 전송할 때는 패킷의 대상이 부하 분산기 전달 규칙의 IP 주소와 일치합니다.

하지만 내부 TCP/UDP 부하 분산기를 커스텀 정적 경로의 다음 홉으로 사용할 때는 패킷의 대상이 부하 분산기 전달 규칙의 IP 주소가 아닐 가능성이 큽니다. 대상이 경로의 대상 범위 안에 있는 패킷의 경우에는 경로가 부하 분산기로 전달됩니다.

내부 TCP/UDP 부하 분산기를 커스텀 정적 경로의 다음 홉으로 사용하려면 다음 홉으로 사용되는 내부 TCP/UDP 부하 분산기를 참조하세요.

세션 어피니티 및 상태 확인 상태

백엔드 VM의 상태를 변경하면 세션 어피니티가 손실될 수 있습니다. 예를 들어 백엔드 VM이 비정상 상태가 되고 다른 정상 상태의 백엔드 VM이 한 개 이상 있으면, 내부 TCP/UDP 부하 분산기가 비정상 상태의 VM에 새 연결을 분산하지 않습니다. 클라이언트에 비정상 VM과 연결된 세션 어피니티가 있으면 대신 다른 정상 상태의 백엔드 VM으로 전달되기 때문에 해당 세션 어피니티가 손실됩니다.

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

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

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

    즉, 단일 클라이언트에서 연결하면 내부 TCP/UDP 부하 분산기를 통해 트래픽 분산을 정확하게 모니터링할 수 없다는 의미입니다. 트래픽 분산을 모니터링하는 데 필요한 클라이언트 수는 부하 분산기 유형, 트래픽 유형, 정상 백엔드 수에 따라 다릅니다.

  • 클라이언트 VM이 부하 분산기의 백엔드 VM인 경우, 부하 분산기의 전달 규칙에 해당하는 IP 주소로 전송되는 연결은 항상 클라이언트/백엔드 VM의 응답을 받습니다. 이 작업은 백엔드 VM이 정상 상태인지 여부에 관계없이 수행됩니다. 부하 분산기의 내부 전달 규칙에 지정된 프로토콜 및 포트의 트래픽 뿐만 아니라 부하 분산기의 IP 주소에 전송되는 모든 트래픽에 대해 수행됩니다.

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

한도

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

다음 단계