PERF05-BP04 로드 밸런싱 및 암호화 오프로딩 활용 - AWS Well-Architected Framework
구현 가이드리소스

PERF05-BP04 로드 밸런싱 및 암호화 오프로딩 활용

로드 밸런서를 사용하여 대상 리소스의 성능 효율성을 최적화하고 시스템의 응답성을 개선합니다.

원하는 결과: 트래픽을 처리할 컴퓨팅 리소스의 수를 줄입니다. 대상에서 리소스 사용 불균형이 발생하지 않도록 합니다. 컴퓨팅 집약적인 태스크를 로드 밸런서로 오프로드합니다. 클라우드 탄력성과 유연성을 활용하여 성능을 개선하고 아키텍처를 최적화합니다.

일반적인 안티 패턴:

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

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

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

이 모범 사례를 따르지 않을 경우 노출 위험도: 높음

구현 가이드

로드 밸런서는 워크로드의 진입점 역할을 하며 여기에서 컴퓨팅 인스턴스 또는 컨테이너와 같은 백엔드 대상으로 트래픽을 분산합니다. 아키텍처를 최적화하는 첫 번째 단계는 적절한 로드 밸런서 유형을 선택하는 것입니다.

먼저 프로토콜(예: TCP, HTTP, TLS 또는 WebSockets), 대상 유형(예: 인스턴스, 컨테이너 또는 서버리스), 애플리케이션 요구 사항(장기간 실행되는 연결, 사용자 인증 또는 고정성 등) 및 배치(예: 리전, 로컬 영역, Outpost 또는 영역 격리)와 같은 워크로드 특성을 나열해 봅니다.

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

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

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

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

로드 밸런서를 활용하면 컨테이너 및 서버리스와 같은 다양한 백엔드 유형에 트래픽을 분산하여 아키텍처를 보다 유연하게 만들 수도 있습니다. 예를 들어 Application Load Balancer는 헤더, 메서드 또는 패턴과 같은 요청 파라미터를 기반으로 트래픽을 다른 대상 그룹으로 전달하는 리스너 규칙으로 구성할 수 있습니다.

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

지연 시간에 민감한 워크로드에 대한 또 다른 대응책은 교차 영역 로드 밸런싱입니다. 교차 영역 로드 밸런싱을 활용하면 각 로드 밸런서 노드를 사용하도록 설정된 모든 가용 영역의 등록된 대상에 트래픽을 분산합니다. 이렇게 하면 왕복 지연 시간에 한 자릿수 밀리초가 추가될 수 있지만 가용성이 향상됩니다.

마지막으로 ALB와 NLB는 모두 로그 및 지표와 같은 모니터링 리소스를 제공합니다. 올바르게 모니터링을 설정하면 애플리케이션의 성능 인사이트를 수집하는 데 도움이 될 수 있습니다. 예를 들어 ALB 액세스 로그를 사용하면 응답하는 데 더 오래 걸리는 요청이나 성능 문제를 일으키는 백엔드 대상을 찾을 수 있습니다.

구현 단계

  1. 워크로드에 적합한 로드 밸런서를 선택합니다.

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

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

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

    4. 로드 밸런서를 비교한 전체 내용을 보려면 ELB 제품 비교를 참조하세요.

  2. SSL/TLS 오프로딩을 사용합니다.

    1. AWS Certificate Manager와 통합된 Application Load Balancer 및 Network Load Balancer로 HTTPS/TLS 리스너를 구성합니다.

    2. 일부 워크로드는 규정 준수상의 이유로 엔드 투 엔드 암호화가 필요할 수 있습니다. 이 경우 대상에서 암호화를 사용하도록 설정해야 합니다.

    3. 보안 모범 사례는 SEC09-BP02 전송 중 데이터 암호화 적용을 참조하세요.

  3. 적절한 라우팅 알고리즘을 선택합니다.

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

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

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

  4. 교차 영역 또는 영역 격리를 고려합니다.

    1. 지연 시간 개선 및 영역 장애 도메인을 위해 교차 영역 끔(영역 격리)을 사용합니다. NLB에서는 기본적으로 비활성화되어 있으며 ALB에서는 대상 그룹별로 비활성화할 수 있습니다.

    2. 가용성과 유연성 향상을 위해 교차 영역을 사용합니다. 기본적으로 교차 영역은 ALB에 대해 활성화되어 있으며 NLB에서는 대상 그룹별로 비활성화할 수 있습니다.

  5. HTTP 워크로드에 대해 HTTP 연결 유지를 활성화합니다.

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

  6. 컴퓨팅 리소스의 더 나은 오케스트레이션을 위해 Elastic Load Balancing 통합을 사용합니다.

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

    2. 로드 밸런서는 컨테이너화된 워크로드를 위해 Amazon ECS 및 Amazon EKS와 통합할 수도 있습니다.

  7. 로드 밸런서를 모니터링하여 성능 병목 현상을 찾습니다.

    1. Application Load Balancer 및 Network Load Balancer에 대한 액세스 로그를 활성화합니다.

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

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

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

    5. 성능 관련 지표에 대한 경보(예: ALB의TargetResponseTime)를 생성합니다.

리소스

관련 모범 사례:

관련 문서:

관련 동영상:

관련 예시: