Elastic Load Balancing

EC2나 컨테이너를 여러 대 띄웠는데 사용자는 한 주소만 알아야 하고, 장애 난 대상은 자동으로 빼야 합니다. 이 분산 규칙을 애플리케이션마다 직접 넣기 시작하면 배포가 늘수록 운영이 불안정해집니다.

클라우드 이전에도 로드 밸런싱은 필요했습니다. Nginx나 HAProxy를 직접 설치해서 프록시로 쓰는 팀이 많았습니다. 하지만 이 방식에는 운영 부담이 따랐습니다. 서버를 늘릴 때마다 설정 파일에 새 백엔드 주소를 추가하고 리로드해야 했고, 헬스 체크 스크립트를 직접 작성해서 죽은 서버를 빼는 로직도 관리해야 했습니다. 헬스 체크가 미흡하면 장애 난 서버로 요청이 계속 가고, SSL 인증서 갱신이나 세션 고정 같은 기능도 별도로 챙겨야 했습니다. 로드 밸런서 자체가 단일 장애점이 되지 않도록 이중화하는 것까지 신경 쓰면 애플리케이션 개발보다 인프라 운영에 시간이 더 들었습니다. Auto Scaling으로 인스턴스가 수시로 생기고 사라지는 클라우드 환경에서는 이 수동 방식이 더 이상 버틸 수 없었고, 분산과 헬스 체크를 관리형으로 제공하는 ELB가 기본 인그레스 계층이 됐습니다.

ELB는 크게 리스너(Listener)와 타깃 그룹(Target Group) 두 축으로 동작합니다. 리스너는 로드 밸런서가 어떤 포트와 프로토콜로 요청을 받을지 정의합니다. 예를 들어 HTTPS 443 포트로 들어오는 요청을 받겠다고 선언하는 것이 리스너입니다. 타깃 그룹은 요청을 실제로 처리할 대상(EC2, ECS 태스크, IP 등)의 묶음입니다. 리스너가 요청을 받으면 규칙에 따라 어떤 타깃 그룹으로 보낼지 결정합니다. 타깃 그룹 안에서 ELB는 주기적으로 헬스 체크를 돌려 비정상 대상을 자동으로 제외합니다. 서비스 성격에 따라 형태를 고릅니다. ALB는 HTTP/HTTPS 요청을 해석해서 경로, 호스트, 헤더 기반으로 라우팅하고, NLB는 TCP/UDP 패킷을 해석 없이 전달해 초저지연을 제공합니다. GWLB는 방화벽이나 IDS 같은 네트워크 어플라이언스를 투명하게 끼워 넣을 때 씁니다.

ELB와 API Gateway는 둘 다 요청 앞단에 서지만 목적이 다릅니다. ELB는 살아 있는 서버나 태스크로 트래픽을 분산하고 고가용성을 만드는 데 강하고, API Gateway는 인증·스로틀링·API 정책 관리에 강합니다. 서버 풀로 요청을 안정적으로 나누는 게 핵심이면 ELB를 보고, 공개 API를 제품처럼 운영하는 게 핵심이면 API Gateway를 보면 됩니다.

EC2 인스턴스 여러 대에 웹 애플리케이션을 배포했다면, ALB를 앞에 두고 타깃 그룹에 인스턴스들을 등록합니다. Auto Scaling 그룹과 연결하면 인스턴스가 늘거나 줄 때 자동으로 타깃 그룹에 반영됩니다. 운영자가 설정 파일을 수정할 필요가 없습니다. 마이크로서비스 아키텍처에서는 ALB의 경로 기반 라우팅이 유용합니다. /api/users는 사용자 서비스 타깃 그룹으로, /api/orders는 주문 서비스 타깃 그룹으로 보내는 식입니다. 하나의 ALB로 여러 서비스를 묶을 수 있습니다. TCP 수준의 초저지연이 필요한 게임 서버나 금융 거래 시스템에는 NLB가 적합합니다. HTTP 해석 없이 패킷을 전달하므로 지연이 훨씬 짧습니다. 다만, 요청 내용을 기반으로 인증이나 스로틀링을 하는 용도에는 맞지 않습니다.