View a markdown version of this page

Amazon Route 53 API リクエストのスロットリング - Amazon Route 53
スロットリングの適用方法リクエストレートトークンバケットサイズとリフィルレートスループット制限の変更API スロットリングをモニタリングする再試行とエクスポネンシャルバックオフ制限の引き上げのリクエストAPI スロットリングのベストプラクティス

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Amazon Route 53 API リクエストのスロットリング

重要

Amazon Route 53 は API スロットリング動作を更新しました。更新には、1 秒あたりのリクエスト数の制限の引き上げと、変更ベースのスロットリングの導入が含まれます。このページでは、更新された制限について詳しく説明します。

Amazon Route 53 は API リクエストをアカウント単位でスロットリングし、サービスの安定性を維持し、すべてのお客様に公平な使用を確保します。Route 53 は 2 つの独立した制限を適用します。

  • リクエストレート: 1 秒あたりの API リクエストの数。

  • 変更スループット: DNS データを変更する API アクション全体で集計された、1 秒あたりの個々の DNS レコードの変更の数。

リクエストはどちらの制限でもスロットリングできます。リクエストがスロットリングされると、Amazon Route 53 は HTTP 400 エラー () を返しますBad request。レスポンスヘッダーには、Throttling の値を持つ Code 要素と、Rate exceeded の値を持つ Message 要素も含まれています。

スロットリングの適用方法

Amazon Route 53 はトークンバケットアルゴリズムを使用します。各制限には、トークンの最大数を保持するバケットがあります。各リクエスト (リクエストレート制限の場合) または各変更 (変更スループット制限の場合) は、該当するバケットからトークンを削除します。バケットは、最大容量まで毎秒固定レートで補充されます。バケットがすでに満杯になったときにリフィルトークンが到着した場合、Route 53 はトークンを破棄します。

2 つの値が各バケットを記述します。

  • バケットの最大容量はバーストです。バケットがいっぱいになると、Route 53 が一度に吸収できるリクエストまたは変更の数です。

  • バケットリフィルレートは、1 秒あたりのリクエスト数または変更数を無期限に維持できる持続レートです。

追加時にリフィルトークンを使用できます。バケットが完全にリフィルするのを待つ必要はありません。

リクエストレートトークンバケットサイズとリフィルレート

Route 53 は、次の 2 つのレベルでリクエストレートスロットリングを適用します。

  • アカウントレベル: アカウントからのすべての Amazon Route 53 API リクエストは、1 つのバケットから取得されます。

  • アカウントとオペレーションレベル: 各 API アクションには独自のバケットもあります。

リクエストは両方のバケットからトークンを消費し、いずれかのバケットが空の場合にスロットリングされます。以下のアクションには、デフォルトのリクエストレート制限が異なります。

API アクションあたりのリクエストレート制限
API アクション バケットの最大容量 バケットリフィルレート
すべての Amazon Route 53 API アクションの組み合わせ (アカウントレベル) 50 10
以下にリストされていない単一の API アクション (アクションごとのデフォルト) 50 10
AssociateVPCWithHostedZone 20 5
ChangeCidrCollection 40 5
CreateCidrCollection 40 5
CreateHealthCheck 50 0.5
CreateHostedZone 40 2
CreateReusableDelegationSet 40 2
CreateTrafficPolicyInstance 1 1
DeleteCidrCollection 40 5
DeleteHealthCheck 15 3
DeleteHostedZone 40 5
DeleteReusableDelegationSet 40 5
DeleteTrafficPolicyInstance 1 1
DisassociateVPCFromHostedZone 10 5
GetHealthCheckLastFailureReason 4 1
GetHealthCheckStatus 4 1
UpdateHealthCheck 50 5
UpdateTrafficPolicyInstance 1 1

Amazon Route 53 API アクションの完全なリストについては、「Amazon Route 53 API リファレンス」の「アクション」を参照してください。 Amazon Route 53

CreateHealthCheck リクエストでオプションで指定するパラメータです。

CreateHealthCheck リクエストは、 AWS アカウント ごとに 2 秒に 1 回送信できます。これは、前の表に示す 1 秒あたりのリフィルレート 0.5 リクエストに対応します。

スループット制限の変更

