블루-그린 배포(Blue-Green Deployment): 무중단 배포의 정석

1. 배포 중 장애를 어떻게 줄일까

배포를 처음 배울 때, 항상 이런 고민이 생깁니다. "서버 재시작하는 1분 동안 사용자가 결제 버튼을 누르면 어떡하지?" "배포했다가 에러 나면 롤백하는 데 30분은 걸릴 텐데..."

이 고민에서 시작한 해결책이 바로 무중단 배포입니다. 과거에는 사용자가 가장 없는 새벽 시간에 점검 공지를 걸고 배포하는 방식이 일반적이었습니다. 이를 점검 시간(Downtime)이라고 불렀죠. 하지만 쿠팡이나 넷플릭스가 "새벽 2시부터 6시까지 점검입니다"라고 하는 거 본 적 있나요? 거의 없습니다. 그들은 24시간 365일 무중단으로 서비스를 운영하면서도 하루에 수십 번씩 배포를 합니다.

그 비결이 바로 무중단 배포(Zero Downtime Deployment)이며, 그중에서도 가장 확실하고 안전한 방법이 블루-그린 배포(Blue-Green Deployment)입니다.

2. 무중단 배포 전략 3대장

무중단 배포에는 크게 3가지 방식이 있습니다. 각각의 장단점을 명확히 알아야 상황에 맞는 전략을 짤 수 있습니다.

2.1 롤링 배포 (Rolling Deployment)

서버가 10대 있다면, 1대씩(혹은 2대씩) 차례대로 새 버전으로 갈아끼우는 방식입니다.

장점: 추가적인 인프라 비용이 거의 안 듭니다. 서버 1대 분량의 여유만 있으면 됩니다.
단점: 배포 도중에는 구버전과 신버전이 공존합니다. 호환성 문제가 생길 수 있습니다. API 응답 값이 버전마다 다르면 클라이언트가 헷갈려합니다. 배포가 느립니다.

2.2 카나리 배포 (Canary Deployment)

광산의 카나리아처럼, 새 버전을 소수(1~5%)의 사용자에게만 먼저 노출시켜 봅니다. 문제가 없으면 점차 트래픽을 늘려갑니다(10% -> 50% -> 100%).

장점: 에러 발생 시 피해를 최소화할 수 있습니다. (A/B 테스트 용도로도 씀)
단점: 트래픽 제어 기술(세션 스티키니스, 로드밸런서 가중치 설정 등)이 복잡합니다.

2.3 블루-그린 배포 (Blue-Green Deployment)

오늘의 주인공입니다. 현재 운영 중인 환경(Blue)과 똑같은 환경(Green)을 하나 더 만듭니다. 배포할 때는 Green에 새 버전을 모두 설치하고 테스트합니다. 준비가 끝나면 로드밸런서가 가리키는 방향을 Blue에서 Green으로 한 방에 돌려버립니다.

장점: 구버전/신버전 공존 문제가 없습니다. 롤백이 0.1초 만에 가능합니다(다시 Blue로 돌리면 끝).
단점: 서버가 2배로 필요하므로 비용이 많이 듭니다. 하지만 클라우드 환경에서는 점검 시간에만 잠깐 띄우고 끄면 되므로 큰 문제가 되지 않습니다.

3. 블루-그린 배포의 아키텍처와 시나리오

개념은 쉽지만, 실제로 구현하려면 몇 가지 단계가 필요합니다. AWS나 Kubernetes 환경을 예로 들어보겠습니다.

1단계 - 준비 (Provisioning)

현재 Live 트래픽은 Blue 그룹(EC2 인스턴스 3대, V1)으로 가고 있습니다. 우리는 대기 중인 Green 그룹(EC2 인스턴스 3대)에 새로운 V2 버전의 애플리케이션을 배포합니다. 이때 일반 사용자는 여전히 Blue를 보고 있으므로, Green에서 지지고 볶고 어떤 짓을 해도 사용자에게는 아무 영향이 없습니다. 개발자들은 Green 환경에 접속해서 QA를 진행합니다.

2단계 - 헬스 체크 (Health Check)

Green 그룹의 서버들이 정상적으로 떴는지 확인합니다. 단순히 포트(80)가 열렸는지만 보는 게 아니라, /health API를 찔러서 DB 연결은 잘 되는지, 레디스는 붙었는지, 외부 API 연동은 되는지 Smoke Test를 수행합니다.

3단계 - 스위치 (Traffic Switch)

모든 테스트가 통과했다면, 로드밸런서(ELB, Nginx) 설정을 변경합니다. Target Group: Blue -> Green 이 순간, 모든 새로운 사용자는 Green으로 접속하게 됩니다. 이것이 Cutover입니다.

4단계 - 모니터링 및 종료 (Monitoring & Terminate)

Green으로 트래픽을 돌린 후 에러율(500 Error, 404 Error)이 치솟는지 봅니다. 만약 문제라면? 즉시 다시 로드밸런서를 Blue로 돌립니다 (Quick Rollback). 만약 1시간 동안 문제가 없다면? 이제 Blue 그룹의 서버를 종료(Terminate)하여 비용을 절감하거나, 다음 배포를 위한 대기 상태(Staging)로 전환합니다.

