외부 애플리케이션 부하 분산기의 장애 조치

이 페이지에서는 외부 애플리케이션 부하 분산기의 장애 조치 작동 방식을 설명합니다. 장애 조치 구성에는 기본 부하 분산기와 백업 부하 분산기라는 두 가지 부하 분산기가 포함됩니다. 이 논의의 목적을 위해 기본 부하 분산기 는 장애 조치를 구성하려는 부하 분산기입니다. 백업 부하 분산기는 기본 부하 분산기에서 상태 점검에 실패하기 시작할 때 연결을 수신하는 부하 분산기입니다.

장애 조치 및 장애 복구는 트래픽을 부하 분산기로 라우팅하고 부하 분산기에서 라우팅하는 자동 프로세스입니다. Cloud DNS가 서비스 중단을 감지하고 트래픽을 기본 부하 분산기에서 백업 부하 분산기로 라우팅하는 프로세스를 장애 조치 라고 합니다. Cloud DNS가 이를 되돌려 트래픽을 기본 부하 분산기로 리디렉션하는 프로세스를 장애 복구라고 합니다.

장애 조치 작동 방식

외부 애플리케이션 부하 분산기의 전역에서 지역으로의 장애 조치는 트래픽을 장애 조치할 리전에 2개 이상의 리전 외부 애플리케이션 부하 분산기를 만들어 처리합니다. 리전 외부 애플리케이션 부하 분산기만 백업 부하 분산기로 사용할 수 있습니다. 리전 외부 애플리케이션 부하 분산기는 개별Google Cloud 리전 내에 자체 포함되어 있을 뿐만 아니라 동일한 리전에서 실행되는 모든 전역 외부 애플리케이션 부하 분산기 또는 기본 애플리케이션 부하 분산기 인프라와도 격리됩니다.

리전 외부 애플리케이션 부하 분산기는 글로벌 외부 애플리케이션 부하 분산기의 장애 조치 부하 분산기로 가장 적합합니다. 두 부하 분산기 모두 Envoy 프록시를 기반으로 하며 매우 유사한 방식으로 트래픽을 처리하기 때문입니다. 이는 트래픽 처리 방식에 상당한 차이가 있는 기본 애플리케이션 부하 분산기와 대조됩니다.

요약하자면 다음과 같은 장애 조치 시나리오가 지원됩니다.

• 전역 외부 애플리케이션 부하 분산기에서 리전 외부 애플리케이션 부하 분산기로 장애 조치
• 리전 외부 애플리케이션 부하 분산기에서 리전 외부 애플리케이션 부하 분산기로 장애 조치
• 기본 애플리케이션 부하 분산기에서 리전 외부 애플리케이션 부하 분산기로 장애 조치

장애 조치 및 장애 복구 워크플로

다음 설정은 전역 외부 애플리케이션 부하 분산기에서 전역 부하 분산기가 백엔드를 배포한 각 리전에 하나씩 있는 리전 외부 애플리케이션 부하 분산기 2개로의 장애 조치를 보여줍니다.

다음 섹션에서는 장애 조치 구성과 관련된 다양한 구성요소가 포함된 일반적인 워크플로를 설명합니다.

1. 기본 부하 분산기의 오류 감지

   Google Cloud 는 상태 점검을 사용하여 기본 외부 애플리케이션 부하 분산기가 정상 상태인지 감지합니다. 세 개의 소스 리전에서 프로브를 전송하도록 상태 점검을 구성합니다. 이 세 개의 소스 리전은 클라이언트가 부하 분산기에 액세스하는 리전을 나타내야 합니다. 예를 들어 전역 외부 애플리케이션 부하 분산기가 하나 있고 대부분의 클라이언트 트래픽이 북미와 유럽에서 발생하는 경우 북미의 두 리전과 유럽의 한 리전에서 시작되는 프로브를 구성할 수 있습니다.

   이러한 리전 중 2개 이상에서 발생한 상태 점검이 실패하면 백업 리전 외부 애플리케이션 부하 분산기로의 장애 조치가 트리거됩니다.

   기타 참고사항:

   • 상태 점검을 만들 때 소스 리전을 정확히 세 개 지정해야 합니다. 전역 상태 점검만 소스 리전을 지정할 수 있습니다.
   • HTTP, HTTPS, TCP 상태 점검이 지원됩니다.
   • 상태 점검 프로브는 구성된 Google Cloud소스 리전에서 약간의 거리에 있는 인터넷의 접속 지점(PoP)에서 실제로 시작됩니다.

