부하 분산기 관리

이 개요 페이지에서는 영역 및 전역 네트워크 구성 모두에 대해 Google Distributed Cloud (GDC) 오프라인에서 내부 및 외부 부하 분산기를 구성하는 방법을 설명합니다.

GDC의 부하 분산은 백엔드 워크로드 전반에서 효율적인 트래픽 분산을 보장하여 애플리케이션 가용성과 성능을 향상시킵니다. 트래픽을 분산하는 데 사용되는 알고리즘은 Maglev입니다. 자세한 내용은 부하 분산 알고리즘을 참고하세요.

이 페이지는 플랫폼 관리자 그룹의 네트워크 관리자 또는 애플리케이션 운영자 그룹의 개발자를 대상으로 합니다. 이들은 조직의 네트워크 트래픽을 관리합니다. 자세한 내용은 GDC 오프라인 환경 문서 대상을 참고하세요.

부하 분산 아키텍처

GDC는 애플리케이션이 서로에게 서비스를 노출할 수 있도록 지원하는 부하 분산기를 제공합니다. 부하 분산기는 백엔드 워크로드 집합에서 트래픽을 균형 있게 조정하는 안정적인 가상 IP (VIP) 주소를 할당합니다. GDC의 부하 분산기는 레이어 4 (L4) 부하 분산을 실행합니다. 즉, 구성된 프런트엔드 TCP 또는 UDP 포트 집합을 해당 백엔드 포트에 매핑합니다. 부하 분산기는 프로젝트 수준에서 구성됩니다.

부하 분산기는 다음 워크로드 유형에 대해 구성됩니다.

  • VM에서 실행되는 워크로드
  • Kubernetes 클러스터 내의 컨테이너화된 워크로드

GDC에서 부하 분산기를 구성하는 방법에는 세 가지가 있습니다.

  • 네트워킹 Kubernetes 리소스 모델 (KRM) API를 사용합니다. 이 API를 사용하여 전역 또는 영역 부하 분산기를 만들 수 있습니다.
  • gdcloud CLI를 사용합니다. 이 API를 사용하여 전역 또는 영역 부하 분산기를 만들 수 있습니다.
  • Kubernetes 클러스터에서 직접 Kubernetes 서비스를 사용합니다. 이 메서드는 영역 부하 분산기만 만듭니다.

부하 분산기 구성요소

KRM API 또는 gdcloud CLI를 사용하여 부하 분산기를 구성할 때는 L4 패스스루 부하 분산기를 사용합니다.

  • L4는 프로토콜이 TCP 또는 UDP임을 의미합니다.
  • 패스스루는 워크로드와 클라이언트 사이에 프록시가 없음을 의미합니다.

