再試行操作

注

コミュニティの関心グループが Yammer から Microsoft Viva Engage に移行されました。 Viva Engage コミュニティに参加し、最新のディスカッションに参加するには、「 Finance and Operations Viva Engage Community へのアクセスを要求する 」フォームに入力し、参加するコミュニティを選択します。

この記事では、アプリケーション プログラミング インターフェイス (API) 要求がサービスの保護 API 制限に達して制限された場合に実装できる再試行操作について説明します。

サービス保護 API の制限エラーが発生した場合、ユーザーからの新しい要求を処理できるまでの時間を示す値が提供されます。 Web API から 429 エラーが返された場合、応答ヘッダーには、ユーザーが要求を再送信するまでに待機する必要がある秒数を示す Retry-After 間隔が含まれます。

再試行後の間隔の後に再送信された要求は、他の受信要求と共に処理され、サーバーへの新しい要求であるかのように優先順位が付けられます。 再試行要求の優先順位は新しい要求よりも高く設定されません。

対話型アプリケーションの再試行

クライアントが対話型アプリケーションの場合は、要求の再試行中にサーバーがビジーであることを示すメッセージを表示します。 ユーザーが操作をキャンセルできるオプションを指定できます。 送信した前の要求が完了するまで、他の要求の送信をユーザーに許可しないでください。

非対話型アプリケーションの再試行

クライアントが対話型アプリケーションでない場合、一般的な方法は、要求を再度送信する前に、指定した間隔が経過するまで待機することです。 通常、この動作を実装するには、 Task.Delay または同等のメソッドを使用して、現在のタスクの実行を一時停止します。

再試行間隔

再試行間隔の期間は、前の 5 分間に含まれる操作の性質によって異なります。 要求が厳しくなるほど、サーバーの復旧にかかる時間は長くなります。

クライアント アプリケーションが最初の 429 応答を受信した後も要求要求を送信し続ける場合、 Retry-After 間隔は拡張され、共有リソースへの影響を最小限に抑えることができます。 この拡張機能により、個々の Retry-After 間隔が長くなるため、アプリケーションでは待機中に非アクティブな期間が長くなります。

要求の数を減らしてから、サービス保護 API の制限に達し始めるまで徐々にその数を増やすことで、可能な限り一貫したレートを目指します。 次に、5 分間の間で処理できる要求数をサーバーから確認できます。 この 5 分間に要求の最大数を制限し、徐々に増やすと、 再試行間隔 を低く抑えるのに役立ちます。 これにより、合計スループットを最適化し、サーバー リソースの急増を最小限に抑えることができます。

再試行操作の実装

次の例では、再試行間隔に指定された秒後に要求を再試行する方法を示します。 

if (!response.IsSuccessStatusCode) 
{ 
    if ((int)response.StatusCode == 429) 
    { 
        int seconds = 30; 
        //Try to use the Retry-After header value if it is returned. 
        if (response.Headers.Contains("Retry-After")) 
        { 
            seconds = int.Parse(response.Headers.GetValues("Retry-After").FirstOrDefault()); 
        } 
        Thread.Sleep(TimeSpan.FromSeconds(seconds)); 

        // Retry sending the request.
    } 
}
  • Last updated on