Blue/Green 배포 (1): 무중단 배포의 기초와 전략
Blue/Green 배포의 개념, 다른 전략과의 비교, 장단점, 그리고 Feature Flag와의 차이점까지
Blue/Green 배포란?
Blue/Green 배포는 동일한 두 환경(Blue, Green)을 동시에 운영하고, 트래픽을 한 번에 전환하는 배포 전략이다.
- Blue: 현재 운영 중인 안정 버전 (Old)
- Green: 새 버전을 배포하고 검증하는 환경 (New)
트래픽 전환은 로드밸런서/서비스 라우팅 설정으로 제어하며, 문제가 생기면 즉시 Blue로 롤백할 수 있어 무중단 운영의 핵심 기법 중 하나이다.
왜 "Blue"와 "Green"인가?
색상에 특별한 의미는 없다. 단순히 두 환경을 구분하기 위한 명명 규칙이다. 어떤 조직에서는 "A/B", "Primary/Secondary", "Live/Staging" 등의 용어를 사용하기도 한다.
배포 전략 비교
Blue/Green 배포를 이해하기 위해 주요 배포 전략들과 비교해보자.
전략별 특성 비교
| 전략 | 설명 | 전환 방식 | 롤백 속도 |
|---|---|---|---|
| Recreate | 기존 버전 중단 → 새 버전 시작 | 전체 교체 | 느림 (재배포 필요) |
| Rolling Update | 인스턴스를 하나씩 새 버전으로 교체 | 점진적 | 중간 |
| Blue/Green | 전체 환경을 한 번에 전환 | 즉시 전환 | 즉시 |
| Canary | 일부 트래픽만 먼저 노출 후 확대 | 비율 조정 | 빠름 |
| A/B Testing | 사용자 특성별로 다른 버전 노출 | 조건부 라우팅 | 빠름 |
리소스 및 복잡도 비교
- Recreate: 추가 리소스 없음, 다운타임 있음, 운영 복잡도 낮음, 테스트 격리 없음
- Rolling Update: 추가 리소스 최소, 다운타임 없음, 운영 복잡도 낮음, 테스트 격리 부분적
- Blue/Green: 추가 리소스 2배, 다운타임 없음, 운영 복잡도 중간, 테스트 격리 완벽
- Canary: 추가 리소스 최소~중간, 다운타임 없음, 운영 복잡도 높음, 테스트 격리 부분적
- A/B Testing: 추가 리소스 중간, 다운타임 없음, 운영 복잡도 높음, 테스트 격리 부분적
언제 어떤 전략을 선택할까?
장점과 한계
장점
무중단 전환
로드밸런서 스위칭만으로 서비스 중단 없이 배포가 가능하다.
완벽한 격리
Green 환경에서 운영과 동일한 조건으로 최종 테스트가 가능하다.
- 실제 트래픽을 받기 전 내부 테스트 수행
- 성능 테스트, 보안 스캔, QA 검증 가능
- 문제 발견 시 사용자에게 영향 없음
초고속 롤백
문제가 발견되면 라우팅 설정만 변경하면 된다.
# 롤백 소요 시간
Recreate: 5-10분 (재배포)
Rolling Update: 2-5분 (점진적 롤백)
Blue/Green: 수 초 (라우팅 변경만)한계
인프라 비용
동일한 환경이 2개 필요하므로 비용 부담이 크다.
- 일반 배포: 서버 10대 x $100/월 = $1,000/월
- Blue/Green: 서버 20대 x $100/월 = $2,000/월 (+$1,000/월)
비용 최적화 팁: 시리즈 4편에서 Spot 인스턴스, 자동 스케일링 등 비용 절감 방법을 다룬다.
데이터 일관성
전환 시점의 DB 상태나 캐시 데이터가 동기화되어 있어야 한다.
문제 시나리오:
- Blue(v1)에서 사용자가 주문 생성
- 주문 데이터가 DB에 저장됨
- Green(v2)으로 전환
- Green에서 해당 주문 처리 시 스키마 불일치 발생 가능
세션 유지
전환 시 기존 Blue 유저들의 세션 유실 대책이 필요하다.
해결책: Redis 같은 외부 세션 스토리지 사용
기본 배포 흐름
5단계 배포 프로세스
각 단계별 체크리스트
| 단계 | 수행 작업 | 성공 기준 |
|---|---|---|
| Step 1 | 현재 상태 확인 | Blue 정상 운영 중 |
| Step 2 | Green 환경에 새 버전 배포 | 모든 Pod/인스턴스 기동 |
| Step 3 | Health Check, Smoke Test | 모든 테스트 통과 |
| Step 4 | 로드밸런서 설정 변경 | 트래픽 100% Green |
| Step 5 | 모니터링 및 Blue 정리 | 에러율 정상 범위 |
Feature Flag와의 비교
Blue/Green 배포와 Feature Flag는 모두 "안전한 릴리스"를 위한 기법이지만, 적용 계층과 목적이 다르다.
개념 비교
| 구분 | Blue/Green | Feature Flag |
|---|---|---|
| 적용 계층 | 인프라 (서버/환경) | 코드 (기능) |
| 전환 단위 | 전체 애플리케이션 | 개별 기능 |
| 롤백 방식 | 라우팅 변경 | 플래그 OFF |
| 대상 제어 | 모든 사용자 | 특정 사용자/그룹 가능 |
| 추가 코드 | 불필요 | 조건문 필요 |
Feature Flag 예시
# Feature Flag 사용 예시
def get_checkout_page(user):
if feature_flags.is_enabled("new_checkout", user):
return render_new_checkout() # 새 기능
else:
return render_old_checkout() # 기존 기능언제 어떤 것을 사용할까?
조합 사용 (Best Practice)
실제 운영에서는 두 기법을 함께 사용하는 것이 효과적이다.
조합 사용의 장점:
- Blue/Green으로 인프라 수준의 안전한 배포
- Feature Flag로 기능 수준의 세밀한 제어
- 문제 발생 시 두 단계의 롤백 옵션