새 버전을 운영 환경에 내보내는 방식을 비교한다. 어떤 방식이든 컨테이너 · Kubernetes 환경에서는 Deployment 의 롤링 업데이트가 기본이고, 그 위에 Ingress · 서비스 메시 · 기능 플래그로 트래픽을 나눠 나머지 방식을 구현한다.
| 방식 | 무중단 | 롤백 | 트래픽 제어 | 자원 요구 | 주요 사용 |
|---|---|---|---|---|---|
| Rolling | 예 | 보통 | 낮음 | 일반 | 일반 서비스 |
| Blue-Green | 예 | 매우 쉬움 | 낮음 | 높음 (환경 2벌) | 안정성 우선 |
| Canary | 예 | 쉬움 | 높음 | 점진 | 점진 배포 · 위험 축소 |
| A/B | 예 | 보통 | 매우 높음 | 보통 | 기능 비교 · 실험 |
| Shadow | 예 | 쉬움 | 높음 (미러링) | 실부하 2배 | 성능 평가 |
| Feature Flag | 예 | 매우 쉬움 | 매우 높음 | 낮음 | 기능 단위 독립 제어 |
기존 버전 인스턴스를 하나씩(또는 일정 비율씩) 새 버전으로 교체한다. 추가 자원이 거의 들지 않고 Kubernetes Deployment 의 기본 전략(RollingUpdate, maxSurge · maxUnavailable)이다. 교체 중에는 두 버전이 함께 돌므로 API · 스키마가 하위 호환돼야 한다.
완전한 환경을 두 벌(Blue 현행, Green 신규) 두고 로드밸런서 · Ingress 의 대상만 바꿔 트래픽을 한 번에 전환한다. 문제가 생기면 대상을 되돌리는 것으로 롤백이 끝난다. 자원이 두 배 들고, 데이터베이스 마이그레이션은 양쪽이 호환되게 설계해야 한다.
새 버전을 일부 트래픽(예: 5%)에만 먼저 태워 오류율 · 지연을 확인한 뒤 비율을 늘려 간다. Ingress 가중치나 서비스 메시(Istio 등), Argo Rollouts · Flagger 같은 도구로 자동화한다.
사용자 그룹(헤더 · 쿠키 · 지역 등)별로 서로 다른 버전을 동시에 제공해 성능과 반응을 비교한다. Canary 가 위험을 줄이는 게 목적이라면 A/B 는 기능 실험이 목적이다.
실제 요청을 복제해 새 버전에도 보내되 응답은 버린다. 실부하로 성능 · 오류를 검증하고 사용자에게는 영향이 없다. 부작용이 있는 요청(결제 · 쓰기)은 걸러야 하고 백엔드 부하가 두 배가 된다.
기능을 코드 배포와 분리해 플래그(설정 값)로 켜고 끈다. 코드는 미리 배포해 두고 기능만 사용자 · 비율별로 열며, 문제가 나면 플래그를 끄는 것으로 롤백한다. 플래그가 쌓이면 코드가 복잡해지므로 정리 주기를 둔다.