NGINX Plus를 활용한 AWS Auto Scaling 그룹 로드 밸런싱

Michael Pleshakov

클라우드의 가장 유용한 기능 중 하나는 컴퓨팅 인스턴스 수를 자동으로 확장하거나 축소할 수 있다는 것입니다. AWS Auto Scaling을 사용하면 일정이나 수요에 따라 Auto Scaling 그룹의 EC2 인스턴스 수를 수동 또는 자동으로 변경할 수 있습니다. Auto Scaling은 현재 워크로드에 적합한 수로 인스턴스 수를 조정하여 비용을 절감하는 데 도움이 됩니다. 또한 Auto Scaling은 장애가 발생한 인스턴스를 다시 시작하여 애플리케이션의 복원력을 높여 줍니다.

Auto Scaling을 사용할 때는 부하 분산이 매우 중요합니다. AWS는 자체 기본 제공 로드 밸런서인 Elastic Load Balancer(ELB, 현재 공식 명칭은 Classic Load Balancer) 및 Application Load Balancer(ALB)를 Auto Scaling과 통합하여 Auto Scaling 그룹의 인스턴스에 대한 부하 분산을 제공합니다. NGINX Plus는 AWS를 비롯한 모든 클라우드 환경에 고급 클라우드 부하 분산 기능을 제공하며 AWS Auto Scaling 그룹을 지원합니다.

기본 제공되는 AWS 클라우드 로드 밸런서를 대체하거나 보완하기 위해 NGINX Plus를 선택해야 하는 주요 이유는 세 가지입니다:

1. NGINX Plus는 ELB와 ALB에는 없는 다양한 고급 기능을 제공합니다.
2. AWS 로드 밸런서(특히 ALB)의 요금 모델은 복잡하여 비용을 예측하기 어렵습니다. NGINX Plus는 당사에서 NGINX Plus 구독을 직접 구매하거나, 시간당 고정 요금으로 청구되는 사전 구축된 NGINX Plus 인스턴스를 AWS Marketplace에서 실행하는 경우 모두 요금 체계가 명확합니다.
3. NGINX Plus는 특정 플랫폼 전용 API에 종속되지 않으므로 여러 클라우드 플랫폼에서 부하 분산 구성을 재사용할 수 있습니다.

NGINX Plus가 AWS 기본 제공 솔루션과 어떻게 비교되고 함께 작동하는지 알아보려면 다음에 관한 블로그 게시물을 읽어보세요: ELB 및 ALB.

이 블로그 게시물에서는 Auto Scaling 그룹의 부하를 분산하도록 NGINX Plus를 구성하는 두 가지 방법을 소개하고, 각 방법을 언제 사용하는 것이 적합한지 설명합니다.

1. ELB 앞단에서 NGINX Plus 사용
2. NGINX, Inc.에서 제공하는 통합 소프트웨어와 함께 NGINX Plus 사용

이 블로그 게시물을 읽고 나면 Auto Scaling 그룹에 고급 부하 분산 기능을 제공하도록 AWS에 NGINX Plus를 배포할 수 있습니다.

AWS Auto Scaling 환경 예시

NGINX Plus를 사용하여 Auto Scaling 그룹의 부하를 분산하는 두 가지 방법을 설명하기 위해 샘플 애플리케이션 환경을 사용합니다. 백엔드 웹 애플리케이션은 Backend One과 Backend Two라는 두 개의 서비스로 구성되며, 각 서비스는 포트 80을 통해 제공됩니다. 각 서비스에는 여러 애플리케이션 인스턴스로 구성된 Auto Scaling 그룹이 있습니다. 로드 밸런서는 요청 URI를 기준으로 클라이언트 요청을 적절한 백엔드로 라우팅합니다:

• Requests for /backend‑one에 대한 요청은 Backend One으로 전달됩니다.
• Requests for /backend‑two에 대한 요청은 백엔드 2로 전달됩니다.

애플리케이션 Auto Scaling 그룹을 자동 또는 수동으로 확장하거나 축소할 때는 변경된 애플리케이션 인스턴스 수가 반영되도록 로드 밸런서 구성을 업데이트해야 합니다. AWS에 기본 제공되는 로드 밸런서는 이 작업을 자동으로 수행합니다. NGINX Plus의 경우 위에서 언급한 방법 중 하나(ELB 앞에 NGINX Plus 배치 또는 통합 소프트웨어와 함께 NGINX Plus 사용)를 통해 스케일링 이벤트를 구성에 반영해야 합니다.

스케일링 이벤트에 대응하여 NGINX Plus 구성을 업데이트하는 또 다른 방법은 외부 서비스 레지스트리를 사용하는 것입니다. NGINX Plus는 DNS 인터페이스를 제공하는 Consul과 같은 서비스 검색 시스템과의 통합을 지원합니다. 이 블로그 게시물에서는 외부 시스템에 의존하지 않으며 간편하게 설정하고 사용할 수 있는 솔루션을 중점적으로 살펴봅니다.

