Compute Engine에서 HAProxy 및 Consul을 사용하여 자동 확장된 내부 부하 분산

이 솔루션에서는 Google Cloud Platform에서 HAProxy 기반의 내부 부하 분산 시스템의 일부로 DNS 기반 서비스 검색 제품인 HashiCorp의 Consul을 사용하는 방법을 보여줍니다.

내부 부하 분산기는 비공개 네트워크의 서버에 네트워크 트래픽을 분산합니다. 트래픽을 분산하는 내부 부하 분산기나 서버 모두 인터넷에 노출되지 않습니다. Google Compute Engine에서 HAProxy를 사용하는 내부 부하 분산 가이드에서는 내부 부하 분산의 기본 개념을 자세히 설명하고 HAProxy 및 Google Compute Engine을 사용하여 내부 부하 분산기를 구성하는 방법을 안내합니다.

이 솔루션은 HAProxy 부하 분산 계층 및 백엔드 서버 계층 모두에서 자동 확장을 지원하도록 이전 구성을 확장합니다. 이러한 수정에 따라 서버를 해당 계층에서 정상적으로 추가 또는 삭제하여, 인프라가 부하 변동에 대응하거나 실패로부터 복구하도록 허용할 수 있습니다. Consul은 이러한 부하 분산 아키텍처를 사용 설정하기 위한 서비스 검색 및 분산 구성 메커니즘을 제공합니다.

소프트웨어 스택

기술 설명
Consul 서비스 검색을 제공합니다. 서버를 Consul에 등록하면 클러스터의 다른 서비스가 이를 검색할 수 있습니다.
Consul 템플릿 Consul 템플릿 데몬을 사용해서 Consul에서 파일 시스템으로 값을 편리하게 채울 수 있는 방법을 제공합니다.
Dnsmasq DNS(도메인 이름 서비스) 쿼리를 인스턴스에서 Consul로 전달합니다. DNS에 의존하는 애플리케이션이 Consul에서 서비스를 쉽게 검색할 수 있게 해줍니다.
HAProxy 고성능 TCP/HTTP 부하 분산기입니다.
백엔드 서버 Compute Engine 인스턴스의 로컬 메타데이터를 JSON으로 출력하는 간단한 Go 애플리케이션입니다.
프런트엔드 서버 백엔드 서버 API의 JSON을 소비하고 이를 HTML로 렌더링하는 간단한 Go 애플리케이션입니다.
Packer 사전 구성된 Google Compute Engine VM 이미지를 만들기 위한 도구입니다. Packer는 Consul 및 HAProxy를 부팅 가능한 이미지에 설치하고 구성하기 위해 사용됩니다.
Cloud Platform 관리형 인스턴스 그룹과 자동 확장 처리 관리형 인스턴스 그룹은 공통 인스턴스 템플릿으로부터 생성된 동종 인스턴스 풀입니다. 자동 확장 처리는 관리형 인스턴스 그룹에서 인스턴스를 추가하거나 삭제합니다.

학습할 내용

각각의 다음 섹션에서는 아키텍처 다이어그램의 특정 부분에 대해 토론하고, Compute Engine에서 해당 섹션을 프로비저닝하기 위한 실무 안내를 제공합니다. 이 문서의 끝에서는 아키텍처의 각 섹션에 대해 자세히 학습하고, 해당 환경에서 이를 실행하고 사용하는 방법을 알게 됩니다.

시작하기 전에

  1. Google 계정에 로그인합니다.

    아직 계정이 없으면 새 계정을 등록하세요.

  2. Google Cloud Platform 프로젝트를 선택하거나 만듭니다.

    리소스 관리 페이지로 이동

  3. Google Cloud Platform 프로젝트에 결제가 사용 설정되어 있는지 확인하세요.

    결제 사용 설정 방법 알아보기

  4. Cloud SDK 설치 및 초기화.

메시지가 나타나면 sudo gcloud components update를 실행합니다.

Consul 클러스터

Consul은 이 아키텍처에서 서비스 등록 및 검색을 제공합니다. HAProxy를 실행하는 Compute Engine 인스턴스는 시작될 때, haproxy-internal이라는 Consul 서비스에 등록되고, 프런트엔드 서버가 Consul에 대한 DNS 쿼리를 통해 모든 HAProxy 서버를 검색할 수 있습니다. 마찬가지로, 백엔드 애플리케이션을 실행하는 인스턴스는 backend라는 Consul 서비스에 등록되고, HAProxy 서버에서 검색될 수 있습니다.

