로드 밸런서(ELB/ALB)의 알고리즘: 라운드 로빈 vs 리스트 커넥션

 트래픽 폭주, 서버가 버티는 비결

웹 서비스 운영 중 사용자가 급격히 늘어날 때, 단 한 대의 서버로는 모든 요청을 처리할 수 없습니다. 이때 등장하는 구세주가 바로 로드 밸런서(Load Balancer)입니다. AWS의 ELB(Elastic Load Balancing)나 ALB(Application Load Balancer)가 대표적인 예입니다.

로드 밸런서는 들어오는 트래픽을 여러 대의 서버(EC2 등)에 골고루 나눠주는 교통경찰 역할을 합니다. 하지만 무턱대고 나누는 것이 아닙니다. '어떤 규칙'으로 나눌 것인가에 따라 서비스의 안정성과 속도가 완전히 달라집니다. 오늘은 가장 대표적인 두 가지 알고리즘, 라운드 로빈(Round Robin)과 리스트 커넥션(Least Connection)을 비교 분석해 봅니다.


1. 라운드 로빈(Round Robin): 공평하게 순서대로

가장 기본적이고 직관적인 방식입니다. '순차적 분산'이라고도 부릅니다.


작동 원리

마치 카드 게임에서 딜러가 플레이어들에게 카드를 한 장씩 순서대로 나눠주는 것과 같습니다. 서버가 A, B, C 세 대가 있다면, 첫 번째 요청은 A, 두 번째는 B, 세 번째는 C, 네 번째는 다시 A에게 보냅니다. 현재 서버의 상태나 부하량은 고려하지 않고 오직 순서에만 입각해 트래픽을 배분합니다.


장점

  • 단순함: 구현이 매우 쉽고 이해하기 편합니다.
  • 리소스 소모 적음: 로드 밸런서가 복잡한 계산을 할 필요가 없어 자체 부하가 적습니다.
  • 동일 환경에 유리: 모든 서버의 스펙이 동일하고, 처리해야 할 요청의 성격(처리 시간)이 비슷할 때 가장 효율적입니다.


단점

  • 부하 불균형: 어떤 요청은 1초 만에 끝나지만, 어떤 요청은 1분이 걸릴 수 있습니다. 라운드 로빈은 이를 무시하고 계속 요청을 보내기 때문에, 운 나쁘게 무거운 작업만 할당받은 특정 서버가 과부하로 뻗어버릴 수 있습니다.


2. 리스트 커넥션(Least Connection): 덜 바쁜 놈이 더 일해라

조금 더 스마트한 방식입니다. ‘최소 연결 분산’이라고도 합니다.


작동 원리

로드 밸런서가 각 서버의 현재 활성 연결(Active Connection) 수를 실시간으로 체크합니다. 새로운 요청이 들어오면, 현재 연결된 세션 수가 가장 적은 서버, 즉 ‘가장 한가한 서버’에게 트래픽을 보냅니다. 서버 A가 10명, B가 5명, C가 2명을 처리 중이라면, 다음 요청은 C에게 배정됩니다.


장점

  • 유연한 대응: 서버마다 트래픽 처리 속도가 다르거나, 요청별로 작업량이 불규칙할 때 효과적입니다.
  • 안정성: 특정 서버에 트래픽이 몰려 과부하가 걸리는 ‘핫스팟(Hotspot)’ 현상을 방지합니다.


단점

  • 복잡성: 로드 밸런서가 모든 서버의 연결 상태를 계속 모니터링해야 하므로 라운드 로빈보다 리소스 소모가 약간 더 많습니다. (현대 하드웨어에서는 크게 문제 되지 않는 수준입니다.)


3. 결정적 차이: 언제 무엇을 써야 할까?

두 알고리즘의 승패는 ‘서비스의 성격’에 따라 갈립니다.


라운드 로빈을 선택해야 하는 경우

  • 단순 웹 서버: 정적인 HTML, 이미지 파일 등 요청 처리 시간이 짧고 일정한 경우.
  • 동일 스펙 서버: 클러스터를 구성하는 모든 서버의 CPU, RAM 성능이 똑같을 때.
  • 세션이 짧은 연결: HTTP(S)와 같이 요청과 응답이 빠르게 종결되는 프로토콜.


리스트 커넥션을 선택해야 하는 경우

  • 롱 폴링 & 스트리밍: 동영상 재생, 실시간 채팅, 온라인 게임 등 한 번 연결되면 세션이 오래 유지되는 경우.
  • 복잡한 로직: DB 쿼리가 복잡하거나 파일 업로드/다운로드 등 처리 시간이 들쑥날쑥한 동적 애플리케이션.
  • 서버 스펙 불일치: 물리 서버와 클라우드 인스턴스가 섞여 있거나, 고성능 서버와 저성능 서버가 혼재된 환경.


4. 심화: 가중치(Weighted) 옵션의 활용

실무에서는 위 두 가지 방식에 '가중치(Weight)' 개념을 더해 사용하기도 합니다.

  • Weighted Round Robin: 서버 스펙이 다를 때(예: A서버가 B서버보다 2배 좋음), A에게 2번, B에게 1번 주는 식으로 비율을 조절합니다.
  • Weighted Least Connection: 마찬가지로 고성능 서버가 더 많은 연결을 감당하도록 가중치를 둡니다.


정답은 모니터링에 있다

"무조건 리스트 커넥션이 좋다"고 말할 수는 없습니다. 트래픽 패턴이 매우 규칙적이고 짧은 요청 위주라면 라운드 로빈이 가장 빠르고 깔끔한 정답일 수 있습니다. 반면, 사용자 체류 시간이 길고 트래픽이 불규칙하다면 리스트 커넥션이 서버 안정성을 보장합니다.