부하 분산기는 다음과 같은 구성 가능한 구성요소로 구성됩니다.

  • 전달 규칙: 전달되는 트래픽과 전달되는 백엔드 서비스를 지정합니다. 전달 규칙의 사양은 다음과 같습니다.

    • 클라이언트가 액세스할 수 있는 CIDR, 포트, 프로토콜의 세 가지 튜플로 구성됩니다.
    • TCP 및 UDP 프로토콜을 지원합니다.
    • 내부 및 외부 전달 규칙을 제공합니다. 클라이언트는 Virtual Private Cloud (VPC) 내에서 내부 전달 규칙에 액세스할 수 있습니다. 클라이언트는 GDC 플랫폼 외부에서 또는 EgressNAT 값이 정의된 워크로드를 통해 내부에서 외부 전달 규칙에 액세스할 수 있습니다.
    • 전달 규칙은 백엔드 서비스에 연결됩니다. 여러 전달 규칙이 동일한 백엔드 서비스를 가리키도록 할 수 있습니다.

  • 백엔드 서비스: 전달 규칙, 상태 점검, 백엔드를 함께 연결하는 부하 분산 허브입니다. 백엔드 서비스는 부하 분산기가 트래픽을 전달하는 워크로드를 식별하는 백엔드 객체를 참조합니다. 단일 백엔드 서비스가 참조할 수 있는 백엔드에는 제한사항이 있습니다.

    • 영역당 하나의 영역 백엔드 리소스
    • 클러스터당 하나의 클러스터 백엔드 리소스 프로젝트 백엔드와 혼합할 수 없습니다.

  • 백엔드: 생성된 백엔드 서비스의 백엔드 역할을 하는 엔드포인트를 지정하는 영역 객체입니다. 백엔드 리소스는 영역으로 범위가 지정되어야 합니다. 라벨을 사용하여 엔드포인트를 선택합니다. 선택기의 범위를 프로젝트 또는 클러스터로 지정합니다.

    • 프로젝트 백엔드는 ClusterName 필드가 지정되지 않은 백엔드입니다. 이 경우 지정된 라벨은 영역의 특정 VPC에 있는 특정 프로젝트의 모든 워크로드에 적용됩니다. 라벨은 여러 클러스터의 VM 및 포드 워크로드에 적용됩니다. 백엔드 서비스가 프로젝트 백엔드를 사용하는 경우 해당 백엔드 서비스에서 해당 영역의 다른 백엔드를 참조할 수 없습니다.

    • 클러스터 백엔드는 ClusterName 필드가 지정된 백엔드입니다. 이 경우 지정된 라벨은 지정된 프로젝트의 명명된 클러스터에 있는 모든 워크로드에 적용됩니다. 단일 백엔드 서비스에서 클러스터당 영역당 백엔드를 최대 하나까지 지정할 수 있습니다.

  • 상태 점검: 백엔드의 특정 워크로드 엔드포인트가 정상인지 여부를 확인하는 프로브를 지정합니다. 비정상 엔드포인트는 다시 정상 상태가 될 때까지 부하 분산기에서 제외됩니다. 상태 확인은 VM 워크로드에만 적용됩니다. 포드 워크로드는 기본 제공 Kubernetes 프로브 메커니즘을 사용하여 특정 엔드포인트가 정상인지 확인할 수 있습니다. 자세한 내용은 상태 점검을 참고하세요.

Kubernetes 사용자 클러스터에서 Kubernetes 서비스를 직접 사용하는 경우 앞에서 나열된 구성요소 대신 Service 객체를 사용합니다. Service 객체가 생성된 클러스터의 워크로드만 타겟팅할 수 있습니다.

외부 및 내부 부하 분산

GDC 애플리케이션은 다음 네트워킹 서비스 유형에 액세스할 수 있습니다.

  • 내부 부하 분산기 (ILB): 조직 내 다른 클러스터에 서비스를 노출할 수 있습니다.
  • 외부 부하 분산기 (ELB): 외부 워크로드에서 라우팅할 수 있는 범위에서 가상 IP (VIP) 주소를 할당하고 GDC 조직 내부 또는 외부의 다른 조직과 같은 GDC 인스턴스 외부의 서비스를 노출합니다. ELB에 세션 어피니티를 사용하여 클라이언트의 요청이 일관되게 동일한 백엔드로 라우팅되도록 합니다.

전역 및 영역 부하 분산기

전역 또는 영역 부하 분산기를 만들 수 있습니다. 전역 부하 분산기의 범위는 GDC 유니버스에 걸쳐 있습니다. 각 GDC 유니버스는 상호 연결되고 컨트롤 플레인을 공유하는 리전으로 구성된 여러 GDC 영역으로 구성될 수 있습니다. 예를 들어 각 영역이 3개인 두 리전으로 구성된 유니버스는 us-virginia1-a, us-virginia1-b, us-virginia1-c 및 eu-ams1-a, eu-ams1-b, eu-ams1-c와 같이 표시될 수 있습니다.

영역 부하 분산기의 범위는 생성 시 지정된 영역으로 제한됩니다. 각 영역은 독립적인 재해 도메인입니다. 영역은 로컬 컨트롤 플레인을 사용하는 인프라, 서비스, API, 도구를 관리합니다.

GDC 유니버스의 전역 및 영역 리소스에 대한 자세한 내용은 다중 영역 개요를 참고하세요.

