NGINX Plus로 AWS Auto Scaling 로드 밸런싱

오늘의 포스트에서는 NGINX Plus로 AWS Auto Scaling 중 Auto Scaling groups 에 로드 밸런싱 하는 방법을 알아보겠습니다.

클라우드의 가장 유용한 기능 중 하나는 컴퓨팅 인스턴스의 수를 자동으로 확장하는 기능입니다. AWS Auto Scaling 을 사용하면 일정이나 수요에 따라 수동 또는 자동으로 Auto Scaling groups 의 EC2 인스턴스 수를 변경할 수 있습니다. Auto Scaling은 인스턴스 수를 현재 워크로드에 적합한 수로 조정하여 비용을 줄이는 데 도움이 됩니다. 또한 Auto Scaling 은 실패한 인스턴스를 다시 시작하여 애플리케이션에 탄력성을 추가합니다.

Auto Scaling을 사용할 때 로드 밸런싱이 중요합니다. AWS는 내장 로드 밸런서인  Elastic Load Balancer(ELB)(현재 공식적으로 Classic Load Balancer라고 함)와 ALB(Application Load Balancer)를 Auto Scaling과 통합하여 Auto Scaling groups 인스턴스의 로드 밸런싱을 제공합니다. NGINX Plus는 AWS를 포함한 모든 클라우드 환경에 대한 고급 클라우드 로드 밸런싱을 제공하며 AWS Auto Scaling groups 을 지원합니다.

NGINX Plus를 기본 제공 AWS 클라우드 로드 밸런서의 대체 또는 추가로 선택하는 세 가지 주요 이유가 있습니다.

  1. NGINX Plus는 ELB 및 ALB에 없는 여러 고급 기능을 제공합니다.
  2. AWS 로드 밸런서(특히 ALB)의 요금 모델은 복잡하여 비용을 예측하기 어렵습니다. NGINX Plus 요금은 연간 구독요금제로 확정 요금형입니다.
  3. NGINX Plus는 플랫폼별 API에 연결하지 않으므로 여러 클라우드 플랫폼에서 로드 밸런싱 구성을 재사용할 수 있습니다.

이 포스트에서는 Auto Scaling groups 의 부하를 분산하도록 NGINX Plus를 구성하는 두 가지 방법을 보여주고 각 방법을 사용하는 것 적합한 경우를 설명합니다.

목차

1. 샘플 AWS Auto Scaling 환경
2. ELB 앞에서 NGINX Plus 사용
3. 통합 소프트웨어와 함께 NGINX Plus 사용
1단계 – AWS API에 대한 액세스 설정
2단계 – 통합 소프트웨어 설치
3단계 – NGINX Plus 구성
4단계 – 통합 소프트웨어 구성
4. 로드 밸런싱 및 확장 테스트
5. NGINX Plus를 고가용성으로 만들기
6. AWS Auto Scaling 올바른 방법 선택
7. AWS Auto Scaling 요약

1. 샘플 AWS Auto Scaling 환경

NGINX Plus를 사용하여 Auto Scaling groups 부하를 분산하는 두 가지 방법을 설명하기 위해 샘플 애플리케이션 환경을 사용하고 있습니다. 백엔드 웹 애플리케이션은 각각 포트 80에 노출되는 두 가지 서비스(backend-one 및 backend-two)로 구성됩니다. 각 서비스에는 여러 애플리케이션 인스턴스의 Auto Scaling groups 이 있습니다. 로드 밸런서는 요청 URI를 기반으로 클라이언트 요청을 적절한 백엔드로 라우팅합니다.

  • /backend‑one 에 대한 요청은 Backend One 으로 이동합니다.
  • /backend‑two 에 대한 요청은 Backend Two 으로 이동합니다.

애플리케이션 Auto Scaling groups 확장할 때(자동 또는 수동) 로드 밸런서 구성을 업데이트하여 새로운 애플리케이션 인스턴스 수를 반영해야 합니다. 내장된 AWS 로드 밸런서는 이 작업을 자동으로 수행합니다. NGINX Plus의 경우 위에서 언급한 방법 중 하나를 사용하여 확장 이벤트를 구성에 추해야 합니다(ELB 앞의 NGINX Plus 또는 통합 소프트웨어가 있는 NGINX Plus).

확장 이벤트에 대한 응답으로 NGINX Plus 구성을 업데이트하는 또 다른 방법은 외부 서비스 레지스트리를 사용하는 것입니다. NGINX Plus는 Consul과 같은 DNS 인터페이스를 제공하는 서비스 검색 시스템과의 통합을 지원합니다. 이 포스트에서는 외부 시스템 사용에 의존하지 않고 설정 및 사용이 쉬운 솔루션에 중점을 둡니다.

2. ELB 앞에서 NGINX Plus 사용

