Azure Load Balancer

VM을 여러 대 두기로 했는데, 사용자는 어느 서버로 접속해야 할지 알 수 없습니다. IP 주소를 직접 나눠줄 수도 없고, DNS 라운드 로빈으로 나눠봐도 특정 VM이 응답을 멈추면 그쪽으로 계속 요청이 들어옵니다. 서버를 추가할수록 트래픽이 어떻게 분산되는지 통제를 잃게 됩니다. 고가용성을 위해 서버를 여러 대 두는 것과, 트래픽을 실제로 고르게 나눠주는 것은 별개의 문제입니다.

서비스 규모가 커지면 수직 확장(서버 사양 업그레이드)에는 금방 한계가 옵니다. 수평 확장으로 방향을 틀면 트래픽을 나누는 문제가 따라옵니다. 온프레미스에서는 전용 하드웨어 장비를 앞에 놓았는데, 비용이 크고 장비 추가에 수주가 걸렸습니다. 클라우드에서는 VM을 분 단위로 늘리고 줄일 수 있게 됐지만, 그 앞에서 트래픽을 분산하고 장애를 감지하는 장치도 같은 속도로 따라와야 했습니다. VM 개수가 바뀔 때마다 구성을 자동으로 반영하는 소프트웨어 기반 분산 장치가 필요해진 것은 이런 운영 속도의 압력 때문입니다.

프런트엔드 IP는 사용자가 접속하는 단일 주소입니다. 그 뒤에 백엔드 풀이 있고, 실제 요청을 처리하는 VM들이 여기에 속합니다. 부하 분산 규칙이 프런트엔드 특정 포트로 들어온 트래픽을 백엔드 풀의 어떤 포트로 보낼지를 정의합니다. 핵심은 헬스 프로브입니다. 15초마다 각 VM에 TCP 연결이나 HTTP 요청을 보내 응답 여부를 확인합니다. 응답하지 않는 VM은 자동으로 풀에서 제외되고, 복구되면 다시 포함됩니다. 분산 알고리즘은 기본적으로 5-tuple 해시(소스 IP, 소스 포트, 목적지 IP, 목적지 포트, 프로토콜)를 사용하므로, 같은 클라이언트의 요청이 같은 VM으로 흘러가면서도 전체적으로는 고르게 분산됩니다. L4에서 동작하기 때문에 HTTP 헤더나 URL 경로는 보지 않고, 패킷 수준에서 전달만 합니다.

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

VM 여러 대를 묶어 고가용성을 구성하는 팀이라면 Load Balancer가 그 앞에 놓이는 표준 구성입니다. 퍼블릭 로드 밸런서는 인터넷 트래픽을 받아 VM 그룹에 분산하고, 내부 로드 밸런서는 VNet 안에서 프런트엔드 서비스가 여러 백엔드 API 서버에 요청을 나눌 때 씁니다. 가용 영역을 걸쳐 백엔드를 배치하면 특정 데이터센터 장애에도 서비스가 유지됩니다. VM 한 대가 다운됐는데 사용자 요청이 계속 들어온다는 상황이 반복된다면, 헬스 프로브 설정과 풀 구성을 먼저 확인해야 합니다. URL 라우팅이나 SSL 처리, 웹 방화벽이 필요한 경우, 또는 여러 리전에 걸친 글로벌 분산이 필요한 경우에는 Load Balancer만으로는 부족합니다.