Elastic Load Balancing
AWS는 Elastic Load Balancing(ELB)이라는 이름으로 다양한 종류의 로드밸런서를 제공하고 있다. 각 로드밸런서의 특징에 따라 사용처가 달라지므로 특징을 알아보고 사용하면 좋을 것 같다.
우선 ELB 자체의 공통적인 특징을 살펴보자면 웹 애플리케이션을 향해 들어오는(incoming) 트래픽을 자동적으로 EC2, 컨테이너, IP 주소에 분산하는 역할을 수행한다. 또한 ELB는 주기적으로 등록된 타겟의 상태를 확인하고, 정상적인 상태의 타겟에만 트래픽을 라우팅한다.
ELB의 세부적인 종류는 다음과 같다:
- Application Load Balancer
- Network Load Balancer
- Gateway Load Balancer
- Classic Load Balancer (AWS의 1세대 로드밸런서, 현재는 EC2 Classic에 사용할 경우를 제외하면 사용하지 않는 것 같다...)
ELB Element
ELB는 다음과 같은 구성요소를 가지고 있다.
- 로드밸런서: 클라이언트가 서버의 서비스에 접근하기 위한 단일 접점
- 리스너: 클라이언트의 연결이 미리 설정해 둔 프로토콜과 포트를 사용하였는지 확인하는 프로세스
- 대상 그룹: 리스너 규칙 조건이 충족된 요청에 대해 분산 받을 그룹
Request Routing
구체적으로 ELB가 어떻게 클라이언트의 Request를 라우팅하는지 살펴보자.
-
클라이언트가 DNS 서버에 로드밸런서의 도메인을 질의한다.
ELB는
http://amazonaws.com도메인을 가지고 있다. 이 DNS 질의에 의해 Amazon DNS 서버가 하나 또는 여러 개의 IP 주소를 반환하게 된다. 전달받은 IP가 바로 로드밸런서의 IP이다. -
로드밸런서를 향해 전달된 트래픽은 리스너를 통해 전달될 대상 그룹을 결정하게 된다.
-
전달될 대상 그룹이 결정되면, 정해진 라우팅 프로토콜(각 로드밸런서마다 상이)에 의해 대상 그룹 내의 리소스(인스턴스 등..)에게 전달된다.
Appliaction Load Balancer (ALB)
ALB는 OSI 7 계층 중 애플리케이션 계층(Layer 7)에서 동작하는 로드밸런서로 HTTP 또는 HTTPS 프로토콜을 사용하는 트래픽에 대해 로드밸런싱을 수행한다. HTTP, HTTPS 트래픽에 대한 복잡한 로드 밸런싱을 수행하므로 마이크로서비스 또는 컨테이너 기반 애플리케이션 구조에 적합하다.
기본적인 라우팅 알고리즘은 라운드 로빈(Round-Robin: 일정 시간 마다 라우팅을 변경)하는 알고리즘이지만, 최소 미해결 요청(Least Outstanding Requests, LOR: 처리하고 있는 요청이 가장 적은 대상에게 라우팅)을 사용할 수도 있다.
Network Load Balancer (NLB)
NLB는 OSI 7 계층 중 전송 계층(Layer 4) 에서 동작하는 로드밸런서이다. millions of requests per second를 처리할 수 있다.
TCP 트래픽의 경우, 로드 밸런서는 프로토콜, 원본 IP 주소, 원본 포트, 대상 IP 주소, 대상 포트, TCP 시퀀스 번호에 따라 흐름 해시 알고리즘을 사용하여 대상을 선택한다. 클라이언트가 요청하는 TCP 연결은 출발 포트와 시퀀스 번호가 계속 달라지기 때문에 해시 알고리즘에 의해 타겟 그룹 내의 다른 대상에 라우팅될 수 있다. 각 TCP 연결은 연결 수명 동안 하나의 대상에 라우팅됩니다.
UDP 트래픽의 경우, 로드 밸런서는 프로토콜, 원본 IP 주소, 원본 포트, 대상 IP 주소, 대상 포트에 따라 흐름 해시 알고리즘을 사용하여 대상을 선택합니다. UDP 흐름은 TCP와 달리, 소스와 목적지가 동일하기 때문에 수명이 다할 때까지 일관되게 단일 대상으로 라우트된다. 서로 다른 UDP 흐름에는 서로 다른 소스 IP 주소와 포트가 있으므로 다른 대상으로 라우팅될 수 있다.
NLB를 사용할 경우 활성화한 긱 AZ에 네트워크 인터페이스가 생성되며 이 인터페이스에 IP가 할당된다. 만약 인터넷 통신을 위해 로드밸런서를 배치할 경우, 각 서브넷 당 하나의 Elastic IP를 할당 받을 수 있다.
Client의 Source IP
그런데 궁금증이 생긴다. 로드밸런서를 통해서 트래픽이 분산될 경우, 트래픽 패킷에 존재하는 Source IP와 Port는 동일하게 유지되는걸까?
트래픽을 전달받은 EC2 입장에서는 incoming 트래픽의 source ip가 ELB의 ip 또는 ELB가 생성한 네트워크 인터페이스 노드 ip이다. 만약 원본 클라이언트의 source ip가 꼭 필요한 경우 어떻게 해야할까?
ALB의 경우: 원본 ip 주소를 기록하도록 설정하면, X-Forwarded-For HTTP 헤더(비공식)에 기록이 된다.
NLB의 경우: 라우팅 대상을 ip 주소가 아닌 인스턴스 id로 지정한다.
살펴보았듯, 두 가지 방법 모두 완벽하게 source ip를 유지하는 방법이라고는 할 수 없다.
그래서 이 문제를 해결하기 위해 Gateway Load Balancer가 서비스를 시작했다.
Gateway Load Balancer(GWLB)
GWLB는 OSI 7 계층 중 네트워크 계층(Layer 3) 에서 동작하는 로드밸런서이다. Transparency한 네트워크 게이트웨이를 제공하므로 방화벽, IPS, IDS 등의 원본 패킷의 데이터가 중요한 가상 어플라이언스를 지원하기 위해 개발되었다.
VPC의 라우팅 테이블을 조정해서 GWLB로 트래픽을 보낼 수 있다.GWLB를 사용하면 가상 어플라이언스로 트래픽의 부하를 분산하고, 가상 어플라이언스의 리소스를 탄력적으로 확장/축소할 수 있다.
또한 GWLB는 양방향의 트래픽을 동일한 어플라이언스로 보냄으로써 어플라이언스가 stateful 한 트래픽 처리를 수행하도록 한다.
GWLB와 가상 어플라이언스는 GENEVE 캡슐화를 사용해서 원본 트래픽의 내용을 보존한다.
GENEVE란?
General Network Virtualization Encapsulation의 준말로 UDP를 통해 구현하는 캡슐화 프로토콜.
다양한 하드웨어와 소프트웨어간의 유연한 통신을 위해 개발되었다.
세부 내용은 RFC 참조...
https://tools.ietf.org/html/rfc8926
마무리...
이것으로 Classic Load Balancer를 제외한 모든 로드밸런서를 확인했다.
각 종류마다 운용되는 Layer도 다르고, 수행하는 로드밸런싱도 미묘하게 다르다.
어떤 이유에 의해 로드밸런싱이 필요한지 잘 생각해보고, 가장 적절한 로드밸런서를 선택해서 사용하는 것이 최적의 결과를 이끌어낼 수 있을 것 같다.
