블루-그린 배포와 카나리아 배포: 주요 차이점

오늘날 소프트웨어 개발에서 배포 단계는 핵심적인 위치를 차지하며, 특히 클라우드 환경에서는 그 중요성이 더욱 부각됩니다.

그럼에도 불구하고, 배포는 종종 간과되는 단계 중 하나입니다. 많은 기업들이 배포를 신속하고 안정적이며 자동화하는 데 충분한 시간과 노력을 투자하지 않는 경향이 있습니다.

여전히 많은 경우에 수동 배포 방식이 사용되고 있습니다. 조금 나은 경우에는 상세하게 문서화된 단계별 체크리스트가 활용되지만, 최악의 경우에는 배포 직전에 즉흥적으로 계획이 세워지기도 합니다.

자동화된 배포 절차는 많은 기업들이 지향하는 장기적인 목표이지만, 실제 구현 과정은 순탄치 않은 경우가 많습니다. 그러나, 완전 자동화되고 안정적인 배포 시스템을 구축하는 것은 장기적으로 상당한 비용 절감으로 이어질 수 있습니다. 이는 대부분의 개발팀이 제품을 릴리스할 때마다 소모하는 많은 노력을 줄여주기 때문입니다.

카나리아 및 블루-그린 배포 전략은 이러한 이점을 활용하면서 고가용성, 빠른 설치 및 복구 프로세스를 추가로 제공합니다. 이러한 전략을 통해 개발팀은 큰 부담 없이 더 자주 릴리스를 할 수 있게 됩니다. 이제 각각의 전략이 무엇인지, 그리고 어떤 차이점이 있는지 자세히 살펴보겠습니다.

블루-그린 배포: 개요

출처: cncf.io

블루-그린 배포는 활성 환경(블루)과 비활성 환경(그린)이라는 두 개의 동일한 환경을 만들어 다운타임을 줄이고 새로운 소프트웨어 버전의 위험을 최소화합니다.

활성 환경은 현재 소프트웨어 버전이 실행 중이며 사용자들이 실제 트래픽을 발생시키는 곳입니다. 비활성 환경은 새로운 소프트웨어 버전이 배포되고 테스트되는 장소입니다.

새로운 버전의 테스트가 완료되면 트래픽을 활성 환경에서 비활성 환경으로 전환하여 새로운 활성 환경으로 만듭니다. 필요에 따라 이 과정을 반복할 수 있습니다.

참고 자료: 블루-그린 배포 및 DevOps에서의 역할 설명

주요 특징 및 장점

블루-그린 배포 프로세스의 주요 특징은 다음과 같습니다.

• 두 개의 동일한 환경은 데이터 및 프로세스 관점에서 동일합니다. 블루(활성) 환경은 실제 사용자들이 일상적인 작업을 수행하는 곳이고, 그린(비활성) 환경은 새로운 배포가 설치되고 블루 환경과 항상 동기화되는 곳입니다.
• 활성 환경에서 비활성 환경으로 트래픽을 전환하여 새로운 활성 환경으로 만듭니다. 이 전환은 즉각적으로 이루어집니다. 이는 배포 과정이 과거의 일이 되고, 다운타임이 전혀 발생하지 않으며, 사용자들이 새로운 환경에 접속하기 위해 아무런 조치를 취할 필요가 없다는 것을 의미합니다.
• 문제가 발생할 경우 신속하게 복구할 수 있습니다. 이렇게 하면 새로운 소프트웨어 버전에 문제가 발생했을 때 다운타임을 최소화하고 애플리케이션의 가용성을 높게 유지할 수 있습니다.
• 자동화된 테스트는 블루-그린 배포의 핵심 요소입니다. 이를 통해 새로운 버전의 소프트웨어가 활성 환경에 배포되기 전에 철저하게 테스트될 수 있습니다.
• 이 배포 방식은 지속적 배포 파이프라인의 일부이며, 이는 소프트웨어를 더 빠르고 자주 프로덕션 환경에 릴리스할 수 있음을 의미합니다. 배포가 이미 완료된 상태에서 트래픽 전환만 수행하면 되기 때문에, 테스트만 빠르게 이루어진다면 매일 배포하는 것도 가능합니다.

카나리아 배포: 개요

출처: cncf.io

카나리아 배포는 새로운 기능이나 업데이트를 전체 사용자에게 배포하기 전에 소규모 사용자 그룹에게 점진적으로 릴리스하는 방식입니다.

이 방식은 새로운 버전의 소프트웨어를 만들어서 소규모 그룹에게 배포하는 동시에, 나머지 사용자는 이전 버전을 계속 사용하게 하는 것을 포함합니다. 개발팀은 새로운 버전이 안정적이고 예상대로 작동하는지 면밀히 모니터링합니다.

