구현하기 바빠서 넘어간 부분들을 조금이라도 정리해보고자 쓰는 TIL 시리즈입니다.
무중단배포라고 하면 일단 하나의 서버에 서비스가 중단되지 않고 계속 실행되고 배포되는 상태라고 막연히 알고 있었다. 그러나 개념을 잘못 알고 있었던 것을 최근에서야 깨닫게 되었다.
그래서 무중단배포란..
기본 개념 / 필요성
하나의 서버가 아닌, 여러 대의 서버와 로드 밸런서를 이용하여 서비스를 계속 운영하면서 새 버전을 배포하는 기술이다. 구 버전 서버가 작동 중인 상태에서 신 버전 서버를 배포하고, 모든 준비가 완료되면 트래픽을 전환하여 서비스 중단(다운타임)을 방지하는 것을 목적으로 한다.
- 서비스가 중단되는 시간(다운타임) 없이 새로운 버전의 애플리케이션을 배포하는 전략
- 무중단 배포는 하나의 서버가 아니라, 최소 두 대 이상의 서버와 로드 밸런서(트래픽 분산)를 전제로 한다.
- 로드 밸런서를 통해 트래픽을 분산하고, 구 버전 서버를 남겨두거나 신규 서버를 추가하여 단계적으로 업데이트를 진행한다.
- 필요성 : 서비스 중단은 사용자 이탈 및 비즈니스 손실로 이어지므로, 고가용성과 비즈니스 연속성을 위해 필수적이다.
무중단 배포 전략 종류
롤링 배포
무중단 배포의 가장 기본적인 방식이다.
롤링 배포는 기존 배포를 점진적으로 새 배포로 업데이트 하는 방식이며 쿠버네티스에서도 이 방법을 활용 (순차적 업데이트)
장점
- 점진적으로 업데이트하기 때문에 다음 배포로 넘어가기 전에 새 배포가 정상인지 확인하고, 비정상일 경우 롤백이 쉽다
- 추가적인 서버 자원(인스턴스)이 많이 필요하지 않아 비용 효율적
단점
- 기존/신규 버전이 모두 운영되기 때문에 호환성 문제가 발생 가능
- 모든 인스턴스가 업데이트될 때까지 구 버전과 신 버전이 공존
- 트래픽 집중: 업데이트 중 서버 수가 일시적으로 줄어들어 남은 서버에 트래픽이 몰릴 수 있다
블루/그린 배포
블루는 기존 인스턴스, 그린은 신규 인스턴스를 나타낸다. 새로운 환경을 완전히 구축하여 트래픽을 한 번에 전환하는 방식이다.
장점
- 블루(기존)와 동일한 환경으로 신규 소프트웨어로 업데이트한 인스턴스를 구성하여 새로운 그린 구성이 끝나면 로드밸런서가 트래픽을 한 번에 그린으로 전환
- 빠른 롤백: 문제가 발생하면 로드 밸런서를 다시 Blue 환경으로 전환하여 즉시 롤백이 가능합니다.
- 트래픽 전환 시 신/구 버전이 공존하지 않아 호환성 문제가 없다
단점
- 운영 환경에 필요한 컴퓨팅 자원의 2배를 준비해야한다는 점이 부담스러움
- 전체 장애 위험: 전환하는 순간 모든 사용자에게 문제가 발생할 위험이 있다
카나리 배포
옛날 광부들이 가스에 민감한 카나리 새를 이용해 가스 유출을 감지했던 것에서 유래된 배포 방식(잠재적인 문제들에 미리 대비하기 위해 나온 방식)
점진적으로 트래픽을 늘려가며 위험을 최소화하는 방식이다.
일정량 부하를 주며 테스트하여 메트릭과 모니터링을 통해 일정 수준 이상의 오류가 발생하지 않으면 배포를 계속하고,
반대의 경우에는 자동 롤백을 수행한다.
장점
- 점진적 노출: 새 버전 인스턴스를 소규모로 배포한 후, 전체 트래픽 중 일부만 신 버전으로 보냄
- 단계적 확대: 문제가 없으면 트래픽 비율을 점차 늘려가며(예: 25%, 50%, 100%) 전체 사용자에게 배포를 완료한다
- 위험 최소화: 문제가 생겨도 소수의 사용자에게만 영향을 미쳐 위험을 가장 잘 통제할 수 있다
- 실제 환경 테스트: 실제 사용자 트래픽을 통해 신규 기능에 대한 A/B 테스트가 가능
단점
- 복잡한 구현: 정교한 트래픽 라우팅 및 모니터링 시스템이 필수적이어서 구현 난이도가 높다
- 단계적으로 검증하며 진행하기 때문에 전체 배포 완료까지 시간이 오래 걸린다
무중단배포 전략별 비교
무중단배포 구축 시 어떤 배포 전략을 선택할지는 주로 자원 제약, 서비스의 안정성 요구 수준, 그리고 새로운 기능의 위험도에 따라 달라질 것이다.
| 구분 | 롤링 배포 | 블루/그린 배포 | 카나리 배포 |
| 작동 방식 | 인스턴스를 하나씩 순차적으로 구 버전에서 신 버전으로 교체 | 구 버전(Blue)과 동일한 신 버전(Green) 환경을 구축 후, 로드 밸런서를 통해 트래픽을 한 번에 전환 | 전체 사용자 중 소수(카나리)에게만 신 버전을 먼저 배포하고 점진적으로 확대 |
| 자원 효율성 | 높음 (추가 인스턴스 최소화) | 낮음 (운영 환경과 동일한 규모의 추가 자원 필요) | 보통 (소수 인스턴스만 추가) |
| 롤백 속도 | 느림 (교체된 인스턴스를 다시 구 버전으로 순차적 재배포 필요) | 매우 빠름 (로드 밸런서 스위칭만으로 즉시 구 버전으로 전환 가능) | 빠름 (카나리 트래픽만 차단/전환) |
| 신/구 버전 공존 | O (배포 기간 동안 공존) | X (전환 순간 외 공존하지 않음) | O (점진적 확대 기간 동안 공존) |
| 위험도 | 보통 (호환성 문제가 발생할 수 있으며, 전체 서버에 영향을 줌) | 낮음 (전환 전 충분한 테스트 가능) | 가장 낮음 (작은 그룹에만 위험 노출) |
| 구현 복잡도 | 가장 낮음 (쿠버네티스 등 도구에서 기본 지원) | 보통 (동일 환경 구축 및 스위칭 로직 필요) | 가장 높음 (트래픽 라우팅, 모니터링 시스템 구축 필수) |
반응형
'TIL' 카테고리의 다른 글
| [TIL] AWS와 k8s (0) | 2025.10.28 |
|---|---|
| [TIL] jakarta vs springframework Transactional (0) | 2025.10.02 |
| [TIL] Layered Architecture (0) | 2025.10.01 |
| [TIL] Java에서의 병렬 처리 (1) | 2025.09.26 |
| [TIL] 스케줄링 (@Scheduled & Quartz) (0) | 2025.09.24 |