Dynamic Media OpenAPIとAsset Gateway:API レート制限の理解と解決
リクエストパターンが動的レート制限を超えると、大量のAPI アクティビティがHTTP 429 エラーを返す場合があります。 この問題は一般的に、バーストトラフィック、繰り返しポーリング、または各呼び出しが個別にカウントされるマルチステップワークフローが原因で発生しますが、キャッシュは更新が表示されるときに遅延する可能性があります。 解決は、ログのスロットリングの確認、不要な要求の削減、キャッシュ動作の尊重、および指数関数的なバックオフの適用に焦点を当てます。 リクエストパターンと再試行動作が調整された後、安定した応答が返されます。
説明 description
環境：
- API ベースのアセット取得ワークフロー
- メタデータ取得ワークフロー
- アセット配信またはゲートウェイとの統合
- 繰り返しまたは大量のAPI リクエストを行うクライアント
問題/症状
- API エンドポイントは、間欠的なHTTP 429 Too Many Requests応答を返します。これは、アプリケーションログまたは監視データで確認でき、影響を受けるエンドポイントに関連付けることができます。
- この問題は、バーストトラフィックやその他の大量のリクエスト期間中に顕著になり、リクエストの読み込み量が多い場合にスロットリングが発生することを示します。
- 1つの操作で、検索、メタデータ検索、アップロード開始、アップロード送信など、複数のカウントされたAPI リクエストが生成される可能性があるため、マルチステップのワークフローが大きな影響を受ける可能性があります。
- ポーリング、再試行、キャッシュされた応答の再利用の失敗など、繰り返しクライアントアクティビティを実行すると、リクエスト量が増加し、スロットリングが発生する可能性があります。
- キャッシュされた応答は最大10分間保持できるため、アセットまたはコンテンツの更新が遅れて表示される可能性があります。この動作は、
Cache-Control: max-age=600などの応答ヘッダーを通じて検証できます。 - この場合、更新されたコンテンツは1 ～ 10分後にのみ表示される可能性があります。これは、個別のAPI障害ではなく、キャッシュレイヤーの遅延を示します。
根本原因：
APIは、1秒あたりの固定リクエストのしきい値ではなく、動的な読み込みベースのレート制限を使用します。 トラフィックの急増、最適化されていないポーリング、マルチステップのアップロードまたはクエリフローにより、リクエストボリュームが健全な制限やトリガーのスロットリングを超える可能性があります。 さらに、応答はCache-Control: max-age=600でキャッシュされる可能性があるため、ダウンストリームキャッシュは、オリジンの更新後も古いデータを引き続き提供できます。
解決策 resolution
スロットリングを減らし、回復を確認するには、次の手順を使用します。
- アプリケーションログまたはAPI モニタリングを確認して、HTTP 429 Too Many Requests応答を特定します。 予想される結果は、影響を受けるAPI エンドポイントに関連付けられたスロットリングの明確な証拠です。 応答が同じワークフローで繰り返し可能であり、無関係な要求に分離されていないことを確認します。
- アップロードまたはクエリのワークフローで、マルチステップのリクエストパターンを調べます。 期待される結果は、各呼び出しが全体的なリクエスト量に別々に貢献するフローの識別です。 検索、メタデータ検索、アップロード開始、アップロード送信などのリクエストシーケンスがすべてカウントされていることを確認します。
Cache-Control: max-age=600を含む、再試行動作と応答キャッシュを確認してください。 期待される結果は、削除、遅延、またはキャッシュできる繰り返し呼び出しを見つけることです。 クライアントがキャッシュ時間を尊重し、同じデータをすぐに再要求しないことを確認します。- 可能な限り応答をキャッシュし、メタデータの取得や呼び出しの重複を繰り返さないようにすることで、リクエストの量を削減します。 期待される結果は、API スループットが低下し、スロットルされたリクエストが少なくなることです。 ログを確認するかモニタリングすることで、リクエスト量が減少し、429件の応答が少ないことを確認し、変更を検証します。
- 更新を確認する際にキャッシュの動作を検証します。 予想される結果は、更新されたコンテンツが即座ではなく通常のキャッシュ伝播後に表示される可能性があることを認識しています。 ブラウザーのキャッシュをクリアし、リクエストを再試行し、更新されたコンテンツが予想される1 ～ 10分のキャッシュウィンドウ内に表示されることを確認して、これを確認します。
- 429応答の後に再試行する前に、クライアントがプログレッシブに長く待機するように、指数関数的なバックオフを適用します。 期待される結果は、スロットルイベントの頻度が低くなります。 再試行変更をデプロイした後にログを監視し、429件の応答が繰り返し低下することを確認して、改善を確認します。
- トラフィックが常にサービス制限に近づいている場合は、リクエストのバッチ処理またはワークフロー設計の変更によって項目別の呼び出しを減らすことができるかどうかを確認します。 期待される結果は、通常のトラフィック下でより安定した応答動作です。 リクエストパターンが通常の使用時に安定し、トリガーの繰り返しスロットリングが発生しないことを確認します。
- リクエストの最適化後もスロットリングが継続する場合は、サポートに連絡する前に、タイムスタンプ、影響を受けるエンドポイント、リクエストと応答のヘッダー、推定リクエスト率、およびキャッシュ戦略の詳細を収集します。 予想される結果は、より迅速な調査をサポートする完全な技術的記録です。 収集した情報が、スロットリングされたリクエストと、そのリクエストが発生する条件を反映していることを確認します。
リクエスト量を削減した後、HTTP 429 Too Many Requests応答が続き、キャッシュが期待どおりに機能し、再試行の動作が更新され、同じAPI ワークフローに対してスロットリングが繰り返し可能な場合は、Adobe サポート にチケットを送信し、タイムスタンプ、影響を受けるエンドポイント、リクエストと応答のヘッダー、推定リクエスト率、およびの詳細トラブルシューティング中中にキャッシュ実行方法を収集含します。