Production 서버에서 새로운 Version을 배포할 때 가장 중요한 것은 문제가 발생했을 때 빠르게 이전 상태로 복구하는 것입니다.
아무리 테스트를 진행해도 실제 운영 환경에서는 예상하지 못한 문제가 발생할 수 있습니다.
예:
새 Version 배포
↓
Application 오류 발생
↓
사용자 영향 발생Rollback 시스템이 없다면 복구 시간이 길어지고 서비스 장애 시간이 증가합니다.
Rollback은 문제가 발생했을 때 이전에 정상적으로 동작하던 Version으로 돌아가는 과정입니다.
기본 구조:
New Version
↓
문제 발생
↓
Rollback 실행
↓
Previous Version 복구이번 글에서는 Docker Compose Rollback 개념부터 Image Version 관리, 자동 복구 Script, CI/CD Rollback Pipeline, Production 운영 전략까지 알아보겠습니다.
Docker Compose Rollback이란?
Rollback은 배포한 Version을 이전 안정 Version으로 되돌리는 작업입니다.
예:
정상 운영:
app:1.0새 배포:
app:2.0문제 발생:
app:2.0 오류Rollback:
app:1.0 복구Rollback이 필요한 이유
Production 환경에서는 다양한 문제가 발생할 수 있습니다.
대표적인 장애:
- Application 오류
- 환경 변수 문제
- Database Migration 오류
- Memory 증가
- 성능 저하
- Dependency 충돌
배포 실패 시:
빠른 복구
↓
서비스 정상화
↓
사용자 영향 최소화Docker Compose Image Version 관리
Rollback의 핵심은 Image Version 관리입니다.
좋지 않은 방식:
image: my-app:latest문제:
현재 Version 확인 어려움권장:
image: my-app:1.2.0Version 구조:
my-app:1.0.0
my-app:1.1.0
my-app:1.2.0이전 Version을 항상 유지해야 합니다.
Docker Compose 수동 Rollback 방법
현재:
app:2.0변경:
docker-compose.yml
image: my-app:1.9재배포:
docker compose up -d결과:
새 Version 제거
↓
이전 Version 실행Docker Compose Rollback Script 작성
자동 복구 Script를 만들 수 있습니다.
rollback.sh:
#!/bin/bash
echo "Rollback Start"
docker compose down
docker compose up -d실행:
chmod +x rollback.sh활용:
장애 발생
↓
Script 실행
↓
복구Docker Compose Healthcheck 기반 Rollback
Healthcheck를 이용하면 자동 판단이 가능합니다.
구조:
Deploy
↓
Healthcheck
↓
실패
↓
Rollback예:
Container unhealthy
↓
이전 Image 실행Docker Compose CI/CD Rollback 구조
자동화 Pipeline:
Git Push
↓
Build
↓
Deploy New Version
↓
Health Check
↓
성공
↓
완료
실패
↓
Rollback구조:
New Version
↓
검증
↓
문제 발생
↓
Previous VersionDocker Compose GitHub Actions Rollback
Workflow에서 실패 처리를 추가할 수 있습니다.
예:
- name: Deploy
run: docker compose up -d
- name: Rollback
if: failure()
run: ./rollback.sh동작:
Deploy 실패
↓
Rollback Script 실행Docker Compose Database Rollback 주의사항
Application Rollback보다 Database Rollback이 어렵습니다.
예:
Version 2.0:
새로운 Column 추가Rollback:
Version 1.0 실행문제:
기존 Application이 새로운 Schema를 이해하지 못함해결:
Backward Compatible Migration 사용
순서:
Column 추가
↓
Application 업데이트
↓
기존 Column 제거Docker Compose Backup과 Rollback
Rollback 전 Backup은 필수입니다.
구조:
Backup 생성
↓
Deploy
↓
문제 발생
↓
RollbackDatabase:
mysqldump backup.sql복원:
mysql < backup.sqlDocker Compose Blue Green Rollback
Blue Green 방식에서는 Rollback이 간단합니다.
현재:
Green 운영문제 발생:
Traffic 이동복구:
Traffic
↓
BlueContainer 삭제 없이 빠르게 복구 가능합니다.
Docker Compose Canary Rollback
Canary 방식:
문제 발생:
Canary 10%복구:
Canary Traffic 제거결과:
기존 Version 100%Docker Compose Rollback Monitoring
자동 Rollback 판단 기준:
Error Rate:
오류 증가Response Time:
응답 지연Health:
unhealthyResource:
CPU / Memory 이상Docker Compose Production Rollback 전략
권장 구조:
Image Version 저장
↓
Deploy
↓
Health Check
↓
Monitoring
↓
문제 발생
↓
자동 Rollback필수 구성:
- Version Tag
- Backup
- Healthcheck
- Monitoring
- Rollback Script
Docker Compose Rollback Best Practice
운영 추천:
- latest Tag 사용 금지
- 이전 Image 보관
- Database Migration 테스트
- 자동 Health Check
- Rollback Script 준비
- CI/CD 실패 처리
배포 흐름:
Build
↓
Test
↓
Deploy
↓
Monitor
↓
Success
↓
완료
Failure
↓
Rollback자주 묻는 질문
Rollback하면 데이터도 자동 복구되나요?
아닙니다.
Database 변경은 별도 Backup과 Migration 전략이 필요합니다.
이전 Docker Image를 삭제하면 안 되나요?
Rollback을 위해 일정 기간 유지하는 것이 좋습니다.
자동 Rollback이 가능한가요?
가능합니다.
Healthcheck와 CI/CD Pipeline을 연결하면 구현할 수 있습니다.
Rollback과 Backup 차이는 무엇인가요?
Rollback은 Version 복구이고 Backup은 데이터 복구입니다.
마무리
Docker Compose Rollback 자동화는 Production 서버 안정성을 유지하기 위한 핵심 기능입니다.
최종 구조:
새 Version 배포
↓
Health Check
↓
Monitoring
↓
문제 감지
↓
Previous Version 복구안정적인 서버 운영에서는 새로운 기능을 빠르게 배포하는 것보다 문제가 발생했을 때 얼마나 빠르게 복구할 수 있는지가 중요합니다.
다음 글에서는 여러 Container를 운영하면서 성능과 트래픽을 처리하기 위한 Docker Compose Scaling 구성 방법을 알아보겠습니다.