ELB 앞단에서 NGINX Plus 사용

이미 Auto Scaling 그룹과 ELB를 사용하고 있다면, NGINX Plus의 몇 가지 고급 기능을 애플리케이션에 적용하는 가장 쉬운 방법은 다음 다이어그램과 같이 ELB 클라우드 로드 밸런서 앞에 NGINX Plus를 배치하는 것입니다:

이 경우 NGINX Plus는 하나 이상의 ELB에 대한 프록시/로드 밸런서 역할을 합니다. NGINX Plus는 고급 라우팅 기능을 사용하여 요청 URI를 기준으로 적절한 ELB에 요청을 전달합니다. 그러면 ELB가 Auto Scaling 그룹의 인스턴스 중 하나로 요청을 전달합니다. 이 구성에서는 ELB가 확장을 지원합니다.

다음은 NGINX Plus 구성입니다.

resolver 169.254.169.253 valid=10s;
upstream backend-one {
    zone backend-one 64k;
    server DNS-name-of-ELB-for-Backend-One resolve;
}

upstream backend-two {
    zone backend-two 64k;
    server DNS-name-of-ELB-for-Backend-Two resolve;
}

server {
    listen 80;

    location /backend-one {
        proxy_set_header Host $host;
        proxy_pass http://backend-one;
    }

    location /backend-two {
        proxy_set_header Host $host;
        proxy_pass http://backend-two;
    }
}

• The resolver 지시문은 NGINX Plus가 내부 ELB 인스턴스의 DNS 이름을 확인하는 데 사용하는 DNS 서버를 정의합니다. 여기서는 AWS DNS 서버의 IP 주소입니다.
• 서비스인 Backend One과 Backend Two에 해당하는 각 Auto Scaling 그룹마다 하나씩, 총 두 개의 upstream 블록을 생성합니다. 트래픽을 해당 그룹으로 로드 밸런싱하는 ELB의 DNS 이름으로 Auto Scaling 그룹을 식별합니다. resolve 매개변수를 사용하여 NGINX Plus가 이름을 주기적으로 다시 확인하도록 합니다. 확인 주기는 앞의 글머리 기호에서 설명한 resolver 지시문의 valid 매개변수로 설정합니다. 여기서는 ELB의 IP 주소가 자주 변경될 수 있으므로 10초로 설정합니다. zone 지시문은 확인된 IP 주소를 저장하기 위한 메모리(여기서는 최대 64 KB)를 할당합니다.
• 포트 80에서 수신 대기하는 가상 server를 정의합니다. location 블록은 NGINX Plus가 /backend‑one에 대한 요청을 Backend One Auto Scaling 그룹의 ELB로 전달하고, /backend‑two에 대한 요청을 Backend Two Auto Scaling 그룹의 ELB로 전달하도록 지시합니다.

보시다시피 이 방법은 설정과 사용이 간편하며, 특히 이미 ELB를 사용 중인 경우 더욱 그렇습니다. 하지만 몇 가지 단점이 있습니다:

• 제한된 부하 분산 옵션. NGINX Plus는 요청을 백엔드 인스턴스에 직접 전달하지 않고 ELB에 전달하므로, 실제 부하 분산은 ELB가 수행합니다. 따라서 NGINX Plus의 더욱 정교한 부하 분산 알고리즘과 세션 지속성 옵션을 활용할 수 없습니다.
• 중복성. NGINX Plus가 부하 분산을 수행할 수 있으므로 ELB는 불필요합니다. ELB를 사용하는 이유는 Auto Scaling과 기본적으로 통합되어 있기 때문입니다.
• 제한적인 프로토콜 지원. NGINX Plus와 달리 ELB는 WebSocket과 UDP를 지원하지 않습니다.

다음 방법은 ELB에 의존하지 않으므로 이러한 단점이 없습니다.

통합 소프트웨어와 함께 NGINX Plus 사용

이 방법에서는 NGINX Plus와 함께 추가 통합 소프트웨어를 설치합니다. 이 소프트웨어(nginx-asg-sync)는 Auto Scaling 그룹을 지속적으로 모니터링합니다. 확장 또는 축소 이벤트가 발생하면 NGINX Plus 구성에서 백엔드 인스턴스를 추가하거나 제거합니다. 그림과 같이 nginx-asg-sync는 AWS Auto Scaling API를 통해 Auto Scaling 그룹의 변경 사항을 파악합니다.

통합 소프트웨어를 사용하려면 다음 단계를 수행하세요:

1. AWS API에 대한 액세스 설정
2. 통합 소프트웨어 설치
3. NGINX Plus 구성
4. 통합 소프트웨어 구성

