로드 밸런서 (Load Balancer)
"Single Entry Point, Infinite Scale-Out"
— 고가용성 이중화 아키텍처를 설계하는 모든 아키텍트들의 영원한 이상향.
서버 한 대가 감당 못 할 짐을 여러 대가 나눠 짊어지게 만드는 분산 컴퓨팅의 일등 공신이자, 교통사고 예방의 수호신. 하지만 트래픽이 몰릴 때 라우팅 설정이 삐끗하면 모든 서버가 도미노처럼 하나씩 과부하로 동반 자살한다.(...)
1. 개요
로드 밸런서는 서버에 가해지는 부하(Load)를 균등하게 분산(Balancing)해 주는 네트워크 장비 또는 소프트웨어 솔루션이다. 클라이언트가 서비스의 대표 IP로 접속을 요청하면, 로드 밸런서가 앞단에서 이를 가로채 뒤에 대기하고 있는 여러 대의 웹 서버 또는 WAS로 요청을 골고루 배분해 준다. 만약 이 친구가 없다면, 한 놈만 패는 우매한 클라이언트들 덕분에 특정 서버는 과부하로 터져 나가고 옆의 서버는 띵가띵가 노는 비극이 벌어지게 된다.(...)
2. L4 vs L7: 계층에 따른 교통 정리
로드 밸런서는 전송 계층(L4)과 응용 계층(L7) 중 어느 레이어에서 동작하느냐에 따라 성격이 확연히 갈린다.
2.1. L4 로드 밸런싱 (Layer 4)
- IP 주소와 포트 번호(Port)를 기준으로 트래픽을 분산한다. TCP/UDP 패킷 수준에서 작동하므로 데이터의 세부 내용을 열어보지 않아 속도가 엄청나게 빠르고 효율적이다.
- 하지만 요청 메시지의 본문이나 쿠키 등을 파악할 수 없어 정교한 라우팅은 불가능하다. 오직 목적지 주소와 포트만 보고 무지성으로 통과시키는 '고속도로 톨게이트' 같은 존재다.
2.2. L7 로드 밸런싱 (Layer 7)
- HTTP 요청의 URI, 헤더, 쿠키 등 실제 애플리케이션 데이터를 기반으로 트래픽을 분산한다.
- 예를 들어,
/[api](./api.md)/v1로 들어오는 요청은 백엔드 API 서버로 보내고,/images로 들어오는 요청은 이미지 전용 스토리지 서버로 전달하는 등의 지능형 라우팅이 가능하다. 패킷을 까서 해석해야 하므로 L4보다 부하가 훨씬 크지만, 현대 마이크로서비스 아키텍처에서는 사실상 필수재로 통한다.1
3. 고가용성(HA)과 세션 유지의 딜레마
단순히 요청을 골고루 뿌려주면 끝날 것 같지만, 실무에서는 두 가지 거대한 골칫거리를 해결해야 한다.
3.1. 세션 정합성과 Sticky Session
- 클라이언트가 로그인한 후 첫 번째 요청은 A 서버로, 두 번째 요청은 B 서버로 가버리면 B 서버에는 로그인 세션이 없어 사용자가 로그아웃되는 기막힌 상황이 벌어진다. 이를 해결하기 위해 특정 클라이언트는 무조건 같은 서버로만 보내주는 스티키 세션(Sticky Session) 기법을 사용하거나, 뒷단에 Redis 같은 공용 세션 저장소를 두는 아키텍처를 채택한다.
3.2. 단일 장애점(SPOF) 해결을 위한 이중화
- 백엔드 서버를 100대 늘려봤자, 정작 교통 정리를 하는 로드 밸런서 1대가 맛이 가면 서비스 전체가 사망한다. 이를 방지하기 위해 로드 밸런서 자체를 Active-Passive나 Active-Active 구조로 이중화하여, 한쪽이 급사하더라도 다른 쪽이 즉시 가발을 쓰고 대타로 나설 수 있는 환경을 구축해야만 한다.2
4. 관련 밈 및 드립
4.1. 임시방편의 최후: 무지성 서버 증설
웹 사이트가 트래픽 폭주로 버벅대면 근본적인 코드 최적화나 인프라 튜닝 대신 일단 로드 밸런서 뒤에 서버 인스턴스 개수(Replica)만 미친 듯이 늘리는 대응 방식이다. 인프라 비용 청구서를 받은 CFO의 얼굴이 사색이 되는 효과를 내지만, 정작 데이터베이스 병목이 원인인 경우에는 서버를 100대 늘려도 다 같이 데이터베이스 대기줄에 나란히 서서 사이좋게 타임아웃 에러를 내뿜게 되는 장엄한 촌극을 감상할 수 있다.(...)
5. 여담
- 헬스 체크(Health Check)의 잔혹사: 로드 밸런서는 백엔드 서버가 살아있는지 주기적으로 노크(Health Check)를 하는데, 서버가 너무 바빠서 이 노크에 대답을 1~2초 늦게 하면 로드 밸런서는 '아, 이 자식 죽었구나!' 하고 트래픽 대상에서 냉정하게 추방해 버린다. 졸지에 혼자 일하던 다른 서버가 독박을 쓰고 과부하로 동반 자살하게 된다.
- 가장 유명한 소프트웨어 밸런서: 전 세계 대다수 웹 개발자들은 전용 L7 하드웨어 장비가 없을 때 Nginx나 HAProxy를 로컬에 세워놓고 로드 밸런서 대용으로 굴린다. 설정 파일 몇 줄만 적어두면 무리 없이 수만 개의 커넥션을 분산해 주는 갓가성비를 보여준다.
- Round Robin의 함정: 로드 밸런싱의 가장 기본 알고리즘인 라운드 로빈은 순서대로 하나씩 쪼개주지만, 특정 요청이 10초 걸리는 무거운 배치 작업이고 다른 요청이 0.1초 만에 끝나는 가벼운 페이지 요청일 때, 라운드 로빈은 아무 생각 없이 무거운 요청들을 특정 서버에 연속으로 먹여 서버를 골로 보낼 수 있다.