NGINX Plus를 사용한 AWS 자동 확장 그룹 로드 밸런싱

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

자동 크기 조정을 사용할 때 부하 분산이 중요합니다. AWS는 기본 제공 로드 밸런서인 Elastic Load Balancer(ELB, 현재는 공식적으로 Classic Load Balancer라고 함)와 Application Load Balancer(ALB)를 Auto Scaling과 통합하여 Auto Scaling 그룹 인스턴스의 로드 밸런싱을 제공합니다. NGINX Plus는 AWS를 포함한 모든 클라우드 환경에 대한 고급 클라우드 로드 밸런싱을 제공하고 AWS 자동 확장 그룹을 지원합니다.

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

1. NGINX Plus는 ELB 및 ALB에 없는 여러 가지 고급 기능을 제공합니다.
2. AWS 로드 밸런서(특히 ALB)의 가격 모델은 복잡하여 비용을 예측하기 어렵습니다. NGINX Plus 가격 책정은 간단합니다. NGINX Plus 구독을 당사에서 직접 구매하거나 AWS Marketplace 에서 사전 구축된 NGINX Plus 인스턴스를 실행하는 경우, 고정된 시간당 요금으로 청구됩니다.
3. NGINX Plus는 플랫폼별 API에 구애받지 않으므로 여러 클라우드 플랫폼에서 로드 밸런싱 구성을 재사용할 수 있습니다.

NGINX Plus가 AWS 내장 솔루션과 어떻게 비교되는지(그리고 함께 작동하는지) 알아보려면 ELB 및 ALB 에 대한 블로그 게시물을 읽어보세요.

이 블로그 게시물에서는 NGINX Plus를 구성하여 자동 크기 조정 그룹의 부하를 분산하는 두 가지 방법을 보여주고 각 방법을 사용하는 것이 합리적인 경우를 설명합니다.

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

이 블로그 게시물을 읽은 후에는 AWS에 NGINX Plus를 배포하여 자동 크기 조정 그룹에 대한 고급 부하 분산을 제공할 준비가 될 것입니다.

샘플 AWS 자동 확장 환경

NGINX Plus를 사용하여 자동 크기 조정 그룹의 부하를 분산하는 두 가지 방법을 설명하기 위해 샘플 애플리케이션 환경을 사용하고 있습니다. 백엔드 웹 애플리케이션은 두 개의 서비스, 즉 백엔드 1과 백엔드 2로 구성되며 각각 포트 80에 노출됩니다. 각 서비스에는 여러 애플리케이션 인스턴스의 자동 크기 조정 그룹이 있습니다. 로드 밸런서는 요청 URI에 따라 클라이언트 요청을 적절한 백엔드로 라우팅합니다.

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

애플리케이션 자동 크기 조정 그룹을 확장할 때(자동 또는 수동), 로드 밸런서 구성을 업데이트하여 새로운 애플리케이션 인스턴스 수를 반영해야 합니다. 내장된 AWS 로드 밸런서는 이를 자동으로 수행합니다. NGINX Plus의 경우 위에 언급된 방법 중 하나(ELB 앞에 있는 NGINX Plus 또는 통합 소프트웨어와 함께 있는 NGINX Plus)를 사용하여 구성에 스케일링 이벤트를 전파해야 합니다.

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

ELB 앞에서 NGINX Plus 사용

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

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

NGINX Plus 구성은 다음과 같습니다.

