Blue/Green 배포

Blue/Green 배포 전략 -> 무중단 배포의 대표적인 방식

-서비스 운영 중, 새로운 버전을 배포하면서도 중단 없이 전환할 수 있는 방법으로 많이 활용되는 전략이 바로 Blue/Green Deployment입니다.
이 글에서는 Blue/Green 배포의 개념, 동작 방식, 장단점, 그리고 실무에서 고려해야 할 사항을 정리했습니다.

 

Blue/Green 배포란?

-Blue/Green 배포는 두 개의 동일한 환경(Blue, Green)을 번갈아 가며 운영하여 무중단 배포와 빠른 롤백을 가능하게 하는 전략입니다.

• Blue 환경 : 현재 운영 중인 서비스 환경 (Production)
• Green 환경 : 새로운 버전을 배포하여 검증하는 환경

동작 방식

1. Blue 환경 운영 중
   • 현재 서비스는 Blue 환경에서 정상적으로 사용자 트래픽을 처리하고 있음.
2. Green 환경 구성 및 배포
   • Blue와 동일한 사양으로 Green 환경을 구성하고, 새로운 버전의 애플리케이션(소스 코드, 인프라 업데이트 등)을 배포.
3. Green 환경 검증
   • 헬스체크 및 QA 테스트 진행
   • 실제 운영과 동일한 조건에서 서비스 이상 여부 확인
4. 트래픽 전환
   • Green 환경이 정상이라고 판단되면, 로드밸런서(ALB, NLB) 또는 Route 53 DNS 라우팅을 통해 트래픽을 Blue → Green으로 전환.
5. 롤백 가능성 확보
   • 만약 Green 환경에서 장애 발생 시, 트래픽을 다시 Blue 환경으로 되돌려 즉시 롤백 가능

 

장점

• 무중단 배포: 배포 과정에서 서비스 중단이 없음
• 빠른 롤백: 장애 발생 시 트래픽만 Blue로 돌리면 즉시 복구 가능
• 안정성 확보: 운영 환경과 격리된 Green 환경에서 충분히 사전 검증 가능

단점

• 비용 부담: 두 개의 동일한 환경(Blue/Green)을 동시에 유지해야 하므로 인프라 비용 증가
• 공유 리소스 문제: DB, 메시지 큐 등 상태 공유 자원에 대한 마이그레이션 전략
• 운영 복잡성: 인프라 자동화가 미흡할 경우 관리 및 운영 부담 발생

추가 고려 사항

Blue/Green 배포를 실무에서 적용할 때는 아래와 같은 점을 추가로 고려해야 합니다:

1. DB 마이그레이션 전략
   • DB는 상태가 공유되므로, 스키마 변경이나 데이터 마이그레이션은 신중해야 함
   • 경우에 따라 Rolling Update + DB Migration Tool (Flyway, Liquibase 등) 병행 필요
2. 자동화 도입
   • CI/CD 도구(GitLab CI/CD, GitHub Actions, AWS CodePipeline 등)와 IaC(Terraform, Helm, ArgoCD 등)를 활용해 환경 전환 자동화 필수
3. 트래픽 분할 전환 (Canary와 혼합)
   • 일부 트래픽만 Green으로 먼저 유입 후, 점진적으로 100% 전환 → 리스크 최소화 가능
4. 모니터링/알림 시스템 연계
   • 전환 직후에는 APM(Datadog, NewRelic, X-Ray 등), 로그 수집(CloudWatch, ELK), 알림(OpsGenie, Slack) 연동 필수