내부 HTTP(S) 부하 분산기용 프록시 전용 서브넷

이 페이지에서는 내부 HTTP(S) 부하 분산용 프록시 전용 서브넷의 작동 방식을 설명합니다 내부 HTTP(S) 부하 분산의 일반적인 개요는 내부 HTTP(S) 부하 분산 개념을 참조하세요.

내부 HTTP(S) 부하 분산기는 네트워크의 프록시 풀을 제공합니다. 프록시는 URL 맵, 백엔드 서비스의 세션 어피니티, 각 백엔드 인스턴스 그룹 또는 NEG의 분산 모드, 기타 요인을 기반으로 이동하는 각 HTTP(S) 요청의 위치를 평가합니다.

  1. 클라이언트는 부하 분산기 전달 규칙의 IP 주소와 포트에 연결됩니다.

  2. 프록시 중 하나에서 클라이언트의 네트워크 연결을 수신하고 종료합니다.

  3. 프록시는 부하 분산기의 URL 맵과 백엔드 서비스에서 지정한 대로 NEG의 적절한 백엔드 VM 또는 엔드포인트에 대한 연결을 설정합니다.

각 부하 분산기의 프록시에는 내부 IP 주소가 할당됩니다. 리전 내 모든 내부 HTTP(S) 부하 분산기의 프록시는 해당 리전 VPC 네트워크의 단일 프록시 전용 서브넷에서 내부 IP 주소를 사용합니다. 이 서브넷은 내부 HTTP(S) 부하 분산 프록시 전용으로 예약되므로 다른 용도로 사용할 수 없습니다. 프록시 전용 서브넷에는 64개 이상의 IP 주소를 제공해야 합니다. 이는 /26 이하의 프리픽스 길이에 해당합니다. VPC 네트워크의 각 리전별로 1개의 프록시 전용 서브넷만 활성화될 수 있습니다.

리전의 내부 HTTP(S) 부하 분산기용으로 GCP에서 만든 프록시만 프록시 전용 서브넷을 사용합니다. 부하 분산기 전달 규칙의 IP 주소는 프록시 전용 서브넷에서 시작되지 않습니다. 백엔드 VM 및 엔드포인트의 IP 주소도 프록시 전용 서브넷에서 시작되지 않습니다.

각 프록시는 해당 부하 분산기의 전달 규칙에서 지정한 IP 주소와 포트를 리슨합니다. 프록시에서 백엔드 VM 또는 엔드포인트로 전송되는 각 패킷에는 프록시 전용 서브넷의 소스 IP 주소가 있습니다.

다음 다이어그램은 트래픽 흐름을 간략하게 보여줍니다.

Layer 7 기반 부하 분산을 사용하는 내부 서비스(확대하려면 클릭)
Layer 7 기반 부하 분산을 사용하는 내부 서비스(확대하려면 클릭)

프록시 전용 서브넷이 부하 분산기 아키텍처에 통합되는 방식

다음 다이어그램은 HTTP(S) 내부 부하 분산기에 필요한 GCP 리소스를 보여줍니다.

내부 HTTP(S) 부하 분산 구성요소(확대하려면 클릭)
내부 HTTP(S) 부하 분산 구성요소(확대하려면 클릭)

다이어그램에서 볼 수 있듯이 내부 HTTP 부하 분산기 배포에는 2개 이상의 서브넷이 필요합니다.

  • 부하 분산기의 내부 관리형 전달 규칙과 백엔드 VM 및 백엔드 엔드 포인트의 IP 주소는 기본 IP 주소 범위가 10.1.2.0/24인 단일 서브넷을 사용합니다. 이 서브넷은 프록시 전용 서브넷이 아닙니다. 서브넷이 부하 분산기와 동일한 리전에 있다면 백엔드 VM 및 엔드포인트에 여러 개의 서브넷을 사용할 수 있습니다.

  • 프록시 전용 서브넷은 10.129.0.0/26입니다.

프록시 전용 서브넷 만들기

HTTP(S) 부하 분산기의 서브넷 예약은 일부 플래그의 추가를 제외하고 서브넷 만들기 절차와 기본적으로 동일합니다.

내부 HTTP(S) 부하 분산기의 전달 규칙을 만들기 전에 부하 분산기의 프록시에서 사용할 프록시 전용 서브넷을 만들어야 합니다. 리전에 대한 프록시 전용 서브넷을 먼저 만들지 않고 내부 HTTP(S) 부하 분산기를 구성하려고 하면 부하 분산기 생성 프로세스가 실패합니다.

내부 HTTP(S) 부하 분산기를 사용하는 가상 네트워크(VPC)의 각 리전에 1개의 프록시 전용 서브넷을 만들어야 합니다. 이 서브넷은 해당 리전의 모든 내부 HTTP 부하 분산기에서 공유합니다.

