이 페이지에서는 외부 애플리케이션 부하 분산기의 장애 조치 작동 방식을 설명합니다. 장애 조치 구성에는 기본 부하 분산기와 백업 부하 분산기라는 두 가지 부하 분산기가 포함됩니다. 이 문서에서는 기본 부하 분산기를 장애 조치를 구성할 부하 분산기로 정의합니다. 백업 부하 분산기는 기본 부하 분산기에서 상태 점검에 실패하기 시작할 때 연결을 수신하는 부하 분산기입니다.
장애 조치 및 장애 복구는 트래픽을 부하 분산기와 주고받는 자동 프로세스입니다. Cloud DNS가 서비스 중단을 감지하고 기본 부하 분산기에서 백업 부하 분산기로 트래픽을 라우팅하는 프로세스를 failover라고 합니다. Cloud DNS가 이를 되돌려 트래픽을 기본 부하 분산기로 리디렉션하는 프로세스를 장애 복구라고 합니다.
장애 조치 작동 방식
외부 애플리케이션 부하 분산기의 전역에서 지역으로의 장애 조치는 트래픽을 장애 조치할 리전에 2개 이상의 리전 외부 애플리케이션 부하 분산기를 만들어 처리합니다. 리전 외부 애플리케이션 부하 분산기만 백업 부하 분산기로 사용할 수 있습니다. 리전 외부 애플리케이션 부하 분산기는 개별 Google Cloud 리전 내에서 자체적으로 포함될 뿐만 아니라 동일한 리전에서 실행되는 모든 전역 외부 애플리케이션 부하 분산기 또는 기존 애플리케이션 부하 분산기 인프라와도 격리됩니다.
리전 외부 애플리케이션 부하 분산기는 글로벌 외부 애플리케이션 부하 분산기의 장애 조치 부하 분산기로 가장 적합합니다. 두 부하 분산기 모두 Envoy 프록시를 기반으로 하며 매우 유사한 방식으로 트래픽을 처리하기 때문입니다. 이는 트래픽 처리 방식에 상당한 차이가 있는 기존 애플리케이션 부하 분산기와 대조됩니다.
요약하자면 다음과 같은 장애 조치 시나리오가 지원됩니다.
- 전역 외부 애플리케이션 부하 분산기에서 리전 외부 애플리케이션 부하 분산기로
- 리전 외부 애플리케이션 부하 분산기에서 리전 외부 애플리케이션 부하 분산기로
- 기존 애플리케이션 부하 분산기에서 리전 외부 애플리케이션 부하 분산기로
장애 조치 및 장애 복구 워크플로
다음 설정은 전역 외부 애플리케이션 부하 분산기에서 두 개의 지역 외부 애플리케이션 부하 분산기로의 장애 조치를 보여줍니다. 전역 부하 분산기가 백엔드를 배포한 각 리전에 하나씩 있습니다.
다음 섹션에서는 장애 조치 구성에 관여하는 다양한 구성요소가 포함된 일반적인 워크플로를 설명합니다.
기본 부하 분산기의 오류 감지
Google Cloud는 상태 점검을 사용하여 기본 외부 애플리케이션 부하 분산기가 정상적인지 감지합니다. 세 개의 소스 리전에서 프로브를 전송하도록 이러한 상태 점검을 구성합니다. 이러한 세 가지 소스 리전은 클라이언트가 부하 분산기에 액세스하는 리전을 대표해야 합니다. 예를 들어 전역 외부 애플리케이션 부하 분산기가 있고 대부분의 클라이언트 트래픽이 북미와 유럽에서 발생하는 경우 북미의 두 지역과 유럽의 한 지역에서 발생하는 프로브를 구성할 수 있습니다.
이러한 리전 중 2개 이상에서 발생한 상태 점검이 실패하면 백업 리전 외부 애플리케이션 부하 분산기로의 장애 조치가 트리거됩니다.
기타 참고사항:
- 상태 점검을 만들 때 소스 리전을 정확히 세 개 지정해야 합니다. 전역 상태 점검만 소스 리전을 지정할 수 있습니다.
- HTTP, HTTPS, TCP 상태 점검이 지원됩니다.
- 상태 점검 프로브는 구성된 Google Cloud 소스 리전에서 약간의 거리에 있는 인터넷의 PoP(Point of Presence)에서 실제로 시작됩니다.
트래픽을 백업 부하 분산기로 라우팅
기본 부하 분산기의 상태 점검이 실패하기 시작하면 Google Cloud는 Cloud DNS 장애 조치 라우팅 정책을 사용하여 백업 부하 분산기로 트래픽을 라우팅하는 방법을 결정합니다.
서비스 중단 시간 또는 트래픽이 기본 부하 분산기에서 백업 부하 분산기로 장애 조치되는 데 걸리는 시간은 DNS TTL 값, 상태 점검 간격, 상태 점검의 비정상 기준점에 따라 결정됩니다. 권장 설정은 권장사항을 참고하세요.
기본 부하 분산기로 장애 조치
상태 점검이 다시 통과하기 시작하면 기본 부하 분산기로 자동으로 장애 복구됩니다. 백업 부하 분산기와 기본 부하 분산기 모두 트래픽을 제공하므로 장애 복구 중에 예상되는 다운타임은 없습니다.
주기적으로 장애 조치 테스트
비즈니스 연속성 계획의 일환으로 주기적으로 장애 조치 워크플로를 테스트하는 것이 좋습니다. 기본 부하 분산기에서 백업 부하 분산기로의 트래픽 전환이 점진적일 때와 즉각적일 때 모두 테스트해야 합니다. 장애 조치가 작동하는지 확인한 후 장애 복구를 트리거하여 트래픽이 예상대로 기본 부하 분산기로 다시 라우팅되는지 확인합니다.
장애 조치 구성
장애 조치를 구성하려면 다음 단계를 따르세요.
- 기존 기본 부하 분산기 구성을 검토하고 기본 부하 분산기에서 사용하는 기능(예: 보안 기능, 트래픽 관리 및 라우팅 기능, CDN)을 백업 리전 외부 애플리케이션 부하 분산기에서 사용할 수 있는지 확인합니다. 유사한 기능을 사용할 수 없는 경우 이 부하 분산기는 장애 조치에 적합하지 않을 수 있습니다.
- 기본 부하 분산기를 최대한 많이 미러링하는 구성으로 백업 리전 외부 애플리케이션 부하 분산기를 만듭니다.
- 상태 점검 및 DNS 라우팅 정책을 만들어 장애를 감지하고 장애 조치 중에 트래픽을 기본 부하 분산기에서 백업 부하 분산기로 라우팅합니다.
기본 부하 분산기 구성 검토
시작하기 전에 백업 리전 외부 애플리케이션 부하 분산기가 현재 기본 부하 분산기에서 사용 중인 모든 기능을 지원하는지 확인하세요.
트래픽 중단을 방지하려면 다음 차이점을 검토하세요.
GKE 배치. GKE 사용자는 GKE 게이트웨이를 사용하여 배포된 부하 분산기가 GKE 인그레스 컨트롤러를 사용하여 배포된 부하 분산기보다 이 장애 조치 메커니즘과 더 호환된다는 점에 유의해야 합니다. GKE 게이트웨이는 전역 및 지역 외부 애플리케이션 부하 분산기의 구성을 모두 지원하기 때문입니다. 그러나 GKE 인그레스 컨트롤러는 기존 애플리케이션 부하 분산기만 지원합니다.
최상의 결과를 얻으려면 GKE Gateway를 사용하여 기본 및 백업 부하 분산기를 모두 배포하세요.
Cloud CDN. 리전 외부 애플리케이션 부하 분산기는 Cloud CDN을 지원하지 않습니다. 따라서 실패가 발생하면 Cloud CDN을 사용하는 모든 작업도 영향을 받습니다. 더 나은 중복을 위해 Cloud CDN의 대체 수단으로 작동할 수 있는 서드 파티 CDN 솔루션을 구성하는 것이 좋습니다.
Google Cloud Armor. 기본 부하 분산기에 Google Cloud Armor를 사용하는 경우 백업 리전 외부 애플리케이션 부하 분산기를 구성할 때도 동일한 Google Cloud Armor 기능을 구성해야 합니다. Google Cloud Armor에는 지역 범위와 전역 범위에서 사용할 수 있는 서로 다른 기능이 있습니다. 자세한 내용은 Google Cloud Armor 문서의 다음 섹션을 참고하세요.
SSL 인증서. 기본 부하 분산기와 백업 부하 분산기 모두에 공통 SSL 인증서를 사용하려면 기본 부하 분산기에서 사용 중인 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 프록시를 부하 분산기에 할당할 수 있습니다.
기본 IP 주소 범위에 하는 것과 동일한 방법으로(expand-ip-range 명령어 사용) 프록시 전용 서브넷을 확장할 수 없습니다. 대신 요구사항을 충족하는 백업 프록시 전용 서브넷을 만든 후 활성 역할로 승격해야 합니다.
프록시 전용 서브넷의 크기를 변경하는 방법을 알아보려면 프록시 전용 서브넷의 크기 또는 IP 주소 범위 변경을 참고하세요.
기본 및 백업 부하 분산기 간에 백엔드 공유
완전한 인프라 중복을 달성하려면 부하 분산기 수준과 백엔드 수준 모두에서 중복을 도입해야 합니다. 즉, 기본 부하 분산기와 중복되지 않는 백엔드(인스턴스 그룹 또는 네트워크 엔드포인트 그룹)를 사용하여 백업 리전 외부 애플리케이션 부하 분산기를 구성해야 합니다.
하지만 기본 부하 분산기와 보조 부하 분산기 간에 백엔드 인스턴스 그룹을 공유하려고 하며 인스턴스 그룹에 자동 확장이 사용 설정된 경우 적절한 장애 조치가 발생하도록 하려면 다음 요구사항을 충족해야 합니다.
- 자동 확장 처리는 여러 신호로 설정해야 합니다. 인스턴스 그룹에는 CPU 확장 신호와 부하 분산기 사용률 신호를 함께 사용하는 것이 좋습니다.
- 전역 및 지역 백엔드 서비스 모두
UTILIZATION분산 모드만 사용해야 합니다. 장애 조치 프로세스 중에 인스턴스가 전역 및 리전 부하 분산기에서 트래픽을 두 번 수신할 수 있으므로RATE분산 모드를 사용하지 않는 것이 좋습니다. - 트래픽이 전역 부하 분산기에서 리전 부하 분산기로 전환되는 다운타임 중에 자동 확장 처리가 그룹을 조기 축소하지 않도록 수평 축소 제어를 구성해야 합니다. 이 다운타임은 DNS TTL과 구성된 상태 점검 간격의 합계만큼 길 수 있습니다.
자동 확장을 올바르게 설정하지 않으면 전역 부하 분산기의 트래픽 손실로 인해 인스턴스 그룹이 급격히 축소되어 장애 조치 중에 보조 서비스 중단이 발생할 수 있습니다.
Cloud DNS 및 상태 점검 구성
이 섹션에서는 Cloud DNS 및 Google Cloud 상태 점검을 사용하여 Cloud Load Balancing 환경을 구성하여 중단을 감지하고 트래픽을 백업 부하 분산기로 라우팅하는 방법을 설명합니다.
다음 단계에 따라 필요한 상태 점검 및 라우팅 정책을 구성합니다.
기본 부하 분산기의 전달 규칙 IP 주소에 대한 상태 점검을 만듭니다.
gcloud beta 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 리전. 소스 리전은 정확히 3개를 지정해야 합니다.HEALTH_CHECK_INTERVAL: 한 프로버에서 실행한 한 프로브의 시작부터 같은 프로버에서 실행한 다음 프로브의 시작까지의 시간(단위: 초). 지원되는 최소 값은 30초입니다. 권장 값은 권장사항을 참고하세요.HEALTHY_THRESHOLD및UNHEALTHY_THRESHOLD: VM 인스턴스가 정상 또는 비정상으로 간주되려면 성공하거나 실패해야 하는 연속 프로브의 수. 둘 중 하나를 생략하면 Google Cloud에서는 기본 기준점 2를 사용합니다.REQUEST_PATH: Google Cloud가 상태 점검 프로브 요청을 보내는 URL 경로. 생략하면 Google Cloud에서 프로브 요청을 루트 경로 /로 전송합니다. 상태를 확인하는 엔드포인트가 비공개인 경우(외부 전달 규칙 IP 주소의 일반적인 경우는 아님) 이 경로를/afhealthz로 설정할 수 있습니다.
Cloud DNS에서 Cloud DNS 레코드 세트를 만들고 여기에 라우팅 정책을 적용합니다. 도메인 이름을 기본 부하 분산기의 전달 규칙 IP 주소로 확인하거나 상태 점검 실패 시 백업 부하 분산기의 전달 규칙 IP 주소 중 하나로 확인하도록 라우팅 정책을 구성해야 합니다.
gcloud beta 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입니다.