ELB 고르는 방법, 처음 쓰는 사람도 헷갈리지 않게
얼마 전 작은 서비스 하나를 AWS에 올리다가 트래픽 분산 설정에서 잠깐 멈춘 적이 있습니다. 서버는 2대로 늘렸는데 사용자가 어느 서버로 들어가야 하는지, 한 서버가 죽으면 어떻게 피해야 하는지 막상 생각하니 꽤 현실적인 문제가 되더라고요. 이럴 때 자주 등장하는 게 ELB입니다.
ELB는 Elastic Load Balancing의 줄임말입니다. 말 그대로 들어오는 요청을 여러 서버나 대상에 나눠 보내는 AWS의 로드 밸런싱 서비스입니다. 그냥 트래픽을 반반 나누는 장치 정도로 생각하기 쉽지만, 실제로는 상태 확인, 장애 대응, HTTPS 처리, 경로별 라우팅 같은 운영 기능까지 같이 맡는 경우가 많습니다.
ELB가 필요한 상황부터 잡기
서버가 1대뿐인 서비스라면 처음에는 ELB가 꼭 필요하지 않을 수도 있습니다. 그런데 서버를 2대 이상으로 늘리는 순간 이야기가 달라집니다. 예를 들어 쇼핑몰 웹 서버가 3대 있고 하루 방문자가 3만 명이라면, 모든 요청이 한 서버로만 몰리면 나머지 서버는 놀고 한 서버만 과부하가 걸릴 수 있습니다.
ELB는 사용자의 요청을 여러 대상으로 나눠 보냅니다. 대상은 EC2 인스턴스일 수도 있고, 컨테이너일 수도 있고, IP 주소나 Lambda일 수도 있습니다. AWS 안내 기준으로 ELB는 등록된 대상의 상태를 확인하고 정상인 대상에만 요청을 보내도록 구성할 수 있습니다. 그래서 한 서버가 장애 상태가 되어도 전체 서비스가 바로 멈추지 않게 만드는 데 큰 역할을 합니다.
- 서버를 여러 대로 운영할 때
- 무중단 배포에 가까운 구조가 필요할 때
- HTTPS 인증서 처리를 한 곳에서 하고 싶을 때
- 특정 경로나 도메인별로 요청을 나누고 싶을 때
- Auto Scaling과 함께 서버 수를 자동으로 늘리고 줄일 때
개인 프로젝트에서는 처음엔 과해 보일 수 있습니다. 근데 실제 서비스를 운영하면 서버 한 대에 모든 걸 맡기는 구조가 생각보다 불안합니다. 배포 한 번, 재시작 한 번에도 사용자가 바로 영향을 받으니까요.
ALB, NLB, GWLB, CLB 차이 구분하는 방법
ELB를 검색하면 ALB, NLB 같은 이름이 같이 나옵니다. 여기서 많이 헷갈립니다. ELB는 큰 서비스 이름이고, 그 안에 여러 종류의 로드 밸런서가 있다고 보면 됩니다. 현재 AWS에서 주로 이야기하는 유형은 Application Load Balancer, Network Load Balancer, Gateway Load Balancer, Classic Load Balancer입니다.
ALB는 웹 서비스에 가장 자주 쓰입니다
ALB는 HTTP와 HTTPS 트래픽에 잘 맞습니다. 웹사이트, API 서버, 관리자 페이지처럼 브라우저나 앱에서 요청을 보내는 일반적인 서비스라면 대개 ALB부터 검토하면 됩니다. 경로 기반 라우팅도 가능합니다. 예를 들어 같은 도메인에서 /api 요청은 API 서버로, /admin 요청은 관리자 서버로 보내는 식입니다.
실제 운영에서는 ALB 앞에 도메인을 붙이고, ALB에서 HTTPS 인증서를 처리한 뒤, 뒤쪽 서버에는 HTTP로 넘기는 구성을 자주 씁니다. 서버마다 인증서를 따로 관리하지 않아도 돼서 운영이 단순해집니다.
NLB는 속도와 네트워크 계층이 중요할 때 씁니다
NLB는 TCP, UDP, TLS 같은 네트워크 계층 트래픽에 맞습니다. 지연 시간이 낮아야 하거나, 매우 많은 연결을 안정적으로 받아야 하는 서비스에 어울립니다. 게임 서버, 실시간 통신, 프록시, 특정 포트를 그대로 열어야 하는 구조에서 자주 후보가 됩니다.
ALB가 요청의 내용까지 보고 똑똑하게 분기하는 쪽이라면, NLB는 더 낮은 계층에서 빠르게 연결을 넘기는 쪽에 가깝습니다. 그래서 단순 웹 API라면 ALB가 편하고, 특정 프로토콜이나 고성능 네트워크 처리가 중요하면 NLB가 더 자연스럽습니다.
GWLB와 CLB는 목적이 다릅니다
GWLB는 방화벽, 침입 탐지, 패킷 검사 같은 가상 네트워크 장비를 배치할 때 쓰는 유형입니다. 일반 웹 서비스를 처음 띄우는 사람이 바로 선택할 일은 많지 않습니다. 네트워크 보안 장비를 여러 대로 늘리고, 그 장비들 사이로 트래픽을 안정적으로 흘려보내야 할 때 어울립니다.
CLB는 이전 세대 로드 밸런서입니다. 기존 시스템에서 이미 쓰고 있다면 유지할 수 있지만, 새로 만든다면 보통 ALB나 NLB를 먼저 봅니다. AWS 문서에서도 기존 CLB는 현재 세대 로드 밸런서로 이전하는 방향을 안내합니다.
초보자가 선택할 때 보는 기준
처음부터 모든 기능을 외울 필요는 없습니다. 내가 다루는 트래픽이 무엇인지 먼저 보면 됩니다. 웹사이트나 REST API라면 ALB, TCP나 UDP 포트 기반 서비스라면 NLB, 보안 장비 트래픽 분산이라면 GWLB로 좁힐 수 있습니다.
- 일반 웹사이트: ALB
- HTTPS API 서버: ALB
- 경로별 서비스 분기: ALB
- TCP 기반 서버: NLB
- UDP가 필요한 서비스: NLB
- 보안 appliance 분산: GWLB
- 기존 오래된 구성 유지: CLB 검토
비용도 같이 봐야 합니다. ELB는 켜두기만 해도 시간 기준 비용이 생기고, 처리량이나 규칙 평가량에 따라 추가 비용이 붙을 수 있습니다. 테스트용으로 잠깐 만든 로드 밸런서를 잊고 방치하면 생각보다 아까운 비용이 나옵니다. 특히 공부용 계정에서는 사용하지 않는 ELB, 대상 그룹, 고정 IP, NAT Gateway까지 같이 확인하는 습관이 필요합니다.
설정할 때 자주 놓치는 부분
ELB를 만들었다고 바로 끝나는 건 아닙니다. 가장 먼저 봐야 할 건 대상 그룹의 상태 확인입니다. Health check 경로가 잘못되어 있으면 서버는 정상인데 ELB는 비정상으로 판단할 수 있습니다. 예를 들어 애플리케이션의 실제 상태 확인 주소가 /health인데 ELB에는 /로 설정해두면, 로그인 리다이렉트나 권한 문제 때문에 실패할 수 있습니다.
보안 그룹도 자주 막힙니다. 사용자는 ALB의 443 포트로 들어오고, ALB는 뒤쪽 EC2의 8080 포트로 보내는 구조라면 EC2 보안 그룹에서 ALB 보안 그룹을 허용해야 합니다. 전체 인터넷을 EC2에 바로 열 필요는 없습니다. 이렇게 하면 외부 사용자는 ALB만 보고, 실제 서버는 ALB를 통해 들어오는 요청만 받게 만들 수 있습니다.
가용 영역도 확인해야 합니다. 서버가 2개인데 둘 다 같은 가용 영역에 있으면 장애 대응 효과가 줄어듭니다. 가능하면 서로 다른 가용 영역에 대상을 나눠 두는 편이 좋습니다. 로드 밸런서의 장점은 트래픽 분산뿐 아니라 장애 범위를 줄이는 데도 있으니까요.
- Health check 경로와 응답 코드 확인
- ALB와 EC2 보안 그룹 연결 확인
- HTTPS 인증서 연결 확인
- 대상 그룹에 정상 대상이 등록됐는지 확인
- 여러 가용 영역에 대상이 분산됐는지 확인
작게 시작해서 운영 기준을 잡기
처음 ELB를 붙일 때는 너무 복잡한 구조보다 단순한 ALB 하나와 서버 2대 구성으로 시작하는 편이 이해하기 쉽습니다. 그 다음 로그를 보고, 응답 시간이 어느 정도인지, 특정 서버에만 에러가 나는지, 배포 중 요청 실패가 있는지 확인하면 됩니다.
사실 ELB는 한 번 제대로 이해해두면 AWS 구조를 보는 눈이 꽤 달라집니다. 사용자는 로드 밸런서로 들어오고, 로드 밸런서는 정상 서버를 골라 요청을 넘기고, 서버 수는 Auto Scaling으로 조절하는 흐름이 보이기 시작합니다. 작은 블로그나 사이드 프로젝트에는 단순한 구성이 충분하지만, 트래픽이 늘어날 가능성이 있는 서비스라면 초기에 ALB 기준으로 구조를 잡아두는 게 나중에 훨씬 편합니다.
