ACS Retry Guidelines (ACS の再試行のガイドライン)

  • [アーティクル]

更新日: 2015 年 7 月 6 日

適用先:Azure

Microsoft Azure Active Directory Access Control (Access Control サービスまたは ACS とも呼ばれます) では、クライアントがトークン要求を送信できるさまざまなトークン発行および管理エンドポイントがサポートされています。 このトピックでは、トークン要求に失敗した場合の再試行ロジックを実装するためのガイドラインを定義します。

エラー処理シナリオ

HTTP 500 番台のエラー コードを返すトークン要求の失敗は通常、再試行に応答します。 一部のシナリオでは、クライアントは ACS に対して自動要求を行うアプリケーションまたはサービスです。 WS-Federation プロトコルを使用する Web ベースのフェデレーションなど、その他のシナリオでは、クライアントは Web ブラウザーであり、エンド ユーザーは手動で操作を再試行する必要があります。 このトピックでは、クライアントがアプリケーションまたはサービスの場合のエラー処理シナリオについて説明します。

これらのシナリオは、次のとおりです。

再試行のガイドライン

以下のガイドラインでは、エラー処理シナリオにおける再試行ロジックの実装方法について説明します。

ガイドライン 1: HTTP 500 シリーズのエラー応答に基づいて再試行ロジックを実装する

ACS が HTTP 500 シリーズ エラーを返す場合は、再試行ロジックを強くお勧めします。 以下の一覧には、一般的な HTTP 番台のエラーの例が含まれています。

  • HTTP エラー 500 - 内部サーバー エラー

  • HTTP エラー 502 - ゲートウェイが無効

  • HTTP エラー 503 - サービス使用不可

  • HTTP エラー 504 - ゲートウェイ タイムアウト

個々の HTTP コードは再試行ロジックで列挙できますが、HTTP 500 番台のエラーが返される場合は再試行ロジックを呼び出すだけで十分です。

再試行ロジックは、ACS90005 などの ACS エラー コードではなく、HTTP 504 (外部サーバー タイムアウト) などの HTTP エラー コードによってトリガーする必要があります。 ACS エラー コードは情報提供のためのコードであり、変更される可能性があります。

通常、HTTP 400 番台のエラー コードが返されるときは、再試行ロジックは推奨されません。 ACS からの 400 番台の HTTP エラー応答コードは、要求が無効であり改訂する必要があることを意味します。 ただし、1 つ例外があります。エラー コード 429 ("要求が多すぎます") は、名前空間が長期にわたってトークン要求レート制限を超えたことを示します。 429 エラーの場合、管理者が名前空間ワークロードの配分を確認し、修正する時間を確保できるまで、バックオフ タイマーを指定した再試行で即時トークン要求バックログを解決できます。 詳細については、「 ACS サービスの制限事項」を参照してください。

ガイドライン 2: 再試行では、最適なフロー制御のためにバックオフ タイマーを使用する必要がある

クライアントは HTTP 500 番台のエラーを受け取った場合、要求を再試行するまで一定期間待機する必要があります。 最良の結果を得るために、後続の再試行ごとにこの時間を長くすることをお勧めします。 この方法により、一時的なエラーをすばやく解決しつつ、解決に時間がかかるネットワークまたはサーバーの一時的な問題に対する要求の処理率を最適化することができます。

たとえば、再試行 1 回目: 1 秒、再試行 2 回目: 2 秒、再試行 3 回目: 4 秒 (以降も同様) のように、インスタンスごとに再試行までの遅延時間を指数関数的に増やす、指数バックオフ タイマーを使用します。

再試行の回数と各再試行までの時間は、ユーザー エクスペリエンス要件に基づいて調整します。 ただし、最大で 5 回の再試行を 5 分の間に行うことをお勧めします。 タイムアウトによって発生したエラーは、解決に時間がかかります。

ガイドライン 3: アイテムを作成または削除する前に、アイテムが存在しないことを確認する

ACS 管理サービスで作成操作または削除操作 (新しい証明書利用者アプリケーションの作成やルールの削除など) を実行する場合、再試行ロジックは、操作を実行する前に項目が存在するかどうかを照会する必要があります。サーバー応答の配信中に発生する一時的なネットワーク障害など、状況によっては、クライアントがエラー応答を取得した場合でも作成または削除操作が成功することがあります。

作成操作が項目の有無を確認せずに再試行されると、重複する項目が作成される場合があります。 また、項目が一意でなければならない場合、システムが HTTP 400 エラーを返すことがあります。

削除操作が項目の有無を確認せずに再試行されると、項目が見つからない場合にシステムが HTTP 400 エラーを返すことがあります。

参照

概念

ACS エラー コード
ACS サービスの制限事項
ACS の管理サービス
方法: OAuth WRAP プロトコルを使用して ACS からトークンを要求する
コード サンプル: OAuth 2.0 証明書認証
ACS ガイドラインの索引