PERF04-BP04 로드 밸런싱을 사용하여 여러 리소스에 트래픽 분산 - 성능 효율성 원칙
구현 지침리소스

PERF04-BP04 로드 밸런싱을 사용하여 여러 리소스에 트래픽 분산

클라우드의 탄력성을 워크로드에 활용할 수 있도록 여러 리소스 또는 서비스에 트래픽을 분산합니다. 로드 밸런싱을 사용하여 암호화 종료를 오프로드하면 성능과 신뢰성을 개선하고 트래픽을 효율적으로 관리 및 라우팅할 수 있습니다.

일반적인 안티 패턴:

  • 로드 밸런서 유형을 선택할 때 워크로드 요구 사항을 고려하지 않습니다.

  • 성능 최적화 시 로드 밸런서 기능을 활용하지 않습니다.

  • 워크로드는 로드 밸런서 없이 인터넷에 직접 노출됩니다.

  • 기존 로드 밸런서를 통해 모든 인터넷 트래픽을 라우팅합니다.

  • 일반 TCP 로드 밸런싱을 사용하고 각 컴퓨팅 노드에서 SSL 암호화를 처리하도록 합니다.

이 모범 사례 확립의 이점: 로드 밸런서는 단일 가용 영역 또는 여러 가용 영역에서 애플리케이션 트래픽의 다양한 부하를 처리하고 고가용성, 자동 규모 조정, 워크로드 활용도 향상을 지원합니다.

이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준: 높음

구현 가이드

로드 밸런서는 워크로드의 진입점 역할을 하며 여기에서 트래픽을 컴퓨팅 인스턴스나 컨테이너와 같은 백엔드 대상으로 분산하여 사용률을 개선합니다.

아키텍처를 최적화하는 첫 번째 단계는 적절한 로드 밸런서 유형을 선택하는 것입니다. 먼저 프로토콜(예: TCP, HTTP, TLS 또는 WebSockets), 대상 유형(예: 인스턴스, 컨테이너 또는 서버리스), 애플리케이션 요구 사항(장기간 실행되는 연결, 사용자 인증 또는 고정성 등) 및 배치(예: 리전, 로컬 영역, Outpost 또는 영역 격리)와 같은 워크로드 특성을 나열해 봅니다.

AWS는 애플리케이션이 로드 밸런싱을 사용할 수 있도록 여러 모델을 제공합니다. Application Load Balancer는 HTTP 및 HTTPS 트래픽을 로드 밸런싱하는 데 가장 적합하며, 마이크로서비스 및 컨테이너를 비롯한 최신 애플리케이션 아키텍처를 제공할 때 사용할 수 있는 고급 요청 라우팅 기능을 제공합니다.

Network Load Balancer는 성능이 매우 우수해야 하는 TCP 트래픽 로드 밸런싱을 수행하려는 경우에 사용하면 가장 효율적입니다. 또한 지연 시간을 매우 짧게 유지하면서 초당 수백만 개의 요청을 처리할 수 있으며, 예상치 못한 휘발성 트래픽 패턴도 처리할 수 있도록 최적화되어 있습니다.

Elastic Load Balancing이 제공하는 통합 인증서 관리 및 SSL/TLS 복호화를 활용하면 로드 밸런서의 SSL 설정을 중앙에서 유연하게 관리하고 CPU 집약적인 작업을 워크로드에서 오프로드할 수 있습니다.

적절한 로드 밸런서를 선택한 후 해당 기능을 활용하면 백엔드가 트래픽을 처리하는 데 필요한 노력을 줄일 수 있습니다.

예를 들어 Application Load Balancer(ALB) 및 Network Load Balancer(NLB)를 모두 사용하면 SSL/TLS 암호화 오프로딩을 수행할 수 있습니다. 이를 통해 대상에서 완료되는 CPU 집약적 TLS 핸드셰이크를 방지하고 인증서 관리를 개선할 수 있습니다.

로드 밸런서에서 SSL/TLS 오프로딩을 구성하면 백엔드에 암호화되지 않은 트래픽을 전달하고 백엔드 리소스를 확보하며 클라이언트에 대한 응답 시간을 개선하는 동시에 클라이언트에서 들어오고 나가는 트래픽의 암호화를 담당하게 됩니다.

Application Load Balancer도 대상에서 지원할 필요 없이 HTTP2 트래픽을 처리할 수 있습니다. HTTP2가 TCP 연결을 보다 효율적으로 사용하므로 이렇게 간단한 결정이 애플리케이션 응답 시간을 개선할 수 있습니다.

아키텍처를 정의할 때 워크로드 지연 시간 요구 사항도 고려해야 합니다. 예를 들어 지연 시간에 민감한 애플리케이션이 있는 경우 지연 시간이 매우 짧은 Network Load Balancer를 사용하기로 결정할 수 있습니다. 또는 AWS 로컬 영역 또는 AWS Outposts에서 Application Load Balancer를 활용하여 워크로드를 고객에게 더 가까이 가져오기로 결정할 수 있습니다.

