프로덕션 테스트를 위해 오른쪽으로 이동

아티클
08/29/2023

Shift right는 DevOps 프로세스의 뒷부분에서 일부 테스트를 프로덕션 환경에서 테스트하도록 이동하는 방법입니다. 프로덕션 환경에서 테스트는 실제 배포를 사용하여 프로덕션 환경에서 애플리케이션의 동작 및 성능을 확인하고 측정합니다.

DevOps 팀이 속도를 향상시킬 수 있는 한 가지 방법은 왼쪽 시프트 테스트 전략을 사용하는 것입니다. Shift left는 DevOps 파이프라인의 앞부분에서 대부분의 테스트를 푸시하여 새 코드가 프로덕션에 도달하고 안정적으로 작동하는 시간을 줄입니다.

그러나 단위 테스트와 같은 많은 종류의 테스트는 쉽게 왼쪽으로 이동할 수 있지만 일부 또는 모든 솔루션을 배포하지 않고는 일부 테스트 클래스를 실행할 수 없습니다. QA 또는 스테이징 서비스에 배포하면 비슷한 환경을 시뮬레이션할 수 있지만 프로덕션 환경을 완전히 대체할 수는 없습니다. 팀은 프로덕션 환경에서 특정 유형의 테스트가 수행되어야 한다는 것을 알게 됩니다.

프로덕션 환경에서의 테스트는 다음을 제공합니다.

프로덕션 환경의 전체 폭과 다양성.
고객 트래픽의 실제 워크로드입니다.
시간이 지남에 따라 프로덕션 수요가 진화함에 따라 프로필 및 동작.

프로덕션 환경은 계속 변경됩니다. 앱이 변경되지 않더라도 앱이 사용하는 인프라는 지속적으로 변경됩니다. 프로덕션 환경에서 테스트는 지정된 프로덕션 배포의 상태 및 품질과 지속적으로 변화하는 프로덕션 환경의 유효성을 검사합니다.

프로덕션 환경에서 테스트 권한을 전환하는 것은 다음 시나리오에서 특히 중요합니다.

마이크로 서비스 배포

마이크로 서비스 기반 솔루션에는 독립적으로 개발, 배포 및 관리되는 많은 수의 마이크로 서비스가 있을 수 있습니다. 다양한 버전과 구성이 여러 가지 방법으로 프로덕션에 도달할 수 있기 때문에 이러한 프로젝트에서 테스트 권한을 전환하는 것이 특히 중요합니다. 프로덕션 전 테스트 검사와 관계없이 프로덕션에서 호환성을 테스트해야 합니다.

배포 후 품질 보장

프로덕션에 릴리스하는 것은 소프트웨어 제공의 절반에 불과합니다. 나머지 절반은 실제 프로덕션 워크로드로 대규모 품질을 보장합니다. 환경이 계속 변화하기 때문에 팀은 프로덕션 환경에서 테스트를 수행하지 않습니다.

프로덕션의 테스트 데이터는 말 그대로 실제 고객 워크로드의 테스트 결과입니다. 프로덕션 환경에서의 테스트에는 모니터링, 장애 조치(failover) 테스트 및 오류 주입이 포함됩니다. 이 테스트는 오류, 예외, 성능 메트릭 및 보안 이벤트를 추적합니다. 또한 테스트 원격 분석은 변칙을 검색하는 데 도움이 됩니다.

배포 링

프로덕션 환경을 보호하기 위해 팀은 링 기반 배포 및 기능 플래그를 사용하여 점진적이고 제어된 방식으로 변경 내용을 롤아웃할 수 있습니다. 예를 들어 고객의 1% 미만이 한 번에 모든 고객을 전환한 후보다 배포 링에 있을 때 쇼핑객이 구매를 완료하지 못하게 하는 버그를 catch하는 것이 좋습니다. 오류가 감지된 기능 값은 지정된 비즈니스에 의미 있는 방식으로 측정된 해당 오류의 순 손실을 초과해야 합니다.

첫 번째 링은 표준 통합 제품군을 실행하는 데 필요한 가장 작은 크기여야 합니다. 테스트는 다른 환경에 대해 파이프라인에서 이미 이전에 실행된 테스트와 유사할 수 있지만 테스트는 프로덕션 환경에서 동작이 동일한지 확인합니다. 이 링은 고객에게 영향을 미치기 전에 잘못된 구성과 같은 명백한 오류를 식별합니다.

초기 링의 유효성을 검사한 후 다음 링은 테스트 실행에 대한 실제 사용자의 하위 집합을 포함하도록 확장할 수 있습니다. 모든 것이 잘 보이면 배포는 모든 사용자가 사용할 때까지 추가 링 및 테스트를 진행할 수 있습니다. 전체 배포가 테스트가 끝났다는 의미는 아닙니다. 원격 분석 추적은 프로덕션 환경에서 테스트하는 데 매우 중요합니다.

오류 주입

팀은 종종 오류 주입 및 비정상 상황 엔지니어링을 사용하여 오류 조건에서 시스템이 어떻게 작동하는지 확인합니다. 이러한 사례는 다음을 지원합니다.

