무중단 배포 전략 총정리(Blue-Green, Rolling, Canary)

CI/CD 파이프라인을 구축한 이유는 코드 변경을 빠르고 안전하게 운영 서버에 반영하고 싶었고, 수작업으로 배포를 진행하는 것이 너무 번거로웠기 때문이다. 하지만, 배포가 끝났음에도 불구하고 로컬에서는 잘 작동하던 코드가 서버에 반영되면서 여러 문제에 부딪히게 되었고 따라서 "사용자에게 들키지 않는 배포", 무중단 배포에 대해서 공부해야할 필요성을 느끼게 되었다.

🏗️ 기본 용어 정리

🧪 수직 확장(Scale Up) vs 수평 확장(Scale Out)부터 이해하자

🔸 수직 확장 (Vertical Scaling / Scale Up)

하나의 좋은 서버를 이용

✅ 장점	- 구현이 간단함 - 기존 애플리케이션 수정 불필요- 데이터 일관성 보장 쉬움
⚠️ 단점	- 하드웨어 성능의 한계 존재- 비용이 기하급수적으로 증가 - 단일 장애점(SPOF) 위험 - 확장 시 다운타임 발생 가능

 

🔸 수평 확장 (Horizontal Scaling / Scale Out)

여러 대의 서버로 부하를 분산하는 방식

✅ 장점	- 이론적으로 무한 확장 가능 - 일부 서버 장애 시 전체 영향 적음 - 비용 효율적, 점진적 확장 가능
⚠️ 단점	- 시스템 구조의 복잡도 증가 - 데이터 일관성 유지 어려움 - 애플리케이션 구조 수정 필요 가능성

 

🧪 로드 밸런싱 (Load Balancing) 과 로드 밸런서

✅ 로드 밸런싱

부하(트래픽)를 여러 서버에 고르게 분산시키는 기술

 

✅ 로드 밸런서

클라이언트(사용자)의 요청을 받아서, 백엔드 서버들 중 하나로 전달하고, 각 서버의 부하를 고려하여 효율적으로 분산 처리한다. 즉, 로드밸런서는 마치 공항에서 줄 세우는 직원처럼 "너는 이쪽 창구, 너는 저쪽 창구" 하면서 요청을 나눠주는 역할을 하는 것이다.

🧪 다운 타임

서버 한 대로 서비스를 운영한다고 가정했을 때, 현재는 V1으로 운영중이지만, 사용자들이 개발이 완료된 V2로 이용할 수 있도록 변경해야한다.

과연 어떻게 할 수 있을까 ?

우선 기존에 실행 중인 V1 버전을 종료한 후 V2 버전을 실행해야 한다. 이 과정에서 두 버전은 동일한 포트를 사용하기 때문에, V2를 실행하기 전에는 반드시 V1을 종료해야 한다. 이때 발생하는 사용자 접속 불가 구간을 다운타임(downtime)이라 하며, 이런 방식의 배포를 중단 배포라고 한다.

🏗️ 무중단 배포

무중단 배포란 말 그대로 서비스가 중단되지 않은 상태로 새로운 버전을 배포하는 것이다. 서비스가 계속 운영되는 상태에서 새로운 버전의 어플리케이션을 배포하는 과정에서 시스테 가동시간을 최소화하여 사용자에게 생기는 불편함(다운타임)이 없는 방식이다.

Blue/Green 배포

두 개의 독립된 배포 환경(Blue와 Green)을 준비하고, 트래픽을 새로운 버전이 배포된 환경으로 전환하는 방식

• Blue: 현재 운영 중인 안정된 환경 (예: V1)
• Green: 새 버전을 배포하고 테스트할 환경 (예: V2)

 

🚀 배포 절차

1. 현재 운영 중인 서버(V1)는 Blue 환경에 있다.
2. 새로운 V2 버전을 Green 환경에 배포하고, 테스트까지 완료한다.
3. 문제가 없으면 로드밸런서의 트래픽을 Blue → Green으로 전환한다.
4. 이제 Green 환경이 운영을 담당하며, Blue 환경은 백업용으로 남긴다.
5. 문제가 생기면 로드밸런서를 다시 Green → Blue로 빠르게 롤백할 수 있다.

📝 장단점

구분설명

✅ 장점
완전한 무중단 배포	트래픽 스위칭만으로 새 버전 적용 가능
빠른 롤백 가능	문제가 생기면 즉시 이전 환경(Blue)으로 전환 가능
운영 상태 분리	배포 중인 환경과 운영 중인 환경이 완전히 분리됨
배포 리스크 최소화	새 버전을 전체 테스트 후 실제 트래픽 전환
⚠️ 단점
인프라 비용 증가	Blue와 Green 두 환경을 동시에 유지해야 함
공통 자원 충돌	DB나 캐시 등 공유 리소스 간의 상태 충돌 우려
데이터 마이그레이션 복잡	DB 스키마가 변경될 경우 롤백이 어려워짐
전환 관리 필요	트래픽 전환 시 타이밍과 헬스체크가 중요함

