Blog,Kubernetes Blog

카나리 배포는 새로운 애플리케이션 버전을 점진적으로 배포하여 시스템 안정성과 사용자 경험을 보호하는 전략입니다. 새로운 버전을 소수의 사용자에게 먼저 제공해 보고, 문제가 없다고 판단될 경우 점차 트래픽을 늘려 전체 사용자에게 배포하는 방식입니다. 이는 대규모 시스템에서 갑작스러운 장애나 성능 저하를 방지하고, 안정적인 운영을 유지하는 데 필수적인 기법이라 할 수 있습니다.

카나리 배포라는 용어는 광부들이 탄광 안에서 유독 가스를 감지하기 위해 카나리아 새를 사용했던 것에서 유래했습니다. 카나리아는 유독 가스에 매우 민감하게 반응하여 광부들이 위험을 미리 감지하고 대처할 수 있도록 도왔습니다. 이와 마찬가지로, 카나리 배포는 새로운 버전의 서비스를 소규모 사용자에게 먼저 배포하여 문제 발생 여부를 확인하고, 문제가 없을 때 점진적으로 전체 사용자에게 확대 배포하는 방식입니다.

기존의 전통적인 배포 방식은 한 번에 모든 인스턴스를 새로운 버전으로 교체하는 방식(블루-그린 배포 혹은 빅뱅 배포)으로, 문제가 발생하면 전체 시스템이 다운될 위험이 컸습니다. 이러한 위험을 해결하기 위해, 소규모 트래픽에 대해 점진적으로 배포하여 문제를 미리 탐지하는 방식이 도입되었으며, 이러한 개념은 실제로 탄광에서 유독가스를 감지하기 위해 카나리아를 사용했던 사례에서 영감을 얻었습니다. 즉, 새로운 환경에서 먼저 작은 그룹이 테스트를 진행하고 이상이 없을 때 전체 적용하는 방식이 소프트웨어 배포에도 도입된 것입니다.

카나리 배포는 단순한 기술적 기법이 아니라 시스템 신뢰성 확보를 위한 철학적 접근입니다. 이 전략의 핵심은 제어된 환경에서의 실패 허용에 있으며, 이는 현대 분산 시스템 운영의 패러다임 변화를 반영합니다. 트래픽 분할 비율(예: 5% → 25% → 50% → 100%)을 점진적으로 확대하면서 다음 요소들을 종합적으로 평가합니다.

• 애플리케이션의 성능: 새로운 버전이 기존 버전과 비교하여 성능 저하 없이 동작하는지 확인합니다.
• 오류율: 새로운 버전에서 발생하는 오류의 빈도를 모니터링하여 서비스 안정성을 평가합니다.
• 사용자 경험: 새로운 버전이 사용자에게 미치는 영향을 분석하고, 사용자 불편을 최소화합니다.
• 인프라 리소스 사용량: 새로운 버전이 시스템 리소스를 효율적으로 사용하는지 확인합니다.

카나리 배포는 단순히 새로운 버전을 배포하는 것을 넘어, 서비스의 안정성을 검증하고 위험을 관리하는 데 목적이 있습니다. 배포 과정에서 발생하는 잠재적인 문제들을 조기에 발견하고 대응함으로써, 전체 서비스에 미치는 영향을 최소화할 수 있습니다. 또한, 사용자 경험에 미치는 영향도 최소화하면서 서비스를 지속적으로 개선할 수 있다는 장점이 있습니다.

카나리 배포가 반드시 필요한 이유는 다음과 같습니다.

첫째, 시스템 장애 가능성을 최소화할 수 있습니다. 새로운 버전이 갑작스럽게 전체 서비스에 반영되면 예기치 못한 오류로 인해 대규모 장애가 발생할 수 있습니다. 그러나 카나리 배포를 활용하면 일부 사용자에게만 적용해 먼저 검증할 수 있기 때문에 서비스의 안정성을 높일 수 있습니다.

둘째, 실시간 사용자 데이터를 기반으로 새로운 버전의 성능을 평가할 수 있습니다. QA 환경에서 발견하지 못한 문제를 실제 트래픽에서 검증할 수 있는 기회를 제공합니다.

셋째, 배포 전략을 유연하게 가져갈 수 있습니다. 버전 간 성능 차이를 비교하고, 필요하면 특정 사용자 그룹에게만 지속적으로 제공하는 방식으로 운영할 수도 있습니다.

Deployment 리소스를 활용하면 새로운 애플리케이션 버전을 점진적으로 배포할 수 있습니다. Kubernetes의 ReplicaSet을 이용하여 새로운 버전의 Pod를 일부만 생성한 후, 점진적으로 확장하면서 기존 버전을 교체하는 방식입니다. 이를 통해 서비스 가용성을 유지하면서 안전하게 배포할 수 있습니다.

