Amazon에서 적합한 로드 밸런서 선택하기: AWS Application Load Balancer와 NGINX Plus 비교

Owen Garrett제품 관리 부문 수석 이사

2016년 8월, Amazon Web Services(AWS)는 HTTP 및 HTTPS 트래픽의 레이어 7 부하 분산을 위한 Application Load Balancer를 출시했습니다새 제품에는 AWS의 기존 레이어 4 및 레이어 7 로드 밸런서인 Elastic Load Balancer에 없던 여러 기능이 추가되었으며, Elastic Load Balancer는 공식적으로 Classic Load Balancer로 이름이 변경되었습니다.

1년 후, AWS는 향상된 레이어 4 로드 밸런싱을 위해 Network Load Balancer를 출시했으며 이에 따라 AWS에서 고가용성의 확장 가능한 애플리케이션을 실행하는 사용자가 선택할 수 있는 옵션은 다음과 같습니다:

• NGINX Open Source 및 NGINX Plus
• Classic Load Balancer
• 애플리케이션 로드 밸런서(ALB)
• 네트워크 로드 밸런서 (NLB)

이 게시물에서는 ALB의 기능을 살펴보고, 가격과 기능을 NGINX Open Source 및 NGINX Plus와 비교합니다.

참고 –

지원되는 기능에 관한 정보는 2020년 7월 기준으로 정확하지만 변경될 수 있습니다. NGINX Plus와 Classic Load Balancer(이전 명칭: Elastic Load Balancer 또는 ELB)를 직접 비교한 내용과 두 제품을 함께 사용하는 방법에 관한 정보는 다음 이전 블로그 게시물을 참조하세요. 고가용성 NGINX Plus 배포에 NLB를 사용하는 방법에 관한 정보는 다음 이전 블로그 게시물을 참조하세요.

Application Load Balancer의 기능

ALB는 Classic Load Balancer나 NLB와 마찬가지로 AWS에 긴밀하게 통합되어 있습니다. Amazon은 이를 계층 7 로드 밸런서라고 설명하지만, 독립형 계층 7 리버스 프록시 및 로드 밸런서가 제공할 수 있는 폭넓은 기능과 세부 조정, 직접 제어 기능을 모두 제공하지는 않습니다.

ALB는 Classic Load Balancer에는 없는 다음과 같은 기능을 제공합니다:

• 콘텐츠 기반 라우팅 ALB는 요청 URL, Host 헤더와 요청의 필드를 기반으로 하는 콘텐츠 기반 라우팅을 지원합니다. 이러한 필드에는 표준 및 사용자 지정 HTTP 헤더와 메서드, 쿼리 파라미터, 소스 IP 주소가 포함됩니다. (ALB 설명서의 “Classic Load Balancer에서 마이그레이션할 때의 이점”을 참조하세요.)
• 컨테이너 기반 애플리케이션 지원. ALB는 Amazon EC2 Container Service(ECS)에서 호스팅되는 컨테이너에 대한 기존 지원을 개선합니다.
• 더 많은 지표. 마이크로서비스별로 지표를 수집할 수 있습니다.
• WebSocket 지원. ALB는 클라이언트와 서버 간의 지속적인 TCP 연결을 지원합니다.
• HTTP/2 지원. ALB는 HTTP/2를 지원하며, 이는 SSL/TLS로 보호되는 콘텐츠를 전송할 때 더 우수한 대안입니다.

(ALB와 Classic Load Balancer의 전체 기능 비교는 AWS 설명서의 ‘제품 비교’를 참조하세요.)

ALB는 Classic Load Balancer의 제한된 기능으로 어려움을 겪던 AWS 사용자에게 중요한 업데이트였으며, 웹 애플리케이션으로 유입되는 트래픽을 보호하고 최적화하며 제어해야 하는 고급 사용자의 요구 사항을 어느 정도 충족했습니다. 하지만 전용 리버스 프록시(예: NGINX)와 로드 밸런서(예: NGINX Plus)가 제공하는 모든 기능을 지원하지는 않습니다.

AWS에서 트래픽을 제어하는 더 나은 접근 방식

사용자는 Amazon ALB 대신 AWS에 NGINX Open Source 또는 NGINX Plus를 배포하여 트래픽을 제어하고 부하를 분산할 수 있습니다. 또한 여러 가용 영역에서 고가용성을 구현하기 위해 Classic Load Balancer 또는 Network Load Balancer를 프런트엔드로 배포할 수도 있습니다. 다음 표에서는 ALB, NGINX, NGINX Plus에서 지원하는 기능을 비교합니다.

참고: 다음 표의 정보는 2020년 7월 기준으로 정확하지만 변경될 수 있습니다.

* NGINX Controller는 이제 F5 NGINX Management Suite입니다.

물론 기능 체크리스트가 아니라, 높은 보안성과 최대 가용성, 완벽한 제어를 바탕으로 애플리케이션을 원활하게 제공하는 데 필요한 역량을 평가하여 로드 밸런싱 솔루션을 선택해야 합니다.

트래픽 급증 처리

