ELB 처음 쓰려면 이렇게, 생활비 블로그 운영자가 이해한 쉬운 설정 방법

얼마 전 블로그 접속이 갑자기 느려진 적이 있었어요. 할인 정보 글 하나가 커뮤니티에 공유되면서 평소보다 방문자가 확 늘었는데, 그때 처음으로 ELB라는 말을 제대로 찾아보게 됐습니다. 살림 블로그도 결국 웹사이트라서 사람이 몰리면 장바구니 줄 서듯 서버도 줄을 서더라고요.

ELB는 AWS에서 제공하는 로드 밸런서 서비스입니다. 쉽게 말하면 방문자가 한꺼번에 들어왔을 때 여러 서버로 일을 나눠주는 안내 데스크 같은 역할을 합니다. 서버 한 대가 모든 요청을 받으면 버벅일 수 있는데, ELB를 앞에 두면 트래픽을 나눠 보내서 사이트가 더 안정적으로 버팁니다.

ELB가 필요한 상황부터 가볍게 보기

개인 블로그나 작은 사이트는 처음부터 ELB가 꼭 필요한 건 아닙니다. 방문자가 하루 수백 명 정도이고 서버 한 대로도 충분히 빠르다면 굳이 비용을 늘릴 이유가 없어요. 그런데 특정 시간에 접속자가 몰리거나, 이벤트 페이지를 운영하거나, 쇼핑몰처럼 접속 장애가 바로 손해로 이어지는 사이트라면 이야기가 달라집니다.

예를 들어 오전 10시에 정부 지원금 신청 글을 올렸는데 10분 동안 방문자가 평소의 5배로 늘었다고 해볼게요. 서버 한 대만 쓰면 CPU 사용률이 90%를 넘고 페이지 로딩이 5초 이상 걸릴 수 있습니다. 반면 같은 서버를 2대 이상 두고 ELB로 나눠 받으면 한쪽이 버거워질 때 다른 쪽이 같이 받아주니 훨씬 안정적입니다.

• 방문자가 특정 시간에 몰리는 사이트
• 장애가 나면 바로 매출이나 신뢰에 영향이 큰 서비스
• 서버를 2대 이상 운영하려는 경우
• HTTPS 인증서 관리를 한곳에서 하고 싶은 경우

ELB 종류 고를 때 헷갈리지 않는 방법

AWS에서 ELB라고 부르는 것 안에는 몇 가지 종류가 있습니다. 처음 보면 이름부터 낯설어서 어렵게 느껴지는데, 실제로는 용도별로 나뉜다고 보면 됩니다. 일반 웹사이트라면 대부분 Application Load Balancer, 줄여서 ALB를 먼저 떠올리면 됩니다.

ALB는 일반 웹사이트에 가장 무난합니다

ALB는 HTTP와 HTTPS 트래픽을 다루는 데 잘 맞습니다. 블로그, 쇼핑몰, 예약 사이트, 관리자 페이지처럼 브라우저로 접속하는 서비스라면 ALB가 편합니다. 주소 경로에 따라 다른 서버로 보낼 수도 있어서, 예를 들면 /blog는 블로그 서버로, /shop은 쇼핑 서버로 나누는 식의 운영도 가능합니다.

NLB는 속도와 대량 트래픽에 강합니다

NLB는 Network Load Balancer입니다. 초당 요청이 아주 많거나 TCP 기반 서비스처럼 더 낮은 단계의 네트워크 처리가 필요할 때 씁니다. 일반 생활 정보 블로그 수준에서는 과한 경우가 많고, 게임 서버나 실시간 서비스처럼 특수한 상황에서 더 자주 보입니다.

CLB는 오래된 방식이라 새로 시작할 땐 덜 권합니다

Classic Load Balancer는 예전 방식입니다. 이미 쓰고 있는 서비스라면 유지할 수 있지만, 새로 만드는 사이트라면 보통 ALB나 NLB를 고르는 편이 낫습니다. 기능이나 운영 편의성 면에서 최신 방식이 더 다루기 좋거든요.

초보자가 ELB 설정할 때 보는 순서

