분산 서비스에서 "재시도"를 피하는 방법은 무엇입니까?

"재시도 스톰"은 클라이언트가 포기하기 전에 설정된 횟수만큼 재 시도하도록 구성 될 때 발생합니다. 서비스의 정상적인 작동에서 패킷 손실이 발생하기 때문에 재시도 정책이 필요합니다.

이 예제를 보자 :

예를 들어 전체 서비스가 초당 80,000 건의 요청을 지원하고 용량의 약 80 %로 실행되도록 확장 된 경우, 서비스가 초당 101,000 건의 요청을 수신하게하는 트래픽 급증으로 인해 해당 요청 중 1,000 건이 실패 할 수 있습니다.

재시도 정책이 시작되면 실패가 감지 된 위치에 따라 초당 최대 102,000 건의 요청으로 서비스를 푸시하는 추가 1,000 건 이상의 요청이 발생합니다. 초당 실패한 요청 수

예상되는 최대 트랜잭션을 넘어서는 대규모의 초과 프로비저닝 서비스 외에는 비효율적입니다. "재시도 폭풍"을 피하기 위해 어떤 전략을 사용할 수 있습니까?

피하려고하는 것에 달려 있습니다.

진정으로 중요한 서비스 인 서비스 중단을 피하려는 경우 ( "API 호출이 적절하게 제공되지 않으면 사람들이 죽을 것"이라는 관점에서) 전용 리소스를 프로비저닝하는 것보다 그렇습니다. 이들은 트래픽 급증을 허용하지 않는 여러 가지 서비스 스파이 킹으로 인해 중단이 발생할 수 있습니다.

서비스 중단이 발생할 가능성 이 훨씬 높은 시나리오에서는 클라이언트와 서버 측 모두에서 문제를 해결할 수 있습니다. 트래픽을 처리하지 않고 (자원을 소비하는) 트래픽이 재 시도인지 알 수 없기 때문에 실제로 많은 트래픽에 대한 문제를 실제로 해결하는 것은 논리적으로 불가능하다는 점은 주목할 만하지 만 성공적이지만 잘못 처리 된 요청에 대한 재시도 클라이언트가 DDOS 등의 경우에는 영향을 줄 수 있습니다 .

에서 클라이언트 코드 상한과 우아하게 실패하는 메커니즘을 가지고 합리적인 재시도 논리를 작성. 이렇게하면 사용자가 실패한 요청의 무한 루프에 빠지지 않고 잠시 동안 방금 수행 한 작업을 시도하도록 오류를 제공합니다.

당신을 위해 서버 측 인프라 가장 간단한 해결책은 스로틀이다. 요청에 대한 엄격한 제한, 특히 특정 사용 사례를 기반으로 논리적으로 요청하고 분산시킬 수있는 경우 (예 : 중앙 집중식 서비스가 어려운 결정을 내리는 경우 지리적으로 먼 요청을 차단하여 스레드가 중단 될 수 있음) 서버 측 또는 불가피하지만 사소한 중단을 고르게 분배하고 싶습니까? 등) 기본적으로 게이트웨이에서 의도적으로 503을 반환하는 것이 요청을 통과시키고 504를 보내는 것보다 훨씬 저렴하다는 사실로 요약합니다. 어쨌든. 기본적으로 고객이 현재 제공 할 수있는 내용을 기반으로 클라이언트가 동작하도록하고 올바른 응답을 제공하여 클라이언트가 적절하게 대응할 수 있도록합니다.

이러한 재시도 폭풍을 방지하는 한 가지 방법은 백 오프 메커니즘을 사용하는 것입니다.

로부터 것은 재시도에 백 오프 구현 구글 앱 엔진의 섹션 규모에 대한 설계 가이드 :

Cloud Datastore와 같은 서비스 또는 URL 가져 오기 또는 소켓 API를 사용하는 외부 서비스를 호출하는지 여부에 관계없이 코드가 실패하면 다시 시도 할 수 있습니다. 이러한 경우, 천둥 무리 문제 를 피하기 위해 항상 무작위 지수 백 오프 정책을 구현해야합니다 . 또한 최대 재시도 한계에 도달 한 후 총 재시도 횟수와 처리 실패를 제한해야합니다.

대부분의 GAE API에는 기본적으로 이러한 백 오프 메커니즘 / 정책이 활성화되어 있습니다.