안녕하세요. 자바파커입니다.

서버가 세 대라서 요청도 세 대에 똑같이 나눴습니다. 그런데 잠시 뒤 1번 서버의 연결은 8개, 2번과 3번 서버는 각각 1개가 됐습니다.

요청 개수는 공평했는데 왜 부하는 공평하지 않을까요?

로드 밸런싱의 목표는 요청 개수를 똑같이 만드는 것이 아니라, 사용 가능한 서버가 감당할 수 있도록 트래픽을 분배하는 것입니다.

요청이 서버 사이를 이동하고 알고리즘을 바꾸자 활성 연결 수가 달라지는 과정은 55초 영상으로도 준비했습니다. 공개되면 이 자리에 연결합니다.

로드 밸런서가 하는 일

클라이언트가 서버 주소를 직접 고르면 서버 추가·제거와 장애 대응이 어렵습니다. 로드 밸런서는 하나의 진입점 뒤에 여러 서버를 숨기고, 새 요청을 어느 서버로 보낼지 결정합니다.

Client → Load Balancer → Server A
                       → Server B
                       → Server C

좋은 분배에는 세 가지 정보가 필요합니다.

• 어떤 서버가 살아 있는가
• 각 서버가 현재 얼마나 바쁜가
• 같은 사용자를 같은 서버로 보내야 하는가

Round Robin — 차례대로 하나씩

Round Robin은 가장 단순합니다.

요청 1 → A
요청 2 → B
요청 3 → C
요청 4 → A

모든 서버의 성능과 요청 처리시간이 비슷하면 충분히 잘 작동합니다. 설정이 없을 때 NGINX가 사용하는 기본 방식도 Round Robin입니다.

문제는 요청의 무게가 다를 때입니다. 50ms 요청과 8초 요청을 모두 한 건으로 세면, 요청 수는 같아도 점유 시간은 크게 달라집니다.

Least Connections — 지금 가장 한가한 서버로

Least Connections는 새 요청이 들어오는 순간 활성 연결 수가 가장 적은 서버를 고릅니다.

긴 요청이 특정 서버에 남아 있으면 이후 요청은 다른 서버로 흐릅니다. 다만 연결 하나의 실제 CPU·메모리 비용까지 아는 것은 아닙니다. 연결 수는 부하를 추정하는 신호일 뿐입니다.

Weighted — 서버 성능이 다를 때

서버 A가 B보다 두 배 강하다면 같은 비율로 보내는 것이 오히려 불공평합니다. 이때 가중치를 둡니다.

upstream backend {
  server app-a:8080 weight=2;
  server app-b:8080 weight=1;
}

대략 A에 두 번, B에 한 번꼴로 분배됩니다. 실제 운영에서는 가중치와 헬스 체크를 함께 사용해야 합니다.

IP Hash — 같은 사용자를 같은 서버로

IP Hash는 클라이언트 IP를 해시해 서버를 고릅니다. 서버 메모리에 세션을 저장한 레거시 애플리케이션에서 세션 고정에 쓸 수 있습니다.

하지만 모바일 통신망·NAT·프록시 환경에서는 여러 사용자가 같은 IP로 보일 수 있습니다. 서버가 추가되거나 빠질 때 매핑도 크게 바뀝니다. 가능하면 세션을 Redis 같은 외부 저장소로 분리하고 서버를 무상태로 만드는 편이 확장에 유리합니다.

헬스 체크가 알고리즘보다 먼저다

아무리 좋은 알고리즘도 죽은 서버를 후보에 남겨 두면 실패합니다.

• 연결 가능 여부만 보는 L4 체크
• HTTP 상태와 응답 본문까지 보는 L7 체크
• 연속 실패·성공 횟수를 둔 완충
• 점진적으로 트래픽을 복구하는 slow start

장애 한 번에 서버를 즉시 빼고 넣으면 상태가 출렁일 수 있습니다. 연속 실패 임계값과 복귀 조건을 함께 설계해야 합니다.

어떤 방식을 고를까

선택 후에는 서버별 활성 연결·응답시간·오류율·거부 요청을 같이 봐야 합니다. 분배 개수만 같다고 균형이 맞은 것은 아닙니다.

정리

로드 밸런서는 요청을 똑같이 세는 장치가 아닙니다.

1. Round Robin은 순서가 단순하지만 요청 무게를 모릅니다.
2. Least Connections는 현재 점유 상태를 더 잘 반영합니다.
3. 서버 성능이 다르면 가중치가 필요합니다.
4. 헬스 체크가 먼저 잘못되면 어떤 알고리즘도 실패합니다.

공평하게 나눈 요청 수와 공평한 부하는 다릅니다.

자주 묻는 질문 (FAQ)

L4와 L7 로드 밸런싱은 무엇이 다른가요?

L4는 IP와 포트 같은 전송 계층 정보를 기준으로 연결을 분배합니다. L7은 HTTP 경로, 헤더, 쿠키처럼 애플리케이션 계층의 정보를 보고 /api와 /images를 서로 다른 서버군으로 보낼 수 있습니다. 단순하고 빠른 분배에는 L4, 콘텐츠 기반 라우팅이 필요하면 L7이 적합합니다.

Round Robin만으로도 충분한 경우가 있나요?

서버 사양이 같고 요청별 처리 시간이 비슷하며 연결이 짧다면 충분합니다. 반대로 스트리밍, 파일 변환, AI 추론처럼 처리 시간 편차가 크면 요청 개수보다 현재 연결 수나 응답 시간을 반영하는 편이 낫습니다.

로드 밸런서 자체가 단일 장애점이 되지 않나요?

한 대만 두면 단일 장애점이 됩니다. 운영 환경에서는 로드 밸런서를 다중화하고 헬스 체크, 장애 조치, 관리형 서비스의 다중 가용 영역 구성을 함께 사용합니다.

참고 자료

• NGINX — HTTP Load Balancing
• NGINX — Upstream Module