🔧
DevOps
Blue-Green
블루-그린 배포
두 환경을 교대 사용하는 무중단 배포 전략. 즉시 롤백 가능.
상세 설명
Blue-Green 배포는 두 개의 동일한 프로덕션 환경(Blue와 Green)을 운영하여 무중단 배포와 즉시 롤백을 가능하게 하는 배포 전략입니다. Martin Fowler가 대중화한 이 방식은 배포 위험을 최소화하는 고전적이면서도 효과적인 방법입니다.
현재 프로덕션 트래픽을 받는 환경(예: Blue)이 있고, 새 버전은 대기 환경(Green)에 배포합니다. 테스트 완료 후 로드밸런서나 라우터를 전환하여 트래픽을 Green으로 보냅니다. 문제 발생 시 다시 Blue로 전환하면 즉시 롤백됩니다.
Kubernetes에서는 Service의 selector를 변경하거나, Ingress의 backend를 전환하여 구현합니다. AWS에서는 Elastic Beanstalk, ECS의 Blue/Green 배포, Route 53의 가중치 라우팅으로 구현할 수 있습니다.
실무에서는 데이터베이스 스키마 변경 시 주의가 필요합니다. Blue와 Green 모두 호환되는 스키마를 유지해야 합니다. Expand-Contract 패턴으로 스키마를 점진적으로 변경하거나, 기능 플래그와 결합하여 사용합니다.
코드 예제
#!/bin/bash
# Kubernetes Blue-Green 배포 스크립트
NAMESPACE="production"
SERVICE="my-app"
NEW_VERSION="v2.0.0"
# 현재 활성 배포 확인 (blue 또는 green)
CURRENT=$(kubectl get svc ${SERVICE} -n ${NAMESPACE} \
-o jsonpath='{.spec.selector.version}')
if [ "$CURRENT" == "blue" ]; then
TARGET="green"
else
TARGET="blue"
fi
echo "현재: $CURRENT -> 전환 대상: $TARGET"
# 새 버전을 대기 환경에 배포
kubectl set image deployment/${SERVICE}-${TARGET} \
app=myregistry/${SERVICE}:${NEW_VERSION} -n ${NAMESPACE}
# 배포 완료 대기
kubectl rollout status deployment/${SERVICE}-${TARGET} \
-n ${NAMESPACE} --timeout=300s
# 헬스체크 통과 확인
echo "헬스체크 수행 중..."
sleep 10
# 트래픽 전환 (Service selector 변경)
kubectl patch svc ${SERVICE} -n ${NAMESPACE} -p \
"{\"spec\":{\"selector\":{\"version\":\"${TARGET}\"}}}"
echo "트래픽이 ${TARGET}으로 전환되었습니다."
echo "롤백: kubectl patch svc ${SERVICE} -n ${NAMESPACE} \
-p '{\"spec\":{\"selector\":{\"version\":\"${CURRENT}\"}}}'"실무에서 이렇게 말해요
시니어: "지난번 배포 롤백에 5분 걸렸는데, Blue-Green으로 바꾸면 10초 만에 롤백할 수 있어요. 트래픽 전환만 하면 되니까."
주니어: "인프라 비용이 두 배가 되지 않나요?"
시니어: "맞아요, 그래서 Spot 인스턴스 활용하거나, 배포 시에만 Green을 스케일업하는 방식을 쓰기도 해요."
면접관: "Blue-Green과 Canary 배포의 차이점은 무엇인가요?"
지원자: "Blue-Green은 트래픽을 한 번에 100% 전환하고, Canary는 점진적으로 트래픽 비율을 늘립니다. Blue-Green은 롤백이 빠르고 간단하지만, Canary는 소규모 사용자로 먼저 검증할 수 있어 위험을 더 분산시킵니다."
리뷰어: "트래픽 전환 전에 Green 환경 헬스체크가 있네요. readinessProbe만 믿지 말고 실제 API 호출 테스트도 추가하면 어떨까요?"
개발자: "좋은 생각이에요. /health 엔드포인트뿐만 아니라 주요 API 몇 개 호출하는 smoke test 추가하겠습니다."
주의사항
- DB 스키마 변경 시 양방향 호환성 필수 - Blue/Green 모두 동작해야 롤백 가능
- 세션 스토리지가 인스턴스에 종속되면 전환 시 세션 유실 - Redis 등 외부 세션 스토어 사용
- 인프라 비용 두 배 - 비용 최적화 위해 Spot, 스케일 조절 전략 검토
- 배포 후 이전 환경(Blue)은 바로 삭제하지 말고 모니터링 후 안정화되면 정리