[인프라/CS] 무중단 배포(Rolling Update, Blue-Green, Canary)

무중단 배포란?

무중단 배포(Zero Downtime Deployment)는 서비스의 새 버전을 배포하는 동안 사용자가 서버스 중단을 거의 느끼지않도록 하는 배포 방식입니다. 일반적인 배포방식은 기존 서버를 내리고 새 서버를 올리는 동안 짧게라도 다음과 같은 문제가 생길수 있습니다.

• 사용자가 요청을 보냈는데 서버가 재시작 중이라 응답하지 못함
• WebSocket 같은 실시간 연결이 끊김
• 배포 직후 초기화가 끝나지 않아 502, 503 같은 에러가 발생함

개발 환경에서는 이와같은 끊김이 별것이 아닐수 있습니다. 배포가 이루어지는 시기와 끊기는 이유를 알고있고 작업시에는 큰 영향이 없기 때문입니다. 하지만 운영 환경에서 서비스의 사용자 입장에서 이러한 끊김은 불편과 더불어 서비스의 문제로 이어지게 됩니다. 따라서 운영 환경에서는 끊기지 않고 배포할수 있는 무중단 배포가 필요한 것이죠.

 

CI/CD와 무중단 배포

인프라를 담당할 때 CI/CD 환경을 구축한적 있었는데 저는 'CI/CD를 하면 무중단 배포되는 거 아닌가?' 라고 생각했었습니다. 최근까지 저는 CD(지속적인 배포)가 무중단 배포를 의미하는줄 알았습니다. 결론부터 말하면 CI/CD를 구축했다고 해서 자동으로 무중단이 되는건 아닙니다. 실제로 운영하면서 팀원이 일시적인 끊김을 경험했고 저또한 그 현상을 확인했습니다. CI/CD는 코드 변경 후 빌드, 테스트, 배포까지 자동화하는 흐름을 의미하고 무중단은 배포 단계에서 서비스의 끊김 없이 새 버전으로 전환하는 운영방식을 뜻합니다.

 

무중단 배포 방식

이러한 무중단 배포 방식은 여러개가 있지만 그 중 Rolling, Blue-Green, Canary 방식을 알아보려 합니다.

 

Rolling Update

Rolling Update는 기존 서버를 한 번에 모두 바꾸지 않고, 인스턴스를 하나씩 새 버전으로 교체하는 방식입니다.
예를 들어 API 서버가 3대라면, 3대를 동시에 내리지 않고 아래처럼 순서대로 교체합니다.

1. 새 버전 인스턴스 1대를 올린다.
2. Readiness/Health check 통과를 확인한다.
3. 기존 인스턴스 1대를 drain 후 종료한다.
4. 이 과정을 반복해 전체를 새 버전으로 교체한다.

장점은 비교적 자원을 덜 쓰고, Kubernetes 같은 환경에서는 기본 전략으로 사용하기 쉽다는것이고, 단점은 배포 중 구버전과 신버전이 동시에 살아 있어서 어떤 사용자는 구버전에 접근을 할수도 있다는 점이 있습니다.
즉, Rolling Update는 조금씩 안전하게 교체하는 전략이지만, 버전 공존을 감당할 수 있어야 합니다.

 

Drain이란

Drain이란

기존 서버로 들어오던 트래픽을 차단하고, 이미 처리 중인 요청만 마무리하도록 하는 작업을 Drain이라고 하며, 진행 중인 요청이 끝나면 해당 인스턴스를 종료합니다.

heath check / liveness / readiness

heath check / liveness / readiness

health check는 가장 큰 개념입니다. 서비스가 정상인지 확인하려고 주기적으로 검사하는 전체 행위를 말합니다.

 

그 안에서 liveness와 readiness는 검사 목적이 다릅니다.
liveness는 "이 애플리케이션이 살아 있냐"를 봅니다. 프로세스가 멈췄거나, 내부적으로 완전히 꼬여서 더 못 살아나는 상태면 liveness가 실패합니다. 그러면 보통 오케스트레이터나 컨테이너 런타임이 그 서버를 다시 시작합니다. 즉, liveness는 재시작이 필요한 상태를 찾는 데 가깝습니다.

 

