로드밸런서에 대해 알아보자

회사에서 L4 스위치와 로드벨런서 관련된 이슈들을 경험해보며,

로드벨런서에 대한 정리가 필요해보여 기록하게되었습니다.

 

도입

 

로드벨런싱 자체는 L2, L3, L4, L7 모두 가능합니다. 

하지만 일반적으로 로드벨런서는 L4 Switch를 말하며, 

 

이 글에서 설명하는 LB 또한 L4 Switch 관점에서 작성하였습니다.

 

1. 로드벨런서의 주요 역할

 

로드벨런서의 사용하는 이유는 아래와 같습니다.

 

1.1 부하 분산 

 

서비스의 규모가 커지다되면 단일 서버로는 모든 트래픽을 버틸 수 없습니다.

이런 경우 보통 서버를 두대 이상 띄우는 Scale-Out 형태로 서버를 증설하게 됩니다.

 

이때 늘어난 N 대의 서버에 부하를 분산시키는걸 부하 분산이라고 하며,

아래의 알고리즘 중 하나를 택해 사용됩니다.

 

부하분산 알고리즘

 

1.1.1 라운드 로빈

 

리얼 서버들의 부하를 순차적으로 시간단위로 분산합니다. 

시간단위지만, 서버별로 가중치를 둘 수도 있습니다. 

 

1.1.2 최소 접속 수 

 

활성화된 세션수가 가장 적은 서버부터 부하분산합니다. 

L4 Switch에는 연결되는 리얼서버간 세션수를 확인 할 수 있는 세션테이블이 존재하는데

이를 통해 판단합니다. 라운드로빈처럼 리얼 서버마다 가중치를 둘 수도 있습니다. 

 

다만 신규서버가 추가될경우 많은 트래픽이 신규서버로 몰릴 위험이 있습니다.

 

1.1.3 해시

 

접속 IP/ 목적지 포트 등을 해싱하여 서버 부하를 고려하지 않고 

클라이언트가 같은 리얼 서버에 지속적으로 접속할 수 있도록 하는 부하분산 방식입니다.

 

이러한 상태를 Sticky 하다고 하며, Sticky Session과 같은 방식을 사용할 때 적용됩니다. 

 

1.2 헬스 체크 

 

Scale-Out된 서버들 중 일부가 장애가 발생한다면 해당 서버들을 로드벨런싱 대상에서 제외시켜야합니다.  

이를 위해 LB는 자신이 로드벨런싱하는 서버들에 대해 주기적으로 헬스 체크를 합니다. 

 

L4에서는 리얼서버들이 살아있는지 확인하기 위해 두가지 방법이 있습니다. 

 

1.2.1 핸드쉐이킹

 

첫번째는 TCP에서 연결을 실행하는 3-Way-Handshaking 또는

연결을 종료하는 4-Way-Handshaking 형태와 유사하게 진행됩니다. 

 

 

1.2.2 Half Open

 

두번째는 TCP 세그먼트의 플래그값 에서 RST(reset) 값을 보내

3-Way-Handshaking 중간에 세션을 끊어버립니다.

 

이 방식을 사용하면 헬스체크로 인한 부하를 줄이거나,

위의 기존 핸드쉐이킹보다 빨리 세션을 끊을 수 있습니다. 

 

 

나머지 레이어에서는 아래와 같은 방법을 통해 헬스체크를 진행합니다. 

 

L2	ARP response 확인
L3	ICMP (ping) 확인
L7	HTTP Request

 

2. 로드 벨런서 구성 방식

 

로드벨런서의 구성방식은 형태에 따라 인라인 구조과 원암 구조으로 나눌 수 있습니다. 

 

2.1 인라인 구조

인라인 형태의 로드벨런서 구성

 

인라인 구조는 위 사진처럼 LB가 스위치에서 리얼 서버까지 일직선상 경로에 있는 형태를 말합니다.

네트워크 구성이 직관적이라는 장점이 있지만, LB를 거칠 필요가 없는 모든 트래픽들이

