AWS ELB(Elastic Load Balancing)

목차

 

Elastic Load Balancing은 들어오는 애플리케이션 트래픽을 Amazon EC2 인스턴스, 컨테이너, IP 주소, Lambda 함수, 가상 어플라이언스와 같은 여러 대상에 자동으로 분산시킵니다. Elastic Load Balancing은 단일 가용 영역 또는 여러 가용 영역에서 다양한 애플리케이션 부하를 처리할 수 있습니다. Elastic Load Balancing이 제공하는 네 가지 로드 밸런서는 모두 애플리케이션의 내결함성에 필요한 고가용성, 자동 조정, 강력한 보안을 갖추고 있습니다.

 

 

Elastic Load Balancing는 로드 밸런서 유형 Application Load Balancer, Network Load Balancer 및 Classic Load Balancer를 지원합니다. Amazon ECS 서비스는 어느 유형의 로드 밸런서든 사용할 수 있습니다. Application Load Balancer는 HTTP/HTTPS (또는 Layer 7) 트래픽을 라우팅할 때 사용됩니다. Network Load Balancer 및 Classic Load Balancer는 TCP(또는 Layer 4) 트래픽을 라우팅할 때 사용됩니다.

 

 

Application Load Balancer

---

Application Load Balancer는 HTTP 및 HTTPS 트래픽의 로드 밸런싱에 가장 적합하며, 마이크로서비스와 컨테이너 등 최신 애플리케이션 아키텍처 전달을 위한 고급 요청 라우팅 기능을 제공합니다. Application Load Balancer는 요청 내용에 따라 트래픽을 Amazon VPC 내의 대상으로 라우팅합니다.

 

 

 

Network Load Balancer

---

Network Load Balancer는 극도의 성능이 요구되는 TCP(Transmission Control Protocol), UDP(User Datagram Protocol) 및 TLS(전송 계층 보안) 트래픽의 로드 밸런싱에 가장 적합합니다. Network Load Balancer는 트래픽을 Amazon VPC 내의 대상으로 라우팅하며, 매우 짧은 지연 시간을 유지하면서 초당 수백만 개의 요청을 처리할 수 있습니다. 

 

 

 

Gateway Load Balancer

---

Gateway Load Balancer는 타사 가상 네트워킹 어플라이언스의 배포, 확장 및 실행을 쉽게 해줍니다. 여러 타사 어플라이언스에 대한 로드 밸런싱 및 자동 조정 기능을 제공하는 Gateway Load Balancer는 트래픽의 소스와 대상에 대해 투명하게 작동합니다. 이 기능 덕분에 Gateway Load Balancer는 보안, 네트워크 분석 및 기타 사용 사례에 타사 어플라이언스와 함께 사용하기에 적합합니다. 

 

 

Classic Load Balancer

---

Classic Load Balancer는 여러 Amazon EC2 인스턴스에서 기본적인 로드 밸런싱을 제공하며, 요청 수준 및 연결 수준에서 작동합니다. Classic Load Balancer는 EC2-Classic 네트워크 내에 구축된 애플리케이션용입니다.

 

특징

 

고가용성 및 탄력성

Elastic Load Balancing은 AWS 네트워크의 일부로서, AZ와 같은 장애 경계를 기본적으로 인식하여 글로벌 서버 로드 밸런싱(GSLB) 없이도 리전에서 애플리케이션을 계속 사용할 수 있도록 합니다. ELB는 또한 완전관리형 서비스이므로 여러 로드 밸런서를 설치하지 않고 애플리케이션 제공에 집중할 수 있습니다. 용량은 기본 애플리케이션 서버의 사용률에 따라 자동으로 추가되거나 제거됩니다. 

보안

Elastic Load Balancing은 Amazon Virtual Private Cloud(VPC)와 연동되어 통합 인증서 관리, 사용자 인증 및 SSL/TLS 복호화를 비롯한 강력한 보안 기능을 제공합니다. 이 두 가지가 결합되어 중앙에서 TLS 설정을 관리하고 CPU 집약적인 워크로드를 애플리케이션에서 오프로드하는 유연성을 제공합니다. 또한 ALB는 AWS WAF와의 통합을 지원하여 악의적인 행위자가 애플리케이션에 도달하기 전의 보호 수준을 강화합니다. 또한 S2N 및 HTTP Guardian이 오픈 소스 솔루션으로 개발되어 HTTP 기반 공격의 가능성을 줄여 줍니다. 

기능 적용 범위

