로드 밸런서

로드 밸런서란

로드 밸런서(load balancer)는 들어오는 트래픽을 여러 서버에 나눠 보내는 장치나 소프트웨어다. 클라이언트는 로드 밸런서의 주소 하나만 알고, 그 뒤에 서버가 몇 대 있는지, 어느 서버가 죽었는지는 모른다.

flowchart LR
  c["클라이언트"] --> lb["로드 밸런서"]
  lb --> a["서버 A<br/>healthy"]
  lb --> b["서버 B<br/>healthy"]
  lb --x cc["서버 C<br/>unhealthy → 풀에서 제외"]

서버 한 대로 버티는 수직 확장에는 한계가 있다. 로드 밸런서는 같은 서버를 여러 대 두는 수평 확장을 가능하게 하는 첫 부품이다.

하는 일

로드 밸런서는 사용자와 웹 서버 사이 한 곳에만 두지 않는다. 웹 서버와 내부 서비스, 서비스와 DB·캐시 사이처럼 계층마다 두어야 각 계층이 따로 늘고 이중화된다(웹 확장성의 구성 요소).

무엇을 보고 나누나

셋 다 요청을 열어 봐야 하므로 L7에서만 된다.

흔히 기대하는 부가 기능

세션 고정은 편하지만 특정 서버에 부하가 쏠리고, 그 서버가 죽으면 세션이 사라진다. 세션을 Redis 같은 외부 저장소에 두거나 토큰 방식으로 바꾸면 고정 없이도 어느 서버로 가도 된다(세션과 토큰 인증).

L4와 L7

L4는 연결 단위로 나누기 때문에 HTTP/2·gRPC처럼 연결 하나에 요청 여러 개를 오래 실어 나르는 프로토콜과 맞지 않는다. 무거운 클라이언트의 긴 연결 하나가 서버 한 대에 계속 붙어 있게 된다. L7은 연결 안의 요청·스트림 단위로 나누고, 재시도·서킷 브레이커·레이트 리밋까지 할 수 있다.

규모가 큰 시스템은 앞단에 L4를 두고 그 뒤에 L7(또는 API 게이트웨이)을 두는 식으로 겹쳐 쓴다. 작은 서비스는 L7 하나로 충분하다. OSI 계층 자체는 OSI 7계층에 있다.

형태

DNS 라운드 로빈

로드 밸런서 없이 한 도메인에 A 레코드를 여러 개 두고, DNS 서버가 질의마다 IP 순서를 돌려 주는 가장 단순한 분산이다. 장비가 필요 없지만 한계가 분명하다.

그래서 DNS 단계에서는 가중치 응답, 헬스 체크와 연동한 장애 조치, 지역 기반 응답(Route 53 같은 관리형 DNS의 라우팅 정책)으로 단점을 보완하고, 데이터 센터 안의 세밀한 분산은 로드 밸런서가 맡는다.

분산 알고리즘

분산 알고리즘은 서버 상태를 보지 않고 정해진 규칙대로 나누는 정적(static) 알고리즘(라운드 로빈, 고정 라운드 로빈, 가중 라운드 로빈, 해시)과, 연결 수·응답 시간 같은 실시간 상태를 보는 동적(dynamic) 알고리즘(최소 연결, 최소 응답 시간)으로 나뉜다. 정적 알고리즘은 단순하고 빠르지만 서버가 무상태여야 고르게 나뉜다.

헬스 체크와 서비스 디스커버리

동적 알고리즘 중 두 개 골라 덜 바쁜 쪽(power of two choices) 은 무작위로 서버 둘을 뽑아 부하가 적은 쪽에 보내는 방식이다. 모든 서버의 상태를 비교하지 않아도 쏠림이 크게 줄어 프록시가 여러 대일 때 특히 잘 맞는다.

L4 로드 밸런서의 구현 방식