2. 백업 부하 분산기로 트래픽 라우팅

   기본 부하 분산기의 상태 점검이 실패하기 시작하면 Google Cloud는 Cloud DNS 장애 조치 라우팅 정책을 사용하여 트래픽을 백업 부하 분산기로 라우팅하는 방법을 결정합니다.

   서비스 중단 기간 또는 트래픽이 기본 부하 분산기에서 백업 부하 분산기로 장애 조치되는 데 걸리는 시간은 DNS TTL 값, 상태 점검 간격, 상태 점검의 비정상 기준점에 따라 결정됩니다. 권장 설정은 권장사항을 참조하세요.

3. 기본 부하 분산기로 장애 복구

   상태 점검이 다시 통과하기 시작하면 기본 부하 분산기로 자동으로 장애 복구됩니다. 백업 부하 분산기와 기본 부하 분산기 모두 트래픽을 제공하므로 장애 복구 중에 예상되는 다운타임은 없습니다.

4. 주기적으로 장애 조치 테스트

   비즈니스 연속성 계획의 일환으로 주기적으로 장애 조치 워크플로를 테스트하는 것이 좋습니다. 기본 부하 분산기에서 백업 부하 분산기로의 트래픽의 점진적 이동과 즉각적인 이동을 모두 테스트해야 합니다. 장애 조치가 작동하는지 확인한 후 장애 복구를 트리거하여 트래픽이 예상대로 기본 부하 분산기로 다시 라우팅되는지 확인합니다.

장애 조치 구성

장애 조치를 구성하려면 다음 단계를 수행하세요.

1. 기존 기본 부하 분산기 구성을 검토하고 기본 부하 분산기에서 사용하는 기능(예: 보안 기능, 트래픽 관리 및 라우팅 기능, CDN)을 백업 리전 외부 애플리케이션 부하 분산기에서 사용할 수 있는지 확인합니다. 유사한 기능을 사용할 수 없는 경우 이 부하 분산기는 장애 조치에 적합하지 않을 수 있습니다.
2. 백업 리전 외부 애플리케이션 부하 분산기 만들기 기본 부하 분산기를 최대한 미러링하는 구성으로
3. 상태 점검 및 DNS 라우팅 정책을 만들어 서비스 중단을 감지하고 장애 조치 중에 트래픽을 기본 부하 분산기에서 백업 부하 분산기로 라우팅합니다.

기본 부하 분산기 구성 검토

시작하기 전에 백업 리전 외부 애플리케이션 부하 분산기가 현재 기본 부하 분산기에서 사용되는 모든 기능을 지원하는지 확인합니다.

트래픽 중단을 방지하려면 다음 차이점을 검토하세요.

• GKE 배치. GKE 사용자는 GKE 게이트웨이를 사용하여 배포된 부하 분산기가 GKE 인그레스 컨트롤러를 사용하여 배포된 부하 분산기보다 이 장애 조치 메커니즘과 더 호환된다는 점에 유의해야 합니다. 이는 GKE 게이트웨이가 전역 및 리전 외부 애플리케이션 부하 분산기 모두의 구성을 지원하기 때문입니다. 그러나 GKE 인그레스 컨트롤러는 기본 애플리케이션 부하 분산기만 지원합니다.

  최상의 결과를 얻으려면 GKE 게이트웨이를 사용하여 기본 부하 분산기와 백업 부하 분산기를 모두 배포하세요.

• Cloud CDN. 리전 외부 애플리케이션 부하 분산기는 Cloud CDN을 지원하지 않습니다. 따라서 장애가 발생하면 Cloud CDN을 사용하는 모든 작업도 영향을 받습니다. 더 나은 중복성을 위해 Cloud CDN의 대체 수단으로 작동할 수 있는 서드 파티 CDN 솔루션을 구성하는 것이 좋습니다.

