초보자를 위한 ELB로 서버 트래픽 나누는 방법
얼마 전 작은 서비스 하나가 이벤트 페이지를 열었다가 접속자가 몰리면서 서버가 버거워지는 걸 봤습니다. 서버 사양을 올리는 것도 방법이지만, 사실 어느 순간부터는 한 대를 크게 키우는 것보다 여러 대로 나눠 받는 쪽이 훨씬 편합니다. AWS에서 그 역할을 맡는 대표적인 서비스가 ELB입니다.
ELB는 Elastic Load Balancing의 줄임말입니다. 쉽게 말하면 사용자 요청을 앞에서 받아서 뒤쪽 서버들에게 나눠 보내는 교통 안내원 같은 역할을 합니다. 사용자는 ELB 주소로 접속하고, ELB는 상태가 좋은 서버를 골라 요청을 넘깁니다. 서버 한 대가 잠깐 아프면 그 서버를 빼고 다른 서버로 보내기 때문에 서비스가 갑자기 멈출 가능성도 줄어듭니다.
ELB가 필요한 순간을 먼저 잡기
처음부터 ELB가 꼭 필요한 건 아닙니다. 방문자가 하루 몇십 명이고 서버 한 대로 충분하다면 단순한 구조가 더 편할 수 있습니다. 그런데 접속자가 특정 시간에 몰리거나, 배포할 때마다 잠깐씩 접속 오류가 나거나, 서버 장애가 곧바로 서비스 장애로 이어진다면 ELB를 앞에 두는 게 꽤 현실적인 선택이 됩니다.
예를 들어 쇼핑몰에서 오전 10시에 쿠폰을 열었는데 1분 안에 요청이 5천 건 들어온다고 해볼게요. 서버 한 대가 모든 요청을 처리하면 CPU와 메모리가 확 올라갑니다. 반면 서버 3대를 두고 ELB가 요청을 나눠 보내면 각 서버가 받는 부담은 대략 3분의 1에 가까워집니다. 물론 실제로는 이미지, DB, 캐시 구조에 따라 달라지지만 출발점은 훨씬 안정적입니다.
- 트래픽이 특정 시간대에 몰린다
- 무중단 배포에 가까운 운영이 필요하다
- 서버 한 대 장애가 전체 장애로 이어지면 곤란하다
- 도메인, HTTPS 인증서, 라우팅을 한곳에서 관리하고 싶다
ALB와 NLB는 이렇게 고르면 편합니다
ELB를 찾다 보면 ALB, NLB 같은 이름이 나옵니다. 여기서 처음 헷갈리는 분들이 많습니다. 웹서비스라면 대부분 ALB부터 떠올리면 됩니다. ALB는 HTTP와 HTTPS 요청을 잘 다루고, 주소 경로나 호스트 이름에 따라 요청을 다른 서버 그룹으로 보낼 수 있습니다.
예를 들어 같은 도메인 안에서도 /api는 API 서버로, /admin은 관리자 서버로 보내는 식입니다. 모바일 앱과 웹이 같은 백엔드를 쓰는 경우에도 라우팅 규칙을 세밀하게 나눌 수 있어요. 반대로 게임 서버, 실시간 통신, TCP 기반 서비스처럼 낮은 지연 시간과 높은 처리량이 중요하면 NLB가 더 어울립니다.
일반적인 회사 홈페이지, 쇼핑몰, SaaS 대시보드, 블로그형 서비스는 ALB가 무난합니다. 포트 80 요청을 443으로 돌리고, 인증서를 붙여 HTTPS를 처리하고, 상태 확인까지 한 번에 가져갈 수 있기 때문입니다. 처음 구축하는 단계라면 ALB로 시작하고, 네트워크 성능 요구가 뚜렷할 때 NLB를 검토하는 흐름이 부담이 적습니다.
처음 설정할 때 놓치기 쉬운 부분
ELB 설정의 중심은 리스너, 대상 그룹, 상태 확인입니다. 리스너는 ELB가 어떤 포트로 요청을 받을지 정하는 부분입니다. 보통 웹서비스는 80과 443을 씁니다. 대상 그룹은 실제 요청을 받을 서버들의 묶음입니다. EC2 인스턴스, IP, 컨테이너 같은 대상이 여기에 들어갑니다.
상태 확인은 생각보다 중요합니다. ELB가 서버에게 주기적으로 괜찮은지 물어보고, 응답이 정상적이면 계속 요청을 보내고, 실패가 반복되면 잠시 제외합니다. 예를 들어 /health 같은 경로를 만들고 200 응답을 돌려주게 하면 관리가 쉬워집니다. 단순히 메인 페이지를 상태 확인 경로로 쓰면 DB 지연이나 외부 API 문제 때문에 불필요하게 서버가 빠질 수 있습니다.
- 리스너는 80, 443처럼 외부에서 받을 포트를 정합니다
- 대상 그룹은 요청을 실제로 처리할 서버 묶음입니다
- 상태 확인 경로는 가볍고 빠르게 응답하게 만드는 게 좋습니다
- 보안 그룹에서 ELB와 서버 사이 포트가 열려 있어야 합니다
또 하나 자주 놓치는 게 보안 그룹입니다. 사용자는 ELB로 들어오고, 서버는 ELB에서 오는 요청만 받게 구성하는 방식이 흔합니다. 이렇게 하면 서버를 인터넷에 넓게 열어두지 않아도 됩니다. 운영 입장에서는 작은 차이처럼 보이지만, 나중에 보안 점검을 받을 때 꽤 큰 차이를 만듭니다.
운영할 때는 숫자를 같이 봐야 합니다
ELB를 붙였다고 모든 문제가 자동으로 사라지진 않습니다. 요청 수, 응답 시간, 4xx 오류, 5xx 오류, 정상 대상 수 같은 지표를 같이 봐야 합니다. 특히 5xx가 늘어난다면 서버 쪽 오류인지, ELB와 서버 연결 문제인지, 대상 그룹 상태 확인이 흔들리는지 나눠서 봐야 합니다.
실제 운영에서는 평균 응답 시간보다 튀는 구간이 더 중요할 때가 많습니다. 평소 200ms 안팎으로 응답하다가 이벤트 시간에 2초, 3초로 늘어난다면 사용자는 체감합니다. 이때 서버를 더 늘릴지, 캐시를 넣을지, DB 쿼리를 손볼지 판단하려면 ELB 지표와 애플리케이션 로그를 같이 봐야 합니다.
비용도 살짝 챙겨야 합니다. ELB는 켜두는 시간과 처리량에 따라 비용이 붙습니다. 테스트용으로 만들고 잊어버리면 한 달 뒤 청구서에서 존재감을 드러냅니다. 개발 환경은 필요한 시간에만 켜거나, 운영 환경과 분리해서 이름을 명확히 붙여두는 습관이 좋습니다.
작게 시작해서 안정성을 키우는 흐름
처음 ELB를 붙일 때는 구조를 너무 크게 잡지 않아도 됩니다. 가장 단순한 흐름은 ALB 하나, 대상 그룹 하나, 서버 두 대입니다. 그다음 HTTPS 인증서를 붙이고, 80 요청은 443으로 보내고, 상태 확인 경로를 별도로 둡니다. 여기까지면 작은 서비스라도 운영 느낌이 꽤 달라집니다.
배포 방식도 조금 편해집니다. 서버 두 대 중 한 대를 먼저 새 버전으로 바꾸고 상태 확인이 정상인지 본 뒤, 나머지 한 대를 바꾸는 식으로 진행할 수 있습니다. 더 나아가면 대상 그룹을 두 개로 나눠 블루 그린 배포처럼 운영할 수도 있습니다. 처음부터 멋진 구조를 만들려고 애쓰기보다, 장애가 났을 때 어디를 봐야 하는지 알 수 있는 구조가 더 오래 갑니다.
ELB는 이름만 보면 조금 딱딱하지만, 실제 역할은 단순합니다. 사용자의 요청을 안정적으로 받아서 건강한 서버에게 보내주는 것. 서비스가 커질수록 이 단순한 역할이 꽤 든든하게 느껴집니다. 서버 한 대로 버티는 시간이 길어질수록 불안도 같이 커지니, 트래픽이 늘기 시작했다면 ELB를 앞에 세우는 선택을 진지하게 고민할 만합니다.
