웹서버를 두 대로 늘렸는데도 특정 서버만 바쁘거나, 새로고침할 때마다 로그인이 풀리는 일이 생길 수 있다. 서버를 추가하는 것과 여러 서버가 하나의 서비스처럼 동작하게 만드는 것은 서로 다른 작업이기 때문이다.
로드밸런서는 들어오는 트래픽을 여러 서버에 나누어 전달한다. 하지만 분산 기준, 서버 상태 확인, 세션과 파일 저장 방식이 맞지 않으면 기대한 효과를 얻기 어렵다. 부하 분산 구조를 이해할 때는 요청이 어느 서버로 전달되는지와 함께, 서버가 바뀌어도 같은 서비스를 제공할 수 있는지를 살펴봐야 한다.
로드밸런서는 요청을 처리할 서버를 선택
로드밸런서는 클라이언트가 접속하는 서비스의 진입점에서 요청이나 연결을 받을 서버를 선택한다. 하나의 요청을 모든 서버에 복제하는 장치가 아니라, 정해진 기준에 따라 처리 대상을 결정하는 역할이다.
대표적인 L7 웹서비스 구성에서는 다음과 같이 동작한다.
- 사용자가 서비스 도메인으로 접속한다.
- 로드밸런서가 설정된 프로토콜과 포트로 요청을 받는다.
- 요청에 맞는 전달 규칙과 서버 그룹을 확인한다.
- 분산 알고리즘과 서버 상태를 바탕으로 처리할 서버를 선택한다.
- 선택된 서버가 요청을 처리하고, 로드밸런서를 통해 응답한다.
AWS Application Load Balancer도 리스너, 규칙, 대상 그룹을 바탕으로 요청을 전달한다. 여기서 리스너는 접속을 받는 설정이고, 대상 그룹은 요청을 처리할 서버들의 묶음에 해당한다. [1]
이 흐름은 프록시 방식의 웹서비스를 설명한 것이다. 모든 로드밸런서가 동일한 응답 경로를 사용하는 것은 아니며, 구현에 따라 서버가 클라이언트로 직접 응답하는 방식도 있다.
L4와 L7은 서버를 선택할 때 보는 정보의 차이
L4와 L7의 차이는 단순한 성능 등급이 아니다. 트래픽의 어떤 정보를 바탕으로 전달 대상을 결정하는지가 핵심이다.
| 구분 | L4 로드밸런싱 | L7 로드밸런싱 |
|---|---|---|
| 주요 판단 정보 | IP 주소, 포트, TCP·UDP 등 전송 계층 정보 | HTTP 경로, 호스트, 헤더 등 애플리케이션 정보 |
| 활용 예 | TCP 기반 업무 서비스의 연결 분산 | /api와 /images 요청을 서로 다른 서버 그룹으로 전달 |
| 선택 기준 | 필요한 프로토콜과 연결 처리 특성 | 요청 내용에 따른 세밀한 전달 규칙 |
예를 들어 같은 도메인의 /api 요청은 API 서버로, /images 요청은 이미지 처리 서버로 보내려면 HTTP 경로를 이해하는 L7 기능이 적합하다. 반면 HTTP 경로를 구분할 필요가 없는 TCP 서비스라면 L4 방식부터 검토할 수 있다. Google Cloud 공식 문서도 L4의 네트워크·전송 계층 정보와 L7의 HTTP 헤더·URI 기반 판단을 구분한다. [2]
HTTPS를 사용할 때는 TLS 연결을 어디에서 종료할지도 정해야 한다. 로드밸런서에서 복호화한 뒤 서버로 다시 암호화해 전달할지, 암호화된 연결을 그대로 전달할지에 따라 인증서 관리와 서버 측 설정이 달라진다. 지원 방식은 제품별로 확인해야 한다.
분산 알고리즘은 요청의 특성에 맞춰 선택
요청 수가 같다고 서버 부하까지 같은 것은 아니다. 짧은 조회 요청과 오래 걸리는 파일 생성 요청을 같은 개수로 배분하면 특정 서버에 작업이 쌓일 수 있다.
| 분산 방식 | 동작 원리 | 적용 시 확인할 점 |
|---|---|---|
| 라운드 로빈 | 서버를 순서대로 선택 | 서버 성능과 요청 처리 비용이 비슷한지 확인 |
| 가중치 기반 분산 | 설정한 비중을 선택 과정에 반영 | 가중치가 실제 처리 능력과 맞는지 확인 |
| 최소 연결 | 활성 연결이 적은 서버를 우선 선택 | 연결 수가 실제 작업량을 잘 나타내는지 확인 |
| 해시 기반 분산 | IP 등 지정한 키로 서버를 결정 | 특정 키에 트래픽이 몰릴 가능성 확인 |
NGINX 공식 문서는 라운드 로빈, 최소 연결, IP 해시와 가중치 설정을 설명한다. 다만 지원 알고리즘과 세부 동작은 제품마다 다르므로 이 표의 방식을 모든 로드밸런서에서 그대로 사용할 수 있다고 가정해서는 안 된다. [3]
최소 연결 방식도 CPU 사용률을 직접 비교하는 방식은 아니다. 연결이 적은 서버에서 무거운 작업이 실행 중일 수 있다. 알고리즘 선택 후에는 서버별 요청 수뿐 아니라 응답시간, 오류율, CPU와 작업 대기 상태를 함께 비교하는 편이 좋다.
헬스체크는 서버가 요청을 받을 수 있는지 판단
로드밸런서가 비정상 서버를 계속 선택하면 사용자는 간헐적인 오류를 경험한다. 헬스체크는 이러한 서버를 분산 대상에서 제외하기 위한 판단 근거다.
능동 헬스체크는 별도 점검 요청을 주기적으로 보내고, 수동 헬스체크는 실제 요청 처리 중 발생한 실패를 관찰한다. 어떤 방식을 지원하는지, 실패를 몇 번 확인한 뒤 제외하는지는 제품과 설정에 따라 달라진다.
점검 URL이 항상 성공만 반환하면 애플리케이션이 제대로 동작하지 않아도 정상으로 판단할 수 있다. 반대로 모든 외부 의존성을 지나치게 엄격하게 검사하면 공통 의존성의 일시적인 문제로 서버 전체가 비정상 판정을 받을 수 있다. 점검 항목은 해당 서버를 제외했을 때 서비스가 개선되는지를 기준으로 설계해야 한다.
또한 헬스체크에는 감지 시간이 있으며, 이미 처리 중이던 요청까지 다른 서버에서 자동으로 이어지는 것은 아니다. AWS ALB는 모든 등록 대상이 비정상이면 비정상 대상에도 요청을 보내는 fail-open 동작을 명시한다. 따라서 “비정상 서버에는 어떤 경우에도 요청이 가지 않는다”라고 이해하면 안 된다. [4]
세션과 파일을 서버 내부에만 두면 분산 연산 증가
다음은 가상 예시다. 서버 A와 B가 같은 웹 애플리케이션을 실행하고 있지만, 로그인 세션을 각 서버 메모리에 따로 저장한다고 가정해 보자. A에서 로그인한 사용자의 다음 요청이 B로 전달되면 B는 로그인 상태를 확인하지 못할 수 있다.
특정 사용자를 같은 서버로 보내는 세션 고정 기능은 이 문제를 완화할 수 있다. 하지만 해당 서버가 중단됐을 때 세션 데이터까지 다른 서버로 복구해 주지는 않는다. AWS ALB 문서에서도 세션 고정은 이후 요청을 같은 대상으로 전달하는 기능으로 설명한다. [5]
여러 서버가 같은 서비스를 제공하려면 다음 항목을 점검해야 한다.
- 로그인 상태: 서버가 바뀌어도 세션을 확인할 수 있는가.
- 업로드 파일: A에 저장한 파일을 B에서도 제공할 수 있는가.
- 애플리케이션 설정: 배포 버전, 비밀값, 실행 설정이 일관적인가.
- 데이터베이스: 웹서버 증가에 따른 연결 수와 쿼리 부하를 감당하는가.
공유 저장소나 외부 세션 저장소를 도입하면 서버 간 상태 차이를 줄일 수 있지만, 그 저장소의 장애와 성능도 함께 설계해야 한다. 로드밸런서 자체가 데이터를 동기화하거나 DB 병목을 해결해 주는 것은 아니다.
배포에서는 신규 요청 중단과 기존 요청 종료를 구분
서버를 교체할 때 분산 대상에서 제외하자마자 프로세스를 종료하면 처리 중인 요청이 끊길 수 있다. 신규 요청을 받지 않도록 한 뒤, 기존 요청을 마무리할 시간을 주는 드레이닝 절차가 필요하다.
AWS ALB의 등록 해제 지연도 이러한 처리를 지원한다. 다만 서버가 먼저 연결을 종료하면 오류가 발생할 수 있으므로 로드밸런서 설정과 애플리케이션 종료 동작을 함께 맞춰야 한다. [5]
배포 전환은 다음 순서로 점검할 수 있다.
- 새 서버의 준비 상태와 실제 기능을 확인한다.
- 새 서버를 분산 대상에 포함하고 오류율과 응답시간을 확인한다.
- 기존 서버의 신규 요청 유입을 중단한다.
- 처리 중인 요청이 종료됐는지 확인한 뒤 기존 서버를 종료한다.
오래 유지되는 연결과 대용량 업로드는 별도 종료 정책을 정해야 한다. 실패한 요청을 재시도한다면 주문·결제·등록 작업이 중복 실행되지 않도록 애플리케이션의 중복 처리 방지도 확인해야 한다.
실무에서는 서버 수보다 장애 후 남는 처리 가용성을 확인
가상으로 평상시 전체 요청을 두 서버가 절반씩 처리한다고 해 보자. 한 대가 중단되면 남은 한 대가 전체 요청을 감당해야 한다. 두 대가 있다는 사실만으로 장애 시 서비스 유지가 보장되지는 않는다.
따라서 도입 검토에서는 다음 질문에 답할 수 있어야 한다.
| 확인 질문 | 판단에 필요한 내용 |
|---|---|
| 서버 한 대가 빠져도 처리 가능한가 | 남은 서버의 용량, 응답시간, 오류율 |
| 서버가 바뀌어도 업무가 이어지는가 | 세션, 파일, 데이터 일관성 |
| 비정상을 제대로 감지하는가 | 헬스체크 범위, 감지 지연, 전체 비정상 시 동작 |
| 로드밸런서 자체가 중단되면 어떻게 되는가 | 자체 구축 시 이중화·전환, 관리형 서비스의 가용성 범위 |
| 서버를 늘린 효과가 있는가 | 웹서버와 DB·저장소의 병목 구분 |
실무적인 선택 기준은 분산 기능의 개수보다 서비스가 실패하는 지점을 얼마나 정확히 알고 있는가에 있다. 접속량이 적은 서비스도 배포 중단을 줄이기 위해 로드밸런서를 사용할 수 있고, 접속량이 많은 서비스도 DB가 병목이면 웹서버 추가 효과가 제한될 수 있다.
로드밸런서를 적용할 때는 먼저 분산할 요청과 서버 상태의 기준을 정하고, 세션·파일·DB 구조를 확인해야 한다. 이후 서버 한 대 중단과 배포 전환을 실제로 시험해 보면, 구성도만으로는 드러나지 않는 서비스의 한계를 확인할 수 있다.