Blue/Green 배포 기초

Blue/Green은 동일한 두 환경을 두고 트래픽을 한 번에 전환해 무중단 배포와 즉시 롤백을 얻는 전략입니다.

TL;DR

• Blue/Green은 동일한 두 환경을 동시에 두고 트래픽을 한 번에 전환해 무중단 배포와 즉시 롤백을 얻는 전략입니다.
• 대가는 환경 2배의 인프라 비용과 전환 시점의 데이터·세션·연결 일관성 관리입니다.
• Blue/Green은 전체 앱을 전환하고 Feature Flag는 개별 기능을 제어합니다. 둘을 함께 쓰면 인프라와 기능 양쪽에서 롤백 옵션을 확보합니다.

Blue/Green 배포란?

Blue/Green 배포는 동일한 두 환경(Blue, Green)을 동시에 운영하고, 트래픽을 한 번에 전환하는 배포 전략입니다.

• Blue: 현재 운영 중인 안정 버전 (Old)
• Green: 새 버전을 배포하고 검증하는 환경 (New)

트래픽 전환은 로드밸런서/서비스 라우팅 설정으로 제어합니다. 문제가 생기면 즉시 Blue로 롤백할 수 있어 무중단 운영의 핵심 기법 중 하나입니다.

왜 "Blue"와 "Green"인가?

색상에 특별한 의미는 없습니다. 단순히 두 환경을 구분하기 위한 명명 규칙입니다. 어떤 조직에서는 "A/B", "Primary/Secondary", "Live/Staging" 등의 용어를 사용하기도 합니다.

flowchart TB
    LB[Load Balancer]
    LB --> Blue
    LB -.-> Green

    subgraph Blue[Blue - ACTIVE]
        B1[v1.0.0]
    end

    subgraph Green[Green - STANDBY]
        G1[v1.1.0]
    end

배포 전략 비교

Blue/Green 배포를 이해하기 위해 주요 배포 전략들과 비교합니다.

전략별 특성 비교

리소스 및 복잡도 비교

• Recreate: 추가 리소스 없음, 다운타임 있음, 운영 복잡도 낮음, 테스트 격리 없음
• Rolling Update: 추가 리소스 최소, 다운타임 없음, 운영 복잡도 낮음, 테스트 격리 부분적
• Blue/Green: 추가 리소스 2배, 다운타임 없음, 운영 복잡도 중간, 테스트 격리 완벽
• Canary: 추가 리소스 최소~중간, 다운타임 없음, 운영 복잡도 높음, 테스트 격리 부분적
• A/B Testing: 추가 리소스 중간, 다운타임 없음, 운영 복잡도 높음, 테스트 격리 부분적

언제 어떤 전략을 선택할까?

flowchart TD
    A{다운타임 허용?}
    A -->|Yes| B[Recreate]
    A -->|No| C{롤백 속도 중요?}
    C -->|Yes| D[Blue/Green]
    C -->|No| E{점진적 검증 필요?}
    E -->|Yes| F[Canary]
    E -->|No| G[Rolling Update]

장점과 한계

장점

무중단 전환

로드밸런서 스위칭만으로 서비스 중단 없이 배포가 가능합니다.

flowchart LR
    subgraph before[전환 전]
        U1[Users] --> LB1[LB: 100% Blue]
        LB1 --> B1[Blue v1.0]
        G1[Green v1.1]
    end

    subgraph after[전환 후]
        U2[Users] --> LB2[LB: 100% Green]
        LB2 --> G2[Green v1.1]
        B2[Blue v1.0]
    end

    before -.->|즉시 전환| after

완벽한 격리

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 상태나 캐시 데이터가 동기화되어 있어야 합니다.

문제 시나리오:

1. Blue(v1)에서 사용자가 주문 생성
2. 주문 데이터가 DB에 저장됨
3. Green(v2)으로 전환
4. Green에서 해당 주문 처리 시 스키마 불일치 발생 가능

세션 유지

전환 중에 기존 Blue 사용자의 세션을 유지할 방법을 정해야 합니다.

flowchart LR
    subgraph problem[세션 유실 문제]
        U[User] -->|전환 전| B[Blue<br/>세션: 서버 메모리]
        U -.->|전환 후| G[Green<br/>세션 없음!]
        G --> X[로그아웃됨]
    end

