次の方法で共有


Go を使用して再試行ポリシーを実装する

クラウドで実行されるアプリケーション、またはリモート サービスやリソースと通信するアプリケーションは、一時的な障害を処理できる必要があります。 これらのアプリケーションでは、ネットワーク接続の一時的な喪失、サービスまたはリソースがビジーのときの要求のタイムアウト、またはその他の要因により、障害が発生することがよくあります。 開発者は、安定性と回復性を向上させるため、一時的な障害を透過的に処理するようにアプリケーションを構築する必要があります。

この記事では、Go 用 Azure Storage クライアント モジュールを使用して、Azure Blob Storage に接続するアプリケーションの再試行ポリシーを構成する方法について説明します。 再試行ポリシーは、失敗した要求をアプリケーションが処理する方法を定義しており、アプリケーションのビジネス要件とエラーの性質に合わせて常に調整する必要があります。

再試行オプションを構成する

Blob Storage の再試行ポリシーはプログラムで構成され、さまざまなサービス要求やシナリオに再試行オプションを適用する方法を制御します。 たとえば、ユーザーの操作に基づいて要求を発行する Web アプリでは、応答性を高め、エラーが発生したときにユーザーに通知するために、再試行回数が少なく、遅延が短いポリシーを実装する場合があります。 または、バックグラウンドでバッチ要求を実行するアプリやコンポーネントでは、要求が正常に完了するための時間があるように、再試行回数を増やし、エクスポネンシャル バックオフ戦略を使用する場合があります。

次の表に、RetryOptions インスタンスで構成できるフィールドと、型、簡単な説明、変更しない場合の既定値を示します。 アプリのニーズに合わせて、これらのプロパティの値を事前に調整しておく必要があります。

プロパティ タイプ 説明 規定値
MaxRetries int32 省略可能。 エラーを生成する前に失敗した操作を再試行する最大回数を指定します。 0 未満の値は、1 回の試行と再試行なしを意味します。 3
TryTimeout time.Duration 省略可能。 HTTP 要求の 1 回の試行で許可される最大時間を示します。 有効にするには、0 より大きい値を指定します。 注: このフィールドを小さい値に設定すると、HTTP 要求のタイムアウトが早期に発生する可能性があります。 既定で無効になっています。
RetryDelay time.Duration 省略可能。 操作を再試行する前に使用する遅延の初期時間を指定します。 この値は、HTTP 応答に Retry-After ヘッダーが含まれていない場合にのみ使用されます。 遅延は、MaxRetryDelay で指定された最大値まで、再試行のたびに指数関数的に増加します。 0 未満の値は、再試行間の遅延がないことを意味します。 4 秒
MaxRetryDelay time.Duration 省略可能。 操作を再試行するまでに許容される最大遅延時間を指定します。 通常、値は RetryDelay で指定された値以上になります。 0 未満の値は、最大値がないことを意味します。 60 秒
StatusCodes []int 省略可能。 操作を再試行する必要があることを示す HTTP 状態コードを指定します。 値を指定すると、既定値が置き換えられます。 空のスライスを指定すると、HTTP 状態コードの再試行が無効になります。 408 - http.StatusRequestTimeout
429 - http.StatusTooManyRequests
500 - http.StatusInternalServerError
502 - http.StatusBadGateway
503 - http.StatusServiceUnavailable
504 - http.StatusGatewayTimeout
ShouldRetry func(*http.Response, error) bool 省略可能。 再試行ポリシーが要求を再試行する必要があるかどうかを評価します。 この関数を指定すると、HTTP 状態コードのリストとの比較と再試行ポリシー内のエラー チェックがオーバーライドされます。 ContextNonRetriable のエラーは、ShouldRetry を呼び出す前に引き続き評価されます。 *http.Responseerror のパラメーターは相互に排他的です。つまり、一方が nil の場合、もう一方は nil ではありません。 戻り値が true の場合は、再試行ポリシーを再試行する必要があることを意味します。

この記事のコード例を使用するには、次の import パスをコードに追加します。

import (
	"context"
	"time"

	"github.com/Azure/azure-sdk-for-go/sdk/azcore"
	"github.com/Azure/azure-sdk-for-go/sdk/azcore/policy"
	"github.com/Azure/azure-sdk-for-go/sdk/azidentity"
	"github.com/Azure/azure-sdk-for-go/sdk/storage/azblob"
)

次のコード例では、RetryOptions のインスタンスで再試行オプションを構成し、それを ClientOptions インスタンスに含めて、新しいクライアント オブジェクトを作成します。

options := azblob.ClientOptions{
	ClientOptions: azcore.ClientOptions{
		Retry: policy.RetryOptions{
			MaxRetries:    10,
			TryTimeout:    time.Minute * 15,
			RetryDelay:    time.Second * 1,
			MaxRetryDelay: time.Second * 60,
			StatusCodes:   []int{408, 429, 500, 502, 503, 504},
		},
	},
}

credential, err := azidentity.NewDefaultAzureCredential(nil)
handleError(err)

client, err := azblob.NewClient(accountURL, credential, &options)
handleError(err)

この例では、client から発行された各サービス要求は、RetryOptions 構造体で定義されている再試行オプションを使用します。 このポリシーは、クライアント要求に適用されます。 アプリのニーズに基づいて、サービス クライアントに対してさまざまな再試行戦略を構成できます。

  • 再試行ポリシーに関するアーキテクチャのガイダンスと一般的なベスト プラクティスについては、「一時的な障害の処理」をご覧ください。
  • 一時的な障害に対する再試行パターンの実装に関するガイダンスについては、「再試行パターン」をご覧ください。