ELB 처음 설정하는 방법: 트래픽 분산을 쉽게 잡는 AWS 로드 밸런서 입문

얼마 전 작은 웹 서비스를 AWS에 올리다가 서버 한 대로는 불안하다는 느낌을 받았습니다. 평소에는 접속자가 20명도 안 되는데, 이벤트 안내 문자를 보내는 순간 요청이 확 늘더라고요. 이럴 때 서버를 여러 대로 늘리는 것만큼 중요한 게 바로 ELB입니다.

ELB는 Elastic Load Balancing의 줄임말입니다. 쉽게 말하면 사용자 요청을 여러 서버로 나눠 보내는 문지기 같은 역할을 합니다. 서버 한 대가 바쁘거나 문제가 생기면 다른 서버로 요청을 보내주기 때문에 서비스가 갑자기 멈출 가능성을 줄일 수 있습니다.

ELB가 필요한 상황부터 잡기

서버가 한 대뿐이면 구조가 단순합니다. 사용자가 접속하면 그 서버가 모든 요청을 처리하죠. 그런데 접속자가 늘거나 배포 중 오류가 생기면 서비스 전체가 흔들릴 수 있습니다. 예를 들어 웹 서버 1대가 초당 100건의 요청을 버틸 수 있는데, 순간적으로 250건이 들어오면 지연이 생기거나 일부 요청이 실패할 수 있습니다.

이때 같은 성능의 서버를 3대로 늘리고 ELB 앞에 세우면 요청을 나눠 처리할 수 있습니다. 단순 계산으로는 초당 300건까지 여유가 생깁니다. 물론 실제로는 DB, 캐시, 네트워크 병목도 같이 봐야 하지만, 웹 서버 쪽 부담을 줄이는 첫 단계로는 꽤 효과적입니다.

• 접속자가 시간대별로 크게 변하는 서비스
• 장애가 나도 서비스가 바로 끊기면 곤란한 서비스
• 무중단 배포나 점진적 배포를 하고 싶은 경우
• HTTPS 인증서 관리를 서버마다 하기 번거로운 경우

ELB 종류를 고르는 방법

AWS에서 주로 쓰는 ELB는 Application Load Balancer, Network Load Balancer, Gateway Load Balancer로 나뉩니다. 이름만 보면 복잡하지만, 웹 서비스를 운영한다면 대부분 Application Load Balancer부터 떠올리면 됩니다.

Application Load Balancer

ALB는 HTTP와 HTTPS 트래픽에 잘 맞습니다. 쇼핑몰, 블로그, API 서버, 관리자 페이지처럼 브라우저나 앱에서 접속하는 서비스에 많이 씁니다. 경로 기반 라우팅도 가능해서 같은 도메인 안에서 /api는 API 서버로, /admin은 관리자 서버로 보내는 식의 구성이 됩니다.

Network Load Balancer

NLB는 TCP, UDP처럼 더 낮은 계층의 트래픽을 빠르게 처리할 때 어울립니다. 지연 시간이 민감하거나 아주 많은 연결을 다루는 서비스에서 자주 선택합니다. 게임 서버, 실시간 통신, 고성능 네트워크 서비스라면 후보에 올릴 만합니다.

Gateway Load Balancer

GWLB는 보안 장비나 네트워크 가상 어플라이언스를 통과시키는 용도에 가깝습니다. 일반적인 웹 서비스 초보 단계에서는 바로 만질 일이 많지 않습니다. 회사 네트워크 보안 구조를 설계할 때 더 자주 등장합니다.

기본 구성은 이렇게 생각하면 쉽습니다

ELB를 설정할 때는 크게 네 가지를 보면 됩니다. 리스너, 대상 그룹, 헬스 체크, 보안 그룹입니다. 처음에는 용어가 낯설지만 한 번 연결해 보면 구조가 꽤 단순합니다.

