Blue-Green 배포

현재 운영 중인 환경(Blue)과 동일한 새 환경(Green)을 구성한 뒤 트래픽을 한 번에 전환해 다운타임 없이 배포하는 전략입니다.

구조

[ 배포 전 ]                    [ 배포 후 ]

사용자 → 로드밸런서 → Blue(v1)   사용자 → 로드밸런서 → Green(v2)
                      Green(v2)                         Blue(v1) ← 대기(롤백용)

Blue(현재 v1)에 트래픽 100%
Green(신버전 v2) 환경을 별도로 구성·테스트
로드밸런서 트래픽을 Green으로 전환
문제 없으면 Blue 종료 / 문제 발생 시 Blue로 즉시 롤백

핵심 특징

무중단: 트래픽 전환이 순간적으로 일어나 서비스 중단 없음
즉시 롤백: Blue가 살아 있어 문제 발생 시 로드밸런서만 되돌리면 됨
동일 환경 보장: Green이 Blue와 완전히 동일한 구조로 준비됨

Canary 배포와 비교

	Blue-Green	Canary 배포
전환 방식	100% 일괄 전환	일부(5~10%)부터 점진적 전환
롤백 속도	즉시 (트래픽 전환만)	즉시 (비율 0%로 축소)
자원 비용	2배 (두 환경 동시 운영)	증분 추가
이슈 발견 시점	전환 후	소수 사용자 노출 중
적합한 경우	대규모 변경, DB 마이그레이션 동반	기능 플래그, A/B 테스트

DB 마이그레이션 주의점

Blue-Green의 가장 어려운 부분. Blue(v1)와 Green(v2)이 같은 DB를 동시에 바라보는 순간이 생김.

[ 안전한 순서 ]

1. 컬럼 추가 (하위 호환 — Blue·Green 모두 동작)
2. Green(v2) 배포 → 트래픽 전환
3. Blue 종료 확인 후 구 컬럼 제거

한 번에 컬럼 삭제+추가를 동시에 하면 Blue가 살아있는 동안 에러 발생.

Cloud Run에서의 적용

# Green 배포 (트래픽 0%, 태그로 먼저 확인)
gcloud run deploy my-app \
  --image gcr.io/my-project/my-app:v2 \
  --no-traffic \
  --tag green

# 스모크 테스트 후 트래픽 전환
gcloud run services update-traffic my-app \
  --to-tags green=100

# 롤백: 이전 리비전으로 되돌리기
gcloud run services update-traffic my-app \
  --to-revisions LATEST=0,PREV_REVISION=100

핵심 정리

두 환경(Blue/Green)을 동시에 운영하다가 로드밸런서 전환으로 순간 배포 — 다운타임 0
롤백이 빠르다는 게 최대 강점 — 문제 발생 시 로드밸런서만 되돌리면 됨
단점은 자원 비용 2배, DB 스키마 변경 시 하위 호환 설계가 필요
점진적 노출이 필요하다면 Canary 배포 선택

→ CI·CD | 로드 밸런싱