블루-그린 배포

블루-그린 배포는 새 버전을 옛 버전과 완전히 분리된 서버 묶음에 통째로 띄우기로 하는 결정입니다. 새 묶음이 다 준비된 다음, 트래픽을 그쪽으로 한 번에 돌립니다. 옛 묶음은 끄지 않고 그대로 둡니다.

상세

블루와 그린이 가리키는 서버 묶음

블루와 그린은 특별한 뜻을 담은 이름이 아닙니다. 서로 구별만 되면 되는 두 묶음에 붙인 색 이름입니다. 한쪽이 지금 요청을 받고, 다른 쪽은 다음 버전을 올려 두는 묶음입니다.

두 묶음은 코드 버전만 다르고 나머지는 같아야 합니다. 서버 대수, 메모리 크기, 설정값이 같아야 그린이 블루를 그대로 대신할 수 있습니다. 한쪽만 작게 두면 전환 순간 그린이 전체 트래픽을 못 받아 냅니다.

역할은 배포마다 뒤바뀝니다. 이번에 그린이 새 버전을 받아 라이브가 되면, 다음 배포 때는 그 묶음이 블루가 되고 또 다른 묶음이 그린이 됩니다. 색 이름 자체가 고정된 신분이 아니라 그때그때 붙는 역할입니다.

전환이 일어나는 방법

두 묶음 앞에는 요청을 한쪽으로만 보내는 장치가 있습니다. 이 장치가 지금 어느 묶음을 가리키는지가 곧 어느 색이 라이브인지를 정합니다.

예를 들어 로드 밸런서는 트래픽을 보낼 대상 목록을 바꿔 방향을 정합니다. 리버스 프록시는 전달 설정을 바꿔 같은 역할을 합니다. DNS(Domain Name System, 도메인 네임 시스템)는 레코드를 바꿔 요청이 갈 곳을 정합니다.

active_pool = "blue"    // 지금 가는 곳
active_pool = "green"   // 전환 뒤 가는 곳

전환은 이 대상 값을 바꾸는 일 하나로 끝납니다. 카나리 배포처럼 트래픽 비율을 조금씩 옮기는 단계가 없습니다. 그래서 전환에 걸리는 시간이 짧고, 어느 순간부터 모든 요청이 새 버전으로 갔는지가 분명합니다.

전환 전후를 그림으로 보면 다음과 같습니다.

flowchart TD
    subgraph 전환전["전환 전"]
        R1["라우터"] --> BL1["블루 · 구버전 · 트래픽을 받는 중"]
        R1 -.-> GR1["그린 · 신버전 · 미리 띄워 둠"]
    end
    subgraph 전환후["전환 후"]
        R2["라우터"] --> GR2["그린 · 신버전 · 트래픽을 받는 중"]
        R2 -.-> BL2["블루 · 구버전 · 켜진 채 대기"]
    end

절차를 시간 순서로 보면 이렇습니다. 운영자가 배포 도구나 콘솔에서 전환을 실행하면, 그린이 준비를 마친 뒤 라우터의 목적지가 바뀝니다.

sequenceDiagram
    participant 운영자
    participant 그린
    participant 라우터
    운영자->>그린: 새 버전 배포
    그린-->>운영자: 준비 완료
    운영자->>라우터: 목적지를 그린으로 변경
    Note over 라우터: 이 순간부터 요청이 그린으로 간다
    라우터-->>운영자: 전환 완료

롤백에 걸리는 시간이 짧은 이유

옛 버전을 지우지 않고 켜 둔 채 대기시키는 것이 이 방식의 핵심입니다. 새 버전에서 문제가 나오면 라우터의 목적지를 블루로 되돌리는 것만으로 옛 버전으로 돌아갑니다. 새 코드를 다시 빌드하거나 배포할 필요가 없습니다.

서버를 한 대씩 순서대로 새 버전으로 바꾸는 롤링 업데이트는 되돌리는 절차도 한 대씩 거꾸로 밟아야 합니다. 서버가 많을수록 되돌리는 데도 그만큼 시간이 걸립니다. 블루-그린 배포는 이미 켜져 있는 묶음으로 돌아가는 것이라 걸리는 시간이 서버 대수와 무관합니다.

