로드밸런싱 알고리즘

나누기는 나누는데, 어떻게 나눌 것인가

로드밸런서가 요청을 나눠준다는 것은 배웠습니다. 그런데 어떤 규칙으로 나눌까요? 이 규칙을 로드밸런싱 알고리즘이라고 합니다.

놀랍게도 이 선택 하나가 서비스를 살리기도 하고 죽이기도 합니다.

1. 라운드 로빈 — 순서대로

가장 단순합니다. 1번, 2번, 3번, 1번, 2번, 3번… 순서대로 돌립니다.

잘 동작합니다. 서버 성능이 같고 요청 무게가 비슷하다면 이보다 나은 게 없습니다. 기억할 것도 없고, 계산할 것도 없고, 고장 날 것도 없습니다. 대부분의 시스템은 여기서 끝내도 됩니다.

그런데 서버가 제각각이면

현실에서는 서버가 똑같지 않습니다. 3년 전에 산 서버와 지난달에 산 서버가 같이 돌아갑니다.

서버 A (신형) : 초당 160건 처리 가능
서버 B (신형) : 초당 160건 처리 가능
서버 C (구형) : 초당 10건 처리 가능

초당 150건을 똑같이 나누면 각 50건입니다. A와 B는 여유롭습니다. C는요? 초당 40건씩 버립니다.

전체 유실률이 27%입니다. A와 B가 놀고 있는데도 사용자의 4분의 1이 오류를 봅니다.

여기서 핵심을 짚습니다. 똑같이 나누는 것은 공평한 것이 아닙니다. 병약한 사람과 장정에게 똑같은 무게의 짐을 지우면, 그것은 공평이 아니라 병약한 사람을 쓰러뜨리는 일입니다.

요청 무게가 다를 때도 같은 일이 벌어진다

서버가 전부 똑같아도 문제가 생길 수 있습니다. 요청마다 무게가 다르기 때문입니다.

• "로그인 상태 확인" — 1밀리초
• "지난 3년 매출 보고서 생성" — 4초

라운드 로빈은 요청의 무게를 보지 않습니다. 그냥 숫자를 셉니다. 운 나쁜 서버에 무거운 요청이 연달아 가면, 그 서버만 죽어갑니다. 요청 수는 정확히 똑같이 나눴는데도요.

2. 최소 연결 우선 — 지금 가장 한가한 곳으로

발상을 바꿉니다. 횟수를 세지 말고, 지금 몇 개를 붙들고 있는지를 봅니다. 그리고 가장 적게 붙들고 있는 서버에 보냅니다.

마법 같은 일이 벌어집니다. 아무도 서버 성능을 알려주지 않았는데 알아서 맞춰집니다.

• 구형 서버 C는 처리가 느리니 요청을 오래 붙들고 있습니다.
• 붙들고 있는 수가 많으니 로드밸런서가 C를 잘 고르지 않습니다.
• 결과적으로 C에는 C가 감당할 수 있는 만큼만 갑니다.

라운드 로빈  : A 50  B 50  C 50 → C가 40건 유실
최소 연결    : A 70  B 70  C 10 → 유실 없음

같은 서버, 같은 트래픽입니다. 규칙 한 줄을 바꿨을 뿐인데 유실이 사라졌습니다. 서버를 새로 사는 것보다 훨씬 싼 해결책입니다.

실무에서 "느린 서버 한 대가 전체를 갉아먹는" 상황의 상당수가 이것으로 풀립니다. 느린 이유가 무엇이든 상관없습니다. 구형이든, 이웃 프로세스가 CPU를 먹고 있든, 디스크가 아프든, 결과적으로 느리면 알아서 덜 받습니다.

3. 일관된 해시 — 같은 사람은 같은 곳으로

세 번째 규칙은 목적이 아예 다릅니다. 균형이 아니라 일관성을 위한 것입니다.

사용자 ID를 계산해서 "이 사람은 항상 2번 서버"로 고정합니다. 왜 이런 걸 할까요?

주로 캐시 때문입니다. 2번 서버가 이 사용자의 데이터를 이미 메모리에 갖고 있다면, 같은 서버로 계속 보내는 편이 훨씬 빠릅니다. 매번 다른 서버로 가면 매번 처음부터 읽어야 합니다.

하지만 대가가 큽니다.

마지막 것이 중요합니다. 일관된 해시는 "상태 없는 서버"의 반대 방향입니다. 그래서 "그냥 캐시 히트율이 좀 좋아지면 좋겠다" 정도의 이유로 쓰면 안 됩니다. 분명한 이유가 있을 때만 씁니다.

정리 — 어떻게 고를 것인가

가장 중요한 조언은 이것입니다. 기본은 라운드 로빈입니다. 그리고 어느 한 서버만 이상하게 힘들어하는 것이 보이면, 그때 최소 연결 우선을 떠올리세요. 미리 복잡하게 갈 이유가 없습니다.

직접 해보세요

아래 과제에는 신형 서버 두 대와 구형 서버 한 대가 있습니다. 서버를 추가할 수는 없습니다. 있는 것만으로 유실을 없애 보세요.