배포 전략 Rolling Blue-Green Canary
3줄 요약
- 배포 전략은 새 버전을 얼마나 빨리 내보낼지가 아니라 실패 반경과 되돌리는 방법을 정하는 운영 판단이다.
- Rolling은 기존 버전과 새 버전이 섞이는 시간을 관리하고, Blue-Green은 전체 환경 전환과 즉시 복귀를 관리하며, Canary는 지표를 보며 트래픽을 점진적으로 늘린다.
- 백엔드 개발자는 Spring health, smoke test, error rate, latency, DB migration 호환성, rollback target을 배포 전부터 설명할 수 있어야 한다.
핵심 정리
- Rolling Deployment는 인스턴스를 조금씩 교체한다. 새 버전과 이전 버전이 동시에 트래픽을 받으므로 API, 설정, DB schema가 양쪽에 모두 맞아야 한다.
- Blue-Green Deployment는 green 환경을 미리 준비한 뒤 트래픽을 한 번에 전환한다. 빠른 복귀가 장점이지만 두 환경의 설정 drift와 비용을 관리해야 한다.
- Canary는 새 버전에 적은 트래픽을 먼저 보내고 지표가 안정적일 때만 비율을 올린다. 중단 조건이 없으면 단순한 느린 배포가 된다.
- Rollback은 애플리케이션 버전만 되돌리는 일이 아니다. DB migration, message format, cache key, 외부 API contract가 이전 버전과 호환되어야 한다.
- 배포 전후 검증 체크리스트는 담당자 기억이 아니라 실행 명령, 기대값, 중단 조건, 관측 창, 복구 기준을 고정하는 문서다.
헷갈리는 지점
- Blue-Green이면 rollback이 항상 쉽다고 생각하기 쉽다.
- 핵심은 트래픽만 되돌리는 것은 쉽지만 이미 적용된 DB 변경이나 외부 side effect는 되돌리기 어렵다는 점이다.
- Canary는 트래픽 비율만 나누면 된다고 생각하기 쉽다.
- 핵심은 error rate, latency, business metric, log sample을 보고 다음 단계로 갈지 멈출지 결정해야 한다는 점이다.
- Rolling은 무중단 배포라고만 외우기 쉽다.
- 핵심은 old/new 버전이 공존하는 동안 호환성이 깨지면 일부 사용자만 실패할 수 있다는 점이다.
확인 질문
- Rolling 배포에서 가장 먼저 확인할 호환성은 무엇인가?
- 이전 버전과 새 버전이 같은 DB schema, message format, cache key, API contract로 동시에 동작할 수 있는지다.
- Canary를 다음 단계로 올리는 기준은 무엇인가?
- 정해진 관측 시간 동안 error rate, latency, health, 핵심 API smoke test, business metric이 기준 안에 있어야 한다.
- Rollback 전에 반드시 확인할 것은 무엇인가?
- 되돌릴 artifact, 현재 배포된 version, DB migration 적용 여부, 이전 버전 호환성, 트래픽 전환 방법이다.