유동 IP 주소를 위한 권장사항

이 솔루션에서는 온프레미스 네트워크 환경에서 애플리케이션을 Compute Engine으로 마이그레이션할 때의 유동 IP 주소 사용 옵션을 설명합니다. '공유' 또는 '가상' IP 주소라고도 하는 유동 IP 주소는 온프레미스 네트워크 환경의 가용성을 높이기 위해 자주 사용됩니다. 유동 IP 주소를 사용하면 동일하게 구성된 다수의 실제 또는 가상 서버 간에 IP 주소를 전달하여 프로덕션 소프트웨어의 장애 조치 또는 업그레이드를 허용할 수 있습니다. 그러나 Compute Engine 환경에서는 유동 IP 주소를 직접 구현할 수 없습니다.

온프레미스 환경의 유동 IP 주소

유동 IP 주소는 일반적으로 온프레미스 환경에서 사용됩니다. 다음 목록은 유동 IP 주소의 몇 가지 사용 사례를 요약한 것입니다.

  • 방화벽이나 부하 분산기와 같은 고가용성의 물리적 어플라이언스는 종종 장애 조치에 유동 IP 주소를 사용합니다.
  • 고가용성이 필요한 서버는 일반적으로 유동 IP 주소를 사용합니다. 예를 들어 Microsoft SQL 서버와 같은 마스터-슬레이브 관계형 데이터베이스는 Always On 가용성 그룹을 사용합니다.
  • 부하 분산기 또는 역방향 프록시를 구현하는 Linux 환경은 IPVS, HAProxy, NGINX와 같은 유동 IP 주소를 사용합니다. 노드 장애를 감지하고 인스턴스 간에 유동 IP 주소를 이동시키기 위해 이러한 환경은 하트비트, 페이스메이커, 연결 유지와 같은 데몬을 사용합니다.
  • 유동 IP 주소는 Windows Server 장애 조치 클러스터링을 사용하여 Windows 서비스에서 고가용성을 제공합니다.

온프레미스 환경에서 유동 IP 주소를 구현하는 방법은 여러 가지입니다. 모든 경우에 IP 주소를 공유하는 서버는 하트비트 메커니즘을 통해 서로의 상태를 공유해야 합니다. 이 메커니즘을 통해 서버는 서로의 상태를 통신하여 알 수 있습니다. 또한 연결된 서버가 실패한 후에 보조 서버가 유동 IP 주소를 인계할 수 있습니다. 이러한 스키마는 가상 라우터 중복 프로토콜(VRRP)을 사용하여 자주 구현되지만 다른 유사한 메커니즘을 사용할 수도 있습니다.

IP 장애 조치가 시작되면 유동 IP 주소를 인계하는 서버가 해당 네트워크 인터페이스에 주소를 추가합니다. 이 서버는 Gratuitous 주소 확인 프로토콜(ARP) 프레임을 전송하고 Layer 2를 사용하는 다른 기기로 이 인계를 알립니다. 다른 접근 방식으로, 최단 경로 우선 개방(OSPF)과 같은 라우팅 프로토콜이 IP 주소를 업스트림 Layer 3 라우터에 알리기도 합니다.

다음 다이어그램은 온프레미스 환경의 일반적인 설정을 보여줍니다.

일반적인 온프레미스 환경

Windows 네트워크 부하 분산 또는 직접 서버 응답이 있는 Linux 부하 분산(예: IP 가상 서버(IPVS))과 같은 온프레미스 부하 분산 솔루션으로 약간 다른 설정을 사용합니다. 이 경우 서비스는 Gratuitous ARP 프레임을 보내지만(단, 다른 서버의 MAC 주소를 Gratuitous ARP 소스로 보냄) 기본적으로 ARP 프레임을 위장하고 다른 서버의 소스 주소를 인계합니다. 이러한 종류의 설정은 이 솔루션의 범위를 벗어납니다. 대부분의 경우 부하 분산으로 마이그레이션하는 것이 바람직한 마이그레이션 경로입니다.

유동 IP 주소를 Compute Engine으로 마이그레이션할 때의 문제

Compute Engine은 Virtual Private Cloud(VPC) 네트워크에서 가상화된 네트워크 스택을 사용하기 때문에 일반적인 구현 메커니즘은 예외적으로 작동하지 않습니다. 예를 들어, VPC 네트워크는 구성된 라우팅 토폴로지를 기반으로 ARP 요청을 처리하고 Gratuitous ARP 프레임을 무시합니다. 또한 OSPF 또는 BGP(Border Gateway Protocol)와 같은 표준 라우팅 프로토콜을 사용하여 VPC 네트워크 라우팅 테이블을 직접 수정하는 것은 불가능합니다.

