리전 외부 애플리케이션 부하 분산기의 고가용성

이 페이지에서는 리전 외부 애플리케이션 부하 분산기를 사용하여 고가용성 배포를 구성하는 방법을 설명합니다. 고가용성을 확보하려면 애플리케이션의 트래픽을 가장 잘 지원하는 리전에 개별 리전 외부 애플리케이션 부하 분산기를 여러 개를 배포하세요. 이는 서로 다른 리전의 리전 외부 애플리케이션 부하 분산기가 서로 격리되어 있을 뿐만 아니라 동일한 리전에서 실행되는 전역 외부 애플리케이션 부하 분산기 또는 기존 애플리케이션 부하 분산기 인프라와도 격리되어 있기 때문에 작동합니다.

Cloud DNS 위치정보 라우팅 정책을 사용하여 여러 리전의 두 개 이상의 부하 분산기로 트래픽을 라우팅합니다. 이 정책은 클라이언트 요청의 출처에 따라 사용 가능한 가장 가까운 리전으로 트래픽을 라우팅합니다. 또한 Google Cloud에서 지역 서비스 중단을 감지하고 정상적인 부하 분산기로만 트래픽을 라우팅할 수 있도록 상태 점검을 사용하는 것이 좋습니다.

다음은 서로 다른 두 리전에 있는 두 개의 리전 외부 애플리케이션 부하 분산기를 보여주는 샘플 설정입니다.

두 개의 리전 외부 애플리케이션 부하 분산기를 통한 고가용성
두 개의 리전 외부 애플리케이션 부하 분산기를 사용한 고가용성(확대하려면 클릭)

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

  1. 상태 점검을 사용하여 지역별 오류 감지

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

    기타 참고사항:

    • 상태 점검을 만들 때 소스 리전을 정확히 세 개 지정해야 합니다. 전역 상태 점검만 소스 리전을 지정할 수 있습니다.
    • HTTP, HTTPS, TCP 상태 점검이 지원됩니다.
    • 상태 점검 프로브는 구성된 Google Cloud 소스 리전에서 약간의 거리에 있는 인터넷의 PoP(Point of Presence)에서 실제로 시작됩니다.
  2. 정상적인 부하 분산기로 트래픽 라우팅

    Google Cloud는 Cloud DNS 위치정보 라우팅 정책을 사용하여 트래픽을 부하 분산기로 유도합니다. 모든 부하 분산기가 정상이면 Cloud DNS는 클라이언트 요청의 출처와 지리적으로 가장 가까운 부하 분산기로 트래픽을 라우팅합니다.

    특정 리전의 부하 분산기에서 상태 점검에 실패하기 시작하면 트래픽이 다른 리전에서 사용 가능한 정상 부하 분산기로 라우팅됩니다.

  3. 모든 부하 분산기 사용으로 대체

    상태 점검이 다시 통과하기 시작하면 자동으로 장애 복구됩니다. 사용 가능한 모든 부하 분산기가 트래픽을 전송하므로 대체 중에 예상되는 다운타임은 없습니다.

리전 간 부하 분산 구성

고가용성을 지원하는 교차 리전 배포를 구성하려면 다음 단계를 따르세요.

  1. 애플리케이션의 트래픽을 가장 잘 지원한다고 판단되는 리전에 리전 외부 애플리케이션 부하 분산기를 만듭니다. 이러한 각 부하 분산기에는 동일한 트래픽 관리 및 보안 구성이 있어야 합니다.
  2. 상태 점검 및 DNS 라우팅 정책을 만들어 클라이언트 위치를 기반으로 트래픽을 부하 분산기로 전달하고 서비스 중단 시 비정상 부하 분산기에서 트래픽을 라우팅합니다.

여러 리전에 부하 분산기 만들기

