Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | |
7 | 8 | 9 | 10 | 11 | 12 | 13 |
14 | 15 | 16 | 17 | 18 | 19 | 20 |
21 | 22 | 23 | 24 | 25 | 26 | 27 |
28 | 29 | 30 |
Tags
- serverless
- terraform
- Validation
- kubernetes
- 병목
- cloudwatch
- 분산시스템
- sns
- IaC
- amazonqcli
- rds
- Lamda
- CHECK
- CAP
- PACELC
- fcm
- aws
- lambda
- SageMaker
Archives
- Today
- Total
잡다한 IT 지식
무중단 배포 전략 정리: Blue/Green, Rolling, Canary, Rainbow 본문
서비스 운영 환경에서 무중단 배포(Zero Downtime Deployment)는 매우 중요한 과제입니다.
사용자에게 영향을 주지 않으면서 새로운 버전을 배포하기 위해 다양한 전략들이 사용되며, 각 방식은 트래픽 전환 방식, 리소스 사용량, 롤백 전략, 배포 속도 등에 따라 차이가 있습니다.
이 글에서는 대표적인 배포 전략인 Blue/Green, Rolling, Canary, Rainbow 방식을 개념부터 장단점까지 일관된 흐름으로 정리합니다.
1. Blue/Green 배포
Blue/Green 배포는 두 개의 독립된 배포 환경(Blue, Green)을 운영하여, 새로운 버전을 별도의 환경에 배포한 뒤 트래픽을 전환하는 방식입니다.
- Blue: 현재 운영 중인 기존 버전
- Green: 새로운 버전이 배포되는 환경
배포 흐름
- Green 환경에 새로운 버전을 배포
- 상태 확인 후 Blue → Green으로 트래픽 전환
- 전환 완료 후 Blue 환경을 종료하거나 대기 상태 유지
- Green 문제 발생 시 Blue로 신속한 롤백 가능
장점
- 모든 사용자가 동일한 버전을 사용함
- 트래픽 전환이 빠르며 롤백이 쉬움
- 무중단 배포 구현이 쉬움
단점
- 리소스 비용이 2배 필요 (두 환경 운영)
- 긴 작업이 있을 경우 전환 타이밍이 늦어질 수 있음
2. Rolling 배포
Rolling Deployment는 무중단 배포를 유지하면서 점진적으로 새 버전을 적용해 나가는 방식입니다.
배포 알고리즘
- 새 버전을 하나 배포
- 해당 인스턴스의 상태가 Healthy해질 때까지 대기
- 이전 버전 하나를 종료
- 종료되지 않은 이전 버전이 남아 있다면 반복
장점
- 지원 도구가 많음: Kubernetes, AWS Elastic Beanstalk 등에서 기본 제공
- 리소스 효율적: 동시에 배포되는 인스턴스 수가 제한됨 → Blue/Green 대비 자원 소모 적음
- 롤백 쉬움: 새 버전 인스턴스를 종료하고 이전 버전을 다시 기동하면 됨
단점
- 속도: 배포가 순차적으로 진행되므로 전체 적용까지 시간이 오래 걸릴 수 있음
- API 호환성 문제: 구버전과 신버전이 동시에 존재하므로, API 간 버전 호환이 반드시 보장되어야 함
3. Canary 배포
Canary Deployment는 새로운 버전을 일부 사용자에게만 먼저 배포해 문제 발생 여부를 판단한 후 점진적으로 전체 사용자로 확장하는 전략입니다.
특징
- 사용자 중 일부(예: 5%)만 새로운 버전을 사용
- 피드백을 수집한 뒤 점진적으로 트래픽 확장
- 이상이 발생하면 빠르게 롤백
장점
- 배포 안정성 높음
- 리스크를 최소화하며 점진적 배포 가능
단점
- 모니터링 및 조건 정의가 필수
- 운영 자동화가 미흡하면 실수로 전체 전파될 위험 존재
4. Rainbow 배포
Rainbow Deployment는 Blue/Green의 확장 개념으로, 여러 개의 버전을 동시에 병행 운영할 수 있는 전략입니다.
주요 특징
- 빨강, 주황, 노랑, 초록 등 다양한 버전이 공존
- 각 버전은 특정 트래픽 또는 작업을 분담
- 비동기 작업(예: 영상 인코딩, 크롤링 등)처럼 클러스터 간 이전이 어려운 작업에 유리
장점
- 다양한 버전 테스트 가능
- 병렬 배포 및 작업 분산에 적합
단점
- 복잡도 증가: 버전 수가 많아지면 테스트, 모니터링, 운영 난이도 상승
5. Shared Resource 개념
위 전략들을 설계할 때 반드시 고려해야 할 요소 중 하나는 공유 리소스와 배포 대상 리소스의 구분입니다.
- Shared Resources
- 배포 환경과 관계없이 공통 사용되는 자원
- 예: Database, Messaging Queue, S3, DNS Zone 등
- Cluster Resources
- 각 버전 환경(Blue, Green, Canary 등)에 종속된 자원
- 예: 애플리케이션 인스턴스, 설정 값, 캐시 등
리소스 분리는 버전 간 충돌 방지, 롤백 속도 개선, 데이터 정합성 유지에 중요한 역할을 합니다.
배포 전략 비교 요약
전략 | 방식 | 리소스 효율 | 배포 속도 | 롤백 용이성 | 실시간 검증 | 운영 복잡도 |
Blue/Green | 두 환경 중 하나만 운영 | 낮음 | 빠름 | 매우 쉬움 | 불가 | 중간 |
Rolling | 점진적 교체 | 높음 | 느림 | 쉬움 | 가능 | 낮음 |
Canary | 일부 트래픽만 신버전 사용 | 높음 | 중간 | 쉬움 | 매우 용이 | 중간 |
Rainbow | 다중 버전 병렬 운영 | 중간 | 느림 | 전략적 설정 필요 | 가능 | 높음 |
'DevOps > 개념' 카테고리의 다른 글
테스트 커버리지 이해와 실습 - Code Coverage와 Branch Coverage (0) | 2025.07.04 |
---|