로드 밸런서 완전 정복
단순히 "분산"만 하는 게 아니다. Meta, Google, Netflix는 알고리즘 레벨에서 로드 밸런서를 다시 정의했다.
API Gateway란 무엇인가?
“당신은 오늘도 모르게 API Gateway를 통과했을 것이다.”
API Gateway는 마이크로서비스 아키텍처의 프론트 데스크 역할을 합니다. 호텔 프론트가 체크인, 키 발급, 문의를 처리하듯, API Gateway는 모든 외부 요청의 단일 진입점으로서 라우팅, 인증, 속도 제한, 로깅, 응답 변환 등의 역할을 담당합니다.
언제 필요한가?
마이크로서비스 기반 아키텍처
서비스 수십 개 이상 분리 → 클라이언트가 각각 접근 불가
API 인증, 로깅, 트래픽 제어 등을 중앙 집중화
언제 불필요한가?
단일 서버/모놀리식 구조
클라이언트가 직접 단일 서비스에 접근 가능할 때로드 밸런서란?
로드 밸런서(Load Balancer)는 다수의 서버에 들어오는 트래픽을 효율적으로 분산하여 시스템의 성능, 가용성, 확장성을 향상시키는 핵심 컴포넌트입니다. 이는 서버 과부하를 방지하고, 장애 발생 시에도 서비스를 지속적으로 제공할 수 있도록 돕습니다.
로드 밸런서의 주요 기능
트래픽 분산: 들어오는 요청을 여러 서버에 고르게 분배하여 특정 서버에 부하가 집중되는 것을 방지합니다.
고가용성(High Availability): 서버 중 하나에 장애가 발생해도 다른 정상 서버로 트래픽을 자동으로 전환하여 서비스 중단을 최소화합니다.
확장성(Scalability): 트래픽 증가에 따라 서버를 추가하거나 제거하여 유연하게 대응할 수 있습니다.
보안 강화: SSL 종료(SSL Termination) 및 DDoS 방어 기능을 통해 보안을 강화할 수 있습니다.
로드 밸런싱 알고리즘
로드 밸런서는 다양한 알고리즘을 사용하여 트래픽을 분산합니다:
라운드 로빈(Round Robin): 요청을 순차적으로 각 서버에 분배합니다.
가중 라운드 로빈(Weighted Round Robin): 서버의 성능에 따라 가중치를 부여하여 트래픽을 분배합니다.
최소 연결(Least Connections): 현재 연결 수가 가장 적은 서버에 요청을 보냅니다.
IP 해시(IP Hash): 클라이언트의 IP 주소를 해싱하여 특정 서버에 매핑합니다.
최소 응답 시간(Least Response Time): 응답 시간이 가장 빠른 서버에 요청을 보냅니다.
로드 밸런서는 단순 분산기가 아니다
대부분의 개발자가 알고 있는 로드 밸런싱은
"라운드 로빈으로 트래픽을 서버에 고르게 보내는 것"입니다.
그러나 빅테크는 다음과 같은 상황까지 고려합니다:
유저의 지역과 네트워크 대역폭
서버의 실시간 CPU/메모리 부하
요청의 크기/유형 (영상, API 등)
연결 지속 시간과 TCP 상태
캐시 적중률과 지역성(Locality)
장애 허용(Failover) 전략
→ 즉, 스마트 라우팅 기반의 로드 밸런싱이 필요합니다.
AWS 로드 밸런서 종류
AWS는 다양한 요구에 맞는 로드 밸런서를 제공합니다:
Application Load Balancer (ALB): HTTP/HTTPS 트래픽에 최적화되어 있으며, URL 경로 기반 라우팅, 호스트 기반 라우팅 등을 지원합니다.
Network Load Balancer (NLB): 초당 수백만 건의 요청을 처리할 수 있는 고성능 로드 밸런서로, TCP 및 UDP 트래픽에 적합합니다.
Classic Load Balancer (CLB): 이전 세대의 로드 밸런서로, EC2-Classic 네트워크에서 사용됩니다.
Gateway Load Balancer (GWLB): 서드파티 가상 어플라이언스를 통합하여 보안 및 네트워크 기능을 확장할 수 있습니다.
AWS Managed Gateway: API Gateway
Amazon API Gateway는 RESTful, WebSocket, HTTP API를 위한 완전 관리형 게이트웨이로, 다음과 같은 기능을 제공합니다:
라우팅 및 통합 - HTTP 요청을 AWS Lambda, EC2, ALB, S3 등 다양한 백엔드 서비스로 라우팅합니다.
인증 및 권한 부여- IAM, Cognito, OAuth 2.0을 통한 인증 및 권한 부여를 지원합니다.
요청/응답 변환 - 요청 및 응답의 포맷을 변환하여 클라이언트와 백엔드 간의 호환성을 제공합니다.
캐싱 - 응답 캐싱을 통해 성능을 향상시키고 백엔드 부하를 줄입니다.
모니터링 - Amazon CloudWatch와 통합하여 API 호출 메트릭을 모니터링합니다.
보안 구성: AWS WAF 및 기타 보안 기능
AWS WAF (Web Application Firewall)는 다음과 같은 보안 기능을 제공합니다:
SQL 인젝션 및 XSS 방지 - 사전 정의된 규칙을 사용하여 일반적인 웹 공격을 차단합니다.
IP 블록 및 허용 목록 - 특정 IP 주소 또는 CIDR 블록을 기반으로 요청을 허용하거나 차단합니다.
지리적 제한 - 특정 국가 또는 지역에서 오는 요청을 제한할 수 있습니다.
봇 제어 - 자동화된 봇 트래픽을 식별하고 차단합니다.
추가적으로, API Gateway는 다음과 같은 보안 기능을 지원합니다:
TLS 암호화 - 전송 중 데이터의 보안을 위해 HTTPS를 사용합니다.
IAM 및 Cognito 통합 - 사용자 인증 및 권한 부여를 위해 AWS IAM 및 Amazon Cognito와 통합됩니다.
요청 유효성 검사 -요청 헤더, 쿼리 문자열, 본문 등을 검사하여 유효성을 확인합니다.
기업들의 로드 밸런서 활용 사례
1. Meta (Facebook)
Katran: Meta는 자체 개발한 L4 로드 밸런서인 Katran을 사용하여 Facebook.com의 모든 트래픽을 처리합니다. Katran은 eBPF를 활용하여 고성능과 유연성을 제공합니다.
Meta (Facebook) Katran
레벨: L4 로드 밸런서 (TCP 기반)
기술: eBPF 기반 커널 레벨 로드 밸런싱
알고리즘:
Source IP 해싱
가중 Least Connection
장애 서버 자동 제외
특징:
커널에서 직접 로드 밸런싱 수행 → user-space context switch 없음
Facebook.com의 모든 요청 처리
Dropbox도 Katran 채택
핵심 인사이트: 사용자 IP를 해싱해 동일 유저가 동일 서버로 연결되게 하여 TCP 세션 및 캐시 효율 극대화
2. Google
Maglev: Google은 자체 개발한 소프트웨어 기반 로드 밸런서인 Maglev를 사용하여 트래픽을 분산합니다. 이는 Google Cloud Load Balancing의 핵심 기술로, 높은 확장성과 안정성을 제공합니다.
L4 ~ L7 로드 밸런서 / 사용자 정의 해시 기반 테이블
알고리즘
Consistent Hashing (with weighted selection)
요청이 들어올 때 Maglev 테이블을 통해 서버 결정
특징
로드 밸런서 하나당 초당 수백만 요청 처리 가능
서버 증설/삭제 시에도 안정적인 키 매핑 유지
Google Cloud Load Balancing의 핵심 기술
핵심 인사이트: 동일 클라이언트 요청을 동일 서버로 보내는 것보다, 서버의 상태 변화에도 안정적인 연결 매핑이 더 중요함
Prequal: YouTube에서는 Prequal이라는 로드 밸런서를 사용하여 실시간 요청 지연을 최소화하고, 서버 용량을 효율적으로 활용합니다.
3. Netflix
eBPF 활용: Netflix는 eBPF를 활용하여 네트워크 관측성과 성능 진단을 수행하며, 이를 통해 로드 밸런싱 효율을 높이고 있습니다.
Netflix — eBPF 기반 + ALB
L4 ~ L7 혼합 / AWS ALB + 내부 eBPF로 최적화된 로드 밸런싱
알고리즘:
ALB는 URI 기반 경로 분기 (예:
/login,/video)내부적으로 Least Response Time 알고리즘도 사용
특징:
글로벌 트래픽을 Open Connect와 함께 분산
Edge → Regional → Origin 로드 밸런서 계층 구조
핵심 인사이트: 스트리밍 트래픽 특성상, 응답 시간과 네트워크 지연률까지 고려된 동적 분산이 필요함
4. Cloudflare
Unimog: Cloudflare는 자체 개발한 엣지 로드 밸런서인 Unimog를 사용하여 전 세계적으로 트래픽을 분산하고, DDoS 공격에 대응합니다.
5. Dropbox
Katran 도입: Dropbox는 Meta의 Katran을 도입하여 L4 로드 밸런싱을 수행하며, 이를 통해 네트워크 성능과 안정성을 향상시켰습니다.
6. Yahoo!
Cilium 활용: Yahoo!는 Cilium을 통해 L4 로드 밸런싱을 수행하며, Kubernetes 환경에서의 네트워크 관리를 최적화하고 있습니다.
7. Walmart
eBPF 기반 로드 밸런싱: Walmart는 eBPF를 활용하여 고성능 L4 로드 밸런싱을 구현하고, 대규모 트래픽을 효율적으로 처리합니다.
API Gateway의 확장 전략
1. 수평 확장 (Horizontal Scaling)
API Gateway는 Stateless → ELB 뒤에 여러 인스턴스 배치 가능
2. 글로벌 분산
지역별 게이트웨이 배포 → Route53 + GeoDNS 조합
설정/정책 동기화 필요
3. 게이트웨이 내 서비스별 로드 밸런싱
Gateway-to-Service: 내부 Target Group 분산
실무에 적용할 수 있는 설계 팁
Health Check 없이 로드 밸런서는 무용지물
매 요청이 살아 있는 서버로만 가게 하려면 필수
단순 Round Robin은 초보 설계
실무에서는 서버별 처리 능력, 연결 수, 응답 시간 고려 필요
ALB vs NLB vs Katran?
ALB: L7, 경로 분기, HTTPS 중심
NLB: 초고속 TCP 처리용
Katran/eBPF: 초대형 트래픽에 적합한 자체 솔루션
Consistent Hashing은 서버 증설/장애에도 안정적
분산 캐시, 스트리밍, 장기 세션이 있을 땐 필수
이중화 (HA)와 멀티 AZ 구성은 기본
단일 로드 밸런서는 SPOF(Single Point of Failure) 위험
결론
로드 밸런싱은 단순한 트래픽 분산을 넘어
지능형 라우팅, 네트워크 최적화, 장애 복원, 비용 절감까지 책임지는 아키텍처 전략입니다.
빅테크처럼 고도화된 알고리즘을 직접 구현하긴 어렵지만,
Cloud Load Balancer, Envoy, Nginx, AWS ALB/NLB 등을 잘 조합하면
어느 정도 비슷한 수준까지 실현할 수 있습니다.
시나리오 문제 (실전형)
시나리오 #1 실시간 주식 트레이딩 플랫폼
상황
고빈도 거래 요청이 밀려드는 주식 매매 API 서버를 설계 중입니다.
동일 유저는 로그인 상태를 유지하고 있고, 연결이 중간에 끊기면 트레이딩이 실패할 수 있습니다.
요구사항
트래픽이 순간적으로 몰릴 수 있음
사용자 세션 유지 필요
트랜잭션 신뢰성과 성능 모두 중요
질문
어떤 로드 밸런서 알고리즘을 사용하겠는가?
세션 유지와 장애 복구를 동시에 만족시키기 위한 구성은?
응답 지연이 생겼을 때 동적으로 조정 가능한 방법은?
해설 방향
해설
IP Hash 기반 또는 Session Affinity (Sticky Session) 알고리즘을 사용합니다.
트레이딩 서비스에서는 하나의 사용자 세션이 항상 같은 서버에 유지되어야 주문 누락이나 중복 주문을 방지할 수 있습니다.
이 방식은 TCP 연결 또는 세션 ID 기준으로 클라이언트를 항상 동일한 서버로 보냅니다.
해설
Application Load Balancer(ALB) 사용 + Sticky Session 설정.
백엔드 서버에는 헬스 체크(Health Check)를 설정하여, 세션이 유지되더라도 서버가 죽었을 경우 자동으로 트래픽을 다른 서버로 전환.
오토스케일링 그룹(Auto Scaling Group)을 사용해 트래픽 급증에 유연하게 대응.
중요한 요청(주문)은 DB 트랜잭션 기반 재시도 로직도 백엔드에 포함되어야 함.
해설
ALB는 트래픽을 단순 분배하지만, EC2 인스턴스 상태(예: CPU, 지연시간)를 기반으로 가중치를 조정하는 방식은 별도 구현 필요.
Custom Load Balancer with NGINX + Lua, 또는 Service Mesh (예: Istio) 활용 시 서버 상태 기반 동적 Weight 조절이 가능.
또는 Amazon Global Accelerator + EC2 Health/CloudWatch 기반 Route 53 Failover를 사용해 지리적으로 최적화된 서버로 유도 가능.
시나리오 #2 글로벌 동영상 플랫폼
상황
YouTube와 유사한 스트리밍 플랫폼을 구축 중이며, 사용자는 전 세계에서 접속합니다.
영상 스트리밍은 조각(Chunk) 단위로 전달되며, 끊김 없는 서비스가 중요합니다.
요구사항
요청 단위가 크고, 연결 시간이 길다
지역 분산 처리 필요
버퍼링 최소화
질문
어떤 로드 밸런서와 알고리즘을 사용하겠는가?
Edge 서버를 고려한 아키텍처 구성은?
특정 지역에 과부하가 발생할 때 처리 방법은?
해설 방향
Network Load Balancer (NLB) + Least Connections / Least Response Time
해설
Network Load Balancer (NLB) 사용 + Least Connections 또는 Least Response Time 알고리즘.
이유: 동영상은 지속적인 연결을 유지하면서 많은 트래픽을 발생시킴.
부하가 적은 서버로 연결을 분배해야 하며 TCP 지연을 줄이는 것이 핵심.
CloudFront CDN 연계 + Edge 캐싱
해설
AWS 기준으로는 CloudFront CDN + Origin Load Balancer (ALB/NLB) 조합을 사용합니다.
콘텐츠(영상 chunk)는 전 세계에 Edge Location을 통해 미리 캐싱되며, 사용자 위치에 가장 가까운 POP에서 제공됩니다.
Origin Shield + Regional Edge Cache를 설정하면, 원본 서버 호출 횟수도 줄일 수 있음.
Region별 서버 Weight 조정 또는 Geo DNS 기반 분산
해설
CloudFront는 기본적으로 위치 기반 자동 라우팅을 수행하지만, 특정 POP가 과부하일 경우 다른 POP로 failover가 가능합니다.
Edge 서버 수용 한계를 넘는 경우, Amazon Global Accelerator로 라우팅을 재조정하거나 Regional Failover 설정을 통해 대체 리전에 요청을 분산합니다.
백엔드 서버 측에서는 Auto Scaling Group + Target Group Health Check로 수평 확장 및 복구 처리.
시나리오 #3 마이크로서비스 기반 쇼핑몰
상황
쇼핑몰은 /products, /cart, /checkout, /orders 같은 URI 별로 서비스를 나눈 구조입니다.
트래픽은 상품 검색 > 장바구니 > 결제 흐름으로 이어집니다.
요구사항
경로별 트래픽 분산
일부 마이크로서비스만 다운되더라도 전체는 살아 있어야 함
각 서비스마다 독립 배포 및 스케일링 가능해야 함
질문
어떤 라우팅 전략이 가장 적절한가?
서비스 장애 격리와 경로 분리를 어떻게 구현할 것인가?
AWS 기준으로 구현하려면 어떤 구조로 만들 것인가?
모범 해설 방향:
Application Load Balancer (ALB) + Path-based Routing
해설
Application Load Balancer (ALB) + Path-based Routing
/products,/checkout,/orders처럼 서비스 별로 라우팅이 분리되는 경우 ALB가 가장 적절.각 URI 패턴에 따라 다른 Target Group으로 연결 가능.
서비스별 Target Group + Health Check 분리
해설
서비스별로 독립적인 Target Group 구성. 예:
/product→ Target Group A/cart→ Target Group B/checkout→ Target Group C
각 Target Group은 자체 헬스 체크 설정.
서비스 A가 죽어도 서비스 B, C는 정상 동작 → 장애 격리 가능.
서비스는 ECS, Lambda, EC2로 독립 배포하여 서킷 브레이커 역할 가능.
ECS Fargate or Lambda + ALB Listener Rule 구성
해설
ALB Listener Rule을 사용하여 URI 경로를 기반으로 서비스 라우팅.
각 Target Group은 ECS 서비스(Fargate), Lambda, EC2 등으로 구성.
Auto Scaling Group을 통해 서비스별로 동적 확장.
보안 - WAF → ALB 앞단에 배치하여 공격 차단.
인증/인가 - API Gateway와 연계하여 Token Validation 가능.
인터뷰 팁 - API Gateway는 “도구”일 뿐
너무 많은 시간 할애 ❌
핵심 기능만 짚고 넘어가야 함:
"라우팅과 미들웨어 처리를 API Gateway로 관리하겠습니다."
중요한 건 게이트웨이 뒤의 설계임 (서비스 분리, DB 구성, 스케일링 전략 등)