서비스 규모가 커질수록 새로운 Version을 한 번에 모든 사용자에게 적용하는 것은 위험합니다.
새로운 코드에 문제가 있을 경우 전체 사용자가 영향을 받을 수 있기 때문입니다.
기존 방식:
새 Version 배포
↓
전체 사용자 적용
↓
문제 발생
↓
전체 장애Canary 배포는 일부 사용자에게만 새로운 Version을 먼저 적용하고 문제가 없는지 확인한 뒤 점차 확대하는 방식입니다.
기본 구조:
사용자 100%
↓
90% 기존 Version
↓
10% 새로운 Version확인 후:
10%
↓
50%
↓
100%으로 Traffic을 증가시킵니다.
이번 글에서는 Docker Compose Canary 배포 개념부터 Container 구성, Nginx Traffic 제어, 점진적 배포 과정, Rollback 방법까지 Production 서버 기준으로 알아보겠습니다.
Canary 배포란 무엇인가?
Canary라는 이름은 광산에서 유래되었습니다.
과거 광부들은 위험한 가스 감지를 위해 카나리아 새를 사용했습니다.
서비스 배포에서도 같은 의미입니다.
새로운 Version을 소수 사용자에게 먼저 적용하여 위험을 확인합니다.
구조:
기존 서비스
↓
새 Version 일부 적용
↓
문제 확인
↓
전체 확대Blue Green과 Canary 차이
Blue Green:
Version A
↓
Version B 전체 전환Canary:
Version A 90%
Version B 10%차이:
| 방식 | 특징 |
|---|---|
| Blue Green | 한 번에 Traffic 전환 |
| Canary | 점진적 Traffic 증가 |
Docker Compose Canary 배포 구조
기본 구조:
사용자
↓
Nginx / Load Balancer
↓
App Stable
↓
App Canary예:
app-v1
↓
기존 서비스
app-v2
↓
신규 테스트 VersionDocker Compose Stable Container 구성
기존 Version:
services:
app-stable:
image: my-app:1.0
container_name: app-stable구조:
사용자
↓
app-stableDocker Compose Canary Container 구성
새 Version:
services:
app-canary:
image: my-app:2.0
container_name: app-canary구조:
일부 사용자
↓
app-canaryDocker Compose Traffic 비율 제어
Canary 배포의 핵심은 Traffic 제어입니다.
예:
초기:
Stable 90%
Canary 10%검증 후:
Stable 50%
Canary 50%최종:
Canary 100%Docker Compose Nginx Canary 설정
Nginx upstream 예:
upstream app {
server app-stable:3000 weight=9;
server app-canary:3000 weight=1;
}의미:
Stable
90%
Canary
10%Traffic 분배:
사용자 요청
↓
Nginx
↓
비율 분배Docker Compose Canary 배포 과정
1단계:
기존 서비스 운영
app-v1
↓
100% Traffic2단계:
Canary 실행
app-v2 시작3단계:
일부 Traffic 전달
90 : 104단계:
Monitoring 확인
확인:
- Error Rate
- Response Time
- CPU
- Memory
5단계:
확대
10%
↓
50%
↓
100%Docker Compose Canary Healthcheck 적용
새 Version은 반드시 검증해야 합니다.
설정:
healthcheck:
test:
- CMD
- curl
- localhost:3000
interval: 10s
retries: 5과정:
Canary 실행
↓
Health Check
↓
Traffic 적용Docker Compose Canary Monitoring
Canary 배포에서는 Monitoring이 매우 중요합니다.
확인 항목:
Error Rate
예:
기존
0.1%
Canary
5%문제 감지 가능
Response Time
응답 속도 증가 확인Resource
CPU
MemoryDocker Compose Canary Rollback
문제 발생:
Canary 오류 증가즉시:
Canary Traffic 제거변경:
upstream app {
server app-stable:3000;
}결과:
전체 사용자
↓
Stable VersionDocker Compose Canary와 CI/CD 연결
자동화 구조:
Git Push
↓
CI Build
↓
Canary Container Deploy
↓
일부 Traffic 적용
↓
Monitoring
↓
확대 또는 RollbackPipeline:
Build
↓
Deploy Canary
↓
Test
↓
Traffic 증가
↓
Complete DeployDocker Compose Canary 장점
위험 감소
전체 장애 방지
실제 사용자 환경 테스트
Production 데이터 기반 확인 가능
빠른 문제 발견
초기 사용자 반응 확인
Rollback 쉬움
Traffic 제거만으로 복구
Docker Compose Canary 단점
운영 복잡도 증가
두 Version 관리 필요
Monitoring 필수
문제 감지 시스템 필요
Database 변경 주의
Schema 호환 필요
Docker Compose Production Canary 구조
실제 운영:
사용자
↓
Load Balancer
↓
Nginx
↓
Stable App 90%
Canary App 10%
↓
Redis
↓
Database
↓
MonitoringDocker Compose Canary Best Practice
추천:
- 작은 비율부터 시작
- Healthcheck 적용
- Error Monitoring
- 자동 Rollback
- Image Version 관리
- Database Migration 검증
운영 흐름:
새 Version Build
↓
Canary Deploy
↓
10% Traffic
↓
Monitoring
↓
50%
↓
100%자주 묻는 질문
Canary 배포는 작은 서비스에도 필요한가요?
가능하지만 운영 규모가 커질수록 효과가 커집니다.
Blue Green과 Canary 중 어떤 것이 좋은가요?
서비스 특성에 따라 다릅니다.
빠른 전환은 Blue Green, 위험 최소화는 Canary가 적합합니다.
Docker Compose에서도 Canary가 가능한가요?
가능합니다.
Nginx, Load Balancer를 이용해 Traffic 제어 구조를 만들 수 있습니다.
Canary 배포에서 가장 중요한 것은 무엇인가요?
Monitoring과 Rollback 준비입니다.
마무리
Docker Compose Canary 배포는 새로운 Version을 안전하게 출시하기 위한 중요한 운영 전략입니다.
핵심 구조:
기존 Version 유지
↓
새 Version 일부 적용
↓
Monitoring
↓
Traffic 확대
↓
전체 전환이 방식을 사용하면 Production 서비스 장애 위험을 줄이고 안정적으로 새로운 기능을 배포할 수 있습니다.
다음 글에서는 Blue Green과 Canary를 포함한 전체 운영 방식을 정리하는 Docker Compose 무중단 배포 전략을 알아보겠습니다.