이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
- LB 알고리즘과 routing rule이 특정 사용자·특정 API 장애를 어떻게 만들 수 있는가?
- weighted routing, stickiness, target group을 백엔드 배포와 어떻게 연결해서 봐야 하는가?
- LB access log와 app log를 어떤 기준으로 비교해야 하는가?
개요
Load Balancer는 들어온 요청을 여러 target 중 하나로 보내는 계층이다. 알고리즘 이름을 외우는 것보다 중요한 것은 “어떤 요청이 어떤 target group, 어떤 target, 어떤 버전으로 갔는가”를 설명하는 능력이다. 특정 API만 실패하거나 일부 사용자만 실패하는 장애는 routing rule, stickiness, weighted canary에서 자주 나온다.
- L4 LB는 TCP/UDP 연결 중심으로 분산한다.
- L7 LB는 Host, Path, Header, Method 같은 HTTP 조건으로 routing할 수 있다.
- weighted routing은 canary/blue-green 배포에 쓰이지만 작은 비율에서도 실사용자 장애를 만들 수 있다.
- sticky session은 상태 저장 앱을 쉽게 붙잡지만 target 과부하와 배포 복잡도를 만든다.
원리
LB routing은 보통 다음 순서로 결정된다.
Listener :443
-> Rule: host/path/header match
-> Target Group
-> Algorithm chooses target
-> Target connection장애 분석에서는 listener, rule, target group, target, app version을 모두 연결해야 한다. “LB 뒤에 있다”는 말은 너무 넓다.
알고리즘과 정책
| 정책 | 의미 | 실전 주의 |
|---|---|---|
| Round Robin | 순서대로 target 선택 | 요청 비용이 균등하지 않으면 쏠림 |
| Least Connections | 연결 수 적은 target 선택 | 장기 연결과 짧은 요청이 섞이면 해석 주의 |
| Weighted | target group별 비율 분산 | canary 오류가 전체 오류율에 희석됨 |
| IP Hash / Stickiness | 같은 사용자를 같은 target에 유지 | 세션 유실 완화, 특정 target 과부하 |
| Header/Path Routing | 조건별 service 분기 | rule 우선순위 오류로 오배송 |
시니어는 평균 error rate만 보지 않고 target group, app version, route, AZ별로 나눈다.
코드와 명령으로 확인하기
response에 app instance와 version을 임시로 노출하면 routing 검증이 빨라진다.
X-App-Instance: orders-7c9f6f6d5b-x2k8p
X-App-Version: 2026.07.01-1
X-Request-ID: 018f...반복 요청으로 분산을 관찰한다.
for i in {1..20}; do
curl -sI https://api.example.com/orders \
| awk 'BEGIN{IGNORECASE=1}/^(x-app-instance|x-app-version|x-request-id):/{print}'
echo
done실제 운영에서는 header 노출이 보안 정책과 충돌할 수 있으므로 내부 debug endpoint나 log 기반으로 대체한다.
Canary와 Weighted Routing
1% canary는 전체 error rate에서는 작아 보인다. 하지만 canary 대상 사용자는 100% 실패를 경험할 수 있다. 그래서 canary는 다음 기준으로 본다.
- canary target group error rate
- canary p95/p99 latency
- canary business metric
- canary version log
- rollback trigger와 자동/수동 권한
weighted routing을 바꾸는 작업은 인프라 변경이지만 앱 배포 절차의 일부다.
인프라 협업 포인트
- 앱 팀은 route별 비용, statefulness, session 필요 여부, canary 관찰 지표를 제공한다.
- 인프라 팀은 listener rule 우선순위, target group, weight, stickiness TTL, access log 위치를 공유한다.
- 장애 때는 “어떤 target group에서만 실패하는가”를 먼저 나눈다.
- sticky session을 쓰면 배포/scale-in 때 사용자 영향과 session store 전략을 함께 논의한다.
실전 팁
- route rule이 많아질수록 우선순위 테스트가 필요하다.
/api/admin/*보다/api/*가 먼저 잡히면 전혀 다른 서비스로 갈 수 있다. - target별 request count가 크게 다르면 알고리즘, keep-alive, sticky, slow target을 함께 의심한다.
- canary는 성공률뿐 아니라 사용자 cohort와 endpoint별 error를 봐야 한다.
- 개인 프로젝트에서는 단일 LB라도 app instance id를 로그에 남기면 “특정 인스턴스만 문제”를 빨리 찾는다.
- memory session을 쓰는 앱은 stickiness보다 shared session store 전환을 먼저 검토한다.
위험 신호!
- target group별 metric 없이 전체 5xx만 본다.
- canary weight만 조정하고 rollback 기준이 없다.
- sticky session이 켜져 있는데 session store/배포 전략 문서가 없다.
- routing rule 변경 후 대표 Host/Path 테스트가 없다.
확인 질문
확인 질문
- weighted canary 장애가 전체 error rate에서 작게 보일 수 있는 이유는 무엇인가?
- canary 비율이 낮으면 전체 평균에는 희석되지만 canary로 간 사용자는 지속적으로 실패할 수 있기 때문이다.
- sticky session이 편하지만 위험한 이유는 무엇인가?
- 특정 target에 사용자가 묶여 과부하와 배포/scale-in 시 세션 끊김이 생길 수 있기 때문이다.
- routing 장애에서 가장 먼저 나눠야 할 축은 무엇인가?
- listener/rule, target group, target instance, app version, route를 나눠야 한다.