네트워크가 자동 모드인지 또는 커스텀 모드인지 여부에 관계없이 프록시 전용 서브넷을 만들어야 합니다. 권장 서브넷 크기는 /24(256개 프록시 전용 주소)이며, 최소 /26(64개의 프록시 전용 주소) 이상이어야 합니다.

gcloud compute networks subnets create 명령어는 프록시 전용 서브넷을 만듭니다.

gcloud beta compute networks subnets create SUBNET_NAME \
    --purpose=INTERNAL_HTTPS_LOAD_BALANCER \
    --role=ACTIVE \
    --region=REGION \
    --network=VPC_NETWORK_NAME \
    --range=CIDR_RANGE

각 항목의 의미는 다음과 같습니다.

  • SUBNET_NAME은 프록시 전용 서브넷의 이름입니다.
  • REGION은 프록시 전용 서브넷의 리전입니다.
  • VPC_NETWORK_NAME은 서브넷이 포함된 VPC 네트워크의 이름입니다.
  • CIDR_RANGE는 서브넷의 기본 IP 범위입니다. 리전의 프록시에서 64개 이상의 IP 주소를 사용할 수 있도록 26 이하의 서브넷 마스크를 사용해야 합니다.

전체 구성 예시는 프록시 전용 서브넷 만들기를 참조하세요.

GCP Console을 사용하는 경우 다음 섹션에 설명된 대로 부하 분산 UI에 프록시 전용 서브넷을 만들 수 있습니다.

백엔드가 프록시 전용 서브넷의 연결을 수락하도록 방화벽 규칙을 구성해야 합니다. 방화벽 규칙 구성에서 l7-ilb-firewall 구성을 참조하세요.

프록시 전용 서브넷의 크기 또는 주소 범위 변경

프록시 전용 서브넷은 리전 및 VPC 네트워크당 1개만 활성화할 수 있고 서브넷의 기본 IP 범위만 확장할 수 있기 때문에 프록시 전용 서브넷을 수정하려면 다음 절차를 따라야 합니다.

  1. gcloud compute networks subnets create 명령어를 사용하여 동일한 리전에 백업 프록시 전용 서브넷을 만들고 필요에 맞는 기본 IP 범위를 지정합니다.

    gcloud beta compute networks subnets create subnet-name \
       --purpose=INTERNAL_HTTPS_LOAD_BALANCER \
       --role=BACKUP \
       --region=region \
       --network=vpc-network-name \
       --range=cidr-range
    
  2. 백업 프록시 전용 서브넷의 기본 IP 범위를 포함하도록 백엔드 VM 또는 엔드포인트에 적용되는 인그레스 허용 방화벽 규칙을 만들거나 수정합니다.

  3. 다음 gcloud 명령어는 백업 프록시 전용 서브넷을 활성 역할로 승격하고 이전의 활성 프록시 전용 서브넷을 백업 역할로 강등합니다.

    gcloud beta compute networks subnets update backup-proxy-subnet \
       --role=ACTIVE \
       --drainTimeoutSeconds=connection-draining-timeout<\var>
    

    자리표시자를 유효한 값으로 바꿉니다.

    • <var>backup-proxy-subnet</var>은 새로 만든 프록시 전용 서브넷의 이름입니다.
    • <var>connection-draining-timeout<\var>은 이전의 활성 프록시 전용 서브넷의 프록시에서 다른 곳으로 기존 연결을 마이그레이션하는 데 GCP가 사용하는 시간(초)입니다.

    프록시 전용 서브넷을 백업에서 활성으로 전환해도 새 연결이 중단되지 않습니다.

    • 새로 활성화된 프록시 전용 서브넷은 새 연결에 사용됩니다.
    • 이전의 활성(현재는 백업) 프록시 전용 서브넷은 더 이상 새 연결에 사용되지 않습니다.
    • GCP는 이전의 활성(현재는 백업) 프록시 전용 서브넷의 프록시에서 기존 연결을 드레이닝하기 시작합니다.
  4. 연결 드레이닝 제한 시간 초과 후 또는 백엔드 VM 또는 엔드포인트에 대한 연결이 이전의 활성(현재는 백업) 프록시 전용 서브넷의 프록시에서 시작되지 않았다고 확신하는 경우 다음을 수행할 수 있습니다.

    • 백엔드 VM 또는 엔드포인트에 적용되는 인그레스 허용 방화벽 규칙을 수정하여 이전의 활성(현재는 백업) 프록시 전용 서브넷의 기본 IP 범위가 포함되지 않도록 합니다.
    • 이전의 활성(현재는 백업) 프록시 전용 서브넷을 삭제하여 기본 IP 주소 범위에 사용된 서브넷의 IP 주소를 해제합니다.

요구사항 및 제한사항