모든 것이 원활하게 진행되면 새로운 버전을 더 많은 사용자에게 배포하여 전체 사용자 기반에 도달하도록 합니다. 이를 통해 개발팀은 모든 사용자에게 한 번에 영향을 줄 수 있는 버그나 기타 문제의 위험을 최소화할 수 있습니다.

이 방법의 목적은 대규모 사용자 기반에 새로운 기능을 도입할 때 발생할 수 있는 위험을 줄이는 것입니다. 따라서 새로운 버전으로의 전환이 훨씬 더 원활하게 이루어질 수 있습니다.

참고 자료: DevOps에서의 카나리아 배포 및 역할 설명

주요 특징 및 장점

카나리아 배포 프로세스의 주요 특징은 다음과 같습니다.

• 새로운 버전을 먼저 소규모 사용자 그룹에게 배포한 다음, 시간이 지남에 따라 점차 더 많은 사용자에게 배포합니다. 이를 통해 모든 사용자에게 한 번에 영향을 줄 수 있는 버그나 기타 문제의 위험을 최소화할 수 있습니다.
• 새로운 버전이 안정적이고 예상대로 작동하는지 면밀히 모니터링합니다. 개발자들은 새로운 버전에 대한 피드백을 더 빨리 받을 수 있으므로, 전체 사용자 기반에 배포하기 전에 필요한 조정을 할 수 있습니다.
• 문제가 발생하면 배포를 빠르고 쉽게 이전 버전으로 되돌릴 수 있습니다. 이를 통해 사용자 경험에 영향을 줄 수 있는 문제의 위험을 줄여 개발자 및 관련자들의 배포 과정에 대한 신뢰를 높이는 데 도움이 됩니다.
• 인적 오류의 위험을 줄이기 위해 배포 프로세스를 최대한 자동화합니다.

요약: 블루-그린 배포와 카나리아 배포 비교

블루-그린 배포와 카나리아 배포 비교: 기능

배포

블루-그린 배포는 두 개의 환경(블루 및 그린)을 활용하지만, 이 두 환경은 데이터 측면에서 지속적으로 동기화됩니다. 이러한 특성으로 인해 두 환경 간의 영구적인 데이터 동기화 프로세스가 필요합니다.

새로운 버전이 테스트를 마치고 준비되면 트래픽이 활성 환경에서 비활성 환경으로 전환되어 새로운 활성 환경이 됩니다.

새로운 코드를 배포하는 데 시간을 낭비하지 않아도 되며, 프로덕션 중단 시간도 없습니다. 모든 프로덕션 사용자는 현재 활성 환경에서 항상 작업을 수행하고 있으며, 전환을 인지하지 못합니다.

출처: aws.amazon.com

카나리아 배포는 대부분의 사용자가 현재 버전을 계속 사용하는 동안, 소규모 사용자 하위 집합에게 새로운 버전의 소프트웨어를 배포하는 것을 포함합니다. 이는 전체적인 전환이 아닌 점진적인 배포 방식입니다. 이때, 테스터는 정의된 하위 집합이기는 하지만 실제 프로덕션 사용자입니다. 이 그룹은 프로덕션 프로세스를 통해 새로운 버전을 적극적으로 테스트하고, 최종적으로 안정화되면 새로운 버전이 나머지 사용자에게 확산됩니다.

고가용성이 우선이라면 블루-그린 배포를 선택해야 합니다. 빠른 피드백과 더 통제된(느리지만) 롤아웃을 선호하는 경우 카나리아 배포를 고려할 수 있습니다.

위험 완화 차이

블루-그린 배포는 안정적인 이전 버전으로 빠르게 전환하여 릴리스 실패 위험을 완화합니다. 이 방법은 모든 사용자에게 즉시 적용됩니다. 물론 롤백 시 사용자에게 새로운 기능이 지연될 위험은 있지만, 새 릴리스의 주요 문제로 인해 적어도 사용자 중 누구도 차단되지 않습니다.

카나리아 배포의 위험 완화 전략은 문제 발생 가능성을 점진적으로 줄이는 데 있습니다. 새로운 기능이 프로덕션 사용자의 하위 그룹에 릴리스되므로, 릴리스가 모든 사용자에게 배포되기 전에 이미 해당 소프트웨어 버전을 사용하고 있습니다. 초기 사용자가 문제를 빠르게 발견할 가능성이 높습니다.

테스트 접근 방식 차이

블루-그린 배포에서는 비활성 환경에 대한 테스트 프로세스만 진행합니다. 개발자, 테스터 및 다양한 관계자들이 원하는 대로 테스트를 진행할 수 있습니다. 테스트가 실제 프로덕션 환경에서 직접 실행되는 것처럼 항상 유사한 동작을 기대할 수 있습니다. 이는 데이터와 구성이 두 환경 간에 항상 동기화되어 있기 때문입니다.

