다음 홉으로 사용되는 내부 TCP/UDP 부하 분산기

내부 TCP/UDP 부하 분산은 내부 IP 주소로 서비스를 실행하고 확장할 수 있게 해주는 리전별 부하 분산기입니다. 내부 TCP/UDP 부하 분산기를 패킷이 최종 목적지로 가는 경로를 따라 전달되는 다음 홉으로 사용할 수 있습니다. 이를 위해 부하 분산기를 커스텀 정적 경로다음 홉으로 설정합니다.

이 페이지의 정보를 검토하기 전에 다음 개념을 숙지해야 합니다.

내부 TCP/UDP 부하 분산기 다음 홉은 다음과 같은 경우에 유용합니다.

  • 게이트웨이 또는 라우터 VM으로 작동하는 여러 VM에 트래픽을 부하 분산합니다.

  • 게이트웨이 가상 어플라이언스를 기본 경로의 다음 홉으로 사용하기 이 구성을 사용하면 Virtual Private Cloud(VPC) 네트워크의 가상 머신(VM) 인스턴스가 부하 분산 가상 게이트웨이 VM을 통해 인터넷에 트래픽을 전송합니다.

  • 백엔드와 동일한 다중 NIC 게이트웨이 또는 라우터 VM 집합을 사용하여 두 개 이상의 방향으로 여러 부하 분산기를 통해 트래픽을 보냅니다. 이렇게 하려면 부하 분산기를 만들고 VPC 네트워크의 커스텀 정적 경로에 대해 다음 홉으로 사용합니다. 각 내부 TCP/UDP 부하 분산기는 단일 VPC 네트워크 내에서 작동하며, 해당 네트워크에서 백엔드 VM의 네트워크 인터페이스로 트래픽을 분산합니다.

아키텍처

다음 다이어그램에서 라우터 VM의 VM 인스턴스 그룹은 두 개의 서로 다른 부하 분산기에 대한 백엔드로 작동합니다. 첫 번째 내부 TCP/UDP 부하 분산은 패킷을 백엔드 VM의 nic0으로 전송하고, 두 번째 내부 TCP/UDP 부하 분산은 동일한 백엔드의 nic1로 패킷을 전송합니다.

여러 NIC로 부하 분산(확대하려면 클릭)
여러 NIC로 부하 분산(확대하려면 클릭)

내부 TCP/UDP 부하 분산기를 다음 홉으로 사용할 때의 이점

부하 분산기가 정적 경로의 다음 홉인 경우 경로가 정의된 VPC 네트워크의 클라이언트 VM의 게스트 운영체제 내에 특별한 구성이 필요하지 않습니다. 클라이언트 VM은 VPC 네트워크 라우팅을 통해 bump-in-the-wire 방식으로 패킷을 부하 분산기의 백엔드로 전송합니다.

내부 TCP/UDP 부하 분산기를 정적 경로의 다음 홉으로 사용하면 내부 TCP/UDP 부하 분산과 동일한 이점이 있습니다. 부하 분산기의 상태 확인은 새 연결이 정상적인 백엔드 VM으로 라우팅되도록 보장합니다. 관리형 인스턴스 그룹을 백엔드로 사용하여 서비스 요구에 따라 VM 집합을 늘리거나 줄이도록 자동 확장을 구성할 수 있습니다.

사양

다음은 내부 TCP/UDP 부하 분산기를 다음 홉으로 사용하기 위한 사양입니다.

경로

커스텀 정적 경로를 만들어 부하 분산기가 정적 경로의 다음 홉인 내부 TCP/UDP 부하 분산기로 TCP, UDP, 기타 프로토콜 트래픽을 전달할 수 있습니다. 경로는 외부(공개적으로 라우팅 가능한) CIDR 프리픽스이거나 프리픽스가 서브넷 경로와 충돌하지 않는 경우 내부 CIDR 프리픽스일 수 있습니다. 예를 들어 기본 경로(0.0.0.0/0)를 패킷 처리를 위해 타사 백엔드 VM으로 트래픽을 보내는 경로로 바꿀 수 있습니다.

클라이언트 IP 세션 어피니티

