도커로 무중단 배포(Blue-Green Deployment) 구현하기

docker

도커로 무중단 배포(Blue-Green Deployment) 구현하기

mirabo01 2025. 11. 12. 09:11

필요하시면 각 이미지에 맞는 설명 문구나 캡션도 함께 만들어드릴게요.

서비스를 운영하다 보면 누구나 한 번쯤 “배포하다가 서버가 멈춘 적”이 있습니다.
처음엔 그게 큰 문제처럼 느껴지지 않지만, 실제 사용자가 많은 환경에서는 단 몇 초의 중단도 민감하게 체감됩니다.
그래서 어느 순간부터는 “다운타임 없는 배포”, 즉 무중단 배포가 필수가 됩니다.

도커를 사용하면 이 과정을 비교적 단순하게 설계할 수 있습니다.
그 대표적인 방법이 바로 Blue-Green Deployment입니다.

배포 중 서버가 멈추는 이유

도커를 쓰기 전에는 새로운 버전을 배포할 때마다
서버를 중지하고, 새로운 코드를 반영하고, 다시 서버를 실행했습니다.
그 몇 초 사이에 사용자는 페이지를 새로고침하면 접속이 끊겼습니다.

도커를 도입한 이후에도 단일 컨테이너에서만 서비스를 운영한다면
결국 docker stop → docker run 사이의 공백이 존재하게 됩니다.
이걸 해결하기 위한 전략이 바로 “두 개의 컨테이너를 번갈아 사용하는 방식”입니다.

Blue-Green 방식이란 무엇인가

이 방식은 이름 그대로 두 가지 버전을 유지합니다.

Blue: 현재 서비스 중인 버전
Green: 새로 배포할 버전

새 버전을 미리 올려 두고, 모든 점검이 끝나면
트래픽을 Blue에서 Green으로 전환합니다.
문제가 없으면 Blue를 종료하고, 혹시 문제가 있으면 즉시 롤백할 수 있습니다.

즉, 서비스가 멈추지 않은 채로 새로운 버전을 반영하는 구조입니다.

도커로 직접 구현해보기

예를 들어 myapp이라는 서비스를 배포한다고 가정해봅니다.

# 현재 버전 (Blue)
docker run -d --name app_blue -p 8080:80 myapp:1.0

# 새 버전 (Green)
docker run -d --name app_green -p 8081:80 myapp:1.1

두 컨테이너를 동시에 띄운 상태에서,
Nginx 같은 프록시 서버를 통해 트래픽을 어느 쪽으로 보낼지 제어합니다.

upstream backend {
    server localhost:8080; # Blue
    # server localhost:8081; # Green
}

server {
    listen 80;
    location / {
        proxy_pass http://backend;
    }
}

테스트가 끝나고 Green이 정상적으로 동작하는 게 확인되면
위 설정에서 주석만 바꿔서 포트를 8081로 지정하고 nginx -s reload를 실행하면 됩니다.
이때 유저는 전환이 일어났다는 사실을 전혀 느끼지 못합니다.

GitHub Actions와 연동해서 자동화하기

Blue-Green 전략을 자동화하면 효율이 훨씬 높아집니다.
GitHub Actions에서 코드를 푸시할 때
새 버전을 빌드하고, Green 컨테이너를 띄운 뒤,
정상 동작이 확인되면 Nginx 설정을 바꾸는 식으로 구성할 수 있습니다.

- name: Switch Traffic
  run: |
    if docker ps | grep app_blue; then
      docker run -d --name app_green -p 8081:80 myapp:${{ github.sha }}
      sed -i 's/8080/8081/' /etc/nginx/conf.d/default.conf
      nginx -s reload
      docker stop app_blue && docker rm app_blue
    else
      docker run -d --name app_blue -p 8080:80 myapp:${{ github.sha }}
      sed -i 's/8081/8080/' /etc/nginx/conf.d/default.conf
      nginx -s reload
      docker stop app_green && docker rm app_green
    fi

직접 구성해 보면 단순히 “자동 배포”가 아니라
현재 버전과 새 버전을 번갈아 유지하면서 전환하는 과정이라는 걸 체감하게 됩니다.

장점과 주의할 점

이 방식의 가장 큰 장점은 다운타임이 없다는 것입니다.
사용자는 새 버전으로 바뀌는 순간에도 페이지를 끊김 없이 이용할 수 있습니다.
또 문제가 생겼을 때 이전 버전으로 빠르게 되돌릴 수 있어 안정성도 높습니다.

하지만 단점도 있습니다.
두 버전을 동시에 띄워야 하기 때문에 서버 자원이 두 배로 필요하고,
세션이나 캐시 같은 공유 자원이 제대로 동기화되지 않으면
전환 시 혼란이 생길 수 있습니다.

그래서 실제 운영에서는 Redis나 DB를 세션 스토리지로 사용하거나,
ECS·EKS 등 오케스트레이션 환경에서 Blue-Green을 자동 관리하는 방식을 씁니다.

무중단 배포를 해야 하는 진짜 이유

결국 이 모든 작업의 목적은 “사용자 경험을 지키는 것”입니다.
개발자 입장에서는 몇 초의 지연이 별일 아닐 수 있지만,
사용자 입장에서는 결제 도중 페이지가 멈추거나 로그인 세션이 끊기면 바로 불편함으로 이어집니다.

Blue-Green Deployment는 그런 문제를 막아주는
운영의 기본이자 신뢰를 지키는 약속 같은 기술이라고 할 수 있습니다.