Round Robin과 Least Connection은 무엇이 다를까?

Load Balancer를 구성하면 가장 먼저 결정해야 하는 것 가운데 하나가 요청을 어떤 기준으로 Backend Server에 분산할지다.

서버가 세 대 있다고 해서 요청이 항상 정확히 3분의 1씩 나뉘는 것은 아니다.

Load Balancer가 어떤 알고리즘을 사용하느냐에 따라 실제 요청량과 Connection 수, 서버별 부하가 달라질 수 있다.

대표적인 방식이 Round Robin과 Least Connection이다.

Round Robin은 서버를 순서대로 선택하고, Least Connection은 현재 연결 수가 상대적으로 적은 서버를 선택한다.

설명만 보면 Least Connection이 더 똑똑하고 좋은 방식처럼 보일 수 있다.

하지만 실제 운영에서는 요청 처리 시간, Keep-Alive, 장시간 연결, 서버 성능 차이 같은 조건에 따라 결과가 달라진다.

이번 글에서는 두 방식이 실제 트래픽을 어떻게 나누는지와 운영 환경에서 어떤 차이가 발생하는지 살펴본다.

요청을 똑같이 나눴는데 서버 부하가 달라지는 이유

Backend Server가 다음과 같이 세 대 있다고 가정해보자.

Server A
Server B
Server C

Load Balancer가 요청을 정확히 같은 개수로 보냈다고 해도 각 서버의 부하가 반드시 동일해지는 것은 아니다.

예를 들어 요청 100개 가운데 일부는 단순 HTML 파일을 반환하고 일부는 데이터베이스 조회와 복잡한 연산을 수행할 수 있다.

같은 한 건의 요청이라도 처리 시간이 전혀 다르다.

요청 A → 20ms
요청 B → 300ms
요청 C → 3초

이런 상황에서는 서버별 요청 개수만 동일하게 만드는 것이 실제 부하를 동일하게 만드는 것과 같지 않다.

또한 Connection이 얼마나 오래 유지되는지도 영향을 준다.

짧은 요청이 반복되는 서비스와 WebSocket처럼 연결을 오랫동안 유지하는 서비스는 같은 분산 방식을 사용하더라도 결과가 달라질 수 있다.

그래서 Load Balancing 알고리즘을 선택할 때는 단순히

요청 개수를 어떻게 나눌까?

만 볼 것이 아니라

각 요청이 서버 자원을 얼마나 오래 사용하고 있는가?

까지 함께 봐야 한다.

Round Robin은 어떻게 요청을 분산할까?

Round Robin은 가장 이해하기 쉬운 분산 방식 가운데 하나다.

Backend Server가 A, B, C 세 대라면 요청을 순서대로 전달한다.

Request 1 → Server A
Request 2 → Server B
Request 3 → Server C
Request 4 → Server A
Request 5 → Server B
Request 6 → Server C

이 과정을 반복한다.

정상적인 상태에서 요청 처리 시간이 비슷하고 서버 성능도 동일하다면 매우 단순하면서도 효과적으로 트래픽을 분산할 수 있다.

Round Robin의 장점은 현재 서버 상태를 복잡하게 계산할 필요가 없다는 것이다.

요청이 들어올 때마다 다음 서버를 선택하면 되므로 동작 원리가 명확하다.

특히 Backend Server의 CPU, Memory, 애플리케이션 구조가 거의 동일하고 요청 처리 시간이 짧은 환경에서는 충분히 안정적으로 사용할 수 있다.

하지만 Round Robin은 한 가지 중요한 사실을 고려하지 않는다.

바로 현재 서버가 얼마나 바쁜가다.

예를 들어 Server A가 이전 요청을 아직 처리하고 있더라도 자신의 순서가 돌아오면 새로운 요청을 받을 수 있다.

같은 요청 수인데 한 서버만 바빠질 수 있다

다음과 같은 상황을 생각해보자.

Server A → 긴 요청 처리 중
Server B → 요청 처리 완료
Server C → 요청 처리 완료

이 상태에서 Round Robin 순서가 A라면 다음 요청은 다시 Server A로 전달된다.

