Blue-Green 배포 전략 완벽 가이드 - 무중단 배포의 핵심 기법
서비스 배포 중 다운타임이 발생하면 사용자 경험은 물론 비즈니스에 직접적인 손실이 발생하죠. Blue-Green 배포는 이런 문제를 해결하는 가장 직관적이고 안전한 무중단 배포 전략이에요.
Blue-Green 배포란?
Blue-Green 배포는 두 개의 동일한 프로덕션 환경을 준비하고, 트래픽을 순간적으로 전환하는 배포 방식이에요. Blue(현재 운영 중인 환경)와 Green(새 버전이 배포될 환경) 두 환경을 유지하며, 새 버전 검증 후 라우터나 로드밸런서를 통해 트래픽을 전환합니다.
핵심 원리는 이래요:
- Blue 환경에서 서비스가 운영 중일 때, Green 환경에 새 버전을 배포
- Green 환경에서 충분한 테스트 완료 후 트래픽을 한 번에 전환
- 문제 발생 시 즉시 Blue로 롤백 가능
실전 구현 방법
Kubernetes를 활용한 구현
쿠버네티스에서는 Service 리소스의 셀렉터를 변경하여 구현할 수 있어요.
# Blue Deployment (현재 운영)
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-blue
spec:
replicas: 3
selector:
matchLabels:
app: myapp
version: blue
template:
metadata:
labels:
app: myapp
version: blue
# Service - 셀렉터만 변경하여 전환
apiVersion: v1
kind: Service
metadata:
name: myapp-service
spec:
selector:
app: myapp
version: green # blue에서 green으로 변경
ports:
- port: 80
NGINX를 활용한 간단 구현
upstream blue {
server blue-app:8080;
}
upstream green {
server green-app:8080;
}
server {
location / {
proxy_pass http://green; # blue에서 green으로 변경
}
}
Blue-Green vs 다른 배포 전략
Rolling 배포와 비교하면, Blue-Green은 전체 트래픽을 한 번에 전환하므로 배포 속도가 빠르고 두 버전이 혼재되지 않아요. 하지만 2배의 리소스가 필요하다는 단점이 있죠.
Canary 배포는 점진적 트래픽 전환으로 리스크를 분산하지만, Blue-Green은 즉각적인 롤백이 가능하고 테스트가 더 명확해요.
주요 장점:
- 즉시 롤백 가능 (DNS/로드밸런서 설정만 변경)
- 배포 전 충분한 검증 시간 확보
- 두 버전 간 간섭 없음
주의사항: 데이터베이스 마이그레이션
Blue-Green 배포의 가장 큰 도전 과제는 데이터베이스 스키마 변경이에요. 새 버전과 구 버전이 동시에 DB를 사용하므로, 스키마 변경 시 하위 호환성을 유지해야 해요.
해결 방법:
- Expand-Contract 패턴 사용 (컬럼 추가 → 마이그레이션 → 기존 컬럼 삭제)
- Blue와 Green 모두 호환되는 스키마로 먼저 마이그레이션
- 읽기 전용 배포와 쓰기 배포를 분리
세션 관리도 중요해요. 스티키 세션보다는 외부 세션 스토어(Redis 등)를 사용하거나, JWT 같은 stateless 인증을 추천해요.
결론
Blue-Green 배포는 충분한 리소스만 확보된다면 가장 안전하고 빠른 무중단 배포 전략이에요. 특히 금융, 이커머스처럼 다운타임이 치명적인 서비스에 적합하죠. 다만 데이터베이스 마이그레이션 전략과 인프라 비용을 충분히 고려해서 도입해야 해요. 실제 프로덕션에 적용하기 전, 스테이징 환경에서 충분히 연습하는 것을 추천드려요.