얼마 전 작은 이벤트 페이지를 운영하는 지인과 이야기했는데, 평소엔 조용하던 서버가 광고를 한 번 돌리자마자 접속 지연을 겪었다고 하더라고요. 서버 한 대로 버티던 구조라 접속자가 몰리는 순간 요청이 한곳에 쌓인 겁니다. 이럴 때 자주 등장하는 AWS 서비스가 바로 ELB입니다.
ELB는 Elastic Load Balancing의 줄임말로, 여러 서버 앞에서 들어오는 요청을 나눠주는 역할을 합니다. 쉽게 말하면 식당 입구에서 손님을 빈 자리로 안내하는 직원 같은 존재예요. 서버가 2대, 3대, 10대로 늘어나도 사용자는 보통 하나의 접속 지점만 보게 되고, ELB가 뒤에서 적절히 분산해줍니다.
ELB가 필요한 상황부터 잡기
처음부터 모든 서비스에 ELB가 꼭 필요한 건 아닙니다. 개인 블로그처럼 방문자가 적고 서버 한 대로 충분한 경우라면 오히려 비용과 설정만 늘어날 수 있어요. 그런데 서비스가 로그인, 결제, 예약, 이벤트 신청처럼 순간 트래픽에 민감하다면 이야기가 달라집니다.
예를 들어 하루 평균 방문자가 1천 명이어도 특정 시간에 500명이 동시에 접속하면 서버 체감 부하는 훨씬 커집니다. CPU 사용률이 80%를 넘나들고 응답 시간이 3초, 5초로 늘어나면 사용자는 금방 이탈합니다. ELB는 이런 상황에서 요청을 여러 대상으로 나눠 한 서버에 부담이 몰리는 일을 줄여줍니다.
- 서버를 2대 이상 운영할 계획이 있다
- 점검 중에도 서비스를 계속 열어두고 싶다
- 트래픽이 특정 시간에 몰린다
- HTTPS 인증서 관리를 한곳에서 하고 싶다
- 장애 난 서버로 요청이 가지 않게 하고 싶다
ELB 종류는 용도에 맞춰 고르기
ELB라고 부르지만 실제로는 몇 가지 유형이 있습니다. 초보자가 가장 많이 만나는 건 ALB와 NLB입니다. 이름이 비슷해서 헷갈리지만 쓰임새는 꽤 다릅니다.
ALB는 웹 서비스에 가장 익숙한 선택
ALB는 Application Load Balancer입니다. 웹사이트, API 서버, 관리자 페이지처럼 HTTP와 HTTPS 기반 서비스에 잘 맞습니다. 주소 경로나 호스트 이름에 따라 요청을 다른 서버 그룹으로 보낼 수 있어서 운영하기 편합니다.
예를 들어 같은 도메인 안에서 사용자 화면은 프론트 서버로, API 요청은 백엔드 서버로 보내는 식의 구성이 가능합니다. 물론 본문에는 외부 주소를 적지 않겠지만, 실제 설정에서는 경로가 /api로 시작하는 요청만 별도 대상 그룹으로 보내는 식으로 자주 씁니다.
NLB는 빠른 처리와 고정적인 네트워크 구성이 필요할 때
NLB는 Network Load Balancer입니다. 대량 연결, 낮은 지연 시간, TCP 기반 서비스가 중요할 때 많이 씁니다. 게임 서버, 실시간 처리, 내부 시스템 연동처럼 네트워크 성능이 민감한 경우에 어울립니다.
일반적인 쇼핑몰이나 회사 홈페이지라면 ALB부터 검토하는 경우가 많습니다. 반대로 초당 연결 수가 매우 많거나 L4 계층 처리가 필요한 구조라면 NLB가 더 자연스럽습니다. 둘 중 무엇이 더 좋다기보다, 요청을 어느 수준에서 나눌지에 따라 선택이 갈립니다.
기본 구성은 리스너, 대상 그룹, 헬스 체크
ELB 설정 화면에 들어가면 낯선 단어가 몇 개 나옵니다. 처음엔 복잡해 보여도 구조는 단순합니다. 들어오는 문을 만들고, 요청을 보낼 서버 묶음을 지정하고, 서버가 살아 있는지 확인하는 흐름입니다.
- 리스너: 80번이나 443번처럼 ELB가 요청을 받는 입구
- 대상 그룹: 요청을 전달할 EC2, 컨테이너, IP 등의 묶음
- 헬스 체크: 서버가 정상 응답하는지 주기적으로 확인하는 검사
- 보안 그룹: 어떤 포트와 IP에서 접근을 허용할지 정하는 방화벽 역할
여기서 헬스 체크가 꽤 중요합니다. 서버 프로세스는 떠 있지만 데이터베이스 연결이 끊겨 실제 요청은 실패하는 경우가 있거든요. 그래서 단순히 서버가 켜져 있는지만 볼 게 아니라, 서비스가 정상 동작할 때만 200 응답을 주는 확인용 경로를 따로 두는 편이 좋습니다.
예를 들어 헬스 체크 간격을 30초로 두고, 2번 연속 실패하면 비정상으로 판단하게 만들 수 있습니다. 그러면 장애가 난 서버로 요청이 계속 들어가는 일을 줄일 수 있습니다. 근데 너무 짧게 잡으면 일시적인 지연에도 서버가 빠졌다 들어왔다 하면서 오히려 불안정해질 수 있으니 서비스 성격에 맞게 잡는 게 좋습니다.
실제 설정할 때 자주 놓치는 부분
ELB를 만들었다고 바로 안정적인 구조가 되는 건 아닙니다. 특히 보안 그룹 연결을 잘못해놓고 왜 접속이 안 되는지 한참 찾는 일이 흔합니다. ELB에는 외부 사용자가 접근할 포트를 열고, 뒤쪽 서버는 ELB에서 들어오는 트래픽만 받게 만드는 구성이 기본입니다.
HTTPS도 많이 헷갈립니다. 보통 인증서는 ELB에 연결하고, 사용자와 ELB 사이를 HTTPS로 암호화합니다. 그 뒤 ELB에서 서버까지도 HTTPS로 유지할지, 내부 구간은 HTTP로 둘지는 보안 기준과 운영 편의에 따라 결정합니다. 개인정보나 결제처럼 민감한 데이터가 오간다면 내부 구간 암호화도 함께 검토하는 편이 낫습니다.
비용도 현실적으로 봐야 합니다. ELB는 사용 시간과 처리량에 따라 요금이 붙습니다. 트래픽이 적은 테스트 환경을 여러 개 켜두면 생각보다 비용이 새는 경우가 있습니다. 개발용, 스테이징용, 운영용을 모두 만들 때는 꼭 필요한 환경인지 한 번 더 확인하는 습관이 좋습니다.
- 대상 서버의 보안 그룹이 ELB 트래픽을 허용하는지 확인
- 헬스 체크 경로가 실제 서비스 상태를 반영하는지 확인
- HTTPS 인증서 만료와 갱신 방식을 확인
- 서버 로그와 ELB 접근 로그를 함께 볼 수 있게 준비
- 테스트용 ELB를 방치하지 않도록 운영 기준 마련
처음 구축한다면 작게 시작하는 편이 편하다
처음부터 복잡한 멀티 리전 구조를 만들 필요는 없습니다. 보통은 같은 리전 안에서 서로 다른 가용 영역에 서버 2대를 두고, ALB 하나로 트래픽을 나누는 방식부터 시작하면 충분합니다. 이 구성만으로도 서버 한 대가 죽었을 때 전체 서비스가 멈추는 위험을 많이 줄일 수 있습니다.
운영하면서 봐야 할 숫자는 응답 시간, 5xx 오류, 대상 그룹의 정상 서버 수, 요청 수 정도입니다. 예를 들어 평소 응답 시간이 200밀리초 수준인데 이벤트 시간에 2초까지 치솟는다면 서버 증설이나 캐시 도입도 같이 고민해야 합니다. ELB는 트래픽을 나눠주는 장치이지, 느린 코드나 무거운 데이터베이스 쿼리를 자동으로 고쳐주지는 않습니다.
그래도 ELB를 앞단에 두면 운영 선택지가 훨씬 넓어집니다. 서버를 하나씩 교체하거나 배포 중인 서버를 잠시 빼는 작업이 쉬워지고, 장애가 난 인스턴스를 자동으로 제외하는 흐름도 만들 수 있습니다. 작은 서비스라도 사용자가 늘어날 가능성이 있다면, 서버 한 대에 모든 부담을 맡기는 구조보다는 ELB를 포함한 단순한 이중화 구성을 일찍 경험해두는 게 꽤 든든합니다.
