Azure Load Balancer

서버 한 대로 서비스를 운영하면, 그 서버가 죽는 순간 모든 사용자가 접속할 수 없습니다. 트래픽이 늘어나면 한 대로 감당할 수 없어 서버를 추가하지만, 사용자가 여러 서버의 IP를 직접 골라 접속할 수는 없습니다. DNS 라운드 로빈으로 나누더라도 장애 서버를 바로 빼지 못하고, 특정 서버에 요청이 몰리는 문제도 해결되지 않습니다. 결국 '사용자는 하나의 주소로 접속하되, 뒤에 있는 여러 서버에 요청을 알아서 나눠주고, 고장난 서버는 자동으로 빼주는 무언가'가 필요합니다. 이 역할을 하는 것이 로드 밸런서입니다.

서비스 초기에는 서버 한 대로 충분하지만, 사용자가 늘면 수직 확장(더 좋은 서버)에는 한계가 옵니다. 수평 확장(서버를 더 추가)으로 방향을 틀면 트래픽을 나누는 문제가 바로 따라옵니다. 온프레미스에서는 하드웨어 로드 밸런서(F5, Citrix 등)를 사들여 앞에 놓았는데, 비용이 크고 설정 변경에 시간이 걸렸습니다. 클라우드에서는 VM을 분 단위로 늘리고 줄일 수 있게 됐지만, 그 앞에서 트래픽을 분산하고 장애를 감지하는 장치도 같은 속도로 따라와야 했습니다. 하드웨어를 사지 않고도, VM 개수가 바뀔 때마다 자동으로 반영되는 소프트웨어 기반 로드 밸런서가 필요해진 것은 이런 운영 속도의 압력 때문입니다.

Azure Load Balancer는 프런트엔드 IP, 백엔드 풀, 부하 분산 규칙, 헬스 프로브의 네 가지 요소로 동작합니다. 프런트엔드 IP는 사용자가 접속하는 단일 진입점이고, 백엔드 풀은 실제 요청을 처리하는 VM 그룹입니다. 부하 분산 규칙은 프런트엔드의 특정 포트로 들어온 트래픽을 백엔드 풀의 어떤 포트로 보낼지를 정의합니다. 핵심 메커니즘은 헬스 프로브입니다. 로드 밸런서는 설정된 간격(예: 15초)마다 각 VM에 TCP 연결이나 HTTP 요청을 보내 응답 여부를 확인합니다. 응답하지 않는 VM은 백엔드 풀에서 제외되고, 복구되면 다시 포함됩니다. 분산 알고리즘은 기본적으로 5-tuple 해시(소스 IP, 소스 포트, 목적지 IP, 목적지 포트, 프로토콜)를 사용해 같은 세션의 패킷이 같은 VM으로 갈 확률을 높이되, 전체적으로 고르게 분산합니다. L4에서 동작하므로 HTTP 헤더나 URL 경로를 보지 않고, 순수하게 네트워크 계층에서 패킷을 전달합니다.

Azure Load Balancer와 Application Gateway는 둘 다 트래픽을 여러 백엔드에 나눈다는 점에서 같지만, 동작하는 계층이 다릅니다. Load Balancer는 L4(TCP/UDP)에서 패킷을 전달하므로 빠르고 프로토콜에 구애받지 않지만, HTTP 헤더나 URL 경로를 기준으로 분산하지는 못합니다. Application Gateway는 L7(HTTP/HTTPS)에서 동작해 경로 기반 라우팅, SSL 종료, WAF 같은 기능을 제공하지만 그만큼 처리 오버헤드가 있습니다. 단순히 여러 VM에 TCP/UDP 트래픽을 나누고 장애 VM을 빼는 것이 목적이면 Load Balancer가 맞고, URL 패턴이나 호스트 이름에 따라 서로 다른 백엔드로 보내야 하거나 웹 애플리케이션 방화벽이 필요하면 L7 수준의 분산이 더 적합합니다.

Azure Load Balancer는 서버 풀 앞에 단일 진입점을 두고 트래픽을 나눠야 하는 가장 기본적인 고가용성 구성에 쓰입니다. 백엔드 그룹 앞에 퍼블릭 로드 밸런서를 놓으면 트래픽 분산과 장애 감지가 자동으로 동작하고, 내부 로드 밸런서는 사설 네트워크 안에서 프런트엔드 서비스가 여러 백엔드 API 서버에 요청을 나눌 때 자주 사용됩니다. 가용 영역을 걸쳐 백엔드를 배치하면 특정 데이터센터 장애에도 서비스가 유지됩니다. 다만 Load Balancer는 L4에서 동작하므로 URL 기반 라우팅이나 SSL 종료, 웹 방화벽이 필요한 경우에는 적합하지 않습니다. 또한 여러 리전에 걸친 글로벌 분산이 필요할 때도 단일 리전 안에서만 동작하는 Load Balancer만으로는 부족합니다.

다음에 볼 개념

함께 보면 좋은 개념