readiness는 "살아는 있는데 지금 요청을 받아도 되냐"를 봅니다.앱은 실행 중이어도 아직 부팅이 안 끝났거나, DB 연결이 안 붙었거나, 외부 의존성이 준비되지 않았으면 요청을 받으면 안 됩니다. 이런 경우 liveness는 성공할 수 있지만 readiness는 실패할 수 있습니다. 그러면 서버는 죽이지 않고, 단지 트래픽만 보내지 않습니다.

 

Blue-Green

Blue-Green 배포는 동일한 운영 환경을 두 개 준비한 뒤, 트래픽만 전환하는 방식의 배포 전략입니다. 여기서 Blue는 현재 서비스 중인 버전을 뜻하고 Green은 새로 배포할 버전을 뜻합니다.

패치 전

패치 후

일반적인 Blue-Green 배포 흐름은 다음과 같습니다.

1. Green 환경에 새 버전을 배포한다.
2. 헬스 체크와 스모크 테스트로 정상 동작을 확인한다.
3. Nginx 또는 Load Balancer가 트래픽을 Blue에서 Green으로 전환한다.
4. 일정 시간 동안 모니터링을 진행한다.
5. 문제가 없다면 기존 Blue 환경을 종료하거나 대기 상태로 둔다.
6. 문제가 발생하면 트래픽을 다시 Blue로 되돌린다.

이 방식의 가장 큰 장점은 새 버전이 완전히 준비된 뒤에 트래픽을 넘길 수 있다는 점 입니다. 그래서 구조도 직관적이고, 롤백도 빠르다는 장점이 있습니다. 하지만 운영 환경을 두 개 준비해야 해서 자원이 더 들고 트래픽 전환 지점(Nginx, Load Balancer)을 별도로 설계해야 한다는 단점이 있습니다. 또한 DB 스키마 변경이 큰 경우 단순히 서버만 두 개로 나누는 것으로 해결되지 않을 수 있다는것도 고려 해야합니다. 그래도 처음 무중단배포를 설계할 때는 가장 이해하기 쉽고 운영하기도 비교적 명확한 편입니다.

 

Canary

Canary 배포는 새 버전을 전체 사용자에게 한 번에 공개하지 않고 일부 트래픽에만 먼저 적용하는 방식입니다. 이 방식은 실제 사용자 트래픽을 활용해 새 버전을 점진적으로 검증할 수 있다는 특징이 있습니다.

 

일반적인 Canary 배포 흐름은 다음과 같습니다.

1. 새 버전을 일부 인스턴스에만 배포한다.
2. 전체 요청 중 아주 작은 비율만 새 버전으로 보낸다.
3. 에러율, 응답 시간, 비즈니스 지표 등을 모니터링한다.
4. 문제가 없으면 트래픽 비율을 점진적으로 확대한다.
   • 예: 5% → 10% → 30% → 50%
5. 최종적으로 전체 트래픽을 새 버전으로 전환한다.
6. 문제가 발생하면 즉시 비율을 줄이거나 0%로 되돌린다.

이 방식의 장점은 리스크를 아주 작게 시작할 수 있다는 점입니다. 운영 트래픽으로 검증하면서도 전체 장애로 번질 가능성을 줄일 수 있습니다. 하지만 지속적인 모니터링 요구와 더불어 운영 난도가 가장 높다는 단점이 있습니다. 세밀한 트래픽 제어가 필요하며 버전별 모니터링과 로그 분리가 중요합니다. 또한 구버전과 신버전이 더 오래 공존하게 됩니다.

 

간단 정리

Rolling Update	인스턴스를 하나씩 교체
Blue-Green	두 개의 환경을 준비하고 트래픽을 전환
Canary	일부 트래픽으로 먼저 검증 후 확대

 

참고

Canary Deployment: Intro to deployment strategies: blue-green, canary, and more - DEV Community

Intro to deployment strategies: blue-green, canary, and more

무중단 배포 패턴: Rolling, Blue/Green, Canary | by Leehaneul | Medium

 

Rolling update와 Blue/Green 배포 패턴에 대한 이해, Argocd(Rollouts)을 사용한 Blue/Green 배포 방법

Rolling update와 Blue/Green 배포 패턴에 대한 이해, Argocd(Rollouts)을 사용한 Blue/Green 배포 방법

Rolling deployments - Overview of Deployment Options on AWS

Rolling deployments - Overview of Deployment Options on AWS