Blue-Green 배포 및 DevOps에서의 역할 설명
소프트웨어 개발의 전통적인 '빅뱅' 방식은 현재 클라우드 및 데브옵스 소프트웨어 플랫폼의 높은 유연성, 민첩성 및 지속적 배포 요구사항을 충족하기 어렵습니다.
제품 릴리스 배포 시 실행할 수동 단계 체크리스트를 만드는 것만으로는 충분하지 않습니다. 그런 방식으로는 진정한 애자일이나 데브옵스라고 할 수 없습니다.
블루-그린 배포: 핵심 설명
블루-그린 배포는 소프트웨어 배포 전략의 일종으로, 동일한 두 개의 환경(활성 환경과 비활성 환경)을 구축하여 다운타임을 줄이고 새로운 소프트웨어 버전으로 인한 위험을 최소화하는 방식입니다.
활성 환경은 현재 소프트웨어 버전이 실행되고 사용자들이 실질적인 트래픽을 발생시키는 곳입니다. 비활성 환경은 새로운 소프트웨어 버전을 배포하고 테스트하는 데 사용됩니다.
새로운 버전이 테스트를 거쳐 준비되면 트래픽은 활성 환경에서 비활성 환경으로 전환되어, 비활성 환경이 새로운 활성 환경이 됩니다. 이 과정은 필요에 따라 반복할 수 있습니다.
데브옵스 환경에서의 의미
블루-그린 배포는 데브옵스 철학과 프로세스에 적합합니다. 사용자에게 최소한의 다운타임만을 허용하며, 릴리스 실패의 위험을 제거하고 소프트웨어의 지속적인 제공과 배포를 가능하게 합니다.
두 개의 동일한 환경이 있으면 기존의 운영 환경에 영향을 주지 않고 새로운 소프트웨어 버전을 테스트하고 배포할 수 있습니다. 이는 데브옵스의 핵심인 빠르고 잦은 릴리스를 가능하게 합니다.
또한, 환경 간의 빠른 트래픽 전환 기능은 데브옵스 환경에서 발생할 수 있는 문제에 대한 빠른 롤백을 가능하게 하는 핵심 요소입니다.
블루-그린 배포의 주요 원칙
#1. 두 개의 동일한 환경
블루-그린 배포를 위해서는 두 개의 동일한 환경을 준비해야 합니다. 데이터와 프로세스 측면에서 동일해야 합니다. 하나는 활성(파란색) 상태이고 다른 하나는 비활성(녹색) 상태입니다.
파란색 환경은 실제 사용자들이 일상적인 작업을 수행하는 곳입니다. 녹색 환경은 항상 파란색 환경과 동기화되지만, 테스터들이 테스트 케이스를 실행하는 곳입니다. 이 환경은 실제 운영 환경과 유사하므로 실제 조건에서 테스트를 실행할 수 있습니다.
#2. 트래픽 전환
새로운 소프트웨어 버전이 테스트를 마치고 준비되면 트래픽은 활성 환경에서 비활성 환경으로 전환되며, 이로써 비활성 환경이 새로운 활성 환경이 됩니다.
전환은 즉각적으로 이루어집니다. 배포는 이제 과거의 개념입니다. 다운타임이 발생하지 않습니다. 사용자들은 새로운 환경에 접속하기 위해 별도의 조치를 취할 필요가 없습니다. 모든 사용자가 동시에 자동으로 새로운 환경으로 리디렉션됩니다.
출처: aws.amazon.com
#3. 신속한 롤백
환경 간 빠른 트래픽 전환 기능은 문제 발생 시 신속한 롤백을 가능하게 합니다. 이를 통해 다운타임을 최소화하고 애플리케이션의 가용성을 높게 유지할 수 있습니다.
녹색 환경에 문제가 발생하면 모든 사용자는 기존의 안정적인 파란색 환경으로 즉시 전환됩니다.
#4. 자동화된 테스트
자동화된 테스트는 블루-그린 배포에서 매우 중요한 부분입니다. 새로운 소프트웨어 버전이 활성 환경에 배포되기 전에 철저하게 테스트되도록 보장합니다.
시스템에 자동화된 테스트(최소한 단위 테스트, 기능 테스트, 회귀 테스트)가 상당 부분 구축되어 있지 않다면, 블루-그린 배포를 구현하는 것은 큰 의미가 없습니다.
자동화된 테스트가 없다면 속도가 크게 느려집니다. 새로운(녹색) 환경을 테스트하는 데 너무 많은 시간이 소요되어, 녹색 환경으로 전환할 때쯤이면 소프트웨어 개발 주기에서 이미 '구식'이 되어버릴 수 있습니다.
#5. 지속적 배포
블루-그린 배포는 지속적 배포 파이프라인의 일부이며, 이는 궁극적으로 소프트웨어를 프로덕션에 더 빠르고 자주 릴리스하는 것을 의미합니다.
녹색 환경에서 새로운 소프트웨어 버전의 테스트가 완료되면 즉시 전환할 수 있습니다. 배포는 이미 완료되었고, 트래픽 전환만 남았기 때문에 매일 수행할 수 있을 정도로 빠릅니다. 물론 테스트 활동도 빨라야 합니다.
일반적인 수명 주기
블루-그린 배포를 실행하는 플랫폼은 고유한 단계와 프로세스로 구성된 수명 주기를 따릅니다. 일반적으로 다음과 같이 구성됩니다.
CI/CD 파이프라인 구현
데브옵스 CI/CD 파이프라인에 블루-그린 배포를 적용하는 것은 자연스러운 과정입니다.
필수 전제 조건은 이미 두 개의 동일한 환경이 있어야 한다는 것입니다. 자동화된 프로세스이므로, 코드 도구(예: AWS CloudFormation 또는 클라우드에 구애받지 않는 Terraform)를 사용하여 자동화된 파이프라인 내에서 환경을 만들거나 재구축 또는 업데이트하는 스크립트를 작성해야 합니다.
이러한 준비가 완료되면 완전히 자동화된 배포 프로세스를 생성하는 것은 비교적 쉬운 단계입니다. 기존 파이프라인을 재사용하여 파란색 및 녹색 환경을 생성하기만 하면 됩니다. 다만, 이번에는 테스트 프로세스를 파이프라인에 포함시켜야 합니다.
트래픽 전환 프로세스는 AWS Elastic Load Balancer 또는 NGINX와 같은 도구를 사용하여 자동화할 수 있습니다. 새로운 버전의 소프트웨어가 테스트를 마치고 준비되면 로드 밸런서나 DNS 설정을 업데이트하여 트래픽을 녹색 환경으로 전송합니다.
다음 단계는 모니터링입니다. 이를 위해 AWS CloudWatch, New Relic 또는 Datadog와 같은 도구를 활용할 수 있습니다.
마지막으로, 기존의 파란색 환경을 폐기할 때도 기존의 파이프라인을 재사용합니다. 서비스를 처음부터 다시 만들지, 아니면 체인에 있는 모든 서비스 스크립트를 업데이트할지는 사용자에 따라 결정됩니다. 일반적으로 폐기 후 재구축이 더 안전한 선택입니다. 업데이트를 할 경우 고려해야 할 더 많은 코너 케이스가 있기 때문입니다.
블루-그린 배포의 모범 사례
블루-그린 배포를 최대한 활용하는 방법을 알고 싶으신가요? 실전에서 얻은 몇 가지 팁을 소개합니다.
확실한 데이터베이스 마이그레이션 전략 마련
새로운 소프트웨어 버전을 배포할 때 데이터베이스 스키마가 올바르게 업데이트되었는지 확인하는 것이 중요합니다. Flyway 또는 Liquibase와 같은 데이터베이스 마이그레이션 전략을 사용하여 데이터베이스 스키마 변경을 관리하십시오.
카나리아 분석 도구 활용
카나리아 배포가 또 다른 접근 방식이기는 하지만, 블루-그린 배포를 보완하는 데 일부 기술을 사용할 수 있습니다.
Kayenta 또는 Spinnaker와 같은 카나리아 분석 도구를 사용하여 실제 환경에서 새로운 버전의 소프트웨어 성능을 분석하십시오. 새 버전과 이전 버전의 소프트웨어 성능을 비교하는 것이 포함됩니다.
Togglz와 같은 기능 토글 프레임워크를 사용하여 새로운 버전의 소프트웨어에서 기능을 활성화하거나 비활성화합니다. 새로운 기능을 점진적으로 출시하고 필요한 경우 빠른 롤백을 가능하게 합니다.
상태 확인 기능이 있는 로드 밸런서 사용
AWS Elastic Load Balancer 또는 NGINX와 같이 상태 확인 기능이 있는 로드 밸런서를 사용하여 트래픽이 정상적인 인스턴스로만 전송되도록 보장합니다. 이를 통해 애플리케이션의 가용성을 높게 유지하고 다운타임을 최소화할 수 있습니다.
자동화된 롤백 기능이 포함된 롤백 계획 활용
문제 발생 시 롤백 계획을 수립하고 AWS CodeDeploy 또는 Octopus Deploy와 같은 도구를 사용하여 롤백 프로세스를 자동화합니다. 이를 통해 다운타임을 최소화하고 애플리케이션의 가용성을 높게 유지할 수 있습니다.
이러한 롤백 계획은 새로운 버전에서 중요한 문제가 발견될 때 주로 녹색 환경에 적용됩니다.
파란색 환경에 대한 롤백 계획은 필요하지 않습니다. 파란색 환경은 스위치에 영향을 받지 않으며 필요할 때마다 즉시 이 안정적인 환경으로 되돌아갈 수 있기 때문입니다.
블루-그린 배포의 과제
블루-그린 배포를 구현하는 데에는 몇 가지 어려움이 있을 수 있습니다. 흔히 발생하는 문제점은 다음과 같습니다.
블루-그린 배포와 카나리아 배포의 차이점
기존 배포 방식과의 차이점은 매우 명확합니다(기존 방식에는 서로 다른 소프트웨어 버전으로 실행되는 두 개의 병렬 환경이 없음). 하지만 카나리아 배포와의 차이점이 좀 더 흥미로울 수 있습니다.
블루-그린 배포는 두 개의 환경(파란색 및 녹색)을 사용합니다. 하지만 이 두 환경은 데이터 측면에서 지속적으로 동기화됩니다. 새로운 버전이 테스트를 거쳐 준비되면, 트래픽은 활성 환경에서 비활성 환경으로 전환되며, 이를 통해 비활성 환경이 새로운 활성 환경이 됩니다. 새 코드를 배포하는 데 시간이 걸리지 않으며, 프로덕션 중단 시간도 없습니다. 모든 프로덕션 사용자는 항상 현재 활성 환경에서 작업하며, 전환을 인지하지 못합니다.
카나리아 배포는 대부분의 사용자와 서버가 기존 버전을 계속 사용하는 동안 소규모 사용자 하위 집합에 새로운 버전의 소프트웨어를 배포하는 방식입니다. 이것은 점진적인 배포이며, 전체를 한 번에 전환하지 않습니다. 이 경우 테스터는 정의된 하위 집합이긴 하지만 실제 프로덕션 사용자입니다. 이 그룹은 프로덕션 프로세스를 통해 새 버전을 적극적으로 테스트하고 있으며, 최종적으로 안정성이 확보되면 새로운 버전이 나머지 사용자에게 확산됩니다.
어떤 방식이 더 좋을까요?
컨설턴트들이 흔히 말하는 "상황에 따라 다르다"는 답변이 여기에 가장 적합합니다.
시스템의 우선순위가 고가용성이라면 블루-그린 배포를 선택해야 합니다.
새 시스템 버전의 빠른 피드백과 제어된(느리더라도) 롤아웃이 더 중요하다면 카나리아 배포가 블루-그린 배포보다 유리합니다.
중요한 것은 두 가지 모두 진정한 데브옵스 시스템을 만드는 데 충분할 만큼 민첩하다는 것입니다.
사례 연구
넷플릭스는 블루-그린 배포를 사용하여 스트리밍 서비스의 새로운 버전을 배포합니다. 블루-그린 배포를 통해 넷플릭스는 사용자 경험에 영향을 주지 않고 새로운 버전의 서비스를 배포할 수 있습니다. 실제로 넷플릭스는 다른 상황에서는 카나리아 배포를 병행하여 사용하고 있습니다. 이는 데브옵스 배포를 위해 다양한 접근 방식을 결합하는 것이 비현실적인 일이 아니라는 것을 보여줍니다.
또한 아마존과 Etsy도 블루-그린 배포를 사용하여 전자상거래 플랫폼의 새로운 버전을 배포합니다.
또 다른 사례는 링크드인이 블루-그린 배포를 사용하여 소셜 네트워킹 플랫폼의 새로운 버전을 배포하는 경우입니다.
마지막으로 IBM은 블루-그린 배포를 사용하여 클라우드 플랫폼의 새로운 버전을 배포합니다.
이러한 기업들은 플랫폼 인프라에 블루-그린 배포를 성공적으로 구현했고, 다른 기업들에게 좋은 본보기가 되었습니다.
마지막으로
카나리아 배포와 마찬가지로 블루-그린 배포는 기존의 애자일 프로세스와 방법론을 최대한 활용하여 아무도 눈치채지 못하는 방식으로 새로운 소프트웨어를 원활하게 제공하기 위해 노력합니다. 이것이 이러한 접근 방식의 궁극적인 목표입니다. 지속적으로 자주 배포하지만 아무도 모르고 아무도 눈치채지 못하며, 결국 아무도 신경쓰지 않습니다.
최신 릴리스에 대한 회사 내 가십이 없는 것은 개발팀에게 약간 실망스러울 수 있습니다. 하지만 제 생각에는 이것이 여러분이 제공할 수 있는 최고의 서비스입니다. 아무도 그에 대해 이야기하지 않지만, 모두가 매일 사용합니다.
다음은 자주 묻는 데브옵스 인터뷰 질문과 답변입니다.