무중단 배포(Zero-Downtime Deployment) 전략 총정리: 롤링, 블루/그린, 카나리
서비스를 운영하다 보면 새로운 기능을 배포하거나 버그를 수정해야 할 일이 빈번하게 발생합니다. 이때 서비스에 다운 타임(정지 시간)이 발생하지 않으면서 새로운 버전의 애플리케이션을 서버에 배포하는 것을 무중단 배포(Zero-Downtime Deployment)라고 합니다.
무중단 배포 패턴에는 대표적으로 순차적으로 배포하는 롤링 배포, 전체 서버를 통째로 바꾸는 블루/그린 배포, 트래픽을 순차적으로 이동시키는 카나리 배포가 존재합니다. 각 배포 방식의 특징과 선택 기준, 그리고 주의사항을 정리해 보겠습니다.
1. 롤링 배포 (Rolling Deployment)
롤링 배포는 서버를 한 대씩(혹은 그룹 단위로) 순차적으로 업데이트하는 가장 기본적인 방식입니다. 구버전에서 신버전으로 트래픽을 점진적으로 전환합니다.
- 동작 방식: 로드 밸런서에서 배포 대상 서버를 제외하고, 업데이트를 진행한 뒤 다시 로드 밸런서에 연결하는 과정을 반복합니다.
- 특징:
- 배포가 진행 중인 시점에는 구버전과 신버전이 공존하므로, 새로운 버전은 반드시 하위 호환성(Backward Compatibility)을 보장해야 합니다.
- 새로운 버전을 배포하기 위해 추가적인 인프라를 구축할 필요가 없어 비용적으로 효율적입니다.
- 배포 중인 서버는 트래픽을 받을 수 없으므로, 남은 서버들에 부하가 집중될 수 있습니다. (서버 용량에 여유가 있어야 함)
- 서버 대수가 많을 경우 배포 시간이 오래 걸릴 수 있어, 한 번에 여러 대를 배포하는 '배포 윈도우(Batch Size)' 조절이 필요합니다.
2. 블루/그린 배포 (Blue/Green Deployment)
블루/그린 배포는 기존 운영 환경(Blue)과 동일한 스펙과 사이즈의 새로운 환경(Green)을 미리 준비하고, 신규 버전을 배포한 후 트래픽을 일제히 신규 버전으로 전환하는 방식입니다.
- 동작 방식: 신규 버전(Green) 배포 및 테스트가 완료되면, 로드 밸런서나 라우터 설정을 변경하여 모든 트래픽을 Green으로 돌립니다. 기존 Blue 환경은 대기 상태로 두거나 폐기합니다.
- 특징:
- 구버전 환경(Blue)이 그대로 남아있기 때문에 문제 발생 시 즉시 롤백이 가능합니다.
- 운영 환경과 똑같은 서버 리소스를 추가로 준비해야 하므로 비용이 두 배로 발생할 수 있습니다.
- 새로운 환경으로 트래픽이 한 번에 몰리기 때문에, 서버가 예열되지 않아 초반 성능 저하가 발생할 수 있습니다. (Warm-up 과정 필요)
3. 카나리 배포 (Canary Deployment)
카나리 배포는 광산의 카나리아 새처럼 위험을 감지하기 위해 소수의 트래픽만 신규 버전으로 분산시킨 후, 문제가 없으면 점차 트래픽 비중을 늘려가는 방식입니다.
- 동작 방식: 기존 서버와 신규 서버를 구성하고 트래픽을 퍼센티지 단위로 조절합니다. (예: 기존 90%, 신규 10% -> 기존 50%, 신규 50% -> 신규 100%)
- 특징:
- 오류율이나 성능 이슈를 소규모 트래픽에서 미리 감지할 수 있어 리스크 관리에 탁월합니다.
- A/B 테스트 용도로 활용하기 좋습니다.
- 롤링 배포와 마찬가지로 특정 시점에 두 버전이 공존하므로 하위 호환성 관리가 필수입니다.
- 동일한 사용자가 새로고침할 때마다 버전이 바뀌지 않도록 스티키 세션(Sticky Session) 설정이 필요할 수 있습니다.
한눈에 보는 배포 전략 비교
| 특징 | 롤링 (Rolling) | 블루/그린 (Blue/Green) | 카나리 (Canary) |
|---|---|---|---|
| 배포 속도 | 느림 | 빠름 (즉시 전환) | 중간 (조절 가능) |
| 비용 (리소스) | 낮음 (추가 서버 불필요) | 높음 (서버 2배 필요) | 중간 |
| 롤백 난이도 | 어려움 (역배포 필요) | 쉬움 (트래픽만 원복) | 쉬움 |
| 위험도 | 중간 | 낮음 (테스트 후 전환) | 매우 낮음 (검증하며 확대) |
어떤 상황에 어떤 전략을 선택해야 할까?
각 배포 전략은 서비스의 상황과 목적에 따라 선택해야 합니다.
1. 롤링 배포를 선택하는 경우
- 비용 절감이 최우선일 때: 배포를 위해 새로운 서버를 추가로 생성하는 비용을 감수하기 어려운 경우 적합합니다.
- 소규모 버그 수정: 서버 API 구간에서 버그가 생겼을 때, 개발 서버 테스트 후 상용 환경에서 1대만 먼저 배포하여 디버그 레벨 로깅 등으로 검증하고 싶을 때 유용합니다. 문제가 없다면 순차적으로 배포를 완료합니다.
2. 블루/그린 배포를 선택하는 경우
- 대규모 업데이트: 기술 부채 해결이나 아키텍처 변경 등 시스템 전반에 큰 변화가 있을 때 적합합니다.
- 안정적인 롤백이 중요할 때: 배포 직후 치명적인 오류가 발생할 가능성이 있어 즉시 이전 버전으로 돌아가야 하는 중요한 서비스에 유리합니다.
3. 카나리 배포를 선택하는 경우
- 데이터 기반 검증이 필요할 때: 신규 기능에 대한 오류율, 성능, 사용자 반응 등을 통계적으로 확인하고 싶을 때 사용합니다.
- A/B 테스트: 특정 사용자 그룹에게만 새로운 UI나 기능을 노출하여 반응을 살피고 싶을 때 채택합니다.
무중단 배포 시 반드시 고려해야 할 기술적 요소
성공적인 무중단 배포를 위해서는 단순히 배포 방식뿐만 아니라 인프라와 데이터베이스 레벨에서의 고려가 필요합니다.
1. 데이터베이스 하위 호환성 (Database Backward Compatibility)
애플리케이션은 무중단으로 배포되더라도 DB 스키마가 변경되면 구버전 애플리케이션에서 오류가 발생할 수 있습니다. 컬럼 삭제나 변경이 필요할 경우, '컬럼 추가 -> 코드 배포 -> 데이터 마이그레이션 -> 컬럼 삭제'와 같이 단계적인 접근이 필요합니다.
2. 우아한 종료 (Graceful Shutdown)
배포를 위해 서버를 내릴 때, 진행 중이던 요청을 강제로 끊어버리면 사용자는 에러를 경험하게 됩니다. SIGTERM 신호를 받았을 때 새로운 요청은 거부하되, 기존에 처리 중이던 작업은 완료한 후 종료되도록 애플리케이션을 설정해야 합니다.
3. 헬스 체크 (Health Check)
새로 배포된 서버가 완전히 구동되지 않은 상태에서 트래픽이 유입되면 에러가 발생합니다. 로드 밸런서가 애플리케이션의 상태(Readiness Probe)를 확인하고, 정상적으로 응답할 때만 트래픽을 보내도록 설정해야 합니다.