다음 방법을 사용하여 전역 부하 분산기를 만들 수 있습니다.

다음 방법을 사용하여 영역 부하 분산기를 만들 수 있습니다.

  • 네트워킹 Kubernetes 리소스 모델 (KRM) API를 사용합니다. API 버전 networking.gdc.goog를 사용하여 영역 리소스를 만듭니다.
  • gdcloud CLI를 사용합니다. gdcloud CLI 명령어를 사용하여 부하 분산기를 만들 영역을 지정할 때는 --zone 플래그를 사용합니다.
  • Kubernetes 클러스터에서 직접 Kubernetes Service를 사용합니다.

서비스 가상 IP 주소

ILB는 조직 내부 전용 VIP 주소를 할당합니다. 이러한 VIP 주소는 조직 외부에서 연결할 수 없으므로 조직 내의 다른 애플리케이션에 서비스를 노출하는 데만 사용할 수 있습니다. 이러한 IP 주소는 동일한 인스턴스의 조직 간에 겹칠 수 있습니다.

반면 ELB는 조직 외부에서 외부적으로 연결할 수 있는 VIP 주소를 할당합니다. 따라서 ELB VIP 주소는 모든 조직에서 고유해야 합니다. 일반적으로 조직에서 사용할 수 있는 ELB VIP 주소가 더 적습니다.

부하 분산 알고리즘

Google의 부하 분산기는 일관된 해싱 알고리즘인 Maglev를 사용하여 수신 트래픽을 백엔드 타겟에 분산합니다. 이 알고리즘은 고성능과 복원력을 위해 설계되어 트래픽이 균등하고 예측 가능하게 분산되는 동시에 백엔드에서 데이터 지역성을 극대화합니다.

Maglev 작동 방식: 해싱 메커니즘

Maglev는 수신되는 각 패킷의 속성을 해싱하여 포워딩 결정을 내립니다. 이렇게 하면 특정 연결의 모든 패킷이 동일한 백엔드로 일관되게 전송되어 데이터 지역성이 극대화됩니다.

  • 해싱 입력 (5튜플): 알고리즘은 패킷 헤더의 표준 5튜플을 사용하여 해시를 생성합니다. 이 튜플은 다음으로 구성됩니다.
    1. 소스 IP 주소
    2. 소스 포트
    3. 대상 IP 주소
    4. 대상 포트
    5. 프로토콜 (예: TCP, UDP)
  • 전달 결정: 이 해시의 결과는 연결을 부하 분산 풀의 정상 백엔드 중 하나에 결정론적으로 매핑합니다. 해당 연결의 전체 기간 동안 모든 패킷이 동일한 백엔드로 전달됩니다.
  • 균형을 위한 엔트로피: 튜플의 5가지 요소를 모두 사용하여 Maglev는 사용 가능한 모든 백엔드에 다양한 연결이 균등하게 분산되도록 충분한 엔트로피를 생성합니다.

백엔드 상태 및 장애 처리

Maglev는 사용 가능한 백엔드 집합이 변경될 때 복원력을 유지하고 중단을 최소화하도록 설계되었습니다.

  • 백엔드 실패: 백엔드가 상태 점검에 실패하면 사용 가능한 대상 목록에서 삭제됩니다. 이전에 장애가 발생한 백엔드로 라우팅된 연결이 종료됩니다. 새 연결은 해싱 알고리즘에 따라 남은 정상 백엔드 간에 자동으로 재분배됩니다. 중요한 점은 다른 정상 백엔드에 대한 연결은 영향을 받거나 다시 라우팅되지 않는다는 것입니다.
  • 백엔드 복구: 비정상 백엔드가 다시 정상 상태가 되어 풀에 다시 추가되면 해시의 일관된 특성으로 인해 이 백엔드가 최소한의 중단으로 풀에 추가되고 LB는 새로 정상 상태가 된 백엔드를 고려하여 부하를 재분산합니다. 이 '최소한의 중단' 접근 방식을 사용하면 기존 연결이 모두 대대적으로 재편성되는 것을 방지할 수 있으며, 이렇게 하면 애플리케이션 캐시나 상태가 압도될 수 있습니다.