오버레이 네트워크를 사용하면 ARP 요청을 통해 전체 Layer 2 통신 및 IP 인계를 가능하게 하는 구성을 만들 수 있습니다. 그러나 오버레이 네트워크를 설정하는 것은 복잡하고 Compute Engine 네트워크 리소스를 관리하기 어렵게 만듭니다. 이러한 접근 방식도 이 솔루션의 범위를 벗어납니다. 대신, 이 솔루션은 기본 Compute Engine 네트워킹 환경에서 장애 조치 시나리오를 구현하기 위한 대체 접근 방식을 제공합니다.

이 솔루션에서는 나와 있는 사용 사례의 대부분을 Compute Engine으로 마이그레이션하는 방법을 설명합니다.

보다 구체적인 사용 사례에 대한 단계별 가이드가 이미 있습니다.

마이그레이션 사용 사례 예시

이 솔루션은 온프레미스 유동 IP 주소에서 Compute Engine으로 이동할 때의 네 가지 마이그레이션 옵션을 설명합니다.

이 사용 사례에는 복잡한 Layer 7 헤더 일치 및 교체에 따라 트래픽을 다른 백엔드로 라우팅하는 2개의 내부 HAProxy 서버 마이그레이션이 포함됩니다. 복잡한 규칙이 있기 때문에 이 서버 집합은 내부 TCP/UDP 부하 분산 또는 HTTP 부하 분산으로 교체할 수 없습니다. 다음 그림은 이 사용 사례의 개요를 보여줍니다.

이전 사용 사례

HAProxy 서버는 별도의 교차 연결을 사용하여 가용성을 확인하고 두 서버 간에 유동 IP 주소를 전달하는 연결 유지된 소프트웨어를 온프레미스 환경에서 사용합니다.

이 사용 사례에서 다음 섹션에 설명된 네 가지 옵션은 모두 유동 IP 주소를 대체하는 유효한 옵션입니다. 더 복잡한 기타 사용 사례의 경우 관련 옵션이 없을 수도 있습니다. 이러한 옵션을 설명하고 나면 이 솔루션은 특정 사용 사례를 기반으로 기본 옵션에 대한 안내를 제공합니다.

다음 섹션에서는 이 사용 사례 시나리오를 Compute Engine으로 이전하는 방법을 설명합니다.

Compute Engine을 사용한 구현

이 섹션에서는 온프레미스 시나리오를 Compute Engine으로 마이그레이션하는 몇 가지 방법을 설명합니다. 복잡함을 줄이기 위해 앞에서 설명한 헤더 기반 일치를 사용하는 대신 모든 요청이 최소한의 백엔드 구성이 있는 단일 그룹의 NGINX 백엔드로 전달됩니다.

모든 예에서 트래픽은 HAProxy에서 자동 확장 인스턴스 그룹에 있는 Compute Engine 백엔드 그룹에서 라우팅됩니다. 이러한 백엔드는 내부 TCP/UDP 부하 분산기를 사용하여 액세스합니다. 구성 예시에서는 이러한 백엔드가 NGINX 기본 구성을 제공합니다.

사용 사례 예시를 구현하려면 테스트를 위한 전용 프로젝트를 사용하세요.

백엔드 구성

이 섹션에서는 HAProxy 노드가 액세스할 NGINX 백엔드를 구성합니다. 권장사항은 기본 네트워크 대신, 이 배포 전용 VPC에서 백엔드를 만드는 것입니다.

백엔드를 설정하려면 다음 단계를 따르세요.

  1. 기본 영역을 설정합니다. 예를 들면 다음과 같습니다.

    gcloud config set compute/zone us-central1-f
    
  2. 테스트할 네트워크를 설정하고 내부 트래픽을 허용하는 방화벽 규칙을 설정하고 ssh 명령어를 사용하여 네트워크와 통신합니다.

    gcloud compute networks create ip-failover
    
    gcloud compute firewall-rules create failover-internal \
        --network ip-failover --allow all --source-ranges 10.128.0.0/11
    
    gcloud compute firewall-rules create failover-ssh \
        --network ip-failover --allow tcp:22 --source-ranges 0.0.0.0/0
    
  3. NGINX 백엔드의 인스턴스 템플릿을 만듭니다.

    gcloud compute instance-templates create www \
        --machine-type n1-standard-1 --network ip-failover \
        --metadata startup-script="apt-get -y install nginx"
    
  4. 템플릿을 기반으로 자동 확장 영역 관리형 인스턴스 그룹을 만듭니다.

    gcloud compute instance-groups managed create www \
        --template www --size 1 --zone us-central1-f
    
    gcloud compute instance-groups managed set-autoscaling www \
        --max-num-replicas 10 --min-num-replicas 1 \
        --target-cpu-utilization 0.8 --zone us-central1-f
    
  5. 고정 IP 주소(10.128.2.2)가 있는 내부 TCP/UDP 부하 분산기를 이 인스턴스 그룹에 연결합니다.

    gcloud compute health-checks create http simple-check
    
    gcloud compute backend-services create www-lb \
        --load-balancing-scheme internal \
        --region us-central1 \
        --health-checks simple-check \
        --protocol tcp
    
    gcloud compute backend-services add-backend www-lb\
        --instance-group www \
        --instance-group-zone us-central1-f \
        --region us-central1
    
    gcloud compute forwarding-rules create www-rule \
        --load-balancing-scheme internal \
        --ports 80 \
        --network ip-failover \
        --region us-central1 \
        --address 10.128.2.2 \
        --backend-service www-lb
    
  6. 테스트할 인스턴스를 만들고 ssh 명령어를 사용하여 연결하고 내부 TCP/UDP 부하 분산 IP 주소에 연결할 수 있는지 확인합니다.

    gcloud compute instances create testing \
        --machine-type n1-standard-1 --zone us-central1-f \
        --network ip-failover --scopes compute-ro
    
    gcloud compute ssh testing --zone us-central1-f
    
    username@testing:~$ curl 10.128.2.2
    <!DOCTYPE html> [...]
    username@testing:~$ exit

