AWS ALB 개요 및 서비스시 고려사항
ALB란?
ALB(Application Load Balancer)는 OSI 7계층(애플리케이션 계층)에서 동작하는 AWS의 로드 밸런서다. HTTP/HTTPS 트래픽을 분석하여 콘텐츠 기반 라우팅을 수행한다.
한마디로, 요청의 URL 경로, 호스트명, 헤더 값을 보고 "이 요청은 어디로 보낼까"를 결정할 수 있다.
AWS 로드 밸런서 비교
| 특성 | ALB | NLB | CLB (레거시) |
|---|---|---|---|
| 계층 | L7 (HTTP/HTTPS) | L4 (TCP/UDP/TLS) | L4 + L7 |
| 라우팅 | 경로, 호스트, 헤더, 쿼리 기반 | 포트 기반 | 단순 라운드로빈 |
| 성능 | 초당 수만 요청 | 초고속 (초당 수백만 연결) | 제한적 |
| WebSocket | 지원 | 지원 | 미지원 |
| gRPC | 지원 | 지원 | 미지원 |
| 고정 IP | 미지원 (DNS 기반) | 지원 (Elastic IP) | 미지원 |
| 비용 | 중간 | 낮음 | 가장 낮음 |
| 사용 시나리오 | 마이크로서비스, 컨테이너 | 게임, IoT, 초저지연 | 마이그레이션 전용 |
결론부터 말하면:
- HTTP 라우팅이 필요하면 → ALB
- 초저지연이나 고정 IP가 필요하면 → NLB
- CLB는 신규 프로젝트에서 쓸 이유가 없다
ALB 핵심 구성 요소
리스너 (Listener)
리스너는 "어떤 프로토콜의 어떤 포트로 들어오는 트래픽을 받을 것인가"를 정의한다.
- HTTP(80), HTTPS(443)이 기본 구성
- HTTPS 리스너에는 ACM(AWS Certificate Manager) 인증서를 연결한다
타겟 그룹 (Target Group)
트래픽을 실제로 처리할 대상을 묶어둔 그룹이다.
| 타겟 유형 | 사용 사례 |
|---|---|
| EC2 인스턴스 | 전통적 서버 기반 |
| IP 주소 | VPC 피어링, 온프레미스 |
| Lambda 함수 | 서버리스 |
| ALB (중첩) | 멀티 계층 아키텍처 |
라우팅 규칙
ALB의 핵심 차별점이다. 요청의 다양한 속성을 기준으로 라우팅할 수 있다.
| 라우팅 조건 | 예시 |
|---|---|
| 경로 기반 | /api/* → API 서버, /static/* → 캐시 서버 |
| 호스트 기반 | api.example.com → API, web.example.com → 웹 |
| HTTP 헤더 | X-Custom-Header: mobile → 모바일 서버 |
| 쿼리 문자열 | ?version=v2 → v2 서버 |
| HTTP 메서드 | POST → 쓰기 서버, GET → 읽기 서버 |
| 소스 IP | 내부 IP → 내부 서비스 |
이 라우팅 규칙 하나 때문에 ALB를 선택하는 경우가 많다. 하나의 ALB로 여러 마이크로서비스에 트래픽을 분배할 수 있으니까.
헬스 체크
| 설정 | 권장값 | 설명 |
|---|---|---|
| 경로 | /health |
전용 헬스 체크 엔드포인트 |
| 간격 | 30초 | 체크 주기 |
| 임계값 | Healthy 3, Unhealthy 3 | 상태 전환 기준 |
| 타임아웃 | 5초 | 응답 대기 시간 |
| 성공 코드 | 200-299 |
정상 응답 범위 |
서비스 설계 시 고려사항
여기서부터가 실전이다. ALB를 붙이는 것 자체는 어렵지 않지만, 제대로 설계하려면 몇 가지를 챙겨야 한다.
1. SSL/TLS 종료 (SSL Offloading)
ALB에서 HTTPS를 종료하고, 백엔드에는 HTTP로 통신하는 패턴이다.
- ACM 무료 인증서를 활용하면 비용 부담이 없다
- 백엔드 서버의 암호화 부하를 제거할 수 있다
- 대부분의 경우 이 패턴이면 충분하다
2. 스티키 세션 (Session Affinity)
| 방식 | 쿠키 | 적합한 경우 |
|---|---|---|
| ALB 생성 쿠키 | AWSALB |
일반적 세션 유지 |
| 앱 기반 쿠키 | 커스텀 | 특정 세션 로직 필요 |
| 사용하지 않음 (권장) | - | 스테이트리스 설계 시 |
가능하면 스테이트리스 설계 + 외부 세션 저장소(Redis, DynamoDB)를 권장한다. 스티키 세션은 스케일링을 어렵게 만드는 주범이다.
3. Auto Scaling 연동
- ALB 타겟 그룹에 ASG(Auto Scaling Group)를 연결하면 스케일 아웃 시 자동으로 타겟이 등록된다
- Connection Draining: 스케일 인 시 기존 연결을 안전하게 종료한다 (기본 300초)
4. 크로스존 로드 밸런싱
AZ(가용 영역) 간 트래픽을 균등하게 분배하는 기능이다. 반드시 활성화하자. ALB는 기본 활성화지만, NLB는 기본 비활성화이니 주의.
5. WAF 통합
AWS WAF를 ALB에 연결하면 L7 수준의 보안을 적용할 수 있다.
- SQL injection, XSS, 봇 차단 규칙 설정
- Rate limiting으로 DDoS 기본 방어
6. 로깅과 모니터링
| 도구 | 용도 |
|---|---|
| Access Logs | S3에 요청 로그 저장 (디버깅, 분석) |
| CloudWatch | 요청 수, 지연시간, 5xx 에러율 |
| Request Tracing | X-Amzn-Trace-Id 헤더로 요청 추적 |
Access Logs는 켜두면 좋은데, 트래픽이 많으면 S3 비용이 꽤 나온다. 필요할 때만 켜는 것도 방법이다.
7. 비용 최적화
- LCU(Load Balancer Capacity Unit) 기반 과금: 새 연결, 활성 연결, 처리 바이트, 규칙 평가 중 가장 높은 항목 기준
- 불필요한 라우팅 규칙을 최소화하자
- 쓰지 않는 ALB는 반드시 제거 — 트래픽이 없어도 시간당 과금된다
일반적인 아키텍처 패턴
마이크로서비스
Client → ALB → /users/* → User Service (ECS)
→ /orders/* → Order Service (ECS)
→ /auth/* → Auth Service (Lambda)
Blue/Green 배포
ALB → 가중치 라우팅 → Blue (90%) 타겟 그룹
→ Green (10%) 타겟 그룹
멀티 테넌트
ALB → tenant-a.example.com → Tenant A 타겟 그룹
→ tenant-b.example.com → Tenant B 타겟 그룹
마무리: 실전 체크리스트
ALB를 도입할 때 아래 항목을 한 번씩 체크해보자.
- [ ] HTTP 기반 라우팅이 필요한 상황인가? (아니면 NLB 검토)
- [ ] SSL 종료를 ALB에서 할 것인가?
- [ ] 스티키 세션 없이 스테이트리스로 설계할 수 있는가?
- [ ] 헬스 체크 엔드포인트(
/health)가 준비되어 있는가? - [ ] 크로스존 로드 밸런싱이 활성화되어 있는가?
- [ ] WAF 연결이 필요한가?
- [ ] Access Logs를 켤 것인가? (S3 비용 고려)
- [ ] 사용하지 않는 ALB가 방치되어 있지 않은가?
ALB는 AWS 웹 서비스 아키텍처의 기본 중 기본이다. 한 번 제대로 이해하면 마이크로서비스 라우팅, Blue/Green 배포, 멀티 테넌트까지 자연스럽게 설계할 수 있다.
Member discussion