Elastic Load Balancing은 규모에 관계없이 모든 비즈니스에 필요한 다양한 기능을 AWS 네이티브 환경에서 제공합니다. Elastic Load Balancing에는 HTTP/2, gRPC, TLS 오프로드, 고급 규칙 기반 라우팅, 수신 컨트롤러 역할을 하는 컨테이너 서비스와의 통합 등 컨테이너 기반 워크로드에 필요한 기능에 대한 지원이 포함되어 있습니다. ALB는 Lambda 함수를 호출하기 위한 네이티브 HTTP 엔드포인트를 제공하므로 고객이 다른 솔루션을 사용할 필요가 없습니다. 또한 Gateway Load Balancer는 여러 타사 어플라이언스를 통해 송수신되는 트래픽을 라우팅하기 위한 단일 게이트웨이를 생성합니다. 

강력한 모니터링 및 가시성

Elastic Load Balancing을 사용하면 Amazon CloudWatch 지표, 로깅, 요청 추적을 통해 애플리케이션 상태와 애플리케이션 성능을 실시간으로 모니터링할 수 있습니다. 따라서 애플리케이션 동작에 대한 가시성이 향상되어 애플리케이션 스택에서 문제를 발견하고 성능 병목을 파악할 수 있습니다. ELB는 애플리케이션 서비스 수준 계약(SLA)을 준수할 수 있도록 지원합니다.

통합 및 글로벌 접근성

네이티브 AWS 서비스인 ELB는 EC2, ECS/EKS, Global Accelerator 및 운영 도구(예: AWS CloudFormation 및 AWS Billing) 등의 다른 AWS 서비스와 긴밀하게 통합됩니다. AWS 워크로드를 실행하는 모든 곳에서 AWS Outposts 및 온프레미스 대상 지원 기능을 갖춘 Amazon 글로벌 인프라와 고객 데이터 센터를 통해 ELB를 사용할 수 있습니다. 

 

 

 

로드밸런서 유형

Application Load Balancer

Application Load Balancer는 애플리케이션 계층(HTTP/HTTPS)에서 라우팅 결정을 내리고, 경로 기반 라우팅을 지원하며, 클러스터의 각 컨테이너 인스턴스 상의 하나 이상의 포트로 요청을 라우팅할 수 있습니다. Application Load Balancer는 동적 호스트 포트 매핑을 지원합니다. 예를 들어, 작업의 컨테이너 정의가 NGINX 컨테이너 포트로 포트 80을 지정하고, 호스트 포트로 포트 0을 지정하면 컨테이너 인스턴스의 임시 포트 범위(예: 최신 Amazon ECS-optimized AMI에서 32768 ~ 61000)에서 호스트 포트가 동적으로 선택됩니다. 작업이 시작되면 NGINX 컨테이너가 인스턴스 ID-포트 조합으로 Application Load Balancer에 등록되고, 트래픽은 해당 컨테이너에 해당하는 인스턴스 ID와 포트에 분산됩니다. 이 동적 매핑을 통해 동일한 컨테이너 인스턴스에서 단일 서비스의 다중 작업이 가능합니다. 자세한 내용은 Application Load Balancers 사용 설명서 단원을 참조하세요.

Network Load Balancer

Network Load Balancer는 전송 계층(TCP/SSL)에서 라우팅을 결정합니다. 초당 수백만 개의 요청을 처리할 수 있습니다. 로드 밸런서가 연결을 수신하면 해시 라우팅 알고리즘 흐름에 따라 기본 규칙의 대상 그룹에서 대상을 선택합니다. 리스너 구성에 지정된 포트에서 선택한 대상에 대한 TCP 연결을 열려고 시도합니다. 그리고 헤더를 수정하지 않고 요청을 전달합니다. Network Load Balancer는 동적 호스트 포트 매핑을 지원합니다. 예를 들어, 작업의 컨테이너 정의가 NGINX 컨테이너 포트로 포트 80을 지정하고, 호스트 포트로 포트 0을 지정하면 컨테이너 인스턴스의 임시 포트 범위(예: 최신 Amazon ECS-optimized AMI에서 32768 ~ 61000)에서 호스트 포트가 동적으로 선택됩니다. 작업이 시작되면 NGINX 컨테이너가 인스턴스 ID-포트 조합으로 Network Load Balancer에 등록되고, 트래픽은 해당 컨테이너에 해당하는 인스턴스 ID와 포트에 분산됩니다. 이 동적 매핑을 통해 동일한 컨테이너 인스턴스에서 단일 서비스의 다중 작업이 가능합니다. 자세한 내용은 Network Load Balancers 사용 설명서 단원을 참조하세요.

