[Deployment] 1. Blue-Green 배포 방식

1. 전통적인 배포 방식의 한계

• 과거 온프레미스 환경에는 서버 자원이 제한적이었음
• 새로운 버전을 배포할 때 기존 운영 서버에 코드를 덮어쓰는 방식이였음
• ✅ 현재 유저가 사용중인 서버에 직접 새 코드를 반영하는 구조
• ⚠️ 장애 범위가 큼: 배포하다 터지면 직접 롤백해야 했음
• ⚠️ 롤백 느림: 문제가 생기면 이전 버전으로 직접 돌려야 하므로 오래걸림
• ⚠️ 디버깅이 어려움: 버그가 나면 서비스를 살리기 바빠 디버깅을 할 수가 없음
• ⚠️ 무중단 배포가 어려움: 서버를 재시작하거나 교체하는 과정에서 일시적인 중단이 발생함

 

2. 블루/그린 배포 방법론

• 현재 운영 중인 환경과 동일한 새로운 환경을 하나 더 만들어놓고, 새 버전을 그곳에 배포한 뒤 검증이 끝나면 트래픽만 전환하는 전략
• 클라우드 기술이 발전하면서, 똑같은 서버 환경을 몇 초 만에 뚝딱 하나 더 만들 수 있게 되었음
• ✅ 블루 환경: 현재 실제 유저들이 접속해서 사용하고 있는 기존 운영 서버
• ✅ 그린 환경: 새 버전이 배포되어 대기 중인 신규 호나경 신버전 서버
• ➡️ 그린 환경이 테스트가 끝나 완벽하게 준비되면, 라우터가 스위치를 돌려 유저들을 그린 환경으로 이동시킴

 

장점

구분	핵심 내용	기대 효과
배포 위험 감소 및 격리	새 버전을 기존 운영 환경과 분리된 Green 환경에 배포함	신버전에 치명적인 버그가 있어도 현재 운영 중인 Blue 환경에는 직접 영향이 없음
빠른 롤백	문제가 발생하면 라우터, 게이트웨이, 로드밸런서의 트래픽 방향만 다시 Blue로 전환함	서비스 중단 시간을 최소화할 수 있음
운영 환경 검증 가능	실제 운영 환경과 거의 동일한 Green 환경에서 새 버전을 검증함	로컬이나 테스트 서버에서 발견하지 못한 문제를 배포 전 확인할 수 있음
카나리 분석 가능	전체 트래픽이 아니라 일부 트래픽만 Green으로 먼저 보낼 수 있음	실제 사용자 기준으로 신버전 안정성을 점진적으로 검증 가능
CI/CD 파이프라인 단순화	기존 서버 상태에 의존하지 않고 새 환경에 배포함	배포 스크립트가 단순해지고 환경 오염 문제를 줄일 수 있음
재해 복구 구조와 유사	Blue와 Green을 전환하는 구조는 Hot-Standby 구조와 비슷함	배포 과정 자체가 장애 대응 구조를 반복적으로 검증하는 효과를 가짐
클라우드 비용 조절 가능	배포 시점에만 Green 환경을 띄우고 안정화 후 기존 Blue를 제거할 수 있음	두 환경을 항상 유지하지 않아도 되므로 비용 부담을 줄일 수 있음

 

3. 고려 사항

DB 스키마 호환성 관리 (Expand and Contract)

• 구버전과 신버전 서버가 배포 과정에서 동시에 같은 DB를 바라보는 순간이 존재합니다.
• 이때 신버전의 기준으로 DB 구조를 바꿔버리면, 아직 살아 있는 구버전 서버에서 에러를 일으킬 수 있음
• ➡️ DB 스키마 변경 배포와 애플리케이션 소스코드 배포를 철저히 분리하여 3단계로 진행합니다.
• Expand: 기존 컬럼은 그대로 둔 채, 새 버전에 필요한 컬럼을 추가합니다.
• Transition: 애플리케이션을 신버전으로 전환하고, 필요한 데이터 마이그레이션을 수행함
• Contract: 구버전 코드가 완전히 제거되면, 옛날 컬럼과 설정을 DB에서 최종 삭제합니다.

 

세션 분리 (공유 세션 구조)

• 로그인 정보나 장바구니 같은 유저 세션 데이터가 각 서버 내부 메모리에만 저장되어 있는 경우
• 블루에서 그린으로 전환하는 순간 유저들의 로그인이 대거 풀리거나 진행 중이던 데이터가 유실될 수 있음
• ➡️ 개별 서버 장비의 상태와 상관없이 세션이 유지되도록 외부 독립 메모리 저장소를 구축합니다.
• 별도의 고속 인메모리 데이터베이스인 Redis(레디스) 등을 활용하여 세션 데이터를 중앙 집중형으로 관리합니다.

 

출처

• Martin fowler - Blue Green Deployment
• AWS - Blue/Green Deployment