무중단 배포 전략 A to Z: 블루그린, 카나리, 롤링, 섀도우 완벽 분석
서비스 중단 없는 무중단 배포(Zero-Downtime Deployment)의 필요성과 다양한 전략 소개
블루그린(Blue-Green), 카나리(Canary), 롤링(Rolling), 섀도우(Shadow) 배포 방식의 개념, 실습, 장단점 비교 분석
각 배포 방식별 안전한 운영을 위한 고려사항 및 쿠버네티스(Kubernetes) 적용 방안 제시
실제 운영 환경에서는 리소스 제약으로 인해 카나리+롤링 방식 혼합 사용이 현실적임을 시사
블루그린 배포: 빠른 전환과 명확한 환경 분리의 이점
블루그린 배포는 운영 환경(Blue)과 새 버전 환경(Green)을 완전히 분리하여 운영 안정성을 극대화하는 전략이다.
빠른 전환 속도: 준비된 Green 환경으로 트래픽을 한 번에 전환하므로 배포 전환 시간(Deployment Switch Time)이 매우 짧다.
신속한 롤백: 새 버전에 문제가 발생하면 코드 재배포 없이 즉시 Blue 환경으로 트래픽을 되돌릴 수 있어 롤백(Rollback) 부담이 적다.
명확한 환경 경계: 운영 중인 Blue와 배포할 Green 환경이 명확히 구분되어 운영자의 가시성(Visibility)이 높다.
하지만 두 개의 전체 환경을 동시에 유지해야 하므로 인프라 비용(Infrastructure Cost)이 크고, 트래픽 전환 순간의 영향 범위(Impact Scope)가 넓다는 단점이 존재한다. 특히 데이터베이스 스키마 변경 시 호환성(Backward Compatibility) 문제가 발생할 수 있어 주의가 필요하다.
카나리 배포: 점진적 검증을 통한 장애 영향 범위 최소화
카나리 배포는 새 버전을 일부 사용자 또는 트래픽에만 점진적으로 노출하여 안정성을 검증하는 방식이다.
장애 영향 범위 축소: 문제가 발생해도 영향받는 사용자를 제한할 수 있어 전체 서비스 장애로 이어질 위험이 낮다.
맞춤형 사용자 그룹 검증: 특정 사용자 그룹을 대상으로 먼저 배포하여 피드백 수집 및 위험도 낮은 검증이 가능하다.
상대적으로 작은 롤백 부담: 새 버전으로 가는 트래픽만 차단하면 되므로 블루그린보다 롤백 부담이 적다.
단점으로는 운영 및 설정의 복잡성 증가, 두 버전 간 호환성 유지의 어려움, 사용자 경험의 비일관성 발생 가능성이 있다. 또한, 서비스 트래픽이 적을 경우 판단 근거 확보가 어렵다는 제약이 있다. 안전한 카나리 배포를 위해서는 작은 비율로 시작하고, 모니터링 지표 기반의 단계적 전환 및 사용자 기반 라우팅이 필수적이다.
롤링 배포: 추가 인프라 부담 없이 점진적 교체
롤링 배포는 기존 인스턴스를 하나씩 순차적으로 새 버전으로 교체하는 방식으로, 추가 인프라 부담이 적다는 장점이 있다.
적은 리소스 증가: 새 컨테이너를 추가하고 기존 컨테이너를 제거하는 과정을 반복하므로 동시 운영 인스턴스 수가 크게 늘지 않는다.
기존 구조 유지 용이: 복잡한 배포 구조 없이 기존 컨테이너 운영 방식 위에 적용하기 쉽다.
점진적 전환 부담 감소: 급격한 트래픽 전환 없이 점진적으로 교체가 이루어진다.
하지만 기존 버전과 새 버전이 동시에 운영되므로 API 응답 형식, DB 사용 방식 등에서 호환성 문제가 발생할 수 있으며, 사용자 경험의 비일관성이나 느린 배포 속도가 단점으로 지적된다. stop-first와 start-first 방식은 컨테이너 교체 순서에 따라 트래픽 전환 흐름이 달라지며, 쿠버네티스에서는 `maxUnavailable`과 `maxSurge` 설정을 통해 유사한 동작을 구현할 수 있다.
섀도우 배포: 실제 트래픽 기반의 안전한 새 버전 검증
섀도우 배포는 실제 사용자 요청을 기존 버전이 처리하면서, 동일한 요청을 새 버전에도 복사하여 전달하는 방식이다.
실제 운영 트래픽 기반 검증: 로드 테스트만으로는 발견하기 어려운 실제 요청 패턴, 예외 케이스, 성능 문제를 확인할 수 있다.
사용자 경험 영향 없음: 새 버전의 응답은 사용자에게 전달되지 않으므로, 잘못된 응답이나 오류가 발생해도 사용자에게 영향을 주지 않는다.
결과 비교 용이: 동일 요청에 대한 두 버전의 응답을 비교하여 결과의 정확성(Result Accuracy)을 검증하기 좋다.
단점으로는 리소스 비용 증가, 쓰기 요청(Write Request) 처리 시 주의 필요성, 그리고 복잡한 운영 구성이 요구된다는 점이다. 특히 쓰기 요청의 경우, 격리된 DB 사용이나 Idempotency 설계를 통해 중복 처리 부작용을 방지해야 한다.
쿠버네티스(Kubernetes) 환경에서의 카나리 배포 구현
쿠버네티스 환경에서는 다양한 도구를 활용하여 카나리 배포를 구현할 수 있다.
Deployment 리소스 활용: Pod 수를 조절하여 트래픽 비율을 점진적으로 늘리는 기본적인 방식이다.
Istio 기반 트래픽 라우팅: `VirtualService`를 통해 정교한 트래픽 비율 제어가 가능하며, Pod 개수와 무관하게 라우팅 규칙을 설정할 수 있다.
Argo Rollouts: 카나리 배포 흐름을 선언적으로 관리하고, 단계별 진행, 운영자 승인, 분석 기반 배포 중단/롤백 기능을 제공한다.
Flagger: Prometheus 등 모니터링 지표를 기반으로 메트릭 기반 자동화된 카나리 배포 및 롤백을 수행한다.
쿠버네티스 기본 `Deployment`의 `RollingUpdate` 전략은 `maxUnavailable`과 `maxSurge` 값을 조정하여 stop-first 또는 start-first와 유사한 동작을 구현할 수 있다.
무중단 배포 전략 선택 시 고려사항
무중단 배포 전략 선택은 서비스의 안정성 요구사항, 리소스 제약, 운영 복잡성 등을 종합적으로 고려해야 한다.
블루그린: 빠른 전환과 명확한 환경 분리가 중요하고 리소스 여유가 있을 때 적합하다.
카나리: 장애 영향 범위를 최소화하고 점진적 검증이 필요할 때 유리하지만, 운영 복잡성과 호환성 문제가 따른다.
롤링: 추가 인프라 부담을 줄이고 기존 구조를 유지하며 점진적 교체를 원할 때 고려할 수 있다.
섀도우: 실제 트래픽으로 새 버전의 정확성과 성능을 검증하고 싶지만 사용자 영향은 피하고 싶을 때 유용하다.
실무에서는 리소스 제약으로 인해 카나리 배포와 롤링 배포를 혼합하여 사용하는 경우가 많으며, DB 변경 시 하위 호환성 확보와 중요 요청에 대한 Idempotency 설계는 모든 배포 전략에서 공통적으로 중요한 고려사항이다.