이미 Auto Scaling groups ELB를 사용하고 있는 경우 NGINX Plus의 일부 고급 기능을 애플리케이션에 가져오는 가장 쉬운 방법은 다이어그램에 표시된 대로 ELB 클라우드 로드 밸런서 앞에 NGINX Plus를 배치하는 것입니다.

NGINX Plus를 AWS Auto Scaling 그룹의 클라우드 로드 밸런서로 사용하는 한 가지 방법은 그룹에 대한 로드 밸런싱을 수행하는 ELB에 배치하는 것입니다.

이 경우 NGINX Plus는 하나 이상의 ELB에 대한 프록시/로드 밸런서 역할을 합니다. NGINX Plus는 고급 라우팅 기능을 사용하여 요청 URI를 기반으로 적절한 ELB로 요청을 전달합니다. 그런 다음 ELB는 Auto Scaling groups 의 인스턴스 중 하나로 요청을 전달합니다. 이 구성에서 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;
    }
}
  • resolver 지시문은 NGINX Plus가 내부 ELB 인스턴스의 DNS 이름을 확인하는 데 사용하는 DNS 서버를 정의합니다. 여기서는 AWS DNS 서버의 IP 주소입니다.
  • 서비스인 백엔드 1과 백엔드 2에 해당하는 각 Auto Scaling 그룹에 하나씩 두 개의 upstream 블록을 생성합니다. 트래픽을 로드 밸런싱하는 ELB의 DNS 이름으로 Auto Scaling 그룹을 식별합니다.
  • resolve 매개변수를 사용하여 NGINX Plus에 주기적으로 이름을 다시 확인하도록 지시합니다. 빈도는 유효한 매개변수에 의해 이전 항목에서 논의된 resolver 지시문에 설정됩니다. 여기서는 ELB의 IP 주소가 자주 변경되기 때문에 10초로 설정했습니다.
  • zone 지시문은 확인된 IP 주소를 저장하기 위해 메모리(여기서는 최대 64KB)를 할당합니다.
  • 포트 80에서 수신 대기하는 가상 server를 정의합니다. location 블록은 NGINX Plus가 Backend One Auto Scaling 그룹의 경우 /backend‑one에 대한 요청을 ELB로 전달하고 /backend‑two에 대한 요청을 Backend Two Auto Scaling group의 경우 ELB로 전달하도록 지시합니다.

보시다시피 이 방법은 특히 이미 ELB를 사용하고 있는 경우 설정 및 사용이 쉽습니다. 그러나 몇 가지 단점이 있습니다.

  • 제한된 로드 밸런싱 옵션. NGINX Plus는 백엔드 인스턴스가 아닌 ELB에 요청을 직접 전달하므로 로드 밸런싱을 수행하는 것은 ELB입니다. 이러한 이유로 NGINX Plus의 보다 정교한 로드 밸런싱 알고리즘 및 세션 지속성 옵션을 활용할 수 없습니다.
  • 중복성(Redundancy). NGINX Plus는 로드 밸런싱을 수행할 수 있으므로 ELB는 중복됩니다. 기본적으로 Auto Scaling과 통합되어 있기 때문에 ELB를 사용하고 있습니다.
  • 제한된 프로토콜 지원. NGINX Plus와 달리 ELB는 WebSocket 및 UDP를 지원하지 않습니다.

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

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

이 방법을 사용하면 NGINX Plus와 함께 추가 통합 소프트웨어를 설치합니다. 소프트웨어( nginx-asg-sync )는 Auto Scaling groups 을 지속적으로 모니터링합니다. 스케일링 이벤트가 발생한 것을 확인하면 NGINX Plus 구성에서 백엔드 인스턴스를 추가하거나 제거합니다. 표시된 대로 nginx-asg-sync는 AWS Auto Scaling API를 통해 Auto Scaling groups 의 변경 사항을 학습합니다.

통합 소프트웨어를 사용하려면 다음 단계를 수행하십시오.

지침에서는 백엔드에 대한 Auto Scaling groups 이 이미 존재한다고 가정합니다. 또한 NGINX Plus가 Amazon Linux AMI에서 실행되고 있다고 가정합니다.

1단계 – AWS API에 대한 액세스 설정 (AWS Auto Scaling)

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
  • 우분투:
$ sudo dpkg -i package-name.deb

전체 설치 지침은 GitHub의 설명서를 참조하십시오.