클라이언트 IP 세션 어피니티는 사용 가능한 세션 어피니티 옵션 중 하나입니다. 이 옵션은 소스 IP 주소 및 대상 IP 주소를 해시 함수의 입력으로 사용하는 2-튜플 어피니티입니다.

자체적으로 내부 TCP/UDP 부하 분산기를 사용할 때, 대상 IP 주소는 부하 분산기의 전달 규칙에 대한 IP 주소입니다. 이 컨텍스트에서 클라이언트 IP 세션 어피니티는 일정한 소스 IP 주소를 포함한 클라이언트의 연결이 동일한 백엔드 VM으로 전달됨을 의미합니다(백엔드 VM이 정상인 경우).

반면에 내부 TCP/UDP 부하 분산기를 정적 경로에 대해 다음 홉으로 사용할 때는 부하 분산기의 백엔드 VM이 대상 IP 주소가 다른 패킷을 처리하고 라우팅하므로 대상 IP 주소가 달라집니다. 이 컨텍스트에서 클라이언트 IP 세션 어피니티 사용하면 클라이언트에 일정한 소스 IP 주소가 포함되더라도 패킷이 동일한 백엔드 VM으로 처리되지 않습니다.

대상 범위

커스텀 정적 경로의 대상 위치는 서브넷 경로와 일치하거나 그보다 구체적일 수 없습니다. 더 구체적인 경우 서브넷 마스크가 더 길다는 것을 의미합니다. 이 규칙은 다음 홉이 내부 TCP/UDP 부하 분산기인 경우를 포함한 모든 커스텀 정적 경로에 적용됩니다. 예를 들어 서브넷 경로가 10.140.0.0/20이라고 가정해 보겠습니다. 커스텀 정적 경로의 대상 위치는 10.140.0.0/20과 같을 수 없으며 10.140.0.0/22와 같이 더 구체적일 수 없습니다.

동일한 VPC 네트워크 및 리전

내부 TCP/UDP 부하 분산기를 다음 홉으로 사용하는 커스텀 정적 경로는 다음으로 제한됩니다.

  • 단일 VPC 네트워크. 부하 분산기와 커스텀 정적 경로가 동일한 VPC 네트워크에 있어야 합니다.

  • 단일 리전 또는 모든 리전. 전역 액세스를 구성하지 않는 한 부하 분산기와 동일한 리전에 있는 리소스만 커스텀 정적 경로를 사용할 수 있습니다. 이 리전 제한은 경로 자체가 전체 VPC 네트워크의 라우팅 테이블의 일부인 경우에도 적용됩니다. 전역 액세스를 사용 설정하면 모든 리전의 리소스가 커스텀 정적 경로를 사용할 수 있습니다.

커스텀 정적 경로 공지

Cloud Router 커스텀 경로 공지를 사용하여 커스텀 정적 경로의 프리픽스(대상)를 공지할 수 있습니다. 경로 공지의 범위는 다음과 같이 부하 분산기의 전역 액세스 설정에 따라 다릅니다.

  • 전역 액세스가 사용 중지되면 부하 분산기와 동일한 리전에 있는 VM, Cloud VPN 터널, Cloud Interconnect 연결(VLAN)에서만 내부 TCP/UDP 부하 분산기를 사용할 수 있습니다. 따라서 커스텀 정적 경로 프리픽스의 커스텀 경로 공지는 Cloud Router와 부하 분산기가 같은 리전에 있는 경우에만 의미가 있습니다.

  • 전역 액세스가 사용 설정되면 모든 리전의 VM, Cloud VPN 터널, Cloud Interconnect 연결(VLAN)에 내부 TCP/UDP 부하 분산기를 사용할 수 있습니다. 전역 동적 라우팅을 사용하면 온프레미스 시스템이 연결된 모든 리전의 커스텀 정적 경로를 사용할 수 있습니다.

다음 표에는 부하 분산기의 접근성이 요약되어 있습니다.

전역 액세스 VPC 네트워크 동적 라우팅 모드 부하 분산기 액세스
사용 중지됨 리전 동일한 리전의 라우터에서 액세스 가능
사용 중지됨 전역 동일한 리전의 라우터에서 액세스 가능
사용 설정됨 리전 모든 리전의 모든 라우터에서 액세스 가능
사용 설정됨 전역 모든 리전의 모든 라우터에서 액세스 가능

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