Classic Load Balancer

Classic Load Balancer는 전송 계층(TCP/SSL) 또는 애플리케이션 계층(HTTP/HTTPS)에서 라우팅 결정을 내립니다. 현재 Classic Load Balancer는 로드 밸런서 포트와 컨테이너 인스턴스 포트의 고정된 관계가 필요합니다. 예를 들어 로드 밸런서 포트 80은 컨테이너 인스턴스 포트 3030에 매핑할 수 있고, 로드 밸런서 포트 4040은 컨테이너 인스턴스 포트 4040에 매핑할 수 있습니다. 하지만 로드 밸런서 포트 80을 한 컨테이너 인스턴스의 포트 3030과 다른 컨테이너 인스턴스의 포트 4040에 매핑할 수는 없습니다. 이 정적 매핑이 가능하려면 Classic Load Balancer를 사용하는 원하는 단일 서비스 수 이상의 컨테이너 인스턴스가 클러스터에 있어야 합니다. 자세한 내용은 Classic Load Balancers 사용 설명서 단원을 참조하세요.

Gateway Load Balancer

 

Gateway Load Balancer를 사용하면 타사 가상 어플라이언스를 쉽게 배포, 확장 및 관리할 수 있습니다. 여러 가상 어플라이언스에 트래픽을 분산하는 동시에 수요에 따라 확장하거나 축소할 수 있는 하나의 게이트웨이를 제공합니다. 이렇게 하면 네트워크의 잠재적인 실패 지점이 제거되고 가용성이 높아집니다.

AWS Marketplace에서 직접 타사 공급업체의 가상 어플라이언스를 찾고, 테스트하고, 구입할 수 있습니다. 이 통합 환경은 배포 프로세스를 간소화하므로 현재와 동일한 공급업체와 협력하든 새로운 시도를 하든 관계없이 가상 어플라이언스의 가치를 더 빨리 확인할 수 있습니다.

 

 

 

게이트웨이 로드 밸런서를 사용하면 방화벽, 침입 탐지 및 방지 시스템, 심층 패킷 검사 시스템과 같은 가상 어플라이언스를 배포, 확장 및 관리할 수 있습니다. 투명한 네트워크 게이트웨이 (즉, 모든 트래픽에 대한 단일 진입 및 종료 지점) 를 결합하고 수요에 따라 가상 어플라이언스를 확장하면서 트래픽을 분산합니다. 게이트웨이 Load Balancer 개방형 시스템 간 상호 연결 (OSI) 모델의 세 번째 계층인 네트워크 계층에서 작동합니다. 모든 포트에서 모든 IP 패킷을 수신하고 리스너 규칙에 지정된 대상 그룹으로 트래픽을 전달합니다. 5 튜플 (TCP/UDP 흐름의 경우) 또는 3 튜플 (비 TCP/UDP 흐름의 경우) 을 사용하여 특정 대상 기기에 대한 흐름의 점착성을 유지합니다. 게이트웨이 Load Balancer 등록된 가상 장치 인스턴스는 포트 6081의 GENEVE 프로토콜을 사용하여 애플리케이션 트래픽을 교환합니다. 이 기능은 8500 바이트의 최대 전송 단위 (MTU) 크기를 지원합니다. 게이트웨이 로드 밸런서는 게이트웨이 Load Balancer 엔드포인트를 사용하여 VPC 경계 전체에서 트래픽을 안전하게 교환합니다. 게이트웨이 Load Balancer 엔드포인트는 서비스 공급자 VPC 가상 어플라이언스와 서비스 소비자 VPC의 애플리케이션 서버 간에 프라이빗 연결을 제공하는 VPC 엔드포인트입니다. 게이트웨이 Load Balancer 가상 어플라이언스와 동일한 VPC 배포합니다. 게이트웨이 Load Balancer 대상 그룹에 가상 장치를 등록합니다. 

 

 

 

제품비교

 

 

보안

Amazon Virtual Private Cloud(VPC)를 사용할 경우 Elastic Load Balancing과 관련된 보안 그룹을 생성 및 관리하여 Application Load Balancer 및 Classic Load Balancer를 위한 추가 네트워킹 및 보안 옵션을 제공할 수 있습니다. 원하는 Load Balancer를 인터넷과 연결되도록 구성하거나 퍼블릭 IP 주소 없이 로드 밸런서를 생성하여 인터넷에 연결되지 않은 내부 로드 밸런서로 사용할 수 있습니다. 

