[네트워크] 로드 밸런서
cs-study에서 스터디를 진행하고 있습니다.
대규모 트래픽에 대처할 수 있는 방법
서버가 단 하나만 존재할 때, 수천만 명의 사람들이 서버에 동시 접속하면 서버는 부하를 감당하지 못할 수 있다. 이를 해결하는 방식에는 서버의 성능을 높이는 Scale-up 방식과 여러 서버는 두는 Scale-out 방식이 있다. 대부분의 서비스는 서버의 성능을 높이는 Scale-up 작업은 한계가 있으므로 분산 처리를 위해 여러 대의 서버를 두는 Scale-out 작업을 하게 되는데, 이때 여러 서버들로 대규모의 네트워크 트래픽을 분산 처리하는 기술을 로드 밸런싱 (Load Balancing)이라고 한다.
로드 밸런싱과 로드 밸런서
로드 밸런싱은 네트워크 또는 서버에 가해지는 부하를 분산해 주는 기술을 의미한다. 로드 밸런싱 기술을 제공하는 서비스 또는 장치를 로드 밸런서 (LB, Load Balancer)라고 부른다. LB는 클라이언트와 네트워크 트래픽이 집중되는 서버들 사이에 위치하며 VIP (Virtual IP)와 함께 구성된다. 또한, 특정 서버에 부하가 집중되지 않도록 트래픽을 다양한 방법으로 분산하여 서버들의 성능을 최적인 상태로 유지할 수 있도록 한다.
VIP란?
VIP란 로드 밸런싱의 대상이 되는 여러 서버를 대표하는 가상의 IP이다. 클라이언트들은 서버의 IP로 직접 요청을 하는 것이 아니라 LB가 가지고 있는 VIP를 대상으로 요청한다. 그리고 LB는 설정된 부하 분산 방법에 따라 각 서버로 요청을 분산한다.
로드 밸런서 동작 방식 (L4 기준)
대부분의 로드 밸런서는 아래와 같은 절차로 동작한다.
- 클라이언트가 브라우저에서 'www.google.com'이라고 입력하면 PC에 설정된 DNS 서버로 DNS 쿼리를 보내고, 로컬 DNS 서버는 'www.google.com'을 관리하는 DNS 서버로부터 L4의 VIP 주소를 획득한다.
- 로컬 DNS는 획득한 VIP 주소를 클라이언트에게 전송한다.
- 클라이언트는 획득한 DNS를 기반으로 L4 VIP로 http(s) 요청을 한다.
- LB는 최적의 서비스 서버를 내부 알고리즘을 통하여 선별한 후 요청을 전송하고, 서버 작업 결과를 LB에게 전송한다.
- 전달 받은 결과를 LB를 통해 클라이언트에게 전송한다.
설정한 mode에 따라 다르게 동작할 수 있다. mode에 따라 어떻게 동작하는지 살펴 보자.
Bridge / Transparent Mode
- 요청
- 사용자가 L4의 VIP로 요청을 전송한다.
- L4에서 Real Server로 전송 시, Destination IP를 VIP에서 Real Server IP로 NAT 수행한다.
- 동일한 네트워크 대역이므로 Destination MAC 주소만 변경된다.
- 응답
- Real Server에서 서비스 응답 시, Destination IP가 다른 대역의 IP이므로 Gateway (Router)로 전송한다.
- Real Server에서 L4를 거치면서 Source IP를 VIP로 NAT 수행한다.
- 동일한 네트워크 대역이므로 MAC 주소는 변경되지 않는다.
Router Mode
- 요청
- 사용자가 L4의 VIP로 요청을 전송한다.
- L4에서 Real Server로 전송 시, Destination IP를 VIP에서 Real Server IP로 NAT 수행한다.
- 네트워크 대역이 변경되었으므로, Source와 Destination MAC 주소 모두 변경된다.
- 응답
- Real Server에서 서비스 응답 시, Destination IP가 다른 대역의 IP이므로 Gateway (L4)로 전송한다.
- L4에서 Source IP를 VIP로 NAT 수행한다.
L4를 중심으로 상/하단의 IP 대역이 서로 다르게 구성되며, L4는 Server 대역 네트워크의 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 수행한다.
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)
로드 밸런서는 서버들에 대한 주기적인 상태 확인을 통해 서버들의 장애 여부를 판단할 수 있다. 이로 인해, 서버에 이상이 생기면 정상적으로 동작하는 서버로 트래픽을 보내 주는 Fail-Over가 가능하며, 또한 TCP/UDP 분석이 가능하기 때문에 방화벽의 역할도 수행할 수 있다.
- L3 체크: ICMP를 이용해 서버의 IP 주소가 통신 가능한 상태인지 확인한다.
- L4 체크: TCP의 3-way handshaking을 통해 각 서버의 포트 상태를 확인한다.
- L7 체크: 애플리케이션 계층에서 체크하는 방법으로 실제 웹 페이지에 통신을 시도해 이상 유무를 파악한다.
Tunneling
터널링은 인터넷 상에서 눈에 보이지 않는 통로를 만들어 통신할 수 있게 하는 개념이다. 데이터를 캡슐화해서 연결된 상호 간에만 캡슐화된 패킷을 구별해 캡슐화를 해제할 수 있다.
로드 밸런서의 VIP 주소로 향하는 요구 패킷이 로드 밸런싱 서버로 전달되면 로드 밸런싱 서버에서 패킷의 목적지 주소와 포트를 검사하여 가상 서버 정책과 일치할 경우, 스케줄링에 따라 실제 작업 서버로 전달하게 된다. 이때 패킷을 일반적인 스트림 방식으로 전달하는 것이 아닌 캡슐 형식으로 감싸서 전달하게 된다. 이렇게 전달되면 작업 서버에서는 감싸진 패킷을 다시 풀고 요청을 처리한다.
NAT (Network Address Translation)
IP 주소를 변환해 주는 기능이다. 예를 들어, 내부 네트워크에서 사용하던 사설 IP 주소를 로드 밸런서 외부의 공인 IP 주소로 변경해 주며, 반대 과정도 가능하다. 이렇게 하면 부족한 공인 IP 주소를 효율적으로 사용할 수 있지만, 로드 밸런싱 관점에서는 여러 개의 호스트가 하나의 공인 IP 주소 (VIP)를 통해 접속하는 것이 주 목적이다.
- SNAT (Source Network Address Translation)
- 내부에서 외부로 트래픽이 나가는 경우, 내부 사설 IP 주소를 외부 공인 IP 주소로 변환하는 방식이다. 집에서 사용하는 공유기가 대표적인 예시이다.
- DNAT (Destination Network Address Translation)
- 외부에서 내부로 트래픽이 들어오는 경우, 외부 공인 IP 주소를 내부의 사설 IP 주소로 변환하는 방식이다.
DSR (Direct Server Routing)
서버에서 클라이언트로 되돌아가는 경우, 목적지를 클라이언트로 설정한 다음 네트워크 장비나 로드 밸런서를 거치지 않고 바로 클라이언트로 찾아가는 방식이다. 이 경우, 로드 밸런서의 부하를 줄여줄 수 있는 장점이 있다.
로드 밸런서의 종류와 로드 밸런싱의 방법
로드 밸런서는 OSI 7 계층을 기준으로 어떻게 부하를 분산하는지에 따라 종류가 나뉜다. 2 계층을 기준으로 부하를 분산한다면 L2, 3 계층을 기준으로 분산한다면 L3인 방식이다. 상위 계층으로 갈수록 섬세한 부하 분산이 가능하지만, 가격과 성능에 드는 비용이 증가한다.
부하 분산에는 L4 로드 밸런서와 L7 로드 밸런서가 가장 많이 활용된다. 그 이유는 L4부터 포트 정보를 바탕으로 분산하는 것이 가능하기 때문이다. 한 대의 서버에 각각 다른 포트 번호를 부여하여 다수의 서버 프로그램을 운영하는 경우라면 최소 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 로드 밸런서 vs L7 로드 밸런서
로드 밸런서 주요 성능 지표
- 초당 연결 수 (Connections per second)
- 최대 처리 가능한 초당 TCP 세션 개수를 의미한다.
- 동시 연결 수 (Concurrent connections)
- 동시에 유지할 수 있는 최대 세션 개수를 의미한다.
- 처리 용량 (Throughput)
- UDP 프로토콜에 대한 로드 밸런싱 성능 지표
- FWLB (Firewall Load Balancing)에서 중요
- 단위는 bps (bit per second) 또는 pps (packet per second) 사용
로드 밸런서 장애 대비
갑작스러운 장애에 대비해 로드 밸런서 서버는 아래와 같이 이중화를 기본으로 구성한다.
로드 밸런서에 장애가 발생했을 시의 시나리오는 다음과 같다.
- 이중화된 로드 밸런서들은 서로 상태 확인을 한다.
- 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
예상 면접 질문 및 답변
대규모 트래픽에 대처할 수 있는 방법
서버의 성능을 높이는 Scale-up과 분산 처리를 위해 여러 대의 서버를 두는 Scale-out이 있다. Scale-up 방식의 경우 한계가 있으므로 주로 Scale-out 방식을 사용한다. Scale-out 방식에서 분산 처리를 하기 위해 로드 밸런싱 기술을 사용한다.
로드 밸런서의 기본 기능은?
서버의 이상 유무를 파악하는 상태 확인(Health Check), 패킷을 캡슐화해서 연결된 상호 간에만 패킷을 구별할 수 있게 해주는 터널링(Tunneling), IP 주소를 변환해주는 NAT 기능이 있다.
로드 밸런서의 종류?
로드 밸런서는 OSI 7계층을 기준으로 어떻게 부하를 분산하는 지에 따라 종류가 나뉜다. 그 중 L4 로드 밸런서와 L7 로드 밸런서가 가장 많이 활용된다.
L4 로드 밸런서에 대해 설명
L4 로드 밸런서는 L4 계층에서 동작하며, 네트워크 계층이나 트랜스포트 계층의 정보를 바탕으로 트래픽을 분산한다. IP 주소, 포트 번호, MAC 주소, 전송 프로토콜에 따라 트래픽을 분산 처리하는 것이 가능하다.
L7 로드 밸런서에 대해 설명
L7 로드 밸런서는 L4 로드밸런서의 기능을 포함하며 애플리케이션 계층의 정보를 바탕으로도 분산 처리가 가능하다. HTTP 헤더, 쿠키 등과 같은 사용자의 요청을 기반으로 특정 서버에 트래픽을 분산할 수 있다.
로드 밸런싱에 사용되는 알고리즘에 대해 설명
L4 로드 밸런서에는 라운드 로빈, 가중치 할당 방식, 최소 연결, 응답 시간, 해시 가반, 대역폭 기반으로 특정 서버에 요청을 분배할 수 있다. L7 로드 밸런서의 경우 L4 로드 밸런서에 사용되는 방식 뿐만 아니라 URL 스위칭 방식, 컨텍스트 스위치 방식, 쿠키 지속성 방식이 있다.
로드 밸런서가 장애를 대비하는 방법
로드 밸런서는 갑작스러운 장애에 대비해 이중화를 기본으로 구성한다. 이중화된 로드 밸런서들은 서로의 상태를 확인하며 장애가 발생하면 정상적으로 작동하는 로드 밸런서로 교체된다.
'스터디 > CS 스터디' 카테고리의 다른 글
[데이터베이스] NoSQL - What are Data Models (0) | 2021.12.17 |
---|---|
[데이터베이스] 인덱스란? (실습 포함) (0) | 2021.12.13 |
[운영체제] Blocking, Non-blocking & Synchronous, Asynchronous (0) | 2021.12.10 |
[네트워크] 라우팅 (0) | 2021.12.07 |
[운영체제] 페이징 교체 알고리즘 (0) | 2021.12.04 |
댓글