서비스 규모가 커질수록 배포 과정에서 가장 중요한 것은 서비스 중단 시간을 최소화하는 것입니다.
일반적인 배포 방식에서는 새로운 Version을 적용할 때 Container를 재시작해야 합니다.
기존 방식:
기존 Container 종료
↓
새 Version 실행
↓
서비스 재시작문제:
- 짧은 시간 서비스 중단
- 배포 실패 위험
- Rollback 어려움
Blue Green 배포 방식은 기존 서비스를 유지하면서 새로운 Version을 별도로 실행한 후 Traffic을 전환하는 방법입니다.
기본 구조:
사용자
↓
Load Balancer
↓
Blue 환경 (현재 운영)
Green 환경 (새 Version)동작:
Blue 실행 중
↓
Green 배포
↓
테스트
↓
Traffic 전환
↓
Blue 종료이번 글에서는 Docker Compose Blue Green 배포 개념부터 Container 구성, Network 전환, Rollback 방법, Production 운영 구조까지 알아보겠습니다.
Blue Green 배포란 무엇인가?
Blue Green 배포는 두 개의 동일한 운영 환경을 유지하는 배포 방식입니다.
Blue:
현재 사용자에게 서비스 중인 Version
Green:
새롭게 배포하는 Version
구조:
Blue
↓
현재 Production
Green
↓
새로운 Release새 Version 검증이 끝나면 Traffic을 Green으로 이동합니다.
기존 배포 방식과 비교
기존 방식:
Version 1
↓
Container 종료
↓
Version 2 실행문제:
Downtime 발생Blue Green:
Version 1 유지
↓
Version 2 실행
↓
Traffic 변경장점:
- 무중단 배포
- 빠른 Rollback
- 안정적인 Release
Docker Compose Blue Green 구조
기본 구조:
Nginx
↓
Blue Container
↓
Application v1
Green Container
↓
Application v2Docker Compose에서는 Service 이름을 분리합니다.
예:
app-blue
app-greenDocker Compose Blue 환경 구성
docker-compose.blue.yml:
services:
app-blue:
image: my-app:1.0
container_name:
app-blue
ports:
- "3001:3000"구조:
Host 3001
↓
Blue ContainerDocker Compose Green 환경 구성
docker-compose.green.yml:
services:
app-green:
image: my-app:2.0
container_name:
app-green
ports:
- "3002:3000"구조:
Host 3002
↓
Green ContainerDocker Compose Blue Green 배포 과정
현재 상태:
Blue
↓
사용자 접속 중새 Version 배포:
Green Container 생성
↓
Healthcheck 확인
↓
테스트정상 확인:
Traffic 이동최종:
사용자
↓
Green
↓
ProductionDocker Compose Nginx Traffic 전환
실제 환경에서는 Nginx가 Traffic을 관리합니다.
기존:
upstream app {
server app-blue:3000;
}변경:
upstream app {
server app-green:3000;
}Reload:
nginx -s reload결과:
사용자 Traffic
↓
Green 이동Docker Compose Healthcheck 적용
Blue Green 배포에서는 새 Version 검증이 중요합니다.
Green 실행:
Container 시작
↓
Healthcheck 실행
↓
healthy 확인설정:
healthcheck:
test:
- CMD
- curl
- localhost:3000
retries: 5healthy 상태 이후 Traffic을 변경합니다.
Docker Compose Rollback 방법
배포 후 문제가 발생하면 빠르게 이전 환경으로 돌아갑니다.
상황:
Green 오류 발생복구:
Traffic
↓
Blue 이동장점:
- 서비스 중단 최소화
- 빠른 복구
Docker Compose Database 주의사항
Application은 쉽게 Blue Green 전환이 가능합니다.
하지만 Database는 주의해야 합니다.
문제:
Blue Application
↓
Database 변경
↓
Green 호환 문제해결:
Database Migration 전략 필요
방법:
- Backward Compatible Migration
- 단계별 Schema 변경
- Migration 테스트
Docker Compose Blue Green CI/CD 연결
자동화 구조:
Git Push
↓
CI Build
↓
Green Container 생성
↓
Test
↓
Traffic 변경
↓
Blue 제거Pipeline:
Build
↓
Deploy Green
↓
Health Check
↓
Switch
↓
CleanupDocker Compose Blue Green 장점
장점:
무중단 배포
서비스 유지
빠른 Rollback
문제 발생 시 즉시 복구
안정적인 테스트
Production과 동일 환경 검증
배포 위험 감소
새 Version 검증 후 적용
Docker Compose Blue Green 단점
주의:
Resource 증가
두 개 환경 실행 필요
Database 관리 필요
Schema 변경 어려움
Traffic 관리 필요
Load Balancer 필요
Docker Compose Production Blue Green 구조
실제 운영:
User
↓
Load Balancer
↓
Nginx
↓
Blue App v1
Green App v2
↓
Database
↓
Redis
↓
StorageDocker Compose Blue Green Best Practice
추천:
- Image Version 고정
- Healthcheck 적용
- 자동 Rollback 준비
- Database Migration 테스트
- Monitoring 연결
- Traffic 전환 자동화
운영 흐름:
새 Version Build
↓
Green Deploy
↓
Health Check
↓
Traffic Switch
↓
Monitoring
↓
Blue 삭제자주 묻는 질문
Blue Green 배포는 Docker Compose에서도 가능한가요?
가능합니다.
Service와 Traffic 전환 구조를 구성하면 사용할 수 있습니다.
작은 서버에서도 사용할 수 있나요?
가능하지만 두 환경을 동시에 실행하기 때문에 추가 Resource가 필요합니다.
Blue Green과 Rollback 차이는 무엇인가요?
Blue Green은 배포 방식이고 Rollback은 문제가 발생했을 때 이전 Version으로 돌아가는 과정입니다.
Database도 Blue Green으로 두 개 운영하나요?
일반적으로 Application은 두 개 운영하고 Database는 별도 Migration 전략을 사용합니다.
마무리
Docker Compose Blue Green 배포는 안정적인 Production 운영을 위한 대표적인 무중단 배포 방식입니다.
핵심 구조:
현재 Version
↓
Blue 유지
새 Version
↓
Green 배포
검증 완료
↓
Traffic 전환이 방식을 적용하면 서비스 중단 없이 새로운 기능을 배포하고 문제가 발생하면 빠르게 이전 Version으로 복구할 수 있습니다.
다음 글에서는 점진적으로 사용자에게 새로운 Version을 적용하는 Docker Compose Canary 배포 전략을 알아보겠습니다.