로드 밸런싱(SLB, Server Load Balancing) 기본 개념

패킷이 네트워크 장비에 의해 어디로 보내질지는 몇 계층 통신인가, 그래서 어떤 데이터를 보느냐에 따라 달라진다. 이 구분은 OSI 7 Layer model에 기반한다.

 

• Layer 2 : Ethernet Header의 MAC address 구분
• Layer 3 : IP Header의 IP address 구분
• Layer 4 : TCP,UDP Header의 Port 구분, packet 조작, Session 관리
• Layer 7 : Application 별 Payload 구분 (HTTP, RTSP 등) 

이 중 여러대의 서버로 부하를 분산하는 로드밸런싱(SLB, Server Load Balancing) 기법은 일반적으로 L4 통신에 해당한다. 보통 서비스 운영에 필요한 포트를 기준으로 분산시키기 때문이다. 그래서 LB 전담 장비들을 L4 장비라고도 부른다.

가장 점유율이 높은 벤더는 Citrix이며 Brocade, F5 사에서도 L4 장비를 제작하고 있다. 각 제조사별 운용 방식 및 config가 상이하며 운영 시엔 각 장비의 특징을 이해하는 것도 중요하겠다.

 

각설하고.

이런 L4 전용 장비들의 위치에 따라 여러가지 운용 mode가 갈리게 되며 그 기법에 대한 기본 개념을 정리한다.

그전에 한 가지만 기억하자. "모든 네트워크 통신에서 요청에 대한 응답은 src/dst를 뒤집어서 보내는 게 원칙"이다. 

 

---

1. Inline mode, 인라인 모드

그야말로 L4 장비가 클라이언트와 서버 통신 라인에 함께 있는(in-line) 구조를 의미한다. 

가장 쉬운 구성으로 모든 트래픽이(서버간 통신이라도) L4 장비를 거치게 되며 client IP가 L4 IP로 바뀌지 않고 그대로 server로 전달된다는 게 가장 큰 특징이다. 이 특징으로 인해 Inline 모드로 운영하는 경우도 있지만 대부분 안전성(L4 장애시 서버 통신도 불가) 및 효율성 문제 때문에 권고되지 않는다.

 

---

2. Proxy mode, 프록시 모드

앞선 Inline mode에서 VIP를 향한 통신만 LB 하겠다는 의지를 담은 구조이다. 불필요하게 L4 자원을 갉아먹던 서버 간 통신은 더 이상 L4 장비를 거치지 않는다. 

client가 VIP로 요청하면 이를 L4 장비가 받아 source IP를 L4 IP로 변경하여 내부 server로 전달하고,

server로부터 받은 응답의 source IP를 L4 VIP로 변경하여 다시 client에게 제공한다. (모든 요청에 대한 응답은 src/dst이 반전돼야 하니까 이 귀찮은 걸 하는 거다. 상기)

이 때문에 서버는 클라이언트에 대한 정보를 전혀 모르며, L4 장비는 어떤 client에서 보낸 요청을 변환하여 어떤 서버로 보냈는지 프락치짓을 했는지 히스토리를 남기기 위해 connection table 또는 session table을 가지고 있어야 한다. 

보통 TCP 기반 통신에서 FIN, RST 플래그를 받으면 해당 테이블에서 삭제하는 방식으로 session을 관리한다. (expired time도 따로 있다. 보통 30분)

 

이처럼 proxy 모드에서는 L4 장비가 VIP 관련 모든 통신을 다 볼 수 있으므로 보안 모니터링 등이 필요한 특수상황에서 꼭 필요한 구조이나, 트래픽이 많을수록 불리하며, 서버 입장에선 보이는게 L4의 IP뿐이므로 어떤 클라이언트가 요청을 했는지 전혀 알 수 없다. (만약 꼭 필요하다면 http 헤더 안에 client IP를 캡슐화해서 보낼 수는 있을 듯)

 

---

3. DSR (Direct Sever Return) 구조

이전까진 server는 client와 접점이 없었기에 누가 이 요청을 했는지도 모르고, 애초에 client가 보고 던지는 VIP도 알 필요가 없었다. 그야말로 L4 장비만 열일하는 구조이다.

그렇다면 요청 하나마다 많은 양의 데이터를 제공해야 하는 contents provider 성격을 띠는 서비스에서는 어떨까?

이는 inbound 트래픽보다 outbound 트래픽이 훨씬 높다는 것을 의미하는데 트래픽 분산 대상이 아닌 outbound 트래픽까지 L4가 감당하게 되면 리소스 낭비이지 않을까. 

 

기술의 발전은 귀찮음에서 나온다고 했던가. L4 장비의 귀찮음을 줄이기 위해 client로 가는 응답을 server가 직접 수행하는 구조가 탄생했다. Direct Server Return(DSR) 즉, 서버가 직접 리턴한다. 이름 참 직관적이다.

(+) 클라이언트 입장에서 요청의 Destination을 VIP로 보냈으면 응답은 Source를 VIP로 달고와야 정상이다. 즉 서버가 VIP를 source로 클라이언트에게 응답해줘야 하기 때문에 VIP를 자신의 IP로 인지할 필요가 생겼다.

 