다음 제약조건은 프록시 전용 서브넷에만 적용됩니다.

  • VPC 네트워크의 각 리전별로 1개의 활성 프록시 전용 서브넷과 1개의 프록시 전용 서브넷을 만들 수 있습니다.

  • 해당 리전 및 네트워크에 활성 프록시 전용 서브넷을 이미 만든 경우가 아니라면 백업 프록시 전용 서브넷을 만들 수 없습니다.

  • 서브넷을 업데이트하여 프록시 전용 서브넷 역할을 백업에서 활성으로 변경할 수 있습니다. 그러면 GCP가 이전의 활성 프록시 전용 서브넷을 백업으로 자동 변경합니다. 프록시 전용 서브넷의 역할을 업데이트하여 백업으로 명시적으로 설정할 수 있습니다.

  • 프록시 전용 서브넷의 연결을 드레이닝하는 동안(drainTimeoutSeconds)에는 프록시 전용 서브넷의 역할을 백업에서 활성으로 변경할 수 없습니다.

  • 지정된 리전 및 VPC 네트워크에서 첫 번째 내부 HTTP(S) 부하 분산기를 만들려면 먼저 해당 리전 및 네트워크에 활성 프록시 전용 서브넷이 있어야 합니다.

  • 프록시 전용 서브넷에 IP 주소가 부족하면 GCP에서 경고를 표시하지 않습니다.

예시

  1. 특정 리전만 전담하는 백업 프록시 전용 서브넷을 만듭니다.

    gcloud beta compute networks subnets create new-l7ibackend-subnet-us-west1 \
       --purpose INTERNAL_HTTPS_LOAD_BALANCER \
       --role BACKUP \
       --region us-west1 \
       --network default \
       --addresses 10.130.0.0/26
    
  2. 백엔드 방화벽을 업데이트하여 새 서브넷의 연결을 수락합니다.

    gcloud compute firewall-rules update l7-ilb-firewall \
       --source-ranges 10.129.0.0/26,10.130.0.0/26
    
  3. 새 서브넷을 업데이트하여 리전의 ACTIVE 프록시 전용 서브넷으로 설정하고 이전 서브넷이 드레이닝될 때까지 기다립니다.

    gcloud beta compute networks subnets update new-l7ilb-ip-range-us-west1 \
       --drain-timeout 1h --role ACTIVE
    

    IP 주소 범위를 즉시 드레이닝하려면 --drain-timeout0s로 설정합니다. 그러면 드레이닝 중인 서브넷에서 할당된 주소가 있는 프록시에 대한 모든 연결이 즉시 종료됩니다.

  4. list 또는 describe 명령어를 사용하여 드레이닝 상태를 모니터링합니다. 서브넷이 드레이닝될 때 서브넷의 상태는 DRAINING입니다.

    gcloud beta compute networks subnets list
    

    드레이닝이 완료될 때까지 기다립니다. 이전 프록시 전용 서브넷이 드레이닝될 때 서브넷의 상태는 READY입니다.

  5. 새 서브넷의 연결만 허용하도록 백엔드 방화벽 규칙을 업데이트합니다.

    gcloud compute firewall-rules update l7-ilb-firewall \
       --source-ranges 10.130.0.0/26
    
  6. 이전 서브넷을 삭제합니다.

    gcloud beta compute networks subnets delete l7ilb-ip-range-us-west1 \
       --region us-west1
    

프록시 전용 서브넷 삭제

프록시 전용 서브넷을 삭제하면 기본 IP 범위가 해제되므로 범위를 다른 용도로 사용할 수 있습니다. GCP는 프록시 전용 서브넷 삭제 요청을 받으면 다음 규칙을 적용합니다.

  • 동일한 리전 및 VPC 네트워크에 1개 이상의 내부 HTTP(S) 부하 분산기가 있으면 활성 프록시 전용 서브넷을 삭제할 수 없습니다.

  • 동일한 리전 및 VPC 네트워크에 백업 프록시 전용 서브넷이 있으면 활성 프록시 전용 서브넷을 삭제할 수 없습니다.

사실상 이러한 규칙에는 다음과 같은 효과가 있습니다.

  • 지정된 리전 및 VPC 네트워크에 내부 HTTP(S) 부하 분산기가 정의되어 있지 않으면 해당 리전의 프록시 전용 서브넷을 삭제할 수 있습니다. 백업 프록시 전용 서브넷이 있으면 먼저 삭제한 다음 활성 프록시 전용 서브넷을 삭제해야 합니다.

  • 지정된 리전 및 VPC 네트워크에 1개 이상의 내부 HTTP(S) 부하 분산기가 정의되어 있으면 활성 프록시 전용 서브넷을 삭제할 수 없습니다. 그러나 백업 프록시 전용 서브넷을 활성 역할로 승격할 수 있으며, 이때 이전의 활성 프록시 전용 서브넷은 백업 역할로 자동 강등됩니다. 연결이 드레이닝된 후 백업(이전의 활성) 프록시 전용 서브넷을 삭제할 수 있습니다.

자세한 내용은 VPC 네트워크 설명서에서 서브넷 삭제를 참조하세요.

다음 단계

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

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