쉬운 설명
사용자가 한 명일 때는 서버 한 대로 충분합니다. 동시에 수만 명이 들어오면 한 대로는 어림없습니다. 그래서 보통 서버를 여러 대로 두고, 그 앞에 로드 밸런서를 세웁니다. 사용자의 요청은 모두 로드 밸런서에 도달하고, 로드 밸런서가 여러 서버에 차례로 또는 부하에 맞춰 분산합니다.
분산 방식은 몇 가지가 있습니다. ① 라운드 로빈(차례대로), ② 최소 연결(가장 한가한 서버로), ③ 가중치(서버 성능에 비례), ④ 해시 기반(같은 사용자는 항상 같은 서버로 — 세션 유지). 상황에 따라 어떤 방식이 맞는지가 다르고, 보통 도구가 여러 옵션을 제공합니다.
핵심 부가 기능은 헬스 체크입니다. 어떤 서버가 응답을 못 하면 로드 밸런서가 그 서버를 자동으로 풀에서 빼고, 회복되면 다시 넣습니다. 사용자는 그 와중에도 끊김 없이 서비스를 씁니다. 또 SSL 종료(HTTPS를 LB에서 풀고 내부는 HTTP), 압축, 캐싱, 속도 제한 같은 부가 기능까지 함께 제공하는 경우가 많습니다.
종류는 크게 둘. ① L4 로드 밸런서(IP·포트 단위로 분산 — 빠름·단순), ② L7 로드 밸런서(URL·헤더 등 콘텐츠 단위로 분산 — 똑똑함·유연). 한 시스템 안에 둘이 함께 있는 경우도 많습니다. 클라우드의 ALB·NLB·GCLB, 오픈소스의 NGINX·HAProxy·Envoy, K8s의 Ingress가 모두 로드 밸런서 역할을 합니다.
주의할 점: 로드 밸런서가 한 대면 그 자체가 단일 장애 지점입니다. 그래서 실서비스에서는 LB도 여러 대 두고 DNS·Anycast로 분산합니다. 또 세션 유지를 잘못 설정하면 한 사용자의 요청이 매번 다른 서버로 가서 로그인이 풀리는 일이 생깁니다. 이런 작은 디테일이 운영의 큰 차이를 만듭니다.
비유로 보면
로드 밸런서는 슈퍼마켓의 입구에서 손님을 빈 계산대로 안내하는 직원과 같습니다. 한 계산대에 줄이 길어지지 않게 골고루 보내고, 어떤 계산대가 잠시 닫히면 다른 곳으로 돌려보냅니다. 손님은 어느 계산대인지 신경 쓰지 않고 매번 매끄럽게 결제를 끝냅니다.
어디에서 만나나
모든 일정 규모 이상 웹 서비스의 앞단, 마이크로서비스 사이의 내부 통신, API 게이트웨이의 뒤, 데이터베이스 읽기 분산(read replica), 글로벌 트래픽의 지역별 분산(GSLB·Anycast). 사실상 모든 현대 인프라의 기본 구성요소입니다.
작은 예시
쇼핑 사이트의 결제 트래픽이 평소의 100배가 되는 블랙프라이데이를 떠올려 보세요. 한 대 서버로는 즉시 멈춥니다. 앞단의 로드 밸런서가 동일한 앱이 도는 100대의 서버에 요청을 분산해야 비로소 사이트가 안 죽고 견딥니다.
자주 하는 오해
한 줄 정리
로드 밸런서의 가치는 '한 대가 죽어도 사용자가 모르게 한다'에 있습니다. 사용자가 안 느끼게 만드는 모든 일은 거의 항상 LB가 뒤에 있습니다.