| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 | 31 |
Tags
- entity
- 문서번호
- 데이터베이스 #try #이중
- es6
- 컴포넌튼
- 10px
- Strict
- 1px border
- 당근마켓
- 전역변수
- 타입스크립트
- 0.75px border
- ZOOM
- TypeScript
- 으
- jwt
- Props
- 클론코딩
- github
- 서버리스 #
- &연산
- 0.5px border
- literal
- angular
- Websocket
- npm
- font-size
- TS
- 0.25px border
- ES5
Archives
- Today
- Total
복잡한뇌구조마냥
[Infra] 무중단 배포 ( Blue-Green, Rolling, Canary ) 본문
🧩무중단 배포란?
👉 서비스를 중단하지 않고 새로운 버전을 배포하는 방식을 의미한다.
배포 중에도
기존 사용자는 정상 요청 처리
새 버전은 준비 완료 후 자연스럽게 전환
❓ 왜 무중단 배포가 필요한가?
전통적인 배포 방식의 문제
서버 종료
→ 새 버전 배포
→ 서버 재시작
→ 서비스 재개
이 방식은 배포 시간 동안
- ❌ 서비스 접속 불가
- ❌ 요청 실패
- ❌ 사용자 이탈
- ❌ 트래픽 많은 서비스에 치명적
“배포 = 장애”가 되어버리는 구조
🎯 무중단 배포의 핵심 목표
| 목표 | 설명 |
| 서비스 연속성 | 배포 중에도 요청 처리 |
| 안정성 | 문제 발생 시 빠른 롤백 |
| 점진적 전환 | 새 버전으로 자연스럽게 이동 |
🧩 무중단 배포의 기본 원리
무중단 배포의 핵심은 단 하나다.
“트래픽을 어디로 보낼지 제어한다”
1️⃣ Blue-Green Deployment

🔹 개념
- Blue: 현재 운영 중인 버전
- Green: 새로 배포할 버전
Blue (운영 중)
Green (배포 & 테스트)
문제 없으면
→ 트래픽을 Green으로 전환
✅ 장점
- 구조가 단순
- 롤백이 매우 쉬움 (트래픽만 되돌리면 끝)
❌ 단점
- 서버를 2배로 운영해야 함
- 비용 증가
👉 EC2 + Nginx / ALB 환경에서 가장 많이 사용
2️⃣ Rolling Deployment

🔹 개념
- 서버를 하나씩 순차적으로 교체
- 전체 서비스는 계속 유지
서버 1 교체
서버 2 교체
서버 3 교체
✅ 장점
- 추가 서버 필요 없음
- 비용 효율적
❌ 단점
- 배포 중 버전 혼재
- 하위 호환성 필요
👉 Kubernetes 환경에서 기본 전략
3️⃣ Canary Deployment

🔹 개념
- 일부 사용자에게만 새 버전 먼저 노출
- 이상 없으면 점진적으로 확대
5% → 20% → 50% → 100%
✅ 장점
- 장애 영향 최소화
- 실제 트래픽으로 검증 가능
❌ 단점
- 트래픽 제어 로직 필요
- 모니터링 필수
👉 대규모 트래픽 서비스에서 사용
4️⃣ 무중단 배포에서 반드시 고려해야 할 요소
🔸 1. 헬스 체크 (Health Check)
컨테이너 올라감 ≠ 서비스 준비 완료
- DB 연결
- 캐시 연결
- 외부 API 의존성
👉 준비 완료 후에만 트래픽 연결
🔸 2. 세션 관리
- 서버 로컬 세션 ❌
- Redis / JWT 기반 세션 ✅
👉 무중단 배포의 숨은 핵심 포인트
🔸 3. DB 변경 전략
- 컬럼 삭제 ❌
- 점진적 변경 ✅
1단계: 컬럼 추가
2단계: 코드 반영
3단계: 기존 컬럼 제거
🔸 4. 롤백 전략
무중단 배포에서
배포보다 중요한 건 롤백
- 이전 이미지 유지
- 빠른 트래픽 전환
- 데이터 호환성 유지
🔄 무중단 배포와 캐시 / 트래픽 문제
무중단 배포 중에도 이런 문제가 생길 수 있다.
- 캐시 초기화
- Redis 재시작
- DB 커넥션 재설정
👉 잘못하면 Cache Stampede + Thundering Herd 유발
대응 전략
- 캐시 TTL 지터
- 배포 시 캐시 flush 지양
- warm-up 요청 수행
🧠 많이 쓰는 조합
EC2 + Docker
→ Blue-Green Deployment
→ Nginx / ALB 트래픽 전환
→ 헬스 체크 기반 연결
→ 문제 시 즉시 롤백
개인 프로젝트 ~ 중소 서비스에서 현실적인 선택
📌 한눈에 비교
| 방식 | 장점 | 단점 | 추천 환경 |
| Blue-Green | 단순, 롤백 쉬움 | 비용 ↑ | EC2 |
| Rolling | 비용 효율 | 버전 혼재 | K8s |
| Canary | 안정성 ↑ | 복잡 | 대규모 |
✍️ 마무리
무중단 배포는
단순히 “서버를 두 개 띄우는 것”이 아니라
트래픽, 세션, DB, 캐시까지 포함한 운영 전략이다.
참고자료:
배포 전략 종류 (롤링 / 블루 · 그린 / 카나리)
MSA의 무중단 배포 전략에 대해 알아보자
velog.io
LIST
'BE > Infra' 카테고리의 다른 글
| [AWS] Lambda + CloudFront 이미지 최적화 ( 리사이징, 캐싱 ) (0) | 2025.12.09 |
|---|---|
| [Infra] Terraform (0) | 2025.12.07 |
| [Infra] Prometheus + Grafana 서버 모니터링 (Docker 기반) (0) | 2025.12.03 |
| [AWS] 배포 정리(EC2 + ECR + RDS + Nginx) (0) | 2025.10.16 |
| Json-server, heroku, env (서버 배포) (0) | 2022.09.04 |