로드밸런서가 필요한 시점 판단하는 방법

얼마 전 서버 두 대를 쓰는 사이트에서 장애 문의가 왔다. 두 서버 모두 정상인데 로드밸런서의 상태 확인 경로가 잘못 설정돼 접속이 끊긴 상태였다. 서버를 늘리기 전에 요청이 어디로 들어가고, 어느 단계에서 실패하는지 확인해야 하는 이유다.

서버 한 대로 충분한지 먼저 계산한다

로드밸런서는 들어온 요청을 여러 서버에 나눠 보내고, 문제가 있는 서버를 요청 대상에서 빼는 역할을 한다. 다만 서버 한 대의 처리 능력을 높여 주지는 않는다. 방문자 수만 보고 도입하면 비용은 늘고 장애 지점도 하나 추가된다.

판단 기준은 월 방문자보다 바쁜 시간대의 초당 요청 수와 응답 시간이다. 예를 들어 실제 운영과 비슷한 부하를 걸었을 때 서버 한 대가 초당 50건을 무리 없이 처리한다고 하자. 평소 여유를 두고 대당 30건 안팎으로 운영하려는데 최대 요청이 초당 60건이라면 서버 두 대가 필요하다. 한 대가 빠져도 그 시간대의 요청을 받아야 한다면 세 대를 검토해야 한다. 이 수치는 예시일 뿐이다. 페이지가 캐시에 있는지, 데이터베이스 조회가 몇 번 일어나는지에 따라 결과는 크게 달라진다.

반대로 피크에도 CPU와 메모리에 여유가 있고 응답 시간이 안정적이라면, 작은 VPS 한 대에 백업과 복구 절차를 갖추는 편이 나을 수 있다. 서버를 여러 대 두는 목적이 처리량인지, 장애 때 서비스를 계속 띄워 두는 것인지부터 구분하면 과한 요금제를 피하기 쉽다.

요청을 나누기 전에 공유할 데이터를 찾는다

웹 요청을 두 서버로 번갈아 보내는 것만으로 운영이 끝나지는 않는다. 첫 요청은 A 서버, 다음 요청은 B 서버로 갈 수 있다. 로그인 세션을 A의 로컬 파일에 저장했다면 사용자가 갑자기 로그아웃된 것처럼 보인다. 업로드 파일을 각 서버 디스크에 따로 저장해도 사진이 보였다 안 보였다 한다.

이때 세션은 두 서버가 함께 접근할 수 있는 저장소로 옮기고, 업로드 파일도 공유 저장소에 두거나 배포 구조에 맞게 동기화해야 한다. 특정 사용자를 같은 서버로 보내는 세션 고정 기능은 당장의 증상을 줄일 수 있지만, 해당 서버가 죽었을 때 세션을 잃는 문제까지 해결하지는 못한다.

연결 방식도 서비스에 맞춰 고른다. 웹사이트에서 요청 경로에 따라 서버를 나누거나 TLS 인증서를 로드밸런서에서 처리하려면 HTTP 요청을 이해하는 방식이 편하다. TCP 연결을 그대로 분산하는 방식이 필요한 서비스도 있다. 처음 구축하는 일반적인 웹사이트라면 이름보다 세션, 업로드, 인증서, 실제 방문자 IP가 애플리케이션까지 어떻게 전달되는지 확인하는 일이 더 급하다.

상태 확인은 실제 서비스 흐름에 맞춘다

로드밸런서가 서버를 빼고 다시 넣는 기준은 상태 확인이다. 기본 페이지가 200 응답을 준다고 주문 기능이나 데이터베이스 연결까지 정상이라는 뜻은 아니다. 반대로 상태 확인 경로가 로그인 페이지로 이동하거나 배포 중 잠깐 실패하면 멀쩡한 서버가 요청 대상에서 빠질 수 있다.

가벼운 상태 확인 경로를 따로 두고, 애플리케이션이 요청을 받을 준비가 됐는지 확인하는 편이 좋다. 데이터베이스 장애를 검사에 포함할지는 서비스 구조에 따라 결정해야 한다. 모든 서버가 같은 데이터베이스를 쓰는데 그 연결 문제로 전부 비정상 처리되면 분산할 정상 서버가 남지 않는다. 상태 확인이 모두 실패했을 때 요청을 어떻게 처리하는지도 제품마다 확인해야 한다.

상태 확인 간격을 10초, 연속 실패 횟수를 3회로 잡았다면 장애 감지에 대략 수십 초가 걸릴 수 있다. 실제 시간은 검사 시점과 응답 제한 시간에 따라 달라진다. 값을 지나치게 짧게 잡으면 순간적인 지연에도 서버가 빠졌다 들어왔다를 반복한다. 배포할 때는 새 요청 유입을 멈춘 뒤 진행 중인 요청이 끝날 시간을 주고, 새 서버가 정상 판정을 받은 다음 트래픽을 보내는 순서가 안전하다.

장애와 비용은 로드밸런서 바깥까지 본다

장애가 나면 먼저 로드밸런서가 정상 서버를 몇 대로 보고 있는지 확인한다. 정상 서버가 0대라면 상태 확인 경로, 서버 포트, 접근 규칙, 최근 배포를 본다. 정상 서버가 남아 있는데 502 오류가 늘었다면 서버와의 연결 실패나 응답 제한 시간을 살핀다. 503 오류라면 요청을 보낼 대상이 없는지부터 확인한다. 오류 코드의 의미는 제품 설정에 따라 차이가 있으니 로드밸런서 로그와 애플리케이션 로그의 시각을 맞춰 보는 게 빠르다.

서버 두 대를 같은 물리 호스트에 올리거나 로드밸런서 한 대를 직접 설치해 놓으면 그 장비가 새로운 단일 장애 지점이 된다. 관리형 서비스를 쓰더라도 서버, 데이터베이스, 저장소가 각각 어떤 장애를 견디는지 따로 봐야 한다. 로드밸런서는 백업을 대신하지 않는다. 잘못 삭제한 데이터는 정상 서버 여러 대에 그대로 반영된다.

비용도 서버 대수만 더해서는 안 된다. 로드밸런서 사용료와 처리량 요금, 서버 간 통신, 공유 저장소, 백업 비용까지 월 단위로 계산한다. 트래픽이 작은 사이트라면 한 대의 서버와 검증된 복구 절차가 더 실용적일 때가 많다. 내가 로드밸런서를 권하는 시점은 피크 부하 수치와 한 대가 멈췄을 때의 손실을 확인했고, 세션과 파일을 여러 서버에서 다룰 준비까지 끝났을 때다.