로드 밸런싱은 여러 서버에 요청을 나누어 처리하게 하는 방식이다. 단일 서버에 작업이 집중되는 것을 줄이고 일부 대상의 장애에 대응하는 데 활용한다. 분배 정책, 서버 상태 확인, 애플리케이션의 세션 설계가 함께 맞아야 기대한 효과를 얻는다. NGINX HTTP 로드 밸런싱
분배 정책의 차이
NGINX의 HTTP 로드 밸런싱 문서는 라운드 로빈, 최소 연결, IP 해시 같은 방식을 설명한다. 서버에 가중치를 두면 같은 비율 대신 처리 능력에 맞춘 분배를 구성할 수 있다.
| 방식 | 분배 기준 |
|---|---|
| 라운드 로빈 | 대상 서버를 순서대로 선택 |
| 최소 연결 | 활성 연결 수를 고려 |
| IP 해시 | 클라이언트 주소를 이용한 대응 |
연결 수가 적다고 CPU 사용량이나 응답 시간이 반드시 낮은 것은 아니다. 알고리즘을 선택할 때 요청 길이와 작업 특성도 살펴야 한다. NGINX upstream 모듈
위키 서버 두 대의 예
문서 조회 서버 A와 B가 같은 데이터 원본을 읽도록 구성하면 프록시가 두 서버에 요청을 분배할 수 있다. 그러나 로그인 정보를 A의 메모리에만 저장하면 다음 요청이 B로 갈 때 사용자가 로그아웃된 것처럼 보일 수 있다. 공유 세션 저장소나 검증 가능한 인증 구조 등을 별도로 고려한다.
실패한 서버의 처리
실패 횟수와 시간 구간에 따른 대상 제외 정책을 설정할 수 있지만, 실제 지원 방식은 제품과 구성에 따라 다르다. 포트가 열렸다는 확인과 정상적인 문서 조회가 된다는 확인도 다르다. 관측 가능성을 통해 대상별 오류율과 지연을 함께 살피는 것이 유용하다.
확장과 복제의 구분
로드 밸런서는 데이터베이스의 내용을 자동으로 복제하지 않는다. 읽기 서버를 늘려도 저장 계층이 병목이면 전체 처리량이 제한된다. 데이터베이스 복제와 별도로 설계해야 한다. 또한 로드 밸런서 자체가 하나의 장애 지점이 될 수 있으므로 진입점의 가용성까지 확인한다. 리버스 프록시와 결합할 수 있지만 두 용어가 항상 같은 기능을 뜻하지는 않는다.