[네트워크] Load Balancer
대규모 트래픽에 대처할 수 있는 방법
서버가 단 하나만 존재할 때, 수천만 명의 사람들이 서버에 동시 접속하면 어떻게 될까? 하나의 서버는 부하를 감당하지 못할 수도 있을 것이다. 이를 해결하는 방식에는 서버의 성능을 높이는 Scale-up 방식과 여러 서버를 두는 Scale-out 방식이 있다.
대부분의 서비스는 서버의 성능을 높이는 Scale-up 작업은 한계가 있으므로 분산 처리를 위해 여러 대의 서버를 두는 Scale-out 작업을 하게 되는데, 이때 여러 서버들로 대규모의 네트워크 트래픽을 분산 처리하는 기술을 로드 밸런싱(Load Balancing)이라고 한다.
로드 밸런싱과 로드 밸런서
로드 밸런싱은 네트워크 또는 서버에 가해지는 부하를 분산해주는 기술을 의미한다. 로드 밸런싱 기술을 제공하는 서비스 또는 장치를 로드 밸런서(LB, Load Balancer)라고 부른다. LB는 클라이언트와 네트워크 트래픽이 집중되는 서버들 사이에 위치하며 VIP(Virtual IP)와 함께 구성된다. 또한, 특정 서버에 부하가 집중되지 않도록 트래픽을 다양한 방법으로 분산하여 서버들의 성능을 최적인 상태로 유지할 수 있도록 한다.
VIP란?
VIP란 로드 밸런싱의 대상이 되는 여러 서버를 대표하는 가상의 아이피다. 클라이언트들은 서버의 IP로 직접 요청을 하는 것이 아니라 LB가 가지고 있는 VIP를 대상으로 요청한다. 그리고 LB는 설정된 부하 분산 방법에 따라 각 서버로 요청을 분산시킨다.
로드밸런서 동작 방식 (L4 기준)
대부분의 로드 밸런서는 아래와 같은 절차로 동작한다.
- 클라이언트가 브라우저에서 www.google.com이라고 입력하면 PC에 설정된 DNS 서버로 DNS Query를 보내고, Local DNS 서버는 www.google.com을 관리하는 DNS 서버부터 L4의 VIP 주소를 획득한다.
- Local DNS는 획득한 VIP 주소를 클라이언트에게 전송한다.
- 클라이언트는 획득한 DNS를 기반으로 L4 VIP로 http(s) 요청을 한다.
- LB는 최적의 서비스 서버를 내부 알고리즘을 통하여 선별한 후 요청을 전송하고, 서버 작업 결과를 LB에게 전송한다.
- 전달받은 결과를 LB를 통해 클라이언트에게 전송한다.
Bridge/Transparent Mode
- 요청
- 사용자가 L4의 VIP로 요청을 전송한다.
- L4에서 Real Server로 전송 시, Destination IP를 VIP에서 Real Server IP로 NAT 한다.
- 동일한 Network 대역이므로, Destination MAC 주소만 변경된다.
- 응답
- Real Server에서 서비스 응답 시, Destination IP가 다른 대역의 IP이므로 Gateway(Router)로 전송한다.
- Real Server에서 L4를 거치면서 Source IP를 VIP로 NAT을 수행한다.
- 동일한 Network 대역이므로 MAC 주소는 변경되지 않는다.
Router Mode
- 요청
- 사용자가 L4의 VIP로 요청을 전송한다.
- L4에서 Real Server로 전송 시, Destination IP를 VIP에서 Real Server IP로 NAT 한다.
- Network 대역이 변경되었으므로, Source와 Destination MAC 주소 모두 변경된다.
- 응답
- Real Server에서 서비스 응답 시, Destination IP가 다른 대역의 IP이므로 Gateway(L4)로 전송한다.
- L4에서 Source IP를 VIP로 NAT을 수행한다.
L4를 중심으로 상/하단의 IP대역이 서로 다르게 구성되며, L4는 Server 대역 Network의 Gateway 역할을 한다.
One Arm Mode
- 요청
- 사용자가 L4의 VIP로 요청을 전송한다.
- L4에서 Real Server로 전송 시, Destination IP를 VIP에서 Real Server IP로 NAT 한다.
- Destination으로 전송을 위해서 Destination MAC 주소도 변경된다.
- Real Server에서 L4로의 전송을 위해서 Source IP도 L4의 IP Pool의 IP로 NAT 한다.
- 응답
- Real Server에 서비스 응답 시, Destination은 L4에서 NAT된 IP Pool의 IP로 보낸다.
- L4에서 클라이언트로 응답 시, Source IP를 Real Server의 IP에서 VIP로 NAT 한다.
- Destination IP를 IP Pool의 IP에서 클라이언트 IP로 NAT 한다.
One-Arm Mode는 클라이언트의 IP가 Server에 전달되지 않기 때문에 Server가 실제 클라이언트의 IP를 이용해야 할 경우 부적합한 기법이다. 일반적으로 권고되지 않는 구성 방법이다.
DSR (Direct Server Return) Mode
방금 위에서 소개한 기법들은 모든 Inbound, Outbound 패킷이 LB를 거치기 때문에 LB에 많은 부하가 발생한다. 대부분의 서비스들의 트래픽은 보통 Inbound 보다 Outbound Packet의 양이 많다. DSR은 Outbound 패킷이 LB를 거치지 않고, 클라이언트에 바로 전달하게 만들어 LB의 부하를 줄일 수 있다.
로드밸런서 기본 기능
상태 확인 (Health Check)
로드 밸런서는 서버들에 대한 주기적인 상태 확인(Health Check)을 통해 서버들의 장애 여부를 판단할 수 있다. 이로 인해, 서버에 이상이 생기면 정상적으로 동작하는 서버로 트래픽을 보내주는 Fail-over가 가능하며, 또한 TCP/UDP 분석이 가능하기 때문에 방화벽(Firewall)의 역할도 수행할 수 있다.
- L3 체크 : ICMP를 이용해 서버의 IP 주소가 통신 가능한 상태인지 확인한다.
- L4 체크 : TCP의 3-way handshaking을 통해 각 서버의 포트 상태를 확인한다.
- L7 체크 : 애플리케이션 계층에서 체크하는 방법으로 실제 웹 페이지에 통신을 시도해 이상 유무를 파악한다.
Tunneling
터널링(Tunneling)은 인터넷상에서 눈에 보이지 않는 통로를 만들어 통신할 수 있게 하는 개념이다. 데이터를 캡슐화해서 연결된 상호 간에만 캡슐화된 패킷을 구별해 캡슐화를 해제할 수 있다.
로드 밸런서의 VIP 주소로 향하는 요구 패킷이 로드 밸런싱 서버로 전달되면 로드 밸런싱 서버에서 패킷의 목적지 주소와 포트를 검사하여 가상 서버 정책과 일치할 경우, 스케줄링에 따라 실제 작업 서버로 전달하게 된다. 이때 패킷을 일반적인 스트림(Stream) 방식으로 전달하는 것이 아닌 캡슐 형식으로 싸서 전달하게 된다. 이렇게 전달되면 작업 서버에서는 감싸진 패킷을 다시 풀고 요청을 처리한다.
NAT (Network Address Translation)
IP 주소를 변환해주는 기능이다. 예를 들어, 내부 네트워크에서 사용하던 사설 IP 주소를 로드 밸런서 외부의 공인 IP 주소로 변경해준다(반대로도 가능). 이렇게 하면 부족한 공인 IP 주소를 효율적으로 사용할 수 있지만, 로드 밸런싱 관점에서는 여러 개의 호스트가 하나의 공인 IP 주소(VIP)를 통해 접속하는 것이 주목적이다.
- SNAT (Source Network Address Translation)
- 내부에서 외부로 트래픽이 나가는 경우, 내부 사설 IP 주소를 외부 공인 IP 주소로 변환하는 방식이다. 집에서 사용하는 공유기가 대표적인 예이다.
- DNAT (Destionation Network Address Translation)
- 외부에서 내부로 트래픽이 들어오는 경우, 외부 공인 IP 주소를 내부의 사설 IP 주소로 변환하는 방식이다.
DSR (Direct Server Routing)
서버에서 클라이언트로 되돌아가는 경우, 목적지를 클라이언트로 설정한 다음 네트워크 장비나 로드밸런서를 거치지 않고 바로 클라이언트로 찾아가는 방식이다. 이 경우, 로드밸런서의 부하를 줄여줄 수 있는 장점이 있다.
로드밸런서 종류와 방법
로드밸런서는 OSI 7 계층을 기준으로 어떻게 부하를 분산하는지에 따라 종류가 나뉜다. 2 계층을 기준으로 부하를 분산한다면 L2, 3 계층을 기준으로 분산한다면 L3인 방식이다. 상위 계층으로 갈수록 섬세한 부하 분산이 가능하지만, 가격과 성능에 드는 비용이 증가한다.
부하 분산에는 L4 로드밸런서과 L7 로드밸런서가 가장 많이 활용된다. 그 이유는 L4부터 포트(Port) 정보를 바탕으로 분산하는 것이 가능하기 때문이다. 한 대의 서버에 각각 다른 포트 번호를 부여하여 다수의 서버 프로그램을 운영하는 경우라면 최소 L4 이상을 사용해야 한다.
L4 로드밸런서
L4 로드밸런서은 L4 계층에서 동작하며, 네트워크 계층(IP, IPX)이나 트랜스포트 계층(TCP, UDP)의 정보를 바탕으로 로드를 분산한다. 즉, IP 주소나 포트 번호, MAC 주소, 전송 프로토콜 등에 따라 트래픽을 나누고 분산 처리하는 것이 가능하다. 이런 이유로 L4 로드 밸런서를 CLB(Connection Load Balancer) 혹은 SLB(Session Load Balancer)라고 부르기도 한다.
L4 로드밸런서에는 다음과 같은 로드밸런싱 방법들이 있다.
라운드 로빈(Round Robin)
요청이 들어오는 대로 서버마다 균등하게 요청을 분배한다. 단순히 순서에 따라 세션을 할당하므로 경우에 따라 경로별로 같은 처리량이 보장이 되지 않는다.
가중치 및 비율 할당 방식 (Weighted Round Robin Scheduling)
라운드 로빈 방식으로 분배하지만, 서버의 가중치에 따라 요청을 더 분배하기도, 덜 분배하기도 한다. 서버 가중치는 사용자가 지정할 수 있고 동적으로 조정되기도 한다. 특정 서버의 성능이 월등히 뛰어나다면 해당 서버에게 높은 가중치를 설정한다.
최소 연결 (Least Connection)
가장 적은 세션을 가진 서버로 트래픽을 보내는 방식이다. 가장 많이 사용되는 방식이라고 한다.
응답 시간 (Fastest Response Time)
가장 빠른 응답 시간을 보내는 서버로 트래픽을 보내주는 방식이다. 각 서버들의 가용 가능한 리소스와 성능. 그리고 처리 중인 데이터 등에 다를 경우 적합한 방식이다.
해시 기반 (Source Hash Scheduling)
사용자의 IP를 해싱한 후 그 결과에 따라 서버로 요청을 분배하기 때문에, 특정 클라이언트는 특정 서버로만 할당시키는 방식이다.
대역폭 (Bandwidth) 기반
서버들과의 대역폭을 고려하여 트래픽을 분산하는 방식이다.
L7 로드밸런서
L7 로드밸런서는 L4 로드밸런서의 기능을 포함하는 것뿐만 아니라 애플리케이션 계층(HTTP, SMTP, FTP)의 정보를 바탕으로도 분산 처리가 가능하다. 쉽게 말해 HTTP 헤더, 쿠키 등과 같은 사용자의 요청을 기준으로 특정 서버에 트래픽을 분산하는 것이 가능하다.
아래 그림과 같이 URL에 따라 부하를 분산시키거나, HTTP 헤더의 쿠키값에 따라 부하를 분산하는 등 클라이언트의 요청을 보다 세분화해 서버에 전달할 수 있다. 또한, L7 로드 밸런서의 경우 특정한 패턴을 지닌 바이러스를 감지해 네트워크를 보호할 수 있으며, DoS/DDoS와 같은 비정상적인 트래픽을 필터링할 수 있어 네트워크 보안 분야에서도 활용되고 있다.
L7 로드밸런서에는 다음과 같은 방법들이 있다.
URL 스위칭 방식 (URL Switching)
특정 하위 URL들은 특정 서버로 처리하는 방식이다. 예를 들어, ‘.../images’ 또는 ‘.../video’와 같은 URL은 서버가 아닌 별도의 스토리지에 있는 객체 데이터로 바로 연결되도록 구성할 수 있다.
컨텍스트 스위칭 방식 (Context Switching)
클라이언트가 요청한 특정 리소스에 따라 특정 서버로 연결할 수 있다. 예를 들어, 이미지 파일에 대해서는 확장자를 참조해 별도로 구성된 이미지 파일이 있는 서버 또는 스토리지로 직접 연결해줄 수 있다.
쿠키 지속성 (Persistence with Cookies)
쿠키 정보를 바탕으로 클라이언트가 연결했었던 서버에 계속 할당해주는 방식이다.
L4 로드밸런서와 L7 로드밸런서 차이점
로드밸런서 주요 성능 지표
L4/L7 로드밸런서의 성능을 결정하는 주요한 지표들은 다음과 같다.
- 초당 연결수 (Connections per second)
- 최대 처리 가능한 초당 TCP 세션 개수를 의미한다.
- 동시 연결수 (Concurrent connections)
- 동시에 유지할 수 있는 최대 세션 개수를 의미한다.
- 처리용량 (Throughput)
- UDP 프로토콜에 대한 로드밸런싱 성능 지표
- FWLB(Firwall Laod Balancing)에서 중요
- 단위는 bps(bit per second) 또는 pps(packet per second)를 사용
로드밸런서 장애 대비
갑작스러운 장애에 대비해 로드밸런서 서버는 아래와 같이 이중화를 기본으로 구성한다.
- 이중화된 로드밸런서들은 서로 상태 확인(Health Check)을 한다.
- Master 서버에 Fail 되면 Standby 서버가 자동으로 Master 서버의 역할을 한다.
- Standby 서버는 평상시에는 대기상태로만 있다가 Master 서버가 Fail 되었을 경우에만 작동을 한다.
- 이 구성을 Fail Over라 한다.
참고
- stevenjlee 블로그
- pakss328 블로그
- wiki hash
- 가비아 기술 블로그
- https://deveric.tistory.com/91
- https://dev.classmethod.jp/articles/load-balancing-types-and-algorithm/
- https://goodgid.github.io/Load-Balancing-And-Clustering/https://icarus8050.tistory.com/101
예상 면접 질문 및 답변
링크 참고
'컴퓨터 공학 > 네트워크' 카테고리의 다른 글
[네트워크] DNS (0) | 2021.12.01 |
---|---|
[네트워크] HTTP & HTTPS (0) | 2021.11.26 |
[네트워크] TCP/IP 흐름제어 & 혼잡제어 (0) | 2021.11.17 |
[네트워크] TCP 3 way handshake & 4 way handshake (0) | 2021.11.10 |
댓글