사용자가 몰리는 서비스는 서버 한 대로 감당이 안 됩니다. 로드밸런서(Load Balancer)는 밀려드는 요청을 여러 서버에 고르게 나눠주는 장비입니다. 서비스의 확장성과 무중단 운영의 핵심 장비입니다.
부하 분산과 헬스체크
- 부하 분산 방식 — 순서대로(라운드로빈), 접속 수가 적은 곳(최소 연결), 가중치 부여 등.
- 헬스체크 — 각 서버의 상태를 계속 확인해, 고장난 서버는 자동으로 제외합니다. 한 대가 죽어도 나머지로 넘겨 무중단 운영이 됩니다.
- 세션 유지(sticky) — 같은 사용자를 같은 서버로 계속 보내야 할 때(로그인 상태 등) 고정합니다.
L4 vs L7
- L4 — IP·포트만 보고 빠르게 분산. 단순·고속.
- L7 — URL·쿠키·헤더 내용까지 보고 정교하게 분산(예:
/img는 이미지 서버로). SSL 종단·캐시도 가능.
프록시
프록시(Proxy)는 요청을 대신 받아 중계하는 장비입니다.
- 포워드 프록시 — 내부 사용자의 인터넷 요청을 대신 처리(캐시·필터·로깅).
- 리버스 프록시 — 외부 요청을 받아 내부 서버로 전달(부하분산·SSL 종단·보안 은닉).
예제 1) "서버 3대로 운영 중인데, 한 대만 점검하려면 서비스를 멈춰야 하나?"
해설) 아닙니다. 로드밸런서의 헬스체크와 수동 드레인(drain) 기능으로 점검할 서버를 빼면, 로드밸런서가 자동으로 나머지 2대로만 보냅니다. 사용자는 끊김을 못 느낍니다. 점검이 끝나면 다시 넣습니다. 무중단 유지보수(롤링 업데이트)의 핵심입니다.
예제 2) "로드밸런서의 L4와 L7 중 뭘 써야 하나?"
해설) 단순히 트래픽만 고루 나누면 L4(빠름). URL 경로별로 다른 서버에 보내거나, 쿠키로 같은 사용자를 같은 서버에 고정하거나, SSL을 여기서 풀어야 하면 L7(정교함)을 씁니다. 대부분 웹 서비스는 L7을 선호합니다.
예제 3) "리버스 프록시와 로드밸런서는 같은 건가?"
해설) 겹치는 부분이 많습니다. 리버스 프록시(예: Nginx)가 로드밸런싱도 하고, 로드밸런서가 프록시 역할도 합니다. 실무에선 리버스 프록시 = 요청 대행+캐시+SSL 종단, 로드밸런서 = 다수 서버 분산에 무게를 둔다고 보면 됩니다.
예제 4) "로그인한 사용자가 자꾸 로그아웃된다(서버 3대 운영)."
해설) 요청이 매번 다른 서버로 가서 세션이 안 맞는 경우입니다. ① 로드밸런서에 세션 고정(sticky session)을 켜거나, ② 세션을 서버가 아닌 공유 저장소(Redis 등)에 두어 어느 서버로 가도 되게 설계합니다. 후자가 더 확장성 있는 방식입니다.
예제 5) "로드밸런서 자체가 고장 나면 전체가 멈추지 않나?"
해설) 맞습니다. 그래서 로드밸런서도 이중화(Active-Standby 또는 Active-Active)합니다. 한 대가 죽으면 다른 대가 즉시 이어받습니다(VRRP 등). '분산 장비가 단일 장애점이 되지 않게' 이중화하는 것이 원칙입니다.
정리
- 로드밸런서는 요청을 여러 서버에 분산, 헬스체크로 무중단·롤링 업데이트.
- 단순 분산은 L4, 내용 기반 정교한 분산·SSL 종단은 L7.
- 세션 문제는 sticky 또는 공유 세션 저장소로 해결.
- 프록시는 요청을 대신 중계(캐시·보안·SSL), 로드밸런서 자신도 이중화.
댓글 0
댓글은 운영자만 작성할 수 있어요.