잘린 지수 백오프

잘린 지수 백오프는 요청 간 지연 증가와 함께 클라이언트가 주기적으로 실패한 요청을 재시도하는 네트워크 애플리케이션의 표준 오류 처리 전략입니다. 클라이언트는 데이터나 메타데이터의 업로드와 다운로드를 비롯한 HTTP 5xx429 응답 코드를 반환하는 Cloud Storage에 대한 모든 요청에 잘린 지수 백오프를 사용해야 합니다.

다음과 같은 경우 잘린 지수 백오프의 작동 방식을 이해하는 것이 중요합니다.

Google Cloud Platform 콘솔을 사용하는 경우 콘솔이 사용자를 대신하여 Cloud Storage에 요청을 보내고 필요한 백오프를 모두 처리합니다.

예제 알고리즘

지수 백오프 알고리즘이 재시도 간 대기 시간을 최대 백오프 시간까지 늘려서 기하급수적으로 요청을 재시도합니다. 예를 들면 다음과 같습니다.

  1. Cloud Storage에 요청합니다.

  2. 요청이 실패하면 1 + random_number_milliseconds초 대기한 후 요청을 재시도합니다.

  3. 요청이 실패하면 2 + random_number_milliseconds초 대기한 후 요청을 재시도합니다.

  4. 요청이 실패하면 4 + random_number_milliseconds초 대기한 후 요청을 재시도합니다.

  5. maximum_backoff 시간까지 이를 반복합니다.

  6. 최대 재시도 횟수까지 계속 대기하고 재시도합니다. 그러나 재시도 간 대기 시간을 늘리지 않습니다.

각 항목의 의미는 다음과 같습니다.

  • 대기 시간은 min(((2^n)+random_number_milliseconds), maximum_backoff)입니다. 여기에서 n은 반복(요청)마다 1씩 증가합니다.

  • random_number_milliseconds는 1,000보다 작거나 같은 임의의 숫자(밀리초)입니다. 이는 많은 클라이언트가 어떤 상황에 의해 동기화되고 모든 요청이 한 번에 재시도되어 동기화된 웨이브로 요청을 보내는 경우를 피하는 데 도움이 됩니다. 각 재시도 요청 후 random_number_milliseconds 값이 다시 계산됩니다.

  • maximum_backoff는 32 또는 64초입니다. 적절한 값은 사용 사례에 따라 다릅니다.

maximum_backoff 시간에 도달한 후에는 계속 재시도해도 좋습니다. 이후 재시도는 백오프 시간을 계속 늘릴 필요가 없습니다. 예를 들어, 클라이언트가 maximum_backoff 시간으로 64초를 사용하는 경우 이 값에 도달한 후 클라이언트는 64초마다 재시도할 수 있습니다. 특정 시점에서 클라이언트가 무한정 재시도하지 못하게 해야 합니다.

클라이언트가 재시도 사이에 얼마나 오래 대기해야 하는지와 몇 번 재시도해야 하는지는 사용 사례와 네트워크 상태에 따라 다릅니다. 예를 들어, 애플리케이션의 모바일 클라이언트는 동일한 애플리케이션의 데스크톱 클라이언트보다 더 자주, 더 긴 간격으로 재시도해야 할 수 있습니다.

maximum_backoff와 재시도할 수 있는 추가 시간이 지난 후 재시도 요청이 실패하면 지원 및 도움말에 나열된 방법 중 하나로 오류를 신고하거나 로깅합니다.

구현 예

다음은 Cloud Storage에서 사용되는 잘린 지수 백오프의 예입니다.

  • 재개 가능한 업로드에 대한 boto 예

  • 자바나 Python을 사용하는 Storage 전송 서비스에서 요청 재시도

  • 지수 백오프를 사용하여 JSON API 업로드 오류 처리

  • Cloud Storage에서 지수 백오프를 사용하여 알림 구독자에게 객체 변경 알림 전송

다음은 Cloud Storage에서 사용할 수 있는 클라이언트 라이브러리에 구현된 백오프의 예입니다.

  • Python용 라이브러리 재시도

  • Node.js용 Google Cloud 클라이언트 라이브러리는 자동으로 백오프 전략을 사용하여 autoRetry 매개변수로 요청을 재시도할 수 있습니다.

이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...

도움이 필요하시나요? 지원 페이지를 방문하세요.