고가용성

Elastic Load Balancer는 가용성이 매우 뛰어납니다. 수신되는 트래픽을 단일 가용 영역 또는 여러 가용 영역의 Amazon EC2 인스턴스 전체에 걸쳐 배포할 수 있습니다. Elastic Load Balancer는 수신되는 애플리케이션 트래픽에 대응하여 요청 처리 용량을 자동으로 조정합니다. 대상이 사용 가능하고 정상 상태인지 확인하기 위해 Elastic Load Balancer는 구성 가능한 케이던스로 대상에 대해 상태 확인을 실행합니다.

높은 처리량

Elastic Load Balancer는 트래픽 증가를 처리할 수 있도록 설계되었으며 초당 수백만 개의 요청을 로드 밸런싱할 수 있습니다. 또한, 갑작스럽고 변동이 심한 트래픽 패턴도 처리할 수 있습니다.

상태 확인

Elastic Load Balancer는 EC2 인스턴스, 컨테이너, IP 주소, 마이크로서비스, Lambda 함수, 어플라이언스 등 정상 상태인 대상으로만 트래픽을 라우팅합니다. Elastic Load Balancing을 사용하면 두 가지 방식으로 애플리케이션 상태에 대한 통찰력을 개선할 수 있습니다. 첫째, 상태 확인 개선을 통해 상세한 오류 코드를 구성할 수 있습니다. 상태 확인을 통해 로드 밸런서 뒤에서 각 서비스의 상태를 모니터링할 수 있습니다. 둘째, 새로운 지표로 EC2 인스턴스에서 실행되는 각 서비스의 트래픽을 파악할 수 있습니다.

고정 세션

고정 세션은 요청을 동일한 클라이언트에서 동일한 대상으로 라우팅하는 메커니즘입니다. Elastic Load Balancer는 고정 세션을 지원합니다. 고정성은 대상 그룹 수준에서 정의됩니다.

운영 모니터링 및 로깅

Amazon CloudWatch가 Application Load Balancer와 Classic Load Balancer에 대해 요청 횟수, 오류 횟수, 오류 유형, 요청 지연 시간 등의 지표를 보고합니다. 또한 Amazon CloudWatch는 Network Load Balancer와 Gateway Load Balancer에 대해 활성 플로우 수, 새 플로우 수, 처리된 바이트 등의 지표를 추적합니다. Elastic Load Balancer는 ELB에 대한 API 호출을 추적하는 AWS CloudTrail과도 통합됩니다.

삭제 방지

Elastic Load Balancer에서 삭제 방지를 활성화하여 우발적 삭제를 방지할 수 있습니다.

 

 

 

 

 

Elastic Load Balancing의 작동 방식

로드 밸런서는 클라이언트에서 오는 트래픽을 허용하고, 하나 이상의 가용 영역에서 등록된 대상(예: EC2 인스턴스)으로 요청을 라우팅합니다. 또한, 로드 밸런서는 등록된 대상의 상태를 모니터링하고 정상 대상으로만 트래픽이 라우팅되도록 합니다. 로드 밸런서가 비정상 대상을 감지하면, 해당 대상으로 트래픽 라우팅을 중단합니다. 그런 다음 대상이 다시 정상으로 감지되면 트래픽을 해당 대상으로 다시 라우팅합니다.

하나 이상의 리스너를 지정하여 들어오는 트래픽을 허용하도록 로드 밸런서를 구성합니다. 리스너는 연결 요청을 확인하는 프로세스입니다. 클라이언트와 로드 밸런서 간의 연결을 위한 프로토콜 및 포트 번호로 구성됩니다. 마찬가지로 로드 밸런서와 대상 간의 연결을 위한 프로토콜 및 포트 번호로 구성됩니다.

Elastic Load Balancing은 다음 유형의 로드 밸런서를 지원합니다.

• Application Load Balancers
• Network Load Balancer
• Gateway Load Balancer
• Classic Load Balancer

로드 밸런서 유형이 구성되는 방법에는 주요 차이점이 있습니다. Application Load Balancer, Network Load Balancer 및 Gateway Load Balancer를 사용하여 대상을 대상 그룹에 등록하고 트래픽을 대상 그룹에 라우팅합니다. Classic Load Balancer에서는 로드 밸런서에 인스턴스를 등록합니다.

가용 영역 및 로드 밸런서 노드