이 지침에서는 백엔드용 Auto Scaling 그룹이 이미 존재하고 NGINX Plus가 Amazon Linux AMI에서 실행 중이라고 가정합니다.

1단계 – AWS API에 대한 액세스 설정

Auto Scaling API와의 통신에는 인증이 필요하므로 nginx-asg-sync에 사용할 자격 증명을 제공해야 합니다. AWS는 IAM 역할을 사용하여 자격 증명을 처리하므로 NGINX Plus 인스턴스를 시작하기 전에 해당 인스턴스에 사용할 역할을 생성해야 합니다. 단계별 지침은 AWS 설명서의 Amazon EC2용 IAM 역할을 참조하세요.

1. IAM 역할을 생성하고 사전 정의된 AmazonEC2ReadOnlyAccess 정책을 연결합니다. 이 정책은 EC2 API에 대한 읽기 전용 액세스를 허용합니다.
2. NGINX Plus 인스턴스를 시작할 때 이 IAM 역할을 인스턴스에 추가합니다.

2단계 – 통합 소프트웨어 설치

통합 소프트웨어를 설치하려면 nginx-asg-sync GitHub 리포지토리에서 운영 체제에 맞는 패키지를 다운로드한 후 NGINX Plus가 실행 중인 인스턴스에 설치합니다.

• Amazon Linux, CentOS 및 RHEL의 경우:

$ sudo rpm -i package-name.rpm

• Ubuntu의 경우:

$ sudo dpkg -i package-name.deb

전체 설치 지침은 GitHub의 문서를 참조하세요.

3단계 – NGINX Plus 구성

통합 소프트웨어는 동적 재구성 및 실시간 활동 모니터링 API를 사용하여 NGINX Plus 구성을 업데이트합니다. 소프트웨어가 제대로 작동하려면 이러한 API를 구성하고 필요한 업스트림 그룹을 선언해야 합니다:

• 즉시 재구성 및 실시간 활동 모니터링을 위한 API 엔드포인트를 구성합니다. 통합 소프트웨어는 이러한 엔드포인트를 사용하여 업스트림 그룹에 백엔드 인스턴스를 추가하거나 제거합니다.
• 각 Auto Scaling 그룹에 대해 upstream 블록을 생성합니다. 블록에 서버를 정의하지 마세요. 확장 이벤트에 따라 nginx-asg-sync가 서버를 자동으로 추가하고 제거합니다.

다음 예시는 간단한 웹 애플리케이션의 구성을 보여 줍니다:

upstream backend-one {    zone backend-one 64k;
    state /var/lib/nginx/state/backend-one.conf;
}

upstream backend-two {
    zone backend-two 64k;
    state /var/lib/nginx/state/backend-two.conf;
}

server {
    listen 80;

    status_zone backend;

    location /backend-one {
        proxy_set_header Host $host;
        proxy_pass http://backend-one;
    }

    location /backend-two {
        proxy_set_header Host $host;
        proxy_pass http://backend-two;
    }
}

server {
    listen 8080;

    root /usr/share/nginx/html;

    location = / {
        return 302 /status.html;
    }

    location = /status.html {}

    location /status {
        access_log off;
        status;
    }

    location /upstream_conf {
        upstream_conf;
    }
}

• ELB 예제와 마찬가지로 두 개의 업스트림 그룹인 backend‑one과 backend‑two를 선언합니다. 이 그룹들은 각각 Auto Scaling 그룹에 해당합니다. 하지만 여기서는 업스트림 그룹에 서버를 추가하지 않습니다. 서버는 nginx‑aws‑sync에 의해 추가되기 때문입니다. state 지시문은 동적으로 구성 가능한 서버 목록이 저장되는 파일을 지정하여 NGINX Plus가 다시 시작된 후에도 목록이 유지되도록 합니다.
• 포트 80에서 수신 대기하는 가상 server를 정의합니다. ELB 예제와 달리 NGINX Plus는 /backend‑one 요청을 Backend One 그룹의 인스턴스로 직접 전달하고, /backend‑two 요청은 Backend Two 그룹의 인스턴스로 직접 전달합니다.
• 포트 8080에서 수신 대기하는 두 번째 가상 서버를 정의하고 여기에 NGINX Plus API를 구성합니다:
  • 온더플라이 API는 다음 주소에서 사용할 수 있습니다. 127.0.0.1:8080/upstream_conf
  • 상태 API는 다음 주소에서 사용할 수 있습니다: 127.0.0.1:8080/status

4단계 – 통합 소프트웨어 구성

통합 소프트웨어는 aws.yaml 파일에서 구성되며, 이 파일은 /etc/nginx 폴더에 있습니다. 애플리케이션에 대해 다음과 같이 구성합니다:

region: us-west-2upstream_conf_endpoint: http://127.0.0.1:8080/upstream_conf
status_endpoint: http://127.0.0.1:8080/status
sync_interval_in_seconds: 5
upstreams:
 - name: backend-one
   autoscaling_group: backend-one-group
   port: 80
   kind: http
 - name: backend-two
   autoscaling_group: backend-two-group
   port: 80
   kind: http

• The region 키는 애플리케이션을 배포할 AWS 리전을 정의합니다.
• The upstream_conf_endpoint 및 status_endpoint 키는 3단계에서 구성한 NGINX Plus API 엔드포인트를 정의합니다.
• The sync_interval_in_seconds 키는 동기화 간격을 정의합니다. nginx-asg-sync는 5초마다 스케일링 업데이트를 확인합니다.
• The upstreams 키는 업스트림 그룹 목록을 정의합니다. 각 업스트림 그룹에 대해 다음을 지정합니다.
  • name – 3단계에서 upstream 블록에 지정한 이름입니다.
  • autoscaling_group – 해당 Auto Scaling 그룹의 이름입니다.
  • port – 백엔드 서비스가 노출되는 포트입니다.
  • kind – NGINX Plus가 백엔드 애플리케이션으로 로드 밸런싱하는 트래픽의 프로토콜입니다. 여기서는 http입니다. 애플리케이션이 TCP/UDP를 사용하는 경우에는 stream을 대신 지정합니다.

After you edit the aws.yaml 파일을 편집한 후 소프트웨어를 다시 시작합니다:

$ sudo restart nginx-asg-sync

부하 분산 및 확장 테스트

위 단계에서는 애플리케이션의 Auto Scaling 그룹에 대한 부하를 분산하도록 NGINX Plus를 구성했습니다. 이제 이를 테스트할 수 있습니다. NGINX Plus는 /backend‑one URI가 포함된 요청을 Backend One 그룹의 인스턴스에 분산하고, /backend‑two URI가 포함된 요청을 Backend Two 그룹의 인스턴스에 분산합니다.

Auto Scaling 그룹을 확장할 때 NGINX Plus가 새 인스턴스를 감지하는 방식을 확인할 수 있습니다. 먼저 실시간 활동 모니터링 대시보드에 접속합니다. 이 대시보드는 NGINX Plus 인스턴스의 포트 8080에서 /status.html 경로를 통해 액세스할 수 있습니다. Upstream 탭에서 Auto Scaling 그룹의 인스턴스를 확인할 수 있습니다.

이제 Auto Scaling 그룹의 용량을 변경하여 Backend One 그룹을 인스턴스 3개에서 5개로 확장합니다. 새 인스턴스가 시작되면 nginx-asg-sync가 해당 인스턴스를 NGINX Plus 구성에 추가합니다. 잠시 후 새 인스턴스가 대시보드에 표시됩니다:

NGINX Plus 고가용성 구현

지금까지는 NGINX Plus 인스턴스를 하나만 시작했습니다. 하지만 고가용성을 위해 NGINX Plus 자체에 대한 Auto Scaling 그룹을 생성하고 NGINX Plus 인스턴스 앞에 ELB를 사용하는 것이 좋습니다. ELB 대신 Route 53을 사용하여 트래픽을 NGINX Plus 인스턴스로 라우팅할 수도 있습니다. ELB를 사용하는 배포 구성도는 다음과 같습니다:

적절한 방법 선택하기

그렇다면 Auto Scaling 그룹의 부하를 분산하도록 NGINX Plus를 구성하는 두 가지 방법 중 어떤 것이 더 적합할까요? 다음 표에서 두 방법을 간략히 비교합니다.

ELB 앞단의 NGINX Plus 통합 소프트웨어를 사용하는 NGINX Plus장점 구성이 간단하며 추가 소프트웨어를 설치할 필요가 없습니다. ELB 방식으로 인한 제약 없이 NGINX Plus의 모든 기능을 온전히 활용할 수 있습니다.단점 지원되는 프로토콜을 비롯해 사용할 수 있는 NGINX Plus 기능의 수가 제한됩니다. 배포 비용과 지연 시간이 증가합니다. 통합 소프트웨어를 설치하고 구성해야 합니다.요약 단점을 감수할 수 있다면 이 방식을 사용하십시오. NGINX Plus의 기능을 최대한 활용하려면 이 방식을 사용하십시오.

요약

AWS Auto Scaling은 수요 수준에 맞게 애플리케이션 인스턴스 수를 조정할 수 있는 이점을 제공합니다. NGINX Plus는 AWS Auto Scaling 그룹과 함께 사용할 수 있는 고급 부하 분산 기능을 제공합니다.

AWS Auto Scaling 그룹에서 NGINX Plus를 사용해 보세요. 30일 무료 평가판을 시작하거나 문의하여 사용 사례에 대해 상담해 보세요.

작성자 소개

Michael Pleshakov

Michael Pleshakov의 다른 블로그 게시물