• Cloud Armor. 기본 부하 분산기에 Cloud Armor를 사용하는 경우 백업 리전 외부 애플리케이션 부하 분산기를 구성할 때도 동일한 Cloud Armor 기능을 구성해야 합니다. Cloud Armor에는 리전 범위와 전역 범위에서 각각 사용할 수 있는 다른 기능이 있습니다. 자세한 내용은 Cloud Armor 문서의 다음 섹션을 참조하세요.

  • 리전 Cloud Armor 보안 정책
  • 전역 Cloud Armor 보안 정책

• SSL 인증서. 기본 부하 분산기와 백업 부하 분산기 모두에 공통 SSL 인증서를 사용하려면 기본 부하 분산기에서 사용되는 SSL 인증서 유형이 백업 리전 외부 애플리케이션 부하 분산기와 호환되는지 확인합니다. 전역, 리전, 기본 부하 분산기에서 사용할 수 있는 SSL 인증서의 차이점을 검토하세요. 자세한 내용은 다음 섹션을 참고하세요.

  • Compute Engine SSL 인증서
  • 인증서 관리자 SSL 인증서

• 백엔드 버킷. 리전 외부 애플리케이션 부하 분산기는 Cloud Storage 버킷을 백엔드로 지원하지 않습니다. 백엔드 버킷을 사용하여 부하 분산기의 장애 조치를 설정할 수 없습니다.

백업 부하 분산기 구성

백업 부하 분산기는 장애 발생 시 트래픽을 리디렉션하려는 리전에 구성하는 리전 외부 애플리케이션 부하 분산기입니다.

백업 부하 분산기를 구성할 때는 다음 고려사항에 유의하세요.

• 두 배포 모두에서 트래픽이 유사하게 처리되도록 백업 리전 외부 애플리케이션 부하 분산기의 기능을 기본 부하 분산기와 최대한 유사하게 구성해야 합니다.

  • 전역 외부 애플리케이션 부하 분산기. 리전 외부 애플리케이션 부하 분산기는 몇 가지 예외를 제외하고 전역 외부 애플리케이션 부하 분산기와 대부분 동일한 기능을 지원합니다. 또한 리전 부하 분산기는 전역 부하 분산기와 동일한 고급 트래픽 관리 기능을 지원하므로 기본 부하 분산기와 백업 부하 분산기 간의 등가성을 더 쉽게 달성할 수 있습니다.

  • 기존 애플리케이션 부하 분산기. 기존 애플리케이션 부하 분산기를 사용하면 기본 부하 분산기와 백업 부하 분산기 간의 기능 동등성을 달성하기가 더 어렵습니다. 리전 외부 애플리케이션 부하 분산기는 트래픽을 다르게 처리하는 Envoy 기반 부하 분산기이기 때문입니다. 프로덕션에 배포하기 전에 장애 조치 및 장애 복구를 철저히 테스트해야 합니다.

  리전, 전역, 기본 애플리케이션 부하 분산기의 구체적인 기능을 확인하려면 부하 분산기 기능 비교 페이지를 참조하세요.

  Terraform과 같은 자동화 프레임워크를 사용하여 기본 배포와 백업 배포에서 모두 부하 분산기 구성의 일관성을 달성하고 유지하는 것이 좋습니다.

• 백엔드가 있는 모든 리전에 백업 리전 외부 애플리케이션 부하 분산기를 설정하는 것이 좋습니다. 예를 들어 5개 리전에 인스턴스 그룹이 있는 전역 배포에서 3개 리전의 지역 부하 분산기만 백업하는 배포로 장애 조치하면 나머지 2개 리전의 백엔드 서비스가 유휴 상태인 동안 3개 리전의 백엔드 서비스가 오버로드될 수 있습니다.

  또한 기본 전역 부하 분산기에서 이러한 백업 리전 부하 분산기로 장애 조치 트래픽을 다시 라우팅할 때 가중치가 적용된 라운드 로빈 정책을 사용하도록 Cloud DNS를 구성하는 것이 좋습니다. 여러 리전에 있는 백엔드 인스턴스 그룹의 최대 크기를 고려하여 각 백업 부하 분산기에 가중치를 할당합니다.