서비스 등록 및 검색을 지원하기 위해서는 하나 이상의 Consul 서버를 실행해야 합니다. Consul 제작자들은 데이터 센터별로 3-5개의 Consul 서버 실행을 강력하게 권장합니다. 이 문서의 예에서는 3개의 Consul 서버 실행을 권장합니다.

실습: Consul 서버 실행

  1. gitpacker가 사전 설치된 tool이라는 Compute Engine 인스턴스를 만듭니다.

    gcloud compute instances create tool \
      --scopes cloud-platform \
      --zone us-central1-f \
      --image-project debian-cloud --image-family debian-9 \
      --metadata "startup-script=apt-get update -y && \
        sudo apt-get install -y git unzip && \
        curl -o /tmp/packer.zip https://releases.hashicorp.com/packer/0.8.6/packer_0.8.6_linux_amd64.zip && \
        curl -o /tmp/consul.zip https://releases.hashicorp.com/consul/0.6.3/consul_0.6.3_linux_amd64.zip && \
        sudo unzip /tmp/packer.zip -d /usr/local/bin/ && \
        sudo unzip /tmp/consul.zip -d /usr/local/bin/"
    
  2. 인스턴스에서 SSH를 시작하기 전에 스크립트가 실행될 수 있도록 몇 분 정도 기다립니다.

  3. 새로운 tool 인스턴스에 연결합니다.

    gcloud compute ssh tool --zone=us-central1-f
    
  4. 소스 코드 저장소를 tool 인스턴스에 복제합니다.

    cd ~
    git clone https://github.com/GoogleCloudPlatform/compute-internal-loadbalancer.git
    
  5. 프로젝트 ID가 포함된 환경 변수를 설정합니다. PROJECT_ID 또는 project-id는 바꾸지 마세요. 모든 항목이 자동으로 처리됩니다.

    export PROJECT_ID=$(curl -H "metadata-flavor: Google" http://metadata.google.internal/computeMetadata/v1/project/project-id)
    
  6. Consul 이미지 파일이 포함된 디렉토리로 변경합니다.

    cd ~/compute-internal-loadbalancer/images/consul
    
  7. packer를 사용해서 Consul 서버에 대한 Google Compute Engine VM 이미지를 빌드합니다. PROJECT_ID를 프로젝트 ID로 바꾸지 마세요. 이 항목은 이전 단계에서 이미 변수로 설정되었습니다.

    packer build -var project_id=${PROJECT_ID} packer.json
    
  8. 생성된 이미지의 ID를 복사합니다. 이 ID는 Builds finished 메시지에서 볼 수 있습니다. 예를 들어 다음 메시지에서 ID는 consul-1450847630입니다.

    ==> Builds finished. The artifacts of successful builds are:
    --> googlecompute: A disk image was created: consul-1450847630
    

    이 ID를 기록해둡니다. 다음 단계 및 이 솔루션의 후반부에 필요합니다.

  9. 3개의 Consul 서버를 시작하고, --image 플래그의 값을 이전 단계에서 복사한 이미지 ID로 바꿨는지 확인합니다.

    gcloud compute instances create consul-1 consul-2 consul-3 \
      --metadata="^|^consul_servers=consul-1,consul-2,consul-3" \
      --zone=us-central1-f \
      --no-address \
      --image=YOUR_CONSUL_IMAGE_ID
    
  10. tool 인스턴스를 클러스터에 연결합니다.

    consul agent \
      -data-dir=/tmp/consul \
      -retry-join=consul-1 \
      -retry-join=consul-2 \
      -retry-join=consul-3 &
    
  11. 인스턴스가 클러스터에 성공적으로 연결된 것을 나타내는 상태 메시지가 표시된 후 clear를 입력하여 콘솔을 지웁니다. 이 시점에는 프롬프트가 표시되지 않고, 깜박이는 블록 커서만 표시됩니다.

  12. 클러스터 구성원을 확인하고 consul-1, consul-2, consul-3server 유형으로 연결되었는지 확인합니다.

    consul members
    

    출력이 다음과 같이 표시됩니다.

      Node          Address           Status  Type    Build  Protocol  DC
      consul-1      10.240.0.5:8301   alive   server  0.6.0  2         dc1
      consul-2      10.240.0.3:8301   alive   server  0.6.0  2         dc1
      consul-3      10.240.0.4:8301   alive   server  0.6.0  2         dc1
      tool          10.240.0.2:8301   alive   client  0.6.0  2         dc1
    

백엔드 애플리케이션

이 예의 백엔드 애플리케이션은 애플리케이션이 실행 중인 Compute Engine 인스턴스의 인스턴스 메타데이터를 반환하는 간단한 마이크로서비스입니다. 이 애플리케이션은 인스턴스 메타데이터를 HTTP GET 요청에 대한 응답에서 JSON 문자열로 반환합니다. 백엔드 애플리케이션을 실행하는 인스턴스에는 비공개 IP 주소만 포함되고 공개 주소는 포함되지 않습니다. 샘플 애플리케이션의 소스 코드는 GitHub에서 검색할 수 있습니다.

백엔드 부트스트래핑

백엔드 애플리케이션을 실행하는 VM이 온라인 상태가 되면, 기존 Consul 클러스터를 연결하고, 클러스터에 자신을 서비스로 등록한 후, HTTP 요청에 대한 응답으로 애플리케이션 프로세스를 시작해야 합니다. 이러한 부트스트래핑은 2개의 systemd 단위인 consul_servers.servicebackend.service에서 수행됩니다.

  • consul_servers.service: 이 단위는 consul_servers.sh 셸 스크립트를 호출합니다. 이 스크립트는 인스턴스의 메타데이터 저장소에서 Consul 서버 이름을 검색하고 이를 /etc/consul-servers 파일에 기록합니다. Consul 서버가 이미 실행 중이어야 하고, consul_servers라는 메타데이터 속성으로 백엔드 서버를 시작해야 합니다. 이 속성의 값은 쉼표로 구분된 Consul 서버 이름 목록입니다. 이 단위 파일은 다음과 같습니다.

    [Unit]
    Description=consul_servers
    
    [Service]
    Type=oneshot
    ExecStart=/bin/sh -c "/usr/bin/consul_servers.sh > /etc/consul-servers"
    
    [Install]
    WantedBy=multi-user.target
    
  • backend.service: 이 단위는 consul_servers.service 다음에 실행됩니다. 이 단위는 /etc/consul-servers에서 Consul 서버 이름을 읽은 후 backend-start.sh 스크립트를 실행합니다. 이 스크립트는 Consul 서비스 파일을 만든 후 클러스터를 연결하고, 서비스를 등록하고, 마지막으로 백엔드 애플리케이션을 시작합니다.

    backend.service 단위 파일은 다음과 같습니다.

    [Unit]
    Description=backend
    After=consul_servers.service
    Requires=consul_servers.service
    
    [Service]
    EnvironmentFile=/etc/consul-servers
    ExecStart=/usr/bin/backend-start.sh
    LimitNOFILE=9999999
    
    [Install]
    WantedBy=multi-user.target
    

    backend-start.sh 스크립트는 다음과 같습니다.

    #! /bin/bash
    export zone=$(curl -s -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/zone" | grep -o [[:alnum:]-]*$)
    
    # Set zone in Consul and HAProxy files
    envsubst < "/etc/consul.d/backend.json.tpl" > "/etc/consul.d/backend.json"
    
    # Start consul
    consul agent -data-dir /tmp/consul -config-dir /etc/consul.d $CONSUL_SERVERS &
    
    # Start the microservice
    /opt/www/gceme -port=8080
    

백엔드 Consul 서비스

backend.service가 시작될 때 생성되는 /etc/consul.d/backend.json 서비스 파일은 다음과 같습니다.

{
  "service": {
    "name": "backend",
    "tags": "us-central1-f",
    "port": 8080,
    "check": {
      "id": "backend",
      "name": "HTTP on port 8080",
      "http": "http://localhost:8080/healthz",
      "interval": "10s",
      "timeout": "1s"
    }
  }
}

Consul 에이전트가 백엔드 서버에서 시작될 때, 이 서버는 Consul 클러스터에 backend 서비스로 등록되며, 서버가 실행되는 가용성 영역이 태그로 사용됩니다. 서비스의 구성원은 DNS 이름 backend.service.consul.을 확인하여 검색할 수 있습니다. 특정 가용성 영역에서 서비스 구성원을 찾기 위해서는 이름에 태그를 붙입니다(예: us-central1-f.backend.service.consul.).

실습: 백엔드 서비스 시작

이 실습 섹션에서는 Packer를 사용하여 백엔드 서비스에 대한 VM 이미지를 빌드하고, 인스턴스 그룹을 사용하여 백엔드 서버의 클러스터를 만들고 관리합니다.

  1. tool 인스턴스에서 백엔드 이미지 파일이 포함된 디렉토리로 변경합니다.

    cd ~/compute-internal-loadbalancer/images/backend
    
  2. packer를 사용해서 Consul 서버의 Compute Engine VM 이미지를 빌드합니다. 다시 말하지만, 이 명령줄의 어떤 부분이라도 현재 변수 값을 사용해서 바꾸지 마세요.

    packer build -var project_id=${PROJECT_ID} packer.json
    
  3. 생성된 이미지의 ID를 다음과 같이 복사합니다.

    ==> Builds finished. The artifacts of successful builds are:
    --> googlecompute: A disk image was created: backend-1450847630
    

    이 ID를 기록해둡니다. 다음 단계 및 이 솔루션의 후반부에 필요합니다.

  4. 백엔드 서버의 구성을 기술하는 인스턴스 템플릿을 만들고 YOUR_BACKEND_IMAGE_ID를 이전 단계의 출력으로 바꿉니다.

    gcloud compute instance-templates create backend \
      --no-address \
      --metadata="^|^consul_servers=consul-1,consul-2,consul-3" \
      --image=YOUR_BACKEND_IMAGE_ID
    
  5. 백엔드 템플릿을 사용해서 2개의 백엔드 서버를 시작하는 인스턴스 그룹을 만듭니다.

    gcloud compute instance-groups managed create backend \
      --base-instance-name=backend \
      --template=backend \
      --size=2 \
      --zone=us-central1-f
    

HAProxy 부하 분산기 계층

HAProxy는 백엔드 서버에 대한 요청을 부하 분산하기 위해 사용됩니다. HAProxy를 실행하는 VM은 온라인 상태가 될 때, 기존 Consul 클러스터를 연결하고, 자체를 클러스터에 서비스로 등록하고, 백엔드 서비스에서 서버를 검색한 후 HAProxy를 시작해야 합니다. 백엔드 서버와 마찬가지로 HAProxy 서버는 비공개 IP 주소를 포함하며, 공개 인터넷을 통해 액세스할 수 없습니다.

HAProxy Consul 서비스

각 HAProxy 서버로 Consul에 등록되는 서비스는 haproxy-internal로 이름이 지정되고 다음과 같이 정의됩니다.

{
  "service": {
    "name": "haproxy-internal",
    "tags": "us-central1-f",
    "port": 8080,
    "check": {
      "id": "haproxy",
      "name": "HTTP on port 8080",
      "http": "http://localhost:8080",
      "interval": "10s",
      "timeout": "1s"
    }
  }
}

이전 백엔드 서비스와 마찬가지로, haproxy-internal 서비스는 인스턴스가 실행 중인 가용성 영역으로 태그가 지정됩니다. 이렇게 하면, 프런트엔드 애플리케이션이 haproxy-internal.service.consul 이름을 사용하는 모든 부하 분산기에 연결할 수 있고, 조회 이름에 특정 영역을 붙여서 영역별 조회를 가능하게 만듭니다. 예를 들어 us-central1-f.haproxy-internal.service.consulus-central1-f 가용성 영역에 있는 서비스 구성원만 반환합니다.

consul-template을 사용하여 백엔드 서비스의 서버 검색

요청을 부하 분산하기 위해서는 모든 정상 상태의 백엔드 서버의 IP 주소를 알아야 하는 HAProxy 서버 그룹을 만듭니다. 이 솔루션에서는 consul-template을 사용하여 이름이 /etc/haproxy/haproxy.cfg인 HAProxy의 구성 파일을 업데이트하고, 백엔드 서비스의 멤버쉽이 변경될 때마다 HAProxy 서비스를 다시 로드합니다. haproxy.cfg 템플릿 파일에서 이 스니펫은 영역별 us-central1-f.backend 서비스를 보여줍니다. 이 서비스는 반복적으로 수행되며, HAProxy에 대해 사용 가능한 서버를 표시하는 server 지시문을 작성합니다.

listen http-in
        bind *:8080&lcub;{range service "us-central1-f.backend"}}
        server &lcub;{.Node}} &lcub;{.Address}}:&lcub;{.Port}}&lcub;{end}}