4. 가장 큰 난관 - 데이터베이스 (Database)

서버(Stateless)는 그냥 2배로 늘리면 됩니다. 돈으로 해결되죠. 하지만 데이터베이스(Stateful)는 하나를 공유합니다. 여기서 문제가 터집니다.

문제 상황 - V2 배포 실패 시나리오

V1 (Blue) 코드는 users 테이블의 fullname 컬럼을 씁니다.
V2 (Green) 코드는 fullname을 쪼개서 first_name, last_name 컬럼을 씁니다.
Green 배포를 위해 DB 마이그레이션을 돌려서 fullname 컬럼을 삭제하고 first_name, last_name을 추가했습니다.
그 순간 운영 중이던 V1 서버들이 500 에러를 뿜으며 폭발합니다.
Unknown column 'fullname' 에러가 로그에 도배됩니다. 배포하기도 전에 서비스가 죽어버린 겁니다. DB 스키마가 하위 호환성을 잃었기 때문입니다.

해결책 - 팽창과 수축 (Expand and Contract) 패턴

DB 마이그레이션이 필요한 경우, 배포를 한 번에 하려 하지 말고 4단계로 쪼개야 합니다.

Expand (확장): first_name, last_name 컬럼을 추가(Add)만 합니다. fullname은 건드리지 않습니다. (V1 서버 정상 작동). 이때 트리거(Trigger)를 걸어서 fullname에 들어오는 값을 새 컬럼에도 복사해줍니다.
Migrate (이주): 기존 fullname 데이터를 새 컬럼들로 복사(Backfill)합니다.
Deploy (배포): V2 애플리케이션(Green)을 배포하고 트래픽을 돌립니다. V2는 새 컬럼을 사용합니다.
Contract (수축): V1 서버가 완전히 은퇴한 뒤에, 며칠 뒤 별도의 배포로 fullname 컬럼을 삭제합니다.

즉, "스키마 변경은 무조건 하위 호환성(Backward Compatibility)을 유지해야 한다"는 원칙을 지켜야 블루-그린 배포가 가능합니다. 이게 무중단 배포의 핵심이자 가장 귀찮은 부분입니다.

5. Kubernetes와 AWS Route53 활용

Route53 가중치 기반 라우팅 (Weighted Routing)

DNS 레벨에서도 블루-그린 배포 흉내를 낼 수 있습니다.

api.example.com A 레코드에 두 개의 IP를 연결합니다.
- IP A (Blue): 가중치 100
- IP B (Green): 가중치 0
배포 후:
- Blue: 가중치 90, Green: 가중치 10 (점진적 이동 - 카나리 스타일)
- Blue: 0, Green: 100 (완전 이동) 이 방식은 DNS 캐싱(TTL) 때문에 즉각적인 롤백이 어렵다는 단점이 있지만(사용자가 캐시된 IP를 계속 들고 있을 수 있음), 글로벌 트래픽을 제어할 때 유용합니다.

CDN 캐시 무효화 (CloudFront Invalidation)

서버 코드는 바꿨는데, 사용자는 여전히 옛날 자바스크립트나 CSS 파일을 보고 있을 수 있습니다. CDN(CloudFront)이 파일을 캐싱하고 있기 때문입니다. 블루-그린 배포 시 반드시 CDN Invalidation(캐시 삭제) 과정이 파이프라인에 포함되어야 완벽한 배포가 됩니다. 더 좋은 방법은 파일 이름에 해시값(app.a1b2c.js)을 붙여서 강제로 새 파일을 받아가게 만드는 전략(Cache Busting)을 쓰는 것입니다. 리액트나 뷰(Vue) 같은 SPA 프레임워크 빌드 도구들이 이걸 자동으로 해줍니다.

6. 마무리 - 돈이냐 안정이냐

블루-그린 배포는 리소스가 2배로 들기 때문에, 스타트업 초기에는 부담스러울 수 있습니다. 하지만 클라우드 환경(AWS)에서는 "사용한 만큼만" 돈을 내므로, 배포하는 그 30분 동안만 서버를 2배로 늘렸다가, 배포 끝나면 바로 줄이는 방식으로 비용을 아낄 수 있습니다.

사용자에게 "점검 중(503 Service Unavailable)" 화면을 보여주는 건 2010년의 감성입니다. 사용자는 기다려주지 않습니다. 새벽 3시에도 접속하는 글로벌 유저가 있을 수 있습니다. 마음 편한 퇴근(칼퇴)과 사용자의 끊김 없는 경험을 위해, 무중단 배포 파이프라인 구축은 선택이 아니라 개발 팀의 필수 역량입니다.

지금 당장 여러분의 배포 파이프라인을 점검해보세요. 배포 버튼을 누를 때 손이 떨린다면, 그것은 시스템 문제이지 여러분의 담력 문제가 아닙니다.