네이티브 통합

하나의 환경은 “블루”로 표시되며 실제 사용자에게 서비스를 제공하고, 다른 하나인 “그린” 환경은 새로운 버전의 배포 및 테스트에 사용됩니다. 새로운 버전이 승인되면 트래픽은 즉시 블루 환경에서 그린 환경으로 전환됩니다.

이 전략은 Jez Humble과 David Farley가 2010년에 출간한 대표 저서 Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation을 통해 널리 알려지고 명명되었습니다.

블루-그린 배포는 다운타임을 제거하고 이전 버전으로 즉시 롤백할 수 있는 지속적 배포 기법입니다. 이 방식은 A/B 테스트를 쉽게 수행할 수 있도록 하고, 준비되지 않은 버전을 최종 사용자가 접할 위험 없이 안전한 개발 환경을 제공합니다.

“블루-그린”이라는 표현이 가장 일반적이지만, 다양한 변형이 존재합니다. Netflix는 “레드/블랙”이라는 용어를 사용하지만 개념은 동일합니다. 경우에 따라 개발자는 두 개 이상의 환경을 운영하기를 원할 수 있습니다. 색상 기반 명명 방식은 두 환경을 구분하는 데 효과적입니다. 하지만 환경이 두 개 이상인 경우에는 버전 번호, 빌드 ID 또는 사용자 지정 이름과 같은 명명 규칙을 사용할 수도 있습니다.

개념은 단순하지만, 전략의 이점을 활용하는 안정적이고 안전한 블루-그린 배포를 구현하려면 여러 단계와 각 단계의 다양한 요소를 고려해야 합니다.

블루-그린 배포를 위한 동일한 환경 생성은 수동으로 수행하거나 자동화된 툴을 사용해 구현할 수 있습니다. Infrastructure as Code(IaC)는 프로비저닝을 자동화하는 방법 중 하나입니다. IaC는 사전에 정의된 사양에 따라 IT 인프라를 자동으로 프로비저닝하고 구성할 수 있도록, 일종의 지침이나 레시피와 같은 기계 판독 가능 구성 파일을 사용합니다.

IaC를 사용하면 이미 운영 중인 블루 환경을 복제하여 그린 환경으로 자동으로 생성할 수 있습니다. 개발자는 신뢰할 수 있는 기준에서 시작한다는 점을 바탕으로 필요에 따라 이러한 템플릿을 수정할 수 있습니다. IaC를 사용하면 반복 가능하고 정확한 복제가 보장됩니다.

애플리케이션 코드, 종속성 및 API를 하나의 “컨테이너 이미지”로 묶는 컨테이너화도 또 다른 접근 방식입니다. 컨테이너를 사용하면 전체 환경이 동일하게 유지됩니다. 오픈소스 컨테이너 오케스트레이션 플랫폼인 Kubernetes는 블루-그린 배포에서 컨테이너화를 위해 널리 사용됩니다.

환경이 생성되면 애플리케이션이 블루(라이브) 환경에 배포됩니다.

로드 밸런서는 클라우드 제공자나 Kubernetes 환경에서 애플리케이션 앞단에 위치하는 경우가 많으며, 운영 트래픽을 원하는 방향으로 분산시키는 메커니즘입니다. 이 시나리오에서는 로드 밸런서가 트래픽을 라이브 상태인 블루 환경으로 전달합니다.

이후 애플리케이션 업데이트가 포함된 새로운 코드가 그린 운영 환경에 배포됩니다. 로드 밸런서가 블루 운영 환경으로 트래픽을 전달하고 있기 때문에, 그린 환경은 실험, 테스트 및 구성을 수행하기에 안전한 공간이 됩니다. 

그린 환경에 대한 배포가 완료되면 필요한 모든 검증 단계를 수행합니다. 이 단계에는 보안 검사, 성능 점검, 버그 검사 등이 포함될 수 있습니다.

그린 환경이 모든 관련 이해관계자의 검증과 승인을 받으면, 로드 밸런서를 업데이트하여 트래픽을 이전 버전인 블루에서 새로운 버전인 그린으로 전환합니다.

이 전환은 즉시 이루어지며, 사용자는 오류를 보거나 블루 또는 그린 환경 이외의 상태를 경험하지 않습니다.

