AWS ELB 와 함께 NGINX Plus 로드 밸런싱 사용

Amazon Web Services (AWS) 를 사용하는 고객들은 종종 로드 밸런싱에 NGINX Plus 또는 Amazon Elastic Load Balancing( ELB )을 사용해야 하는지에 대해 묻습니다. 아마존은 NGINX Plus를 AWS에서 설정하는 방법을 설명하는 백서를 발행했습니다. 본 포스트에서는 NGINX Plus와 ELB 중에서 선택할 때 고려해야 할 요소 및 두 가지 모두 사용해야 하는 상황에 대해 다룹니다.

목차

1. AWS ELB 개요
2. NGINX Plus의 기능
 2-1. Routing 요청
 2-2. URL Rewrite 및 Redirection
 2-3. 고급 애플리케이션 Active Health Checks
 2-4. WebSocket 및 HTTP/2 지원
 2-5. Rate Limiting
 2-6. 다중 로드 밸런싱 알고리즘
3. AWS ELB의 기능
 3-1. AWS ELB Auto Scaling
 3-2. AWS ELB Route 53 Health Checks
4. NGINX Plus 및 AWS ELB 결합 기능
 4-1. Active-Active 고가용성
 4-2. NGINX Plus 인스턴스에 대한 AWS ELB의 Auto Scaling
 4-3. AWS ELB Auto Scaling Backend 인스턴스
5. Access Logging
6. 요약

1. AWS ELB 개요

Amazon Elastic Load Balancing ( ELB )는 AWS와 강하게 통합되어 고가용성 인프라를 제공하도록 설계되었지만, NGINX Plus와 같은 다양한 Layer 7 기능을 갖추고 있지는 않습니다. NGINX Plus와 ELB 의 기능 중복으로 인해 올바른 솔루션을 선택하는 것이 항상 명확하지는 않지만, 일반적으로 ELB 는 여러 AWS 존과 지역 간에 고가용성을 유지하면서 간단한 로드 밸런싱이 필요한 경우 좋은 선택이며, NGINX Plus는 매우 기본적인 Layer 7 기능 이상이 필요한 경우 좋은 선택입니다. 둘을 함께 사용하면 ELB 와 NGINX Plus 인스턴스의 Active-Active 고가용성 클러스터를 포함하여 매우 완벽한 솔루션을 제공할 수 있습니다.

다음은 NGINX Plus와 ELB 에서 사용 가능한 일부 기능을 보여주는 행렬입니다.

이제 NGINX Plus와 ELB 의 몇 가지 기능 차이점과 두 가지를 결합할 때 사용할 수 있는 기능에 대해 설명하겠습니다.

2. NGINX Plus의 기능

NGINX Plus만을 사용하는 보편적인 사용 사례는 단일 가용 영역에서 하나의 NGINX Plus 인스턴스가 애플리케이션의 수요를 충족하는 경우입니다. 그리고 여러 AWS 지역에 이러한 NGINX Plus 인스턴스가 있다면 Amazon Route 53을 사용하여 트래픽을 분산시킬 수 있습니다.

NGINX Plus는 다음과 같은 Layer 7 기능을 제공합니다. ELB 에서는 이러한 기능이 덜 제공되거나 전혀 제공되지 않습니다.

2-1. Routing 요청

NGINX Plus는 URL, 요청 헤더, 쿠키 등을 기반으로 요청을 라우팅할 수 있습니다. ELB 의 경우, 특정 DNS 이름과 포트로 들어오는 모든 요청은 동일한 Backend 서버 세트로 전송됩니다. NGINX Plus를 사용하면 Backend 서버 풀 또는 Upstream 그룹을 여러 개 사용할 수 있습니다. 예를 들어, .html, .jpg, .gif 또는 .png로 끝나는 URL은 하나의 Upstream 그룹으로, .php로 끝나는 모든 요청은 다른 그룹으로 보낼 수 있습니다. 또는 /store로 시작하는 모든 요청은 하나의 Upstream 그룹으로, /support로 시작하는 모든 요청은 다른 그룹으로 보낼 수 있습니다.

2-2. URL Rewrite 및 Redirection

NGINX Plus는 백엔드 서버로 전달되기 전에 들어오는 요청의 URL을 다시 작성할 수 있어 파일의 위치를 변경하지만 클라이언트에게 공지된 URL을 변경하지 않아도 되는 경우에 유용합니다. 또한 NGINX Plus는 요청을 Redirection 할 수 있습니다. 가장 간단한 경우는 모든 HTTP 요청을 HTTPS 서버로 Redirection 하는 것입니다.

2-3. 고급 애플리케이션 Active Health Checks

NGINX Plus를 구성하여 프록시하는 서버의 상태를 확인할 수 있습니다. HTTP 애플리케이션 Health Checks를 원하는 경우 요청될 URL과 헤더를 지정하여 사용자 정의할 수 있습니다. 또한 유효한 응답 코드와 응답 본문에 포함되어야 하는 문자열을 지정할 수 있습니다. TCP/UDP Health Checks를 통해 전송할 문자열과 서버가 반환(return)해야 하는 문자열을 지정할 수도 있습니다.

HTTP 및 TCP/UDP Health Checks, Health Checks 간격, NGINX Plus가 응답을 기다리는 시간, 노드가 다운될 때까지 연속적으로 실패한 횟수를 지정할 수 있습니다. 또한, 노드가 다시 정상적으로 돌아온 후에도 즉시 전체 트래픽을 받지 않도록 ‘slow-start’ 기능을 구성할 수 있습니다. 이렇게 하면 NGINX Plus가 지정한 시간 동안 노드에 대한 트래픽을 서서히 늘리도록 할 수 있습니다.