이 구성 예시는 인스턴스당 2GB/초 네트워크 처리량으로 제한되는 n1-standard-1 인스턴스를 사용합니다. 실제 배포의 경우 필요에 따라 인스턴스의 크기를 조정하게 됩니다.

또한 인스턴스는 외부 IP 주소로 생성되므로 시작 스크립트를 사용하여 필요한 패키지를 다운로드할 수 있습니다. 프로덕션 환경에서는 커스텀 이미지를 생성하고 외부 IP 주소 없이 인스턴스를 생성합니다.

옵션 1: 내부 TCP/UDP 부하 분산 사용

내부 TCP/UDP 부하 분산 뒤에 있는 관리형 인스턴스 그룹에 HAProxy 서버 두 개를 배치하고 다음 그림과 같이 내부 TCP/UDP 부하 분산 IP 주소를 가상 IP 주소로 사용하여 Compute Engine에서 온프레미스 시나리오를 구현할 수 있습니다.

옵션 1: 내부 TCP/UDP 부하 분산

여기서는 온프레미스 마이그레이션 서비스가 내부적으로만 노출된 것으로 가정합니다. 마이그레이션하려는 서비스가 외부에서 사용 가능한 경우 HTTP(S) 부하 분산, TCP 프록시, SSL 프록시, 네트워크 부하 분산을 사용하여 유사한 방식으로 이 시나리오를 구현할 수 있습니다.

다음과 같은 베타 전용 옵션도 사용할 수 있습니다.

온프레미스 환경과 다른 점

내부 TCP/UDP 부하 분산 IP 주소는 몇 가지 눈에 띄는 차이점을 제외하고 온프레미스 환경의 유동 IP 주소와 유사하게 작동합니다.

  • 트래픽 분산

    가장 눈에 띄는 차이점은 두 노드 간에 트래픽이 공유된다는 것입니다. 원래 설정에서는 트래픽이 한 번에 하나의 노드에만 도달합니다. 이 접근 방법은 요청 자체의 내용에 따라 트래픽이 라우팅되는 시나리오에서는 문제가 되지 않지만 지속적으로 동기화되지 않는 머신 상태(예: 마스터/슬레이브 데이터베이스)가 있는 경우에는 작동하지 않습니다.

  • 장애 조치 시간

    온프레미스 환경에서 Gratuitous ARP와 쌍을 이루었을 때 연결 유지를 사용하면 몇 초 안에 IP 주소를 장애 조치할 수 있습니다. Compute Engine 환경에서 평균 복구 시간은 장애 모드에 따라 다릅니다. 가상 머신(VM) 인스턴스 또는 VM 인스턴스 서비스에 장애가 발생할 경우 장애 조치 평균 시간 트래픽은 Check IntervalUnhealthy Threshold와 같은 상태 확인 매개변수에 따라 달라집니다. 이 매개변수를 기본값으로 설정하면 장애 조치는 일반적으로 15~20초가 걸리지만 매개변수를 조정하면 시간을 더 줄일 수 있습니다. Compute Engine에서 영역 내 또는 여러 영역에서의 장애 조치는 동일한 시간이 걸립니다.

  • 상태 확인

    온프레미스에서 사용할 때, 유지 신호를 기다리는 것 외에도 연결 유지는 HAProxy 프로세스의 가용성 모니터링과 같은 다양한 방법으로 호스트 머신 상태를 검사할 수 있습니다. Compute Engine에서 상태 검사는 HTTP/HTTPS/TCP 또는 SSL 포트를 사용하여 호스트 외부에서 액세스할 수 있어야 합니다. 호스트 세부사항을 점검해야 하는 경우 인스턴스에 간단한 서비스를 설치하여 해당 세부사항을 노출하거나 대체 옵션을 선택해야 합니다.

  • 포트

    온프레미스 환경에서 유동 IP 주소는 모든 트래픽을 허용합니다. 내부 TCP/UDP 부하 분산기의 경우 내부 전달 규칙에서 다음 포트 사양 중 하나를 선택해야 합니다.

    • 숫자로 1~5개의 포트 지정
    • ALL을 지정하여 모든 포트의 트래픽 전달