따라서 테스터는 테스트를 진행하지만, 실제 프로덕션 사용자들이 발견할 수 있는 모든 문제를 포착하지 못할 가능성이 있습니다. 하지만 비활성 환경과 활성 환경 간의 전환이 항상 빠르기 때문에 큰 문제가 되지 않습니다. 개발자는 문제를 수정하고 다시 전환할 수 있습니다.

출처: ibm.com

카나리아 배포를 사용하면 프로덕션 사용자를 테스터로 활용할 수 있습니다. 이러한 사용자들은 일반적으로 더 짧은 시간 안에 더 많은 문제를 발견하는 경향이 있습니다. 그들은 단순히 일상적인 업무 프로세스를 엔드-투-엔드로 실행합니다.

이러한 테스트 시나리오와 사례를 구성해서가 아니라, 어쨌든 그렇게 해야 하기 때문입니다. 해당 그룹의 일부 사용자들은 일시적으로 심각한 문제를 겪을 위험이 있습니다. 하지만 대부분의 사용자에겐 영향을 주지 않으며, 개발팀은 가장 심각한 실제 문제에 즉시 집중할 수 있습니다.

경험 및 사용 사례

다음은 이러한 배포 방식이 성공적으로 실행되고 있는 몇 가지 알려진 사용 사례입니다.

• Netflix는 블루-그린 배포를 사용하여 스트리밍 서비스의 새로운 버전을 배포합니다.
• Amazon과 Etsy는 블루-그린 배포를 사용하여 전자 상거래 플랫폼의 새로운 버전을 배포합니다.
• LinkedIn은 블루-그린 배포를 사용하여 소셜 네트워킹 플랫폼의 새로운 버전을 배포합니다.
• IBM은 블루-그린 배포를 사용하여 클라우드 플랫폼의 새로운 버전을 배포합니다.
• Netflix는 또한 카나리아 배포를 사용하여 스트리밍 서비스에 대한 변경 사항을 배포합니다. 회사는 자동화된 테스트, 기능 플래그 및 A/B 테스트를 결합하여 변경 사항을 천천히 적용합니다.
• Google은 카나리아 배포를 사용하여 클라우드 서비스에 변경 사항을 적용합니다. 이 회사 역시 자동화된 테스트, 트래픽 분할 및 모니터링 기능을 활용하여 모든 사용자에게 배포하기 전에 소규모 사용자 그룹에 변경 사항을 점진적으로 롤아웃합니다.

모범 사례 및 향후 동향

자동화가 핵심이며, DevOps 파이프라인은 배포 프로세스의 미래를 이끌어갈 핵심 요소입니다. 이 파이프라인은 다음 단계를 포함하는 완전 자동화된 프로세스입니다.

• 서비스, 데이터, 사용자 또는 권한 측면에서 대상 환경을 생성하거나 업데이트합니다.
• 코드 리포지토리에서 직접 소스 코드의 전체 또는 델타 버전을 자동으로 배포합니다.
• 데이터베이스 스키마 업그레이드 및 데이터 새로 고침을 수행합니다.
• 배포 활동 중에 자동화된 테스트를 실행합니다.
• 중요한 테스트 사례가 성공적으로 완료되지 않은 경우 자동 롤백 프로세스를 실행합니다.
• 수동 개입 단계를 완전히 제거합니다.

이러한 배포 파이프라인이 구축되면, 카나리아 배포 또는 블루-그린 배포, 혹은 다른 어떤 프로세스든 연결하여 사용할 수 있습니다. 이들은 이미 효과가 입증된 몇 가지 예에 불과합니다. 그러나 이들은 배포 활동과 관련된 대부분의 문제를 해결하기 위한 철학적 프레임워크일 뿐입니다. 시간이 지남에 따라 이들 사이를 전환하거나 두 가지를 조합하여 사용하는 것도 어렵지 않습니다.

마지막 말

수동 배포 방식을 고수하는 것은 미숙한 개발 프로세스 또는 팀의 모습을 드러내는 것입니다. 혹은 특정 회사가 소프트웨어 제공 측면에서 얼마나 경직되고 획일적인지를 보여줄 수 있습니다. 두 경우 모두 기존 방식을 바꾸기 위해 많은 노력이 필요하다는 것을 의미합니다. 따라서 프로젝트에 위에 언급된 배포 전략을 구현해 보는 것을 고려하십시오.

다음으로, Kubernetes에서 애플리케이션을 배포하는 방법을 확인해 보십시오.