기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

재시도 동작

일시적인 오류 또는 제한으로 인해에 대한 요청이 AWS 서비스 실패하면 SDK는 요청을 자동으로 재시도할 수 있습니다. 이 페이지에서는 재시도를 구성하는 방법과 재시도가 내부적으로 작동하는 방법을 다룹니다.

재시도 구성

SDK가 사용하는 재시도 전략과 재시도 횟수를 제어합니다.

재시도 모드 선택

재시도 모드는 요청이 실패할 때 SDK가 작동하는 방식을 결정합니다. 표준, 적응형, 레거시의 세 가지 모드를 사용할 수 있습니다.

표준 모드(기본값)

표준 모드는 지터와 함께 지수 백오프를 사용하여 실패한 요청을 재시도합니다. 일시적 오류(예: 네트워크 제한 시간)에는 더 짧은 지연을 사용하고 제한 오류(예: )에는 더 긴 지연을 사용합니다ThrottlingException.

표준 모드에는 각 재시도에 대한 토큰을 공제하고 요청이 성공할 때 토큰을 보충하는 토큰 버킷인 재시도 할당량이 포함됩니다. 사용 가능한 토큰이 소진되면 SDK는 재시도 없이 오류를 반환하므로 성공할 가능성이 낮은 재시도를 기다리지 않고 애플리케이션이 빠르게 실패합니다. 또한 재시도 트래픽을 줄여 서비스 중단을 더 빠르게 해결할 수 있습니다. 정상 작동 중에는 할당량이 가득 차서 효과가 없습니다. 재시도 할당량은 초기 요청을 지연하거나 차단하지 않습니다. 재시도만 영향을 받습니다. 자세한 내용은 재시도 할당량(토큰 버킷)을 참조하세요.

다른 모드를 선택할 특별한 이유가 없는 한 표준 모드를 사용합니다.

적응 모드

적응 모드에는 표준 모드의 모든 항목과 클라이언트 측 속도 제한기가 포함됩니다. 속도 제한기는 제한 응답을 추적하고 SDK가 요청을 보내는 속도를 조정합니다. 표준 모드와 달리 적응 모드는 조절이 감지될 때 재시도뿐만 아니라 초기 요청을 지연하거나 차단할 수 있습니다.

속도 제한기는 SDK 클라이언트 인스턴스별로 작동합니다. 클라이언트의 모든 요청은 대상 API 작업 또는 리소스에 관계없이 동일한 속도 제한을 공유합니다.

적응 모드를 사용해야 하는 경우:

적응 모드를 사용하지 않는 경우:

적응 모드는 일반적인 기본값으로 권장되지 않습니다.

레거시 모드

레거시 모드는 표준 모드가 도입되기 전에 사용되는 각 SDK의 재시도 동작입니다. 표준화된 재시도 할당량은 포함되지 않습니다. 일부 SDKs(예: Java)는 레거시 모드에서 자체 재시도 할당량 구현이 있었지만 SDKs 간에 동작이 일관되지 않습니다. 표준화된 할당량이 없으면 클라이언트는 서비스 중단 중에도 계속해서 전체 속도로 재시도합니다. 이렇게 하면 성공할 가능성이 낮은 요청에 스레드와 연결이 연결되고 서비스 복구를 지연시킬 수 있는 로드가 추가됩니다.

레거시 모드SDKs마다 다릅니다. 재시도 횟수, 백오프 타이밍, 재시도 가능한 오류 세트 및 제한 동작은 언어마다 다릅니다. 레거시 재시도 동작에 의존하는 코드는 SDKs.

사용 가능한 위치: Java, Python, Ruby, PHP, C++, CLI

다음에서는 사용할 수 없습니다. .NET, Go, Kotlin, Rust, Swift, JavaScript

이전 버전과의 호환성을 위해 레거시 모드가 존재합니다. 현재 레거시 모드를 사용하는 경우 표준 모드로 전환합니다.

재시도 설정

다음 설정은 재시도 동작을 제어합니다. 환경 변수, 공유 구성 파일(~/.aws/config) 또는 코드의 클라이언트 구성을 통해 설정할 수 있습니다.

최대 시도 횟수 값이 3이면 SDK가 초기 요청을 한 번 하고 최대 두 번 재시도를 할 수 있습니다. 재시도를 완전히 비활성화하려면 최대 시도 1 횟수를 로 설정합니다.

구성 우선 순위

여러 위치에서 동일한 설정을 지정하면 SDK는 다음 우선 순위를 사용하여 값을 가장 높음에서 가장 낮음으로 확인합니다.

이는 표준 AWS SDK 구성 우선 순위를 따릅니다. 더 높은 수준에서 설정된 값은 항상 더 낮은 수준에서 설정된 값을 재정의합니다. 예를 들어를 환경 변수AWS_RETRY_MODE=adaptive로 설정하고 retry_mode=standard에서 ~/.aws/config를 설정하는 경우 SDK는 적응 모드를 사용합니다.

언어별 구성