consul-template은 다음과 같이 systemd에서 실행됩니다.

consul-template -template "/etc/haproxy/haproxy.ctmpl:/etc/haproxy/haproxy.cfg:service haproxy restart" -retry 30s -max-stale 5s -wait 5s

자세한 내용은 consul_template.service 단위 파일을 참조하세요.

실습: HAProxy 부하 분산기 시작

이 실습 섹션에서는 Packer를 사용하여 HAProxy 부하 분산기 서버에 대한 VM 이미지를 빌드하고, 인스턴스 그룹을 사용하여 서버 클러스터를 만들고 관리합니다.

  1. tool 인스턴스에서 HAProxy 이미지 파일이 포함된 디렉토리로 변경합니다.

    cd ~/compute-internal-loadbalancer/images/haproxy
    
  2. packer를 사용하여 Compute Engine VM 이미지를 빌드합니다. 다음 명령어를 그대로 실행합니다.

    packer build -var project_id=${PROJECT_ID} packer.json
    
  3. 생성된 이미지의 ID를 다음과 같이 복사합니다.

    ==> Builds finished. The artifacts of successful builds are:
    --> googlecompute: A disk image was created: haproxy-1450847630
    

    이 ID를 기록해둡니다. 다음 단계 및 이 솔루션의 후반부에 필요합니다.

  4. 백엔드 서버의 구성을 기술하는 인스턴스 템플릿을 만들고 YOUR_HAPROXY_IMAGE_ID를 이전 단계의 출력으로 바꿉니다.

    gcloud compute instance-templates create haproxy \
      --no-address \
      --metadata="^|^consul_servers=consul-1,consul-2,consul-3" \
      --image=YOUR_HAPROXY_IMAGE_ID
    
  5. 2개의 HAProxy 서버를 시작하는 인스턴스 그룹을 만듭니다.

    gcloud compute instance-groups managed create haproxy \
      --base-instance-name=haproxy \
      --template=haproxy \
      --size=2 \
      --zone=us-central1-f
    