DNS 업데이트를 통해 사용자 트래픽을 원하는 환경으로 유도할 수 있지만, 캐시가 IP 주소를 갱신하는 과정에서 지연이 발생할 수 있습니다. 이러한 이유로 즉시 적용이 가능한 로드 밸런서가 선호됩니다.

검증 단계에서 대부분의 잠재적 버그나 성능 문제를 발견했더라도, 새롭게 운영 상태가 된 그린 환경을 지속적으로 모니터링하는 것이 중요합니다. 이 과정에서는 분석 소프트웨어와 서비스가 도움이 됩니다. 활동 데이터를 비교하면 이상 징후를 파악할 수 있습니다.

문제가 발생할 경우, 개발자가 문제를 해결하는 동안 사용자 트래픽을 다시 블루 환경으로 전환할 수 있습니다.

사용되지 않는 블루 환경을 폐기하는 것은 선택 사항이며, 일부 조직은 향후 롤백이 필요할 경우를 대비해 블루 환경을 계속 유지하기도 합니다. 하지만 수명 주기 중 특정 시점에 블루 환경을 폐기하는 것이 비용 측면에서 유리할 수도 있습니다. 또는 블루 환경을 다음 실험용 환경, 즉 그린 환경으로 전환할 수도 있습니다.

지속적 통합/지속적 전달 파이프라인은 “소프트웨어 전달 프로세스를 간소화하는 자동화된 DevOps 워크플로”입니다. 이 파이프라인은 애플리케이션 코드 변경 사항을 지속적으로 전달할 수 있도록 지원합니다.

이 방식은 블루-그린 배포와 밀접하게 연계되어 있습니다. CI/CD는 블루-그린 배포를 가능하게 하며, 블루-그린 배포는 무중단 및 위험 최소화를 위한 소프트웨어 업데이트 배포를 지원하기 위해 CI/CD 파이프라인에 통합되는 경우가 많습니다.

CI 파이프라인은 새로운 코드가 중앙 저장소에 통합되기 전에 자동으로 테스트 및 통합하여, 결함이 있는 코드가 배포되는 위험을 줄입니다. CD 파이프라인은 블루-그린 배포 전략을 활용해 사용자에게 영향을 주지 않으면서 빠른 릴리스를 최적화합니다. 블루-그린 배포는 거의 지속적인 가용성과 안전한 롤백을 제공하며, 이는 빈번하고 신뢰할 수 있는 코드 릴리스를 목표로 하는 CI/CD의 핵심 목표 달성에 중요한 역할을 합니다.

광산의 카나리아라는 관용구에서 유래한 카나리 배포는 새로운 소프트웨어 버전을 배포할 때 위험을 줄이는 또 다른 방법입니다.

블루/그린 배포는 두 개의 별도 환경을 생성해 각각이 전체 트래픽 또는 전혀 트래픽을 처리하는 방식인 반면, 카나리 배포는 다른 접근 방식을 취합니다. 카나리 릴리스는 하나의 환경에서 여러 버전을 동시에 운영합니다.

카나리 배포에서는 새로운 버전을 먼저 일부 사용자에게만 배포합니다. 이후 개발자는 오류 증가, 성능 저하 또는 기타 문제가 발생하는지 확인할 수 있습니다. 이 소수의 사용자가 “광산의 카나리아” 역할을 합니다. 문제가 없으면 오류를 지속적으로 확인하면서 새로운 버전으로의 트래픽을 점진적으로 늘립니다.

카나리 배포의 가장 큰 장점은 인프라 비용 측면입니다. 카나리 배포는 하나의 환경만 사용하지만 블루/그린 배포는 두 개의 환경을 사용하기 때문입니다. 하지만 블루/그린 배포의 단순한 로드 밸런싱 기반 전환과 비교하면, 카나리 배포는 롤백이 필요한 경우 더 복잡하고 위험할 수 있습니다.

카나리 배포 방식은 잠재적인 오류보다 새로운 릴리스를 가능한 한 빠르게 사용자에게 제공하는 것이 더 중요하거나, 실제 사용자 경험을 통해 영향을 모니터링하려는 경우에 유용합니다.

또한 하이브리드 접근 방식도 존재합니다. 로드 밸런서는 예를 들어 사용자 트래픽의 1%를 그린 환경으로 보내고, 나머지 99%는 블루 환경으로 유지할 수 있습니다. 이는 두 전략을 결합한 방식으로, 카나리 배포의 인사이트를 제공하면서도 빠르고 쉽게 롤백할 수 있는 기능을 제공합니다.

