배포, 테스트 방식(전략)(Recreate, Rolling, blue/green, Canary, A/B, Shadow)

목차

 

배포 방식에 대해 찾아 보았는데

롤백하고 카나리하고 비슷하게 적어 놓는 경우도 있고 블루/그린도 비슷하게 적어놓은경우가 많아

역시 구글에서 정리해놓은 것을 옮겨보는게 좋아 보여 포스팅 했습니다.

 

배포 방식

서비스를 배포할 때 항상 사용자에게 즉시 노출되는 것은 아닙니다. 서비스가 출시된 후에만 사용자에게 애플리케이션의 변경사항이 표시되기도 합니다. 그러나 서비스가 인플레이스 출시되면 배포와 출시가 동시에 발생합니다. 이 경우 새 버전을 배포하면 프로덕션 트래픽이 허용되기 시작합니다. 또는 여러 서비스 버전을 동시에 프로비저닝하기 위한 배포 전략이 있습니다. 이러한 배포 패턴을 사용하면 들어오는 요청을 수신하는 버전을 제어하고 관리할 수 있습니다.

Recreate, Rolling, Blue/green

 

테스트 방식

일반적으로 동시 실행 및 부하의 현실적인 수준에서 합당한 기간 동안 서비스의 신뢰성과 안정성을 검증하는 데 사용됩니다.

Canary, A/B, Shadow

 

 

 

 

 

Recreate

 

 

주요 이점

재생성 방법의 이점은 단순성입니다. 두 개 이상의 애플리케이션 버전을 동시에 관리할 필요가 없으므로 데이터 및 애플리케이션에 대한 이전 버전과의 호환성 도전과제를 방지할 수 있습니다.

 

고려사항

재생성 메서드는 업데이트 프로세스 중에 다운타임이 발생합니다. 다운타임은 유지보수 기간 또는 중단을 처리할 수 있는 애플리케이션의 문제가 아닙니다. 그러나 서비스수준계약(SLA) 및 가용성 요구사항이 높은 미션 크리티컬 애플리케이션이 있는 경우 다른 배포 전략을 선택할 수도 있습니다.

 

 

Rolling

 

이 배포 방식에서는 동시에 업데이트하는 인스턴스 수를 창 크기(window size)라고 합니다. 위 다이어그램에서 순차적 업데이트의 창 크기는 1입니다. 한 번에 하나의 애플리케이션 인스턴스가 업데이트됩니다. 큰 클러스터가 있는 경우 창 크기를 늘릴 수도 있습니다.

순차적 업데이트를 사용하면 애플리케이션을 유연하게 업데이트할 수 있습니다.

• 이전 버전을 축소하기 전에 새 버전으로 애플리케이션 인스턴스를 수직 확장할 수 있습니다(일시 급증 업그레이드 프로세스라고도 함).
• 새 인스턴스를 동시에 수직 확장하는 동안 사용할 수 없는 최대 애플리케이션 인스턴스 수를 지정할 수 있습니다

주요 이점

• 다운타임 없음. 창 크기에 따라 배포 대상을 점진적으로 업데이트합니다(예: 하나씩 또는 2개씩). 애플리케이션의 새 버전이 트래픽을 수락할 준비가 된 후에만 트래픽을 업데이트된 배포 대상으로 전달합니다.
• 배포 위험 감소. 업데이트를 점진적으로 출시하면 새 버전의 불안정성이 일부 사용자에게만 영향을 미칩니다.

고려사항(단점)

• 느린 롤백. 새 출시가 안정적이지 않는 경우 새 복제본을 종료하고 이전 버전을 재배포할 수 있습니다. 그러나 출시와 마찬가지로 롤백은 점진적인 프로세스입니다.
• 이전 버전과의 호환성. 새 코드와 이전 코드가 나란히 표시되어 있으므로 사용자가 임의로 버전 중 하나로 라우팅될 수 있습니다. 따라서 새 배포가 이전 버전과 호환되는지 확인합니다. 즉, 새 애플리케이션 버전은 이전 버전이 저장하는 데이터를 읽고 처리할 수 있습니다. 이 데이터에는 디스크, 데이터베이스에 또는 사용자 브라우저 세션의 일환으로 저장된 데이터가 포함될 수 있습니다.
• 고정 세션. 애플리케이션에 세션 지속성이 필요한 경우 부하 분산기가 고정 및 연결 드레이닝을 지원하는 것이 좋습니다. 또한 세션이 기본 리소스에서 분리될 수 있도록 가능하면 세션 복제나 Datastore를 이용한 세션 관리를 통해 세션 공유를 호출하는 것이 좋습니다