옵션 1 구현

이 솔루션을 구현하려면 다음 단계를 완료하세요.

  1. 요청을 전달하는 HAProxy 서버용 인스턴스 템플릿을 만듭니다.

    gcloud compute instance-templates create haproxy \
        --machine-type n1-standard-1 --network ip-failover \
        --metadata "startup-script=
    sudo apt-get install -y haproxy
    cat << EOF >> /etc/haproxy/haproxy.cfg
    frontend www
        bind :80
        option http-server-close
        default_backend web-backend
    backend web-backend
        server web-1 10.128.2.2:80 check
    EOF
    service haproxy restart"
    
  2. 정적 크기가 2인 인스턴스 템플릿을 기반으로 영역(zone) 인스턴스 그룹을 만듭니다. 이전에 생성한 상태 확인을 사용하여 자동 복구 정책을 인스턴스에 연결합니다.

    gcloud compute instance-groups managed create haproxy \
        --template haproxy --size 2 --zone us-central1-f
    
    gcloud compute instance-groups managed update \
        haproxy --health-check simple-check --zone us-central1-f
    
  3. 상태 확인을 사용하여 내부 TCP/UDP 부하 분산기를 HAProxy 서버에 연결합니다.

    gcloud compute backend-services create haproxy-lb \
        --load-balancing-scheme internal \
        --region us-central1 \
        --health-checks simple-check \
        --protocol tcp
    gcloud compute backend-services add-backend haproxy-lb\
        --instance-group haproxy \
        --instance-group-zone us-central1-f \
        --region us-central1
    
    gcloud compute forwarding-rules create haproxy-rule \
        --load-balancing-scheme internal \
        --ports 80 \
        --network ip-failover \
        --region us-central1 \
        --address 10.128.1.1 \
        --backend-service haproxy-lb
    
  4. 내부 TCP/UDP 부하 분산을 통해 HAProxy에 도달할 수 있는지 테스트합니다.

    gcloud compute ssh testing --zone us-central1-f
    
    username@testing:~$ curl 10.128.1.1
    <!DOCTYPE html> [...]
    username@testing:~$ exit

콘솔을 통해 HAProxy 인스턴스 중 하나를 삭제하거나 인스턴스 중 하나에서 HAProxy 프로세스를 중지하면 짧은 장애 조치 시간 후에 계속 curl을 수행할 수 있습니다.

옵션 2: 단일 관리형 인스턴스 사용

복구 시간 요구사항에 따라 여러 서버가 온프레미스로 사용되는 경우에도 단일 VM 인스턴스로 마이그레이션하는 것이 적절한 Compute Engine 옵션일 수 있습니다. 그 이유는 새로운 Compute Engine 인스턴스를 시작하는 데는 몇 분 밖에 걸리지 않지만 온프레미스에서의 오류는 일반적으로 수정하는 데 몇 시간 또는 며칠까지도 걸리기 때문입니다.

옵션 2: 단일 관리형 인스턴스

옵션 2와 옵션 1 비교: 내부 TCP/UDP 부하 분산

옵션 2는 옵션 1에 비해 큰 장점과 단점이 있습니다.

장점:

  • 트래픽 분산

    인스턴스가 하나뿐이므로 온프레미스 마스터-슬레이브 시나리오와 마찬가지로 모든 트래픽이 단일 인스턴스에 도달합니다.

  • 비용 절감

    2개 대신 단일 VM 인스턴스를 사용하면 구현 비용을 절반으로 줄일 수 있습니다.

  • 단순성

    이 솔루션은 구현하기 쉽고 약간의 오버헤드가 있습니다.

단점:

  • 장애 조치 시간

    상태 확인에서 머신 장애를 감지한 후 실패한 인스턴스를 삭제하고 다시 작성하는 데는 최소 1분이 소요되지만 종종 그보다 훨씬 많은 시간이 소요됩니다. 이 프로세스는 내부 TCP/UDP 부하 분산에서 인스턴스를 삭제하는 것보다 훨씬 느립니다.

  • 영역 오류에 대한 대응

    크기가 1인 관리형 인스턴스 그룹은 영역 장애를 처리하지 못합니다. 영역 장애에 응답하려면 서비스가 실패할 때 Stackdriver Monitoring 경고를 추가하고 영역 장애가 발생하면 수동으로 다른 영역에 인스턴스 그룹을 만듭니다.