이 페이지(retry_mode 및 max_attempts)에 설명된 교차 SDK 설정은 모든 SDKs에서 작동합니다. 그러나 코드에서 재시도를 구성하기 위한 API는 언어에 따라 다릅니다. 사용자 지정 백오프 전략, 추가 재시도 가능 오류, 재시도 할당량 조정과 같은 언어별 구성 옵션은 SDK 개발자 안내서를 참조하세요.

재시도 작동 방식

이 섹션에서는 AWS SDKs 실패한 요청을 처리하는 방법, 즉 재시도를 트리거하는 오류, 시도 사이에 SDK가 대기하는 시간, 재시도를 중지하는 시간을 설명합니다.

요청이 실패하면 어떻게 되나요?

AWS SDK를 통해 API를 호출하면 SDK는 다음 순서를 따릅니다.

SDK는 요청이 성공하거나, 최대 시도 횟수에 도달하거나, 재시도 할당량이 고갈되거나, 재시도할 수 없는 오류가 발생할 때까지이 루프를 반복합니다. 전체 프로세스는 자동입니다. 애플리케이션에 성공한 응답 또는 최종 오류가 표시됩니다.

재시도되는 오류

SDK는 실패한 각 요청을 임시, 제한 또는 재시도 불가의 세 가지 범주 중 하나로 분류합니다. 이 분류는 SDK가 요청을 재시도할지 여부와 재시도하기 전에 대기하는 시간을 결정합니다.

분류는 서비스 응답의 오류 코드와 HTTP 상태 코드를 기반으로 합니다. 예를 들어 오류 코드가 있는 HTTP 400RequestTimeout은 일시적이며 재시도된 것으로 분류됩니다. 를 사용하는 HTTP 400ValidationException은 재시도할 수 없는 것으로 분류되어 즉시 반환됩니다.

오류 분류

일시적인 오류는 짧은 기본 지연(50ms)으로 재시도됩니다.

조절 오류는 더 긴 기본 지연(1,000ms)으로 재시도됩니다.

재시도할 수 없는 오류(예: AccessDeniedException, ValidationException, ResourceNotFoundException)는 코드에 즉시 반환됩니다.

제한 오류는 서비스가 속도 제한으로 인해 요청을 적극적으로 거부했음을 의미하므로 SDK는 재시도하기 전에 더 오래 기다렸다가 서비스에서 용량을 복구할 시간을 제공합니다. 특정 지연은 SDK가 대기하는 시간 섹션을 참조하세요.

SDK가 대기하는 시간

SDK는 전체 지터와 함께 지수 백오프를 사용합니다. 평균적으로 각 재시도는 마지막 시도보다 오래 대기하며, 무작위화를 통해 여러 클라이언트의 요청을 분산합니다.

오류 유형별 기본 지연

기본 지연은 오류가 일시적인지 또는 제한인지에 따라 달라집니다.

백오프 공식

SDK는 다음 공식을 사용하여 각 재시도 지연을 계산합니다.

delay = random(0, 1) × min(20,000 ms, base_delay × 2^retry)

위치:

최대 백오프 한도는 20초입니다. 시도 횟수에 관계없이 개별 지연이 20초를 초과하지 않습니다.

작업 예제

예제 1: 일시적 오류, 최대 3회 시도

추가된 총 지연 시간은 두 재시도에서 평균 약 75ms입니다.

예제 2: 제한 오류, 최대 3회 시도

추가된 총 지연 시간은 두 재시도에서 평균 약 1,500ms입니다.

예제 3: 일시적 오류, 백오프 캡에 도달

기본 지연 시간이 50ms인 경우 한도 설정 전 계산된 지연은 다음과 같습니다.

한도는 일시적 오류에 대한 10번째 재시도(11번째 시도) 시 적용됩니다. 기본값이 1,000ms인 제한 오류의 경우 캡은 6번째 재시도 시 적용됩니다.

지터가 중요한 이유

무작위 승수를 전체 지터라고 합니다. 이렇게 하지 않으면 동시에 오류에 도달한 모든 클라이언트가 동시에 재시도하여 재시도 트래픽 버스트를 생성합니다("thundering herd" 문제). 전체 지터는 전체 백오프 기간에 균일하게 재시도를 분산하므로 서비스가 동기화된 스파이크 대신 일정한 요청 세류를 수신합니다.

예를 들어 1,000개의 클라이언트가 모두 동시에 503을 수신한다고 가정합니다. 전체 지터는 정확히 50ms에서 1,000회의 재시도를 모두 수행하는 대신 50ms 기간에 첫 번째 재시도를 균일하게 분산합니다.

서버 지정 재시도 타이밍

일부는 오류 응답에 x-amz-retry-after 헤더를 AWS 서비스 포함합니다. 헤더 값은 밀리초 단위의 지연입니다. 이 헤더가 있으면 SDK는 계산된 백오프 지연의 최소값과 계산된 백오프 지연의 최대값에 5,000ms를 더한 서버 지정 지연을 사용합니다. 계산된 백오프 자체는 20초로 제한되므로 유효 최대 서버 방향 지연은 25초입니다. 서비스가 지터링할 것으로 예상되므로 SDK는이 값에 지터를 적용하지 않습니다. 이렇게 하면 서비스에서 용량을 사용할 수 있을 것으로 예상되는 정확한 시간에 통신할 수 있습니다.