연결 드레이닝 : 연결 드레이닝은 VM이 인스턴스 그룹에서 삭제되거나 엔드포인트가 영역 NEG에서 삭제될 때 진행 중인 기존 요청에 완료될 시간을 제공하는 프로세스입니다.

 

 

BLUE/GREEN

다이어그램에서 블루는 현재 애플리케이션 버전을, 그린은 새 애플리케이션 버전을 나타냅니다. 한 번에 하나의 버전만 게시되며, 그린 배포가 생성되고 테스트되는 동안 트래픽이 블루 배포로 라우팅됩니다. 테스트를 완료하면 트래픽을 새 버전으로 라우팅합니다.

 

배포에 성공하면 가능한 롤백에 대한 블루 배포를 유지하거나 사용 중지할 수 있습니다. 또는 이러한 인스턴스에 애플리케이션의 최신 버전을 배포할 수 있습니다. 이 경우 현재(블루) 환경은 다음 출시의 스테이징 영역으로 제공됩니다.

 

 

 

주요 이점

• 제로 다운타임. 블루/그린 배포를 사용하면 다운타임 없이 신속하게 컷오버할 수 있습니다.
• 즉시 롤백. 부하 분산기를 조정하여 트래픽을 다시 블루 환경으로 전달함으로써 배포 프로세스 중 언제든지 롤백할 수 있습니다. 다운타임의 영향은 문제를 감지한 후 트래픽을 블루 환경으로 전환하는 데 걸리는 시간으로 제한됩니다.
• 환경 분리. 블루/그린 배포는 동시 그린 환경을 가동해도 블루 환경을 지원하는 리소스에 영향을 미치지 않도록 합니다. 환경을 분리하면 배포 위험이 줄어듭니다.

컷오버(cutover)란 기존에 운영되던 정보시스템을 완전히 중단시키고, 새로 구축된 정보시스템을 본격 오픈하는 것을 의미한다

 

 

고려사항

• 비용 및 운영 오버헤드. 인프라가 동일한 중복 환경을 유지해야 하기 때문에 블루/그린 배포 패턴을 채택하면 운영 오버헤드와 비용이 증가할 수 있습니다.
• 이전 버전과의 호환성. 블루 및 그린 배포는 데이터 포인트 및 Datastore를 공유할 수 있습니다. 두 애플리케이션 버전이 Datastore의 스키마와 레코드 형식을 사용할 수 있는지 확인하는 것이 좋습니다. 이전 버전과의 호환성은 원할하게 두 버전 간에 전환하려는 경우에 필요합니다.
• 컷오버. 현재 버전을 사용 중지하려는 경우 기존 트랜잭션 및 세션에서 적절한 연결 드레이닝을 허용하는 것이 좋습니다. 이 단계를 통해 현재 배포에서 처리된 요청을 정상적으로 완료하거나 종료할 수 있습니다.

 

 

Canary

변경사항을 부분적으로 출시한 후 기준 배포와 비교하여 성능을 평가합니다.

얼핏 보면 rolling과 같아 보이는데  rolling은 서버를 새버전에 중점을 두는것이고 canary는 유저를 새버전에 둔다고 생각하면 됩니다.

 

 

이 테스트 패턴에서는 프로덕션 버전과 함께 애플리케이션의 새 버전을 배포합니다. 그런 다음 프로덕션 버전에서 카나리아 버전으로 트래픽 비율을 분할하고 라우팅하여 카나리아의 성능을 평가합니다.

