초보자를 위한 ELB 이해하고 적용하는 방법
얼마 전 작은 웹 서비스를 올려둔 지인이 밤마다 사이트가 느려진다며 로그를 같이 보자고 했는데, 서버 한 대가 모든 요청을 혼자 받느라 꽤 버거워하고 있었습니다. 평소에는 괜찮다가 이벤트 페이지를 열거나 광고를 집행한 날에만 접속이 몰리는 상황이었죠. 이럴 때 자주 등장하는 단어가 바로 ELB입니다.
ELB는 AWS에서 제공하는 Elastic Load Balancing의 줄임말입니다. 쉽게 말하면 사용자의 요청을 여러 서버로 나눠 보내는 교통정리 담당자에 가깝습니다. 서버가 1대일 때는 모든 방문자가 그 서버로 들어가지만, 서버가 2대, 3대 이상으로 늘어나면 누가 어느 서버로 갈지 정해야 합니다. ELB는 이 일을 자동으로 처리해 줍니다.
ELB가 필요한 상황을 먼저 떠올리기
웹 서비스를 처음 만들 때는 보통 서버 한 대로 시작합니다. 하루 방문자가 100명, 500명 정도라면 큰 문제가 없을 수 있습니다. 그런데 특정 시간에 1분 동안 요청이 1,000개씩 몰리면 이야기가 달라집니다. CPU 사용률이 90%를 넘고, 응답 시간이 0.2초에서 3초 이상으로 늘어나기도 합니다.
이때 서버를 더 좋은 사양으로 바꾸는 방법도 있습니다. 흔히 수직 확장이라고 부릅니다. 예를 들어 2vCPU 서버를 8vCPU 서버로 바꾸는 식입니다. 하지만 트래픽이 계속 늘면 비용이 급격히 커지고, 서버 한 대가 장애 나면 서비스 전체가 멈춘다는 약점은 그대로 남습니다.
ELB를 쓰면 서버 여러 대를 묶어두고 요청을 분산할 수 있습니다. 서버 A가 바쁘면 서버 B로 보내고, 서버 C가 응답하지 않으면 자동으로 제외하는 식입니다. 덕분에 접속자가 늘어도 더 유연하게 버틸 수 있고, 장애가 났을 때도 전체 서비스가 한 번에 멈출 가능성을 낮출 수 있습니다.
ELB 종류는 이렇게 구분하면 편합니다
AWS에서 ELB라고 말할 때는 보통 몇 가지 로드 밸런서 중 하나를 가리킵니다. 이름이 조금 비슷해서 처음 보면 헷갈리는데, 실제 선택 기준은 생각보다 단순합니다.
ALB는 웹 서비스에 가장 자주 씁니다
ALB는 Application Load Balancer입니다. HTTP와 HTTPS 요청을 다루는 데 잘 맞습니다. 일반적인 홈페이지, 쇼핑몰, 관리자 페이지, API 서버처럼 브라우저나 앱에서 들어오는 웹 요청을 처리할 때 많이 사용합니다.
예를 들어 같은 도메인으로 들어온 요청이라도 경로에 따라 다르게 보낼 수 있습니다. 상품 관련 요청은 상품 서버로, 회원 관련 요청은 회원 서버로 보내는 방식입니다. 호스트 이름 기준 분기도 가능합니다. 그래서 마이크로서비스 구조나 여러 서비스를 한 입구로 묶고 싶을 때 꽤 유용합니다.
NLB는 빠른 연결과 고정 IP가 중요할 때 어울립니다
NLB는 Network Load Balancer입니다. TCP, UDP 같은 네트워크 계층의 트래픽을 처리합니다. 아주 낮은 지연 시간, 많은 연결 수, 고정 IP가 필요한 환경에서 자주 선택됩니다.
예를 들어 게임 서버, 실시간 통신, 대량의 TCP 연결을 처리하는 시스템이라면 ALB보다 NLB가 어울릴 수 있습니다. 웹 페이지를 예쁘게 라우팅하는 기능보다는 빠르고 안정적으로 연결을 전달하는 쪽에 강점이 있습니다.
CLB는 오래된 서비스에서 만날 수 있습니다
CLB는 Classic Load Balancer입니다. 예전부터 있던 방식이라 기존 시스템에서 아직 볼 수 있습니다. 새로 만드는 서비스라면 보통 ALB나 NLB를 먼저 검토하는 편이 자연스럽습니다. 특별히 기존 구조를 유지해야 하는 이유가 없다면 최신 로드 밸런서를 쓰는 쪽이 관리와 기능 면에서 편합니다.
ELB를 붙일 때 실제 흐름
ELB를 적용한다고 해서 갑자기 복잡한 구조를 모두 알아야 하는 건 아닙니다. 기본 흐름은 꽤 명확합니다. 먼저 EC2 같은 서버를 2대 이상 준비합니다. 같은 애플리케이션이 돌아가도록 구성하고, 사용자가 직접 서버 IP로 들어오지 않게 앞단에 ELB를 둡니다.
그다음 대상 그룹을 만듭니다. 대상 그룹은 ELB가 요청을 보낼 서버 목록이라고 보면 됩니다. 서버 A, 서버 B, 서버 C를 묶어두고, ELB는 이 그룹 안에서 정상인 서버를 골라 요청을 전달합니다.
여기서 중요한 것이 헬스 체크입니다. 헬스 체크는 서버가 살아 있는지 주기적으로 확인하는 기능입니다. 예를 들어 30초마다 특정 경로에 요청을 보내고, 200 응답이 돌아오면 정상으로 판단합니다. 만약 서버 B가 계속 오류를 내면 ELB는 서버 B로 요청을 보내지 않습니다. 사용자는 장애가 난 서버를 직접 만나지 않게 되는 셈입니다.
- 사용자는 서비스 주소로 접속합니다.
- 요청은 먼저 ELB에 도착합니다.
- ELB는 정상 서버를 확인합니다.
- 요청을 적절한 서버로 전달합니다.
- 문제가 있는 서버는 대상에서 잠시 제외됩니다.
실무에서는 여기에 Auto Scaling을 함께 붙이는 경우가 많습니다. 트래픽이 늘면 서버를 자동으로 늘리고, 한가해지면 줄이는 방식입니다. 예를 들어 CPU 사용률이 70%를 넘으면 서버를 2대에서 4대로 늘리고, 다시 30% 아래로 내려가면 2대로 줄일 수 있습니다. ELB는 새로 생긴 서버까지 대상에 넣어 요청을 나눠줍니다.
비용과 운영에서 놓치기 쉬운 부분
ELB는 편하지만 비용이 생깁니다. 로드 밸런서가 켜져 있는 시간, 처리한 데이터, 규칙 수나 연결 수 같은 요소가 비용에 영향을 줍니다. 작은 테스트 서비스라면 서버 비용보다 ELB 비용이 더 눈에 띄게 느껴질 수도 있습니다. 그래서 개인 실습용이라면 켜둔 리소스를 확인하는 습관이 꽤 중요합니다.
보안 그룹 설정도 자주 막히는 지점입니다. 사용자는 ELB로만 접속하게 하고, 실제 서버는 ELB에서 들어오는 요청만 받도록 구성하는 방식이 일반적입니다. 서버의 80번이나 443번 포트를 전체 공개로 열어두면 로드 밸런서를 앞에 둔 의미가 줄어듭니다.
로그도 챙겨두면 좋습니다. 접속이 느린 문제가 생겼을 때 애플리케이션 로그만 보면 원인을 놓칠 수 있습니다. ELB의 지표를 보면 정상 대상 수, 응답 코드, 지연 시간, 요청 수를 확인할 수 있습니다. 예를 들어 5xx 오류가 갑자기 늘었다면 서버 애플리케이션 문제인지, 대상 그룹 설정 문제인지 좁혀볼 수 있습니다.
처음 적용한다면 이렇게 시작하면 쉽습니다
처음부터 완벽한 구조를 만들려고 하면 ELB가 어렵게 느껴집니다. 저는 보통 가장 단순한 그림부터 권합니다. ALB 하나, 같은 애플리케이션 서버 2대, 대상 그룹 1개, 헬스 체크 경로 1개. 이 정도만 구성해도 로드 밸런싱의 감이 꽤 빨리 옵니다.
운영 중인 웹 서비스라면 적용 순서도 조심스럽게 잡는 편이 좋습니다. 먼저 서버 두 대가 같은 방식으로 동작하는지 확인하고, ELB 뒤에 붙인 뒤 테스트 주소로 충분히 확인합니다. 로그인, 결제, 파일 업로드처럼 상태가 중요한 기능은 특히 꼼꼼히 봐야 합니다. 세션을 서버 메모리에만 저장하고 있다면 사용자가 서버 A와 서버 B를 오가면서 로그인이 풀릴 수 있기 때문입니다.
이럴 때는 세션을 Redis 같은 외부 저장소로 빼거나, 애플리케이션 구조를 상태에 덜 의존하도록 바꾸는 방법을 생각할 수 있습니다. 단순히 ELB만 붙였는데 문제가 생겼다면 로드 밸런서 자체보다 애플리케이션이 여러 서버에서 동시에 돌아갈 준비가 덜 된 경우가 많습니다.
ELB는 트래픽이 많은 대기업만 쓰는 도구처럼 보이지만, 사실 작은 서비스가 조금 더 안정적으로 자라기 위한 기본 장치에 가깝습니다. 서버 한 대로 버티는 시기를 지나 방문자가 늘기 시작했다면, 로드 밸런서 구조를 한 번 익혀두는 것만으로도 운영 감각이 확 달라집니다. 처음엔 낯설어도 ALB부터 천천히 붙여보면 생각보다 손에 잘 잡히는 편입니다.
