Loadbalancer란? Round Robin vs Least Connection

 

 

Loadbalancer란?

종단 서버의 부하분산을 위해서 Loadbalancer(이하 LB) 서버(혹은 전용 장비)에 트래픽이 들어온 후 네트워크 분산하는 솔루션

nginx, envoy 혹은 기타 소프트웨어(proxy 소프트웨어등)로 구현될 수 있으며, 고가의 로드밸런싱 전용 장비도 있습니다.

 

LB는 vip라고 불리는 ip를 사용하며, clinet는 해당 vip로 트래픽을 전송합니다.

LB는 이렇게 들어온 트래픽들을 자신이 정한 Rule에 맞춰 종단 서버로 포워딩합니다.

 

L4 계층부터 세션의 의미를 가지므로 트래픽 분산이 정상 동작할 수 있습니다.

여기서 말하는 세션이란, 의미가 있는 데이터(패킷)들의 모음입니다. 

UDP에는 TCP와 같은 완전한 연결형 프로토콜은 아니지만, clinet의 ip와 port를 보고 어디부터 어디까지의 패킷이 하나의 세션을 갖는지 알 수 있습니다.

예로 Client에서 "i am ahsung" 이라는 데이터를 보냈고 패킷이 인터넷 상에서 "i", "am", "ahsung" 3개의 패킷으로 쪼개졌다고 합시다.

L3 계층만으로는 패킷1, 패킷2, 패킷3이 마구잡이로 들어왔을 때, LB는 어디부터 어디까지가 의미있는 개념을 갖는 데이터들의 모음인지 알수가 없고

이렇게 쪼개진 데이터를 종단 서버로 분산해서 보내게되면, 각 서버 입장에서는 의미없는 데이터만 받을 뿐입니다.

그렇기 때문에 최소 L4의 계층에서 "i", "am", "ahsung" 3개의 패킷은 같은 세션이라는 것을 인식하고 분산이 이루어져야합니다.

TCP는 connection 단위로 분산하게 되고 한번 맺어진 connection 트래픽은 똑같은 종단 서버로만 보내게됩니다. 

 

보통 L4, L7  두 종류의 로드밸런서가 있으며 어떤 레이어의 패킷까지 인식하며 트래픽 포워딩시 기능을 지원하는가에 차이가 있습니다.

L4 계층은 보통 L3계층의 ip와 L4 계층의 port까지 인식하고 수정하여 포워딩할 수 있으며, 해당 계층 관련한 서비스를 제공하기도 합니다. ddos, 플로딩 방지 등등

 

L7은 애플리케이션단까지 패킷을 열어보고 수정이 가능합니다.

보통은 http(s)를 지원하는 경우가 많고 nginx, envoy와 같은 웹서버들이 대표적으로 사용될 수 있습니다.

(LB 전용 장비에서도 기능을 지원합니다.)

L7의 패킷을 인식하고 수정이 가능하므로, 보통 L7은  인증서를 대신 처리하고 종단 서버로는 http/ TLS가 없는 형태로 포워딩을 할 수 있습니다.

L7 계층 패킷의 인식, 수정이 가능하므로 이론적으로 헤더를 읽고 토큰 인증처리 등 해당 계층에서 할 수 있는 동작은 모두 가능합니다.

(L7 LB에 따라 어디까지 지원해주냐는 다름)

 

 

또한 종단 서버와 패킷을 주고 받는데 보통 2가지 방식이 있습니다.

Inline

요청: Client -> LB -> Server 

응답: Server -> LB -> Client

 

요청과 응답에 LB가 모두 관여하며 Proxy처럼 동작합니다.

모든 동작에 LB가 관여하기 때문에 보안상으로 더 안전하게 관리가 가능하지만 LB의 부하 이슈가 존재합니다.

 

DSR(Direct Server Return)

요청: Client -> LB -> Server

응답: Server -> Client

 

요청은 LB를 통해서 받지만, client로의 응답은 Server가 바로 보내게 됩니다.

이를 가능하게 하려면, Client 입장에서 응답을 LB의 ip(vip)로부터 받은 것처럼 인식 시켜야합니다.

 

이를 가능하게 하는 기술로는 Server측에서 LB와 같은 ip를 사용하되 Server 내부적으로만 사용할 뿐, 외부로 광고(arp) 하지 않아야합니다.

