분산 규칙 비교
아래 표는 위키백과 로드 밸런싱 문서와 일반적인 설명에 나오는 개념을 정리한 것입니다. 제품마다 이름과 세부 동작은 다를 수 있습니다.
| 규칙 | 기준 | 잘 맞는 상황 | 약점 |
|---|---|---|---|
| 라운드로빈 | 순번 | 서버 사양과 요청 비용이 비슷할 때 | 현재 부하를 보지 않음 |
| 가중 라운드로빈 | 순번 + 서버별 가중치 | 성능이 다른 서버가 섞여 있을 때 | 가중치를 사람이 정해야 함 |
| 최소 연결 | 현재 활성 연결 수 | 요청마다 처리 시간 차이가 클 때 | 연결 수가 곧 부하는 아님 |
| 해시(출발지 기준 등) | 주소·포트 등으로 계산한 값 | 같은 클라이언트를 같은 서버로 보내고 싶을 때 | NAT·프록시 뒤 사용자가 한 서버에 몰릴 수 있음 |
가상 예시: 같은 요청 6개, 규칙에 따라 달라지는 배치
가상 예시입니다. 서버 A, B, C 세 대가 있고 요청 6개가 1초 간격으로 들어옵니다. 첫 요청은 처리에 10초가 걸리는 무거운 작업이고 나머지 다섯 개는 1초짜리라고 가정합니다. 라운드로빈은 A, B, C, A, B, C 순으로 배정하므로 네 번째 요청도 A로 갑니다. A는 아직 10초짜리 작업을 처리 중이라 이 요청은 기다려야 합니다. 반면 최소 연결 규칙은 요청이 들어오는 순간 활성 연결이 가장 적은 서버를 고릅니다. 이 시나리오를 단순 계산하면 첫 요청만 A에 가고 나머지 다섯 개는 모두 한가한 B로 갑니다(1초 안에 끝나 B가 계속 비기 때문). 실제 서비스에서는 연결 수만으로 부하를 판단하기 어렵고 동점 처리 방식도 제품마다 달라서, 이 예시는 "규칙에 따라 배치가 달라질 수 있다"는 점만 보여 줍니다. 가중 라운드로빈도 같은 방식으로 이해할 수 있습니다. 가중치를 A:B:C = 5:3:2로 두면 10개 요청 중 A에 5개, B에 3개, C에 2개가 배정됩니다.
세션 고정의 대가와 로드밸런서 자체의 이중화
위키백과 문서는 한 사용자 세션의 요청을 계속 같은 백엔드 서버로 보내는 방식을 지속성(persistence) 또는 스티키니스라고 부릅니다. 가장 큰 단점으로 꼽히는 것이 자동 장애 전환의 어려움입니다. 그 서버가 죽으면 서버에 있던 세션 데이터도 함께 사라집니다. 또 클라이언트 IP로 사용자를 구분하는 방식은 DHCP, NAT, 웹 프록시 때문에 믿기 어려울 수 있다고 같은 문서가 지적합니다. 관련 개념은 NAT 기초 가이드와 DHCP 기초 가이드에서 볼 수 있습니다. 로드밸런서 자체도 단일 장애점이 되지 않도록 고가용성 쌍(high-availability pair)으로 배치하는 것이 일반적이라고 같은 문서는 설명합니다. 장애 전환이 가능하려면 남은 서버가 몰린 요청을 받아낼 여유 용량(N+1 같은 중복 구성)도 필요합니다.
L4와 L7을 고르는 기준
L4·L7 구분은 OSI 계층 번호에서 온 이름입니다(OSI 7계층 가이드 참고). 일반적으로 L4는 IP와 포트 수준, L7은 URL·헤더 같은 응용 계층 정보를 기준으로 삼습니다. 위키백과 문서는 L7에 해당하는 내용을 "요청된 URL에 따라 서로 다른 서버로 보내는 콘텐츠 인식 스위칭"으로 설명하고, TLS 종료를 하면 HTTPS 요청 내용을 보고 분산을 결정할 수 있다고 덧붙입니다. 정리하면 단순하고 빠른 분산이 목적이면 L4 쪽, 경로나 헤더에 따라 다른 서버군으로 보내야 하면 L7 쪽을 검토하게 됩니다. 다만 두 방식의 성능 차이는 제품과 구성에 크게 좌우되므로 일반론으로 단정하기 어렵습니다.
직접 점검해 보는 체크리스트
- 서버 사양이 서로 다른가? 그렇다면 가중치 지원 여부를 확인합니다.
- 한 요청이 수 초 이상 걸리는 작업이 섞여 있는가? 연결 수 기반 규칙을 검토합니다.
- 로그인 상태가 서버 메모리에 있는가? 세션 저장소를 분리하면 고정 없이도 동작할 수 있습니다.
- 상태 확인 대상이 실제 서비스 경로를 반영하는가? 핑만 되고 앱이 죽은 경우를 놓칠 수 있습니다.
- 로드밸런서도 이중화되어 있고, 서버 한 대가 빠져도 나머지가 감당할 용량이 있는가?
흔한 오해와 정정
- 오해: 로드밸런서만 두면 서비스가 절대 안 멈춘다. 실제: 로드밸런서도 단일 장애점이 될 수 있어 이중화가 필요하고, 모든 서버가 공통 원인(예: 같은 DB 장애)으로 실패하면 분산만으로 해결되지 않습니다.
- 오해: 라운드로빈이 항상 공평하다. 실제: 요청 개수는 공평해도 요청이 쓰는 자원은 다를 수 있습니다.
- 오해: 로드밸런싱과 CDN은 같은 것이다. 실제: 둘 다 트래픽을 나누지만 대상 범위와 목적이 다릅니다.
한계와 더 알아볼 점
이 글은 일반 개념만 다룹니다. 알고리즘의 정확한 이름과 옵션, 상태 확인 주기, 지속성 방식은 사용하는 소프트웨어나 클라우드 서비스의 공식 문서에서 확인해야 합니다. 오토스케일링과 결합한 구성 역시 서비스마다 동작과 지연이 다릅니다.
지역 단위로 트래픽을 나누는 CDN도 함께 보면 좋아요
로드밸런서가 서버 그룹 안에서 트래픽을 나눈다면, 전 세계 지역별로 트래픽을 나누는 기술도 있습니다.CDN(콘텐츠 전송 네트워크)이란? 기초 개념 정리에서 이어서 확인해보세요.
대역폭·지연시간 개념이 헷갈린다면
서버 성능을 이야기할 때 자주 등장하는 대역폭, 지연시간, 처리량의 차이가 궁금하다면대역폭·지연시간·처리량 차이 완전정복도 참고해보세요.
자주 묻는 질문
가중 라운드로빈은 언제 쓰나요?
서버 사양이 서로 다를 때 성능이 높은 서버가 더 많은 요청을 받도록 하는 방식입니다. 위키백과 문서도 가장 강력한 장비가 더 많은 요청을 먼저 받도록 가중할 수 있다고 설명합니다.
DNS 라운드로빈만으로도 부하 분산이 되나요?
하나의 이름에 여러 IP를 돌려주는 방식으로 어느 정도 분산은 가능하지만, 응답이 캐시되고 서버 상태를 직접 확인하지 않으므로 장애 대응은 느릴 수 있습니다. 짧은 TTL을 쓰는 이유이기도 합니다.
세션 고정을 쓰면 서버가 죽었을 때 로그인은 어떻게 되나요?
세션이 서버 메모리에만 있다면 그 서버가 죽을 때 함께 사라져 다시 로그인해야 할 수 있습니다. 세션 정보를 별도 저장소에 두는 설계가 대안으로 거론됩니다.
로드밸런서 자체가 고장 나면 어떻게 되나요?
로드밸런서가 단일 장애점이 되지 않도록, 실제 서비스에서는 로드밸런서 자체도 이중화(여러 대를 두고 하나가 죽으면 다른 하나가 대신 처리)해서 운영하는 경우가 일반적입니다.
작은 웹사이트에도 로드밸런싱이 필요한가요?
서버 한 대로 충분히 감당되는 트래픽이라면 당장은 필요하지 않습니다. 다만 방문자가 늘어나 서버를 여러 대로 늘리는 시점부터는 로드밸런서 없이는 트래픽을 나눠 받을 방법이 없기 때문에 필수적인 요소가 됩니다.