로드 밸런서 vs API 게이트웨이 (하나가 다른 것을 대체할 수 있나요)
Source: Dev.to
현대 아키텍처에서 로드 밸런서와 API 게이트웨이는 모두 중요한 구성 요소이지만, 해결하는 문제가 다릅니다. 두 컴포넌트가 동일한 요청 경로에 나타날 수 있기 때문에 종종 혼동되거나 서로 교체 가능한 것으로 오해되기도 합니다.
Load Balancer Types
| Load Balancer | OSI Layer | What It Understands |
|---|---|---|
| L4 Load Balancer | Layer 4 (Transport) | TCP/UDP, IP, Port |
| L7 Load Balancer | Layer 7 (Application) | HTTP/HTTPS, headers, paths |
핵심 포인트: 로드 밸런서는 주로 트래픽 분산에 초점을 맞추며, API 로직을 처리하지 않습니다.
API Gateway
| Component | OSI Layer |
|---|---|
| API Gateway | Layer 7 (Application) |
API 게이트웨이는 HTTP 의미론을 깊이 이해합니다. 예를 들어:
- Headers
- JSON payloads
- Authorization tokens
- Request paths
- API versions
Key Differences at a Glance
| Aspect | Load Balancer | API Gateway |
|---|---|---|
| Primary Purpose | Distribute traffic | Manage APIs |
| OSI Layer | L4 or L7 | L7 only |
| Authentication | ❌ (very limited) | ✅ Built‑in |
| Rate Limiting | ❌ | ✅ |
| API Versioning | ❌ | ✅ |
| Request Transformation | ❌ | ✅ |
| Protocol Awareness | TCP/HTTP | HTTP/REST/GraphQL |
| Backend Awareness | Servers | Microservices & APIs |
Why One Can’t Replace the Other
Load Balancer
- 비유: 트래픽 경찰관 🚦이 어느 서버가 요청을 처리할지 결정하는 것과 같습니다.
- Layer 4 책임: IP 주소, 포트 번호, TCP/UDP 연결.
- Layer 7 책임 (해당되는 경우):
- 서버 간 트래픽 분산
- 경로 기반 라우팅 (예:
/api → server A) - 스티키 세션 (같은 사용자를 같은 서버에 보내기)
- 헬스 체크
- SSL 종료
Note: 스티키 세션은 “이 사용자를 다시 같은 서버에 보내라”는 의미일 뿐이며, 신원 확인, 토큰 검증, 권한 부여와는 무관합니다.
로드 밸런서는 빠르고 가벼우며 단순하도록 설계되었습니다. 무거운 보안 로직을 추가하면 성능이 저하되고 확장이 복잡해집니다.
API Gateway
- 비유: 건물 입구의 보안 요원 🛂이 API 접근을 제어하는 것과 같습니다.
- 핵심 책임:
- 인증 (JWT, OAuth, API keys)
- 인가 (사용자가 할 수 있는 작업)
- 속도 제한 및 스로틀링
- API 버전 관리 (v1, v2, …)
- 요청/응답 변환
- 로깅 및 모니터링
API 게이트웨이는 누가 호출하고, 얼마나 자주 호출하며, 어떤 권한을 가지고 있는지를 중점적으로 다룹니다. 인증은 토큰 검증, 만료 확인, 역할/권한 검사, 경우에 따라 외부 아이덴티티 스토어 호출까지 포함하므로 단순히 HTTP 헤더를 읽는 수준을 훨씬 넘어섭니다.
Summary
- Load balancer: “이 요청은 어디로 가야 할까?” – 라우팅과 기본 헬스 체크에 집중합니다.
- API gateway: “누가 호출하고 무엇을 할 수 있나?” – 보안, 트래픽 제어, API‑특화 기능을 추가합니다.
책임이 서로 다른 레이어에서 작동하기 때문에, 로드 밸런서는 레이어 7에서 동작하더라도 API 게이트웨이를 완전히 대체할 수 없습니다.