.NET을 사용하여 재시도 정책 구현
클라우드에서 실행되거나 원격 서비스 및 리소스와 통신하는 모든 애플리케이션은 일시적인 오류를 처리할 수 있어야 합니다. 이러한 애플리케이션에서는 네트워크 연결의 순간적인 손실, 서비스 또는 리소스가 사용 중일 때의 요청 시간 제한 또는 기타 요인으로 인해 오류가 발생하는 것이 일반적입니다. 개발자는 안정성과 복원력을 향상시키기 위해 일시적인 오류를 투명하게 처리하는 애플리케이션을 빌드해야 합니다.
이 문서에서는 .NET용 Azure Storage 클라이언트 라이브러리를 사용하여 Azure Blob Storage에 연결하는 애플리케이션에 대한 재시도 정책을 설정하는 방법을 알아봅니다. 다시 시도 정책은 애플리케이션이 실패한 요청을 처리하는 방법을 정의하며, 항상 애플리케이션의 비즈니스 요구 사항 및 오류의 특성에 맞게 조정해야 합니다.
다시 시도 옵션 구성
Blob Storage에 대한 다시 시도 정책은 프로그래밍 방식으로 구성되어 다양한 서비스 요청 및 시나리오에 다시 시도 옵션이 적용되는 방식을 제어할 수 있습니다. 예를 들어 사용자 상호 작용을 기준으로 요청을 실행하는 웹앱은 다시 시도 횟수가 적고 지연이 짧은 정책을 구현하여 응답성을 높이고 오류가 발생할 때 사용자에게 알릴 수 있습니다. 또는 백그라운드에서 일괄 처리 요청을 실행하는 앱 또는 구성 요소는 다시 시도 횟수를 늘리고 지수 백오프 전략을 사용하여 요청 시간이 성공적으로 완료되도록 할 수 있습니다.
다음 표에는 RetryOptions 클래스의 속성과 형식, 간단한 설명, 기본값이 나와 있습니다. 앱의 요구 사항을 충족하기 위해 이러한 속성 값을 사전에 조정해야 합니다.
속성 | Type | 설명 | 기본값 |
---|---|---|---|
Delay | TimeSpan | 고정된 접근 방식을 위한 재시도 사이의 지연 시간 또는 백오프 기반 접근 방식을 위한 베이스 계산에 의한 지연 시간입니다. 서비스에서 Retry-After 응답 헤더를 제공하는 경우 헤더 값으로 지정된 기간으로 인해 다음 재시도가 지연됩니다. | 0.8초 |
MaxDelay | TimeSpan | 서비스에서 Retry-After 응답 헤더를 제공하지 않는 경우 재시도 사이에 허용되는 최대 지연 시간입니다. 서비스에서 Retry-After 응답 헤더를 제공하는 경우 헤더 값으로 지정된 기간으로 인해 다음 재시도가 지연됩니다. | 1분 |
MaxRetries | int | 포기하기 전 최대 재시도 횟수입니다. | 5(참고 참조) |
모드 | RetryMode | 다시 시도 지연을 계산하는 데 사용하는 방법입니다. | 지수 |
NetworkTimeout | TimeSpan | 개별 네트워크 작업에 적용된 시간 제한입니다. | 100초 |
참고 항목
StorageClientOptions
의 기본값을 MaxRetries
3에서 5로 늘입니다. 다른 모든 속성의 기본값은 다음과 같습니다 RetryOptions
.
Blob Storage에 대한 이 코드 예제에서는 BlobClientOptions 클래스의 Retry
속성에서 다시 시도 옵션을 구성합니다. 그런 다음, 다시 시도 옵션을 사용하여 Blob 서비스에 대한 클라이언트 개체를 만듭니다.
// Provide the client configuration options for connecting to Azure Blob Storage
BlobClientOptions blobOptions = new BlobClientOptions()
{
Retry = {
Delay = TimeSpan.FromSeconds(2),
MaxRetries = 5,
Mode = RetryMode.Exponential,
MaxDelay = TimeSpan.FromSeconds(10),
NetworkTimeout = TimeSpan.FromSeconds(100)
},
};
BlobServiceClient blobServiceClient = new BlobServiceClient(
accountUri,
new DefaultAzureCredential(),
blobOptions);
이 예제에서 BlobServiceClient
개체에서 발급된 각 서비스 요청은 BlobClientOptions
개체에 정의된 대로 다시 시도 옵션을 사용합니다. 앱의 요구 사항에 따라 서비스 클라이언트에 대한 다양한 다시 시도 전략을 구성할 수 있습니다.
지역 중복성을 사용하여 앱 복원력 향상
앱에 고가용성 및 오류에 대한 더 큰 복원력이 필요한 경우 다시 시도 정책의 일부로 Azure Storage 지역 중복성 옵션을 활용할 수 있습니다. 지역 중복 복제를 위해 구성된 스토리지 계정은 주 지역에서 동기적으로 복제된 다음 수백 마일 떨어진 보조 지역에 비동기적으로 복제됩니다.
Azure Storage는 지역 중복 복제를 위해 GRS(지역 중복 스토리지) 및 GZRS(지역 영역 중복 스토리지)의 두 가지 옵션을 제공합니다. 스토리지 계정에 지역 중복성을 사용하도록 설정하는 것 외에도 보조 지역의 데이터에 대한 읽기 액세스를 구성해야 합니다. 스토리지 계정에 대한 복제 옵션을 변경하는 방법을 알아보려면 스토리지 계정 복제 방법 변경을 참조하세요.
이 예제에서는 BlobClientOptions
에서 GeoRedundantSecondaryUri 속성을 설정합니다. 이 속성을 설정하면 재시도 중에 GET
또는 HEAD
요청에 보조 URI가 사용됩니다. 보조 URI의 응답 상태가 404인 경우 이 상태 코드는 리소스가 아직 전파되지 않았을 수 있음을 나타내기 때문에 요청에 대한 후속 재시도에서는 보조 URI를 다시 사용하지 않습니다. 그렇지 않으면 후속 재시도는 주 URI와 보조 URI 간에 번갈아 가며 시도됩니다.
Uri secondaryAccountUri = new Uri($"https://{accountName}-secondary.blob.core.windows.net/");
// Provide the client configuration options for connecting to Azure Blob Storage
BlobClientOptions blobOptionsGRS = new BlobClientOptions()
{
Retry = {
Delay = TimeSpan.FromSeconds(2),
MaxRetries = 5,
Mode = RetryMode.Exponential,
MaxDelay = TimeSpan.FromSeconds(10),
NetworkTimeout = TimeSpan.FromSeconds(100)
},
// Set the secondary storage URI
GeoRedundantSecondaryUri = secondaryAccountUri
};
BlobServiceClient blobServiceClient = new BlobServiceClient(
accountUri,
new DefaultAzureCredential(),
blobOptionsGRS);
지역 복제를 사용하는 앱은 몇 가지 특정 디자인 고려 사항을 염두에 두어야 합니다. 자세한 내용은 지역 중복을 사용하여 고가용성 애플리케이션 설계를 참조하세요.
다음 단계
- 이 문서는 .NET용 Blob Storage 개발자 가이드의 일부입니다. 앱 빌드에서 개발자 가이드 문서의 전체 목록을 참조하세요.
- 다시 시도 정책에 대한 아키텍처 지침 및 일반적인 모범 사례는 일시적인 오류 처리를 참조하세요.
- 일시적인 오류에 대한 다시 시도 패턴을 구현하는 방법에 대한 지침은 다시 시도 패턴을 참조하세요.