LoadBalancer Types: L3, L4, L7

Overview

이번 문서에서는 로드밸런서란 무엇인지, 로드밸런서의 종류는 뭐가 있는지에 대해서 포스팅하겠습니다.

LoadBalancer?

로드밸런서가 없는 환경에서는 위 사진과 같이 한 서버에 트래픽이 몰리는 현상을 해결할 수 없습니다.

이를 방지하기 위해 서버에 가해지는 부하를 적절하게 분산하는 작업이 필요합니다.
이 역할을 로드밸런싱이라고 하고 작업을 담당하는 장비를 로드밸런서라고 합니다.

로드밸런서는 OSI 7계층중 어떤 계층을 기준으로 분산작업을 하느냐에 따라 그 타입이 나뉘어 집니다.
아래 그림은 OSI 7계층을 나타낸 것입니다.

예를 들어 TCP, UDP와 같은 4계층 지표를 기준으로 분산 작업을 하는 로드밸런서라면 L4 로드밸런서, IP와 포트를 기준으로 분산 작업을 하는 로드밸런서라면 L3로드밸런서라고 합니다.

7로 올라갈수록 더욱 섬세하게 부하를 분산시킬 수 있습니다.

이번 문서에서는 모든 로드밸런서를 다루지 않고 L3, L4, L7만 다룰 것입니다.

LoadBalancing Algorithm

트래픽을 분산시키는 방법은 여러가지가 있습니다.
각 로드밸런서에 대해서 설명하기 전에 로드밸런싱 알고리즘부터 간단히 짚고 넘어가겠습니다.

1. 라운드 로빈(Round Robin)
   대부분 로드밸런싱의 default 방법입니다. 서버에 들어온 요청을 순서대로 돌아가면서 배정하는 방식입니다.
2. 가중 라운드 로빈(Weighted Round Robin)
   각 서버에 가중치를 매기고, 가중치가 높은 서버에 우선적으로 클라이언트로부터의 요청을 배분합니다.
3. IP 해시(IP Hash)
   클라이언트의 IP 주소를 특정 서버로 매핑하여 요청을 처리합니다. 클라이언트는 항상 동일한 서버로 연결되는 것을 보장합니다.
4. 최소 연결(Least Connection)
   요청이 들어온 시점에 가장 적은 연결상태를 보이는 서버에 우선적으로 연결시켜줍니다.
5. 최소 리스폰타임(Least Response Time)
   서버의 현재 연결 상태와 응답시간을 모두 고려하여 트래픽을 배분합니다.

L3 LoadBalancer

L3 로드밸런서는 Ip를 기준으로 트래픽을 분산시키는 기본적인 형태의 로드밸런서입니다.

A(또는 AAAA)레코드를 같은 호스트 이름으로 등록하게 되면, DNS Resolver는 그 리스트를 재배치하여 클라이언트에게 리턴해 줄 것입니다.
그러고 나면 클라이언트에서는 리턴된 리스트의 가장 첫번째 ip로 연결을 시도하게 됩니다.

L4 LoadBalancer

L4로드밸런싱은 Network Load Balancing (NLB)라고도 하며, OSI 7Layer중 Layer4(TCP/UDP)를 기준으로 로드밸런싱하는 역할을 합니다.
IP와 포트정보를 보고 정해진 정책에 따라 라우팅해주게 됩니다.

위 그림을 참고해서 예를 들어보겠습니다.

• 로드밸런서에 80번 포트로 들어오는 요청은 백엔드 서비스 1,2,3,4로 연결됨
• 로드밸런싱 알고리즘은 라운드로빈을 사용

이런 규칙을 갖고 있다면 클라이언트가 로드밸런서에 80번 포트로 요청할 때마다 백엔드 1,2,3,4를 번갈아가면서(Round-Robin) 접근할 수 있을겁니다.

이처럼 클라이언트의 데이터에 관계없이 패킷레벨에서만 로드를 분산하기 때문에 빠르고 효율적이라는 장점을 가지고 있습니다.

L4로드밸런서는 tls/ssl termination의 유무에 따라 크게 두가지 디자인이 있습니다.

tls/ssl termination이란?

트래픽을 암호화 및 암호 해독하는 컴퓨팅 집약적인 작업으로부터 백엔드 서버를 해방하기 위한 작업입니다.
ex) client와 lb사이의 개방된 네트워크에서는 https통신, lb와 backend사이는 http통신.

1. TCP/UDP Termination 로드 밸런서

• 구현이 쉽다
• 낮은 지연시간
• tls termination기능을 lb가 수행함

2. TCP/UDP Passthrough 로드 밸런서

• tls termination을 lb가 수행하지 않음
• 대신 연결추적, NAT을 수행한 뒤 각 연결에 대한 패킷이 선택된 백엔드로 전달
  • 연결추적 : 활성 tcp연결의 상태를 추적함. (handshake가 완료되었는지, FIN이 수신되었는지, 연결 유휴 상태가 얼마나 오래되었는지, 연결에 대해 어떤 백엔드를 선택했는지 등의 데이터를 포함)
  • NAT : 패킷이 로드밸런서를 통과할 때 패킷의 ip/포트 정보를 변경

사용하는이유:

• tls termination을 사용하지 않으므로 lb에 가해지는 부하가 적어짐. termination lb보다 훨씬 많은 수의 액티브연결및 초당패킷(PPS)를 처리 가능
• DSR(Direct Server Return) 사용가능해짐

[Background++] DSR(Direct Server Return)이란?

한마디로 정의해서 client->backend로 갈때는 로드밸런서를 통해서 가지만, backend->client로 요청에 대한 답을 줄때는 로드밸런서를 거치지 않고 바로 가는 방식을 뜻합니다.

• Passthrough lb를 기반으로함
• 수신(ingress)/요청(request) 패킷만 lb를 통과
• 송신(engress)/응답(response) 패킷은 lb를 거치지 않고 바로 client로
• 전형적인 HTTP요청/응답패턴에서는 10%정도가 요청이고 90%정도가 응답이라고 할 수 있음. DSR방식을 사용한다면 lb의 부하를 획기적으로 줄일 수 있음
• NAT대신 lb에서는 일반적으로 GRE(generic routing encapsulation)을 사용하여 lb->백엔드로 가는 ip패킷을 캡슐화함. 백엔드에서는 캡슐을 분해해서 클라의 ip와 tcp포트정보를 얻을 수 있다
• 가장 중요한건 백엔드가 로드밸런싱에 참여한다는것. 백엔드에 GRE터널이 올바르게 구성되어 있어야한다.

L7 LoadBalancer

L7로드밸런싱은 Application Load Balancing (ALB)라고도 하며, OSI 7Layer중 Layer7을 기준으로 로드밸런싱하는 역할을 합니다.
IP와 포트정보뿐만 아니라 패킷의 URL정보, 쿠키, payload정보들을 보고 정해진 정책에 따라 라우팅해주게 됩니다.
하위 로드밸런서보다 세부적인 로드밸런싱이 가능하다는 것이 특징입니다.

마이크로서비스간의 통신은 보통 HTTP를 사용합니다. 그래서 HTTP기반 로드밸런서는 이러한 통신을 쉽게 처리할 수 있다는 장점도 있습니다.
또한 DOS같은 비정상적인 트래픽을 필터링할 수 있어 안전성이 높습니다.

하지만 패킷 내용을 복호화하여 처리를 해야하므로 부하가 많이 걸릴 수 있습니다.

References

• Exploring the new IBM Cloud Kubernetes Service LoadBalancer 2.0
• [번역] 최신 네트워크 로드 밸런싱 및 프록시 소개

---