
서비스를 중단하지 않고 새로운 버전의 애플리케이션을 배포하는 방식
즉, 서비스가 계속 운영되는 상태에서 새로운 버전을 배포하여 사용자가 서비스를 이용하는 동안
다운*타임이 발생하지 않도록 하는 배포 전략이다.*
이를 위해 보통 여러 대의 서버 또는 여러 인스턴스 환경을 구성하고 로드 밸런서나 트래픽 제어를 통해 점진적으로 트래픽을 전환한다.
실제 서비스를 서버 한 대로 운영하고 있다고 가정해보자.
현재 서비스는 application-V1 버전이 실행되고 있다.
이후 기능이 업데이트되어 application-V2를 새로 개발하고 배포하려고 한다.
새로운 버전을 배포하기 위해서는 V2의 빌드 파일을 서버에 업로드하고 애플리케이션을 실행해야 한다.
하지만 일반적으로 V1과 V2는 같은 포트에서 실행되기 때문에 V2를 실행하려면 먼저 V1 애플리케이션을 종료해야 한다.
즉 다음과 같은 과정이 발생한다.

이때 V1이 종료된 시점부터 V2가 정상적으로 실행되기 전까지 사용자가 서비스를 이용할 수 없는 시간이 발생한다.
이처럼 서비스가 일시적으로 중단되는 시간을 다운타임(Downtime) 이라고 한다.
서비스 규모가 커질수록 이러한 다운타임은 사용자 경험에 큰 영향을 주기 때문에
대부분의 운영 환경에서는 이를 최소화하거나 제거하기 위한 무중단 배포 전략을 사용한다.
대표적인 무중단 배포 전략으로는 다음과 같은 방식들이 있다.
각 전략은 트래픽을 새로운 버전으로 전환하는 방식에서 차이가 있다.

두 개의 동일한 운영 환경을 준비한 뒤 트래픽을 한 번에 전환하는 방식
이 전략에서는 기존 버전과 새로운 버전이 각각 독립적인 환경에서 실행된다.
일반적으로
현재 운영 중인 환경 → **Blue**
새롭게 배포할 환경 → **Green**
배포 과정은 다음과 같다.
- 현재 Blue 환경에서 서비스가 정상적으로 운영된다.
- 새로운 버전의 애플리케이션을 Green 환경에 배포한다.
- Green 환경에서 충분한 테스트와 검증을 진행한다.
- 문제가 없으면 로드 밸런서의 트래픽을 Blue에서 Green으로 전환한다.
- 이후 기존 Blue 환경은 종료하거나 대기 상태로 유지한다.
만약 새로운 버전에서 문제가 발생한다면
로드 밸런서를 통해 즉시 Blue 환경으로 트래픽을 되돌려 빠르게 롤백할 수 있다.

여러 개의 서버(또는 인스턴스)를 순차적으로 업데이트하는 방식
즉, 전체 서버를 한 번에 교체하지 않고 일부 서버만 새 버전으로 교체하면서 점진적으로 배포를 진행한다.
배포 과정은 다음과 같다.
- 여러 개의 서버 중 한 인스턴스를 로드 밸런서에서 제외한다.
- 해당 서버의 애플리케이션을 새 버전으로 업데이트한다.
- 업데이트가 완료되면 다시 로드 밸런서에 포함시킨다.
- 이후 다른 인스턴스에서도 같은 과정을 반복한다.
이 과정을 반복하여 모든 서버가 새로운 버전으로 교체되면 배포가 완료된다.

새로운 버전을 일부 사용자에게만 먼저 적용하여 안정성을 검증하는 방식
이 전략의 이름은 과거 탄광에서 유독가스를 감지하기 위해 사용했던 카나리아(canary)에서 유래했다.
배포 과정은 다음과 같다.
- 기존 버전과 새로운 버전을 동시에 운영한다.
- 전체 사용자 중 일부 사용자에게만 새로운 버전을 제공한다.
- 오류율, 성능, 로그 등을 모니터링하여 문제 여부를 확인한다.
- 문제가 없으면 점진적으로 트래픽 비율을 늘린다.
- 최종적으로 전체 트래픽을 새 버전으로 전환한다.
만약 문제가 발생하면 트래픽을 다시 기존 버전으로 돌려 피해 범위를 최소화할 수 있다.
무중단 배포는 서비스 중단 없이 새로운 버전을 배포하기 위한 운영 전략이다.
대표적인 방식으로는 Blue/Green, Rolling, Canary 배포가 있으며 각각 트래픽을 전환하는 방식과 운영 비용, 위험 관리 방식에서 차이가 있다.
서비스 규모와 운영 환경에 따라 적절한 전략을 선택하여 사용할 수 있다.