[Istio 가이드 ep.11] 2부 트래픽 관리 #5 | Canary 배포란? 실전 적용 방법

🔹 개요

이번 글에서는 Canary 배포 전략을 활용한 트래픽 제어 방법을 다룹니다.
**Canary 배포(Canary Deployment)**는 일부 사용자만 새로운 서비스로 라우팅하여 점진적으로 배포를 진행하는 전략입니다.
Istio에서는 VirtualService와 DestinationRule을 활용하여 Canary 배포를 쉽게 적용할 수 있습니다.

이 글에서는 Canary 배포 개념, 가중치 기반 트래픽 분배,
헤더 기반 라우팅을 활용한 Canary 배포 방법을 살펴보겠습니다.

---

🔹 1. Canary 배포란?

✅ 1.1 Canary 배포 개념

Canary 배포는 기존 서비스(Stable)와 새로운 서비스(Canary)를 동시에 운영하면서,
일부 사용자에게만 새로운 버전의 서비스를 제공하는 배포 전략입니다.

Canary 배포의 특징

• 점진적인 배포 진행 가능
• 일부 사용자에게만 Canary 버전 제공 가능
• 배포 후 이상 여부를 빠르게 감지 가능
• 문제 발생 시 Canary 버전만 롤백 가능

Canary 배포의 흐름

1. Canary(신규 버전)를 배포하지만, 기본적으로 Stable(기존 버전)만 사용자에게 제공
2. 일부 트래픽을 Canary 버전으로 전달하여 테스트 진행
3. Canary 버전이 안정적이면 트래픽을 점진적으로 증가
4. 완전히 Canary 버전으로 전환 후, Stable 버전 제거

---

🔹 2. Istio에서 Canary 배포 적용 방법

✅ 2.1 Canary 배포를 위한 DestinationRule 설정

아래 YAML은 Stable(v1)과 Canary(v2)를 구분하는 DestinationRule 설정입니다.

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: my-service
spec:
  host: my-service  # 대상 서비스 이름
  subsets:
    - name: v1  # Stable 버전 (기존 서비스)
      labels:
        version: v1
    - name: v2  # Canary 버전 (신규 서비스)
      labels:
        version: v2
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN  # 라운드 로빈 방식으로 트래픽 분배

설명:

• subsets.name: v1 → 기존 Stable 버전 서비스 정의
• subsets.name: v2 → 신규 Canary 버전 서비스 정의
• loadBalancer.simple: ROUND_ROBIN → 서버 간 트래픽을 골고루 분배

---

✅ 2.2 가중치 기반 Canary 배포 (VirtualService 적용)

아래 VirtualService는 90%의 트래픽을 기존 서비스(v1), 10%를 신규 서비스(v2)로 분배하는 설정입니다.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-service
spec:
  hosts:
    - my-service
  http:
    - route:
        - destination:
            host: my-service
            subset: v1  # 기존 서비스 (Stable)
          weight: 90  # 90% 트래픽을 기존 버전으로 전달
        - destination:
            host: my-service
            subset: v2  # 신규 서비스 (Canary)
          weight: 10  # 10% 트래픽을 신규 버전으로 전달

설명:

• weight: 90 → 기존 Stable 버전(v1)으로 90% 트래픽을 보냄
• weight: 10 → 신규 Canary 버전(v2)으로 10% 트래픽을 보냄
• Canary 버전이 안정적이면 점진적으로 트래픽 비율을 증가시킴

---

🔹 3. 헤더 기반 Canary 배포

✅ 3.1 특정 사용자만 Canary 버전을 사용하도록 설정

모든 사용자가 아닌, 특정 헤더 값이 있는 사용자만 Canary 버전으로 라우팅하는 방법입니다.
예를 들어, X-Canary-User: true 헤더가 포함된 요청만 Canary 버전으로 보냅니다.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-service
spec:
  hosts:
    - my-service
  http:
    - match:
        - headers:
            X-Canary-User:
              exact: "true"  # 특정 헤더가 있는 경우 Canary 버전으로 라우팅
      route:
        - destination:
            host: my-service
            subset: v2
    - route:
        - destination:
            host: my-service
            subset: v1  # 기본적으로 Stable 버전으로 라우팅

설명:

• headers.X-Canary-User.exact: "true" → 특정 헤더 값이 **"true"**인 요청만 Canary 버전(v2)으로 전달
• 나머지 모든 요청은 기본적으로 Stable 버전(v1)으로 전달

---

🔹 4. Canary 배포 진행 방법

1️⃣ 초기 배포 상태

• 기존 Stable 버전(v1)으로 모든 트래픽이 전달됨
• 신규 Canary 버전(v2) 배포 후, Canary 트래픽은 0%

2️⃣ Canary 트래픽 점진적 증가

• 10% → 25% → 50% → 100% 순으로 트래픽 증가

3️⃣ Canary 안정성 검증

• Canary 버전(v2)이 정상적으로 운영되면, 100% 트래픽을 Canary 버전으로 이동

4️⃣ Stable 버전(v1) 제거

• Canary 버전(v2)이 완전히 운영되면 Stable 버전(v1) 제거

5️⃣ 문제 발생 시 롤백

• 문제가 발생하면 VirtualService를 수정하여 100% 트래픽을 기존 Stable 버전(v1)으로 즉시 복구 가능

---

📌 결론

• Canary 배포는 일부 사용자에게만 새로운 서비스를 제공하는 점진적 배포 전략입니다.
• 가중치 기반 트래픽 분배를 활용하여 점진적으로 신규 버전으로 트래픽을 이동 가능합니다.
• 헤더 기반 라우팅을 사용하면 특정 사용자 그룹만 Canary 버전을 사용할 수 있도록 설정 가능합니다.
• 문제 발생 시 기존 Stable 버전으로 빠르게 롤백이 가능하여 안정적인 배포가 가능합니다.