• 패스스루의 NAT 방식은 목적지 IP를 가상 IP(VIP)에서 실제 서버 IP로 바꾸고, 응답이 로드 밸런서를 지날 때 출발지를 다시 VIP로 바꾼다. 응답까지 로드 밸런서가 감당한다.
• DSR은 같은 L2 망이면 IP는 두고 MAC 주소만 바꿔 넘기고(서버는 VIP를 루프백에 둔다), 망이 다르면 IP-in-IP·GRE 터널로 캡슐화해 넘긴다.
• 종료 방식(L7 프록시 포함)에서는 서버에 로드 밸런서 IP가 보인다. 원래 클라이언트 IP는 X-Forwarded-For 헤더나 PROXY 프로토콜로 넘기고 서버가 그것을 읽게 설정한다(프록시: 포워드 프록시와 리버스 프록시). L7의 세션 고정은 응답에 서버 식별 쿠키를 붙이고 다음 요청에서 그 쿠키로 같은 서버를 고르는 식이다.

고가용성은 두 가지로 만든다.

• 액티브·스탠바이 쌍: 두 대가 상태를 공유하고 한 대는 대기한다. 단순하지만 용량 절반이 놀고 확장이 어렵다. 소프트웨어 로드 밸런서(HAProxy 등)는 보통 keepalived의 VRRP로 하트비트를 주고받다가, 액티브가 응답하지 않으면 스탠바이가 VIP를 넘겨받는다(고가용성 이중화 구조와 장애 감지).
• ECMP + 일관 해시 클러스터: 라우터가 ECMP로 여러 로드 밸런서에 흐름을 나누고, 각 로드 밸런서는 일관 해시로 같은 흐름을 같은 서버에 보낸다. 상태 공유 없이 수평 확장되고 여러 대가 죽어도 버틴다. Google Maglev, AWS NLB가 이 계열이다.

L7 프록시는 보통 상태 없이 여러 대를 나란히 두어 확장한다. 그래서 큰 시스템은 앞단 L4 클러스터(대량 트래픽·DDoS 흡수) + 뒤의 L7 프록시의 2단 구성을 많이 쓴다.

배치 토폴로지

서비스 간 트래픽은 사이드카(서비스 메시)로, 외부 트래픽은 엣지 프록시로 받는 구성이 흔하다. 이때 프록시들은 데이터 평면이 되고, 설정·라우팅 규칙·인증서를 내려 주고 상태를 모으는 중앙 제어 평면(Istio의 istiod 등)이 따로 선다. 존 장애 시 자동 우회, 전역 정책 적용, 이상 탐지를 제어 평면이 맡는다(분산 시스템의 통신·데이터 흐름 패턴).

클러스터링과 무엇이 다른가

로드 밸런서 뒤의 서버들은 서로를 모른다. 각자 받은 요청만 처리한다. 클러스터(cluster)의 노드들은 서로를 알고 협력해 하나의 시스템처럼 동작한다(리더 선출, 상태 공유, 데이터 복제). 둘은 함께 쓰인다. 액티브-액티브 클러스터 앞에는 보통 로드 밸런서가 서고, 독립된 웹 서버 여러 대처럼 클러스터가 아닌 서버에도 로드 밸런싱은 쓸 수 있다. 클러스터의 종류와 구성은 고가용성 이중화 구조에 있다.

정리

• 로드 밸런서는 트래픽 분산, 헬스 체크로 장애 우회, 수평 확장을 맡는다.
• L4는 IP·포트만 보고 빠르게, L7은 HTTP를 열어 보고 똑똑하게 나눈다.
• 세션 고정은 최후의 수단이다. 상태를 서버 밖으로 빼면 어느 서버로 가도 된다.
• 리버스 프록시·API 게이트웨이와 겹치는 기능이 많다. 차이는 API 게이트웨이에 정리했다.

관련 노트: API 게이트웨이, 프록시: 포워드 프록시와 리버스 프록시, 웹 확장성의 구성 요소, 대규모 트래픽에서 서비스를 지키는 설계, 쿠버네티스 위 웹 서비스의 요청 경로