Elastic Load Balancing의 작동 방식 - Elastic Load Balancing

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

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를 사용하면 로드 밸런서 수준에서 교차 영역 로드 밸런싱이 항상 사용됩니다. 대상 그룹 수준에서 교차 영역 로드 밸런싱을 비활성화할 수 있습니다. 자세한 내용은 Application Load Balancer 사용 설명서교차 영역 로드 밸런싱 해제를 참조하세요.

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

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

영역 이동

영역 전환은 Amazon Route 53 Application Recovery Controller(Route 53 ARC) 내의 기능입니다. 영역 전환을 사용하면 한 번의 작업으로 손상된 가용 영역에서 로드 밸런서 리소스를 다른 곳으로 이동할 수 있습니다. 이러한 방법을 통해 AWS 리전의 다른 정상 가용 영역에서 계속 운영할 수 있습니다.

영역 전환을 시작하면 로드 밸런서가 해당 리소스에 대한 트래픽을 영향을 받는 가용 영역으로 보내는 것을 중단합니다. Route 53 ARC는 영역 전환을 즉시 생성합니다. 그러나 영향을 받는 가용 영역에서 진행 중인 기존 연결을 완료하는 데는 보통 몇 분 정도 소요될 수 있습니다. 자세한 내용은 Amazon Route 53 Application Recovery Controller 개발자 안내서영역 이동 작동 방식: 상태 확인 및 영역 IP 주소를 참조하세요.

영역 이동은 교차 영역 로드 밸런싱이 꺼진 상태에서 Application Load Balancer 및 Network Load Balancer에서만 지원됩니다. 교차 영역 로드 밸런싱을 켜면 영역 전환을 시작할 수 없습니다. 자세한 내용은 Amazon Route 53 Application Recovery Controller 개발자 안내서영역 전환에 지원되는 리소스를 참조하세요.

영역 전환을 사용하기 전에 다음을 검토하세요.

  • 영역 이동에서는 교차 영역 로드 밸런싱이 지원되지 않습니다. 이 기능을 사용하려면 교차 영역 로드 밸런싱을 꺼야 합니다.

  • Application Load Balancer를 AWS Global Accelerator에서 액셀러레이터 엔드포인트로 사용할 때는 영역 전환이 지원되지 않습니다.

  • 특정 로드 밸런서에 대한 영역 전환은 단일 가용 영역에 대해서만 시작할 수 있습니다. 여러 가용 영역에 대한 영역 전환은 시작할 수 없습니다.

  • AWS은(는) 여러 인프라 문제가 서비스에 영향을 미치는 경우 DNS에서 영역 로드 밸런서 IP 주소를 사전에 제거합니다. 영역 전환을 시작하기 전에 항상 현재 가용 영역 용량을 확인하세요. 로드 밸런서의 교차 영역 로드 밸런싱이 꺼져 있으며 영역 전환을 사용하여 영역 로드 밸런서 IP 주소를 제거하는 경우, 영역 전환의 영향을 받는 가용 영역도 대상 용량을 잃게 됩니다.

  • Network Load Balancer의 대상인 Application Load Balancer는 항상 Network Load Balancer에서 영역 이동을 시작하세요. Application Load Balancer에서 영역 전환을 시작하는 경우 Network Load Balancer는 이동을 인식하지 못하고 Application Load Balancer로 트래픽을 계속 전송합니다.

자세한 내용은 Amazon Route 53 Application Recovery Controller 개발자 안내서Route 53 ARC 영역 전환 모범 사례를 참조하세요.

라우팅 요청

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

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

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

자세한 내용은 Amazon Route 53 개발자 안내서ELB 로드 밸런서로 트래픽 라우팅을 참조하세요.

라우팅 알고리즘

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

  1. 적용할 규칙을 결정하기 위해 우선 순위에 따라 리스너 규칙을 평가합니다.

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

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

  1. 흐름 해시 알고리즘을 사용하여 기본 규칙에 대한 대상 그룹에서 대상을 선택합니다. 알고리즘은 다음을 기반으로 합니다.

    • 프로토콜

    • 소스 IP 주소 및 소스 포트

    • 대상 IP 주소 및 대상 포트

    • TCP 시퀀스 번호

  2. 각 개별 TCP 연결은 연결 수명 동안 하나의 대상에 라우팅됩니다. 클라이언트로부터의 TCP 연결은 소스 포트와 시퀀스 번호가 서로 다르므로 다른 대상에 라우팅될 수 있습니다.

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

  • TCP 리스너에 대한 라운드 로빈 라우팅 알고리즘 사용

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

HTTP 연결

Classic Load Balancer는 사전 개방 연결을 사용하지만 Application Load Balancer는 그렇지 않습니다. Classic Load Balancer와 Application Load Balancer는 모두 연결 멀티플렉싱을 사용합니다. 즉, 여러 프런트 엔드 연결에 있는 여러 클라이언트의 요청을 단일 백엔드 연결을 통해 지정된 대상으로 라우팅할 수 있습니다. 연결 멀티플렉싱은 지연 시간을 최소화하고 애플리케이션의 로드를 줄입니다. 연결 멀티플렉싱을 하지 않으려면 HTTP 응답에 keep-alive 헤더를 설정하여 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개의 요청을 동시에 전송할 수 있습니다. 또한 애플리케이션 로드 밸런서는 HTTP에서 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는 클라이언트로 다시 응답을 프록시한 후에 들어오는 클라이언트 요청에서 연결 헤더를 인식합니다.

HTTP/1.1을 사용하는 Application Load Balancers 및 Classic Load Balancers가 Expect: 100-Continue 헤더를 수신할 시, 내용 길이 헤더를 확인하지 않고 HTTP/1.1 100 Continue로 즉시 응답합니다. Expect: 100-Continue 요청 헤더는 대상으로 전달되지 않습니다.

HTTP/2를 사용하는 경우 Application Load Balancer는 클라이언트 요청 Expect: 100-Continue 헤더를 지원하지 않습니다. Application Load Balancer는 HTTP/2 100 Continue로 응답하거나 이 헤더를 대상으로 전달하지 않습니다.

HTTP 헤더 제한

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

  • 요청 라인: 16K

  • 단일 헤더: 16K

  • 전체 응답 헤더: 32K

  • 전체 요청 헤더: 64K

로드 밸런서 체계

로드 밸런서를 생성할 때 로드 밸런서를 내부 로드 밸런서 또는 인터넷 경계 로드 밸런서로 생성할지 여부를 선택해야 합니다.

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

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

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

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

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

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

로드 밸런서 노드의 MTU 크기는 구성할 수 없습니다. 점보 프레임(9001 MTU)은 Application Load Balancer, Network Load Balancer 및 Classic Load Balancer용 로드 밸런서 노드 전체에서 표준입니다. 게이트웨이 로드 밸런서는 8500 MTU를 지원합니다. 자세한 내용은 User Guide for Gateway Load Balancers(Gateway Load Balancer 사용 설명서)의 Maximum transmission unit (MTU)(네트워크 MTU (최대 전송 단위))을 참조하세요.

경로 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 검색을 참조하세요.