[Kubernetes] 레이블(Lable)을 이용한 카나리(Canary) 배포를 위한 배포 전략 비교
안녕하세요, 저는 최근 쿠버네티스(Kubernetes)를 공부하며 본격적으로 배포 실습을 진행해보고 있습니다.
(Kubernetes를 공부하며 실습하는 과정에서 작성한 실습용 예제 코드들은 GitHub repo: Kubernetes_study 에 정리하고 있습니다.)
배포시 레이블(Lable)을 이용하여 각 리소스별로 자원을 구분해가며 다양한 배포 전략으로 배포를 진행해보는 실습을 하다가, 배포 전략에 대해 한번 정리해두면 좋을것 같아 아래와 같이 정리하게 되었습니다.
1. 배포 전략의 종류
파드를 새 버전으로 배포(업데이트)하는 방법에는 크게 3가지 전략이 있습니다.
- 롤링(Rolling) 업데이트 ⇒ 하나씩 업데이트하기(가장 많이 쓰임)
- 카나리(Canary) 업데이트 ⇒ 일부만 업데이트하고 유지하기(대부분 예전버전 유지)
- 블루(Blue, OLD)-그린(Green, NEW) 업데이트 ⇒ 한꺼번에 업데이트하기(다운 타임 없이 진행)
배포 전략으로 많이 사용되는 롤링 업데이트, 카나리 업데이트, 블루-그린 업데이트는 각각의 특성과 장단점이 존재합니다. 따라서, 배포 전략을 선택 시에는 프로젝트의 요구사항, 팀의 기술 역량, 예산 등의 조건들이 함께 검토되어야 합니다.
(1) 롤링 업데이트(Rolling Update)
(a) 정의: 서비스 인스턴스를 순차적으로 업데이트하여 점진적으로 새로운 버전을 배포하는 방식
(b) 장점:
- 무중단 배포 가능: 한번에 모든 인스턴스를 업데이트하지 않으므로 다운타임이 거의 없다.
- 리소스 효율적: 추가적인 인프라가 필요하지 않다.
- 간단한 관리: 자동화 도구(kubernetes)로 쉽게 구현 가능하다.
(c) 단점:
- 롤백이 복잡: 문제가 발생하면 이미 업데이트된 인스턴스를 원래 상태로 되돌려야 하므로 복잡할 수 있다.
- 중간 상태의 위험성: 업데이트 중 일부 인스턴스는 새로운 버전, 일부는 이전 버전을 실행하게 되어 비일관성 문제가 발생할 수 있다.
- 모니터링 필요: 업데이트 과정에서 문제가 발생하지 않도록 세밀한 모니터링이 필요하다.
(2) 카나리 배포
(a) 정의: 새 버전을 일부 사용자(또는 트래픽)에만 배포하여 영향을 제한적으로 테스트한 후 점진적으로 확장하는 방식
(b) 장점:
- 안정성: 새 버전의 문제가 제한된 사용자 그룹에서만 발생하므로 리스크를 줄일 수 있다.
- 실시간 피드백: 새 버전에 대한 성능과 안정성을 실사용 환경에서 테스트할 수 있다.
- 롤백 용이: 문제가 발생하면 새 버전을 사용하는 트래픽만 이전 버전으로 전환하면 된다.
(c) 단점:
- 트래픽 분배 설정의 복잡성: 트래픽 라우팅을 세밀하게 조정해야 하며, 추가적인 네트워크 구성이 필요하다.
- 시간 소모: 전체 사용자로 확대하기까지 시간이 더 걸릴 수 있다.
- 특정 사용자 경험: 일부 사용자만 새 버전을 사용하므로 예상치 못한 사용자 불만이 있을 수 있다.
(3) 블루-그린 업데이트
(a) 정의: 두 개의 환경(Blue: 현재 운영 중인 환경, Green: 새로운 버전 환경)을 사용하여 전환 시 전체 트래픽을 새 버전으로 이동하는 방식
(b) 장점:
- 무중단 배포: Blue 환경이 가동 중인 동안 Green 환경을 준비하므로 다운 타임 없이 배포가 가능하다.
- 빠른 롤백: 문제가 발생하면 즉시 Blue 환경으로 트래픽을 전환할 수 있다.
- 테스트 용이: Green 환경에서 새 버전을 충분히 테스트할 수 있다.
(c) 단점:
- 높은 비용: 두 개의 환경을 동시에 유지하므로 리소스와 비용이 증가한다.
- 복잡성 증가: 별도의 환경 구성 및 관리가 필요하다.
- 데이터 동기화 문제: 데이터베이스나 상태가 공유되면 동기화 문제를 해결해야 한다.
2. 배포 전략 별 권장 사용 사례
| 롤링 업데이트 (Rolling Update) |
카나리 업데이트 (Canary Update) |
블루-그린 업데이트 (Blue-Green Update) |
| (사례) 리소스가 제한적이고 배포 중 약간의 중간 상태를 감수할 수 있을 때 * 중간 규모 * 모니터링을 지속적으로 해줘야 함 |
(사례) 새 버전을 사용자 일부에게만 적용 해 안정성을 확인하고 싶은 경우 * A/B 테스트 가능, 성능 모니터링에 유용 * 10~20% 정도만 테스트 |
(사례) 높은 안정성과 빠른 롤백이 중요한 미션 크리티컬 시스템 * 큰 회사, 리소스 많이 필요 * 신 버전을 새로 다 구축해 놓고 한번에 전환 시키는 것 |
3. 카나리 배포(Canary Deployment) 예시
- 기존 버전을 유지한 채로 일부 버전만 신규 버전으로 올려서 신규 버전에 버그나 이상은 없는지 확인하는 방식의 업데이트
- 서비스(Service) - 디플로이먼트(Deployment) 구조 YAML 파일 예시
| 기존 버전: |
apiVersion: apps/v1 kind: Deployment metadata: name: mainui-stable spec: replicas: 2 selector: matchLabels: app: mainui version: stable ..... |
|
| 서비스 요청 ⇒ | apiVersion: v1 kind: Service metadata: name: mainui-svc spec: selector: app: mainui |
|
| 업데이트 버전: |
apiVersion: apps/v1 kind: Deployment metadata: name: mainui-stable spec: replicas: 1 selector: matchLabels: app: mainui version: canary ..... |
4. 비교 요약
| 특성 | 롤링 업데이트 | 카나리 업데이트 | 블루-그린 업데이트 |
| 무중단 배포 | 가능 | 가능 | 가능 |
| 리스크 관리 | 중간 | 높음 | 높음 |
| 롤백 용이성 | 낮음 | 높음 | 매우 높음 |
| 비용 효율성 | 높음 | 중간 | 낮음 |
| 구현 복잡성 | 낮음 | 중간 | 높음 |
[참고]
https://reference-m1.tistory.com/211