프런트엔드 애플리케이션

이 예에서 프런트엔드 애플리케이션은 HAProxy 부하 분산기를 통해 백엔드의 JSON 출력을 사용하고 이를 HTML로 렌더링합니다.

프런트엔드 애플리케이션을 실행하는 각 인스턴스에는 공개 및 비공개 IP 주소가 포함됩니다. 이러한 인스턴스는 인터넷에서 요청을 수신하고 비공개 IP 주소를 통해 HAProxy에 요청을 수행할 수 있습니다. 샘플 애플리케이션의 소스 코드는 GitHub에서 제공됩니다.

백엔드에 프런트엔드 연결

프런트엔드 애플리케이션은 백엔드 위치를 런타임 플래그로 수락합니다.

gceme -frontend=true -backend-service=http://BACKEND_SERVICE_ADDRESS:PORT

프런트엔드 서버는 또한 Consul 클러스터의 구성원이므로, DNS를 사용해서 HAProxy 서비스를 쉽게 검색하고 프런트엔드 프로세스가 시작될 때 서비스 이름을 backend-service 플래그에 대한 값으로 제공할 수 있습니다.

gceme -frontend=true -backend-service=http://us-central1-f.haproxy-internal.service.consul:8080

DNS 및 Dnsmasq를 사용한 Consul 서비스 검색