• 리전 외부 애플리케이션 부하 분산기는 프리미엄 및 표준 네트워크 서비스 등급을 모두 지원합니다. 장애 조치 중에 지연 시간이 주요 문제가 아닌 경우 표준 등급을 사용하여 백업 리전 외부 애플리케이션 부하 분산기를 설정하는 것이 좋습니다. 표준 등급 인프라를 사용하면 전역 외부 애플리케이션 부하 분산기에서 사용하는 프리미엄 등급 인프라와 추가로 격리할 수 있습니다.

• 기본 부하 분산기와 백업 부하 분산기 모두에 동일한 백엔드를 사용하려면 백엔드가 있는 리전에 백업 리전 외부 애플리케이션 부하 분산기를 만듭니다. 백엔드 인스턴스 그룹에 자동 확장을 사용 설정한 경우 배포 간에 백엔드를 공유하기 위한 요구사항 백엔드를 충족해야 합니다.

• 필요한 경우 리전 외부 애플리케이션 부하 분산기에 Envoy 프록시를 추가로 예약하여 장애 조치 이벤트가 발생할 때 추가 트래픽이 동일한 리전의 다른 부하 분산기 배포를 중단하지 않도록 합니다. 자세한 내용은 프록시 전용 서브넷 용량 추가 예약을 참조하세요.

리전 외부 애플리케이션 부하 분산기를 구성하는 방법은 VM 인스턴스 그룹 백엔드가 있는 리전 외부 애플리케이션 부하 분산기 설정을 참조하세요.

프록시 전용 서브넷 용량 추가 예약

리전 및 VPC 네트워크의 모든 리전 Envoy 기반 부하 분산기는 동일한 Envoy 프록시 풀을 공유합니다. 장애 조치 이벤트 시 백업 리전 외부 애플리케이션 부하 분산기에서 기본 부하 분산기의 장애 조치 트래픽을 처리하기 위해 프록시 사용량이 증가합니다. 백업 부하 분산기에서 항상 용량을 사용할 수 있도록 프록시 전용 서브넷의 크기를 검토하는 것이 좋습니다. 특정 리전의 트래픽을 처리하는 데 필요한 예상 프록시 수를 계산하고 필요한 경우 용량을 늘리는 것이 좋습니다. 이는 장애 조치 이벤트로 인해 동일한 리전 및 네트워크의 다른 리전 Envoy 기반 부하 분산기가 중단되지 않도록 하는 데에도 도움이 됩니다.

일반적으로 리전 외부 애플리케이션 부하 분산기 프록시가 관리할 수 있는 최대 항목은 다음과 같습니다.

• 초당 600개(HTTP) 또는 150개(HTTPS)의 새 연결
• 3,000개의 활성 연결
• 초당 1,400개 요청

DNS 정책을 사용하여 다양한 리전의 여러 백업 부하 분산기 간에 트래픽을 분할하는 경우 리전 및 네트워크별 프록시 요구사항을 추정할 때 이를 고려해야 합니다. 프록시 전용 서브넷이 클수록Google Cloud 에서 필요에 따라 더 많은 수의 Envoy 프록시를 부하 분산기에 할당할 수 있습니다.

기본 주소 범위에 하는 것과 동일한 방법으로(expand-ip-range 명령어 사용) 프록시 전용 서브넷을 확장할 수 없습니다. 대신 요구사항을 충족하는 백업 프록시 전용 서브넷을 만든 후 활성 역할로 승격해야 합니다.

프록시 전용 서브넷의 크기를 변경하는 방법을 알아보려면 프록시 전용 서브넷의 크기 또는 IP 주소 범위 변경을 참고하세요.

기본 부하 분산기와 백업 부하 분산기 간에 백엔드 공유

완전한 인프라 중복성을 달성하려면 부하 분산기 수준과 백엔드 수준 모두에서 중복을 도입해야 합니다. 즉, 기본 부하 분산기와 중복되지 않는 백엔드(인스턴스 그룹 또는 네트워크 엔드포인트 그룹)를 사용하여 백업 리전 외부 애플리케이션 부하 분산기를 구성해야 합니다.

