Amazon Load Balancer 선택: AWS Application Load Balancer vs NGINX Plus
이번 포스트에서는 Application Load Balancer(ALB)의 기능을 NGINX 및 NGINX Plus와 비교합니다.
2016년 8월, Amazon Web Services(AWS)는 HTTP 및 HTTPS 트래픽의 Layer 7 Load Balancing을 위한 애플리케이션 Load Balancer를 도입했습니다. 이 신제품은 공식적으로 Classic Load Balancer로 이름이 변경된 AWS의 기존 Layer 4 및 Layer 7 Load Balancer인 Elastic Load Balancer에서 누락된 몇 가지 기능을 추가했습니다.
1년 후, AWS는 향상된 Layer 4 Load Balancing을 위해 Network Load Balancer를 출시했습니다. 따라서 AWS에서 고가용성과 확장성이 뛰어난 애플리케이션을 실행하는 사용자를 위한 선택 항목은 다음과 같습니다.
- NGINX 및 NGINX Plus
- Classic Load Balancer
- Application Load Balancer (ALB)
- Network Load Balancer (NLB)
목차
1. Application Load Balancer(ALB)의 기능
2. AWS에서 트래픽 제어를 위한 더 나은 접근 방식
3. 트래픽 급증 처리
4. 헬스 체크(Health Check)로 장애가 발생한 서버 감지
5. Application Load Balancer(ALB) 가격
6. 결론
1. Application Load Balancer(ALB)의 기능
Classic Load Balancer 또는 NLB와 같은 ALB는 AWS에 긴밀하게 통합됩니다. Amazon은 이것을 Layer 7 Load Balancer라고 설명합니다. 그러나 독립형 Layer 7 Reverse Proxy 및 Load Balancer가 제공할 수 있는 모든 기능, 조정 및 직접 제어를 제공하지는 않습니다.
Application Load Balancer(ALB)는 Classic Load Balancer에서 누락된 다음 기능을 제공합니다.
- 콘텐츠 기반 라우팅 – ALB는 요청 URL, 호스트 헤더, 표준 및 사용자 정의 HTTP 헤더와 메서드, 쿼리 매개변수, Source IP 주소를 포함하는 요청의 필드를 기반으로 콘텐츠 기반 라우팅을 지원합니다. (ALB 설명서의 “Classic Load Balancer에서 마이그레이션의할 경우의 이점” 을 참조하십시오.)
- 컨테이너 기반 애플리케이션을 지원 – ALB는 Amazon의 EC2 Container Service(ECS)에서 호스팅되는 컨테이너에 대한 기존 지원을 개선합니다.
- 더 많은 메트릭(Metrics) – Microservices 단위로 메트릭을 수집할 수 있습니다.
- WebSocket 지원 – ALB는 클라이언트와 서버 간의 지속적인 TCP 연결을 지원합니다.
- HTTP/2 지원 – ALB는 SSL/TLS로 보안된 콘텐츠를 제공할 때 우수한 대안인 HTTP/2를 지원합니다.
Application Load Balancer와 Classic Load Balancer의 전체 기능 비교는 AWS 설명서의 “제품 비교“를 참조하십시오.
Application Load Balancer는 Classic Load Balancer의 제한된 기능 세트로 어려움을 겪고 있는 AWS 사용자를 위한 중요한 업데이트였으며 웹 애플리케이션에 대한 트래픽을 보호, 최적화 및 제어할 수 있어야 하는 고급 사용자의 요구 사항을 해결하는 데 어느 정도 도움이 되었습니다. 그러나 여전히 전용 Reverse Proxy(NGINX 등) 및 Load Balancer(NGINX Plus 등)의 모든 기능을 제공하지는 않습니다.
2. AWS에서 트래픽 제어를 위한 더 나은 접근 방식
사용자는 Amazon Application Load Balancer를 사용하는 대신 AWS에 NGINX 또는 NGINX Plus를 배포하여 트래픽을 제어하고 Load Balancing할 수 있습니다. 또한 여러 가용 영역에서 고가용성을 달성하기 위해 Classic Load Balancer 또는 Network Load Balancer를 Frontend로 배포할 수 있습니다. 다음 표는 ALB, NGINX 및 NGINX Plus에서 지원하는 기능을 비교합니다.
| Amazon Application Load Balancer | NGINX | NGINX Plus | |
| Load Balancing 방법 및 특징 | Round_robin 및 least_outstanding_requests 메서드, 쿠키 기반 세션 지속성, 가중 대상 그룹(Weighted Target Groups) 및 느린 시작(Slow Start) | 가중 Upstream 서버를 사용하는 여러 Load Balancing 방법(라운드 로빈, 최소 연결, 해시, IP 해시 및 랜덤 포함) | NGINX와 동일하며 최소 시간 방법, 더 많은 세션 지속 방법 및 느린 시작(Slow Start) |
| 캐싱(Caching) | ❌ Load Balancer의 캐싱이 지원되지 않음 | ✅ 정적 파일 캐싱 및 동적(애플리케이션) 캐싱 | ✅ 정적 파일 캐싱 및 동적(애플리케이션) 캐싱 |
| 헬스 체크(Health Checks) | Active(비동기 검사를 위해 반환된 상태 코드를 확인하여 실패한 서버 식별) | Passive(클라이언트 요청에 대한 응답을 확인하여 실패한 서버 식별) | Active and Passive – Active 검사는 ALB보다 더 풍부하게 구성 가능합니다. |
| 고가용성 | HA 여러 가용 영역에 ALB 인스턴스를 배포할 수 있지만 지역 간에는 배포할 수 없습니다. | NLB가 있는 Active‑Active HA 및 탄력적 IP주소가 있는 Active‑Passive HA | NGINX와 동일하며, 모든 NGINX Plus 인스턴스에서 원활한 HA를 위한 내장 클러스터 상태 공유 |
| IP 제품군의 모든 프로토콜 지원 | ❌ HTTP 및 HTTPS 전용 | ✅ TCP 및 UDP, Passive 헬스 체크 기능 포함 | ✅ TCP 및 UDP, Active, Passive 헬스 체크 기능 포함 |
| Load Balancer 인스턴스당 여러 애플리케이션 | ✅ | ✅ | ✅ |
| 콘텐츠 기반 라우팅 | ✅ 요청 URL, 호스트 헤더, 표준 및 사용자 지정 HTTP 헤더, 메서드, 쿼리 매개변수, Source IP 주소를 포함한 요청 필드 기반 | ✅ ALB와 동일한 요소, NGINX JavaScript 모듈을 Inline JavaScript 엔진으로 사용하는 쿠키 및 동적 계산을 기반으로 합니다. | ✅ NGINX와 동일한 요소와 Key‑Value Store 의 JWT 클레임 및 값을 기반으로 합니다. |
| 컨테이너화된 애플리케이션 | Amazon ID, ECS 컨테이너 인스턴스, Auto Scaling 그룹 및 AWS Lambda 함수에 대한 Load Balancing 가능 | 수동 구성 또는 구성 템플릿 필요 | SRV 레코드를 포함한 DNS를 사용한 자동 구성, 주요 Registry 서비스와 함께 작동 |
| 휴대성 | ❌ 모든 환경(개발, 테스트 및 Production)은 AWS에 있어야 합니다. | ✅ 모든 환경은 모든 배포 플랫폼에 있을 수 있습니다. | ✅ 모든 환경은 모든 배포 플랫폼에 있을 수 있습니다. |
| SSL/TLS | ✅ SNI를 지원하는 멀티 SSL/TLS 인증서 ❌ SSL/TLS Upstream 검증이 지원되지 않음 | ✅ SNI를 지원하는 멀티 SSL/TLS 인증서 ✅ SSL/TLS 암호의 전체 선택 ✅ SSL/TLS Upstream의 전체 검증 | ✅ SNI를 지원하는 멀티 SSL/TLS 인증서 ✅ SSL/TLS 암호의 전체 선택 ✅ SSL/TLS Upstream의 전체 검증 |
| HTTP/2 및 WebSocket | ✅ | ✅ | ✅ |
| 인증 기능 | – OIDC, SAML, LDAP, AD IdP 인증 옵션 – AWS Cognito 및 CloudFront와 통합 | 멀티 인증 옵션 | 멀티 인증 옵션 |
| 고급 기능 | ❌ 베어본(Barebones) API | ✅ 오리진 서비스(Origin Serving), 우선 순위 지정, 속도 제한 등 | ✅ NGINX와 동일, RESTful API, Key‑Value Store |
| Logging 및 디버깅 | ✅ Amazon binary 로그 형식 | ✅ 사용자 지정 가능한 로그 파일 및 여러 디버그 인터페이스 | ✅ 완전히 사용자 지정 가능한 로그 파일 및 여러 디버그 인터페이스, NGINX에서 완벽하게 지원 |
| 모니터링 도구 | ✅ Amazon CloudWatch와 통합 | ✅ NGINX Controller 및 기타 타사 도구 | ✅ NGINX Controller 및 기타 타사 도구, 통계에 보고된 확장 세트 |
| 공식 기술 지원 | ✅ 추가 비용으로 | ❌ 커뮤니티 지원만 해당 | ✅ 가격에 포함되며 NGINX Support가 제공됩니다. |
| 프리 티어(Free tier) | ✅ 처음 750시간 | ✅ 언제나 무료 | ✅ 30일 Trial 구독 |
물론 Load Balancing 선택은 기능 체크리스트가 아니라 높은 보안, 최대 가용성 및 완벽한 제어를 통해 애플리케이션을 완벽하게 제공하는 데 필요한 기능을 평가하여 평가해야 합니다.
3. 트래픽 급증 처리
Amazon의 Classic Load Balancer(이전 ELB)는 트래픽 급증에 대한 대응이 좋지 않아 어려움을 겪었습니다. Load Balancer 인스턴스는 현재 트래픽 수준에 맞게 자동으로 크기가 조정되었으며, 트래픽 급증이 발생하면 ELB가 응답하고 추가 용량을 배포하는 데 몇 분이 걸릴 수 있습니다. 사용자는 트래픽 급증에 앞서 추가 리소스를 요청하기 위해 수동 양식 기반 프로세스에 의존해야 했습니다. ALB는 NGINX를 기반으로 하기 때문에 ALB 인스턴스가 훨씬 더 많은 트래픽을 처리할 수 있지만 트래픽 급증에 대응하여 이벤트를 확장할 수 있습니다. 또한 트래픽 급증은 자동으로 Load Balancer 용량 단위(LCU)의 소비를 증가시켜 결과적으로 비용을 증가시킵니다.
Load Balancing Proxy를 직접 배포하고 확장하면 용량과 비용을 완벽하게 제어할 수 있습니다. NGINX 및 NGINX Plus는 표준 Amazon 인스턴스 내에 배포되며, Sizing 가이드는 용량이 다른 인스턴스 유형의 잠재적인 피크 성능을 나타냅니다. NGINX Plus의 가격은 모든 인스턴스 크기에 대해 동일하므로 트래픽 급증을 처리하기 위해 초과 용량을 배포하는 것이 비용 효율적이며, 더 많은 용량이 필요할 때 양식 없이 더 많은 인스턴스를 신속하게 배포할 수 있습니다.
4. 헬스 체크(Health Check)로 장애가 발생한 서버 감지
Amazon Application Load Balancer 테스트 결과 “Passive” 헬스 체크을 구현하지 않는 것으로 나타났습니다. 서버는 비동기 테스트에서 예상한 상태 코드를 반환하지 않음을 확인한 경우에만 서버가 실패한 것으로 감지됩니다.
인스턴스 클러스터 Load Balancing하기 위해 ALB 인스턴스를 생성하여 이를 발견했습니다. 최소 5초 빈도와 최소 임계값 2회 실패로 헬스 체크을 구성하고 ALB에 꾸준한 요청 Stream을 보냈습니다. 인스턴스 중 하나를 중지했을 때 일부 요청에 대해 ALB는 헬스 체크에서 인스턴스가 중단되었음을 감지할 때까지 몇 초 동안 502 Bad Gateway 오류를 반환했습니다. Passive 헬스 체크(NGINX 및 NGINX Plus에서 모두 지원됨)는 이러한 유형의 오류가 최종 사용자에게 표시되지 않도록 합니다.
Application Load Balancer의 헬스 체크는 HTTP 상태 코드(예: 200 OK 또는 404 Not Found)를 검사해야만 인스턴스의 상태를 확인할 수 있습니다. 이러한 상태 확인은 신뢰할 수 없습니다. 예를 들어 일부 웹 애플리케이션은 서버에서 생성된 오류를 사용자에게 친숙한 페이지로 대체하고 일부 오류는 웹 페이지 본문에서만 보고됩니다.
NGINX Plus는 Passive 및 Active 헬스 체크를 모두 지원하며, 후자는 ALB보다 더 강력하며, 상태 코드뿐만 아니라 응답 본문과도 일치할 수 있습니다.
5. Application Load Balancer(ALB) 가격
마지막으로, Application Load Balancer를 배포할 때 직면하는 가장 큰 문제는 비용입니다. Load Balancing은 Amazon 청구서에서 중요한 부분을 차지할 수 있습니다.
AWS는 복잡한 알고리즘을 사용하여 요금을 결정합니다. 새로운 연결 수, 동시 연결 수, 매월 관리할 데이터의 양(예측하기 매우 어려움)을 정확하게 알고 Amazon과 동일한 방식으로 LCU 계산을 실행할 수 없다면 매월 Amazon 청구서를 걱정하게 될 것입니다.
NGINX Plus는 완벽한 예측 가능성을 제공합니다. 시간당 고정 비용과 AWS 호스팅 비용으로 완전한 지원을 통해 훨씬 더 강력한 Load Balancing 솔루션을 얻을 수 있습니다.
6. 결론
NGINX Plus는 Layer 4 Load Balancing 기능을 포함 Layer 7 Load Balancing을 위한 검증된 솔루션입니다. Amazon 자체 Classic Load Balancer 또는 NLB와 연동하여 잘 작동합니다.
AWS 환경에서 이미 널리 사용되는 솔루션 개요를 확인하고 NGINX Plus 성능을 직접 테스트 및 사용해 보려면 지금 30일 무료 평가판을 신청하거나 사용 사례에 대해 최신 소식을 빠르게 전달받고 싶으시면 아래 뉴스레터를 구독하세요.