Packer 스크립트는 프런트엔드 서버에 dnsmasq를 설치합니다. dnsmasq가 .consul TLD에 대한 쿼리를 확인할 수 있도록 /etc/resolv.conf는 이름 서버로 127.0.0.1을 포함하도록 수정됩니다. 그런 후 consul-template은 HAProxy 서비스에서 부하 분산기의 호스트 이름과 주소를 포함하는 /etc/hosts.consul이라는 두 번째 호스트 파일을 렌더링합니다. /etc/hosts.consul을 생성하기 위한 consul-template 파일은 다음과 같습니다.

&lcub;{range service "$zone.haproxy-internal"&rcub;}
&lcub;{.Address}} $zone.&lcub;{.Name}} $zone.&lcub;{.Name}}.service.consul&lcub;{end}}

consul-template은 이 파일을 렌더링하고 HAProxy 서버가 해당 인스턴스 그룹에서 추가 또는 삭제될 때마다 dnsmasq 서비스를 다시 시작합니다. 렌더링된 /etc/hosts.consul은 다음과 같습니다.

10.240.0.8 us-central1-f.haproxy-internal us-central1-f.haproxy-internal.service.consul
10.240.0.9 us-central1-f.haproxy-internal us-central1-f.haproxy-internal.service.consul

마지막으로 dnsmasq는 이러한 추가 호스트 파일을 사용하도록 구성되며, 프런트엔드 애플리케이션의 haproxy-internal.service.consul에 대한 분석 요청에 응답할 수 있습니다. 인스턴스 구성의 전체 세부정보는 images/frontend 디렉토리에 제공됩니다.