Canary를 구성할 때 평가에 대한 주요 메트릭을 선택합니다. Canary를 실제 프로덕션 환경이 아닌 동등한 기준과 비교하는 것이 좋습니다.

분석에 영향을 줄 수 있는 요소(예: 캐싱, 장기 연결, 해시 개체)를 줄이려면 애플리케이션의 기준 버전에 대해 다음 단계를 수행하는 것이 좋습니다.

• 애플리케이션의 기준 및 프로덕션 버전이 동일하도록 합니다.
• 카나리아를 배포하는 동시에 기준 버전을 배포합니다.
• 기준 배포(예: 애플리케이션 인스턴스 수 및 자동 확장 정책)가 카나리아 배포와 일치하도록 합니다.
• 기준 버전을 사용하여 카나리아와 동일한 트래픽을 제공합니다.

주요 이점

• 실시간 프로덕션 트래픽을 테스트하는 기능. 스테이징 환경에서 시뮬레이션된 트래픽을 사용하여 애플리케이션을 테스트하는 대신 실시간 프로덕션 트래픽에서 카나리아 테스트를 실행할 수 있습니다. 카나리아 출시를 통해 새 애플리케이션을 출시할 시점과 출시의 다음 단계를 트리거할 시기를 결정해야 합니다. 모니터링하여 문제를 확실하게 감지할 수 있도록 카나리아에 충분한 트래픽이 있어야 합니다.
• 빠른 롤백. 사용자 트래픽을 애플리케이션의 이전 버전으로 리디렉션하여 빠르게 롤백할 수 있습니다.
• 제로 다운타임. 카나리아 릴리스를 사용하면 다운타임 없이 실시간 프로덕션 트래픽을 다른 버전의 애플리케이션으로 라우팅할 수 있습니다.

고려사항

• 느린 출시. 점진적 출시마다 적절한 기간 동안 모니터링이 필요하므로 전체 출시가 지연될 수 있습니다. 카나리아 테스트는 몇 시간이 걸리기도 합니다.
• 관측 가능성. 카나리아 테스트를 구현하기 위한 기본 요건은 인프라 및 애플리케이션 스택을 효과적으로 관찰하고 모니터링하는 것입니다. 강력한 모니터링을 구현하려면 상당한 노력이 필요할 수 있습니다.
• 이전 버전과의 호환성 및 고정 세션. 순차적 업데이트와 마찬가지로 카나리아가 배포되는 동안 여러 애플리케이션 버전이 환경에서 실행되므로 카나리아 테스트는 이전 버전과의 비호환성 및 세션 지속성의 위험을 초래할 수 있습니다.

 

 

A/B 

가설을 테스트한다고 생각하면 좋은데,

A/B 테스트는 데이터에서 파생된 결과를 기반으로 예측은 물론 비즈니스 결정을 내리는 데 사용됩니다.

 

A/B 테스트를 수행하는 경우 다음 다이어그램과 같이 라우팅 규칙에 따라 일부 사용자를 새 기능으로 라우팅합니다.

라우팅 규칙에는 브라우저 버전, 사용자 에이전트, 위치정보, 운영체제 등의 요소가 포함될 때도 있습니다. 버전을 측정하고 비교한 후에는 더 나은 결과를 얻은 버전으로 프로덕션 환경을 업데이트합니다

 

 

주요 이점

A/B 테스트는 애플리케이션 기능의 효과를 측정하는 데 가장 적합합니다. 앞에서 설명한 배포 패턴의 사용 사례는 새 소프트웨어를 안전하게 출시하고 예측 가능하게 롤백하는 것에 중점을 둡니다. A/B 테스트에서는 새 기능의 대상을 제어하고 사용자 동작에서 통계적으로 유의미한 모든 차이점을 모니터링합니다.

 

고려사항