옵션 2 구현

옵션 2를 구현하려면 다음 단계를 완료하세요.

  1. HAProxy VM 인스턴스에 대한 인스턴스 템플릿을 만듭니다.

    gcloud compute instance-templates create haproxy-single \
        --machine-type n1-standard-1 --network ip-failover \
        --metadata "startup-script=
    sudo apt-get install -y haproxy
    cat << EOF >> /etc/haproxy/haproxy.cfg
    frontend www
        bind :80
        option http-server-close
        default_backend web-backend
    backend web-backend
        server web-1 10.128.2.2:80 check
    EOF
    service haproxy restart"
    
  2. HAProxy VM에 크기가 1인 관리형 인스턴스 그룹을 만들고 자동 복구 정책을 연결합니다.

    gcloud compute instance-groups managed create haproxy-single \
        --template haproxy-single --size 1 --zone us-central1-f
    
    gcloud compute instance-groups managed update \
        haproxy-single --health-check simple-check --zone us-central1-f
    
  3. 내부 TCP/UDP 부하 분산 IP 주소를 통해 HAProxy에 도달할 수 있는지 테스트합니다.

    gcloud compute ssh testing --zone us-central1-f
    
    username@testing:~$ instance=$(gcloud compute instances list |awk '$1 ~ /^haproxy-single/ { print $1 }')
    
    username@testing:~$ curl $instance
    <!DOCTYPE html> [...]
    username@testing:~$ exit

    콘솔을 사용하여 HAProxy 인스턴스를 삭제하거나 HAProxy 인스턴스 프로세스를 중지하면 인스턴스는 동일한 IP 주소 및 인스턴스 이름을 가진 지연이 발생한 후에 자동으로 복구됩니다.

옵션 3: 다른 우선순위 경로를 사용한 장애 조치

우선순위가 다른 두 Compute Engine 경로는 내부 TCP/UDP 부하 분산을 사용할 수 없는 경우 두 인스턴스 간에 트래픽 장애 조치를 수행하는 또 다른 방법을 제공합니다.

이 섹션에서는 2개의 VM 인스턴스를 만들고 정적 크기가 1인 자동 복구 관리형 인스턴스 그룹에 배치하여 시스템이 자동으로 치료되도록 합니다.

이 두 인스턴스에서 IP 전달을 사용 설정해야 합니다. 그런 다음 인스턴스를 만든 후 트래픽을 처리할 우선순위가 다른 2개의 경로를 설정하여 모든 유동 IP 트래픽을 이 두 인스턴스로 전환합니다.

옵션 3: 다른 우선순위 경로

옵션 3과 옵션 1 비교: 내부 TCP/UDP 부하 분산

옵션 3을 사용하면 내부 TCP/UDP 부하 분산을 쉽게 사용할 수 없는 사용 사례를 마이그레이션할 수 있습니다. 이 옵션에는 다음과 같은 장점이 있습니다.

  • 트래픽 분산

    트래픽은 항상 가장 낮은 우선순위의 VM 인스턴스로 이동합니다. 이 VM 인스턴스를 사용할 수 없는 경우 트래픽은 그 다음 우선순위의 경로를 사용합니다. 이 아키텍처는 주어진 시간에 하나의 서버만 활성화되는 온프레미스 환경과 유사합니다.

  • 프로토콜

    내부 TCP/UDP 부하 분산은 특정 프로토콜 또는 포트에만 적용되는 반면 경로는 특정 대상에 대한 모든 트래픽에 적용됩니다.

  • 지역성

    내부 TCP/UDP 부하 분산은 한 리전 내에서만 사용 가능하며 경로는 디렉터리에 관계없이 만들 수 있습니다.