리스너는 ELB가 어떤 포트로 요청을 받을지 정하는 설정입니다. 예를 들어 사용자가 HTTPS로 접속한다면 443 포트 리스너를 둡니다. 대상 그룹은 ELB가 요청을 넘겨줄 서버 묶음입니다. EC2 인스턴스 2대나 3대를 하나의 대상 그룹에 넣는 식입니다.

헬스 체크는 서버가 정상인지 확인하는 장치입니다. ALB가 일정 간격으로 특정 경로를 호출해 보고, 응답이 정상일 때만 트래픽을 보냅니다. 보통 /health 같은 경로를 만들어 두고 200 응답을 주게 만듭니다. 실제 서비스 화면 대신 가벼운 확인용 경로를 쓰는 편이 관리하기 좋습니다.

• 리스너: 외부 요청을 받는 포트와 프로토콜
• 대상 그룹: 트래픽을 전달받을 서버 묶음
• 헬스 체크: 서버 정상 여부 확인
• 보안 그룹: 어떤 트래픽을 허용할지 정하는 방화벽 역할

초보자가 자주 막히는 설정

가장 흔한 실수는 보안 그룹입니다. ELB에는 80 또는 443 포트를 열어두고, EC2 서버에는 ELB에서 들어오는 포트만 허용하는 식으로 잡는 게 일반적입니다. 서버를 인터넷 전체에 직접 열어두면 관리가 쉬워 보이지만, 운영 단계에서는 불필요한 노출이 됩니다.

두 번째는 헬스 체크 실패입니다. 서버는 멀쩡히 떠 있는데 대상 그룹에서 unhealthy로 보이는 경우가 있습니다. 이때는 헬스 체크 경로가 실제로 존재하는지, 응답 코드가 허용 범위에 들어가는지, 서버 포트가 대상 그룹 포트와 맞는지 확인해야 합니다. 특히 앱은 3000번 포트에서 뜨는데 대상 그룹은 80번 포트를 보고 있으면 계속 실패합니다.

세 번째는 HTTPS 인증서입니다. AWS Certificate Manager에서 인증서를 발급받고 ALB 리스너에 연결하면, 개별 서버에 인증서를 하나씩 설치하지 않아도 됩니다. 운영해 보면 이 차이가 꽤 큽니다. 인증서 갱신이나 서버 교체 때 손이 덜 갑니다.

운영할 때 같이 챙기면 좋은 것

ELB를 붙였다고 끝은 아닙니다. CloudWatch 지표를 같이 봐야 실제로 잘 동작하는지 알 수 있습니다. 예를 들어 대상 응답 시간, 4xx 오류, 5xx 오류, 정상 대상 수 같은 지표를 보면 장애 징후를 빨리 잡을 수 있습니다.

비용도 미리 감을 잡아두는 게 좋습니다. ELB는 사용 시간과 처리량 기준으로 비용이 붙습니다. 작은 개인 프로젝트라면 부담이 크지 않을 수 있지만, 트래픽이 많거나 여러 환경에 로드 밸런서를 많이 만들면 생각보다 비용이 쌓입니다. 개발, 스테이징, 운영 환경을 나눠 쓰는 팀이라면 안 쓰는 리소스를 방치하지 않는 습관이 중요합니다.

실무에서는 처음부터 복잡하게 만들기보다 ALB 하나, 대상 그룹 하나, EC2 두 대 정도로 시작하는 구성이 가장 배우기 쉽습니다. 그다음 HTTPS, 오토 스케일링, 경로 기반 라우팅을 차례로 붙이면 구조가 자연스럽게 보입니다. ELB는 어렵게 느껴지는 이름과 달리, 서버가 혼자 버티지 않게 해주는 기본 체력 장치에 가깝습니다. 작은 서비스라도 사용자에게 끊기지 않는 경험을 주고 싶다면 꽤 빨리 익혀둘 만한 기능이라고 생각합니다.