재시도 할당량(토큰 버킷)

SDK는 성공한 요청과 실패의 비율을 추적하는 내부 토큰 예산을 유지합니다. 장애가 분산되면 예산이 고갈되고 SDK가 오류를 직접 반환합니다. 성공할 가능성이 낮은 재시도를 기다리는 대신 애플리케이션이 빠르게 실패합니다. 또한 재시도 트래픽을 줄여 서비스 중단을 더 빠르게 해결할 수 있습니다.

재시도 할당량 작동 방식

토큰 예산이 가득 차기 시작합니다. 각 재시도는 토큰을 공제합니다. 재시도가 성공하면 SDK는 해당 재시도에서 사용하는 토큰을 복원합니다. 첫 번째 시도에서 요청이 성공하면(재시도 필요 없음) SDK는 토큰 1개를 복원합니다. 예산이 0에 도달하면 SDK는 재시도를 중지하고 오류를 코드에 직접 반환합니다.

임시 재시도 비용이 높을수록 서로 다른 실패 패턴이 반영됩니다. 500s 및 연결 실패와 같은 일시적인 오류는 종종 서비스 전반의 문제를 나타냅니다. 이러한 상황에서는 지속적인 재시도가 성공할 가능성이 낮습니다. 호출에 지연 시간을 추가하고, 클라이언트 리소스를 연결하며, 모든 사용자의 복구를 지연시킬 수 있습니다. 제한 오류는 요청이 성공하기 전에 서비스에 더 많은 시간이 필요함을 나타냅니다. SDK는 성공 가능성을 높이기 위해 재시도 사이에 더 오래 기다립니다.

가 할당량 블록 재시도를 차단하는 경우

재시도 할당량은 항상 토큰을 추적하지만 예산이 소진될 때만 재시도를 차단합니다. 정상 작동 중에는 거의 모든 요청이 성공하고 예산이 가득 찬 상태로 유지됩니다. 할당량은 재시도에 관찰 가능한 영향을 미치지 않습니다.

성공적인 재시도는 동일한 요청에서 이전에 실패한 재시도 비용이 아닌 자체 토큰 비용(토큰 14개 또는 5개)만 복원합니다. 예를 들어 첫 번째 재시도가 실패하고 두 번째 재시도가 성공하면 예산은 14개의 토큰을 잃게 됩니다. 재시도가 성공하지 않고 모든 시도를 소진하면 예산이 가장 빠르게 드레이닝되지만 요청이 성공하기 전에 여러 번 재시도가 필요한 경우에도 점진적으로 드레이닝됩니다.

기본값이 최대 3회인 경우 요청의 약 22% 이상에서 일시적인 오류가 지속되거나 제한 오류의 경우 약 32% 이상에서 할당량이 고갈되기 시작합니다. 이러한 속도 미만에서는 실패한 재시도가 예산을 비우는 것보다 성공한 요청이 예산을 더 빠르게 보충합니다.

500개의 토큰으로 구성된 예산의 시작 밸런스는 짧은 실패 버스트를 흡수하는 버퍼를 제공합니다. 심각한 오류라도 오류가 잠시 급증해도 버퍼를 비울 만큼 오래 지속되지 않는 한 재시도를 차단하지 않습니다.

실제적 영향

서비스별 동작

DynamoDB

DynamoDB 클라이언트는 DynamoDB의 짧은 지연 시간 프로파일에 최적화된 조정된 기본값을 사용합니다.

이러한 기본값은 Amazon DynamoDB 및 DynamoDB 스트림 모두에 적용됩니다.

장기 폴링 작업

특정 AWS 작업은 긴 폴링을 사용합니다. 작업이 도착할 때까지 연결을 열린 상태로 유지할 수 있습니다. 이러한 작업은 특별한 재시도 처리를 받습니다.

특수 동작: 재시도 할당량이 고갈되고 재시도가 차단된 경우에도(의 7단계요청이 실패하면 어떻게 되나요?) SDK는 여전히 백오프 지연을 적용하여 오류를 코드에 반환합니다.

이는 긴 폴링 작업이 일반적으로 긴 루프에서 호출되기 때문에 중요합니다. 코드는를 호출ReceiveMessage하고 모든 메시지를 처리한 다음 즉시를 ReceiveMessage 다시 호출합니다. 강제 백오프가 없으면 토큰 예산이 소진되어 SDK가 지연 없이 오류를 반환합니다. 그러면 폴링 루프가 즉시 다음 요청을 전송하여 클라이언트 CPU 사용량을 급증시키고 추가 트래픽을 생성합니다. 강제 백오프 지연은이 주기를 중단하여 장애 발생 시 클라이언트 리소스 사용량과 폴링 속도를 관리할 수 있도록 합니다.

AWS SDKs 도구 지원

다음 표에는 각 SDK에서 업데이트된 재시도 동작의 가용성이 나열되어 있습니다. 최소 버전, before-and-after 기본값, 코드 예제를 포함한 SDK별 세부 정보는 GitHub 추적 문제를 참조하세요.