로드 밸런서에서 가용 영역을 활성화하면 Elastic Load Balancing이 해당 가용 영역에서 로드 밸런서 노드를 생성합니다. 가용 영역에 대상을 등록하지만 가용 영역은 활성화하지 않는 경우 이러한 등록된 대상은 트래픽을 수신하지 않습니다. 활성화된 각 가용 영역에 등록된 대상이 하나 이상 있는지 확인하는 경우에 로드 밸런서가 가장 효과적입니다.

모든 로드 밸런서에 대해 여러 가용 영역을 활성화하는 것이 좋습니다. 그러나 Application Load Balancer를 사용하여 최소한 둘 이상의 가용 영역을 활성화해야 합니다. 이 구성을 사용하면 로드 밸런서가 트래픽을 계속 라우팅할 수 있습니다. 가용 영역 하나가 사용할 수 없는 상태가 되거나 정상 상태 대상을 가지고 있지 않은 경우, 로드 밸런서가 다른 가용 영역에 있는 정상 상태의 대상으로 트래픽을 라우팅할 수 있습니다.

가용 영역을 비활성화해도 해당 가용 영역의 대상은 로드 밸런서에 등록된 상태로 남아 있습니다. 대상은 등록된 상태로 유지되지만 로드 밸런서는 트래픽을 해당 대상으로 라우팅하지 않습니다.

교차 영역 로드 밸런싱

로드 밸런서의 노드는 클라이언트로부터 요청을 가져와서 등록된 대상에 분산합니다. 교차 영역 로드 밸런싱을 활성화하면 각 로드 밸런서 노드가 활성화된 모든 가용 영역에 있는 등록된 대상 간에 트래픽을 분산합니다. 교차 영역 로드 밸런싱을 비활성화하면 각 로드 밸런서 노드가 해당 가용 영역에 있는 등록된 대상 간에만 트래픽을 분산합니다.

다음 다이어그램은 교차 영역 로드 밸런싱의 효과를 보여 줍니다. 활성화된 2개의 가용 영역이 있는데 가용 영역 A에는 2개의 대상이 있고 가용 영역 B에는 8개의 대상이 있습니다. 클라이언트는 요청을 보내며, Amazon Route 53은 로드 밸런서 노드 중 하나의 IP 주소를 통해 각 요청에 응답합니다. 이렇게 하면 각 로드 밸런서 노드가 클라이언트가 보내는 트래픽의 50%를 수신하도록 트래픽이 분산됩니다. 각 로드 밸런서 노드는 공유 트래픽을 해당 범위의 등록된 대상에만 분산합니다.

교차 영역 로드 밸런싱이 활성화된 경우 각 10개의 대상이 트래픽의 10%를 수신합니다. 이는 각 로드 밸런서 노드가 클라이언트 트래픽의 50%를 10개의 대상 모두에게 라우팅할 수 있기 때문입니다.

교차 영역 로드 밸런싱이 비활성화되어 있는 경우:

• 가용 영역 A의 두 대상이 각각 트래픽의 25%를 받습니다.
• 가용 영역 B에 있는 8개의 대상은 각각 트래픽의 6.25%를 받습니다.

이는 각 로드 밸런서 노드가 클라이언트 트래픽의 50%를 가용 영역에 있는 대상에만 라우팅할 수 있기 때문입니다.

Application Load Balancer에서는 교차 영역 로드 밸런싱이 항상 사용됩니다.

Network Load Balancer 및 Gateway Load Balancer를 사용하면 기본적으로 교차 영역 로드 밸런싱이 비활성화됩니다. 로드 밸런서를 생성한 후 언제든지 교차 영역 로드 밸런싱을 활성화하거나 비활성화할 수 있습니다.

Classic Load Balancer를 생성하면 교차 영역 로드 밸런싱에 대한 기본값은 로드 밸런서 생성 방법에 따라 달라집니다. API 또는 CLI에서는 교차 영역 로드 밸런싱이 기본적으로 비활성화되어 있습니다. AWS Management Console에서는 교차 영역 로드 밸런싱을 활성화하는 옵션이 기본적으로 선택됩니다. Classic Load Balancer를 생성한 후 언제든지 교차 영역 로드 밸런싱을 활성화하거나 비활성화할 수 있습니다. 자세한 정보는 Classic Load Balancer 사용 설명서의 교차 영역 로드 밸런싱 활성화를 참조하세요.

라우팅 요청