멀티 영역 배포의 동작

Maglev는 토폴로지를 인식하지 못한다는 점을 이해하는 것이 중요합니다. 백엔드의 실제 위치나 네트워크 경로를 고려하지 않고 해시의 수학적 결과에 따라 트래픽을 분산합니다.

  • 위치에 관계없이 균등한 분배: Maglev는 풀의 모든 백엔드를 동일한 타겟으로 취급합니다. 여러 영역에 백엔드가 분산되어 있는 경우 트래픽이 모든 백엔드 간에 고르게 분산됩니다. 이 알고리즘은 '로컬' 영역의 백엔드를 선호하거나 영역 간 네트워크 지연 시간을 고려하지 않습니다.
  • MultiZone Interconnect 용량 확인:백엔드는 여러 영역에 걸쳐 있을 수 있으므로 네트워크 관리자는 MultiZone Interconnect에 부하 분산기 노드와 백엔드 간의 교차 영역 트래픽을 처리할 수 있는 충분한 네트워크 용량이 있는지 확인해야 합니다.

제한사항

  • BackendService 리소스는 포드 워크로드의 HealthCheck 리소스로 구성하면 안 됩니다. BackendService 사양의 HealthCheckName은 선택사항이며 포드로 부하 분산기를 구성할 때는 생략해야 합니다.

  • 부하 분산기 구성은 포드와 VM이 포함된 혼합 워크로드를 타겟팅할 수 없습니다. 따라서 하나의 BackendService 리소스에 포드와 VM이 포함된 혼합 백엔드는 허용되지 않습니다.

  • ForwardingRuleExternal, ForwardingRuleInternal, BackendService 또는 HealthCheck과 같은 글로벌 부하 분산기 커스텀 리소스의 이름은 이러한 영역 부하 분산기 커스텀 리소스와 동일하면 안 됩니다.

  • 조직은 자신이 속한 영역당 최대 500개의 전달 규칙을 정의할 수 있습니다. 전역 전달 규칙은 모든 영역에서 이 한도에 포함됩니다.

표준 클러스터의 제한사항

Standard 클러스터의 부하 분산에는 다음과 같은 제한사항이 적용됩니다.

단일 클러스터 범위

  • 단일 클러스터 범위: Service type=LoadBalancer 리소스를 사용하여 표준 클러스터에 프로비저닝된 부하 분산기 (ILB 또는 ELB)는 해당 단일 표준 클러스터 내에만 있는 포드인 백엔드 엔드포인트를 타겟팅해야 합니다. 여러 표준 클러스터 또는 표준 클러스터와 공유 클러스터의 혼합에서 실행되는 포드로 트래픽을 분산하려고 시도하는 단일 부하 분산기 정의는 지원되지 않습니다.

  • gdcloud CLI 및 네트워킹 Kubernetes 리소스 모델 API는 표준 클러스터에서 지원되지 않습니다. type=LoadBalancer 및 연결된 주석과 함께 표준 Kubernetes Service 리소스를 사용하여 표준 클러스터의 부하 분산을 관리합니다.

  • 프로젝트 범위 부하 분산기는 표준 클러스터를 무시합니다. gdcloud CLI 명령어 또는 네트워킹 Kubernetes 리소스 모델 API를 사용하여 프로젝트 범위 부하 분산기 구성을 만드는 경우 프로젝트의 모든 표준 클러스터가 무시됩니다.

  • 전역 부하 분산은 지원되지 않습니다. 표준 클러스터용으로 프로비저닝된 ILB 및 ELB 리소스는 단일 영역으로 범위가 지정된 영역 리소스입니다. 표준 클러스터 부하 분산기에서는 전역 부하 분산이 지원되지 않습니다.

  • 크로스존 ILB 연결은 지원되지 않습니다. 표준 클러스터 포드에서 다른 영역의 전역 ILB 또는 영역 ILB로의 연결은 지원되지 않습니다.

다음 단계