ELB도 HTTP 및 TCP Health Checks를 제공하지만, HTTP 응답 본문 또는 TCP 응답 문자열을 지정할 수 없으며, 노드가 다운될 때까지 연속적으로 실패한 횟수를 설정할 수 없습니다. 또한, ELB는 UDP 트래픽을 처리하지 않습니다.

2-4. WebSocket 및 HTTP/2 지원

NGINX Plus는 WebSocket 및 HTTP/2 애플리케이션의 부하를 분산하고 프록시할 수 있습니다. ELB에는 현재 이 기능이 없습니다.

2-5. Rate Limiting

NGINX Plus는 여러 제한을 구성하여 NGINX Plus 인스턴스 간의 트래픽을 제어할 수 있습니다. 이러한 제한은 인바운드 연결, Backend 노드 연결, 인바운드 요청 속도 및 클라이언트로부터 NGINX Plus 및 백엔드 서버로부터 NGINX Plus로의 데이터 전송 속도 등이 포함됩니다.

2-6. 다중 로드 밸런싱 알고리즘

로드 밸런싱 구성 시, NGINX Plus는 사용할 알고리즘을 선택할 수 있도록 제공합니다. 라운드 로빈, 최소 연결(Least Connections), 최소 시간(Least Time), IP 해시(Hash), 해시(Hash) 등이 있습니다. 반면 ELB는 TCP 로드 밸런싱에는 라운드 로빈을, HTTP 및 HTTPS 트래픽에는 Least Outstanding Request (최소 연결과 유사)를 사용합니다.

3. AWS ELB 의 기능

NGINX Plus의 Layer 7 기능 중 어느 것도 필요하지 않은 경우, ELB를 가용성 있는 로드 밸런싱 솔루션으로 사용할 수 있으며, Route 53을 통해 가용 영역 및 지역 간에도 사용할 수 있습니다. 또한 다음 단락에서 설명하는 NGINX Plus에서 사용할 수 없는 기능을 제공할 수 있습니다.

3-1. AWS ELB Auto Scaling

ELB Auto Scaling은 전체 로드의 변화에 ​​따라 로드 밸런싱 되는 Backend 노드의 수를 늘리거나 줄이는 기능을 제공합니다.

3-2. AWS ELB Route 53 Health Checks

Route 53을 활성화하여 ELB에 대한 Health Checks를 자동으로 구성하고 관리할 수 있습니다. NGINX Plus와 함께 Route 53을 사용하는 경우 사용자 지정 Health Checks를 구성할 수 있습니다.

4. NGINX Plus 및 AWS ELB 결합 기능

NGINX Plus와 ELB를 함께 사용하여 두 제품의 상위 기능과 다음 단락에서 설명하는 추가 기능을 활용할 수 있습니다.

4-1. Active-Active 고가용성

ELB를 사용하여 NGINX Plus 인스턴스 간에 로드 밸런싱을 수행하면 Active-Active 인스턴스 세트를 생성하여 가용성을 높일 수 있습니다.

4-2. NGINX Plus 인스턴스에 대한 AWS ELB의 Auto Scaling

ELB Auto Scaling을 사용하여 부하에 따라 NGINX Plus 인스턴스 수를 늘리거나 줄일 수도 있습니다.

4-3. AWS ELB Auto Scaling Backend 인스턴스

NGINX Plus의 Layer 7 기능을 활용하면서 ELB Auto Scaling을 이용하여 Backend 서버 인스턴스 수를 확장하거나 축소할 수 있습니다. 이를 위해 ELB를 NGINX Plus 뒤에 배치하고 Backend 서버 앞에 두면 됩니다.

5. Access Logging

NGINX Plus와 ELB는 모두 접근 로깅을 지원하지만, 정확한 기능은 다릅니다. NGINX Plus는 로컬 디스크 또는 syslog로 로깅할 수 있으며 로깅할 값의 매우 많은 세트를 제공합니다. ELB는 Amazon S3로 직접 로그를 기록하고 로깅할 값을 구성할 수 있지만, 가능한 값 목록은 덜 포괄적입니다. AWS에서 실행하는 모든 애플리케이션에 대한 로깅을 S3로 집중화하는 것은 매우 편리할 수 있으며, ELB는 기본적으로 이를 수행합니다. NGINX Plus 로깅을 S3로 집중화하려면, NGINX Plus를 S3에 로그를 기록하도록 구성된 syslog 서버에 연결하면 됩니다.

6. 요약

앞서 설명한 바와 같이 NGINX Plus 및 ELB는 개별적으로 또는 함께 여러 구성에서 애플리케이션 로드 밸런싱에 사용할 수 있습니다. 다음 다이어그램은 각 구성 요소를 사용할 수 있는 위치를 보여줍니다.

ELB는 부하 분산 요구 사항이 간단한 경우에는 좋은 선택이며, 고가용성 및 Auto Scaling 기능이 뛰어납니다. NGINX Plus는 부하 분산 요구 사항이 더 복잡한 경우에는 좋은 선택입니다. 두 가지를 함께 사용하면 NGINX Plus의 고급 부하 분산 기능과 AWS ELB의 Active-Active 고가용성 및 Auto Scaling 기능을 모두 활용할 수 있습니다.

NGINX Plus를 사용해 보려면 오늘 무료 30일 체험을 시작하거나 사용 사례에 대해 문의하십시오.