실습: 프런트엔드 애플리케이션 시작

이 실습 섹션에서는 Packer를 사용하여 프런트엔드 서버에 대한 VM 이미지를 빌드한 후 공개 IP 주소를 사용해서 단일 프런트엔드 인스턴스를 시작합니다.

  1. tool 인스턴스에서 프런트엔드 이미지 파일이 포함된 디렉터리로 변경합니다.

    cd ~/compute-internal-loadbalancer/images/frontend
    
  2. 다음 명령어를 실행하여 프런트엔드 서버에 대한 HTTP 액세스를 허용하도록 방화벽 규칙을 만듭니다.

    gcloud compute firewall-rules create frontend-http \
        --source-ranges=0.0.0.0/0 \
        --target-tags=frontend-http \
        --allow=TCP:80
    
  3. packer를 사용하여 Compute Engine 인스턴스 이미지를 빌드합니다. 다음 명령어를 그대로 실행합니다.

    packer build -var project_id=${PROJECT_ID} packer.json
    
  4. 생성된 이미지의 ID를 다음과 같이 복사합니다.

    ==> Builds finished. The artifacts of successful builds are:
    --> googlecompute: A disk image was created: frontend-1450847630
    

    이 ID를 기록해둡니다. 다음 단계 및 이 솔루션의 후반부에 필요합니다.

  5. 공개 IP 주소 및 포트 80을 여는 frontend-http 태그를 사용하여 프런트엔드 인스턴스를 만듭니다. YOUR_FRONTEND_IMAGE_ID는 이전 단계의 출력으로 바꿉니다.

    gcloud compute instances create frontend \
        --metadata="^|^consul_servers=consul-1,consul-2,consul-3" \
        --zone=us-central1-f \
        --tags=frontend-http \
        --image=YOUR_FRONTEND_IMAGE_ID
    
  6. 만들기 작업이 성공하면 인스턴스의 세부정보가 출력됩니다. 출력은 다음 예와 비슷하게 표시됩니다.

    NAME     ZONE          MACHINE_TYPE  PREEMPTIBLE INTERNAL_IP EXTERNAL_IP   STATUS
    frontend us-central1-f n1-standard-1             10.240.0.10 104.197.14.97 RUNNING
    
  7. 터미널 창에서 EXTERNAL_IP의 값을 복사하고 이를 브라우저에서 열어서 프런트엔드 애플리케이션을 확인합니다.

  8. 페이지를 여러 번 새로고침하고 여러 백엔드가 요청을 처리하는 것을 확인합니다.

자동 확장 및 오류 처리

만든 HAProxy 이미지를 사용해서 인스턴스를 시작하면 인스턴스가 Consul에 자신을 자동으로 등록합니다. 이 인스턴스는 DNS를 통해 프런트엔드 인스턴스가 검색할 수 있습니다. 마찬가지로, HAProxy 인스턴스가 실패할 경우, Consul은 해당 실패를 감지하고, 프런트엔드에 dnsmasq를 다시 시작하는 consul-template으로 알림이 제공됩니다. 실패한 인스턴스를 통해서는 요청이 더 이상 라우팅되지 않습니다. 이러한 인스턴스 부트스트랩은 검색 가능하고, 정상적으로 실패하기 때문에, Compute Engine 자동 확장 처리를 쉽게 추가하여 활용도에 따라 부하 분산 용량을 자동으로 추가하거나 삭제할 수 있습니다.