해결책: Redis 같은 외부 세션 스토리지 사용

상태 있는 연결과 작업

무상태 HTTP 요청과 달리, 오래 유지되는 연결이나 실행 중인 작업은 즉시 전환 시 별도로 처리해야 합니다. 전환 순간에 연결이 끊기거나 작업이 두 버전에 걸쳐 실행될 수 있습니다.

• 장기 연결(WebSocket, 스트리밍): 전환 후에도 기존 Blue 연결이 끝날 때까지 Blue를 유지(connection draining)한 뒤 정리합니다.
• 비동기 작업(큐 컨슈머): 큐 메시지 포맷을 버전 간 호환되게 유지해야 Green이 Blue가 넣은 메시지를 처리할 수 있습니다.
• 배치/크론: 전환 시점에 두 환경이 같은 작업을 중복 실행하지 않도록 분산 잠금을 걸거나 한쪽 환경에서만 돌립니다.

이 셋은 4편의 Connection Draining, 세션 외부화와 직접 이어집니다.

기본 배포 흐름

5단계 배포 프로세스

flowchart TB
    subgraph step1[Step 1: Blue 운영 중]
        B1[Blue v1.0]
        T1[100% 트래픽] --> B1
    end

    subgraph step2[Step 2: Green 배포]
        B2[Blue v1.0]
        G2[Green v1.1<br/>배포 중]
        T2[트래픽] --> B2
    end

    subgraph step3[Step 3: Green 검증]
        B3[Blue v1.0]
        G3[Green v1.1<br/>Health Check<br/>Smoke Test]
        T3[트래픽] --> B3
    end

    subgraph step4[Step 4: 트래픽 전환]
        B4[Blue v1.0]
        G4[Green v1.1]
        T4[100% 트래픽] --> G4
    end

    subgraph step5[Step 5: Blue 정리/대기]
        G5[Green v1.1<br/>새로운 Blue]
        T5[트래픽] --> G5
        B5[Old Blue<br/>롤백 대비 유지]
    end

    step1 --> step2 --> step3 --> step4 --> step5

각 단계별 체크리스트

Feature Flag와의 비교

Blue/Green 배포와 Feature Flag는 모두 "안전한 릴리스"를 위한 기법이지만, 적용 계층과 목적이 다릅니다.

개념 비교

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()  # 기존 기능

is_enabled의 첫 인자는 플래그 키이고, 둘째 인자는 대상 사용자입니다. 같은 코드에서 사용자별로 새 기능과 기존 기능을 분기합니다.

언제 어떤 것을 사용할까?

flowchart TD
    A{무엇을 변경하나요?}
    A -->|인프라/전체 앱| B[Blue/Green]
    A -->|개별 기능| C[Feature Flag]

    B --> B1[버전 업그레이드<br/>전체 리팩토링<br/>플랫폼 마이그레이션]
    C --> C1[A/B 테스트<br/>점진적 롤아웃<br/>사용자별 기능]

조합 사용

실제 운영에서는 두 기법을 함께 사용하는 것이 효과적입니다.

flowchart TB
    subgraph prod[Production]
        subgraph bg[Blue/Green 배포]
            subgraph app[Application v2.0]
                FF[Feature Flags]
                FA[Feature A: ON 100%]
                FB[Feature B: ON 50% canary]
                FC[Feature C: OFF]
            end
        end
    end

조합 사용의 장점:

• Blue/Green으로 인프라 수준의 안전한 배포
• Feature Flag로 기능 수준의 세밀한 제어
• 문제 발생 시 두 단계의 롤백 옵션

정리

Blue/Green은 동일한 두 환경을 두고 로드밸런서 라우팅만 바꿔 트래픽을 한 번에 전환합니다. 무중단 배포와 즉시 롤백을 얻는 대신 환경 2배의 인프라 비용과 전환 시점의 데이터·세션·연결 일관성 관리를 감수합니다.

전체 앱 단위 전환에는 Blue/Green, 기능 단위 제어에는 Feature Flag가 맞습니다. 둘을 함께 쓰면 인프라와 기능 양쪽에서 롤백 옵션을 확보합니다. 다음 글에서는 데이터 일관성과 세션 유지, Connection Draining 같은 전환 시점의 실무 문제를 다룹니다.