Amazon의 Classic Load Balancer(이전 명칭: ELB)는 트래픽 급증에 제대로 대응하지 못했습니다. 로드 밸런서 인스턴스의 규모는 현재 트래픽 수준에 맞춰 자동으로 조정되었으며, 트래픽이 급증하면 ELB가 이에 대응하여 추가 용량을 배포하는 데 수 분이 걸릴 수 있었습니다. 사용자는 트래픽 급증에 앞서 추가 리소스를 요청하기 위해 양식을 작성하는 수동 절차(“사전 워밍업”이라고 함)를 이용해야 했습니다. ALB는 NGINX를 기반으로 하므로 ALB 인스턴스가 훨씬 더 많은 트래픽을 처리할 수 있지만, 트래픽 급증에 대응하는 확장 이벤트가 여전히 발생할 수 있습니다. 또한 트래픽이 급증하면 Load Balancer Capacity Unit(LCU) 사용량이 자동으로 증가하여 비용도 높아집니다.

로드 밸런싱 프록시를 직접 배포하고 확장하면 용량과 비용을 완벽하게 제어할 수 있습니다. NGINX와 NGINX Plus는 표준 Amazon 인스턴스에 배포되며, 당사의 사이징 가이드에서는 용량이 서로 다른 인스턴스 유형의 잠재적인 최대 성능을 확인할 수 있습니다. NGINX Plus의 가격은 모든 인스턴스 크기에 동일하게 적용되므로 트래픽 급증에 대비해 여유 용량을 배포하는 것이 비용 효율적이며, 더 많은 용량이 필요할 때 별도의 양식을 작성하지 않고도 인스턴스를 신속하게 추가 배포할 수 있습니다.

상태 확인을 통한 장애 서버 감지

Amazon ALB를 테스트한 결과, Amazon ALB는 ‘수동형’ 상태 확인을 구현하지 않는 것으로 나타났습니다. 서버가 예상된 상태 코드를 반환하지 않는다는 사실이 비동기 테스트를 통해 확인된 후에야 해당 서버에 장애가 발생한 것으로 감지됩니다.

인스턴스 클러스터의 부하를 분산하도록 ALB 인스턴스를 생성하여 이 사실을 확인했습니다. 상태 확인 주기는 최소값인 5초로, 실패한 상태 확인의 임계값은 최소값인 2회로 구성한 후 ALB에 지속적으로 요청을 보냈습니다. 인스턴스 중 하나를 중지하자 일부 요청에 대해 ALB가 502 Bad Gateway 오류를 몇 초 동안 반환했으며, 이는 상태 확인에서 해당 인스턴스가 중단된 것을 감지할 때까지 계속되었습니다. 패시브 상태 확인(NGINX와 NGINX Plus 모두 지원)을 사용하면 최종 사용자에게 이러한 유형의 오류가 노출되는 것을 방지할 수 있습니다.

ALB의 상태 확인은 HTTP 상태 코드(예: 200 OK 또는 404 Not Found)를 검사하는 방식으로만 인스턴스의 상태를 판단할 수 있습니다. 이러한 상태 확인은 신뢰하기 어렵습니다. 예를 들어 일부 웹 애플리케이션은 서버에서 생성된 오류를 사용자 친화적인 페이지로 대체하며, 일부 오류는 웹 페이지 본문에만 표시됩니다.

NGINX Plus는 수동 상태 확인과 능동 상태 확인을 모두 지원하며, 능동 상태 확인은 ALB의 상태 확인보다 강력하여 상태 코드뿐만 아니라 응답 본문의 내용도 일치 여부를 확인할 수 있습니다.

가격

마지막으로, ALB를 배포할 때 직면하게 되는 가장 큰 문제는 비용입니다. 로드 밸런싱 비용은 Amazon 청구액에서 상당한 비중을 차지할 수 있습니다.

AWS는 요금을 산정하기 위해 복잡한 알고리즘을 사용합니다. 매월 처리할 신규 연결 수, 동시 연결 수, 데이터 양을 정확히 파악하고(이는 예측하기가 매우 어렵습니다), Amazon과 동일한 방식으로 LCU를 계산할 수 있지 않다면 매달 Amazon 청구서를 걱정하게 될 것입니다.

AWS 기반 NGINX Plus는 비용을 완벽하게 예측할 수 있게 해줍니다. 고정된 시간당 비용과 AWS 호스팅 요금만으로 완벽한 지원이 제공되는 훨씬 더 강력한 부하 분산 솔루션을 이용할 수 있습니다.

결론

NGINX Plus는 검증된 레이어 7 부하 분산 솔루션으로, 레이어 4 부하 분산 기능도 제공합니다. Amazon의 Classic Load Balancer 또는 NLB와 함께 사용하면 효과적입니다.

AWS 환경에서 이미 매우 인기 있는 솔루션인 NGINX와 NGINX Plus를 지속적으로 더 많이 활용하시기를 권장합니다. 아직 NGINX Plus 사용자가 아니라면 지금 30일 무료 평가판을 시작하거나 사용 사례에 대해 논의하려면 문의해 주세요.

작성자 소개

Owen Garrett제품 관리 부문 수석 이사

Owen Garrett의 다른 블로그 게시물