로드벨런서를 경유하기때문에 LB에 부하가 많이 갈 수 있습니다. 

 

2.2 One-ARM 구조

 

원암 형태의 로드벨런서 구성

 

원암 구조는 LB가 스위치 옆에 있는 형태입니다. 한쪽 팔을 벌린 형태와 유사하여 원암으로 불립니다. 

원암 구조에서의 장점은 모든 트래픽이 LB를 경유하지 않아도 된다 는 점입니다.

단점으로는 인라인 구조보다 조금 더 설정이 까다롭다는 점입니다. 

 

원암 구조에서는 리얼 서버 응답이 다시 LB를 거쳐 사용자에게 전달되기 위해

DNAT (Destination NAT) 뿐 아니라 SNAT(Source NAT) 이 같이 수행되어야합니다.

 

이 때문에 모든 클라이언트 IP가 LB의 IP로 찍히는 경우 도 간혹 있습니다. 

이 경우는 서비스 운영에 꽤 치명적이지만, 

 

아래 후술할 LB의 동작 모드 중 DSR(Direct Server Return)을 사용하여 해결 할 수 있습니다.

 

3. 로드 벨런서의 동작 모드

 

로드 밸런서는 크게 세가지 형태로 동작합니다.

 

3.1 트랜스패런트 모드

 

트랜스패런트 모드는 LB가 L2 스위치처럼 동작합니다.  

LB에서 사용하는 VIP 주소와 실제 서버가 동일한 네트워크를 사용합니다.  

 

기존의 네트워크 대역을 그대로 사용하는 투명한 구조를 사용한다 하여 붙여졌습니다.  

 

요청시 LB로 전달된 도착지 IP와 MAC 주소를 리얼 서버의 IP와 MAC 주소로 변조하여 동작하며

응답시에는 목적지 MAC 주소는 이미 게이트웨이 주소를 가지고 있어 따로 변조하지 않습니다.  

 

인라인, 원암 모두 사용가능하지만 원암 구성에서는 LB에서 SNAT을 필요로합니다. 

 

트랜스패런트 상태의 Request

 

트랜스패런트 상태의 Response

 

3.2 라우티드 모드

 

이름처럼 LB가 라우팅 역할을 수행하는 모드입니다. 

LB 기준으로 서로 다른 네트워크가 분리되어있습니다.

 

보안 강화 목적으로 네트워크를 사설로 분리하여 구축할 때 사용됩니다. 

트랜스패런트 모드와 비슷하지만, 응답시 출발지 MAC 주소도 변경해야된다는 차이가 있습니다. 

 

라우티드 모드

 

3.3 DSR 모드

 

DSR은 Direct Server Return의 줄임말이며 원암 구조에서만 사용됩니다.

행해지는 네트워크 레이어에 따라 L2DSR 과 L3DSR로 나뉩니다. 

 

이전 두개의 모드들은 응답이 LB를 경유하여 나갔지만, 

DSR 모드는 LB를 경유하지 않고 리얼서버에서 직접 응답을 내려줍니다. 

 

응답 트래픽이 LB를 경유하지 않으므로 LB에 부하를 적게준다는 장점이 있지만,

단점으로는 위의 두 모드와는 다르게 리얼서버에서도 추가설정을 해줘야한다는 점,

응답이 LB를 거치지 않아 문제확인이 어렵다는 단점이 있습니다. 

 

DSR 모드 예시

 

구성에따라 L2DSR은 # 부분에서 동일 네트워크만 가능하고

L3DSR은 # 부분에서 다른 네트워크에서도 가능합니다. 

 

3.3.1 L2DSR

 

L2DSR에서 MAC 주소 변경을 통해 클라이언트의 요청을 전달합니다.

이때 IP 주소를 MAC 주소로 변환하는 ARP Request 범위 내에 있어야하며,

그로인해 LB와 리얼 서버 모두 동일 네트워크에 속해있어야만 합니다.

 

