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 트래픽이 무너져버립니다.)
그것을 가능하게하는 기술로는 서버측은 lo(루프백 인터페이스)에 vip를 할당하고
(루프백에 할당된 ip는 arp로 광고하지 않습니다. 대표로 127.0.0.1)
LB가 L2계층의 mac 주소를 종단 서버의 주소로 바꾸어 패킷을 전달하는 방법이 있습니다.
패킷의 ip는 여전히 vip이지만 L2 계층 통신으로 종단 서버 NIC는 통과하여 CPU까지 트래픽은 인입에 성공합니다.
그후 보통의 경우 OS는 인터페이스에 할당된 ip가 아니라면 패킷을 drop하지만 lo 인터페이스를 통해서 성공적으로 인입합니다.
그후 자연스럽게 ip는 vip로 트래픽을 리턴하게 됩니다.
하지만 해당 방법은 mac주소만으로 LB와 종단 서버가 통신할 수 있어야하므로 같은 LAN에 존재해야한다는 단점이 있습니다.
이를 피하는 L3dsr 방법은 터널링이나 iptables을 사용한 특정한 Rule을 사용해서
서버만 인식하는(arp하지 않는) vip가 할당된 특수한 네트워크 인터페이스 (터널용 인터페이스 혹은 루프백 인터페이스)까지 트래픽을 도달 시켜 사용합니다.
터널링
https://itpenote.tistory.com/409
IP 터널링
캡슐화, IPSec, IPv4-inIPv6 터널링, Mobile IP I. 인터넷 상의 가상의 파이프라인 생성, IP 터널링의 개요 가. IP 터널링의 정의 - IP 계층 상에 전용망 환경에서 point-to-point로 연결한 것과 같은 효과를..
itpenote.tistory.com
보통 터널링은 외부에 한층 더 ip 헤더를 캡슐화해서 더 빠른 라우팅으로 패킷이 전달되도록 공중 인터넷 망에서 사용되는 기술이지만,
LB <-> 종단 서버단에서도 사용합니다.
LB에서 종단 서버로 터널링(캡슐화/ ip in ip)프로토콜을 사용해서 client로 부터 받은 패킷중 L3계층에 외부 ip를 종단 서버의 ip로 캡슐화하여 외부 네트워크로 보냅니다.
외부 네트워크는 종단 서버의 ip만 인식하여 종단 서버까지 트래픽이 도달합니다.
(터널링 프로토콜은 ip 헤더중 특정 영역에 표시가 되있어서 인식하고자하면 인식이 가능합니다.)
종단 서버는 터널링 인터페이스를 통해 터널링 프로토콜을 번역할 수 있고 역캡슐화하여 내부 ip 패킷을 받아드립니다.
상위 계층의 port정보등을 통해 애플리케이션단까지 데이터가 도달하게 됩니다.
보통의 인터넷 네트워크 장비는 이렇게 역캡슐화된 ip를 진짜 ip의 주인에게 다시 보내는 작업을 합니다.(네트워크 장비의 소프트웨어)
iptables를 통해 패킷의 tos 영역을 참조한 L3DSR 사례
https://tech.kakao.com/2014/05/28/l3dsr/
kakao의 L3DSR 구성 사례
Overview 서비스 웹서버 Load Balancing을 위한 메커니즘으로 KAKAO에서는 L3DSR 방식을 사용하고 있습니다. 멀티IDC에서 L3DSR 방식을 활용, IDC 위치나 서버의 물리적인 위치에 따른 제한없이 서비스 웹서
tech.kakao.com
Round Robin
종단 서버로 커네션을 순서대로 분산한다.
Least Connection
활성화된 커넥션이 적은 서버부터 분산한다.
Round Robin도 순서대로 커넥션을 전달하기 때문에 무슨 차이가 있나 싶겠지만,
client와 커넥션 수명은 상황에 따라 모두 다를 수 있다.
특정 서버의 커넥션이 오래 살아 남은 경우 Round Robin 방식은 특정 서버에 부하가 더 몰릴 가능성이 있다.
댓글