하지만 기본 부하 분산기와 보조 부하 분산기 간에 백엔드 인스턴스 그룹을 공유하고 인스턴스 그룹에 자동 확장도 사용 설정된 경우 적절한 장애 조치가 발생하도록 하려면 다음 요구사항을 충족해야 합니다.

• 자동 확장 처리는 CPU 기반 확장으로만 설정해야 합니다. 부하 분산기의 사용률 기반 확장 방법은 지원되지 않습니다.
• 전역 및 리전 백엔드 서비스 모두 UTILIZATION 분산 모드만 사용해야 합니다. 장애 조치 프로세스 중에 인스턴스가 전역 및 리전 부하 분산기 모두에서 2배의 트래픽을 수신할 수 있으므로 RATE 분산 모드를 사용하는 것은 권장되지 않습니다.
• 트래픽이 전역 부하 분산기에서 리전 부하 분산기로 전환되는 다운타임 중에 자동 확장 처리가 그룹을 조기 축소하지 않도록 수평 축소 설정을 구성해야 합니다. 이 다운타임은 구성된 DNS TTL과 상태 점검 간격의 합계만큼 높을 수 있습니다.

자동 확장을 올바르게 설정하지 못하면 장애 조치 중에 보조 서비스 중단이 발생할 수 있습니다. 전역 부하 분산기의 트래픽 손실로 인해 인스턴스 그룹이 빠르게 축소되기 때문입니다.

Cloud DNS 및 상태 점검 구성

이 섹션에서는 Cloud DNS 및 Google Cloud 상태 점검을 사용하여 서비스 중단을 감지하고 백업 부하 분산기로 트래픽을 라우팅하도록 Cloud Load Balancing 환경을 구성하는 방법을 설명합니다.

다음 단계를 수행하여 필수 상태 점검 및 라우팅 정책을 구성합니다.

1. 기본 부하 분산기의 전달 규칙 IP 주소에 대한 상태 점검을 만듭니다.

   gcloud compute health-checks create http HEALTH_CHECK_NAME \
       --global \
       --source-regions=SOURCE_REGION_1,SOURCE_REGION_2,SOURCE_REGION_3 \
       --use-serving-port \
       --check-interval=HEALTH_CHECK_INTERVAL \
       --healthy-threshold=HEALTHY_THRESHOLD \
       --unhealthy-threshold=UNHEALTHY_THRESHOLD \
       --request-path=REQUEST_PATH
   

   다음을 바꿉니다.

   • HEALTH_CHECK_NAME: 상태 점검의 이름
   • SOURCE_REGION: 상태 점검이 수행되는 세 개의 Google Cloud리전. 소스 리전을 정확히 세 개 지정해야 합니다.
   • HEALTH_CHECK_INTERVAL: 한 프로버에서 실행한 한 프로브의 시작부터 같은 프로버에서 실행한 다음 프로브의 시작까지의 시간(단위: 초). 지원되는 최솟값은 30초입니다. 권장 값은 권장사항을 참조하세요.
   • HEALTHY_THRESHOLD 및 UNHEALTHY_THRESHOLD: VM 인스턴스가 정상 또는 비정상으로 간주되려면 성공하거나 실패해야 하는 연속 프로브의 수. 둘 중 하나를 생략하면 Google Cloud 는 기본 기준점 2를 사용합니다.
   • REQUEST_PATH:Google Cloud 가 상태 점검 프로브 요청을 보내는 URL 경로. 생략하면 Google Cloud 는 프로브 요청을 루트 경로 /로 전송합니다. 상태를 점검하는 엔드포인트가 비공개인 경우(외부 전달 규칙 IP 주소에서는 일반적인 경우가 아님) 이 경로를 /afhealthz로 설정할 수 있습니다.