클라이언트는 로드 밸런서에 요청을 보내기 전에 로드 밸런서는 DNS(도메인 이름 시스템) 서버를 사용하여 로드 밸런서의 도메인 이름을 해석합니다. 로드 밸런서가 amazonaws.com 도메인에 있기 때문에 DNS 항목은 Amazon에서 제어합니다. Amazon DNS 서버는 클라이언트에 하나 이상의 IP 주소를 반환합니다. 이 주소는 로드 밸런서에 대한 로드 밸런서 노드의 IP 주소입니다. Network Load Balancer에서 Elastic Load Balancing은 활성화된 각 가용 영역에 대해 네트워크 인터페이스를 생성합니다. 가용 영역의 각 로드 밸런서 노드는 이 네트워크 인터페이스를 사용하여 고정 IP 주소를 가져옵니다. 로드 밸런서를 생성할 때 필요에 따라 탄력적 IP 주소 하나를 각 네트워크 인터페이스에 연결할 수 있습니다.

애플리케이션에 대한 트래픽이 시간에 따라 변화하므로 Elastic Load Balancing은 로드 밸런서를 확장하고 DNS 항목을 업데이트합니다. 또한 DNS 항목은 TTL을 60초로 지정합니다. 이렇게 하면 트래픽 변화에 따라 IP 주소를 신속하게 다시 매핑할 수 있습니다.

클라이언트는 로드 밸런서로 요청을 전송하는 데 사용할 IP 주소를 결정합니다. 요청을 수신한 로드 밸런서 노드는 등록된 대상 중 상태가 양호한 대상을 선택하고 프라이빗 IP 주소를 사용하여 해당 대상으로 요청을 전송합니다.

라우팅 알고리즘

Application Load Balancer에서 요청을 수신하는 로드 밸런서 노드는 다음 프로세스를 사용합니다.

1. 적용할 규칙을 결정하기 위해 우선 순위에 따라 리스너 규칙을 평가합니다.
2. 대상 그룹에 대해 구성된 라우팅 알고리즘을 사용하여 규칙 조치에 대한 대상 그룹에서 대상을 선택합니다. 기본 라우팅 알고리즘은 라운드 로빈입니다. 대상이 여러 개의 대상 그룹에 등록이 된 경우에도 각 대상 그룹에 대해 독립적으로 라우팅이 수행됩니다.

Network Load Balancer에서 연결을 수신하는 로드 밸런서 노드는 다음 프로세스를 사용합니다.

1. 흐름 해시 알고리즘을 사용하여 기본 규칙에 대한 대상 그룹에서 대상을 선택합니다. 알고리즘은 다음을 기반으로 합니다.
2. • 프로토콜
   • 소스 IP 주소 및 소스 포트
   • 대상 IP 주소 및 대상 포트
   • TCP 시퀀스 번호
3. 각 개별 TCP 연결은 연결 수명 동안 하나의 대상에 라우팅됩니다. 클라이언트로부터의 TCP 연결은 소스 포트와 시퀀스 번호가 서로 다르므로 다른 대상에 라우팅될 수 있습니다.

Classic Load Balancer에서 요청을 수신하는 로드 밸런서 노드는 다음과 같이 등록된 인스턴스를 선택합니다.

• TCP 리스너에 대한 라운드 로빈 라우팅 알고리즘 사용
• HTTP 및 HTTPS 리스너에 대한 최소 미해결 요청 라우팅 알고리즘 사용

HTTP 연결

Classic Load Balancer는 사전 개방 연결을 사용하지만 Application Load Balancer는 그렇지 않습니다. Classic Load Balancer와 Application Load Balancer는 모두 연결 멀티플렉싱을 사용합니다. 즉, 여러 프런트 엔드 연결에 있는 여러 클라이언트의 요청을 단일 백엔드 연결을 통해 지정된 대상으로 라우팅할 수 있습니다. 연결 멀티플렉싱은 지연 시간을 최소화하고 애플리케이션의 로드를 줄입니다. 연결 멀티플렉싱을 하지 않으려면 HTTP응답에 keep-alives 헤더를 설정하여 HTTP Connection: close를 비활성화합니다.

Application Load Balancer와 Classic Load Balancer는 프런트 엔드 연결에서 파이프라인 HTTP를 지원합니다. 백 엔드 연결에서는 파이프라인 HTTP를 지원하지 않습니다.

