L4/L7 Load Balancing

1. Load Balancing

L4/L7 스위치가 Load Balancing 목적으로 지원하며 동일한 목적을 하는 서버에 부하를 일정하게 분산하기 위하여 사용합니다.
L4는 Transport 계층까지 확인할 수 있으며 L7는 Application 계층까지 확인 가능합니다.
Client는 실제 Load Balancer IP로 접속하게 되어 통신하며 뒷단의 Server IP를 알 수 없습니다. (Reverse Proxy 역할)
LB는 뒷단의 Server Health Check를 하여 문제가 있다면 Load Balancing 대상에서 제외시킵니다.
(하드웨어/소프트웨어 방식이 있으며 본 게시글은 하드웨어 기준이며 장비는 F5를 가장 많이 사용하고 그 다음으로는 Alteon?!)

2. L4/L7 Load Balancer

L4 Load Balancer : Transport 계층 ~ Network 계층 정보를 가지고 Load Balancing
- Client <-> LB, LB <-> Server 별도로 Session을 맺음

인라인, one arm 구성의 경우 위와 같이 세션을 맺고 DSR 구성의 경우 Server -&amp;gt; Client로 응답

L7 Load Balancer : Application 계층 ~ Network 계층의 정보를 가지고 Load Balancing
- HTTP 헤더(URL, 쿠키, 컨텐츠, 브라우저 정보 등)까지 볼 수 있기 때문에 클라이언트 더 많은 정보를 확인 가능하여 섬세한 Load Balancing 가능

- 서버들의 상태를 더 섬세하게 체크할 수 있기 때문에 문제가 있는 서버가 있을 경우 빠르게 제외할 수 있음
- Client <-> LB, LB <-> Server(Client에서 요청이 있을 경우 세션 맺기 시작) 별도로 Session을 맺음
- 그 외 캐싱, 비정상적인 세션(DDoS 공격 등)을 체크하고 사전에 필터링, Qos 가능
(물론 🤔 L7이 좋은 점만 있지만 가격이 비싸기 때문에 목적에 따라 L4 or L7 선택)

3. 구성

Inline
- 단순한 구성으로 모든 Server와 통신하기 위해서 LB를 거쳐야해서 LB 장애 시 통신이 불가능합니다.
- LB가 필요없는 불필요한 스위칭을 해줘야 합니다.
- LB가 Src NAT를 해주기 때문에 Server는 Client IP를 알 수 없어 LB가 별도 DB에 Client IP를 저장 or 헤더에 Client IP가 기록되도록 개발&운영해야합니다.

One Arm
- L4에 문제가 생겨도 BB <-> Server는 통신 가능합니다.
- LB 서비스를 사용하지 않는 Server는 LB를 거치지않고 Server와 통신할 수 있습니다.
- LB가 Src NAT를 해주기 때문에 Server는 Client IP를 알 수 없어 LB가 별도 DB에 Client IP를 저장 or 헤더에 Client IP가 기록되도록 개발&운영해야합니다.
- Server에 따라 트래픽 플로우가 달라 트러블슈팅시 고려해야합니다.

DSR(Direct Server Return)
- 트래픽이 들어올 때는 LB를 거치지만 나갈 때는 LB를 거치지않고 통신합니다.
- LB는 Src/Dst NAT 없이 Server로 트래픽을 전달하며 Server는 처리(Loopback IP와 LB IP가 동일하기 때문에 Server가 처리 가능) 후 LB를 거치지않고 Client로 트래픽을 보낼 수 있습니다.
- Server에는 Loopback IP에 LB IP를 넣고 GARP와 ARP Response를 비활성화하여 LB가 동일한 IP가 있음을 알지 못하게 합니다.
- LB는 SYN 받은 후 SYN+ACK 받은 기록 없이 ACK를 받게 되는데 LB 쪽에서 SYN+ACK 없이 세션이 맺어질 수 있도록 설정이 필요합니다.
- LB가 Src NAT를 해주지 않기 때문에 Server는 Client IP를 직접 알 수 있습니다.

4. Load Balancing 알고리즘

라운드 로빈(Default, Round Robin)
- 요청을 순서대로 각 서버에 균등하게 분배하는 방식
- 서버 커넥션 수나 응답시간에 상관없이 현재 서버들에 돌아가며 트래픽을 분배
- 가장 빠름

IP 해시(IP Hash)
- 클라이언트의 IP 주소를 특정 서버로 매핑하여 분배하는 방식
- 사용자의 IP(+ Port 등 원하는대로 해싱 대상을 지정할 수 있음)를 해싱해 로드를 분배하기 때문에 사용자가 항상 동일한 서버로 연결되는 것을 보장

최소 접속(Least Connection)
- 서버에 연결되어 있는 Connection 개수만 갖고 단순 비교하여 가장 적은곳에 분배하는 방식
- 신규 서버가 들어올 경우 가장 균등하게 분배할 수 있음

그 외 가중치 최소 접속(Weighted Least Connections), 응답 시간(Fastest Response Time) 등

5. Health Check

ICMP
- Netwrok 계층에서 확인하며 IP를 통해 상태 체크할 수 있습니다.

TCP
- Transport 계층에서 확인하며 세션을 통해 상태 체크할 수 있습니다.
- LB는 Interval에 따라 Health Check를 계속 하기 때문에 Server가 해당 세션을 가지고 있지 않도록 LB가 RST로 세션을 종료해줘야 합니다.

HTTP
- Application 계층에서 확인하며 웹 서비스를 통해 상태 체크할 수 있습니다.
- LB는 Interval에 따라 Health Check를 계속 하기 때문에 Server가 해당 세션을 가지고 있지 않도록 LB가 RST로 세션을 종료해줘야 합니다.

6. SSL Offload

- SSL은 Transport 계층 Security로 LB가 SSL 인증서를 가지고 TLS Handshaking을 대신해줄 수 있습니다.
- Client <-> LB는 HTTPS(Default 443 Port), LB <-> Server는 HTTP(Default 80 Port) 통신을 하기 때문에 LB는 Port NAT를 해줘야합니다.
- 하지만? 이렇게 외부에서 LB 통해 Client가 접속하는 Server는 DMZ이기 때문에 LB <-> Server가 HTTP 통신을 하는 건 보안 목적으로 허용하지 않을 수 있습니다. 🤔

참고(도움이 매우 많이 되었습니다) :
https://aws-hyoh.tistory.com/entry/L4-Switch-%EC%89%BD%EA%B2%8C-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0?category=767420

L4 스위치 쉽게 이해하기 #1(L4 스위치의 개요)