リクエストレート制限に加えて、DNS データを変更する API アクションには、変更スループット制限が適用されます。この制限では、リクエストの数ではなく、リクエストによって行われた DNS レコードの変更の数に基づいて枯渇する別のトークンバケットを使用します。変更スループットは API アクションごとではなく AWS アカウント、 ごとに制限されます。以下のすべてのアクションは、最大容量が 1,500 の変更 (バースト) で、1 秒あたり 100 の変更 (持続) で補充される 1 つのバケットから取得されます。

変更は次のようにカウントされます。

オペレーションごとに消費されるトークン
運用 消費されたトークン
ChangeResourceRecordSets ごとに 1CREATE、 ごとに 1DELETE、 ごとに 2 UPSERT
AssociateVPCWithHostedZone 2
DisassociateVPCFromHostedZone 2
CreateHostedZone 2
DeleteHostedZone 2

他のすべての Amazon Route 53 API アクションは、変更スループットトークンを消費せず、リクエストレートによってのみ制限されます。

例: 1,000 個のトークンを消費する 1,000 個の変更 (バースト) を含む 1 つのリクエストを送信できます。バースト後、バケットは 1 秒あたり 100 トークンで補充されます。1 秒あたり 100 件の変更を送信し続けると、そのレートを無期限に維持できます。1 秒あたり 500 回の変更を維持しようとすると、バケットは枯渇し、それ以降のリクエストは補充されるまでスロットリングされます。

API スロットリングをモニタリングする

Amazon Route 53 API の使用状況をモニタリングするには、アプリケーションログで HTTP 400 レスポンスを監視するか、CloudWatch メトリクスを介して API の使用状況を追跡します。スロットリングエラーが発生すると、リクエストが前のセクションで説明した制限のいずれかを超えています。

再試行とエクスポネンシャルバックオフ

API リクエストをポーリングまたは再試行するときは、エクスポネンシャルバックオフアルゴリズムを使用してリクエスト間のスリープ間隔を計算することをお勧めします。エクスポネンシャルバックオフでは、連続するエラーレスポンスの再試行間隔が徐々に長くなります。最大遅延間隔と最大再試行回数を実装し、連続する衝突を防ぐためにジッター (ランダム遅延) を追加することを検討してください。詳細については、「 ビルダーライブラリ」の「タイムアウト、再試行、ジッターによるバックオフ」を参照してください。 AWS

各 AWS SDK は自動再試行ロジックを実装します。これには、スロットリングに応じてクライアント側のリクエストレートを調整するアダプティブ再試行モードが含まれます。これらの制限に定期的に近づくワークロードの場合は、アダプティブ再試行を有効にすることを検討してください。詳細については、「AWS SDK とツールのリファレンスガイド」の「再試行動作」を参照してください。

制限の引き上げのリクエスト

AWS サポートを通じて、API リクエストレートまたは変更スループット制限の引き上げをリクエストできます。引き上げをリクエストするには:

  • AWS サポートセンターを開きます。

  • ケースを作成し、サービス制限の引き上げを選択します。

  • Limit type で、Route 53 を選択します。

  • 現在の使用状況と必要な制限を指定します。

API スロットリングのベストプラクティス

  • リクエストレートとバッチサイズのバランス: リクエストレート制限によって調整されている場合は、リクエストごとにより多くの変更を送信します。変更スループット制限によって調整されている場合は、合計変更率を減らします。非常に小さいバッチも非常に大きいバッチも、単独では最適ではありません。

  • アトミック性にバッチ処理を使用する: 1 つのChangeResourceRecordSetsリクエストのすべての変更はアトミックに適用されるため、成功または失敗します。

  • 時間の経過とともに変更を分散する: 大きなバッチを同時に送信するのではなく、数秒にわたって変更を均等に分散します。

  • 持続的なスループットではなく、時折の急増に頼る: バースト容量は正当なトラフィックの急増に対応します。持続的な運用上限ではありません。

  • エクスポネンシャルバックオフで再試行: HTTP 400 レスポンスを受け取ったら、試行ごとに増加する遅延後に再試行します (「」を参照再試行とエクスポネンシャルバックオフ)。

  • リクエスト制限の事前引き上げ: ワークロードの増加が予想される場合は、制限に達する前に引き上げをリクエストします (「」を参照制限の引き上げのリクエスト)。

より広範な Amazon Route 53 のガイダンスについては、「」を参照してくださいAmazon Route 53 のベストプラクティス。