내부 TCP/UDP 부하 분산 개념

내부 TCP/UDP 부하 분산은 내부 가상 머신 인스턴스만 액세스할 수 있는 비공개 부하 분산 IP 주소로 서비스를 실행하고 확장할 수 있게 해주는 리전 부하 분산기입니다.

개요

Google Cloud Platform(GCP) 내부 TCP/UDP 부하 분산은 비공개 내부(RFC 1918) IP 주소를 사용하여 VPC 네트워크의 동일한 리전에 있는 VM 인스턴스 간에 트래픽을 분산시킵니다.

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

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

프로토콜, 스키마, 범위

각 내부 TCP/UDP 부하 분산기는 TCP 또는 UDP 트래픽을 지원하며 둘 다는 지원하지 않습니다.

내부 TCP/UDP 부하 분산기는 내부 부하 분산 스키마가 있는 단일 백엔드 서비스를 사용합니다. 즉, GCP 내 트래픽 부하를 인스턴스 간에 분산시킵니다. 인터넷에서 발생하는 트래픽 부하를 분산시키는 데 사용할 수는 없습니다.

내부 TCP/UDP 부하 분산기의 범위는 전역이 아니라 리전입니다. 즉, 내부 TCP/UDP 부하 분산기는 여러 리전에 걸쳐 있을 수 없습니다. 단일 리전 내에서 부하 분산기는 모든 영역을 서비스합니다. 리전 및 영역을 참조하세요.

Cloud 부하 분산기의 서로 다른 방식에 대한 자세한 내용은 부하 분산기 선택부하 분산 개요를 참조하세요.

사용 사례

액세스 예시

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

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

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

3계층 웹 서비스 예시

내부 TCP/UDP 부하 분산을 HTTP(S) 부하 분산기와 같은 다른 부하 분산기와 함께 사용할 수 있습니다. 이때 웹 계층은 외부 부하 분산기를 사용한 후에 내부 부하 분산기 뒤에 있는 서비스에 의존합니다.

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

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

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

내부 TCP/UDP 부하 분산에는 다음 특성이 있습니다.

  • 부하 분산기는 관리형 서비스입니다.
  • 부하 분산기는 프록시가 아닙니다.
  • 가상 네트워킹에서 구현됩니다.
  • 중간 기기 또는 단일 장애점이 없습니다.
  • 백엔드 VM의 응답은 부하 분산기를 통하지 않고 클라이언트에 직접 전달됩니다.

기기 기반 또는 인스턴스 기반 부하 분산기와 달리 내부 TCP/UDP 부하 분산은 클라이언트의 연결을 종료하지 않습니다. 트래픽이 부하 분산기를 거쳐 백엔드로 전송되는 대신 백엔드로 직접 전송됩니다. GCP Linux 또는 Windows 게스트 환경은 부하 분산기의 IP 주소를 사용하여 각 백엔드 VM을 구성하고, GCP 가상 네트워킹은 트래픽 전달을 적절히 조절하면서 관리합니다.

아키텍처

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

비관리형 인스턴스 그룹, 관리형 영역 인스턴스 그룹, 관리형 리전 인스턴스 그룹 등 모든 유형의 인스턴스 그룹을 부하 분산기의 백엔드로 사용할 수 있지만 NEG(Network Endpoint Group)는 사용할 수 없습니다.

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

내부 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 부하 분산기를 생성할 수도 있습니다.

리전에 있는 클라이언트 VM만 내부 TCP/UDP 부하 분산기에 액세스할 수 있습니다. 내부 TCP/UDP 부하 분산기에 패킷을 전송하기 위해서는 동일한 VPC 네트워크의 클라이언트 VM이 동일한 리전에 있어야 하지만 동일한 서브넷에는 있지 않아도 됩니다. 다른 네트워크에 있는 클라이언트 시스템의 내부 TCP/UDP 부하 분산기와 통신할 수도 있습니다. 단, 해당 네트워크가 부하 분산기가 정의되어 있는 VPC 네트워크에 제대로 연결되어 있어야 합니다. 내부 TCP/UDP 부하 분산 및 연결된 네트워크를 참조하세요.

고가용성

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

다음 권장사항은 단일 영역을 의존하지 않도록 백엔드 VM 인스턴스를 배포하는 방법을 설명합니다.

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

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

구성요소

내부 TCP/UDP 부하 분산기는 다음과 같은 GCP 구성요소로 구성됩니다.

