서론
이번에는 AWS에서 제공하는 다양한 로드밸런싱을 설명해본다.
Load Balancing (부하 분산)
서버, 네트워크, 스토리지 등과 같은 컴퓨팅 자원들에 대한 부하를 분산시켜주는 기술
웹사이트나 애플리케이션 등의 인기 있는 서비스를 제공하는 경우, 대량의 트래픽이 발생할 수 있기 때문에 여러 대의 서버를 이용해 이를 처리해야 한다.
이때 부하분산을 이용하면 각 서버의 처리 능력을 균등하게 사용하고, 각 서버가 다운될 경우 다른 서버들이 이를 대신 처리함으로써 서비스의 안정성과 가용성을 보장할 수 있다.
AWS에서는 부하분산을 위해 Elastic Load Balacing(이하 ELB)를 제공하고 있으며 4가지 종류의 ELB 유형을 제공한다.
- Network Load Balancer
- Application Load Balancer
- Classic Load Balancer
- Gateway Load Balancer
본론으로 들어가기 전 용어 하나만 설명하고 넘어가겠다.
대상 그룹 (Target Group)
ELB의 리스너에서 들어오는 요청을 지정된 대상에 전달하는 데 사용되는 논리적인 그룹
대상 그룹은 일반적으로 EC2 인스턴스 또는 IP 주소, Container Service 컨테이너, Lambda 함수 등과 같은 원하는 대상을 포함한다.
ELB의 작동방식
ELB는 생성 시 그저 ELB라는 것 하나만 생성되는 것이 아니다.
리스너, 지정된 가용영역에 따른 ENI 등 몇가지 요소가 생성되며 이를 그림으로 나타내면 다음과 같다.
-
리스너 (Listener)
클라이언트의 요청을 받아들이는 역할을 수행한다.
어떤 프로토콜과 포트를 사용할지 지정할 수 있으며, 하나의 리스너에는 여러 규칙을 지정할 수 있다. -
ENI
ELB를 생성할 때, 어느 서브넷으로 트래픽을 로드밸런싱 할지 결정한다.
이때, 각 서브넷별로 트래픽을 라우팅 하기 위한 ENI가 생성된다.
이 ENI가 대상 그룹에 지정된 대상(인스턴스, 람다함수 등)으로 트래픽을 전송한다. -
DNS Name
ELB를 생성하면 여기에 접속하기 위한 ELB 전용 DNS Name이 자동으로 부여된다.
이 DNS는 ELB마다 고유하며, 삭제 후 재생성 하지 않는 이상 변하지 않는다.
즉, 클라이언트는 모든 노드에 대한 IP를 모르더라도 DNS name을 통해 접근하면 된다.
ELB가 트래픽을 로드밸런싱 하는 과정은 다음과 같다.
- 클라이언트는 DNS Name을 통해 접속을 시도한다.
- ELB의 리스너는 클라이언트의 요청을 받아들이고 자신이 가진 규칙과 비교한다.
- 적절한 로드밸런싱 규칙이 있다면, 해당 트래픽을 적절한 대상그룹에 속한 대상으로 라우팅 한다. 이때, 이 트래픽은 해당 대상이 속한 서브넷의 ENI로 라우팅 된다.
- ENI로 라우팅된 트래픽은 목적지 대상으로 전송된다.
물론 ELB는 이것 말고도 중요한 요소가 몇가지 더 있다.
그 중 하나가 상태 검사(Health Check)이다.
로드밸런싱의 대상이 만약 장애가 생겨 비정상이라면 그쪽으로는 트래픽을 보내면 안될 것이다.
그렇기 때문에 ELB는 사전에 대상의 정상/비정상 여부를 판단하여 만약 비정상이라 판단된다면 그쪽으로는 트래픽을 보내지 않는다.
추가적으로 고려할만한 사항은 로드밸런싱의 알고리즘이다.
기존에 온프레미스에서 사용하는 로드밸런서도 여러가지 알고리즘을 제공한다.
AWS에서도 다양한 로드밸런싱 알고리즘을 제공하고 있다.
정적 로드밸런싱 알고리즘
1. 라운드 로빈
제일 기본적인 알고리즘, 순서대로 요청을 분배한다.
2. 가중치 기반 라운드 로빈
순서대로 요청을 분배하지만, 서버에 얼마나 많은 요청이 갈지 비율을 정할 수 있다.
3. IP 해시
요청자의 IP를 기반으로 로드밸런싱 한다. 이를 이용하면 사용자가 항상 동일한 서버로 연결된다.
동적 로드밸런싱 알고리즘
1. 최소 연결
현재 가장 적은 연결을 가진 서버로 연결한다.
2. 가중치 기반 최소 연결
현재 가장 적은 연결을 가진 서버로 연결하되, 그 비율을 정할 수 있다.
3. 최소 응답 시간
응답속도가 제일 빠른 서버로 연결한다.
4. 리소스 기반
서버의 리소스(CPU, Memory등) 상태를 기반으로 제일 자원이 남는 서버로 연결한다.
ELB에는 컴퓨팅/라우팅 노드의 개념 또한 존재한다.
간단하게 말하여 컴퓨팅 노드는 보안그룹을 적용해야 하지만, 라우팅 노드는 단순히 트래픽을 전달만 하는 용도이기 때문에 보안그룹이 필요없다.
컴퓨팅 노드 : ALB, CLB
라우팅 노드 : NLB, GWLB
Network Load Balancer
Network Load Balancer(이하 NLB)는 OSI 4계층인 전송 계층의 로드밸런서이다.
이름이 Network라고 3계층이라고 착각하면 안된다.
OSI에서 4계층의 핵심은 TCP/UDP이다.
즉, NLB는 TCP/UDP 트래픽을 로드밸런싱 할 수 있다.
다만 4계층까지 처리가 한계이기 때문에 요청 경로에 따른 분산 처리나, SSL 통신에서의 복호화 등의 작업은 불가능하다.
이러한 작업이 없는 대신 ALB에 비해서 상대적으로 처리 속도가 빠르다.
Application Load Balancer
Network Load Balancer(이하 NLB)는 OSI 7계층인 응용 계층의 로드밸런서이다.
7계층 답게 NLB의 기능을 포함하여 여러 조건에 기반한 로드밸런싱 규칙을 지정할 수 있다.
대표적으로 HTTP 요청의 경로에 따라 어느 대상그룹으로 요청이 라우팅 될지 결정하거나, SSL 통신을 복호화 할 수 있다.
ALB는 HTTP/HTTPS 통신에 특화되어 있으며 요청 경로 뿐 아니라 헤더, 쿼리 문자열, 쿠키 등의 정보를 기반으로 라우팅이 가능하다.
이 외에도 Connection Draining, Sticky Session등 여러 기능을 지원한다.
특별한 경우가 아니라면 웹 서비스를 제공하는 경우 대부분의 상황에서는 ALB가 적합할 것이다.
NLB와의 결정적인 차이점 중 하나로, ALB는 보안그룹을 연결할 수 있지만, NLB는 불가능하다.
Classic Load Balancer
가장 오래된 로드밸런서 서비스이며 4계층, 7계층을 지원한다.
다른 로드밸런서 타입에 비해서 구시대적이지만, 어떻게 보면 제일 단순한 로드밸런서 타입이라 아직 많은 사용자가 이를 사용하고 있다.
하지만, CLB는 라우팅될 대상이 EC2 인스턴스만 가능하다. 따라서 NLB, ALB와는 다르게 Lambda 함수는 지정 불가능하다.
Gateway Load Balancer
제일 이질적인 Load Balancer이다.
다른 LB는 요청을 라우팅 하는 대상이 해당 트래픽의 최종 목적지이다.
즉, 해당 요청은 트래픽을 전달 받는 대상에서 소비한 뒤 적절한 응답을 되돌려준다.
하지만 GWLB는 이와 다르게 라우팅 하는 대상이 최종 목적지가 아니다.
GWLB가 요청을 라우팅 하면 해당 트래픽은 잠시 대상에게 전달된 후 최종 목적지로 이동한다.
굳이 왜 이러는 것일까?
이전 포스트의 East-West 트래픽을 기억하는가?
그때, 별도로 라우팅 규칙을 지정하여 중간에서 패킷을 감시하거나 필터링을 수행하는 시스템을 중간에 추가할 수 있었다.
GWLB도 이와 목적이 비슷하다.
잠시 최종 목적지가 아닌 다른 대상으로 트래픽을 보내 최종 목적지에서 요청을 소비하기 전에 검사나 전처리 등을 수행할 수 있도록 하는 것이다.
이는 주로 제3자가 제공하는 어플라이언스를 사용하기 위해 사용되며 GWLB의 라우팅 대상은 이 어플라이언스가 될 수 있다.
