2017-04-18 12 views
0

실제로 더 나은 용어가 필요할 수도 있지만 그 사실을 알지 못하며 문제의 주제를 제안하거나 수정하는 사람에게 감사 할 것입니다. 적절하게.B가 폴백 인 경우 일종의 A/B 테스트

프로덕션 서버에 배포 된 웹 API 서비스 S을 고려하십시오. 그것을 진리의 근원으로 삼자.

그런 다음 예를 들어 핵심 비즈니스 로직이나 서비스의 공개 계약에 직접적으로 영향을 미치지 않는 일부 외부 종속성이나 인프라 코드를 업데이트해야합니다.

따라서 S_updated은 스테이징 단계를 통과해야만 프로덕션에 배포됩니다. 코드베이스의 변경으로 인해이 서비스가 이전 버전으로 작동하거나 통합 문제로 인해 전혀 작동하지 않을 것으로 예상됩니다. 시스템의 동작을 어떻게 든 변경하는 위험은 여전히 ​​있지만, 나는 그것으로 살 수 있고 단위 테스트가 다소 좋은 안전망이 될 것으로 기대합니다. 이것은 또한 연습에 의해 입증됩니다.

실제적으로는 S_updated을 프로덕션에 배포하고 이전 S 서비스에 대한 요청의 일부 또는 전부 (구성에 따라 다름)를 전달할 수있는 프록시 서비스를 가질 수 있습니다.

이러한 기능에 대한 일반적인 구성 가능한 솔루션이 있습니까?

+1

Canary 출시 및 Blue/Green 배포를 연구해야합니다. 이들은 당신이 묘사하고있는 패턴입니다. – Paolo

답변

1

파올로의 의견이 정확합니다. Canary release process.

배포 할 때 클라이언트가 이전 서비스에 도달 할 가능성이 높으며 새 서비스에 도달 할 가능성이 적습니다. 따라서 (새 서비스의 오류로 인해) 호출이 실패하면 클라이언트는 호출을 반복하고 이전 서비스에 도달 할 확률이 높습니다.

이 작업을 수행하는 방법은 사용중인 인프라에 따라 다릅니다.

예를 들어 kubernetes 클러스터를 사용하는 경우 서비스의 프런트 엔드 부하 분산 장치가 트래픽의 일부만을 두 번째 클러스터 (또는 동일한 클러스터에서 실행중인 경우 두 번째 서비스)로 보내도록 구성합니다. 새 버전의 서비스를 실행합니다.

DNS 기반로드 균형 조정 솔루션을 사용하는 경우 새 서비스가있는 서버로 트래픽을 보내는 가중치 모드로 DNS 정책을 변경해야합니다.

+0

예, 카나리아와 매우 유사합니다. 하지만 사용자 기반이 너무 작기 때문에 요청을 나눌 수 없습니다. =) 테스트에 몇 달이 걸릴 것입니다. –

+1

또 다른 대안은 API 게이트웨이를 사용하여 실패한 요청을 대체 엔드 포인트로 경로 재 지정하도록 구성하는 것입니다. Hystrix에서 Kong 또는 Zuul과 같은 것을 사용하십시오. 또한 사용자가 테스트 할 수없는 경우 자동화 된 테스트를 작성하는 것도 고려하십시오. –