Application Load Balancer는 프런트 엔드 연결에서 HTTP/0.9, HTTP/1.0, HTTP/1.1, HTTP/2 등의 프로토콜을 지원합니다. HTTPS 리스너에서만 HTTP/2를 사용할 수 있고, 하나의 HTTP/2 연결을 이용해 최대 128개의 요청을 동시에 전송할 수 있습니다. 또한 Application Load Balancer는 HTTP에서 WebSockets으로 연결을 업그레이드할 수 있도록 지원합니다. 그러나 연결 업그레이드가 있는 경우, Application Load Balancer 리스너 라우팅 규칙 및 AWS WAF 통합은 더 이상 적용되지 않습니다.

Application Load Balancer는 기본적으로 백엔드 연결(로드 밸런서를 등록된 대상에)에서 HTTP/1.1을 사용합니다. 그러나 프로토콜 버전을 사용하면 HTTP/2 또는 gRPC를 사용하여 대상에 요청을 보낼 수 있습니다. 자세한 내용은 프로토콜 버전을 참조하세요. Keep-alive는 기본적으로 백엔드 연결에서 지원됩니다. 호스트 헤더가 없는 클라이언트로부터 오는 HTTP/1.0 요청의 경우, 로드 밸런서가 백 엔드 연결로 전송된 HTTP/1.1 요청에 대한 호스트 헤더를 생성합니다. 호스트 헤더에는 로드 밸런서의 DNS 이름이 포함되어 있습니다.

Classic Load Balancer는 프런트 엔드 연결(클라이언트에서 로드 밸런서)에서 HTTP/0.9, HTTP/1.0, HTTP/1.1 등의 프로토콜을 지원합니다. 이는 백엔드 연결(로드 밸런서를 등록된 대상에)에서 HTTP/1.1을 사용합니다. Keep-alive은(는) 기본적으로 백엔드 연결에서 지원됩니다. 호스트 헤더가 없는 클라이언트로부터 오는 HTTP/1.0 요청의 경우, 로드 밸런서가 백 엔드 연결로 전송된 HTTP/1.1 요청에 대한 호스트 헤더를 생성합니다. 호스트 헤더에는 로드 밸런서 노드의 IP 주소가 포함되어 있습니다.

HTTP 헤더

Application Load Balancer와 Classic Load Balancer는 X-Forwarded-For, X-Forwarded-Proto, X-Forwarded-Port 헤더를 요청에 자동으로 추가합니다.

Application Load Balancer는 HTTP 호스트 헤더의 호스트 이름을 대상으로 보내기 전에 소문자로 변환합니다.

HTTP/2를 사용하는 프런트 엔드 연결의 경우, 헤더 이름이 소문자입니다. HTTP/1.1을 사용하여 대상에 요청이 전송되기 전에 X-Forwarded-For, X-Forwarded-Proto, X-Forwarded-Port, Host, X-Amzn-Trace-Id, Upgrade, Connection과 같이 헤더 이름이 대/소문자 혼용으로 변환됩니다. 기타 모든 헤더 이름은 소문자입니다.

Application Load Balancer와 Classic Load Balancer는 클라이언트로 다시 응답을 프록시한 후에 들어오는 클라이언트 요청에서 연결 헤더를 인식합니다.

Application Load Balancer와 Classic Load Balancer에 Expect 헤더가 수신되면 콘텐츠 길이 헤더를 테스트하지 않고 HTTP 100 Continue를 사용하여 클라이언트에 즉시 응답하고 Expect 헤더를 제거한 다음 요청을 라우팅합니다.

HTTP 헤더 제한

Application Load Balancer에 대한 다음 크기 제한은 변경할 수 없는 하드 제한입니다.

HTTP/1.x 헤더

• 요청 라인: 16K
• 단일 헤더: 16K
• 전체 헤더: 64K

HTTP/2 헤더

• 요청 라인: 16K
• 단일 헤더: 16K
• 전체 헤더: 64K

로드 밸런서 체계

로드 밸런서를 생성할 때 로드 밸런서를 내부 로드 밸런서 또는 인터넷 경계 로드 밸런서로 생성할지 여부를 선택해야 합니다. EC2-Classic에서 Classic Load Balancer를 생성할 때는 반드시 인터넷 경계 로드 밸런서여야 한다는 점을 참고하십시오.

인터넷 경계 로드 밸런서의 노드는 퍼블릭 IP 주소를 가집니다. 인터넷 경계 로드 밸런서의 DNS 이름은 노드의 퍼블릭 IP 주소로 공개적으로 확인이 가능합니다. 따라서 인터넷 경계 로드 밸런서는 인터넷을 통해 클라이언트의 요청을 라우팅할 수 있습니다.