실습: HAProxy 부하 분산기 실패 시뮬레이션

이전에 만든 HAProxy 인스턴스 그룹에는 2개의 인스턴스가 포함되었습니다. 그룹 크기를 1개 인스턴스로 조정해서 다음과 같이 인스턴스 중 하나에서 실패를 시뮬레이션할 수 있습니다.

gcloud compute instance-groups managed resize haproxy --size=1

인스턴스 그룹 관리자는 종료할 인스턴스를 무작위로 선택합니다. Consul에서는 tool 터미널에 이러한 실패를 알리는 알림이 표시됩니다.

2015/12/27 20:00:43 [INFO] memberlist: Suspect haproxy-gg94 has failed, no acks received
2015/12/27 20:00:44 [INFO] serf: EventMemberFailed: haproxy-gg94 10.240.0.8

실패한 인스턴스는 더 이상 서비스의 구성원이 아니며, 이를 제외하도록 프런트엔드 서버가 업데이트됩니다.

consul members를 실행하면 종료된 HAProxy 인스턴스를 볼 수 있습니다. 다음과 비슷한 출력이 표시됩니다.

$ consul members
Node          Address           Status  Type    Build  Protocol  DC
backend-lfwe  10.240.0.6:8301   alive   client  0.6.0  2         dc1
backend-mq5c  10.240.0.7:8301   alive   client  0.6.0  2         dc1
consul-1      10.240.0.5:8301   alive   server  0.6.0  2         dc1
consul-2      10.240.0.3:8301   alive   server  0.6.0  2         dc1
consul-3      10.240.0.4:8301   alive   server  0.6.0  2         dc1
frontend      10.240.0.10:8301  alive   client  0.6.0  2         dc1
haproxy-gg94  10.240.0.8:8301   failed  client  0.6.0  2         dc1
haproxy-tm64  10.240.0.9:8301   alive   client  0.6.0  2         dc1
tool          10.240.0.2:8301   alive   client  0.6.0  2         dc1

실습: HAProxy 자동 확장 사용 설정

기존 인스턴스 그룹에 대해 자동 확장을 사용 설정할 수 있습니다. 자동 확장 처리는 CPU 사용률이나 커스텀 측정항목 또는 둘 다를 기준으로 확장을 지원합니다. 이 예에서는 HAProxy 서버의 집계된 CPU 사용률이 70%를 초과하거나 네트워크 입력률이 초당 1기가비트를 초과할 때 용량을 추가하도록 자동 확장 처리를 구성합니다.

다음 명령어를 사용하여 HAProxy 서버 그룹에 대해 자동 확장을 사용 설정하세요.

gcloud compute instance-groups managed set-autoscaling haproxy \
  --zone=us-central1-f \
  --min-num-replicas=2 \
  --max-num-replicas=8 \
  --scale-based-on-cpu \
  --target-cpu-utilization=.7 \
  --custom-metric-utilization="metric=compute.googleapis.com/instance/network/received_bytes_count,utilization-target=1000000000,utilization-target-type=DELTA_PER_SECOND"

Cloud Deployment Manager를 사용한 다중 영역 배포

Google Cloud Deployment Manager는 Cloud Platform 리소스의 생성 및 관리를 자동화하여 사용자를 위한 서비스 및 애플리케이션 개발에 집중할 수 있게 해주는 인프라 관리 서비스입니다. Cloud Deployment Manager를 사용하면 단 몇 번의 단계로 여러 개의 가용성 영역에서 전체 솔루션을 실행할 수 있습니다.

  1. tool 인스턴스에서 ~/compute-internal-loadbalancer/dm/config.yaml 파일을 편집합니다. 이전 단계에서 Packer로 만든 이미지의 이미지 ID를 삽입합니다.

    ...
    haproxy_image: REPLACE_WITH_YOUR_IMAGE_ID
    backend_image: REPLACE_WITH_YOUR_IMAGE_ID
    frontend_image: REPLACE_WITH_YOUR_IMAGE_ID
    consul_image: REPLACE_WITH_YOUR_IMAGE_ID
    ...
    

    이미지 목록이 준비되지 않았으면 tool 인스턴스에 연결된 터미널 창에서 gcloud compute images list를 실행합니다.

  2. gcloud를 사용하여 전체 아키텍처를 배포합니다.

    gcloud deployment-manager deployments create internal-lb-demo \
        --config=$HOME/compute-internal-loadbalancer/dm/config.yaml
    
  3. 배포가 처리될 때 Cloud Deployment Manager 콘솔 페이지에서 진행 상태를 추적합니다.

  4. 배포가 완료되면 HTTP 부하 분산기 콘솔 페이지를 열고 수신 트래픽 열에서 IP 주소를 클릭하여 프런트엔드에 액세스하고 애플리케이션이 작동 중인지 확인합니다. 배포가 완료된 후 부하 분산기가 요청 처리를 시작하려면 몇 분 정도 걸릴 수 있습니다.