간단하게 리얼서버들의 루프백 IP가 LB의 VIP로 된다고 생각하면됩니다. 

 

이를 위해 리얼서버들은 다음과 같은 설정이 적용되야합니다.

 

1. 중복된 IP로 MAC이 갱신되지 않도록 위의 VIP에 대한 ARP 브로드캐스팅에 응답 금지 

 

- 해당 ARP 브로드캐스팅은 LB만 해야합니다.

 

2. 루프백 인터페이스가 자기 자신이 아닌 위의 LB와 동일한 VIP로 변경

 

- LB에서 리얼서버로 요청이 전달 될 때 목적지 IP가 리얼서버 IP가 아닐 경우 요청이 폐기됩니다. 

이를 우회하기 위해 리얼서버의 루프백 인터페이스가 LB의 VIP로 되어야합니다. 

 

이후 LB에서는 목적지 IP 변경 없이 목적지의 MAC 주소만 리얼 서버의 MAC주소로 변경하여 

요청을 전달합니다.

 

L2 DSR

 

3.3.2 L3DSR

 

L3DSR은 L2DSR이 동일 네트워크 대역에 위치해야한다는 한계를 극복하기 위해 야후에서 처음 소개되었습니다. 

MAC주소 대신 IP주소를 변경해 전달합니다. 

 

L3DSR은 IP 터널링 방식 (IPv6를 IPv4로 터널링하듯이)과 DSCP 기반 방식이 있습니다.

여기서는 DSCP 기반 방식만 설명합니다.

 

DSCP 방식은 IP헤더 중 DSCP 필드를 조작하여 통신하는 방식입니다.

(아래 IPv4 헤더의 필드 중 DSCP 와 ECN 필드를 합쳐 TOS 필드 (Type Of Service) 라고 부릅니다)

 

L2 DSR과 마찬가지로 루프백 인터페이스를 LB와 리얼서버 모두 동일한 VIP 설정하도록 합니다.

해당 VIP에 대한 ARP 응답 또한 리얼서버에서는 하면 안됩니다. 

 

리얼서버들은 LB에서 설정한 DSCP 필드값으로 요청이 왔을 경우 목적지 IP가

내 IP가 아니더라도 패킷을 허용하도록 설정한 후 도착지 IP를 위의 루프백 인터페이스에서 설정한 VIP로 응답합니다.

 

L3DSR - 구성 // 출저 : https://github.com/yahoo/l3dsr/blob/master/docs/nanog51.pdf

 

DSCP 필드 출저: 위키피디아

 

4. 로드벨런서의 HA 구성

 

로드벨런서 또한 과도한 요청으로 장애가 생길 수 있습니다.

이에 각 제조사마다 또는 공통으로 사용되는 HA 구성을 위한 프로토콜을 제공합니다.

 

VRRP와 HSRP 등이 존재하며 간단하게 RFC 표준으로 정의된 VRRP 만 정리합니다.

 

VRRP는 RFC5798로 등록되어있으며, Master와 Backup 상태가 있습니다.

LB들은 서로 VRRP advertisement packet 을 주고받으며 이 패킷의 필드 중

Priority 가 높은쪽이 Master가 되며 모든 트래픽을 받게됩니다. 

 

Matster에 장애가 발생할 경우에도 VRRP advertisement packet을 다른 LB에 전달하지 못하니

다른 Priority가 높은 LB가 Master로 승격됩니다.

 

VRRP 

 

후기 & Reference 

 

굉장히 어질어질한 내용이 많았는데 생각날때 다시 공부하면서 더 찾아봐야겠습니다.

 

(책) IT 엔지니어를 위한 네트워크 입문

https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=254155831

IT 엔지니어를 위한 네트워크 입문

 

야후의 L3DSR 소개

https://github.com/yahoo/l3dsr/blob/master/docs/nanog51.pdf

 

kakao의 L3DSR 구성 사례

https://tech.kakao.com/2014/05/28/l3dsr/