Canary vs. Blue-Green 배포 전략 비교 및 Kubernetes 적용 가이드

Canary 배포 vs. Blue-Green 배포 전략 비교 및 Kubernetes 적용

이 문서는 안정적인 서비스 배포를 위한 Canary 배포와 Blue-Green 배포 전략을 비교하고, Kubernetes 환경에서 각 전략을 어떻게 적용할 수 있는지 안내합니다.

1. 배포 전략 개요

새로운 버전의 소프트웨어를 배포할 때 발생할 수 있는 위험을 최소화하고, 문제 발생 시 신속하게 대응하기 위해 다양한 배포 전략이 사용됩니다. Canary 배포와 Blue-Green 배포는 대표적인 무중단 배포 전략입니다.

1.1. Canary 배포

• 개념: 새로운 버전(Canary)을 전체 사용자 중 일부에게만 먼저 배포하여, 실제 운영 환경에서의 성능 및 안정성을 점검하는 방식입니다. 성공적이면 점진적으로 전체 사용자에게 배포를 확대합니다.
• 장점: 실제 사용자 트래픽을 통해 검증하므로 실환경에서의 문제점을 조기에 발견할 수 있습니다. 롤백이 용이하며, 점진적 배포로 인한 위험이 낮습니다.
• 단점: 트래픽 분할 및 관리가 복잡할 수 있습니다. 모든 사용자에게 동시에 배포되지 않으므로, 초기 피드백을 받기까지 시간이 더 걸릴 수 있습니다.
• 주요 활용: 서비스 중단 없이 점진적으로 신규 기능을 출시하거나, 성능 변화를 민감하게 모니터링해야 할 때 유용합니다.

1.2. Blue-Green 배포

• 개념: 현재 운영 중인 환경(Blue)과 완전히 동일한 새 환경(Green)을 준비합니다. 새 버전은 Green 환경에 배포하고, 테스트 완료 후 모든 트래픽을 Blue에서 Green으로 전환합니다. 문제가 발생하면 즉시 트래픽을 다시 Blue로 되돌립니다.
• 장점: 배포 과정이 단순하고, 롤백이 매우 빠릅니다. 서비스 중단 시간이 거의 발생하지 않습니다.
• 단점: 운영 환경과 동일한 규모의 추가 환경이 필요하므로 리소스 비용이 증가할 수 있습니다. 두 환경을 동시에 운영해야 하는 기간 동안 동기화 이슈가 발생할 수 있습니다.
• 주요 활용: 서비스 중단이 절대적으로 허용되지 않거나, 롤백이 매우 신속해야 하는 미션 크리티컬한 서비스에 적합합니다.

2. Kubernetes 환경에서의 적용

Kubernetes는 다양한 배포 전략을 유연하게 지원합니다. 주로 Deployment, Service, Ingress 리소스를 활용하여 구현합니다.

2.1. Canary 배포 적용 (Istio, Argo Rollouts 활용)

Kubernetes 네이티브 기능만으로는 Canary 배포 구현이 복잡할 수 있어, 서비스 메시(Service Mesh)나 배포 자동화 도구를 활용하는 것이 일반적입니다.

• Istio:

  • VirtualService 및 DestinationRule을 사용하여 트래픽을 여러 버전의 서비스(Deployment)로 분할합니다.
  • 예시: VirtualService에서 신규 버전 Deployment로 10% 트래픽을 보내고, 90%는 기존 버전으로 유지합니다.
  • 헬스 체크 및 롤백 자동화는 추가 설정이 필요할 수 있습니다.

• Argo Rollouts:

  • Kubernetes 네이티브 Deployment를 대체하는 Rollout 리소스를 제공합니다.
  • Canary, Blue-Green 등 다양한 고급 배포 전략을 선언적으로 정의하고 자동화합니다.
  • analysisTemplate을 통해 Prometheus, Datadog 등 외부 모니터링 도구와 연동하여 자동 롤백 기능을 구현할 수 있습니다.

  # Argo Rollouts 예시 (개념)
  apiVersion: argoproj.io/v1alpha1
  kind: Rollout
  metadata:
    name: my-app-rollout
  spec:
    replicas: 3
    strategy:
      canary:
        steps:
        - setWeight: 10
        - pause: { duration: 5m }
        - setWeight: 50
        - pause: { duration: 5m }
    template:
      spec:
        containers:
        - name: nginx
          image: nginx:1.21.6
          ports: [containerPort: 80]
    # ... (version, analysisTemplate 등 추가 설정)
  

2.2. Blue-Green 배포 적용 (Service, Ingress 활용)

Blue-Green 배포는 Kubernetes의 Service와 Ingress를 조합하여 비교적 간단하게 구현할 수 있습니다.

• 방법:

  1. Deployment를 두 개 준비합니다: my-app-blue (기존 버전)와 my-app-green (신규 버전).
  2. Service를 두 개 생성합니다: my-app-blue-svc (blue Deployment를 가리킴) 및 my-app-green-svc (green Deployment를 가리킴).
  3. Ingress 리소스를 사용하여 모든 트래픽을 my-app-blue-svc로 향하게 설정합니다.
  4. 신규 버전 테스트가 완료되면, Ingress 리소스의 service.name을 my-app-green-svc로 변경하여 트래픽을 전환합니다.
  5. 문제가 발생하면 Ingress 설정을 다시 my-app-blue-svc로 되돌립니다.

  # Ingress 예시 (트래픽 전환)
  apiVersion: networking.k8s.io/v1
  kind: Ingress
  metadata:
    name: my-app-ingress
  spec:
    rules:
    - http:
        paths:
        - path: /
          pathType: Prefix
          backend:
            service:
              name: my-app-blue-svc  # <-- 이 부분을 my-app-green-svc로 변경
              port:
                number: 80
  

3. 고려사항 및 모범 사례

• 모니터링 및 로깅: 배포 전후의 서비스 성능, 에러율, 응답 시간 등을 면밀히 모니터링해야 합니다. Prometheus, Grafana, ELK Stack 등의 도구를 활용하세요.
• 헬스 체크: Kubernetes의 Liveness Probe 및 Readiness Probe를 정확하게 설정하여, 비정상적인 Pod는 자동으로 격리하고 트래픽을 받지 않도록 합니다.
• 롤백 전략: 각 배포 전략에 맞는 롤백 절차를 명확히 정의하고 자동화하는 것이 중요합니다. Argo Rollouts는 이를 위한 강력한 기능을 제공합니다.
• CI/CD 연동: Jenkins, GitHub Actions, GitLab CI 등 CI/CD 도구와 통합하여 배포 프로세스를 자동화합니다. Terraform이나 Helm Chart를 사용하여 인프라 및 애플리케이션 구성을 관리하는 것이 좋습니다.
• 시크릿 관리: 배포 과정에서 민감한 정보(API 키, DB 비밀번호 등)는 Kubernetes Secrets 또는 Vault와 같은 별도의 시크릿 관리 도구를 사용하여 안전하게 관리해야 합니다.

4. 결론

Canary 배포와 Blue-Green 배포는 각각의 장단점