로드밸런서

창구를 늘렸는데 줄이 그대로인 이유

앞서 "처리량이 부족하면 창구를 늘려라"를 배웠습니다. 그래서 서버를 세 대로 늘렸습니다. 그런데 여전히 느립니다. 왜일까요?

손님을 나눠주는 사람이 없기 때문입니다.

민원실에 창구를 세 개 열어놓고 안내 직원을 두지 않으면 어떻게 될까요? 손님들은 문에서 가장 가까운 1번 창구에 줄을 섭니다. 2번과 3번은 텅 빈 채로 앉아 있습니다. 창구를 늘리는 데 돈은 다 썼는데 대기 시간은 그대로입니다.

웹에서 벌어지는 똑같은 일

브라우저는 shop.example.com이라는 이름을 주소 하나로 바꿔서 그 주소로 접속합니다. 주소 하나 = 서버 한 대입니다. 서버를 세 대로 늘려도 브라우저는 자기가 아는 주소 하나에만 갑니다. 나머지 두 대의 존재조차 모릅니다.

서버 1  ← 초당 100건 전부 여기로   (한계 40건 → 60건 유실)
서버 2  ← 0건                      (놀고 있음)
서버 3  ← 0건                      (놀고 있음)

돈은 세 배로 쓰고 성능은 그대로입니다. 게다가 이 구성은 서버 1이 죽으면 서비스 전체가 끝납니다. 살아 있는 서버가 두 대나 있는데도요.

대표 번호를 만든다

큰 회사에 전화하면 대표번호로 겁니다. 그 번호는 특정 직원의 자리 전화가 아닙니다. 교환대로 연결되고, 교환원이 지금 통화 가능한 직원에게 돌려줍니다.

• 직원이 몇 명인지 걸 때는 알 필요가 없습니다.
• 직원이 늘거나 줄어도 대표번호는 그대로입니다.
• 어떤 직원이 자리를 비웠으면 교환원이 알아서 다른 사람에게 돌립니다.

로드밸런서가 이 교환대입니다.

                  ┌→ 서버 1 (초당 33건)
사용자 → 로드밸런서 ├→ 서버 2 (초당 33건)
                  └→ 서버 3 (초당 33건)

이제 사용자가 아는 주소는 로드밸런서 하나입니다. 서버가 세 대인지 서른 대인지 사용자는 알 필요도, 알 방법도 없습니다.

로드밸런서가 하는 두 가지 일

로드밸런서를 "나눠주는 기계"로만 이해하면 절반만 이해한 것입니다. 실제로는 두 가지를 합니다.

두 번째가 실무에서는 더 중요할 때가 많습니다. 서버 한 대가 죽는 일은 생각보다 자주 일어납니다. 하드웨어가 고장 나기도 하고, 배포하다가 실수하기도 하고, 메모리가 새기도 합니다.

로드밸런서가 있으면 그때 아무 일도 일어나지 않습니다. 죽은 서버로 가던 요청이 살아 있는 서버로 갈 뿐입니다. 사용자는 모릅니다. 담당자는 다음 날 아침에 고쳐도 됩니다.

로드밸런서가 없는 시스템에서는 서버 한 대의 고장이 곧 새벽 3시 긴급 호출입니다. 있는 시스템에서는 월요일 아침의 할 일입니다. 같은 고장인데 삶의 질이 다릅니다.

정직하게 짚어야 할 것

로드밸런서를 놓으면 이상한 일이 벌어집니다. 로드밸런서 자신이 죽으면 전부 죽습니다.

서버를 세 대로 늘려 단일 장애점을 없앴는데, 그 앞에 새로운 단일 장애점을 하나 만들어 놓은 셈입니다. 문제를 옮긴 것 아니냐고 물을 수 있습니다. 맞습니다. 하지만 세 가지 이유로 남는 장사입니다.

1. 로드밸런서는 하는 일이 단순합니다. 요청을 받아 넘기기만 하므로 우리가 짠 코드처럼

자주 고장 나지 않습니다.

1. 지켜야 할 곳이 한 곳입니다. 여기저기 흩어진 위험보다 훨씬 관리하기 쉽습니다.
2. 그리고 이 한 곳도 결국 이중화합니다. 그 방법은 뒤의 강의에서 다룹니다.

직접 해보세요

아래 과제에는 서버가 이미 세 대 있고, 사용자와 전부 연결되어 있습니다. 그런데도 요청의 절반 이상이 버려집니다. 먼저 실행해서 왜 그런지 확인한 다음 고쳐 보세요. 서버를 더 사는 것이 답이 아니라는 것을 눈으로 보게 됩니다.