삭제

Consul을 사용한 HAProxy 가이드를 완료한 후에는 이후 요금이 청구되지 않도록 Google Cloud Platform에서 만든 리소스를 삭제할 수 있습니다. 다음 섹션에서는 이러한 리소스를 삭제하거나 사용 중지하는 방법을 설명합니다.

프로젝트 삭제

청구되지 않도록 하는 가장 쉬운 방법은 가이드에서 만든 프로젝트를 삭제하는 것입니다.

프로젝트를 삭제하는 방법은 다음과 같습니다.

  1. GCP Console에서 프로젝트 페이지로 이동합니다.

    프로젝트 페이지로 이동

  2. 프로젝트 목록에서 삭제할 프로젝트를 선택하고 삭제 삭제를 클릭합니다.
  3. 대화상자에서 프로젝트 ID를 입력한 다음 종료를 클릭하여 프로젝트를 삭제합니다.

인스턴스 그룹 삭제

Compute Engine 인스턴스 그룹을 삭제하려면 다음을 사용하세요.

  1. GCP Console에서 인스턴스 그룹 페이지로 이동합니다.

    인스턴스 그룹 페이지로 이동

  2. 다음 옆에 있는 체크박스를 클릭합니다. 삭제할 인스턴스 그룹
  3. 페이지 상단의 삭제 delete를 클릭하여 인스턴스 그룹을 삭제합니다.

인스턴스 삭제

Compute Engine 인스턴스를 삭제하는 방법:

  1. GCP Console에서 VM 인스턴스 페이지로 이동합니다.

    VM 인스턴스 페이지로 이동

  2. 다음 옆에 있는 체크박스를 클릭합니다. 삭제할 인스턴스
  3. 페이지 상단의 삭제 삭제를 클릭하여 인스턴스를 삭제합니다.

디스크 삭제

Compute Engine 디스크를 삭제하려면 다음을 사용하세요.

  1. GCP Console에서 디스크 페이지로 이동합니다.

    디스크 페이지로 이동

  2. 다음 옆에 있는 체크박스를 클릭합니다. 삭제할 디스크
  3. 페이지 상단의 삭제 삭제를 클릭하여 디스크를 삭제합니다.

이미지 삭제

Compute Engine 디스크 이미지를 삭제하려면 다음을 사용하세요.

  1. GCP Console에서 VM 인스턴스 페이지로 이동합니다.

    이미지 페이지로 이동

  2. 삭제하려는 이미지의 체크박스를 클릭합니다.
  3. 삭제 를 클릭하여 이미지를 삭제합니다.

Cloud Deployment Manager 배포 삭제

배포를 삭제하려면 다음 명령어를 실행하세요.

gcloud deployment-manager deployments delete internal-lb-demo

다음 단계

지금까지 비공개 네트워크를 사용하는 Compute Engine 인스턴스에서 HAProxy 및 Consul을 사용하여 확장 가능하고, 복원력이 있는 내부 부하 분산 솔루션을 만드는 방법을 확인했습니다. 또한 부하 분산 계층과 해당 클라이언트를 등록하고 검색하기 위해 서비스 검색이 작동하는 방법을 살펴봤습니다.

이 솔루션을 확장하거나 수정하여 데이터베이스 서버 또는 키-값 저장소와 같은 여러 백엔드 애플리케이션을 지원할 수 있습니다.

내부 부하 분산기를 테스트 로드하는 방법에 대한 자세한 내용은 Kubernetes를 사용한 분산 부하 테스트를 참조하세요.

Google Cloud Platform에서 제공되는 다른 부하 분산 솔루션에 대해 알아보세요.

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

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