요약: AWS 로드밸런싱의 모든 것을 파헤칩니다. 트래픽을 분산하는 기본 원리부터 ALB, NLB, CLB 3총사의 특징과 정확한 사용처, 그리고 무중단 서비스를 위한 헬스 체크의 비밀까지, 현업 멘토가 실무 예시와 함께 완벽하게 정리해 드립니다.
안녕하세요! 👋 IT 업계의 후배님들과 네트워크/보안 전문가를 꿈꾸는 학생 여러분! 👨🏫 여러분의 성장을 돕는 멘토, 네트워크/보안 전문가입니다. 반갑습니다! 현업에서 쌓은 깊이 있는 지식과 실무 경험을 바탕으로, 여러분이 꼭 알아야 할 핵심 기술들을 쉽고 재미있게 알려드릴게요.
오늘은 클라우드 서비스의 심장과도 같은 AWS 로드 밸런싱(Load Balancing)에 대해 깊이 파헤쳐 보겠습니다. 복잡한 개념이라고 겁먹지 마세요! 교통경찰, 쇼핑몰 매니저 등 실생활 예시를 통해 머리에 쏙쏙 들어오도록 설명해 드릴 테니, 편하게 따라오세요! 🚀
1. 로드밸런서, 도대체 왜 필요한가요? 🤔
서버가 혼자 일하면 벌어지는 일
여러분, 인기 많은 맛집을 상상해 보세요. 손님(사용자)들이 한꺼번에 몰려드는데, 주방장(서버)이 한 명뿐이라면 어떻게 될까요? 주문은 밀리고, 음식은 늦게 나오고, 결국 손님들은 지쳐서 가게를 떠나버릴 겁니다. 웹 서비스도 마찬가지입니다. 수많은 사용자의 요청(트래픽)을 서버 한 대가 모두 처리하려고 하면, 결국 과부하(Overload)가 걸려 서비스가 느려지거나 멈춰버리는 '대참사'가 발생하게 되죠.
구원투수의 등장: AWS Elastic Load Balancing (ELB)
이때 등장하는 해결사가 바로 로드밸런서(Load Balancer)입니다. 로드밸런서는 마치 능숙한 교통경찰처럼, 몰려드는 요청(트래픽)을 여러 대의 서버에 골고루 나누어주는 역할을 합니다. AWS에서는 이 서비스를 Elastic Load Balancing (ELB)이라고 부르며, 크게 3가지 목표를 가지고 있습니다.
✨ 가용성 향상 (High Availability): 서버 한 대가 아프더라도 다른 건강한 서버들이 계속 서비스를 이어가게 합니다.
🚀 확장성 확보 (Scalability): 사용자가 몰려들면 서버를 빠르게 추가(Scale-out)하고, 빠지면 줄여(Scale-in) 유연하게 대응합니다.
⚡ 성능 최적화 (Performance Optimization): 요청을 효율적으로 분배하여 사용자의 응답 시간을 줄이고, 서비스 전반의 성능을 끌어올립니다.
자, 그럼 지금부터 AWS의 로드밸런서 3총사, CLB, ALB, NLB를 하나씩 만나볼까요?
2. AWS 로드밸런서 3총사 완전정복! 🕵️♂️
2-1. 클래식 로드밸런서 (CLB) - 역사의 시작
Classic Load Balancer (CLB)는 AWS 로드밸런서의 1세대 모델입니다. TCP, UDP, HTTP, HTTPS 등 다양한 종류의 요청을 처리할 수 있는 다재다능한 짐꾼이었지만, 사용자의 진짜 IP 주소가 보이지 않는다는 치명적 단점이 있었습니다. 현재는 특별한 이유가 없는 한 신규 서비스에는 거의 사용하지 않으므로, "이런 시작이 있었구나!" 정도로 이해하고 넘어가시면 됩니다.
2-2. 애플리케이션 로드밸런서 (ALB) - 똑똑한 웹 서비스 전문가
Application Load Balancer (ALB)는 CLB의 단점을 보완하고 HTTP/HTTPS 웹 서비스에 특화되어 태어난, 현대 웹 환경의 표준과도 같은 존재입니다. OSI 7계층 중 L7(애플리케이션 계층)에서 동작하며, 요청의 '내용'을 들여다보고 아주 똑똑하게 트래픽을 제어할 수 있습니다.
핵심 기능: 콘텐츠 기반 라우팅 (Content-based Routing)
ALB의 가장 큰 무기는 요청의 URL 경로, 호스트 이름 등을 분석해서 각각 다른 서버 그룹(Target Group)으로 보내주는 것입니다.
실무 예시 🛍️ (쇼핑몰 운영):
www.myshop.com/products 요청은 → 상품 정보 서버 그룹으로!
www.myshop.com/cart 요청은 → 장바구니 서버 그룹으로!
admin.myshop.com 요청은 → 관리자 전용 서버 그룹으로!
이처럼 경로 및 호스트 기반 라우팅을 통해, 기능별로 서버를 분리하여 마이크로서비스 아키텍처(MSA)를 쉽게 구현할 수 있습니다.
그 외에도 컨테이너 환경을 위한 **Dynamic Port Mapping**, **SSL 오프로딩**, **AWS WAF(웹 방화벽)** 연동 등 강력한 기능을 제공하여 현대적인 웹 서비스의 필수 파트너가 되었습니다.
2-3. 네트워크 로드밸런서 (NLB) - 초고속 성능의 지배자
Network Load Balancer (NLB)는 '성능'과 '속도'에 모든 것을 건 로드밸런서입니다. OSI 7계층 중 L4(네트워크 계층)에서 동작하며, 요청의 내용은 쳐다보지도 않고 오직 IP 주소와 포트 번호만 보고 빛의 속도로 트래픽을 전달합니다.
핵심 특징:
초고성능 & 초저지연: 초당 수백만 건의 요청을 매우 낮은 지연 시간으로 처리합니다.
소스 IP 보존: ALB/CLB와 가장 다른 점! NLB는 프록시가 아니라 '투명하게' 트래픽을 전달하기 때문에, 서버에서 사용자의 원본 IP 주소를 그대로 확인할 수 있습니다.
실무 예시 🎮 (온라인 게임 서버): 0.1초의 지연도 승패에 영향을 미치는 실시간 대전 게임이나, 사용자의 '진짜 IP'를 기준으로 보안 정책을 적용해야 할 때 최고의 선택입니다.
3. 한눈에 보는 ELB 3종 스펙 비교 📊
학생, 주니어 엔지니어분들을 위해 세 로드밸런서를 표로 깔끔하게 정리해 드릴게요. 이 표만 잘 이해해도 "로드밸런서 좀 아는데?" 소리 들으실 수 있습니다!
| 특징 | Classic (CLB) | Application (ALB) | Network (NLB) |
|---|---|---|---|
| 동작 계층 | L4/L7 (혼합) | L7 (HTTP/HTTPS) | L4 (TCP/UDP) |
| 소스 IP 보존 | ❌ (LB IP만 보임) | ❌ (LB IP만 보임) | ✅ (원본 IP 유지) |
| 고급 라우팅 | 제한적 | ✅ (경로, 호스트 기반 등) | ❌ (단순 포워딩) |
| 성능 | 보통 | 높음 (웹 최적화) | 매우 높음 (초저지연) |
| 주요 사용처 | 레거시 시스템 | 웹/마이크로서비스, 컨테이너 | 고성능 TCP/UDP, 게임 |
4. 로드밸런서의 심장, 헬스 체크 & 모니터링 ❤️🩹
"서버님, 살아계신가요?" 헬스 체크(Health Check)의 모든 것
헬스 체크는 로드밸런서가 서버들에게 주기적으로 "똑똑, 일 잘하고 있니?"라고 물어보는 과정입니다. 로드밸런서는 설정된 주기(예: 30초)마다 서버의 특정 포트나 URL 경로로 신호를 보내고, 정상 응답이 오지 않는 서버는 '비정상(Unhealthy)'으로 판단합니다.
실무 예시 (장애 자동 격리): 웹 서버 3대 중 1대가 다운되면, 헬스 체크에 실패한 해당 서버를 로드밸런서가 즉시 '비정상'으로 판단하고 더 이상 트래픽을 보내지 않습니다. 덕분에 사용자는 서비스 중단을 거의 느끼지 못하고, 나머지 건강한 서버 2대가 계속 서비스를 이어가게 됩니다. 이게 바로 서비스의 '고가용성(High Availability)'이죠!
문제가 생기기 전에 파악하자! CloudWatch 모니터링
AWS CloudWatch 서비스를 이용하면 우리 로드밸런서가 얼마나 열심히 일하는지, 건강 상태는 어떤지 속속들이 들여다볼 수 있습니다. RequestCount(요청 수), Latency(지연 시간), UnhealthyHostCount(비정상 서버 수), HTTPCode_Target_5XX_Count(서버 에러 수) 등의 핵심 지표를 모니터링하여 장애를 감지하고 원인을 신속하게 파악할 수 있습니다.
5. 베테랑의 실무 조언 (Field Tips from a Pro) 📝
후배님들과 학생 여러분, 기술의 기능을 아는 것을 넘어 '왜'와 '어떻게'를 고민해야 진정한 전문가로 성장할 수 있습니다.
💡 단순 암기보다 '왜?'를 고민하세요: "ALB는 L7이다"라고 외우지 마세요. "왜 L7 기능이 필요해졌을까?"를 생각해보는 겁니다. 바로 마이크로서비스, 컨테이너처럼 서비스가 점점 더 복잡하고 세분화되면서, 똑똑한 트래픽 제어가 중요해졌기 때문이죠. 이런 '왜'를 이해하면 기술의 본질이 보입니다.
🔐 소스 IP 보존의 중요성을 기억하세요: "우리 서비스는 사용자의 실제 IP 기반으로 보안 정책을 적용해야 해!" 라는 요구사항이 있다면, 고민할 필요도 없이 NLB를 검토해야 합니다. 이것이 ALB와 NLB를 가르는 결정적인 기준이 될 때가 많습니다.
🛡️ 보안 그룹(Security Group) 설계를 다르게 하세요: ALB 사용 시에는 웹 서버 보안 그룹에서 ALB의 보안 그룹 ID로부터 오는 트래픽만 허용하는 것이 Best Practice입니다. NLB 사용 시에는 서버에서 사용자의 원본 IP를 허용해야 하므로, 보안 설정에 더욱 신경 써야 합니다.
6. 알아두면 쓸모있는 용어 정리 📚
L4 / L7: OSI 7계층 모델의 4계층(전송 계층, IP/Port)과 7계층(애플리케이션 계층, HTTP)을 의미합니다.
프록시(Proxy): 클라이언트와 서버 사이에서 요청과 응답을 중계해주는 '대리인' 서버.
SSL 오프로딩(SSL Offloading): 로드밸런서가 서버 대신 HTTPS 암호화/복호화 부담을 짊어지는 기술.
헬스 체크(Health Check): 로드밸런서가 대상 서버의 동작 상태를 주기적으로 검사하는 기능.
타겟 그룹(Target Group): 로드밸런서가 트래픽을 분산할 대상 서버들의 묶음.
7. 자주 묻는 질문 (FAQ) 🙋♀️
Q1: 이제 막 웹사이트를 만들었는데, 어떤 로드밸런서를 써야 할까요?
A: 100%에 가깝게 ALB(Application Load Balancer)를 추천합니다. 현대적인 웹 서비스에 필요한 거의 모든 기능(경로 기반 라우팅, SSL 인증서 관리 등)을 제공하며, 사실상의 표준입니다.
Q2: 로드밸런서를 사용하면 제 서버의 실제 IP 주소가 숨겨지나요?
A: "어떤 로드밸런서를 쓰느냐에 따라 다릅니다!" ALB/CLB를 사용하면 '예'(숨겨짐), NLB를 사용하면 '아니요'(원본 IP 전달).
Q3: 헬스 체크 설정, 너무 어렵습니다. 정답이 있나요?
A: '정답'은 없습니다. 민감한 서비스는 주기를 짧게, 실패 임계치를 낮게 설정하여 장애를 빠르게 감지하고, 일반적인 서비스는 기본값으로 시작하여 운영하면서 서비스에 맞게 튜닝하는 것이 좋습니다.
마치며
자, 오늘 저와 함께 AWS 로드밸런싱의 세계를 여행해 보셨는데 어떠셨나요? CLB, ALB, NLB라는 세 친구가 각자 어떤 개성과 능력을 가졌는지, 그리고 언제 어떻게 활약하는지 명확히 이해되셨기를 바랍니다. 오늘 배운 내용을 바탕으로 직접 AWS 콘솔에서 로드밸런서를 만들어보고, 트래픽도 보내보면서 여러분의 것으로 만드시길 응원합니다!
궁금한 점이 있다면 언제든지 댓글로 질문해주세요! 여러분의 성장을 항상 응원하겠습니다.
더 상세한 내용은 Youtube채널(@NetworkingClass)을 참고해서 공부하실 수 있습니다.
아래 동영상을 참고하시면 내용을 이해하시는 데 더욱 도움이 될 것입니다.
댓글
댓글 쓰기