Amazon에서 올바른 로드 밸런서 선택: AWS 애플리케이션 로드 밸런서와 비교 NGINX 플러스

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

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

• NGINX 오픈 소스 및 NGINX Plus
• 클래식 로드 밸런서
• 애플리케이션 로드 밸런서 (ALB)
• 네트워크 로드 밸런서 (NLB)

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

참고사항–

 

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

 

애플리케이션 로드 밸런서의 기능

ALB는 Classic Load Balancer나 NLB와 마찬가지로 AWS와 긴밀하게 통합되어 있습니다. Amazon에서는 이를 7계층 로드 밸런서라고 설명하지만 단독 7계층 역방향 프록시 및 로드 밸런서가 제공할 수 있는 모든 기능, 튜닝 및 직접 제어를 제공하지는 않습니다.

ALB는 Classic Load Balancer에서 누락된 다음과 같은 기능을 제공합니다.

• 콘텐츠 기반 라우팅. ALB는 요청 URL, 호스트 헤더, 표준 및 사용자 정의 HTTP 헤더와 메서드, 쿼리 매개변수, 소스 IP 주소를 포함하는 요청의 필드를 기반으로 하는 콘텐츠 기반 라우팅을 지원합니다. ( ALB 설명서 의 "클래식 로드 밸런서에서 마이그레이션하는 이점"을 참조하세요.)
• 컨테이너 기반 애플리케이션 지원 ALB는 Amazon의 EC2 Container Service(ECS)에서 호스팅되는 컨테이너에 대한 기존 지원을 개선합니다.
• 더 많은 측정항목. 마이크로서비스별로 메트릭을 수집할 수 있습니다.
• 웹소켓 지원. ALB는 클라이언트와 서버 간의 지속적인 TCP 연결을 지원합니다.
• HTTP/2 지원. ALB는 SSL/TLS로 보안된 콘텐츠를 전송할 때 뛰어난 대안인 HTTP/2를 지원합니다.

(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 컨트롤러는 이제 F5 NGINX 관리 제품군 입니다.

물론, 기능 체크리스트가 아닌 완벽한 보안, 최대 가용성, 완벽한 제어 기능을 갖추고 애플리케이션을 완벽하게 제공하는 데 필요한 기능을 평가하여 로드 밸런싱 선택을 평가해야 합니다.

교통량 급증 처리

Amazon의 Classic Load Balancer(이전 ELB)는 트래픽 급증에 대한 대응력이 부족했습니다. 로드 밸런서 인스턴스는 현재 트래픽 수준에 맞게 자동으로 크기가 조정되었으며, 트래픽이 급증하면 ELB가 응답하고 추가 용량을 배포하는 데 몇 분이 걸릴 수 있습니다. 사용자는 트래픽 급증에 앞서 추가 리소스를 요청하기 위해 수동 양식 기반 프로세스에 의존해야 했습니다(이를 "사전 워밍"이라고 함). ALB는 NGINX 기반이므로 ALB 인스턴스는 훨씬 더 많은 트래픽을 처리할 수 있지만 트래픽 급증에 대한 대응으로 여전히 크기 조정 이벤트가 발생할 수 있습니다. 게다가 트래픽 급증은 자동으로 로드 밸런서 용량 단위(LCU)의 소모가 더 커지고 결과적으로 비용도 증가합니다.

부하 분산 프록시를 직접 배포하고 확장하면 용량과 비용을 완벽하게 제어할 수 있습니다. NGINX와 NGINX Plus는 표준 Amazon 인스턴스 내에 배포되며, 크기 가이드는 다양한 용량을 갖춘 인스턴스 유형의 잠재적인 최대 성능을 나타냅니다. NGINX Plus의 가격은 모든 인스턴스 크기에 동일하므로 급증하는 트래픽을 처리하기 위해 초과 용량을 배포하는 것이 비용 효율적이며, 더 많은 용량이 필요할 때 양식을 작성할 필요 없이 빠르게 더 많은 인스턴스를 배포할 수 있습니다.

상태 검사를 통한 실패한 서버 감지

Amazon ALB에 대한 테스트 결과, "수동" 상태 검사를 구현하지 않는 것으로 나타났습니다. 비동기 테스트를 통해 예상된 상태 코드가 반환되지 않는다는 것이 확인되면 서버가 실패한 것으로 감지됩니다.

우리는 인스턴스 클러스터의 부하를 분산하기 위해 ALB 인스턴스를 생성하면서 이를 발견했습니다. 최소 5초 간격과 최소 2번의 검사 실패 임계값으로 상태 검사를 구성하고 ALB에 꾸준한 요청 스트림을 보냈습니다. 인스턴스 중 하나를 중지했을 때 일부 요청에 대해 ALB가 다음을 반환했습니다. 502 나쁜 게이트웨이 인스턴스가 다운된 것을 상태 검사에서 감지할 때까지 몇 초 동안 오류가 발생했습니다. 수동 상태 검사(NGINX와 NGINX Plus에서 모두 지원)를 통해 이러한 유형의 오류가 최종 사용자에게 드러나는 것을 방지할 수 있습니다.

ALB의 상태 검사는 HTTP 상태 코드(예:)를 검사하여 인스턴스의 상태만 확인할 수 있습니다. 200확인 또는 404찾을 수 없음 ). 이러한 상태 검사는 신뢰할 수 없습니다. 예를 들어, 일부 웹 애플리케이션은 서버에서 생성된 오류를 사용자 친화적인 페이지로 바꾸고, 일부 오류는 웹 페이지 본문에만 보고됩니다.

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일 체험판을 시작하거나 저희에게 문의하여 사용 사례에 대해 논의해 보세요 .