리졸버 169.254.169.253 유효=10초; 업스트림 백엔드-원 { 존 백엔드-원 64k; 서버 백엔드-원에 대한 ELB의 DNS 이름 확인; } 업스트림 백엔드-투 { 존 백엔드-투 64k; 서버 백엔드- 투에 대한 ELB의 DNS 이름 확인; } 서버 { 수신 80; 위치 /백엔드-원 { 프록시_세트_헤더 호스트 $호스트; 프록시_패스 http://백엔드-원; } 위치 /백엔드-투 { 프록시_세트_헤더 호스트 $호스트; 프록시_패스 http://백엔드-투; } }

• resolver 지시문은 NGINX Plus가 내부 ELB 인스턴스의 DNS 이름을 확인하는 데 사용하는 DNS 서버를 정의합니다. AWS DNS 서버의 IP 주소입니다.

• 우리는 각 자동 확장 그룹, 즉 백엔드 1과 백엔드 2에 해당하는 서비스마다 하나씩, 총 두 개의 업스트림 블록을 생성합니다. 트래픽 부하를 분산하는 ELB의 DNS 이름으로 자동 확장 그룹을 식별합니다.

  resolve 매개변수를 사용하여 NGINX Plus에 주기적으로 이름을 다시 확인하도록 지시합니다. 빈도는 이전 항목에서 설명한 resolver 지시문에 대한 유효한 매개변수를 통해 설정됩니다. 여기서는 ELB의 IP 주소가 자주 변경되므로 10초로 설정했습니다.

  zone 지시어는 확인된 IP 주소를 저장하기 위해 메모리(여기서는 최대 64KB)를 할당합니다.

• 포트 80에서 수신하는 가상 서버를 정의합니다. 위치 블록은 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 )는 자동 확장 그룹을 지속적으로 모니터링합니다. 스케일링 이벤트가 발생한 것을 확인하면 NGINX Plus 구성에서 백엔드 인스턴스를 추가하거나 제거합니다. 표시된 대로 nginx-asg-sync는 AWS Auto Scaling API를 통해 Auto Scaling 그룹의 변경 사항을 학습합니다.

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

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

이 지침에서는 백엔드에 대한 자동 크기 조정 그룹이 이미 존재한다고 가정합니다. 또한 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 패키지 이름 .rpm
  

• 우분투의 경우:

  $ sudo dpkg -i 패키지 이름 .deb
  

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

3단계 – NGINX Plus 구성

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

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

다음 예는 간단한 웹 애플리케이션에 대한 구성을 나타냅니다.

업스트림 백엔드-1 { 존 백엔드-1 64k;
상태 /var/lib/nginx/state/backend-one.conf;
}

업스트림 백엔드-2 {
존 백엔드-2 64k;
상태 /var/lib/nginx/state/backend-two.conf;
}

서버 {
수신 80;

상태_존 백엔드;

위치 /backend-one {
프록시_설정_헤더 호스트 $host;
프록시_패스 http://backend-one;
}

위치 /backend-two {
프록시_설정_헤더 호스트 $host;
프록시_패스 http://backend-two;
}
}

서버 {
수신 8080;

루트 /usr/share/nginx/html;

위치 = / {
반환 302 /status.html;
}

location = /status.html {}

location /status {
access_log off;
status;
}

location /upstream_conf {
upstream_conf;
}
}

• ELB 예에서와 같이 우리는 자동 크기 조정 그룹에 해당하는 두 개의 업스트림 그룹인 backend‑one 과 backend‑two를 선언합니다. 하지만 여기에서는 nginx‑aws‑sync 에 의해 서버가 추가되므로 업스트림 그룹에 어떤 서버도 추가하지 않습니다. state 지시어는 동적으로 구성 가능한 서버 목록이 저장되는 파일의 이름을 지정하여 NGINX Plus를 다시 시작해도 해당 목록이 유지되도록 합니다.
• 포트 80에서 수신하는 가상 서버를 정의합니다. 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단계 – 통합 소프트웨어 구성

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

지역: us-west-2upstream_conf_endpoint: http://127.0.0.1:8080/upstream_conf
상태_엔드포인트: http://127.0.0.1:8080/status
동기화_간격_초: 5
업스트림:
- 이름: 백엔드-원
자동 확장 그룹: 백엔드-원-그룹
포트: 80
종류: http
- 이름: 백엔드-투
자동 확장 그룹: 백엔드-투-그룹
포트: 80
종류: http

• 지역 키는 애플리케이션을 배포하는 AWS 지역을 정의합니다.
• upstream_conf_endpoint 및 status_endpoint 키는 3단계 에서 구성한 NGINX Plus API 엔드포인트를 정의합니다.
• sync_interval_in_seconds 키는 동기화 간격을 정의합니다. nginx-asg-sync는 5초마다 스케일링 업데이트를 확인합니다.

• 업스트림 키는 업스트림 그룹 목록을 정의합니다. 각 상류 그룹에 대해 다음을 지정합니다.

  • name – 3단계에서 업스트림 블록에 지정한 이름입니다.
  • autoscaling_group – 해당 자동 크기 조정 그룹의 이름입니다.
  • 포트 – 백엔드 서비스가 노출되는 포트입니다.
  • 종류 – NGINX Plus가 백엔드 애플리케이션에 부하를 분산하는 트래픽의 프로토콜, 여기 http . 애플리케이션이 TCP/UDP를 사용하는 경우 대신 스트림을 지정하세요.

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

$ sudo nginx-asg-sync를 다시 시작합니다.

로드 밸런싱 및 스케일링 테스트

위의 단계에서 우리는 NGINX Plus를 구성하여 애플리케이션의 자동 확장 그룹에 대한 부하를 분산했습니다. 이제 테스트해 볼 수 있습니다. NGINX Plus는 /backend‑one URI가 있는 요청을 Backend One 그룹 인스턴스에 분산하고, /backend‑two URI가 있는 요청을 Backend Two 그룹 인스턴스에 분산합니다.

NGINX Plus가 자동 확장 그룹을 확장할 때 어떻게 새로운 인스턴스를 선택하는지 살펴보겠습니다. 먼저, NGINX Plus 인스턴스의 포트 8080에서 /status.html 로 접근할 수 있는 라이브 활동 모니터링 대시보드에 액세스합니다. 업스트림 탭에서 자동 크기 조정 그룹의 인스턴스를 확인할 수 있습니다.

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

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

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

올바른 방법 선택하기

그렇다면 자동 크기 조정 그룹의 부하를 분산하기 위해 NGINX Plus를 구성하는 방법 중 어떤 것이 더 좋을까요? 다음 표에서는 두 가지를 간략하게 비교합니다.

요약

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

AWS Auto Scaling 그룹과 함께 NGINX Plus를 사용해 보세요. 무료 30일 평가판을 시작하거나 저희에게 문의하여 사용 사례에 대해 논의해 보세요 .