작업 순서

다음 홉으로 사용되는 커스텀 정적 경로를 만들려면 먼저 내부 TCP/UDP 부하 분산기를 만들어야 합니다. 경로를 만들려면 먼저 부하 분산기가 있어야 합니다. 존재하지 않는 부하 분산기를 참조하는 경로를 만들려고 시도하면 Google Cloud에서 오류가 반환됩니다.

전달 규칙과 연결된 내부 IP 주소를 사용하지 않고 전달 규칙의 이름 및 부하 분산기 리전을 사용하여 내부 TCP/UDP 부하 분산기 다음 홉을 지정합니다.

내부 TCP/UDP 부하 분산기를 참조하는 다음 홉이 포함된 경로를 만든 다음에는 경로를 먼저 삭제하지 않는 한, 부하 분산기를 삭제할 수 없습니다. 특히 이 전달 규칙을 다음 홉으로 사용하는 커스텀 정적 경로가 없을 때까지 내부 전달 규칙을 삭제할 수 없습니다.

백엔드 요구사항

  • IP 전달(--can-ip-forward = True)을 허용하도록 모든 내부 TCP/UDP 부하 분산기의 백엔드 VM을 구성해야 합니다. 자세한 내용은 인스턴스 기반 또는 부하 분산기 기반 라우팅 고려사항을 참조하세요.

  • 백엔드가 Google Kubernetes Engine(GKE) 노드인 내부 TCP/UDP 부하 분산기는 커스텀 정적 경로에 대해 다음 홉으로 사용할 수 없습니다. 해당 노드의 소프트웨어는 대상이 임의 대상이 아닌 클러스터에서 관리되는 IP 주소와 일치하는 경우에만 Pod에 트래픽을 라우팅할 수 있습니다.

TCP, UDP, 기타 프로토콜 트래픽 처리

내부 TCP/UDP 부하 분산기가 다음 홉으로 배포되면 Google Cloud는 다음 사항에 관계없이 모든 포트에서 모든 트래픽을 백엔드 VM으로 전달합니다.

  • 전달 규칙의 프로토콜 및 포트 구성
  • 백엔드 서비스의 프로토콜 구성

경로의 다음 홉인 내부 TCP/UDP 부하 분산기는 Google Cloud VPC 네트워크(예: TCP, UDP, ICMP)에서 지원하는 프로토콜에 대한 모든 트래픽 전달을 원활하게 지원합니다.