3단계 – NGINX Plus 구성

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

  • 즉석 재구성 및 라이브 활동 모니터링을 위해 API Endpoint를 구성합니다. 통합 소프트웨어는 이러한 Endpoint를 사용하여 업스트림 그룹에서 백엔드 인스턴스를 추가 및 제거합니다.
  • 각 Auto Scaling groups 에 대한 블록을 생성합니다. 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 예에서와 같이 Auto Scaling groups 에 해당하는 두 개의 업스트림 그룹인 backend‑one 및 backend‑two 를 선언합니다. 그러나 여기서는 서버가 nginx‑aws‑sync 에 의해 추가되기 때문에 업스트림 그룹에 서버를 추가하지 않습니다. 지시문 state 은 동적으로 구성 가능한 서버 목록이 저장되는 파일의 이름을 지정하여 NGINX Plus를 다시 시작해도 지속되도록 합니다.
  • 포트 80에서 수신하는 가상을 정의합니다. ELB 예와 달리 NGINX Plus는 /backend‑one 에 대한 요청을 Backend One 그룹의 인스턴스에 직접 전달하고 /backend‑two 에 대한 요청을 백엔드의 인스턴스에 직접 전달합니다.
  • 포트 8080에서 수신하는 두 번째 가상 서버를 정의하고 여기에 NGINX Plus API를 구성합니다.
  • 온더플라이 API는 127.0.0.1:8080/upstream_conf 에서 사용할 수 있습니다.
  • 상태 API는 127.0.0.1:8080/status 에서 사용할 수 있습니다.

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

통합 소프트웨어는 /etc/nginx 폴더의 aws.yaml 파일에서 구성됩니다. 애플리케이션의 경우 다음 구성을 정의합니다.

region: us-west-2
upstream_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
  • region key 는 애플리케이션을 배포하는 AWS 지역을 정의합니다.
  • upstream_conf_endpoint 및 status_endpoint key 는 3단계에서 구성한 NGINX Plus API Endpoint를 정의합니다.
  • sync_interval_in_seconds key 는 동기화 간격을 정의합니다. nginx-asg-sync는 5초마다 스케일링 업데이트를 확인합니다.
  • upstreams key는 upstream 그룹 목록을 정의합니다. 각 upstream 그룹에 대해 다음을 지정합니다.
  • nameupstream– 3단계에서 블록에 지정한 이름.
  • autoscaling_group – 해당 Auto Scaling groups 의 이름.
  • port – 백엔드 서비스가 노출되는 포트.
  • kind – 트래픽 NGINX Plus의 프로토콜은 백엔드 애플리케이션(여기서는 http)에 부하를 분산합니다. 애플리케이션이 TCP/UDP를 사용하는 경우 stream을 대신 지정하십시오.

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

$ sudo restart nginx-asg-sync

4. 로드 밸런싱 및 확장 테스트

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

Auto Scaling groups 을 확장할 때 NGINX Plus가 새 인스턴스를 선택하는 방법을 볼 수 있습니다. 먼저 NGINX Plus 인스턴스의 포트 8080에서 /status.html 에 액세스할 수 있는 라이브 활동 모니터링 대시보드에 액세스합니다. Upstreams 탭 에는 Auto Scaling groups 의 인스턴스가 표시됩니다.

이제 Auto Scaling groups 의 용량을 변경하여 Backend One 그룹을 3개에서 5개 인스턴스로 확장합니다. 새 인스턴스가 시작된 후 nginx-asg-sync는 이를 NGINX Plus 구성에 추가합니다. 곧 새 인스턴스가 대시보드에 나타납니다.

5. NGINX Plus를 고가용성으로 만들기

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

6. AWS Auto Scaling 올바른 방법 선택

그렇다면 Auto Scaling groups 의 로드 밸런싱을 위해 NGINX Plus를 구성하는 어떤 방법이 더 나을까요? 두 가지를 간략하게 비교합니다.

 ELB 앞의 NGINX Plus통합 소프트웨어가 포함된 NGINX Plus
장점간단한 구성 및 추가 소프트웨어 설치 없음.ELB 방법에 따른 제한 없이 모든 NGINX Plus 기능을 최대한 활용할 수 있습니다.
단점지원되는 프로토콜을 포함하여 사용할 수 있는 NGINX Plus 기능의 수를 제한합니다. 배포 비용과 대기 시간이 증가합니다.통합 소프트웨어의 설치 및 구성이 필요합니다.
요약단점이 허용되는 경우 이 방법을 사용하십시오.이 방법을 사용하여 NGINX Plus의 기능을 최대한 활용하십시오.

7. AWS Auto Scaling 요약

AWS Auto Scaling은 수요 수준에 따라 애플리케이션 인스턴스 수를 조정하는 이점을 제공합니다. NGINX Plus는 AWS Auto Scaling groups 과 함께 사용할 수 있는 고급 로드 밸런싱 기능을 제공합니다.

AWS Auto Scaling groups 과 함께 NGINX Plus를 사용해 보십시오. 무료 30일 평가판을 시작 하거나 사용 사례에 대해 논의하려면 당사에 문의하십시오.

또한 NGINX에 대한 최신 소식을 빠르게 전달받고 싶으시면 아래 뉴스레터를 구독하세요.