구성요소 목적 요구사항
내부 IP 주소 부하 분산기의 주소입니다. 내부 IP 주소는 내부 전달 규칙과 동일한 서브넷에 있어야 합니다. 서브넷은 백엔드 서비스와 동일한 리전에 있어야 합니다.
내부 전달 규칙 내부 IP 주소와 조합된 내부 전달 규칙이 부하 분산기의 프런트엔드입니다. 부하 분산기가 수락하는 프로토콜과 포트를 정의하며 트래픽을 리전 내부 백엔드 서비스로 보냅니다. 내부 TCP/UDP 부하 분산기의 전달 규칙은 다음 조건을 충족해야 합니다.
load-balancing-schemeINTERNAL이어야 합니다.
ip-protocolTCP 또는 UDP를 사용해야 하며, 백엔드 서비스의 protocol과 일치해야 합니다.
• 백엔드 서비스와 동일한 리전에 있는 VPC 네트워크의 subnet을 참조해야 합니다.
리전 내부 백엔드 서비스 리전 내부 백엔드 서비스는 백엔드(인스턴스 그룹)와 통신하는 데 사용되는 프로토콜을 정의하며 상태 확인을 지정합니다. 백엔드는 비관리형 인스턴스 그룹, 관리형 영역 인스턴스 그룹 또는 관리형 리전 인스턴스 그룹일 수 있습니다. 백엔드 서비스는 다음 조건을 충족해야 합니다.
load-balancing-schemeINTERNAL이어야 합니다.
protocolTCP 또는 UDP를 사용해야 하며, 전달 규칙의 protocol과 일치해야 합니다.
• 연관된 상태 확인이 있어야 합니다.
• 동일한 리전에 있는 백엔드를 참조해야 합니다. 백엔드 인스턴스 그룹은 리전의 서브넷에 있을 수 있습니다. 백엔드 서비스 자체는 특정 서브넷에 연결되지 않습니다.
상태 확인 모든 백엔드 서비스에는 연관된 상태 확인이 있어야 합니다. 상태 확인은 GCP에서 관리되는 백엔드가 트래픽을 수신할 수 있는지를 판단할 때 기준이 되는 매개변수를 정의합니다. 백엔드 인스턴스 그룹에 있는 정상 VM만 클라이언트 VM에서 부하 분산기의 IP 주소로 보낸 트래픽을 수신합니다. 전달 규칙 및 백엔드 서비스가 TCP 또는 UDP를 사용할 수 있더라도 GCP에는 UDP 트래픽에 대한 상태 확인이 없습니다. 자세한 내용은 상태 확인 및 UDP 트래픽을 참조하세요.

내부 IP 주소

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

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

전달 규칙

내부 TCP/UDP 부하 분산을 위해서는 백엔드 서비스 및 인스턴스 그룹(통칭하여 백엔드 구성요소)과 동일한 리전의 서브넷에 내부 전달 규칙이 적어도 한 개 있어야 합니다. 내부 전달 규칙은 같은 리전에 있고 부하 분산기의 백엔드 서비스와 동일한 프로토콜을 사용해야 합니다.

전달 규칙은 부하 분산기가 트래픽을 수락하는 포트를 정의하는 곳입니다. 내부 TCP/UDP 부하 분산기는 프록시가 아닙니다. 트래픽을 수신하는 포트에서 그대로 트래픽을 백엔드로 전달합니다. 포트 번호를 적어도 한 전달 규칙에 하나씩 지정해야 합니다.

포트 외에도 내부 전달 규칙을 만들 때 VPC 네트워크의 특정 서브넷을 참조해야 합니다. 전달 규칙에 대해 지정하는 서브넷이 백엔드 VM에서 사용하는 서브넷과 동일할 필요는 없습니다. 하지만 전달 규칙, 서브넷, 백엔드 서비스는 모두 같은 리전에 있어야 합니다. 내부 전달 규칙을 만들 때 GCP는 선택한 서브넷의 기본 IP 주소 범위 내에서 사용 가능한 내부 IP 주소를 선택합니다. 또는 서브넷의 기본 IP 범위에서 내부 IP 주소를 지정할 수 있습니다.

전달 규칙 및 포트 사양

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

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

특정 프로토콜(TCP 등)에 대한 모든 트래픽을 단일 내부 부하 분산기로 전달하기 위해 모든 포트를 지원하는 내부 전달 규칙을 만듭니다. 그러면 백엔드 VM이 포트당 하나씩 여러 개의 애플리케이션을 실행할 수 있습니다. 특정 포트로 전송된 트래픽은 해당 애플리케이션에 전달되고, 모든 애플리케이션은 동일한 IP 주소를 사용합니다.