(같은 ip를 여러 장비가 사용한다고 외부 스위치등의 네트워크 장비에 광고하게 되면 ip 트래픽이 무너져버립니다.)

 

이것을 구현하는 첫 번째 방식으로 L2DSR이 있습니다.

서버측은 ARP 광고를 하지 않는 lo(루프백 인터페이스)에 vip를 할당하고 LB가 L2계층의 mac 주소를 종단 서버의 Mac 주소로 바꾸어 패킷을 전달합니다.

패킷의 ip는 여전히 vip이지만 변조된 Mac 주소로, 종단 서버 NIC를 통과하여 CPU까지 트래픽은 인입에 성공합니다.

보통의 경우 커널은 인터페이스에 할당된 IP가 아니라면 패킷을 drop 하지만 lo 인터페이스를 통해서 성공적으로 받아드릴 수 있습니다.

그후 자연스럽게 Src, Dst를 주소를 뒤집어 패킷을 응답하기 때문에 vip로 트래픽을 리턴하게 됩니다.

 

하지만 해당 방법은 mac주소만으로 LB와 종단 서버가 통신할 수 있어야하므로 같은 LAN에 반드시 존재해야한다는 단점이 있습니다.

 

 

이를 피하는 L3dsr 방법은 터널링이나 iptables를 사용하는 방식이 있습니다.

 

터널링

https://itpenote.tistory.com/409

IP 터널링

보통 터널링은 IP 헤더 한층 더 ip 헤더를 캡슐화해서 더 빠른 라우팅으로 패킷이 전달되도록 공중 인터넷 망에서 사용되는 기술이지만, LB <-> 종단 서버단에서도 사용합니다.

 

OS마다 설정 방식은 조금 다르지만 Linux를 기준으로 설명하자면, 커널은 VIP가 할당된 터널 인터페이스를 할당합니다.

이때 터널 인터페이스를 할당하려면 커널이 터널 프로토콜을 이해할 수 있는 메커니즘이 있어야합니다. (커널은 터널링 관련 모듈을 on/off 할 수 있음)

 

LB에서 종단 서버로 터널링(캡슐화/ ip in ip) 프로토콜을 사용해서 client로 부터 받은 패킷 위에 종단 서버의 ip를 덧씌워(캡슐화하여) 패킷을 발송합니다. 외부 네트워크는 Outer IP 헤더의 Dst IP가 종단 서버의 IP이기 때문에 종단 서버까지 트래픽이 도달합니다.

  - Inner IP 헤더 = (Src IP = Client IP, Dst IP = VIP)

  - Outer IP 헤더 = (Src IP = 임의 IP, Dst IP = 종단 서버 IP)

 

터널링 프로토콜은 ip 헤더중 protocol 영역에 표시가 되있어서 인식이 가능합니다.

종단 서버는 터널링 인터페이스와 ipip 모듈등을 활성화했기 때문에 해당 ip 헤더가 outer ip 헤더인 것을 인지하고 역캡슐화를 통해 inner ip 헤더를 확인하고 Inner 헤더의 Dst IP를 받아들일 수 있는 터널 인터페이스를 따라 트래픽을 수신하고 상위 계층(애플리케이션)까지 도달합니다.

 

이때 패킷은 Inner IP 헤더 기준으로 받았기 때문에 TCP 소켓은 Inner IP 기준의 (Src, Dst)로 생성됩니다. 즉, 응답을 Src VIP로 만들어 패킷을 송신합니다.

이때 중요한게ip 헤더가 하나 더 추가됨에 따라 MTU 사이즈가 표준 보다 커질 수 있으므로 협상할 MSS를 미리 작게 해야합니다.

표준이 MTU가 1500, TCP_MSS가 1460 때문에 outer ip가 추가될 것 까지 계산해서 MSS를 1440으로 협상하게 해야합니다.

TCP_MSS 1460 그대로 협상할 경우, Client <-> LB 패킷 통신은 큰 문제 없지만 LB에서 outer ip를 씌워 MTU가 1520으로 초과하면, LB -> 종단 서버 트래픽 흐름중 표준 1500 초과를 지원하지 않는 중간 네트워크 홉이 패킷을 떨구거나, 종단 서버가 drop할 수 있습니다.

 