내부 로드 밸런서의 노드는 오직 프라이빗 IP 주소만 가집니다. 내부 로드 밸런서의 DNS 이름은 노드의 프라이빗 IP 주소로 공개적으로 확인이 가능합니다. 따라서 내부 로드 밸런서는 로드 밸런서를 위한 VPC에 액세스하여 클라이언트의 요청만 라우팅할 수 있습니다.

인터넷 경계 및 내부 로드 밸런서는 모두 프라이빗 IP 주소를 사용하여 대상으로 요청을 라우팅합니다. 따라서 대상이 퍼블릭 IP 주소 없이도 내부 또는 인터넷 경계 로드 밸런서에서 요청을 수신할 수 있습니다.

애플리케이션에 여러 계층이 있는 경우 내부 및 인터넷 경계 로드 밸런서를 모두 사용하는 아키텍처를 설계할 수 있습니다. 예를 들어, 애플리케이션이 인터넷에 연결되어야 하는 웹 서버와 웹 서버에만 연결되는 애플리케이션 서버를 사용하는 경우에 해당됩니다. 인터넷 경계 로드 밸런서를 생성하고 여기에 웹 서버를 등록합니다. 내부 로드 밸런서를 생성하고 여기에 애플리케이션 서버를 등록합니다. 웹 서버는 인터넷 경계 로드 밸런서에서 요청을 수신하고 애플리케이션 서버에서 내부 로드 밸런서로 요청을 전송합니다. 애플리케이션 서버는 내부 로드 밸런서에서 요청을 수신합니다.

로드 밸런서에 대한 네트워크 MTU

네트워크 연결의 MTU(최대 전송 단위)는 연결을 통해 전달할 수 있는 허용되는 최대 크기의 패킷 크기(바이트)입니다. 연결의 MTU가 클수록 하나의 패킷으로 전달할 수 있는 데이터의 양이 늘어납니다. 이더넷 패킷은 프레임 또는 전송 중인 실제 데이터와 이를 둘러싼 네트워크 오버헤드 정보로 구성됩니다. 인터넷 게이트웨이를 통해 전송되는 트래픽은 1500 MTU로 제한됩니다. 이에 따라 패킷이 1500바이트인 경우에는 단편화되고, IP 헤더에 Don't Fragment 플래그가 설정된 경우 삭제됩니다.

Application Load Balancer, Network Load Balancer 또는 Classic Load Balancer 노드의 MTU 크기는 구성할 수 없습니다. 점보 프레임(MTU 9001)은 모든 로드 밸런서 노드에서 표준입니다. 경로 MTU는 발신 호스트와 수신 호스트 간의 경로에서 지원되는 최대 패킷 사이즈입니다. 경로 MTU 검색(PMTUD)을 사용하여 두 디바이스 간의 경로 MTU를 확인할 수 있습니다. 경로 MTU 검색은 클라이언트 또는 대상이 점보 프레임을 지원하지 않는 경우 특히 중요합니다.

호스트가 수신 호스트의 MTU 또는 경로를 따르는 디바이스의 MTU보다 큰 패킷을 전송하는 경우 수신 호스트 또는 디바이스가 패킷을 삭제한 다음 Destination Unreachable: Fragmentation Needed and Don't Fragment was Set (Type 3, Code 4)과(와) 같은 ICMP 메시지를 반환합니다. 이렇게 하면 전송 호스트에 페이로드를 여러 개의 작은 패킷으로 분할한 다음 다시 전송하도록 지시합니다.

클라이언트 또는 대상 인터페이스의 MTU 크기보다 큰 패킷이 계속 삭제되면 경로 MTU 검색(PMTUD)이 작동하지 않는 것일 수 있습니다. 이를 방지하려면 경로 MTU 검색이 종단간에 작동하고, 클라이언트 및 대상에서 점보 프레임을 사용하도록 설정했는지 확인하세요. 경로 MTU 검색 및 점보 프레임 사용에 대한 자세한 내용은 Amazon EC2 사용 설명서에서 경로 MTU 검색을 참조하세요.

 

 

 

 

Reference

 

EC2 Container Service와 함께 AWS Application Load Balancer 및 Network Load Balancer 사용

https://medium.com/containers-on-aws/using-aws-application-load-balancer-and-network-load-balancer-with-ec2-container-service-d0cb0b1d5ae5

Using AWS Application Load Balancer and Network Load Balancer with EC2 Container Service

https://docs.openstack.org/octavia/pike/user/guides/l7.html