ELB 설정은 크게 보면 복잡하지 않습니다. 먼저 서버를 준비하고, 그 서버들을 묶을 대상 그룹을 만든 뒤, 로드 밸런서를 앞에 세우는 흐름입니다. 여기서 대상 그룹은 ELB가 트래픽을 보낼 서버 목록이라고 생각하면 편합니다.

• 1단계: EC2 서버를 2대 이상 준비합니다.
• 2단계: 같은 애플리케이션이 두 서버에서 잘 뜨는지 확인합니다.
• 3단계: Target Group을 만들고 서버를 등록합니다.
• 4단계: ALB를 만들고 HTTP 또는 HTTPS 리스너를 설정합니다.
• 5단계: 도메인의 DNS를 ELB 주소로 연결합니다.

여기서 은근히 많이 놓치는 부분이 헬스 체크입니다. ELB는 서버가 살아 있는지 계속 확인합니다. 예를 들어 /health 같은 주소를 만들어 두고 정상일 때 200 응답이 나오게 하면, ELB가 그 서버로 트래픽을 보내도 되는지 판단합니다. 만약 한 서버가 오류를 내면 ELB가 그쪽으로 보내는 요청을 줄이거나 멈춥니다.

비용과 운영에서 꼭 체크할 부분

ELB는 편하지만 무료는 아닙니다. 로드 밸런서 사용 시간과 처리한 데이터, 요청량에 따라 비용이 붙습니다. 작은 블로그라면 서버 비용보다 ELB 비용이 더 눈에 띌 수도 있어요. 그래서 트래픽이 많지 않은 초기 단계라면 무작정 붙이기보다 실제 방문자 수와 장애 위험을 보고 결정하는 게 현실적입니다.

제가 비용을 볼 때는 월 방문자 수보다 피크 시간을 더 봅니다. 하루 방문자가 3천 명이어도 하루 종일 고르게 들어오면 서버 한 대로 버틸 수 있습니다. 그런데 30분 안에 2천 명이 몰리면 다른 문제입니다. 생활비도 한 달 지출 총액만 보는 게 아니라 카드값 빠지는 날짜를 보는 것과 비슷합니다.

• HTTPS를 쓴다면 인증서를 ACM에서 발급해 ALB에 연결
• 보안 그룹에서 ALB는 외부 접속 허용, EC2는 ALB에서만 접속 허용
• 서버 2대 이상이면 같은 코드와 환경 변수 유지
• 로그를 켜서 오류가 어느 서버에서 나는지 확인
• 비용 알림을 설정해 예상 밖 지출 방지

ELB를 쓰면 좋아지는 점과 불편한 점

좋은 점은 분명합니다. 서버 한 대가 잠깐 문제를 일으켜도 전체 사이트가 바로 멈추지 않을 가능성이 커집니다. HTTPS 설정도 로드 밸런서에서 처리하면 서버마다 인증서를 따로 만지는 번거로움이 줄어듭니다. 트래픽이 늘 때 서버를 추가하기도 수월합니다.

그런데 불편한 점도 있습니다. 구조가 하나 더 생기니 원인을 찾을 때 볼 곳이 늘어납니다. 예전에는 서버 로그만 보면 됐는데, 이제는 ALB 설정, 대상 그룹, 헬스 체크, 보안 그룹, DNS까지 같이 봐야 합니다. 비용도 매달 붙습니다. 그래서 저는 작은 테스트 사이트에는 바로 쓰지 않고, 실제 방문자가 늘거나 장애 비용이 커졌을 때 붙이는 쪽을 더 현실적으로 봅니다.

ELB는 어려운 기술 이름처럼 보이지만, 결국 방문자를 여러 계산대로 나눠 보내는 장치에 가깝습니다. 내 사이트가 아직 조용한 골목 가게라면 필요 없을 수 있고, 특정 시간마다 줄이 길어지는 가게라면 꽤 든든한 선택이 됩니다. 무조건 좋다기보다, 접속자가 몰렸을 때 잃는 것과 매달 내는 비용을 나란히 놓고 보면 판단이 훨씬 쉬워집니다.