중복 부하 분산 장치를 추가로 구성할 때는 다음 사항을 고려하세요.

  • 요청을 제공하는 부하 분산기에 관계없이 트래픽이 일관되게 처리되도록 모든 리전 외부 애플리케이션 부하 분산기를 유사한 기능으로 구성합니다. 예를 들어 모든 리전 외부 애플리케이션 부하 분산기에 동일한 유형의 SSL 인증서, 동일한 Google Cloud Armor 정책, 동일한 트래픽 관리 설정을 사용해야 합니다.

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

  • 애플리케이션의 트래픽을 가장 잘 지원한다고 판단되는 모든 리전에 리전 외부 애플리케이션 부하 분산기를 설정하는 것이 좋습니다.

  • 리전 외부 애플리케이션 부하 분산기는 프리미엄 및 표준 네트워크 서비스 등급을 모두 지원합니다. 지연 시간을 줄이려면 프리미엄 등급에서 리전 외부 애플리케이션 부하 분산기를 추가로 설정하는 것이 좋습니다.

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

Cloud DNS 및 상태 점검 구성

이 섹션에서는 Cloud DNSGoogle Cloud 상태 점검을 사용하여 Cloud Load Balancing 환경을 구성하여 중단을 감지하고 트래픽을 다른 리전의 부하 분산기로 라우팅하는 방법을 설명합니다.

다음 단계에 따라 필요한 상태 점검 및 라우팅 정책을 구성합니다.

  1. 기본 부하 분산기의 전달 규칙 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개. 소스 리전은 정확히 3개를 지정해야 합니다.
    • HEALTH_CHECK_INTERVAL: 한 프로버에서 실행한 한 프로브의 시작부터 같은 프로버에서 실행한 다음 프로브의 시작까지의 시간(단위: 초). 지원되는 최솟값은 30초입니다. 권장 값은 권장사항을 참고하세요.
    • HEALTHY_THRESHOLDUNHEALTHY_THRESHOLD: VM 인스턴스가 정상 또는 비정상으로 간주되려면 성공하거나 실패해야 하는 연속 프로브의 수. 둘 중 하나를 생략하면 Google Cloud에서는 기본 기준점 2를 사용합니다.
    • REQUEST_PATH: Google Cloud가 상태 점검 프로브 요청을 보내는 URL 경로. 생략하면 Google Cloud가 루트 경로 /로 프로브 요청을 보냅니다. 상태 점검 대상 엔드포인트가 비공개인 경우(외부 전달 규칙 IP 주소의 일반적인 경우는 아님) 이 경로를 /afhealthz로 설정할 수 있습니다.
  2. Cloud DNS에서 레코드 세트를 만들고 위치정보 라우팅 정책을 적용합니다.

    gcloud beta dns record-sets create DNS_RECORD_SET_NAME \
        --ttl=TIME_TO_LIVE \
        --type=RECORD_TYPE \
        --zone="MANAGED_ZONE_NAME" \
        --routing-policy-type="GEO" \
        --routing-policy-data="FORWARDING_RULE_NAME_A@REGION_A;FORWARDING_RULE_NAME_B@REGION_B[,;FORWARDING_RULE_NAME_C@REGION_C]" \
        --health-check=HEALTH_CHECK_NAME
    

    다음을 바꿉니다.

    • DNS_RECORD_SET_NAME: 추가할 레코드 모음의 DNS 또는 도메인 이름(예: test.example.com)
    • TIME_TO_LIVE: 레코드의 초 단위 TTL (수명). 권장 값은 DNS 고려사항을 참고하세요.
    • RECORD_TYPE: 레코드 유형(예: A)
    • MANAGED_ZONE_NAME: 레코드 모음을 관리하려는 관리형 영역의 이름(예: my-zone-name)
    • FORWARDING_RULE_NAME: 각 REGION의 부하 분산기 전달 규칙 이름
    • REGION: 각 부하 분산기가 배포된 리전

권장사항

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

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

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

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

    DNS TTL을 30~60초로 설정하는 것이 좋습니다. TTL이 높을수록 다운타임이 길어집니다. DNS가 다른 리전으로 전환된 후에도 인터넷의 클라이언트가 비정상적인 부하 분산기에 계속 액세스하기 때문입니다.

  • 일시적인 오류로 인해 트래픽의 불필요하고 갑작스러운 경로 변경을 방지하도록 상태 점검의 정상 및 비정상 기준 파라미터를 구성합니다. 기준점이 높을수록 트래픽이 다른 리전의 부하 분산기로 전환되는 데 걸리는 시간이 늘어납니다.