바로 가기

Blue-GreenDeployment(블루 그린 배포)란?

URL 복사

Blue-Green 배포는 애플리케이션 또는 마이크로서비스의 이전 버전에 있던 사용자 트래픽을 이전 버전과 거의 동일한 새 버전으로 점진적으로 이전하는 애플리케이션 릴리스 모델입니다. 이때 두 버전 모두 프로덕션 환경에서 실행 상태를 유지합니다.

이전 버전을 blue 환경으로, 새 버전은 green 환경으로 부를 수 있습니다. 프로덕션 트래픽이 blue에서 green으로 완전히 이전되면 blue는 롤백에 대비하여 대기 상태로 두거나 프로덕션에서 가져온 후 업데이트하여 다음 업데이트의 템플릿으로 삼을 수 있습니다.

이와 같은 지속적 배포 모델에는 단점이 있습니다. 환경에 따라서는 업타임 요구 사항이 다르거나 blue-green과 같은 CI/CD 프로세스를 제대로 수행할 리소스가 없을 수도 있습니다. 그러나 애플리케이션을 지원하는 기업의 디지털 트랜스포메이션이 본격화되면서 많은 애플리케이션이 이러한 지속적 제공을 지원하도록 진화하고 있습니다.

 

Blue green deployment model

설명하자면 다음과 같습니다. 간단한 클라우드 네이티브 애플리케이션을 개발했습니다. 화면에서 날아다니는 다채로운 색상의 풍선을 탭하여 터뜨리면 점수를 얻는 모바일 게임입니다. 이 게임의 백엔드는 여러 컨테이너 기반의 마이크로서비스로 지원되며 게임 도전과제, 득점, 메커니즘, 통신, 플레이어 식별 등을 처리합니다.

최초 릴리스 이후 수백 명의 사용자가 게임을 플레이하기 시작합니다. 그에 따라 1분마다 수천 개의 트랜잭션 로그를 기록합니다. 일찍 자주 릴리스하라는 DevOps 팀의 조언에 따라 여러분은 빨간색 풍선의 크기와 속도를 증가시키기 위해 메커니즘 마이크로서비스의 마이너 업데이트를 출시하려 합니다.

플레이 중인 사용자 수가 가장 적은 자정이 될 때까지 기다렸다가 프로덕션 환경으로 업데이트를 푸시하는 방법 대신, blue-green 배포 모델을 사용하여 앱 사용량이 가장 많은 시점에 업데이트를 진행하려 합니다. 아울러 제로 다운타임을 목표로 합니다. 

이렇게 하려는 이유는 프로덕션 환경(blue)의 메커니즘 마이크로서비스를 똑같은 별도의 컨테이너(green)에 복사해 두었기 때문입니다. green 환경에서 빨간색 풍선의 크기와 속도를 높인 다음 활성 상태의 blue 환경과 함께 프로덕션 환경에 푸시하기에 앞서, Q/A 및 스테이징(대개 Jenkins와 같은 오픈소스 스트레스 테스트 프로젝트를 통해 자동화된)을 거쳤습니다.

운영 팀은 로드 밸런서를 사용하여 각 사용자의 다음 트랜잭션을 blue에서 green으로 리디렉션할 수 있습니다. 모든 프로덕션 트래픽이 green 환경을 거쳐 필터링되면 blue 환경이 오프라인 상태가 됩니다. blue는 재해 복구 옵션이 되어 대기하거나, 다음 업데이트를 위한 컨테이너가 될 수 있습니다.

쿠버네티스는 Blue-Green 배포 프로세스와 관련된 모든 요소, 이를테면 클라우드 네이티브 애플리케이션, 마이크로서비스, 컨테이너, 지속적인 통합, 지속적인 제공, 지속적인 배포, SRE, DevOps 등에 잘 맞습니다. Linux® 컨테이너 작업을 자동화하는 오픈소스 플랫폼인 쿠버네티스는 클라우드 네이티브 애플리케이션의 마이크로서비스를 패키지화하는 컨테이너의 오케스트레이션을 지원하며, 개발자가 애플리케이션 아키텍처를 처음부터 새로 구축할 필요 없이 재사용할 수 있는 아키텍처 패턴 컬렉션은 이러한 쿠버네티스를 지원합니다.

이러한 쿠버네티스 패턴 중 하나가 잘 알려진 선언적 배포(Declarative Deployment) 패턴입니다. 마이크로서비스는 원래 작기 때문에 그 수가 금세 몇 배로 늘어날 수 있습니다. 선언적 배포 패턴을 사용하면 쿠버네티스 아키텍처에서 가장 작고 간단한 단위인 포드(pod)를 배포할 때 수작업의 부담이 줄어듭니다.

선도적인 엔터프라이즈 쿠버네티스 플랫폼인 Red Hat® OpenShift가 CI/CD 기능을 핵심 요소로 삼으면서 더욱 강화되었기 때문입니다. 또한 Red Hat은 Red Hat OpenShift 환경 내에 blue-green 그린 배포를 롤아웃할 수 있도록 단계별 커맨드 라인 프롬프트 및 인수를 이미 문서화했습니다.

그리고 엔터프라이즈 쿠버네티스 플랫폼을 오픈소스로 유지하더라도 전체 플랫폼 및 이 플랫폼에 의존하는 모든 요소를 계속 제어할 수 있으므로, 애플리케이션 및 서비스는 그 위치 또는 기반에 상관없이 정상적으로 작동하게 됩니다.

이러한 이점을 지금 바로 얻어보십시오. Red Hat 기술의 기반이 되는 소스 코드를 검사, 수정 및 개선할 수 있습니다. Fortune 선정 500대 기업 중 90% 이상이 신뢰하는* Red Hat 제품 및 기술로 구현된 인프라에서는 무엇이든 가능합니다.

추가 자료

문서

DevSecOps란?

DevOps의 민첩성과 대응 능력을 최대한 활용하려면 IT 보안 팀이 애플리케이션의 전체 라이프사이클에서 주요 역할을 해야 합니다.

문서

CI/CD(지속적 통합/지속적 제공): 개념, 방법, 장점, 구현 과정

CI/CD는 애플리케이션의 통합 및 테스트 단계에서부터 제공 및 배포에 이르는 애플리케이션의 라이프사이클 전체에 걸쳐 지속적인 자동화와 지속적인 모니터링을 제공합니다.

문서

DevOps 엔지니어는 어떤 사람일까요?

DevOps 엔지니어는 조직 내 협업, 혁신, 문화적인 변화를 지원하는 기술 및 전문성을 두루 갖추고 있습니다.  

DevOps에 대한 자세한 내용

제품

Red Hat 전문가가 참여하는 집중적인 전문 레지던스 환경에서 애자일 방법론과 오픈소스 툴로 기업의 비즈니스 문제를 해결하는 방법을 학습합니다.

다양한 시각으로 고객의 상황을 파악하고 이를 바탕으로 고객의 과제를 분석하여 종합적이고 비용 효율적인 솔루션을 통해 문제를 해결하도록 돕는 전략적인 조언자입니다.

리소스

체크리스트

DevOps 방법론을 활용한 엔터프라이즈 자동화

백서

Red Hat Ansible Automation Platform으로 CI/CD 파이프라인 간소화

자세히 알아보기