대신 대기시키는 시간에는 값을 냅니다. 블루를 얼마 동안 켜 둘지는 팀이 정합니다. 새 버전이 안정됐다고 판단하면 블루를 끄고, 다음 배포의 그린 묶음으로 남겨 둡니다.

함께 맞춰야 하는 데이터 문제

두 묶음이 같은 데이터베이스를 공유하는 경우가 많습니다. 서버는 새 것과 옛 것을 따로 띄워도 데이터베이스까지 두 벌 두면 데이터가 갈립니다. 그래서 데이터베이스는 대개 한 벌만 두고 두 버전이 함께 씁니다.

한 벌만 두면 스키마를 바꿀 때 조심해야 합니다. 새 버전이 필요한 열을 추가하는 동안, 옛 버전도 여전히 그 테이블을 읽고 씁니다. 옛 버전이 모르는 열을 추가하는 것은 괜찮지만, 옛 버전이 쓰는 열을 지우거나 이름을 바꾸면 블루가 곧바로 오류를 냅니다.

그래서 스키마를 한 번에 바꾸지 않고 여러 배포에 걸쳐 나눠 바꿉니다. 먼저 새 열을 추가해 두 버전 다 문제없이 돌게 하고, 옛 버전을 완전히 걷어낸 뒤에야 옛 열을 지웁니다. 이 순서를 지키는 작업이 스키마 마이그레이션에 해당합니다.

두 버전이 동시에 같은 데이터를 오가도 깨지지 않는 성질은 하위 호환이라고 부릅니다.

카나리 배포와 어떻게 다른가

카나리 배포는 새 버전에게 트래픽의 일부만 보내고, 문제가 없는지 지켜본 뒤 그 비율을 서서히 늘립니다. 블루-그린 배포는 지켜보는 절차를 배포 전에 끝내고, 전환은 전부 아니면 전무로 한 번에 합니다.

둘 다 되돌리기가 쉽다는 점은 같습니다. 카나리 배포는 비율을 다시 0으로 낮추고, 블루-그린 배포는 라우터를 블루로 되돌립니다. 다만 카나리 배포는 일부 사용자가 잠깐이라도 문제 있는 버전을 만날 수 있는 반면, 블루-그린 배포는 전환 전에 이미 검증을 끝낸 묶음만 트래픽을 받습니다.

고를 만한 상황과 미룰 상황

이 결정이 맞는 상황은 무중단으로 배포해야 하고, 문제가 생겼을 때 되돌리는 시간을 최대한 줄이고 싶을 때입니다. 서버가 자기 안에 상태를 안 갖고 있어서 새 묶음으로 그대로 옮겨 붙일 수 있는 서비스일수록 적용하기 쉽습니다.

미룰 상황은 서버 두 벌을 동시에 띄울 자원이 빠듯할 때입니다. 데이터베이스 스키마를 크게 바꿔야 하는 배포도 조심해야 합니다. 두 버전이 오래 공존해야 하는데 그 공존을 지탱할 스키마 설계가 안 돼 있으면, 서버는 두 벌인데 실제로는 한쪽만 쓸 수 있는 상태가 됩니다.

관련 항목

같은 계보의 다른 배포 전략

카나리 배포 · 롤링 업데이트 · 단계적 출시 · 재생성 · A/B 테스트 · 기능 플래그

전환을 실행하는 장치

로드 밸런서 · 리버스 프록시 · DNS · 서비스 메시 · API 게이트웨이

스키마를 나눠 바꾸는 데 쓰는 개념

스키마 마이그레이션 · 하위 호환 · 데이터베이스 마이그레이션

이 결정이 속하는 상위 흐름

지속적 배포 · 지속적 전달 · 데브옵스 · 무중단 배포

전환 전에 상태를 확인하는 장치

헬스 체크 · 타임아웃 · 서킷 브레이커