블루-그린 배포는 전체 전환 방식이든 카나리 형태의 롤아웃이든 다양한 장점을 제공합니다.

로드 밸런서가 트래픽을 원하는 환경으로 즉시 전환하기 때문에 최종 사용자는 다운타임을 전혀 경험하지 않습니다. 이는 다운타임이 심각한 비즈니스 문제로 이어질 수 있는 고트래픽 환경에서 큰 장점입니다.

두 개의 별도 환경 중 하나가 안전하고 정상적으로 운영되고 있다는 점은 문제가 발생했을 때 개발자가 즉시 변경 사항을 되돌릴 수 있게 합니다. 그린 환경에서 문제가 발생하면 트래픽을 블루 환경으로 간단히 다시 전환할 수 있습니다.

두 개의 별도 환경은 서로 다른 버전에 대한 지표 분석, 분석 정보 확인 및 A/B 테스트를 간소화합니다. 분석 및 모니터링 데이터는 블루 또는 그린 환경 중 하나에 명확하게 연결되어, 비교 및 상태 점검을 쉽게 수행할 수 있습니다. 이는 두 버전이 동시에 활성화되어 구분이 어려운 카나리 배포와 대비됩니다.

그린 실험 환경은 최종 사용자에게 노출되지 않은 상태에서 새로운 버전을 철저히 테스트할 수 있게 합니다. 새로운 버전은 의도대로 작동할 것이라는 높은 확신을 가지고 배포됩니다. 그렇지 않은 경우에도 트래픽을 즉시 안정적인 블루 환경으로 되돌릴 수 있습니다.

블루-그린 배포는 많은 장점을 제공하지만, 개발 팀이 고려해야 할 잠재적인 단점과 적합하지 않은 사용 사례도 존재합니다.

두 개의 완전히 프로비저닝된 환경을 동시에 운영하기 때문에 호스팅 및 인프라 비용이 증가할 수 있습니다. 이 비용이 반드시 단일 환경 대비 정확히 두 배가 되는 것은 아닙니다. 경우에 따라 그린 환경은 더 작은 규모로 운영되거나, 블루 환경이 빠르게 폐기되거나, 두 환경 간 일부 리소스를 공유할 수도 있습니다. 그러나 일정 수준의 비용 증가는 발생할 가능성이 높습니다.

블루-그린 배포에만 국한된 문제는 아니지만, 기존 환경과 새로운 환경 간 데이터베이스 동기화를 유지하는 것은 어려울 수 있습니다. 예를 들어 스키마 변경이 빈번하거나 복잡한 블루-그린 시스템에서는 호환성을 유지하기가 까다로울 수 있습니다.

라이브 환경이 중단되지 않도록 하려면 스키마 변경은 이전 버전과 호환되어야 하며, 즉 새로운 시스템이 기존 시스템과 함께 작동할 수 있어야 합니다. 그렇지 않은 경우 각 환경에 별도의 데이터베이스가 필요하며, 이들은 실시간으로 동기화되어야 할 수 있습니다. 이러한 양방향 동기화는 데이터 불일치나 성능 저하와 같은 자체적인 위험을 동반합니다.

이 문제를 해결하기 위해 GitHub Actions와 같은 CI/CD 툴은 스키마 업데이트를 자동으로 관리하는 데이터베이스 배포 프로세스를 제공합니다. 경우에 따라 스키마 변경이 지나치게 복잡하면 블루-그린 배포의 장점이 사라질 수 있습니다.

요청 간 지속 데이터를 유지하는 상태 저장 애플리케이션에서는 블루-그린 배포가 문제를 일으킬 수 있습니다. 상태 저장 애플리케이션의 예로는 여러 방문에 걸쳐 내용이 유지되는 장바구니나 메시지 로그가 있습니다. 환경 간 데이터베이스가 공유되지 않거나 호환되지 않으면 이러한 데이터가 손실될 수 있습니다.

마이크로서비스 애플리케이션은 개별적으로 배포 가능한 다양한 구성 요소로 이루어진 매우 복잡한 시스템인 경우가 많습니다. 마이크로서비스 개발자는 하루에도 수십 번 배포를 수행할 수 있기 때문에, 점진적으로 배포하는 카나리 방식이 더 안전한 선택으로 여겨집니다.