옵션 3은 내부 TCP/UDP 부하 분산을 사용하는 옵션 1과 비교할 때 단점이 있습니다.

  • 상태 확인

    옵션 3을 사용하면 두 경로 중 하나에 상태 확인이 연결되지 않습니다. 경로는 기본 VM 서비스의 상태와 관계없이 사용됩니다. 서비스가 비정상적인 경우에도 트래픽은 인스턴스로 전달됩니다. 이러한 인스턴스에 자동 복구 정책을 연결하면 특정 비정상적인 시간대가 지나면 인스턴스가 종료되지만 일단 인스턴스가 다시 시작되면 서비스가 시작되기 전에 트래픽이 다시 시작됩니다. 이는 비정상적인 인스턴스가 여전히 트래픽을 처리하고 있거나 재시작 프로세스 중일 때 잠재적인 서비스 오류를 발생시킬 수 있습니다.

  • 장애 조치 시간

    VM 인스턴스를 삭제하거나 중지하면 경로가 자동으로 취소됩니다. 그러나 상태 확인이 누락되었기 때문에 인스턴스를 아직 사용할 수 있으면 경로는 계속 사용됩니다. 또한 인스턴스 중지에는 시간이 걸리므로 내부 TCP/UDP 부하 분산 방식보다 장애 조치 시간이 상당히 길어집니다.

  • 유동 IP 주소 선택

    서브넷의 일부가 아닌 IP 주소에만 경로를 설정할 수 있습니다. 유동 IP 주소는 모든 기존 서브넷 범위 밖에서 선택해야 합니다.

  • VPC 네트워크 피어링

    VM 인스턴스는 자체 VPC 네트워크의 경로만 사용할 수 있으며 피어링된 VPC 네트워크는 사용할 수 없습니다.

옵션 3 구현

구현하는 동안 ip-failover 네트워크의 모든 활성 서브넷 외부에 있는 10.191.1.1 IP 주소를 사용합니다. 다음 단계를 완료하세요.

  1. 요청을 전달하는 HAProxy 서버용 인스턴스 템플릿을 만듭니다.

    gcloud compute instance-templates create haproxy-route \
        --machine-type n1-standard-1 --network ip-failover \
        --metadata "startup-script=
    apt-get update
    apt-get install -y haproxy
    cat << EOF >> /etc/haproxy/haproxy.cfg
    frontend www
        bind :80
        option http-server-close
        default_backend web-backend
    backend web-backend
        server web-1 10.128.2.2:80 check
    EOF
    cat << EOF >> /etc/network/interfaces
    auto eth0:0
    iface eth0:0 inet static
        address 10.191.1.1
        netmask 255.255.255.255
    EOF
    service haproxy restart
    service networking restart" --can-ip-forward
    
  2. HAProxy VM에 대해 크기가 1인 관리형 인스턴스 그룹 2개를 만들고 자동 복구 정책을 연결합니다.

    gcloud compute instance-groups managed create haproxy-r1 \
        --template haproxy-route --size 1 --zone us-central1-f
    
    gcloud compute instance-groups managed update \
        haproxy-r1 --health-check simple-check --zone us-central1-f
    
    gcloud compute instance-groups managed create haproxy-r2 \
        --template haproxy-route --size 1 --zone us-central1-b
    
    gcloud compute instance-groups managed update \
        haproxy-r2 --health-check simple-check --zone us-central1-b
    
  3. 시작한 후에 이러한 VM 인스턴스에 대한 기본 및 백업 경로를 만듭니다.

    haproxy1=$(gcloud compute instances list |awk '$1 \
        ~ /^haproxy-r1/ { print $1 }')
        #save the instance name of the first HAproxy instance
    
    haproxy2=$(gcloud compute instances list |awk '$1 \
        ~ /^haproxy-r2/ { print $1 }')
        #save the instance name of the second HAproxy instance
    
    gcloud compute routes create haproxy-route1 \
        --destination-range 10.191.1.1/32 --network ip-failover \
        --priority 500 --next-hop-instance-zone us-central1-f \
        --next-hop-instance $haproxy1
    
    gcloud compute routes create haproxy-route2 \
        --destination-range 10.191.1.1/32 --network ip-failover \
        --priority 600 --next-hop-instance-zone us-central1-b \
        --next-hop-instance $haproxy2
    
  4. 경로를 통해 HAProxy에 도달할 수 있는지 테스트합니다.

    gcloud compute ssh testing --zone us-central1-f
    
    username@testing:~$ curl 10.191.1.1
    <!DOCTYPE html> [...]
    username@testing:~$ exit

    콘솔을 사용하여 기본 HAProxy 인스턴스를 삭제하면 인스턴스가 완전히 종료되자마자 보조 인스턴스에 대한 경로가 사용됩니다.

옵션 4: 경로 API 호출을 사용한 장애 조치

옵션 3과 마찬가지로 옵션 4도 경로를 사용하지만 몇 가지 중요한 차이점이 있습니다. 자동 복구와 인스턴스 재생성을 자동으로 수행하는 대신 연결 유지 또는 다른 스크립트는 API 호출을 사용하여 새로운 정상 인스턴스에 대한 경로를 추가하거나 비정상적인 인스턴스에서 경로를 삭제합니다. 이 접근 방식은 Compute Engine 상태 확인을 사용하여 애플리케이션 상태를 추적하거나 기본 가상 머신을 결정할 수 없는 상황에서 유용합니다. 모든 애플리케이션 로직은 경로의 동적 재프로그래밍을 트리거할 수 있습니다.

