[k8s] Rolling / Canary / Blue-green 배포

서비스에 k8s 적용 간, 배포 방식에 관하여 관련 레퍼런스를 읽어볼 기회가 생겼습니다.

현대 어플리케이션은 높은 가용성과, 빠른 피드백 루프를 요구하기에,
이를 위하여 단일 서비스에 대한 전면적 배포방식보다는, 점진적이고 제어 가능한 배포 전략을 채택하는 것이 일반적이게 되었습니다.

이번 글에서는 이러한 배포의 대표적인 전략인 Canary, Rolling, Blue-Green을 살펴보도록 하겠습니다.

 

1. Canary

---

 

- Canary 배포는 전체 신규 버전을 소수의 인스턴스 혹은 소수의 사용자 그룹에게 먼저 릴리즈하여, 정상 동작 여부와 안정성을 검증한 후 점차 배포 범위를 확대하는 전략입니다.

- 이름과 비슷하게 과거, 카나리아 새를 광산에 데리고 갔던 것에서 유래하여 장애 가능성을 사전에 탐지하기 위한 접근 방식이라고 볼 수 있습니다.

 

아래는 장/단점을 간략히 요약한 글입니다.

 

장점

1. 위험 최소화
   • 초기 소수 인스턴스에 문제가 생기면 전체 서비스로의 확산을 방지하여, 기존(prev) 잘 가동되던 서비스로 롤백을 할 수 있습니다.
2. 실제 트래픽 기반 검증
   • 테스트 환경이 아닌 프로덕션 트래픽에서 모니터링을 할 수 있습니다.
3. 유연한 트래픽 제어
   • 트래픽 비율 조절을 통해 안정화 기간을 부여합니다
   • ex) 1% 검증 -> 5% 검증 -> 20% 검증

단점

1. 복잡도 증가
   • 트래픽 분할, A/B 테스트 로직, 모니터링 컴포넌트가 추가적으로 필요합니다.
2. 리소스 중복
   • 구 버전(Stable)과, 새 버전(Canary)가 동시에 운영되므로 리소스 사용량이 증가합니다.

2. Rolling

---

 

- Rolling 배포는 새로운 버전을 점진적으로 도입하면서, 기존 인스턴스를 점진적으로 교체하는 전략입니다.

- 각 배치(batch)마다 일부 파드(pod)를 신규 버전으로 업그레이드하여 전체 서비스 가용성을 유지합니다.

 

 

장점

1. 무중단 배포
   • 새 인스턴스 생성 후 구 인스턴스 종료로 서비스의 끊김이 없이 배포가 가능합니다 (하지만, 이는 카나리와, blue-green도 같습니다.)
2. 비교적 단순한 구현
   • k8s의 기본 배포에서 지원하는 방식입니다.
   • 특정 deployment 전략을 취하지않으면, rolling 배포전략이 적용됩니다.
   • kubectl apply -f ~.yml을 통해 배포를 하고, 모니터링 툴을 사용하여 확인을 해보면 알 수 있습니다.

단점

1. 일관성 보장이 어려움
   • 버전이 혼재된 상태로 트래픽이 분산될 수 있어, 일관된 유지관리가 어렵습니다.
   • 파드별로 업데이트가 진행이 되기 때문에 특정 클라이언트는 이전(prev) 버전, 특정 클라이언트는 다음(next) 버전에 있는 상태로 공존할 수 있습니다.
2. 롤백 복잡도
   • 특정 배치에서 오류가 발생하였을 시에 전체 순서를 역으로 되돌리기가 어려울 수 있습니다.

 

3. Blue-Green

---

 

- Blue-Green 배포는 두 개의 동일한 프로덕션 환경을 유지하고, 트래픽을 한 환경에서 다른 환경으로 완전히 전환하는 전략입니다.

