로드 밸런서

서비스가 작을 때는 서버 한 대로 충분합니다. 주소창에 친 이름이 그 한 대를 가리키고, 모든 요청이 거기로 가고, 그 한 대가 다 답합니다. 문제는 사람이 늘 때가 아니라 갑자기 늘 때 생깁니다. 한 대가 감당할 수 있는 동시 요청 수에는 천장이 있고, 그 천장을 넘으면 응답이 느려지다가 아예 답하지 않습니다.

더 곤란한 건 그 한 대가 서비스 전체라는 점입니다. 재부팅하면 그동안 아무도 못 들어오고, 새 버전을 올리는 몇 분도 마찬가지이고, 디스크가 고장 나면 복구될 때까지 서비스가 없습니다. 이런 지점을 단일 장애점이라고 부릅니다. 그것 하나가 멈추면 전체가 멈추는 자리입니다.

페이지덱에서도 같은 일이 있었습니다. 무료 플랜 공지가 퍼진 날 동시 접속이 평소의 열 배로 뛰었고 서버가 응답을 멈췄습니다. 태오가 십 분 만에 같은 구성의 서버를 한 대 더 띄웠지만 소용이 없었습니다. 새 서버의 주소는 아무도 모르니 사람들은 여전히 죽은 쪽으로만 들어갔습니다. 서버를 늘리는 것과 늘린 서버에 사람이 가는 것은 다른 일이었습니다.

로드 밸런서는 이 둘 사이를 잇습니다. 바깥에서 보는 주소는 하나로 두고, 그 뒤에 서버를 몇 대 세우든 들어온 요청을 알아서 나눠 보냅니다. 서버를 늘리는 일이 그때부터 설정 한 줄로 끝납니다.

요청을 받아 넘기는 자리를 하나 만들어 두면 서로 다른 세 가지 문제가 같이 풀립니다.

1. 분배 — 뒤에 선 서버 중 어디로 보낼지 규칙으로 정합니다. 가장 단순한 것은 차례로 돌아가며 보내는 방식이고, 응답 시간이 제각각인 서비스에서는 지금 붙어 있는 연결이 가장 적은 쪽으로 보냅니다.
2. 장애 격리 — 뒤쪽 서버에 몇 초마다 한 번씩 "살아 있냐" 고 묻고 답이 없는 대를 목록에서 뺍니다. 보통 5초마다 확인해 두 번 연속 실패하면 제외하는 식이라, 한 대가 죽어도 십여 초 뒤부터는 그쪽으로 요청이 가지 않습니다. 4대 중 1대가 빠지면 남은 3대가 각각 33퍼센트씩 더 받게 되니, 애초에 대수를 정할 때 한 대가 빠져도 버틸 만큼 여유를 둡니다.
3. 무중단 교체 — 롤링 배포가 가능해집니다. 4대 중 1번을 목록에서 빼고 새 버전을 올린 뒤 되돌려 놓고, 같은 일을 2번부터 4번까지 반복합니다. 교체하는 내내 나머지 3대가 요청을 받으니 사용자 쪽에서는 끊기는 순간이 없습니다.

여기서 걸리는 것이 세션입니다. 세션은 사용자가 들어와서 나갈 때까지의 이용 묶음인데, 로그인 상태 같은 것이 1번 서버의 메모리에만 들어 있으면 다음 요청이 2번으로 갔을 때 처음 온 사람 취급을 받습니다. 푸는 방법은 두 가지입니다. 같은 사용자를 계속 같은 서버로 보내도록 묶어 두거나, 로그인 상태를 서버 바깥의 공용 저장소로 옮기는 것입니다. 앞쪽이 손이 덜 가지만 그 서버가 죽으면 거기 묶인 사람들은 전부 로그아웃되고, 대수를 늘려도 이미 묶인 사람은 옮겨 가지 않아 쏠림이 남습니다.

같은 문제를 다루는 다른 수가 셋 있고, 셋 다 로드 밸런서를 완전히 대신하지는 못합니다.

