🌳 고급 고급
Blue-Green 배포의 장단점은?
쉽게 이해하기
Blue-Green 배포는 무대 전환처럼 동작해요. 공연 중에 다음 무대를 뒤에서 미리 세팅해두고, 준비가 완료되면 조명을 확 바꿔서 관객이 새 무대를 보게 하는 거예요. 문제가 생기면 즉시 이전 무대로 조명을 되돌릴 수 있어서 안전하죠.
핵심 정리
무중단 배포의 대표 전략이지만 비용과 복잡도가 올라가요.
자세히 알아보기
Blue-Green 배포는 두 개의 동일한 프로덕션 환경을 유지하면서 배포하는 전략이에요. Blue(현재 버전)가 서비스 중일 때 Green(새 버전)을 배포하고 테스트한 뒤, 로드밸런서를 전환해서 트래픽을 Green으로 보내는 방식이죠.
장점은 명확해요. 첫째, 무중단 배포가 가능해요. 사용자는 서비스 중단을 전혀 느끼지 못해요. 둘째, 즉시 롤백할 수 있어요. Green에서 문제가 발생하면 로드밸런서를 다시 Blue로 전환하기만 하면 되니까 몇 초 안에 이전 버전으로 되돌릴 수 있어요. 셋째, 프로덕션 환경에서 실제 테스트가 가능해요. Green 환경에 일부 트래픽만 보내서(Canary 방식과 결합) 검증한 뒤 전환할 수 있죠.
단점도 있어요. 가장 큰 문제는 비용이에요. 항상 두 배의 인프라를 유지해야 하니까 서버, 데이터베이스, 스토리지 비용이 두 배로 들어요. 작은 스타트업에는 부담스러울 수 있어요. 둘째, 데이터베이스 마이그레이션이 복잡해져요. Blue와 Green이 같은 DB를 쓰면 스키마 변경 시 호환성 문제가 생기고, 별도 DB를 쓰면 동기화 문제가 생겨요. 보통 '하위 호환 마이그레이션'을 먼저 하고 배포하는 전략을 써요.
실무에서는 Kubernetes의 Service를 Blue/Green 전환에 활용하거나, AWS의 Elastic Beanstalk 'Swap Environment URLs' 기능을 사용해요. 소규모 프로젝트라면 Rolling Update나 Canary 배포가 더 적합할 수 있어요.