지금 운영 중인 서비스의 Access Log와 서버 리소스 점유율을 확인해 보세요. 특정 서버만 CPU가 튀거나 응답이 느리다면, 알고리즘을 변경할 때가 된 것입니다. 최적의 로드 밸런싱은 예측이 아닌 데이터 기반의 튜닝에서 시작됩니다.

댓글

댓글 쓰기

이 블로그의 인기 게시물

VPC 네트워크 설계: 서브넷(Subnet)을 퍼블릭/프라이빗으로 나누는 기준

  클라우드 보안의 시작, 네트워크 격리 클라우드 인프라를 구축할 때 가장 먼저 마주하는 용어 중 하나가 바로 VPC(Virtual Private Cloud) 입니다. VPC는 클라우드 내에 만드는 우리만의 가상 데이터 센터입니다. 하지만 단순히 VPC를 만들었다고 끝이 아닙니다. 이 거대한 공간을 어떻게 쪼개고(Subnetting), 어떤 용도로 사용할지 결정하는 것이 보안과 효율성을 좌우합니다. 많은 초보 설계자가 범하는 실수는 모든 리소스를 인터넷에 노출된 하나의 서브넷에 몰아넣는 것입니다. 이는 마치 현관문 없이 금고를 길거리에 두는 것과 같습니다. 오늘은 안전하고 튼튼한 인프라를 위해 서브넷을 퍼블릭(Public)과 프라이빗(Private)으로 나누는 결정적 기준을 알아보겠습니다. 1. 서브넷 분리의 핵심 원리: 라우팅 테이블과 인터넷 게이트웨이 퍼블릭과 프라이빗을 나누는 기준은 물리적인 위치가 아닙니다. 바로 ' 인터넷과 직접 통신할 수 있는가?' 입니다. 이를 기술적으로 결정하는 것은 라우팅 테이블(Routing Table) 설정입니다. 퍼블릭 서브넷: 라우팅 테이블이 인터넷 게이트웨이(IGW, Internet Gateway) 를 향해 열려 있습 니다. 외부에서 들어오는 트래픽을 직접 받을 수 있고, 내부에서 밖으로 나갈 수도 있습니다. 프라이빗 서브넷: 인터넷 게이트웨이로 가는 경로가 없습니다. 외부에서 직접 접근할 수 없으며, 내부IP(Private IP)로만 통신합니다. 2. 퍼블릭 서브넷(Public Subnet): 외부와 소통하는 접점 퍼블릭 서브넷은 외부 사용자의 요청을 가장 먼저 받아내는 '안내 데스크' 역할을 합니다. 따라서 반드시 외부 인터넷 접근이 필요한 리소스 만 이곳에 배치해야 합니다. 퍼블릭 서브넷 배치 기준 로드 밸런서 (Load Balancer, ALB/NLB): 사용자의 트래픽을 받아 뒷단의 서버로 분산시켜주는 역할을 하므로 반드시 공인 IP를 가지고 외부에 노출되어야...
자세한 내용 보기

온프레미스 vs 클라우드: 인프라 아키텍처의 결정적 차이 5가지

기업의 운명을 가르는 선택, 인프라 아키텍처 디지털 전환(DX)이 가속화되면서 모든 기업은 중요한 기로에 서 있습니다. 바로 "데이터와 시스템을 어디에 둘 것인가?"라는 질문입니다. 과거에는 회사 내부에 서버실을 구축하는 것이 당연했지만, 이제는 클라우드가 강력한 대안으로 자리 잡았습니다. 하지만 무조건적인 클라우드 전환이 정답은 아닙니다. 이 글에서는 IT 인프라의 두 축인 온프레미스(On-Premise) 와 클라우드(Cloud) 의 개념을 명확히 하고, 의사 결정에 꼭 필요한 5가지 결정적 차이를 분석해 드립니다. 1. 개념의 차이: 소유할 것인가, 빌려 쓸 것인가? 본격적인 비교에 앞서 두 개념을 가장 쉽게 이해하는 방법은 '부동산'에 비유하는 것입니다. 온프레미스(On-Premise): 직접 땅을 사고 집을 짓는 '자가 주택'과 같습니다. 하드웨어부터 네트워크, 운영체제까지 기업이 직접 구매하여 사내 전산실이나 데이터 센터 에 구축하고 운용합니다. 모든 통제권이 나에게 있습니다. 클라우드(Cloud): 필요한 만큼 공간을 빌려 쓰는 '호텔'이나 '공유 오피스'와 같습니다. AWS, Azure, Google Cloud 같은 공급자가 구축해 둔 거대한 인프라 자원을 인터넷을 통해 필요한 만큼 빌려 쓰고, 쓴 만큼 비용을 지불합니다. 2. 비용 구조: 초기 투자비용(CAPEX) vs 운영 비용(OPEX) 가장 큰 차이는 돈을 쓰는 방식에 있습니다. 온프레미스: 초기 투자 중심 (CAPEX) 온프레미스는 시스템 구축 초기에 막대한 자본적 지출(CAPEX)이 발생합니다. 서버, 스토리지, 네트워크 장비를 직접 구매해야 하며, 이를 설치할 공간과 전력, 냉각 시스템도 갖춰야 합니다. 구축 후에는 감가상각을 통해 비용을 처리합니다. 장기적으로 시스템 변경이 거의 없다면 총비용 면에서 유리할 수 있습니다. 클라우드: 운영 비용 중심 (OPEX) 클라우드는 초기 구축비...
자세한 내용 보기