📌 언제 쓰면 좋을까?

• 실서비스 트래픽이 많고, 다운타임이 허용되지 않을 때
• 롤백 속도가 중요한 서비스 (ex: 결제 시스템, 사용자 데이터 변경 등)
• 배포 전후 상태를 명확히 분리해 테스트하고 싶을 때

Rolling 배포

롤링 배포의 경우, 여러 서버 중 일부만 순차적으로 업데이트하면서 전체 배포를 완료하는 방식이다.
즉, 모든 인스턴스를 한꺼번에 교체하는 것이 아니라, 정해진 비율만큼 점진적으로 새 버전으로 교체하면서 전체 배포를 완료한다.

 

🚀 배포 절차

1. 전체 서버 중 일부(예: 1개)를 선택하여 새 버전(V2)으로 교체
2. 헬스체크를 통과하면 다음 서버를 교체
3. 전체 서버가 V2로 전환될 때까지 반복
4. 문제 발생 시 롤백 또는 배포 중단 가능

📝 장단점

구분설명

✅ 장점
무중단 배포 가능	서버를 순차적으로 교체하여 서비스 중단 없이 배포 가능
인프라 비용 절감	기존 서버를 재활용하므로 별도 이중 환경 불필요
점진적 배포	문제 발생 시 배포를 중단하고 영향 범위를 제한할 수 있음
CI/CD와 통합 용이	자동화된 파이프라인 구축에 적합
⚠️ 단점
롤백이 복잡함	중간 단계에서 문제가 생기면 일부만 롤백하기 어려움
신구 버전 동시 운영	호환성 문제나 상태 불일치 발생 가능성 있음
사용자 경험 불일치	어떤 사용자는 V1, 어떤 사용자는 V2를 경험할 수 있음
전체 배포 시간 증가	서버를 하나씩 교체하므로 시간이 오래 걸림

 

📌 언제 쓰면 좋을까?

• 서버가 여러 대인 경우
• 클라우드 환경이나 Kubernetes 사용 중인 경우
• 점진적 배포/모니터링이 중요한 서비스
• 비용 효율성을 중요시하는 팀

카나리(Canary) 배포

🧐 Canary가 뭔뎅 ?

"Canary"라는 이름은 과거 광부들이 유독가스를 감지하기 위해 가스에 민감한 카나리아 새를 먼저 탄광에 들여보냈던 일화에서 유래되었다. 서비스에서도 마찬가지로, "일부 사용자"가 초기 탐지자 역할을 맡는 셈이다.

Canary 배포는 새로운 버전을 전체 사용자에게 한 번에 적용하지 않고, 일부 사용자에게만 먼저 노출시켜 테스트하는 배포 방식이다. 이 방식은 배포 초기에 발생할 수 있는 오류나 성능 이슈를 조기에 감지하고, 문제가 없을 경우에만 점진적으로 전체 트래픽을 옮겨가는 것이 핵심이다.

 

🚀 배포 절차

1. 전체 트래픽 중 일부만 새 버전(V2)이 배포된 서버로 전달한다.
2. (예: 전체 요청 중 5%만 V2로 전송)
3. 새 버전의 동작을 모니터링하며, 오류율이나 성능 저하 여부를 분석한다.
4. (로그, 메트릭, 사용자 반응 등 기반)
5. 이상이 없다고 판단되면, 트래픽 비율을 점진적으로 증가시킨다.
6. (예: 5% → 25% → 50% → 100%)
7. 모든 트래픽이 V2로 안전하게 전환되면 배포 완료.
8. 문제 발생 시, 트래픽을 즉시 기존 버전(V1)으로 되돌리거나 배포를 중단한다.

📝 장단점

구분설명

✅ 장점
리스크 최소화	소수 사용자 대상으로 먼저 배포하여 문제 조기 탐지 가능
트래픽 제어 유연	점진적으로 트래픽을 조절하며 안전하게 배포 가능
무중단 배포 가능	전체 서비스를 끊지 않고도 배포 가능
A/B 테스트 활용 가능	사용자 그룹별로 실험 적용 가능
⚠️ 단점
운영 복잡도 증가	트래픽 분기, 모니터링, 자동화 구성 필요
신구 버전 공존	세션, 데이터 구조 차이로 호환성 문제 발생 가능
사용자 경험 불일치	사용자마다 사용하는 버전이 다를 수 있음
롤백 설계 필요	트래픽 전환 중 문제 발생 시 복구 시나리오 필수

 

📌 언제 쓰면 좋을까?

• 새 기능에 대한 불확실성이 클 때
• 사용자 수가 많아 일괄 배포가 부담스러울 때
• 데이터 기반 A/B 테스트를 병행하고 싶을 때
• 실시간 대응과 롤백 전략이 준비되어 있을 때

참고문헌

https://hudi.blog/zero-downtime-deployment/#:~:text=downtime

https://www.samsungsds.com/kr/insights/1256264_4627.html

https://www.youtube.com/watch?v=sIPU_VkrguI

https://www.youtube.com/watch?v=6SvUZqbU37E