무중단 배포

hznnoy·2026년 3월 9일

CS

목록 보기
24/24

무중단 배포란?

서비스를 중단하지 않고 새로운 버전의 애플리케이션을 배포하는 방식

즉, 서비스가 계속 운영되는 상태에서 새로운 버전을 배포하여 사용자가 서비스를 이용하는 동안
다운*타임이 발생하지 않도록 하는 배포 전략이다.*

이를 위해 보통 여러 대의 서버 또는 여러 인스턴스 환경을 구성하고 로드 밸런서나 트래픽 제어를 통해 점진적으로 트래픽을 전환한다.

무중단 배포를 사용하지 않을 경우

실제 서비스를 서버 한 대로 운영하고 있다고 가정해보자.

현재 서비스는 application-V1 버전이 실행되고 있다.
이후 기능이 업데이트되어 application-V2를 새로 개발하고 배포하려고 한다.

새로운 버전을 배포하기 위해서는 V2의 빌드 파일을 서버에 업로드하고 애플리케이션을 실행해야 한다.

하지만 일반적으로 V1과 V2는 같은 포트에서 실행되기 때문에 V2를 실행하려면 먼저 V1 애플리케이션을 종료해야 한다.

즉 다음과 같은 과정이 발생한다.

  1. V1 애플리케이션 종료
  2. 새로운 V2 버전 실행

이때 V1이 종료된 시점부터 V2가 정상적으로 실행되기 전까지 사용자가 서비스를 이용할 수 없는 시간이 발생한다.

이처럼 서비스가 일시적으로 중단되는 시간을 다운타임(Downtime) 이라고 한다.

서비스 규모가 커질수록 이러한 다운타임은 사용자 경험에 큰 영향을 주기 때문에
대부분의 운영 환경에서는 이를 최소화하거나 제거하기 위한 무중단 배포 전략을 사용한다.


무중단 배포 전략

대표적인 무중단 배포 전략으로는 다음과 같은 방식들이 있다.

  • Blue/Green 배포
  • Rolling 배포
  • Canary 배포

각 전략은 트래픽을 새로운 버전으로 전환하는 방식에서 차이가 있다.


Blue/Green 배포

두 개의 동일한 운영 환경을 준비한 뒤 트래픽을 한 번에 전환하는 방식

이 전략에서는 기존 버전과 새로운 버전이 각각 독립적인 환경에서 실행된다.

일반적으로

현재 운영 중인 환경 → **Blue**
새롭게 배포할 환경 → **Green**

배포 과정은 다음과 같다.

  1. 현재 Blue 환경에서 서비스가 정상적으로 운영된다.
  2. 새로운 버전의 애플리케이션을 Green 환경에 배포한다.
  3. Green 환경에서 충분한 테스트와 검증을 진행한다.
  4. 문제가 없으면 로드 밸런서의 트래픽을 Blue에서 Green으로 전환한다.
  5. 이후 기존 Blue 환경은 종료하거나 대기 상태로 유지한다.

만약 새로운 버전에서 문제가 발생한다면
로드 밸런서를 통해 즉시 Blue 환경으로 트래픽을 되돌려 빠르게 롤백할 수 있다.

장점

  • 배포 과정에서 서비스 중단이 없다.
  • 롤백이 매우 빠르고 간단하다.
  • 구버전과 신버전이 완전히 분리되어 있어 버전 충돌 가능성이 낮다.

단점

  • 두 개의 운영 환경을 동시에 유지해야 하므로 서버 리소스가 두 배로 필요하다.

Rolling 배포

여러 개의 서버(또는 인스턴스)를 순차적으로 업데이트하는 방식

즉, 전체 서버를 한 번에 교체하지 않고 일부 서버만 새 버전으로 교체하면서 점진적으로 배포를 진행한다.

배포 과정은 다음과 같다.

  1. 여러 개의 서버 중 한 인스턴스를 로드 밸런서에서 제외한다.
  2. 해당 서버의 애플리케이션을 새 버전으로 업데이트한다.
  3. 업데이트가 완료되면 다시 로드 밸런서에 포함시킨다.
  4. 이후 다른 인스턴스에서도 같은 과정을 반복한다.

이 과정을 반복하여 모든 서버가 새로운 버전으로 교체되면 배포가 완료된다.

장점

  • 추가로 많은 서버 리소스를 확보하지 않아도 무중단 배포가 가능하다.
  • 인스턴스를 하나씩 교체하기 때문에 배포 위험을 점진적으로 줄일 수 있다.

단점

  • 배포 중에는 일부 서버만 운영되기 때문에 서버 하나당 처리해야 하는 트래픽이 증가할 수 있다.
  • 배포 과정에서 구버전과 신버전이 동시에 존재하기 때문에 버전 간 호환성 문제가 발생할 수 있다.

Canary 배포

새로운 버전을 일부 사용자에게만 먼저 적용하여 안정성을 검증하는 방식

이 전략의 이름은 과거 탄광에서 유독가스를 감지하기 위해 사용했던 카나리아(canary)에서 유래했다.

배포 과정은 다음과 같다.

  1. 기존 버전과 새로운 버전을 동시에 운영한다.
  2. 전체 사용자 중 일부 사용자에게만 새로운 버전을 제공한다.
  3. 오류율, 성능, 로그 등을 모니터링하여 문제 여부를 확인한다.
  4. 문제가 없으면 점진적으로 트래픽 비율을 늘린다.
  5. 최종적으로 전체 트래픽을 새 버전으로 전환한다.

만약 문제가 발생하면 트래픽을 다시 기존 버전으로 돌려 피해 범위를 최소화할 수 있다.

장점

  • 실제 사용자 환경에서 새로운 버전을 검증할 수 있다.
  • 문제 발생 시 영향 범위를 제한할 수 있다.
  • 위험을 점진적으로 관리할 수 있다.

단점

  • 구버전과 신버전이 동시에 존재하기 때문에 호환성 문제가 발생할 수 있다.
  • 트래픽 제어 및 모니터링 환경이 필요하다.

정리

무중단 배포는 서비스 중단 없이 새로운 버전을 배포하기 위한 운영 전략이다.

대표적인 방식으로는 Blue/Green, Rolling, Canary 배포가 있으며 각각 트래픽을 전환하는 방식과 운영 비용, 위험 관리 방식에서 차이가 있다.

  • Blue/Green 배포는 두 개의 환경을 사용하여 트래픽을 한 번에 전환하는 방식이다.
  • Rolling 배포는 여러 인스턴스를 순차적으로 업데이트하는 방식이다.
  • Canary 배포는 일부 사용자에게 먼저 새로운 버전을 적용하여 안정성을 검증하는 방식이다.

서비스 규모와 운영 환경에 따라 적절한 전략을 선택하여 사용할 수 있다.


profile
노력에는 지름길이 없으니까요

0개의 댓글