백엔드 애플리케이션을 모든 포트에 개방하는 데 관심이 있는 경우에는 백엔드 VM에서 방화벽 규칙을 배포하여 수신 트래픽 범위를 원하는 포트로 설정할 수 있습니다.

전달 규칙은 생성한 후에 수정할 수 없습니다. 내부 전달 규칙의 지정된 포트 또는 내부 IP 주소를 변경해야 하는 경우에는 전달 규칙을 삭제하고 바꿔야 합니다.

여러 전달 규칙

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

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

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

백엔드 서비스

각 내부 TCP/UDP 부하 분산기는 하나의 리전 내부 백엔드 서비스를 사용합니다. 백엔드 서비스의 이름은 GCP Console에 표시되는 내부 TCP/UDP 부하 분산기의 이름입니다.

백엔드 서비스는 하나 이상의 내부 전달 규칙에 의해 전달되는 트래픽을 수락합니다. 리전 내부 백엔드 서비스는 TCP 또는 UDP 트래픽을 수락하지만 둘 다 수락하지는 않습니다. 그리고 전달 규칙에 따라 트래픽을 받은 포트에서 그대로 백엔드 VM으로 트래픽을 전달합니다.

백엔드 서비스에는 적어도 하나의 백엔드 인스턴스 그룹 및 연관된 상태 확인이 있어야 합니다. 백엔드는 백엔드 서비스(및 전달 규칙)와 동일한 리전에 있는 비관리형 인스턴스 그룹, 영역 관리형 인스턴스 그룹 또는 리전 관리형 인스턴스 그룹일 수 있습니다. 백엔드 서비스는 백엔드 VM에 트래픽을 분산시키며, 구성된 경우 세션 어피니티를 관리합니다.

상태 확인

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

기존 상태 확인을 사용하거나 새로운 상태 확인을 정의할 수 있습니다. 내부 TCP/UDP 부하 분산기는 상태 확인을 통과하는 백엔드 VM에만 트래픽을 전송합니다. 하지만 모든 백엔드 VM이 상태 확인에 실패할 경우 GCP는 모든 VM 간에 트래픽을 분산시킵니다.

다음과 같은 상태 확인 프로토콜을 사용할 수 있습니다. 상태 확인의 프로토콜은 부하 분산기 자체의 프로토콜과 일치하지 않아도 됩니다.

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

생성하는 상태 확인 유형과 관계없이 GCP는 내부 TCP/UDP 부하 분산기의 IP 주소로 상태 확인 프로브를 전송함으로써 부하 분산된 트래픽이 어떻게 전달되는지를 시뮬레이션합니다. 백엔드 VM에서 실행되는 소프트웨어는 부하 분산기 자체의 IP 주소로 전송된 부하 분산 트래픽과 상태 확인 프로브에 응답해야 합니다. 자세한 내용은 상태 확인 패킷의 대상을 참조하세요.

상태 확인 및 UDP 트래픽

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

이 구성에서 클라이언트 요청은 UDP 프로토콜을 사용하여 부하 분산되고, TCP 서비스는 GCP 상태 확인 프로버에 정보를 제공하는 데 사용됩니다. 예를 들어 GCP에 HTTP 200 응답을 반환하는 각 백엔드 VM에서 간단한 HTTP 서버를 실행할 수 있습니다. 이 예시에서는 UDP 서비스가 제대로 구성되고 실행 중인 경우에만 HTTP 서버가 200을 반환하도록 백엔드 VM에서 실행되는 자체 로직을 사용해야 합니다.

트래픽 분산

내부 TCP/UDP 부하 분산기가 새 연결을 분산시키는 방식은 장애 조치를 구성했는지 여부에 따라 다릅니다.

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

  • 장애 조치를 구성했으면 내부 TCP/UDP 부하 분산기가 구성된 장애 조치 정책에 따라 활성 풀의 VM 간에 새 연결을 분산시킵니다. 모든 백엔드 VM이 비정상인 경우에는 트래픽 삭제 여부를 선택할 수 있습니다.

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

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

세션 어피니티 옵션

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

세션 어피니티는 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 부하 분산기

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

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

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

백엔드 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에서 요청 전송을 참조하세요.

한도

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

다음 단계

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

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