애플리케이션 장애를 수동으로 조사하고 인스턴스를 수동으로 온라인 상태로 되돌리려면 경로 API 호출을 장애 조치 메소드로 사용하는 것이 유용합니다. 그러나 VM은 모든 장애를 로깅해야 하며 정상적으로 작동할 때 자동으로 교체될 수 있어야 하므로 Compute Engine에서 수동으로 장애를 조사하지 마세요.

옵션 4: 경로 API 호출을 사용한 장애 조치

옵션 4 차이점 비교: 내부 TCP/UDP 부하 분산

옵션 4는 내부 TCP/UDP 부하 분산을 사용할 때와 다른 다음과 같은 장점을 제공합니다.

  • 트래픽 분산

    옵션 2 및 3에서와 마찬가지로 트래픽은 한 번에 하나의 VM 인스턴스에만 적용됩니다.

  • Compute Engine 상태 확인에 의존하지 않음

    장애 조치는 모든 커스텀 애플리케이션 로직에 의해 트리거 될 수 있습니다. 옵션 4를 사용하면 스크립트를 사용하여 기본 및 보조 HAProxy 사이의 통신 장애에 대한 연결 유지 응답을 관리합니다. 이는 Compute Engine 상태 확인을 사용할 수 없거나 사용하지 않을 때만 작동하는 유일한 옵션입니다.

옵션 4에는 다음과 같은 주요 단점이 있습니다.

  • 복잡성

    이 옵션은 Compute Engine API 또는 gcloud 호출을 사용하여 커스텀 빌드되어야 하며Compute Engine API를 사용하여 경로를 취소하고 새 경로를 설정합니다. 이 로직을 신뢰할 수 있는 방법으로 구현하는 것은 복잡한 경우가 많습니다.

  • 장애 조치 시간

    Compute Engine에서 경로를 취소하고 새 경로를 만드는 데 커스텀 스크립트로 최소 2개의 Compute Engine API 호출이 필요하기 때문에 장애 조치는 내부 부하 분산기를 사용하는 것보다 약간 느립니다.

  • 유동 IP 주소 선택

    서브넷의 일부가 아닌 IP 주소에만 경로를 설정할 수 있습니다. 유동 IP 주소는 모든 기존 서브넷 범위 외부에서 선택해야 합니다.

  • VPC 네트워크 피어링

    VM 인스턴스는 자체 VPC 네트워크의 경로만 사용할 수 있으며 피어링된 VPC 네트워크는 사용할 수 없습니다.

옵션 4 구현

이 구현에서는 ip-failover 네트워크의 모든 활성 서브넷 외부에 있는 10.190.1.1 IP 주소를 사용합니다. 이 주소의 경로는 연결 유지에 의해 자동으로 생성되고 삭제됩니다.

먼저 두 인스턴스의 정적 내부 IP 주소를 사용하여 haproxy 및 연결 유지가 있는 2개의 HAProxy 인스턴스를 만듭니다. 또한 경로를 종료할 수 있도록 IP 전달을 사용 설정해야 하고 Compute Engine API에 대한 액세스를 요청해야 합니다. 간단히 하기 위해 이 예시에서는 인스턴스 템플릿 및 그룹을 사용하지 않습니다.

