서버의 다운타임을 최소화하는 배포 전략. ![[Pasted image 20260326172211.png]] ## 전략별 비교 **① Rolling Deployment** — 가장 기본적인 방법으로 인스턴스를 하나씩 새 버전으로 교체합니다. 전환 중 v1/v2가 동시에 서비스되므로 API 하위 호환성이 필요하고, DB 마이그레이션 전략(expand-contract 패턴)도 병행해야 합니다. GCP Cloud Run, Kubernetes rollout이 이 방식을 기본으로 씁니다. **② Blue-Green Deployment** — v2 환경을 미리 완전히 세팅한 뒤 LB(또는 DNS)만 전환합니다. 전환 자체는 수초 안에 끝나고, 문제 발생 시 즉시 롤백이 가능합니다. 단, 리소스가 2배 필요하고 전환 순간 새 연결이 몰릴 수 있어 warm-up이 중요합니다. **③ Canary Deployment** — 새 버전에 전체 트래픽의 1~10%만 먼저 흘려보내고, 에러율·레이턴시를 모니터링하면서 점진적으로 100%로 늘립니다. 실사용자로 검증하는 가장 안전한 방법이지만, 분석을 위한 관측성(Observability) 구축이 전제됩니다. --- ## 공통으로 필요한 것들 **DB 마이그레이션** — 절대 DROP/RENAME을 배포와 동시에 하지 말고, `v1이 읽을 수 있는 상태 유지 → v2 배포 → 이후 컬럼 정리` 순서로 분리합니다. **Health check** — `/health` 엔드포인트가 정상 응답할 때만 트래픽을 보내도록 LB를 설정해야 합니다. Cloud Run이나 Kubernetes readiness probe가 이 역할을 합니다. **Connection draining** — 기존 인스턴스에 요청이 남아있을 수 있으므로, 종료 전 수십 초의 `graceful shutdown` 시간을 줘야 합니다 (Cloud Run은 `--timeout` 설정). **Feature flag** — 코드를 먼저 배포하고 기능은 플래그로 켜는 방식이면, 배포 자체의 위험도를 크게 낮출 수 있습니다.