Load Balancer 입장에서는 A가 요청을 몇 개 처리하고 있는지보다 순서를 기준으로 선택하기 때문이다.

극단적인 예를 들어보자.

각 서버에 요청 한 건씩 전달됐다.

Server A → 10초 소요
Server B → 0.1초 소요
Server C → 0.1초 소요

B와 C는 빠르게 요청을 끝냈지만 A는 여전히 이전 작업을 수행하고 있다.

그런데 이후에도 단순 Round Robin 방식이라면 일정 순서마다 계속 A가 선택된다.

이 상황이 반복되면 요청 개수는 비슷하지만 실제 동시 처리량은 A에 더 많이 쌓일 수 있다.

그 결과 A 서버에서

CPU 사용률 증가
Worker 점유
Connection 증가
응답 시간 증가
Timeout

같은 현상이 발생할 수 있다.

이 문제를 완화하기 위해 사용할 수 있는 방식 가운데 하나가 Least Connection이다.

Least Connection은 무엇을 기준으로 서버를 선택할까?

Least Connection은 이름 그대로 현재 활성 Connection이 가장 적은 서버를 우선 선택하는 방식이다.

예를 들어 현재 상태가 다음과 같다고 하자.

Server A : 80 connections
Server B : 20 connections
Server C : 35 connections

새로운 연결이 들어오면 Server B가 선택될 가능성이 높다.

Round Robin이라면 단순히 다음 순서의 서버를 선택하지만 Least Connection은 서버의 현재 연결 상태를 참고한다.

이 방식이 유용한 이유는 요청 처리 시간이 서로 다른 환경에서 나타난다.

처리가 오래 걸리는 서버에는 Connection이 상대적으로 오래 남아 있다.

반대로 요청을 빠르게 처리하는 서버는 Connection이 빨리 종료되기 때문에 활성 Connection 수가 감소한다.

결과적으로 Load Balancer가 상대적으로 여유가 있는 서버로 새로운 연결을 전달할 수 있다.

개념적으로는

새 Connection
      ↓
현재 연결 수 비교
      ↓
가장 적은 서버 선택

과 같은 흐름이다.

하지만 여기서 중요한 것은 Least Connection이 CPU 사용률이나 실제 애플리케이션 부하를 직접 확인하는 것은 아니라는 점이다.

기본적인 Least Connection 알고리즘의 기준은 Connection 수다.

Connection이 적다고 서버가 항상 여유로운 것은 아니다

Least Connection은 Round Robin보다 서버 상태를 더 반영하는 것처럼 보이지만 완벽한 방식은 아니다.

예를 들어 다음 두 서버를 생각해보자.

Server A : Connection 10개
Server B : Connection 30개

Connection 수만 보면 A가 훨씬 여유롭게 보인다.

하지만 A의 10개 요청이 모두 CPU를 많이 사용하는 무거운 작업이고 B의 30개 요청이 정적 파일을 처리하는 가벼운 요청이라면 실제 서버 부하는 반대일 수 있다.

Server A
CPU : 95%

Server B
CPU : 30%

이런 상황에서도 단순 Least Connection은 A의 Connection 수가 더 적다는 이유로 A를 선택할 수 있다.

따라서 Least Connection을

가장 부하가 낮은 서버 선택

이라고 이해하면 정확하지 않다.

보다 정확하게는

현재 활성 Connection 수가 적은 서버 선택

이라고 이해해야 한다.

Keep-Alive 환경에서는 Connection과 요청 수를 구분해야 한다

Load Balancer를 분석할 때 자주 혼동되는 부분이 Connection 수와 HTTP Request 수다.

HTTP Keep-Alive가 사용되면 하나의 TCP Connection에서 여러 HTTP Request를 처리할 수 있다.

TCP Connection 1개
   ├─ Request 1
   ├─ Request 2
   ├─ Request 3
   └─ Request 4

따라서

Connection 100개

라고 해서 반드시 요청도 100개라는 의미는 아니다.