2. Cloud DNS에서 Cloud DNS 레코드 세트를 만들고 라우팅 정책을 적용합니다. 도메인 이름을 기본 부하 분산기의 전달 규칙 IP 주소로 확인하거나 상태 점검 실패 시 백업 부하 분산기의 전달 규칙 IP 주소 중 하나로 확인하도록 라우팅 정책을 구성해야 합니다.

   gcloud dns record-sets create DNS_RECORD_SET_NAME \
       --ttl=TIME_TO_LIVE \
       --type=RECORD_TYPE \
       --zone="MANAGED_ZONE_NAME" \
       --routing-policy-type=FAILOVER \
       --routing-policy-primary-data=PRIMARY_LOAD_BALANCER_FORWARDING_RULE \
       --routing-policy-backup-data_type=GEO \
       --routing-policy-backup-data="BACKUP_REGION_1=BACKUP_LOAD_BALANCER_1_IP_ADDRESS[;BACKUP_REGION_2=BACKUP_LOAD_BALANCER_2_IP_ADDRESS;BACKUP_REGION_3=BACKUP_LOAD_BALANCER_3_IP_ADDRESS]" \
       --health-check=HEALTH_CHECK_NAME \
       --backup-data-trickle-ratio=BACKUP_DATA_TRICKLE_RATIO
   

   다음을 바꿉니다.

   • DNS_RECORD_SET_NAME: 추가할 레코드 모음의 DNS 또는 도메인 이름(예: test.example.com)
   • TIME_TO_LIVE: 레코드 세트의 초 단위 TTL(수명). 권장 값은 권장사항을 참조하세요.
   • RECORD_TYPE: 레코드 유형(예: A)
   • MANAGED_ZONE_NAME: 레코드 모음을 관리하려는 관리형 영역의 이름(예: my-zone-name)
   • PRIMARY_LOAD_BALANCER_FORWARDING_RULE: 기본 부하 분산기의 전달 규칙 이름
   • BACKUP_REGION: 백업 부하 분산기가 배포되는 리전
   • BACKUP_LOAD_BALANCER_IP_ADDRESS: 각 리전에 해당하는 백업 부하 분산기의 전달 규칙 IP 주소
   • BACKUP_DATA_TRICKLE_RATIO: 기본 부하 분산기가 정상인 경우에도 백업 부하 분산기로 보낼 트래픽의 비율. 비율은 0~1 사이여야 합니다(예: 0.1). 기본값은 0으로 설정됩니다.

권장사항

다음은 Cloud DNS 레코드 및 상태 점검을 구성할 때 유의해야 할 몇 가지 권장사항입니다.

• 트래픽이 기본 부하 분산기에서 백업 부하 분산기로 장애 조치되는 데 걸리는 시간(즉, 서비스 중단 시간)은 DNS TTL 값, 상태 점검 간격, 상태 점검의 비정상 기준점 파라미터에 따라 다릅니다.

  Google의 Cloud DNS를 사용하는 경우 다음 수식을 사용하여 이 기간의 상한값을 계산할 수 있습니다.

  Duration of outage = DNS TTL + Health Check Interval * Unhealthy Threshold
  

  장애 조치 구성의 경우 DNS TTL을 30~60초로 설정하는 것이 좋습니다. TTL이 높을수록 다운타임이 길어집니다. DNS가 백업 리전 외부 애플리케이션 부하 분산기로 장애 조치한 후에도 인터넷의 클라이언트가 계속해서 기본 외부 애플리케이션 부하 분산기에 액세스하기 때문입니다.

• 일시적인 오류로 인한 불필요한 장애 조치를 방지하도록 상태 점검에서 정상 및 비정상 기준 파라미터를 구성합니다. 기준점이 높을수록 트래픽이 백업 부하 분산기로 장애 조치되는 데 걸리는 시간이 늘어납니다.

• 장애 조치 설정이 예상대로 작동하도록 기본 부하 분산기가 정상 상태일 때도 항상 백업 부하 분산기로 적은 비율의 트래픽을 전송하도록 DNS 라우팅 정책을 구성할 수 있습니다. DNS 레코드 세트를 만들 때 --backup-data-trickle-ratio 파라미터를 사용하여 이 작업을 실행할 수 있습니다.

  백업으로 전송되는 트래픽 비율을 0에서 1 사이의 비율로 구성할 수 있습니다. Cloud DNS를 사용하면 백업 VIP 주소로 트래픽의 100%를 전송하여 장애 조치를 수동으로 트리거할 수 있지만 일반적인 값은 0.1입니다.