계층 로드 밸런싱

중요

이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 고객과 기존 고객 모두 사용할 수 없습니다. 고객은 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션할 것을 강력히 권장합니다. 마이그레이션에 대해 궁금한 점이 있으면 AWS re:Post 또는 Premium AWS Support를 통해 AWS Support 팀에 문의하세요.

AWS OpsWorks 스택은 Elastic Load Balancing과 HAProxy라는 두 가지 로드 밸런싱 옵션을 제공합니다. 이 옵션은 일반적으로 애플리케이션 서버 계층의 인스턴스 전반에서 부하를 분산하는 데 사용됩니다. 이 주제에서는 계층에 로드 밸런싱을 추가할 때 어떤 옵션을 선택할지 결정하는 데 도움이 되도록 각 옵션의 이점과 제약을 설명합니다. 일부의 경우 두 옵션을 모두 사용하는 것이 최선의 방법입니다.

SSL 종료

내장 HAProxy 계층은 SSL 종료를 처리하지 않습니다. 따라서 서버에서 SSL을 종료해야 합니다. 이 접근 방식의 장점은 트래픽이 서버에 도달할 때까지 암호화된다는 것입니다. 하지만 서버가 암호 해독을 처리해야 하므로 서버 로드가 증가합니다. 또한 애플리케이션 서버에 SSL 인증서를 배치해야 하는데, 애플리케이션 서버는 사용자가 액세스하기 더 쉽습니다.

Elastic Load Balancing을 사용하면 로드 밸런서에서 SSL을 종료할 수 있습니다. 이렇게 하면 애플리케이션 서버의 부하가 줄어들지만 로드 밸런서와 서버 간의 트래픽은 암호화되지 않습니다. Elastic Load Balancing을 사용하면 서버에서 SSL을 종료할 수도 있지만 설정하기가 다소 복잡합니다.

스케일링

수신 트래픽이 HAProxy 로드 밸런서의 용량을 초과할 경우 수동으로 용량을 증가해야 합니다.

Elastic Load Balancing은 수신 트래픽을 처리하기 위해 자동으로 확장됩니다. Elastic Load Balancing 로드 밸런서가 처음 온라인으로 전환될 때 예상 로드를 처리하는 데 충분한 용량을 갖추게 하려면 로드 밸런서를 사전 워밍할 수 있습니다.

로드 밸런서 장애

HAProxy 서버를 호스팅하는 인스턴스에 장애가 발생할 경우 인스턴스를 재시작할 수 있을 때까지 전체 사이트가 오프라인이 될 수 있습니다.

Elastic Load Balancing은 HAProxy보다 장애 방지 기능이 더 강합니다. 예를 들어, EC2 인스턴스가 등록된 각 가용 영역에 로드 밸런싱 노드를 프로비저닝합니다. 한 영역에서 서비스가 중단되면 다른 노드가 계속해서 수신 트래픽을 처리합니다. 자세한 내용은 Elastic Load Balancing Concepts를 참조하세요.

유휴 제한 시간

두 유형의 로드 밸런서는 모두 서버가 지정된 제한 시간 값보다 오래 유휴 상태를 유지할 경우 연결을 종료합니다.

• HAProxy - 유휴 제한 시간 값에 상한이 없습니다.

• Elastic Load Balancing – 기본 유휴 제한 시간 값이 60초이며 최대값은 3,600초(60분)입니다.

대부분의 경우 Elastic Load Balancing 유휴 제한 시간은 충분합니다. 이보다 긴 유휴 제한 시간이 필요할 경우 HAProxy를 사용하는 것이 좋습니다. 예:

• 푸시 알림에 사용되는 장시간 HTTP 연결.

• 60분 이상 소요되는 작업을 수행하기 위해 사용하는 관리 인터페이스.

URL 기반 매핑

로드 밸런서가 수신 요청을 요청의 URL에 따라 특정 서버로 전달해야 할 수 있습니다. 예를 들어 온라인 상거래 애플리케이션을 지원하는 애플리케이션 서버 10개의 그룹이 있다고 가정합시다. 서버 중 8개는 카탈로그를 처리하고 2개는 결제를 처리합니다. 요청 URL을 기반으로 모든 결제 관련 HTTP 요청을 결제 서버로 보내려고 합니다. 이 경우, "payment" 또는 "checkout"을 포함하는 모든 URL을 결제 서버 중 하나로 리디렉션합니다.

HAProxy에서는 URL 기반 매핑을 사용하여 지정된 문자열을 포함하는 URL을 특정 서버로 리디렉션할 수 있습니다. AWS OpsWorks 스택에서 URL 기반 매핑을 사용하려면 기본 제공 쿡북의 템플릿을 재정의하여 사용자 지정 HAProxy 구성 파일을 생성해야 합니다. haproxy-default.erb haproxy 자세한 정보는 HAProxy Configuration Manual 및 사용자 지정 템플릿 사용 단원을 참조하세요. HTTPS 요청에는 URL 기반 매핑을 사용할 수 없습니다. HTTPS 요청은 암호화됩니다. 따라서 HAProxy가 요청 URL을 검사할 방법이 없습니다.

Elastic Load Balancing은 URL 매핑을 제한적으로 지원합니다. 자세한 내용은 Elastic Load Balancing의 리스너 구성을 참조하세요.

권장 사항: HAProxy에서만 처리할 수 있는 요구 사항이 아니라면 로드 밸런싱에 Elastic Load Balancing을 사용할 것을 권장합니다. 이 경우 가장 좋은 방법은 Elastic Load Balancing을 HAProxy 서버 집합으로 수신 트래픽을 분산하는 프런트 엔드 로드 밸런서로 사용하여 두 유형을 결합하는 것이 최선의 방법일 수 있습니다. 방법:

• 스택의 각 가용 영역에서 HAProxy 인스턴스를 설정하여 요청을 영역의 애플리케이션 서버로 분산합니다.

• HAProxy 인스턴스를 Elastic Load Balancing 로드 밸런서에 할당합니다. 그러면 수신 요청이 HAProxy 로드 밸런서로 분산됩니다.

이 접근 방식은 HAProxy의 URL 기반 매핑을 사용하여 다양한 유형의 요청을 적절한 애플리케이션 서버로 분산할 수 있습니다. 하지만 HAProxy 서버 중 하나가 오프라인으로 전환될 경우 Elastic Load Balancing 로드 밸런서가 자동으로 수신 트래픽을 정상 상태의 HAProxy 서버로 분산하므로 사이트는 기능을 유지합니다. 단, Elastic Load Balancing을를 프런트 엔드 로드 밸런서로 사용해야 합니다. HAProxy 서버는 요청을 다른 HAProxy 서버로 분산할 수 없습니다.