- 예를들어, Blue환경에서 기존 사용자들의 트래픽을 관리하다가, Green환경에서 새로 배포될 다음 버전의 서비스를 프로비저닝 하여 트래픽을 받을 준비가 완료되면 Blue환경의 트래픽을 Green환경으로 옮기는 전략입니다.

- 주로 Argo Rollout과 같이 사용합니다.

 

Argo Rollout? 
네이티브 쿠버네티스 배포전략은 기본적으로 롤링-업데이트 전략을 지원합니다.
하지만, 롤링 업데이트 전략에는 많은 제한이 있는데,
1. 롤아웃 속도에 대한 제어가 거의 없음
2. 새 버전으로의 트래픽 흐름을 제어할 수 없음
3. 업데이트를 확인하기 위해 외부 메트릭을 쿼리하는 기능이 없음.
4. 진행을 중단할 수는 있지만 업데이트를 자동으로 중단 및 롤백할 수 없음.

이러한 문제를 보완하기위해 Blue/green, canary 및 자동 롤백, 수동 판단 등의 고급 배포 기능을 지원하는 k8s controller이자, CRDs세트가 나오게 되었습니다.

Ref : https://argoproj.github.io/rollouts/

 

 

장점

1. 단순한 트래픽 전환
   • 전환 시점에 스위치만 수행해주면 됩니다.
2. 빠른 롤백
   • 문제가 생기면 즉시 트래픽을 기존 환경으로 되돌리기만 하면 되므로, 롤백이 수월합니다.
3. 완전한 분리 테스트
   • 실제 프로덕션과 동일한 인프라에서 사전 검증이 가능합니다.

 

단점

1. 리소스 낭비
   • 두 배포 환경을 동시에 운영하므로 운영 비용이 증가합니다.
2. 데이터 동기화 문제
   • stateful한 서비스 동기화가 필요합니다

 

 

정리 표

---

 

구분	Canary	Rolling	Blue-Green
트래픽 분할 방식	트래픽 비율 제어(granular)	순차 교체(batch)	전환(Switch)
장애 대응 속도	문제 확산 전차단 가능	배치별 모니터링 후 중단 필요	즉시 롤백 가능
리소스 요구량	구 버전+소수 신규 버전 중복 운영	최대 Surge 수만큼 중복 운영	전체 Blue+Green 동시 운영
복잡도	높음	중간	낮음 또는 중간
구현 편의성	서비스 메시 활용 권장	Kubernetes 기본 지원	환경 완전 분리 필요

 

 

 

마무리

모든 전략이 무중단을 지원하나, 무중단배포의 사용 편의성은 Rolling > Canary > Blue-Green순이라고 보시면 됩니다.
(Rolling은 기본적인 k8s의 배포방식이므로 별다른 조치가 필요 없음)
어느 하나가 무조건 좋다 나쁘다의 문제가 아닌, 각 상황에 맞는 배포전략을 택하면 좋을 문제인것같습니다.
소규모 팀이거나, 예산에 제약이 있다면 Rolling배포로 시작을 하며 k8s의 기본기능을 활용하다가, 서비스의 규모가 커지면서 점차 blue-green 혹은 canary 배포전략을 택하는것을 고려하는것도 괜찮을 것 같습니다.
이러한 deploymeny 전략들은 적절한 모니터링 체계(Prometheus, Grafana)와, 자동화 도구(Terraform, Helm)와 결합하여 전략을 잘 설계하는것이 중요합니다.
상황에 맞는 배포전략을 잘 선택하셔서 성공적인 서비스를 운영하시면 좋겠습니다.
혹여, 글에 틀린 정보가 있거나, 피드백을 주시고 싶으시다면 댓글에 남겨주세요. 겸허히 수용하겠습니다
감사합니다.

Reference
- Martin Fowler, “Canary Release”: https://martinfowler.com/bliki/CanaryRelease.html
- Kubernetes 공식 문서, Rolling Update : https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment
- AWS CodeDeploy Blue/Green 배포: https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configuration-blue-green.html