반대로 짧은 Connection이 매우 빠르게 생성되고 종료되는 서비스라면 현재 순간의 Connection 수가 낮더라도 초당 요청 수는 높을 수 있다.

이 때문에 Load Balancer를 운영할 때는 하나의 지표만 보면 안 된다.

최소한 다음 항목을 함께 보는 것이 좋다.

Request Rate
Active Connections
Response Time
HTTP Status
Backend CPU
Backend Memory

특히 Round Robin과 Least Connection을 비교할 때 서버별 요청 수만 보면 실제 차이를 놓칠 수 있다.

실제 서버에서는 어떤 증상으로 차이가 나타날까?

Round Robin 환경에서 특정 Backend Server의 응답 시간이 길어지면 흥미로운 현상이 나타날 수 있다.

요청 분포 자체는 비슷하다.

Server A : 10,100 requests
Server B : 9,950 requests
Server C : 9,950 requests

겉으로 보면 Load Balancing은 매우 정상적으로 동작한다.

하지만 응답 시간이 다음과 같다면 상황이 다르다.

Server A : 평균 1.8초
Server B : 평균 180ms
Server C : 평균 190ms

A 서버에는 요청이 계속 동일한 비율로 들어오고 있기 때문에 느린 서버가 전체 사용자 경험에 영향을 준다.

Least Connection에서는 A의 요청 처리가 오래 걸리면서 활성 Connection이 증가한다면 새로운 연결이 B와 C 쪽으로 더 많이 이동할 가능성이 있다.

이때 요청 분포는 오히려 다음처럼 보일 수 있다.

Server A : 6,500 requests
Server B : 11,600 requests
Server C : 11,900 requests

숫자만 보면 불균형처럼 보이지만 실제로는 더 빠르게 처리할 수 있는 서버로 트래픽이 이동한 결과일 수 있다.

따라서 Load Balancing 상태를 분석할 때

각 서버에 요청이 동일하게 들어갔는가?

만으로 정상 여부를 판단하면 안 된다.

Round Robin 문제는 어떻게 분석할까?

먼저 Backend Server별 요청량을 비교한다.

Nginx를 Backend Web Server로 사용한다면 Access Log를 분석해 서버별 Request 수와 응답 코드를 비교할 수 있다.

실시간으로 로그를 확인할 때는 다음과 같이 볼 수 있다.

tail -f /var/log/nginx/access.log

하지만 요청량만으로는 부족하다.

응답 시간 정보도 함께 기록하는 것이 좋다.

Nginx에서는 로그 포맷에 $request_time 등을 포함시켜 요청 처리 시간을 확인할 수 있다.

예를 들어 특정 서버만 지속적으로 처리 시간이 길다면 Load Balancer 알고리즘 문제가 아니라 Backend Server 자체의 문제가 먼저 존재할 수 있다.

이때는

top

또는

vmstat 1

같은 명령으로 CPU와 시스템 자원 상태를 확인할 수 있다.

top은 특정 프로세스가 CPU나 Memory를 과도하게 사용하는지 확인할 때 유용하다.

vmstat 1은 CPU 대기 상태나 Run Queue 등 시스템 전체 흐름을 연속적으로 확인할 때 사용할 수 있다.

중요한 것은

Load Balancer 문제인가?
Backend Server 문제인가?

를 분리해서 보는 것이다.

Least Connection 문제는 어떻게 분석할까?

Least Connection에서는 서버별 Active Connection 수를 확인하는 것이 중요하다.

Linux에서는 다음과 같이 서버가 현재 가지고 있는 TCP 연결을 확인할 수 있다.

ss -ant

특정 서비스 포트를 기준으로 확인하려면 필터링해서 볼 수도 있다.

ss -ant | grep ':443'

다만 단순히 출력 줄 수만 세는 것으로 모든 상황을 판단해서는 안 된다.

TCP Connection에는

ESTABLISHED
TIME_WAIT
CLOSE_WAIT
SYN_RECV

등 여러 상태가 존재한다.

Least Connection 알고리즘이 어떤 Connection 상태를 기준으로 계산하는지는 사용하는 Load Balancer 구현과 설정에 따라 달라질 수 있다.

