Load Balancer

서버 인스턴스가 한 대뿐이면 성능 병목과 장애 지점이 모두 한곳에 몰립니다. 트래픽이 늘면 그 서버를 키워야 하고, 장애가 나면 서비스 전체가 멈춥니다. 여러 인스턴스를 띄워도 클라이언트가 개별 주소를 알고 직접 선택해야 한다면 배포 때마다 주소를 바꿔야 하고, 죽은 인스턴스로 계속 요청이 가는 문제가 생깁니다. 다수 인스턴스를 운영하는 순간, 요청을 어디로 보낼지 대신 판단해 주는 계층이 필요해집니다.

웹 서비스가 수평 확장을 전제로 설계되기 시작하면서 단일 서버 증설만으로는 버티기 어려운 상황이 많아졌습니다. 클라우드 환경에서는 인스턴스가 자동으로 늘고 줄고 교체되기까지 하므로, 클라이언트가 실제 서버 목록을 따라가는 방식은 현실적이지 않았습니다. 동시에 무중단 배포와 멀티 AZ 운영 같은 요구가 보편화되면서, 현재 살아 있는 인스턴스로만 트래픽을 흘려보내는 전면 계층이 인프라 기본 요소가 됐습니다.

클라이언트 요청이 로드 밸런서에 도착하면, 로드 밸런서는 대상 그룹 안에서 건강한 인스턴스를 고릅니다. 건강 상태는 주기적인 헬스체크로 판단하고, 실패한 인스턴스는 잠시 대상 목록에서 제외합니다. 어떤 로드 밸런서는 네트워크 계층에서 단순 분산만 하고, 어떤 로드 밸런서는 HTTP 헤더나 경로를 보고 더 세밀하게 라우팅하기도 합니다. 핵심은 인스턴스 수와 상태 변화가 있어도 외부 계약은 하나의 주소로 유지된다는 점입니다.

API Gateway와 Load Balancer는 겉으로 비슷해 보여도 질문이 다릅니다. Load Balancer는 같은 역할을 하는 인스턴스 여러 대 중 어디가 이번 요청을 처리할지 정합니다. API Gateway는 이 요청이 어떤 서비스로 가야 하는지와 공통 정책을 어디서 적용할지 정합니다. Service Discovery와도 다릅니다. Discovery가 현재 살아 있는 서비스 위치를 찾게 해 준다면, Load Balancer는 그 후보 중 어느 대상을 선택할지 담당합니다.

웹 API, 내부 서비스, 작업 처리기 풀처럼 동일한 역할의 인스턴스를 여러 대 운영하는 대부분의 환경에서 기본적으로 등장합니다. 특히 무중단 배포, 가용성 영역 분산, 오토스케일링을 쓰는 환경에서는 거의 필수에 가깝습니다. 다만 세션을 서버 메모리에 두는 구조처럼 상태가 인스턴스에 강하게 붙어 있으면 분산만으로는 충분하지 않고, 상태 외부화나 세션 전략을 같이 설계해야 합니다.