관리 메뉴

피터의 개발이야기

[DevOps] 청록색 배포, A/B 테스트 및 카나리아 배포 본문

DevOps

[DevOps] 청록색 배포, A/B 테스트 및 카나리아 배포

기록하는 백앤드개발자 2023. 10. 23. 23:41
반응형

 

ㅁ 들어가며

 회사에서 DevOps에 관해서 이야기 하는 중 배포 방법을 언급했는데 구체적인 설명을 하면서 이 글을 정리하게 되었습니다. 블루그린 배포는 Amazon과 같은 곳에서 10년 이상 시행되었던 안전하고 입증된 방법입니다. 이와 관련된 책을 읽고 정리한 글은 [AWS] '서비스 운영이 쉬어지는 AWS 인프라 구축가이드' - 5장이 있습니다. 이 뿐만 아니라 배포에 관련된 카나리라는 개념도 함께 이해할 필요가 있습니다. 이런 이해는 많은  마이크로서비스, DevOps 및 클라우드 네이티브에 관한 내용을 명확히 이해하는데 도움이 됩니다.

 

 

ㅁ 무중단/중단 배포

  무중단배포는 기존 A,B서비스에 영향이 없는 C를 배포할 때에는 가능합니다. 하지만 B서비스가 사용하는 테이블이 변경되는 경우, B와 C가 양립할 수 없는 경우에는 무중단 배포를 할 수 없습니다. 중단배포는 전체 서비스를 중단하여 배포할 수 밖에 없었습니다.

 

 

ㅁ 로드밸런스를 이용한 배포

  로드밸런스를 이용한 배포 방법입니다. 배포하는 서버는 로드밸런스의 대상그룹에서 제외시키고 배포 후에 다시 대상그룹을 지정해 주는 방식입니다. 이 경우 서버는 2대 이상이어야 합니다. 추가 인스턴스를 생성하지 않고 기존의 인스턴스로 배포하는 무중단 배포방법입니다.

 

 

 

ㅁ블루 그린 배포

  두개 이상의 Auto Scaling 그룹을 나누어 AMI- 시작 템플릿을 지정하여 배포하는 방식입니다. 우선 AMI를 작성하기 위한 인스턴스를 만들어 이미지를 만들고 Auto Scaling 그룹을 만든다. 이후 로드밸런스에서 블루 그린을 나누어 대상그룹에 지정해 줍니다. 4대 이상 대량 배포 시에 유리합니다. 검증된 시작탬플릿을 통해 정해진 개수의 인스턴스를 AWS에서 자동으로 생성해 줍니다. 이러한 방법은 기본적으로 릴리스와 관련된 중단 시간을 줄이는 것을 목표로 하며, 예측 가능한 방식으로 애플리케이션을 릴리스하는 기술입니다 . 출시 전에 앱을 준비하고 문제를 발견하면 신속하게 롤백이 가능한 방법입니다.

 

 아래의 그림에서 그린은 app v1인 상태이고 블루는 app v2가 준비된 "그린" 환경으로 두 개의 동일한 환경(인프라)가 있습니다.

https://martinfowler.com/bliki/BlueGreenDeployment.html

일단 app v2 환경에 배포를 합니다. 이 환경에서 새 버전의 테스트를 완료하고 문제가 없다면, 블루 환경을 가리키도록 로드 밸런서 라우터를 변경합니다.

  릴리스로 인한 실패 또는 예외를 모니터링합니다. 모든 것이 좋아 보인다면 결국 친환경 환경을 종료하고 새로운 릴리스를 준비하는 데 사용할 수 있습니다. 그렇지 않은 경우 로드 밸런서를 다시 지정하여 녹색 환경으로 빠르게 롤백할 수 있습니다. 

 

 이론적으로는 좋은 것 같습니다. 하지만 주의해야 할 사항이 있습니다.

  • 친환경에서 장기 실행 트랜잭션. 파란색으로 전환하면 미결제 트랜잭션과 새 트랜잭션을 정상적으로 처리해야 합니다. DB 백엔드가 이를 처리할 수 없는 경우에도 문제가 될 수 있습니다.
  • 엔터프라이즈 배포는 일반적으로 "마이크로서비스" 스타일 배포에 적합하지 않습니다. 즉, 마이크로서비스 스타일 앱과 일부 기존의 변경하기 어려운 앱이 함께 작동하는 중첩이 있을 수 있습니다. 블루-그린 배포를 위해 둘 사이를 조정하면 여전히 다운타임이 발생할 수 있습니다.
  • 데이터베이스 마이그레이션은 정말 까다로울 수 있으며 앱 배포와 함께 마이그레이션/롤백해야 합니다. 이를 수행하기 위한 좋은 도구와 기술이 있지만 기존 RDBMS, NoSQL 및 파일 시스템 지원 DB가 있는 환경에서는 이러한 사항을 미리 숙고해야 합니다. 맹목적으로 Blue Green 배포를 수행한다면 데이터 정합성이 위배되고 실제로는 해로울 수 있습니다.
  • 이를 위해서는 AWS와 같은 클라우드 인프라가 필요합니다.

 

