배포 중에 일부 사용자만 새 버전을, 나머지는 옛 버전을 받아 세션이 깨지거나, 문제가 터졌는데 롤백에 수 분이 걸려 장애가 길어진 경험이 있을 겁니다. 블루그린 배포는 현재 운영 중인 환경(블루)과 동일한 신버전 환경(그린)을 따로 띄워 두고, 검증이 끝나면 트래픽을 한 번에 그린으로 넘기는 방식입니다. 문제가 생기면 다시 블루로 되돌리기만 하면 됩니다.
다른 전략과의 차이
| 전략 | 방식 | 롤백 속도 | 추가 자원 |
|---|---|---|---|
| 롤링 | 인스턴스를 순차 교체 | 느림(되돌리기 재배포) | 적음 |
| 블루그린 | 두 환경 병행, 일괄 전환 | 즉시(트래픽 되돌림) | 두 배 |
| 카나리 | 일부 트래픽만 신버전 | 빠름 | 중간 |
블루그린의 핵심 이점은 롤백이 재배포가 아니라 트래픽 스위치라는 점입니다. 그린에서 문제가 보이면 로드밸런서 대상만 블루로 되돌리면 수 초 만에 복구됩니다. 대신 두 환경을 동시에 유지하므로 자원 비용이 늘고, 전환 시점의 DB 스키마 호환을 신경 써야 합니다.
전환 단계
- 현재 트래픽은 블루(
v1)가 받는 상태에서, 동일 구성의 그린(v2)을 배포합니다. - 그린에 내부 트래픽만 보내 헬스체크·스모크 테스트로 검증합니다. 사용자에게는 아직 노출하지 않습니다.
- 로드밸런서의 대상 그룹을 블루에서 그린으로 전환합니다.
YAML
# 로드밸런서가 가리키는 대상만 교체
service:
selector:
app: shop
version: v2 # v1 -> v2 로 스위치
- 전환 후 에러율·지연을 관찰하다 이상이 보이면 즉시
version: v1으로 되돌립니다. - 안정이 확인되면 블루(
v1)를 회수합니다. 곧바로 지우지 말고 한동안 대기 환경으로 남겨 두면 안전합니다.
주의할 함정
가장 자주 발목을 잡는 건 데이터베이스 스키마입니다. 블루와 그린이 같은 DB를 공유하는 경우, 컬럼 삭제나 타입 변경처럼 한쪽 버전만 깨지는 변경을 한 번에 하면 전환·롤백이 모두 위험해집니다. 그래서 스키마 변경은 두 버전이 함께 동작할 수 있도록 확장 후 정리(expand and contract) 로 나눕니다. 먼저 컬럼을 추가(두 버전 호환)하고, 신버전이 안정된 뒤 다음 배포에서 옛 컬럼을 제거합니다.
세션·캐시도 두 환경이 공유하거나 외부 저장소(Redis 등)에 두어, 전환 시 로그인이 풀리지 않게 합니다.
요점 정리
- 블루그린은 두 환경을 병행하고 트래픽을 일괄 전환해 무중단·즉시 롤백을 얻는다.
- 롤백이 재배포가 아니라 트래픽 스위치라 복구가 수 초로 빠르다.
- DB 스키마는 확장 후 정리로 두 버전 호환을 유지한다.
- 전환 직후 옛 환경을 바로 지우지 말고 대기로 남겨 둔다.
블루그린 전환과 롤백을 직접 구성해 보는 실습은 클라우드 트랙에서 회원가입 없이 무료로 시작할 수 있습니다.