따라서 운영 환경에서는 Load Balancer 자체가 제공하는 Backend Connection 통계를 우선 확인하는 것이 좋다.

그리고 해당 값과 실제 Backend Server의 TCP 상태를 비교해야 한다.

서버 성능이 다르다면 Weight도 함께 생각해야 한다

Backend Server 세 대의 성능이 모두 동일하다는 보장은 없다.

예를 들어

Server A : 16 Core
Server B : 16 Core
Server C : 8 Core

같은 환경일 수 있다.

이런 구조에서 세 서버에 동일한 비율로 요청을 전달하면 C 서버가 먼저 병목에 도달할 가능성이 있다.

이때는 Weight를 적용할 수 있다.

개념적으로

Server A : Weight 2
Server B : Weight 2
Server C : Weight 1

처럼 처리 능력이 높은 서버가 더 많은 요청을 받도록 설정하는 것이다.

Round Robin에 Weight를 적용하면 Weighted Round Robin이 되고 Least Connection에도 구현에 따라 Weight를 함께 사용할 수 있다.

중요한 점은 Weight를 단순히 CPU Core 수만 보고 결정하지 않는 것이다.

애플리케이션 성능은 CPU뿐 아니라 Memory, Disk I/O, DB Connection, JVM Heap, Worker 수 등 다양한 요소의 영향을 받는다.

실제 처리량을 측정한 뒤 비율을 조정하는 것이 더 안전하다.

어떤 환경에서 어떤 방식을 선택해야 할까?

요청 처리 시간이 비교적 균일하고 Backend Server의 성능이 동일하다면 Round Robin은 단순하면서도 충분히 효과적이다.

예를 들어 정적 콘텐츠나 빠른 API처럼 요청 하나의 처리 시간이 크게 차이 나지 않는 환경에서는 복잡한 분산 기준이 필요하지 않을 수 있다.

반대로 요청 처리 시간이 크게 달라지고 하나의 Connection이 오랫동안 유지되는 환경이라면 Least Connection을 검토할 수 있다.

대표적으로

장시간 HTTP 요청
Streaming
WebSocket
처리 시간이 다양한 API

등에서는 Connection 상태를 고려하는 방식이 더 적합할 수 있다.

하지만 어떤 알고리즘을 사용하든 그것만으로 Backend Server의 성능 문제가 해결되는 것은 아니다.

한 서버에서 애플리케이션 오류나 CPU 병목이 발생한다면 분산 알고리즘보다 먼저 해당 원인을 찾아야 한다.

Load Balancer는 부하를 분산하는 역할을 하지 느린 서버를 빠르게 만드는 장치는 아니기 때문이다.

정리

Round Robin과 Least Connection의 가장 큰 차이는 서버를 선택하는 기준이다.

Round Robin은

순서

를 기준으로 한다.

Least Connection은

현재 활성 Connection 수

를 기준으로 한다.

따라서 요청 처리 시간이 비슷하고 서버 성능이 동일한 환경에서는 Round Robin만으로도 안정적인 분산이 가능하다.

반대로 요청 처리 시간이 크게 다르거나 Connection 유지 시간이 긴 환경에서는 Least Connection이 특정 서버로 연결이 쌓이는 현상을 완화하는 데 도움이 될 수 있다.

하지만 Least Connection 역시 실제 CPU 사용률이나 애플리케이션 처리 능력을 직접 판단하는 방식은 아니다.

그래서 운영 환경에서는 알고리즘 이름만 보고 선택해서는 안 된다.

서버별 Request 수, Active Connection, 응답 시간, CPU, Memory, Error 비율을 함께 확인해야 한다.

결국 중요한 것은 요청을 똑같이 나누는 것이 아니라 각 Backend Server가 감당할 수 있는 수준으로 실제 부하가 분산되고 있는지 확인하는 것이다.

Round Robin과 Least Connection의 차이를 이해하면 Load Balancer 설정을 단순한 옵션 선택이 아니라 실제 서버 상태와 연결 흐름을 기준으로 판단할 수 있게 된다.