또한 RP filter와 같은 커널 네트워크 메커니즘을 회피하는 설정도 필요할 수 있습니다.

RP(Rerverse Path) filter 쉽게 설명하자면 수신된 패킷의 Src IP를 열어서, 올바른 경로로 들어왔는지, 현재 들어온 인터페이스의 역방향 라우팅을 검증해봅니다. 좀 말이 이상하죠? 저도 처음에 뭔소리야 싶었는데..ㅋㅋㅋ..

 

대충 쉽게만 설명해보자면 응답한다고 가정해보면 수신했던 Src IP가 Dst IP가 되겠죠? 이때 라우팅 테이블을 보고 Dst IP를 라우팅할 수 있는 경로의 인터페이스로 패킷을 내보낼 것입니다.

이때 라우팅 가능한 인터페이스와 현재 들어온 인터페이스가 다르면 이놈 스푸핑 공격인가? 하고 drop하는 개념이죠

 

좀 더 쉽게 설명하면, 서버 입장에서 어? 나는 eth0 인터페이스가 연결된 네트워크로는 도저히 이 IP 주소로 도달 시킬 수 없을거 같은데, 이거 어떻게 온거지? 검사하는거죠

 

RP filter는 사용안함, 엄격, 느슨 세 단계가 있습니다.

엄격은 정확하게 들어온 인터페이스의 라우팅 테이블을 검사합니다. 느슨은 모든 인터페이스의 라우팅 테이블 기준으로 검사하죠

특히 느슨 단계 + default 라우팅 설정된 인터페이스가 있으면 그냥 안한거랑 같을 거 같습니다...ㅋㅋㅋ (테스트는 안해본..)

 

최신 배포판들은 기본이 엄격 모드라고 합니다.

대부분의 서버는 default 라우팅 설정이 있는 인터페이스 한 개만 사용할 거라 큰 문제 없지만 여러 인터페이스를 사용하는 서버들은 신경써야합니다. 특히 이 설정은 가상 인터페이스라고 봐주는 거 없고 보통은 가상 인터페이스에 라우팅 설정은 안하기 때문에 터널 인터페이스의 RP Filter를 꺼야합니다.

 

 

iptables를 통해 패킷의 tos 영역을 참조한 L3DSR 사례

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

kakao의 L3DSR 구성 사례

이건 아주 대충 설명하면,

1. IP 헤더에는 tos라는 보통 잘 사용 안하는 영역이 있습니다.

2. 서버는 lo 루프백 인터페이스에 VIP를 할당합니다. (L2DSR과 동일)

3. 서버에 iptables 규칙을 추가합니다.

    - IP 헤더의 TOS 필드에 특정 값이 들어오면 PreRouting 단계에서 의도한 Dst IP를 VIP로 변조합니다.

    - 예로 서버 하나당 VIP를 10.10.10.11, 10.10.10.12 두 개 쓴다면, tos=10 => 10.10.10.11, tos=20 => 10.10.10.12로 변조

4. 변조된 Dst IP(VIP)는 lo 루프백 인터페이스를 통해 수신될 수 있고 이후는 L2DSR과 동일한 방식으로 응답합니다.

 

TOS의 문제점이 있는데, 해당 필드를 LB와 종단 서버외 다른 곳에서 사용하면 충돌이 발생할 수도 있습니다.

Client 시스템쪽에서도 다른 사유로 TOS 필드를 사용하고 있는데, LB에서 DSR용도로 그 tos를 덮어씌운다거나

혹은 LB를 통해서 들어온 패킷이 아닌데 마침 TOS 필드를 사용중이었어서 의도치 않게 lo 인터페이스를 타고 엉뚱하게 src ip를 vip로 변조한다던가..

 

 

Round Robin

종단 서버로 커네션을 순서대로 분산한다.

 

Least Connection

활성화된 커넥션이 적은 서버부터 분산한다.

Round Robin도 순서대로 커넥션을 전달하기 때문에 무슨 차이가 있나 싶겠지만,

client와 커넥션 수명은 상황에 따라 모두 다를 수 있다.

특정 서버의 커넥션이 오래 살아 남은 경우 Round Robin 방식은 특정 서버에 부하가 더 몰릴 가능성이 있다.