1. 서버 한 대를 키우기 — 메모리를 8기가에서 32기가로 올리는 식입니다. 코드를 고칠 필요가 없어 당장 급할 때 가장 빠른 수입니다. 다만 한 대가 커지는 데 한계가 있고, 사양을 바꾸는 동안 그 한 대가 멈추며, 단일 장애점은 그대로 남습니다.
2. DNS 로 나눠 보내기 — 이름 하나에 서버 주소를 여러 개 걸어 두고 묻는 쪽마다 다른 주소를 내주는 방식입니다. 장비 없이 되는 대신 죽은 서버를 빼는 데 시간이 걸립니다. 주소를 받아 간 쪽이 그 값을 한동안 저장해 두기 때문에, 설정에서 지워도 캐시가 만료될 때까지는 죽은 서버로 계속 들어갑니다.
3. 리버스 프록시를 앞에 두기 — 요청을 대신 받아 뒤로 넘기는 중계라 분배 기능이 딸려 오는 경우가 많습니다. 실무에서 둘을 같은 장비로 쓰는 일이 흔한 이유입니다. 뒤에서 다시 다룹니다.

직접 세우는 대신 클라우드 사업자가 파는 것을 켜는 선택도 있습니다. 요금은 시간당 얼마에 처리한 양을 더해 매기고, 대신 장비 자체가 죽는 경우를 사업자가 책임집니다. 대수가 스스로 늘고 주는 오토스케일링과 같이 쓰려면 사실상 이쪽을 씁니다.

"로드 밸런서 뒤에 두 대 더 붙였어요. 이제 여섯 대예요."

서비스를 멈추지 않고 처리 능력을 1.5배로 올렸다는 말입니다.

"3번 서버 헬스 체크 떨어져서 빠졌는데 원인 좀 보죠."

한 대가 응답을 못 해 목록에서 제외됐고, 지금 서비스는 나머지로 돌고 있다는 뜻입니다.

"로그인이 자꾸 풀린다는데 세션을 서버 메모리에 들고 있는 거 아니에요?"

요청이 다른 서버로 갈 때마다 로그인 상태를 잃는 구조를 의심하는 말입니다.

페이지덱에서는 그날 이후 앞에 로드 밸런서를 두고 서버 네 대를 뒤에 세웠습니다. 태오가 새 버전을 올릴 때는 한 대씩 빼고 교체하는 방식을 쓰고, 점심시간처럼 사람이 몰리는 구간에는 대수가 자동으로 여섯까지 늘었다가 새벽에 두 대로 줄어듭니다.

로드 밸런서를 두면 서버를 늘리는 만큼 계속 빨라진다고 기대하는 경우가 많습니다. 대수와 처리량이 비례하니 자연스러운 기대입니다. 하지만 늘어나는 것은 요청을 받는 쪽뿐이고, 그 뒤에서 모든 서버가 같은 데이터베이스 한 대를 부르고 있으면 병목은 거기로 옮겨 갑니다. 서버를 4대에서 12대로 늘렸는데 응답 시간이 그대로인 상황이 여기서 나옵니다. 그 상태로 대수만 더 늘리면 데이터베이스에 붙는 연결이 늘어 오히려 전체가 느려집니다. 수평 확장은 어느 서버가 받아도 결과가 같게 만들어져 있을 때만 대수에 비례합니다.

로드 밸런서 자체는 안 죽는다고 여기는 것도 흔합니다. 장애를 막으려고 둔 장치이니 그것만은 튼튼할 것 같지만, 모든 요청이 한 점을 지나가므로 그것이 멈추면 뒤에 선 서버가 전부 멀쩡해도 서비스가 없습니다. 단일 장애점을 없애려다 더 확실한 단일 장애점을 하나 만든 셈입니다. 그래서 실무에서는 이 장치도 두 대 이상 두거나, 사업자가 그 이중화를 책임지는 관리형 제품을 씁니다.