1. 새로운 버전 배포

• • 기존 Deployment의 spec.template을 새로운 버전의 컨테이너 이미지로 변경합니다.
  • Kubernetes는 자동으로 새 ReplicaSet을 생성하고 설정된 비율에 따라 Pod를 신규 버전으로 전환합니다.

2. 기존 버전과 공존

• • 새 버전이 정상적으로 동작하는지 확인하기 위해 기존 버전의 Pod 일부를 유지합니다.
  • 설정된 maxSurge(최대 추가 생성 Pod 개수) 및 maxUnavailable(최대 중지 Pod 개수) 값에 따라 Pod 교체가 진행됩니다.

3. 트래픽 분산 및 검증

• • 신규 Pod가 트래픽을 정상적으로 처리하는지 확인하고, 문제 발생 시 롤백할 수 있도록 설정합니다.
  • 필요할 경우 kubectl rollout undo deployment <deployment-name> 명령으로 롤백이 가능합니다.

• 배포된 새 버전의 Pod가 부하를 감당할 수 있는지 확인하기 위해 HPA를 적용할 수 있습니다.

• HPA는 CPU, 메모리 사용량 등을 모니터링하여 자동으로 Pod 수를 조정합니다.

• 이를 통해 트래픽이 급증하는 경우에도 새 버전의 안정성을 검증할 수 있습니다.

새로운 버전을 도입할 때 트래픽을 어떻게 분산할 것인지가 매우 중요합니다. 이를 위해 Ingress 또는 Service Mesh를 활용할 수 있습니다.

• Istio의 VirtualService는 트래픽을 특정 버전의 서비스(Pod)로 보낼 수 있도록 설정하는 리소스입니다.
• DestinationRule과 함께 사용하면 새로운 버전으로 특정 비율만큼의 트래픽을 전달할 수 있습니다.
• 설정 예시는 다음과 같습니다.

• 위 설정에서는 기존 v1 버전에 90%의 트래픽을 보내고, 새로운 v2 버전에는 10%만 전달하도록 트래픽을 조정합니다.

• Istio는 Envoy Proxy를 기반으로 하며, 이를 활용해 실시간으로 트래픽을 조정할 수 있습니다.
• 문제가 발생하면 VirtualService의 설정을 즉시 변경하여 기존 버전으로 트래픽을 다시 전송(롤백) 할 수 있습니다.
• 별도의 배포 없이 설정 변경만으로 빠른 롤백이 가능하다는 장점이 있습니다.

Argo Rollouts는 Kubernetes 네이티브 방식의 카나리 배포 및 블루-그린 배포를 지원하는 도구입니다.

• 기존 Deployment 대신 Rollout 리소스를 사용하여 보다 세밀한 배포 전략을 적용할 수 있습니다.
• 트래픽을 점진적으로 새로운 버전으로 이동시키면서 자동 검증 및 롤백 기능을 지원합니다.

1. Rollout 리소스 정의

• • spec.strategy.canary를 사용하여 카나리 배포 방식을 설정합니다.

2. 점진적인 트래픽 이동

• • 처음에는 10%만 새 버전으로 보내고, 이상이 없으면 50%, 100% 순으로 이동합니다.

3. 자동 롤백 기능

• • 신규 버전에 문제가 발생하면 자동으로 이전 버전으로 롤백할 수 있습니다.

• setWeight를 통해 트래픽을 단계적으로 증가시킬 수 있습니다.
• pause 설정을 통해 각 단계에서 검증 후 진행할 수 있도록 합니다.
• Argo Rollouts는 자동화된 롤백 기능을 제공하므로, 새 버전이 정상적으로 동작하지 않을 경우 자동으로 이전 버전으로 복구할 수 있습니다.

이러한 방법들을 조합하면 안정적인 점진적 배포 전략을 설계할 수 있습니다.

특히 Argo Rollouts와 Service Mesh(Istio)를 함께 활용하면 자동화된 트래픽 제어 및 롤백이 가능하여 더욱 신뢰성 높은 배포를 할 수 있습니다.

카나리 배포는 마이크로서비스 아키텍처 환경에서 필수적인 배포 전략입니다. Kubernetes의 Deployment 리소스, Ingress, Service Mesh, 그리고 Argo Rollouts와 같은 도구들을 적절히 활용하면 카나리 배포를 보다 효율적으로 구현하고 관리할 수 있습니다. 이러한 기술들을 심도 있게 이해하고 적용하여 안정적이고 지속 가능한 서비스를 제공할 수 있기를 바랍니다.