---

1) L2DSR

서버가 클라이언트로 직접 응답하기 위해선 클라이언트가 알고있는 VIP를 이제 서버도 알아야한다. (요청/응답 반전 법칙을 다시 일깨우자.) 때문에 서버에 L4 VIP와 동일한 Loopback IP를 설정해 두어야한다. 

 

그럼 VIP만 보고 L4 장비인지 server인지 어떻게 구분하는가? Layer 2에 해당하는 mac 주소를 본다. (그래서 "L2" DSR이다.) IP 주소와 포트 정보는 건드리지 않는다.

 

이처럼 먼저 요청을 받은 L4 장비가 destination mac 주소를 server mac 주소로 변환하여 전달하고, 서버는 vip를 향한 client 요청이 자신의 것임을 알고 응답하게된다.

 

하지만 L2DSR 구조는 매우 크리티컬한 전제조건이 있다.

L4 장비와 서버가 L2 통신이 되어야만 한다는 것 즉, 바인딩 할 Server들은 꼭 L4 장비와 같은 Broadcast domain에 있어야한다는 소리다. 그렇지 않다면 mac 주소만보고 올바른 서버로 찾아들어 갈 수 없다. 

 

이는 일반적으로 서로 물리적으로 연결돼있다는걸 의미하는데, 증설 등 여러 이유로 서버는 어디에나 필요해질 수 있기에 이런 위치/공간적 제약은 서비스 운용에 큰 한계로 다가왔다.

 

---

2) L3DSR

L3DSR은 L2DSR과 기본적인 목적과 효율은 동일하나 서버 위치적 제약을 탈피할 수 있는 구성이다.

L4 장비와 서버가 상호 통신 가능한 구조기만 하면 구성할 수 있으며 mac 변조를 했던 L2DSR과 달리 Inbound Packet의 Destination IP를 변조한다.

이 변조를 IP header 중 어떤 부분을 이용하여 수행하는지 따라 IP Tunnel 방식, ToS field의 DSCP를 활용하는 2가지 방식으로 구분된다.

 

2-1) IP Tunnel 기반 L3DSR

IP header 자체가 하나 더 붙는 구조이다. 기존의 클라이언트의 요청을 Inner IP header에 그대로 보존한 뒤 덧붙여진 Outer IP header의 Destination IP(=server real ip)를 보고 실제 server를 찾아 들어간다. (이 때 Outer Source IP는 통신에 영향을 주지 않기에 벤더마다 이 값을 L4 IP를 주는데가 있고 Client IP로 설정하는 데가 있다.)

L4에서 추가된 Outer IP header는 서버의 ethernet에서 처리되어 사라지고, 남은 기존의 Inner IP header를 tunnel interface에서 처리한 뒤 client로 응답해준다.

 

일반적으로 Ethernet MTU는 1500이며 IP/TCP header 각 20 Byte를 제외한 Payload, 즉 MSS(Maximum Segment Size)는 1460이다. 하지만 IP Tunnel 기반 L3DSR에서는 IP header 하나가 추가되기 위한 20 Byte의 공간이 더 필요하기 때문에 MSS를 1440으로 조정한다. 조정하지 않는다면 패킷은 라우팅 과정에서 Fragment 되며, DF flag가 1로 설정됐다면 아예 drop될 것이다.

이렇듯 MSS 값 조정이 필요하다는 조건 때문에 Linux 계열 서버에만 적용 가능하다는 단점이 있다. (windows 서버는 mss 조정에 한계가 있다)

 

2-2) ToS(DSCP) 기반 L3DSR

DSCP(Differentiated Service Code Point)는 IPv4 기준 ToS(Type of Service) Field의 상위 6 bit 값으로, 이를 통해 특정 트래픽 유형에 대한 우선 순위를 지정할 수 있다. 

 

일반적으로 QoS 개념에서 등장하는 용어로 세부 용도가 다양하지만,

SLB에선 사전에 L4와 server 간 VIP와 DSCP를 mapping 시켜두어 DSCP를 보고 VIP에 바인딩 된 서버를 찾아가게 하는 용도로 사용된다. 즉, 특정 VIP로의 요청을 서버의 Loopback Interface까지 전달되게 하는 용도로 쓰인다. 

 

L4와 server가 공유하는 VIP/DSCP 정보를 mapping table이라 명하겠다.

클라이언트로부터 Inbound Packet을 받은 L4는 Destination IP를 서버의 real IP로 변조한 뒤, mapping table 정보를 바탕으로 DSCP를 세팅하여 서버로 전달한다. 동일한 DSCP가 설정된 서버는 mapping table를 보고 자신의 Loopback IP(=VIP)로 온 요청인줄 알게 된다. 이에 Source IP를 VIP로 설정 후 DSCP를 0으로 세팅하여 클라이언트로 응답한다.

 

 

다시는 아이패드로 그림그린다고 까불지 않겠습니다.