지연 시간에 민감한 워크로드에 대한 또 다른 대응책은 크로스 영역 로드 밸런싱입니다. 크로스 영역 로드 밸런싱을 활용하면 각 로드 밸런서 노드를 사용하도록 설정된 모든 가용 영역의 등록된 대상에 트래픽을 분산합니다.

로드 밸런서와 통합된 Auto Scaling을 사용합니다. 성능 효율적인 시스템의 주요 측면 중 하나는 백엔드 리소스의 크기를 적절하게 조정하는 것과 관련이 있습니다. 이를 위해서는 백엔드 대상 리소스에 대한 로드 밸런서 통합을 활용할 수 있습니다. Auto Scaling 그룹과 로드 밸런서 통합을 사용하면 수신 트래픽에 대한 응답으로 필요에 따라 로드 밸런서에서 대상이 추가되거나 제거됩니다. 로드 밸런서는 컨테이너식 워크로드를 위해 Amazon ECS 및 Amazon EKS와 통합할 수도 있습니다.

구현 단계

  • 트래픽 볼륨, 가용성 및 애플리케이션 확장성을 포함한 로드 밸런싱 요구 사항을 정의합니다.

  • 애플리케이션에 적합한 로드 밸런서 유형을 선택하세요.

    • HTTP/HTTPS 워크로드에 대해 Application Load Balancer를 사용합니다.

    • TCP 또는 UDP에서 실행되는 비HTTP 워크로드에 대해 Network Load Balancer를 사용합니다.

    • 두 제품의 기능을 모두 활용하려면 두 제품의 조합(NLB의 대상인 ALB)을 사용합니다. 예를 들어 ALB의 HTTP 헤더 기반 라우팅과 함께 NLB의 고정 IP를 사용하려는 경우 또는 AWS PrivateLink에 HTTP 워크로드를 노출하려는 경우 이를 수행할 수 있습니다.

    • 로드 밸런서의 전체 비교를 위해서 ELB 제품 비교를 참조하세요.

  • 가능하면 SSL/TLS 오프로딩을 사용하세요.

  • 적절한 라우팅 알고리즘(ALB만)을 선택합니다.

    • 라우팅 알고리즘에 따라 백엔드 대상에서의 활용도 및 성능에 미치는 영향에 차이를 만들 수 있습니다. 예를 들어 ALB는 라우팅 알고리즘에 대한 두 가지 옵션을 제공합니다.

    • 미해결 요청 최소화: 애플리케이션에 대한 요청의 복잡성이 다양하거나 대상의 처리 능력이 다양한 경우 백엔드 대상에 로드를 더 효율적으로 분산하기 위해 사용합니다.

    • 라운드 로빈: 요청과 대상이 유사하거나 대상 간에 요청을 균등하게 분산해야 하는 경우에 사용합니다.

  • 크로스 영역 또는 영역 격리를 고려합니다.

    • 지연 시간 개선 및 영역 장애 도메인을 위해 크로스 영역 끔(영역 격리)을 사용합니다. 이 기능은 NLB에서 기본적으로 꺼져 있으며 ALB의 경우 대상 그룹별로 해제할 수 있습니다.

    • 가용성과 유연성 향상을 위해 크로스 영역을 사용합니다. 기본적으로 크로스 영역은 ALB에서 활성화되어 있으며 NLB의 경우 대상 그룹별로 활성화할 수 있습니다.

  • HTTP 워크로드(ALB만)에 대해 HTTP 연결 유지를 활성화합니다. 이 기능을 사용하면 로드 밸런서는 연결 유지 제한 시간이 만료될 때까지 백엔드 연결을 재사용하여 HTTP 요청 및 응답 시간을 개선하고 백엔드 대상의 리소스 사용률을 줄일 수 있습니다. Apache 및 Nginx에 대해 이 작업을 수행하는 방법에 대한 자세한 내용은 Apache 또는 NGINX를 ELB의 백엔드 서버로 사용하기 위한 최적의 설정은 무엇인가요?를 참조하세요.

  • 로드 밸런서에 대한 모니터링을 켜세요.

    • Application Load Balancer 및 Network Load Balancer의 액세스 로그를 활성화합니다.

    • ALB에 대해 고려해야 할 주요 필드는 request_processing_time, request_processing_time, response_processing_time입니다.

    • NLB에 대해 고려해야 할 주요 필드는 connection_time 및 tls_handshake_time입니다.

    • 필요할 때 로그 쿼리를 준비합니다. Amazon Athena를 사용하여 ALB 로그와 NLB 로그를 모두 쿼리할 수 있습니다.

    • ALB의 TargetResponseTime과 같은 성능 관련 지표에 대한 경보를 생성합니다.

리소스

관련 문서:

관련 비디오:

관련 예제: