Istio의 트래픽 관리 기능을 실전 시나리오로 살펴봅니다. 가중치 기반 라우팅, 카나리 배포, 서킷 브레이커, 폴트 인젝션, 트래픽 미러링까지.
서비스 메시의 가장 강력한 기능 중 하나는 애플리케이션 코드 변경 없이 트래픽 흐름을 세밀하게 제어할 수 있다는 점입니다. 이 장에서는 Istio의 트래픽 관리 기능을 실전 시나리오별로 살펴보겠습니다.
가장 기본적이면서도 강력한 트래픽 관리 기법입니다. 동일 서비스의 여러 버전으로 트래픽을 비율 기반으로 분배합니다.
새 버전을 소수의 트래픽으로 먼저 검증한 뒤 점진적으로 확대하는 카나리 배포를 Istio로 구현할 수 있습니다.
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
name: reviews
namespace: bookinfo
spec:
host: reviews
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
name: reviews
namespace: bookinfo
spec:
hosts:
- reviews
http:
- route:
- destination:
host: reviews
subset: v1
weight: 90
- destination:
host: reviews
subset: v2
weight: 10이 설정으로 트래픽의 90%는 v1으로, 10%는 v2로 라우팅됩니다. v2의 에러율과 지연 시간을 관찰한 후, weight를 단계적으로 조정하여 배포를 진행합니다.
배포 진행 단계:
v1:v2 = 90:10 → 관찰 → 70:30 → 관찰 → 50:50 → 관찰 → 0:100
특정 사용자나 테스트 그룹만 새 버전으로 라우팅할 수 있습니다.
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- match:
- headers:
x-canary:
exact: "true"
route:
- destination:
host: reviews
subset: v2
- route:
- destination:
host: reviews
subset: v1QA 팀이 x-canary: true 헤더를 포함한 요청을 보내면 v2를 테스트할 수 있고, 일반 사용자에게는 영향이 없습니다.
Istio는 DestinationRule을 통해 다양한 로드 밸런싱 알고리즘을 설정할 수 있습니다.
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
name: reviews
spec:
host: reviews
trafficPolicy:
loadBalancer:
simple: LEAST_REQUEST # 최소 요청 수 기반지원하는 알고리즘:
| 알고리즘 | 설명 | 적합한 상황 |
|---|---|---|
ROUND_ROBIN | 순차 분배 (기본값) | 균일한 요청 처리 시간 |
LEAST_REQUEST | 미처리 요청이 가장 적은 인스턴스로 | 처리 시간이 불균일할 때 |
RANDOM | 무작위 분배 | 간단한 분산이 필요할 때 |
PASSTHROUGH | 로드 밸런싱 없이 직접 연결 | 특수한 경우 |
특정 기준에 따라 같은 클라이언트의 요청을 항상 같은 인스턴스로 라우팅합니다.
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
name: reviews
spec:
host: reviews
trafficPolicy:
loadBalancer:
consistentHash:
httpHeaderName: x-user-id다운스트림 서비스의 장애가 상위 서비스로 전파되는 것을 방지합니다. Istio에서는 Connection Pool과 Outlier Detection 두 가지 메커니즘으로 구현됩니다.
동시 연결 수와 대기 요청 수를 제한합니다.
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
name: reviews
spec:
host: reviews
trafficPolicy:
connectionPool:
tcp:
maxConnections: 100 # 최대 TCP 연결 수
http:
http1MaxPendingRequests: 50 # 대기 큐 최대 크기
http2MaxRequests: 100 # 최대 동시 요청 수
maxRequestsPerConnection: 10 # 연결당 최대 요청 수
maxRetries: 3 # 최대 동시 재시도 수연속적으로 에러를 반환하는 인스턴스를 로드 밸런싱 풀에서 일시적으로 제거합니다.
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
name: reviews
spec:
host: reviews
trafficPolicy:
outlierDetection:
consecutive5xxErrors: 5 # 연속 5xx 에러 5회 시
interval: 10s # 10초 간격으로 확인
baseEjectionTime: 30s # 30초간 풀에서 제거
maxEjectionPercent: 50 # 최대 50%까지만 제거Outlier Detection 동작 흐름:
[인스턴스 A] 정상 ──→ 로드 밸런싱 풀에 유지
[인스턴스 B] 5xx x 5 ──→ 풀에서 제거 (30초)
[인스턴스 C] 정상 ──→ 로드 밸런싱 풀에 유지
30초 후: [인스턴스 B] 다시 풀에 추가 → 또 실패 시 제거 시간 증가
일시적인 네트워크 오류나 서버 에러에 대해 자동으로 재시도합니다.
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- route:
- destination:
host: reviews
retries:
attempts: 3 # 최대 3회 재시도
perTryTimeout: 2s # 각 시도당 타임아웃
retryOn: 5xx,reset,connect-failure,retriable-4xx재시도는 양날의 검입니다. 일시적 장애에는 효과적이지만, 대상 서비스가 과부하 상태일 때 재시도가 부하를 더 가중시킬 수 있습니다. 반드시 서킷 브레이커와 함께 사용하세요.
요청이 지정 시간 내에 응답하지 않으면 실패로 처리합니다.
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- route:
- destination:
host: reviews
timeout: 5s # 5초 타임아웃프로덕션과 유사한 환경에서 장애 상황을 인위적으로 재현하여 시스템의 회복 탄력성을 검증합니다.
응답에 인위적인 지연을 추가합니다.
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- fault:
delay:
percentage:
value: 10 # 10% 요청에
fixedDelay: 5s # 5초 지연 주입
route:
- destination:
host: reviewsHTTP 에러 응답을 인위적으로 반환합니다.
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- fault:
abort:
percentage:
value: 5 # 5% 요청에
httpStatus: 503 # 503 에러 반환
route:
- destination:
host: reviews폴트 인젝션은 카오스 엔지니어링의 기본 도구입니다. 서킷 브레이커, 재시도, 폴백 로직이 실제로 작동하는지 검증할 수 있습니다.
실제 트래픽의 복사본을 새 버전으로 보내어, 실사용자에게 영향 없이 새 버전을 검증합니다. 미러링된 요청의 응답은 버려집니다.
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- route:
- destination:
host: reviews
subset: v1
mirror:
host: reviews
subset: v2
mirrorPercentage:
value: 100 # 100% 미러링트래픽 미러링 흐름:
클라이언트 ─→ [Envoy] ─→ reviews v1 (실제 응답 반환)
│
└──→ reviews v2 (응답 무시, 로그/메트릭만 확인)
트래픽 미러링은 카나리 배포 이전 단계로 유용합니다. 실제 프로덕션 트래픽 패턴으로 새 버전의 에러율, 지연, 리소스 사용량을 측정한 후 카나리 배포를 시작하면 리스크를 최소화할 수 있습니다.
실제 프로덕션에서는 여러 기능을 조합하여 안전한 배포 파이프라인을 구성합니다.
배포 파이프라인:
1. 미러링 (Shadow)
v1: 100% 실제 트래픽
v2: 100% 미러 트래픽 (응답 무시)
→ v2 메트릭 확인, 에러 없으면 다음 단계
2. 카나리 (1%)
v1: 99%, v2: 1%
→ 실제 사용자 트래픽으로 검증
3. 카나리 (10%)
v1: 90%, v2: 10%
→ 에러율/지연 시간 비교
4. 블루-그린 전환
v1: 0%, v2: 100%
→ v1을 롤백 대비로 유지
5. 정리
v1 Pod 제거
이 과정을 자동화하는 도구로 Flagger나 Argo Rollouts가 있으며, Istio의 트래픽 관리 CRD와 연동하여 메트릭 기반 자동 롤아웃/롤백을 수행합니다.
다음 장에서는 경량 서비스 메시를 표방하는 Linkerd의 철학과 아키텍처를 살펴보겠습니다.
이 글이 도움이 되셨나요?
Istio의 내부 아키텍처, Ambient 모드와 사이드카 모드의 비교, 설치와 기본 설정까지 Istio의 핵심을 깊이 있게 분석합니다.
Linkerd의 설계 철학, Rust 기반 마이크로 프록시 아키텍처, 설치와 운영, 그리고 Istio와의 비교를 통해 Linkerd의 강점을 분석합니다.
서비스 메시의 핵심 구성요소인 데이터 플레인과 컨트롤 플레인의 역할, Envoy 프록시의 내부 구조, 그리고 다양한 배포 모델을 분석합니다.