추가 고려사항

  • 네트워크 태그가 지원되지 않음. 경로의 다음 홉으로 내부 TCP/UDP 부하 분산기가 있는 경우 커스텀 정적 경로는 네트워크 태그를 사용할 수 없습니다.

  • 모든 백엔드가 비정상일 경우. 내부 TCP/UDP 부하 분산기의 모든 백엔드에서 상태 확인에 실패해도 이 부하 분산기 다음 홉을 사용하는 경로가 계속 적용됩니다. 경로를 통해 처리된 패킷은 트래픽 분산에 따라 다음 홉 부하 분산기의 백엔드 중 하나로 전송됩니다.

  • 공통 내부 IP 주소(--purpose=SHARED_LOADBALANCER_VIP)를 사용하는 전달 규칙은 지원되지 않음. 다음 홉 내부 TCP/UDP 부하 분산기와 공통 IP 주소를 사용하는 내부 TCP/UDP 부하 분산기 전달 규칙은 상호 배타적인 기능입니다. 다음 홉 내부 TCP/UDP 부하 분산기는 하나의 백엔드 서비스(하나의 부하 분산기)만 명확하게 참조되도록 부하 분산기의 전달 규칙에 고유한 IP 주소를 사용해야 합니다. 공통 내부 IP 주소를 사용하는 전달 규칙이 다양한 백엔드 서비스(다른 내부 TCP/UDP 부하 분산기)를 참조할 수 있습니다.

  • 동일한 대상과 여러 다음 홉 내부 TCP/UDP 부하 분산기. 동일한 대상에서 서로 다른 내부 TCP/UDP 부하 분산기 다음 홉을 사용하여 2개 이상의 커스텀 정적 경로를 만드는 경우 Google Cloud는 ECMP를 사용하여 부하 분산기 다음 홉 간에 트래픽을 분산하지 않습니다. 경로가 고유한 우선순위를 가지는 경우 Google Cloud는 우선순위가 가장 높은 경로의 다음 홉 내부 TCP/UDP 부하 분산기를 사용합니다. 경로가 동일한 우선순위를 가지는 경우에도 Google Cloud는 다음 홉 내부 TCP/UDP 부하 분산기를 하나만 선택합니다. 후자의 경우, 아래 다이어그램에 표시된 것처럼 Google Cloud는 확정 내부 알고리즘을 사용하여 단일 다음 홉 전달 규칙(forwarding-rule-a)을 선택하며, 우선순위가 같은 다른 경로를 무시합니다.

    같은 대상, 다른 내부 TCP/UDP 부하 분산기 다음 홉
    같은 대상, 다른 내부 TCP/UDP 부하 분산기 다음 홉
  • 여러 대상 및 동일한 다음 홉 내부 TCP/UDP 부하 분산기. 각 경로에 대상과 우선순위의 고유한 조합이 있다면 여러 커스텀 정적 경로에 동일한 다음 홉 내부 TCP/UDP 부하 분산기를 사용할 수 있습니다. 대상, 우선순위, 내부 TCP/UDP 부하 분산기의 다음 홉이 동일한 커스텀 정적 경로를 여러 개 만들 수 없습니다. 예를 들어 route-x, route-y, route-z는 모두 만들 수 있지만 route-x-copy는 만들 수 없습니다.

    공통 내부 TCP/UDP 부하 분산기 다음 홉을 사용하는 경로 예시
    공통 내부 TCP/UDP 부하 분산기 다음 홉을 사용하는 경로 예시

사용 사례

여러 배포 및 토폴로지에서 내부 TCP/UDP 부하 분산기를 다음 홉으로 사용할 수 있습니다.

각 예시는 다음 가이드라인을 참조하세요.

  • 각 VM 인터페이스는 별도의 VPC 네트워크에 있어야 합니다.

  • 서브넷 경로를 재정의할 수 없으므로 백엔드 VM 또는 부하 분산기를 사용하여 동일한 VPC 네트워크의 서브넷 간 트래픽을 라우팅할 수 없습니다.

  • 내부 TCP/UDP 부하 분산기는 소프트웨어 정의 패스 스루 부하 분산기입니다. 패킷은 소스 또는 대상 정보(주소 또는 주소 및 포트)를 변경하지 않고 백엔드 VM에 전달됩니다.

    라우팅, 패킷 필터링, 프록시, 주소 변환은 내부 TCP/UDP 부하 분산기의 백엔드로 사용되는 가상 어플라이언스 VM에서 처리합니다.

내부 TCP/UDP 부하 분산기를 NAT 게이트웨이에 대해 다음 홉으로 사용

이 사용 사례는 인터넷으로 트래픽을 라우팅하는 여러 NAT 게이트웨이 인스턴스로 내부 VM 트래픽의 부하를 분산합니다.

NAT 사용 사례(클릭하여 확대)
NAT 사용 사례(확대하려면 클릭)

허브 및 스포크: VPC 네트워크 피어링을 사용하여 다음 홉 경로 교환

서브넷 경로 교환 외에도 커스텀 정적 및 동적 경로를 내보내고 가져오도록 VPC 네트워크 피어링을 구성할 수 있습니다. 네트워크 태그를 사용하거나 기본 인터넷 게이트웨이의 다음 홉을 포함하는 커스텀 정적 경로는 제외됩니다. 다음 홉 내부 TCP/UDP 부하 분산기를 사용하는 커스텀 정적 경로가 포함됩니다.

