アプリケーションワークロードのレート制限を最適化
API スロットリングを管理し、アプリケーション内の SP-API の使用を最適化します。
販売パートナーAPI(SP-API)アプリケーションを設計するときは、APIごとのリソースレート制限を考慮する必要があります。Selling Partner API では、可用性を維持し、個々の API が過負荷にならないように、各販売パートナーの API ごとのリソース割り当てが維持されます。
これらのレート制限を超えると、SP-APIは以下を返します 429 Too Many Requests
エラーが発生し、通話が制限されます。過度の API スロットリングは、ジョブの失敗、遅延、運用の非効率性につながり、最終的には組織に時間と費用がかかります。このようなエラー応答を受け取った場合は、失敗したリクエストをレート制限に準拠した方法で再送信できます。
このガイドでは、API スロットリングを効果的に管理し、SP-API アプリケーションのパフォーマンスと信頼性を最適化するのに役立つ以下の戦略の概要を説明します。
For comprehensive guidance on best practices across various aspects of SP-API integration, refer to the SP-API Well-Architected Guidance playlist on the Amazon SP-API Developer University channel.
レート制限の確認と順守について
レート制限を確認して遵守する方法については、次のガイダンスを確認してください。
レート制限を確認
Review the usage plan for each SP-API operation in the documentation. To learn how to find the usage plan, refer to How to find your usage plan.
文書化された制限を API レスポンスのレート制限ヘッダーと比較してください。レスポンスヘッダーは HTTP ステータスコード 20x、400、404 で使用できます。スロットリングを回避するには、これらの制限内にとどまるようにアプリケーションを設計してください。
To learn more about usage plans and how the SP-API rate limiting algorithm works, refer to Usage Plans and Rate Limits.
エラー監視および警告システムのセットアップ
API のレート制限を順守するには、エラーの発生を監視して警告する効果的なシステムを設定することが重要です。このプロセスには通常、以下のステップが含まれます。
- API レスポンスをログに記録する: ステータスコード、ヘッダー、エラーメッセージを含む完全な API レスポンスデータをキャプチャして保存することで、エラーの分析と分類が可能になります。
- エラーを分類: HTTP ステータスコードに基づいて、ログに記録されたエラーを関連するバケットに整理します。たとえば、400 レベルのクライアントエラーは、400 件の無効な入力、403 件の認証問題、404 件のリソースが見つかりません、429 件のレート制限違反などのバケットに分類できます。
- エラーダッシュボードの作成: API オペレーションごとのエラー率とエラータイプを一元化されたダッシュボードで視覚化することで、問題のある領域をすばやく特定できます。
- アラート閾値の設定: エラータイプごとに適切なしきい値を定義し、エラー率がしきい値を超えたときに事前に通知されるようにアラートを設定します。
If you use AWS services, you can implement this best practice by using Amazon CloudWatch:
- クラウドウォッチログ: 詳細な API レスポンスデータをキャプチャして保存します。
- クラウドウォッチメトリクスフィルター: カスタムメトリクスを作成して、ステータスコードに基づいてさまざまなエラータイプをカウントします。
- CloudWatch alarms: Monitor the error metrics and trigger notifications (for example, Amazon Simple Notification Service) when thresholds are breached.
スパイクトラフィックを回避
API リクエストを時系列で均等に分散することで、特定の操作への呼び出しが集中し、その後にアクティビティが最小限になるのを防ぐことができます。このような不均一なスパイクにより、さらに 429 エラーが発生しますが、時間の経過とともにトラフィックを分散させることで回避できます。
レートリミッターを実装して大量のトラフィックを管理し、API ごとのリソース制限に基づいて 1 秒あたり N 回のリクエストを許可できます。レートリミッターを使用すると、長期にわたって一貫した呼び出しパターンが維持され、トラフィックのピークが緩和され、API の使用が均一になります。レートリミッターの各 API のガイドラインとして、API ごとのレート制限を使用してください。
For a step-by-step code example that uses the Selling Partner API Authentication/Authorization Library to implement a rate limiter, refer to the following sample code.
リトライとバックオフの手法の実装
ワークロードへの影響を回避し、アプリケーションの信頼性を高めるために、次の手法を積極的に実装してください。
- リトライ: 自動再試行ロジックを実装します。リトライ設定は、リクエスト間の遅延とキューイングを少し加えることで設定できます。
- エクスポネンシャル・バックオフ: エクスポネンシャルバックオフアルゴリズムを使用してフロー制御を改善し、エラーレスポンスを連続して再試行するまでの待ち時間を徐々に長くします。指数関数は急速に増加するため、指数バックオフではバックオフ時間が非常に長くなる可能性があります。最大遅延間隔と最大再試行回数を設定し、操作やその他のローカル要因に基づいて調整できます。
- Jitter: Retries can be ineffective if all clients retry at the same time. To avoid this problem, use jitter, which is a random amount of time before making or retrying a request to help prevent large bursts by spreading out the arrival rate. Most exponential back-off algorithms use jitter to prevent successive collisions. For more information, refer to Exponential Backoff and Jitter.
API リクエストの数を減らす
以下のセクションでは、イベントベースのワークロード、バッチオペレーション、および一括操作を使用して API リクエストの数を減らす方法について説明します。
イベントベースのワークロード
Monitor notifications by using the Selling Partner API for Notifications and perform actions based on specific conditions. With the Selling Partner API for Notifications, you can create a destination to receive notifications, subscribe to notifications, delete notification subscriptions, and so on. Instead of polling for information, your application can receive information directly from Amazon when an event invokes a notification to which you subscribe.
There are many notification types available for your application to leverage. For more information, refer to the Notifications API v1 Use Case Guide.
バッチオペレーション
1 回のリクエストでアイテムのバッチのデータを取得します。SP-API は一連のバッチ操作をサポートしています。これらの操作は 1 回のリクエストのバッチに対して 1 回の呼び出しと同じアクションを実行します。1 回の API 呼び出しで、1 回の API 呼び出しで適切な数のリクエスト (大抵は 20) を送信できます。
SP-APIは現在、以下のユースケースのバッチ操作をサポートしています。
- カタログ API を使用して商品を検索する
- オファーまたは価格情報の取得
- 商品の手数料見積もりの取得
一括操作
1 回の API リクエストで一括データをアップロードおよびダウンロードできます。
To upload data in bulk, you can use the Feeds API. There are feeds for a wide variety of use cases, such as creating listings, managing inventory and prices, acknowledging orders, and so on. For a list of available feed types, refer to Feed Type Values.
To download data in bulk, you can use the Reports API or the Data Kiosk API. The Reports API provides reports for a variety of use cases, including monitoring inventory, tracking orders for fulfillment, getting tax information, tracking returns and seller performance, managing a selling business with Fulfillment by Amazon, and so on. For details about Reports API operations and associated data types and schemas, refer to the Reports API reference. For available report types, refer to Report Type Values.
The Data Kiosk API supports GraphQL query operations for dynamic report capabilities. GraphQL is a query language for APIs that enables you to request and receive the data that you need in a single request. Data Kiosk's GraphQL-based dynamic reporting suite helps you generate custom GraphQL queries to access bulk data from Amazon datasets. For details, refer to Data Kiosk Schema Explorer User Guide.
その他のベスト・プラクティス
他にも以下のベストプラクティスを念頭に置いてください。
- 使用状況を監視し、アプリケーションの成長に応じてスケーリングします。
- コードを最適化して不要な API 呼び出しを排除してください。
- Cache frequently used data to reduce the need for repeated API requests. You can cache data on your servers using Object-level storage like Amazon S3. You can also save relatively static information in a database or serialize it in a file.
- キューに入っている次のジョブの実行を待つ間、キュー内のSP-APIリクエストを調整して他の処理タスクを実行します。
Updated 23 days ago