Azure Data Manager for Agriculture の API スロットリング ガイダンス
スロットリングにより、リソースの過剰使用を防ぐため、一定期間内のサービスへの要求の数が制限されます。 Azure Data Manager for Agriculture での REST API のスロットリングにより、サービス API を呼び出すお客様は、一定の期間内でより一貫したパフォーマンスを得られます。
Azure Data Manager for Agriculture は、大量の要求を処理できます。 一部のお客様から処理しきれない量の要求が発生した場合は、すべてのお客様の最適なパフォーマンスと信頼性を確保する上で調整が役立ちます。
スロットルの制限は、選択されたバージョンと、お客様が使用している製品の機能によって異なります。 Azure Data Manager for Agriculture は、次の 2 つの異なるバージョンをサポートしています。
- Standard: 一般的にお勧めするバージョンです。
- Basic: プロトタイプ作成要件に適しています。
これらの制限は、トラフィックの急激な増加に対応するため、3 つの時間枠 (1 分ごと、5 分ごと、1 か月ごと) 内で運用されます。
この記事では、制限に達する前に残っている要求数を追跡する方法と、制限に達したときに対応する方法について説明します。 スロットルの制限は、これらの API に適用されます。
API の分類
Azure Data Manager for Agriculture API は、主に次の 3 つのカテゴリに分類されます。
- 書き込み操作: データを変更するために、
PATCH、POST、DELETEなどの REST API メソッドを使用する API。 - 読み取り操作: メソッド型
POSTの検索 API など、データを取得するために REST API メソッド型GETを使用する API。 - 長時間実行ジョブ操作: REST API メソッド型
PUTを使用する長時間実行の非同期ジョブ API。
次の表で説明するように、利用可能なすべてのクォータ ユニット数は、これらのカテゴリ間で共有されます。 たとえば、書き込み操作にすべてのクォータを使用すると、他の操作のクォータは残りません。 各操作では特定のクォータ ユニットが消費されます。これは、さらに使用する場合のクォータ残量の追跡に役立ちます。
| 操作 | 各要求のユニット コスト |
|---|---|
| 書き込み | 5 |
| 読み込み | 1 1 |
| 長時間実行ジョブ: ソリューション推論 | 5 |
| 長時間実行ジョブ: ファーム操作 | 5 |
| 長時間実行ジョブ: イメージのラスター化 | 2 |
| 長時間実行ジョブ: エンティティのカスケード削除 | 2 |
| 長時間実行ジョブ: 気象インジェスト | 1 |
| 長時間実行ジョブ: 衛星インジェスト | 1 |
1 複数のアイテムを取得する場合、応答で返されるアイテムごとに追加のユニット コストが考慮されます。
Basic バージョンの API 制限
次の表は、Basic バージョンのカテゴリごとに使用可能なユニット数の合計を一覧表示したものです。
| 操作 | 調整時間枠 | 各時間枠の後にユニット数がリセットされます |
|---|---|---|
| 書き込み/読み取り | 1 分ごと | 25,000 |
| 書き込み/読み取り | 5 分ごと | 100,000 |
| 書き込み/読み取り | 1 か月ごと | 5,000,000 |
| 長時間実行ジョブ | 5 分ごと | 1000 |
| 長時間実行ジョブ | 1 か月ごと | 100,000 |
Standard バージョンの API 制限
Standard バージョンは、Basic バージョンと比較して、月あたりの API クォータが 5 倍になります。 その他のクォータ制限は変更されません。
次の表は、Standard バージョンのカテゴリごとに使用可能なユニット数の合計を一覧表示したものです。
| 操作 | 調整時間枠 | 各時間枠の後にユニット数がリセットされます |
|---|---|---|
| 書き込み/読み取り | 1 分ごと | 25,000 |
| 書き込み/読み取り | 5 分ごと | 100,000 |
| 書き込み/読み取り | 1 か月ごと | 25,000,000 1 |
| 長時間実行ジョブ | 5 分ごと | 1000 |
| 長時間実行ジョブ | 1 か月ごと | 500,000 1 |
1 この制限は Basic バージョンの制限の 5 倍です。
エラー コード
上限に達すると、HTTP 状態コード 429 Too many requests が返されます。 応答には Retry-After 値が含まれます。これは、次の要求を送信する前にアプリケーションの待機 (またはスリープ) が必要な秒数を指定します。
この再試行値が経過する前に要求を送信した場合、要求は処理されず、新しい再試行値が返されます。 指定された時間が経過すると、Azure Data Manager for Agriculture にもう一度要求を行うことができます。 TCP 接続を確立しようとしたり、異なるユーザー認証方法を使用したりしても、制限は各テナント固有であるため、これらの制限を回避することはできません。
よく寄せられる質問
割り当てられた API クォータを 1 分あたりの時間枠内で書き込み操作のためにすべて使い果たした場合、同じ時間枠内で読み取り操作の要求を正常に行うことはできますか?
クォータ制限は、一覧表示された操作カテゴリ間で共有されます。 書き込み操作のためにすべてのクォータを使用すると、他の操作のためのクォータは残りません。 この記事では、各操作で消費される具体的なクォータ ユニット数について詳しく説明します。
特定の時間枠で許可された要求の合計数を計算するにはどうすればよいですか?
成功した API 要求の合計許容数は、プロビジョニングしたバージョンと要求を行う時間枠によって異なります。
たとえば、Standard バージョンでは、1 分の時間内に 25,000 (時間経過ごとにリセットされるユニット数) / 5 (各要求のユニット コスト) = 5,000 の書き込み API を作成できます。 あるいは、4,000 回の書き込み操作と 5,000 回の読み取り操作を組み合わせて使用することもでき、その場合、4,000 * 5 + 5,000 * 1 = 25,000 の合計消費ユニット数になります。
同様に、Basic バージョンでは、1 か月間に 5,000,000 (時間枠ごとにリセットされるユニット数) / 1 (要求ごとのユニット数) = 5,000,000 の読み取り操作 API を実行できます。
顧客は最大何件のセンサー イベントをインジェストできますか?
このシステムでは、1 時間あたり最大 100,000 件のイベントをインジェストできます。 新しいイベントは継続的に承認されますが、処理が遅れる場合があります。 延期期間は、これらのイベントがインジェストと並行してリアルタイムのエグレス シナリオに対してすぐに利用できないことを意味する場合があります。