다음을 수행하여 hub VPC 네트워크에 있는 다음 홉 방화벽 가상 어플라이언스를 사용하여 허브 및 스포크 토폴로지를 구성할 수 있습니다.

  • hub VPC 네트워크에서 백엔드로 방화벽 가상 어플라이언스가 포함된 내부 TCP/UDP 부하 분산기를 만듭니다.
  • hub VPC 네트워크에서 커스텀 정적 경로를 만들고 다음 홉을 내부 TCP/UDP 부하 분산기로 설정합니다.
  • VPC 네트워크 피어링을 사용하여 hub VPC 네트워크를 각 spoke VPC 네트워크에 연결합니다.
  • 각 피어링에 대해 해당 커스텀 경로를 내보내도록 hub 네트워크를 구성하고 커스텀 경로를 가져오도록 해당 spoke 네트워크를 구성합니다. 부하 분산기 다음 홉을 포함하는 경로는 hub 네트워크가 내보내는 경로 중 하나입니다.

hub VPC 네트워크의 다음 홉 방화벽 어플라이언스 부하 분산기는 라우팅 순서에 따라 스포크 네트워크에서 사용할 수 있습니다.

  • 전역 액세스가 사용 중지된 경우 부하 분산기와 동일한 리전의 클라이언트
  • 전역 액세스가 사용 설정된 경우 라우팅 순서에 따라 모든 리전의 클라이언트
허브 및 스포크(클릭하여 확대)
허브 및 스포크(확대하려면 클릭)

여러 NIC에 대한 부하 분산

다음 사용 사례에서 백엔드 VM은 여러 VPC 네트워크의 NIC가 포함된 가상 어플라이언스 인스턴스(예: 패킷 검사, 라우팅 또는 게이트웨이 VM)입니다. 이러한 가상 어플라이언스 인스턴스는 타사의 상용 솔루션이거나 직접 빌드한 솔루션일 수 있습니다. 가상 어플라이언스는 여러 NIC가 포함된 Compute Engine VM입니다.

이 예시에서는 관리형 VM 인스턴스 그룹에 있는 백엔드 가상 어플라이언스의 단일 집합을 보여줍니다.

testing이라는 VPC 네트워크에서 내부 TCP/UDP 부하 분산기에 fr-ilb1이라는 전달 규칙이 포함됩니다. 예시에서 이 부하 분산기는 nic0 인터페이스에 트래픽을 분산합니다.

production이라는 VPC 네트워크에서 다른 내부 TCP/UDP 부하 분산기에는 fr-ilb2라는 전달 규칙이 포함됩니다. 이 부하 분산기는 다른 인터페이스(이 예시에서는 nic1)에 트래픽을 분산합니다.

여러 NIC 부하 분산이 포함된 트래픽(확대하려면 클릭)
여러 NIC 부하 분산이 포함된 트래픽(확대하려면 클릭)

자세한 구성 설정은 여러 백엔드 NIC로 부하 분산을 참조하세요.

대칭 해싱

앞의 예시에서는 소스 네트워크 주소 변환(SNAT)을 사용하지 않습니다. Google Cloud는 대칭 해싱을 사용하기 때문에 SNAT가 필요하지 않습니다. 즉, 패킷이 동일한 흐름에 속하면 Google Cloud는 동일한 해시를 계산합니다. 즉, 소스 IP 주소:포트가 대상 IP 주소:포트로 교체되면 해시는 변경되지 않습니다.

참고:

  • 2021년 6월 22일 이후에 내부 TCP/UDP 부하 분산기 전달 규칙을 만들면 대칭 해싱이 자동으로 사용 설정됩니다.

  • 기존 내부 TCP/UDP 부하 분산기에서 대칭 해싱을 사용 설정하려면 대칭 해싱 사용 설정에 설명된 대로 전달 규칙과 다음 홉 경로를 다시 만들어야 합니다.

  • 대칭 해싱은 내부 TCP/UDP 부하 분산에서만 지원됩니다.

  • 대칭 해싱은 프로토콜 TCP 및 UDP에 다음 세션 어피니티 유형으로 지원됩니다.

    • 클라이언트 IP(2튜플)
    • 클라이언트 IP 및 프로토콜(3튜플)
    • 클라이언트 IP, 프로토콜, 포트(5튜플)
  • 어떠한 이유로든 사용 사례에 SNAT가 필요할 경우 SNAT를 사용할 수도 있습니다.

다음 단계