ㅁ A/B 테스트

  A/B 테스트는 청록색 배포가 아닙니다. A/B 테스트 는 유용성, 인기도, 인지도 등과 같은 다양한 이유와 이러한 요소가 수익에 미치는 영향에 대해 애플리케이션의 기능을 테스트하는 방법입니다. 일반적으로 앱의 UI 부분과 연결되지만 물론 이를 위해서는 백엔드 서비스를 사용할 수 있어야 합니다. 애플리케이션 수준 스위치(예: 특정 UI 컨트롤을 표시할 시기를 아는 스마트 로직), 정적 스위치(애플리케이션에서) 및 카나리아 릴리스를 사용하여 이를 구현할 수 있습니다.

 

  청록색 배포와 A/B 테스트의 차이점은 A/B 테스트가 앱의 기능을 측정하기 위한 것이라는 것입니다. 청록색 배포는 새 소프트웨어를 안전하게 릴리스하고 예측 가능하게 롤백하는 것입니다. 분명히 이들을 결합할 수 있습니다. 블루-그린 배포를 사용하여 A/B 테스트에 사용할 수 있는 앱에 새로운 기능을 배포합니다.

 

 

ㅁ 카나리 배포

옛날 광부들은 지하 갱도로 내려갈 때 카나리아라는 새를 두어마리 데리고 내려갔다고 합니다. 갱에서 나오는 이산화탄소나 메탄가스가 무색 무취여서 자신도 모르는 새에 중독 될 위험이 있기 때문에, 그런 환경에 민감한 카나리아 새를 데리고 들어간 거죠. 마케팅 효과를 간접적으로 테스트 하고 유효한 마케팅 전략을 위해서 블루 그린처럼 대규모 업데이트가 아닌 사용자 빈도수를 정하여 테스트 하는 방법이 카나리 배포의 목적이라고도 할 수 있습니다. 낮은 환경에서 수행하는 엄청난 수준의 테스트에 관계없이 프로덕션 환경에서 여전히 일부 버그가 있다는 사실을 완화할 수 있는 또 다른 릴리스 전략입니다. 흔히 쉽게 이야기하자면 일부 사용자를 통해 간을 보는 것이죠.

 

 

피드백을 빨리 받을수록 배포를 더 빨리 실패하거나 신중하게 진행할 수 있습니다. 청록색 배포와 동일한 이유로 위의 사항에 주의하십시오. 즉, 데이터베이스 변경으로 인해 여전히 문제가 발생할 수 있습니다.

 

 

ㅁ 정리

 DevOps 환경에서 Docker 및 Kubernetes 와 같은 기술은 이러한 배포 전략을 구현하는 데 크게 도움이 될 수 있습니다. 예를 들어 OpenShift 기본 세부 정보에 대해 걱정할 필요 없이 이러한 기술을 사용하는 데 필요한 도구를 제공하여 Docker 및 Kubernetes 사용을 크게 단순화합니다. 위에서 논의한 이 도구와 관련한 동영상 정보입니다.

 

 

ㅁ 함께 보면 좋은 사이트

[AWS] '서비스 운영이 쉬어지는 AWS 인프라 구축가이드' - 5장

ㅇ  https://blog.christianposta.com/deploy/blue-green-deployments-a-b-testing-and-canary-releases/

반응형
Comments