다음 단계를 수행하여 옵션 4를 만드세요.

  1. 정적 IP 주소가 10.128.4.100인 기본 인스턴스를 만듭니다.

    gcloud compute instances create haproxy-a \
        --machine-type n1-standard-1 --network ip-failover \
        --can-ip-forward --private-network-ip=10.128.4.100 \
        --scopes compute-rw --zone us-central1-f \
        --metadata 'startup-script=
    apt-get update
    apt-get install -y haproxy keepalived
    cat << EOF >> /etc/haproxy/haproxy.cfg
    frontend www
        bind :80
        option http-server-close
        default_backend web-backend
    backend web-backend
        server web-1 10.128.2.2:80 check
    EOF
    cat << EOF >> /etc/network/interfaces
    auto eth0:0
    iface eth0:0 inet static
        address 10.190.1.1
        netmask 255.255.255.255
    EOF
    cat << EOF >> /etc/keepalived/keepalived.conf
    vrrp_script haproxy {
        script "/bin/pidof haproxy"
        interval 2
    }
    
    vrrp_instance floating_ip {
        state MASTER
        interface eth0
        track_script {
            haproxy
        }
        unicast_src_ip 10.128.4.100
        unicast_peer {
            10.128.4.200
        }
        virtual_router_id 50
        priority 100
        authentication {
            auth_type PASS
            auth_pass yourpassword
        }
        notify_master /etc/keepalived/takeover.sh
    }
    EOF
    cat << EOF >> /etc/keepalived/takeover.sh
    #!/bin/bash
    gcloud compute routes delete floating --quiet
    gcloud compute routes create floating \
        --destination-range 10.190.1.1/32 --network ip-failover \
        --priority 500 --next-hop-instance-zone us-central1-f \
        --next-hop-instance haproxy-a --quiet
    EOF
    chmod +x /etc/keepalived/takeover.sh
    service haproxy restart
    service networking restart
    service keepalived start'
    
  2. 정적 IP 주소가 10.128.4.200인 보조 인스턴스를 만듭니다.

    gcloud compute instances create haproxy-b \
        --machine-type n1-standard-1 --network ip-failover \
        --can-ip-forward --private-network-ip=10.128.4.200 \
        --scopes compute-rw --zone us-central1-c \
        --metadata 'startup-script=
    apt-get update
    apt-get install -y haproxy keepalived
    cat << EOF >> /etc/haproxy/haproxy.cfg
    frontend www
        bind :80
        option http-server-close
        default_backend web-backend
    backend web-backend
        server web-1 10.128.2.2:80 check
    EOF
    cat << EOF >> /etc/network/interfaces
    auto eth0:0
    iface eth0:0 inet static
        address 10.190.1.1
        netmask 255.255.255.255
    EOF
    cat << EOF >> /etc/keepalived/keepalived.conf
    vrrp_script haproxy {
        script "/bin/pidof haproxy"
        interval 2
    }
    
    vrrp_instance floating_ip {
        state BACKUP
        interface eth0
        track_script {
            haproxy
        }
        unicast_src_ip 10.128.4.200
        unicast_peer {
            10.128.4.100
        }
        virtual_router_id 50
        priority 50
        authentication {
            auth_type PASS
            auth_pass yourpassword
        }
        notify_master /etc/keepalived/takeover.sh
    }
    EOF
    cat << EOF >> /etc/keepalived/takeover.sh
    #!/bin/bash
    gcloud compute routes delete floating --quiet
    gcloud compute routes create floating \
        --destination-range 10.190.1.1/32 --network ip-failover \
        --priority 500 --next-hop-instance-zone us-central1-c \
        --next-hop-instance haproxy-b --quiet
    EOF
    chmod +x /etc/keepalived/takeover.sh
    service haproxy restart
    service networking restart
    service keepalived start'
    
  3. 경로를 통해 HAProxy에 도달할 수 있는지 테스트합니다.

    gcloud compute ssh testing --zone us-central1-f
    
    username@testing:~$ curl 10.190.1.1
    <!DOCTYPE html> [...]
    username@testing:~$ exit

    인스턴스 haproxy-a에서 HAProxy가 종료되거나 인스턴스가 잠기면 VRRP 하트비트가 누락되고 haproxy-b 인스턴스가 takeover.sh 스크립트를 호출합니다. 이 스크립트는 10.190.1.1에 대한 경로를 haproxy-a에서 haproxy-b로 이동하며 테스트는 계속 작동합니다.

사용 사례에 가장 적합한 옵션 선택

복잡한 라우팅 결정을 내리는 일련의 HAProxy 노드와 관련된 사용 사례의 경우 선호되는 Compute Engine 구현은 옵션 1: 내부 TCP/UDP 부하 분산입니다. 이 옵션은 VM 인스턴스가 상태를 추적하지 않고 active-active 시나리오에서 쉽게 작동할 수 있기 때문입니다. 또한 Compute Engine 상태 확인을 사용할 수 있습니다. 다른 사용 사례에서는 옵션 1이 가장 적합한 옵션이 아닐 수도 있습니다.

앞에서 설명한 각 옵션에 대해 설명한 장단점과 더불어 다음 의사 결정 트리를 사용하여 구현 스키마를 결정할 수 있습니다.

의사 결정 트리

고가용성 및 안정적인 애플리케이션은 수평 확장 아키텍처를 사용하여 Compute Engine에 구현하는 것이 가장 좋으며 이는 단일 노드 장애의 영향을 최소화합니다. 유동 IP 주소가 있는 2개의 서버와 같은 일반적인 온프레미스 시나리오를 마이그레이션하기는 어렵습니다. 이 시나리오는 Compute Engine에서 중복될 수 없기 때문입니다. 앞서 언급했듯이 Gratuitous ARP를 사용하여 1초 이내에 다른 머신 간 IP 주소를 이동하는 것은 가상 라우팅 인프라의 특성으로 인해 불가능합니다.

내부 TCP/UDP 부하 분산을 사용하면 많은 사용 사례를 Compute Engine으로 간단하고 안정적으로 전송할 수 있습니다. 내부 부하 분산기를 사용할 수 없는 경우, 복잡한 오버레이 라우팅 메커니즘이 필요 없는 몇 가지 다른 옵션을 구현할 수 있습니다.

다음 단계