• 복잡한 설정. A/B 테스트에는 한 버전이 다른 버전보다 나은지 확인할 수 있는 대표 샘플이 필요합니다. 샘플 크기를 미리 계산(예: A/B 테스트 샘플 크기 계산기 사용)하고 통계적 유의성이 95% 이상이 되도록 적절한 기간 동안 테스트를 실행해야 합니다.
• 결과의 유효성. 거짓양성, 편향된 샘플링 또는 외부 요인(예: 시즌성 또는 마케팅 프로모션)을 비롯한 여러 요소가 테스트 결과를 왜곡시킬 수 있습니다.
• 관측 가능성. 중복 트래픽에 대해 여러 A/B 테스트를 실행하면 모니터링 및 문제해결 프로세스가 어려울 수 있습니다. 예를 들어 제품 페이지 A와 제품 페이지 B를 비교하거나 결제 페이지 C와 결제 페이지 D를 비교하면, 버전 간 트래픽 분할과 같은 측정항목을 결정하는 데 분산 추적이 중요해집니다.

 

 

 

Shadow

Canary와 같은 순차적 실험 기술은 테스트 초기 단계에서 고객을 열악한 애플리케이션 버전에 노출시킬 수 있습니다. 시뮬레이션과 같은 오프라인 기술을 사용하여 이 위험을 관리할 수 있습니다. 하지만 오프라인 기술은 새 버전과의 사용자 상호작용이 없으므로 애플리케이션의 개선사항을 검증하지는 않습니다.

Shadow 테스트를 사용하면 다음 다이어그램과 같이 새 버전을 사용자로부터 숨기는 방식을 이용하여 새 버전을 현재 버전과 함께 배포하고 실행할 수 있습니다.

수신 요청은 테스트 환경에서 미러링되고 재실행됩니다. 이 프로세스는 이전에 캡처된 프로덕션 트래픽의 사본이 새로 배포된 서비스에 대해 재실행된 후에 실시간 또는 비동기적으로 발생할 수 있습니다.

섀도 테스트가 기존 프로덕션 환경 또는 사용자 상태를 변경할 수 있는 부작용을 트리거하지 않도록해야 합니다.

 

주요 이점

• 제로 프로덕션 영향. 트래픽이 중복되므로 섀도 데이터를 처리하는 서비스의 모든 버그는 프로덕션에 영향을 주지 않습니다.
• 프로덕션 부하를 사용하여 새 백엔드 기능 테스트. Diffy 등의 도구를 함께 사용하면 트래픽 섀도잉을 통해 실시간 프로덕션 트래픽과 비교하여 서비스의 동작을 측정할 수 있습니다. 이 기능을 사용하면 애플리케이션 버전 간의 오류, 예외, 성능, 결과 패리티를 테스트할 수 있습니다.
• 배포 위험 감소. 트래픽 섀도잉은 일반적으로 카나리아 테스트와 같은 다른 접근 방식과 결합됩니다. 트래픽 섀도잉을 사용하여 새 기능을 테스트한 후에는 시간이 지남에 따라 늘어나는 사용자 수에 맞춰 기능을 출시하여 사용자 환경을 테스트합니다. 애플리케이션이 안정성 및 성능 요구사항을 충족할 때까지 전체 출시가 발생하지 않습니다.

고려사항

• 부작용. 트래픽 섀도잉 기능을 사용하면 상태를 변경하거나 타사 서비스와 상호작용하는 서비스를 신중하게 처리해야 합니다. 예를 들어 장바구니 플랫폼의 결제 서비스를 섀도 테스트하려는 경우에는 고객이 주문에 대해 두 번 결제하면 됩니다. 원치 않는 변형이나 기타 위험성이 높은 상호작용을 야기할 수 있는 섀도 테스트를 방지하려면 타사 시스템 또는 Datastore 대신 Hoverly와 같은 가상화 도구나 스터브를 사용하는 것이 좋습니다.
• 비용 및 운영 오버헤드. 섀도 테스트는 설정하기가 상당히 복잡합니다. 또한 블루/그린 배포와 마찬가지로 섀도 배포는 두 환경을 동시에 실행하고 관리하도록 설정되어야 하기 때문에 비용과 운영에 영향을 미칩니다.

 

 

 

 

Reference

원본입니다.

https://cloud.google.com/architecture/application-deployment-and-testing-strategies?hl=ko 

애플리케이션 배포 및 테스트 전략  |  클라우드 아키텍처 센터  |  Google Cloud