구현된 복원력 메커니즘이 실제로 작동하는지 확인합니다.
한 하위 시스템의 오류가 해당 하위 시스템 내에 포함되어 있고 주요 중단을 생성하기 위해 계단식으로 표시되지 않는지 확인합니다.
이전 인시던트에 대한 복구 작업이 다른 인시던트가 발생할 때까지 기다리지 않고도 원하는 효과가 있음을 증명합니다.
라이브 사이트 엔지니어가 인시던트 처리에 더 잘 대비할 수 있도록 보다 현실적인 교육 훈련을 만듭니다.

오류 주입 실험은 끊임없이 변화하는 시스템에서 실행해야 하는 비용이 많이 드는 테스트이므로 자동화하는 것이 좋습니다.

카나리아 엔지니어링은 효과적인 도구일 수 있지만 고객에게 거의 또는 전혀 영향을 주지 않는 카나리아 환경으로 제한해야 합니다.

장애 조치(failover) 테스트

오류 주입의 한 가지 형태는 BCDR(비즈니스 연속성 및 재해 복구)을 지원하기 위한 장애 조치(failover ) 테스트입니다. Teams에는 모든 서비스 및 하위 시스템에 대한 장애 조치(failover) 계획이 있어야 합니다. 계획에는 다음이 포함되어야 합니다.

서비스가 중단되는 비즈니스 영향에 대한 명확한 설명입니다.
BCDR 계획을 고안하는 플랫폼, 기술 및 사용자 측면에서 모든 종속성의 맵입니다.
재해 복구 절차의 공식 설명서입니다.
재해 복구 훈련을 정기적으로 실행하는 주기입니다.

회로 차단기 오류 테스트

회로 차단기 메커니즘은 일반적으로 해당 구성 요소의 오류가 경계 밖으로 퍼지는 것을 방지하기 위해 더 큰 시스템에서 지정된 구성 요소를 차단합니다. 회로 차단기를 의도적으로 트리거하여 다음 시나리오를 테스트할 수 있습니다.

회로 차단기가 열릴 때 대체가 작동하는지 여부입니다. 대체는 단위 테스트와 함께 작동할 수 있지만 프로덕션에서 예상대로 작동하는지 알 수 있는 유일한 방법은 오류를 주입하여 트리거하는 것입니다.
회로 차단기가 필요할 때 열기에 적합한 민감도 임계값이 있는지 여부입니다. 오류 주입은 대기 시간 또는 연결 끊기 종속성을 강제로 차단기 응답성을 관찰할 수 있습니다. 올바른 동작이 발생하는 것뿐만 아니라 충분히 빠르게 발생하는지 확인하는 것이 중요합니다.

예: Redis 캐시 회로 차단기 테스트

Redis 캐시 는 일반적으로 사용되는 데이터에 대한 액세스 속도를 높여 제품 성능을 향상시킵니다. Redis에 중요하지 않은 종속성을 사용하는 시나리오를 고려합니다. Redis가 중단되면 원래 데이터 원본을 요청에 다시 사용할 수 있으므로 시스템이 계속 작동해야 합니다. Redis 오류가 회로 차단기를 트리거하고 대체가 프로덕션에서 작동하는지 확인하려면 이러한 동작에 대한 테스트를 주기적으로 실행합니다.

다음 다이어그램에서는 Redis 회로 차단기 대체 동작에 대한 테스트를 보여 줍니다. 목표는 차단기가 열릴 때 호출이 궁극적으로 SQL로 이동하도록 하는 것입니다.

Diagram showing tests for the Redis circuit breaker and fallback behavior.

앞의 다이어그램은 Redis 호출 앞에 차단기가 있는 세 개의 AT를 보여 줍니다. 한 테스트는 회로 차단기가 구성 변경을 통해 열리도록 한 다음 호출이 SQL로 이동하는지 여부를 관찰합니다. 그런 다음 또 다른 테스트는 회로 차단기를 닫고 호출이 Redis로 다시 반환되도록 하여 반대 구성 변경을 검사.

이 테스트는 차단기가 열릴 때 대체 동작이 작동하는지 확인하지만, 회로 차단기 구성이 차단기를 열어야 하는 경우 유효성을 검사하지 않습니다. 해당 동작을 테스트하려면 실제 오류를 시뮬레이션해야 합니다.

오류 에이전트는 Redis로 가는 호출에 오류를 도입할 수 있습니다. 다음 다이어그램은 오류 주입을 사용한 테스트를 보여줍니다.

Diagram showing Redis circuit breaker testing with fault injection.

오류 인젝터에서 Redis 요청을 차단합니다.
회로 차단기가 열리고 테스트는 대체가 작동하는지 여부를 관찰할 수 있습니다.
오류가 제거되고 회로 차단기가 Redis에 테스트 요청을 보냅니다.
요청이 성공하면 되돌리기 다시 Redis로 호출합니다.

추가 단계는 차단기의 민감도, 임계값이 너무 높거나 너무 낮은지 여부 및 다른 시스템 시간 제한이 회로 차단기 동작을 방해하는지 여부를 테스트할 수 있습니다.

이 예제에서 차단기가 예상대로 열리거나 닫히지 않으면 라이브 사이트 인시던트 (LSI)가 발생할 수 있습니다. 오류 주입 테스트가 없으면 랩 환경에서 이러한 유형의 테스트를 수행하기가 어렵기 때문에 문제가 발견되지 않을 수 있습니다.