# REL05-BP02 リクエストのスロットル
<a name="rel_mitigate_interaction_failure_throttle_requests"></a>

リクエストを制限して、予想外の需要の増加によるリソースの枯渇を緩和します。スロットリングレートを下回るリクエストは処理され、定義された制限を超えるリクエストは拒否され、リクエストがスロットリングされたことを示すメッセージが返されます。

 **期待される成果:** 突然のカスタマートラフィックの増加、フラッディング攻撃、または再試行ストームによる大量のスパイクは、リクエストスロットリングによって軽減され、サポートされているリクエスト量の通常の処理をワークロードが継続できるようになります。 

 **一般的なアンチパターン:** 
+  API エンドポイントのスロットルは実装されていないか、予想される量を考慮せずにデフォルト値のままになっています。 
+  API エンドポイントは負荷テストされておらず、スロットリング制限もテストされていません。 
+  リクエストのサイズや複雑さを考慮せずにリクエストレートをスロットリングできます。 
+  最大リクエストレートまたは最大リクエストサイズをテストしますが、両方を一緒にテストするわけではありません。 
+  リソースは、テストで設定したのと同じ制限にプロビジョニングされません。 
+  アプリケーション (A2A) API コンシューマーへの適用を目的とした使用プランは設定も検討もされていません。 
+  水平方向にスケーリングするキューコンシューマーには、最大同時実行設定は設定されていません。 
+  IP アドレスごとのレート制限は実装されていません。 

 **このベストプラクティスを活用するメリット:** スロットル制限を設定したワークロードは、予期しない量のスパイクが発生しても、正常に動作し、受け入れられたリクエストの負荷を正常に処理できます。API やキューへのリクエストの急なスパイクや持続的なスパイクはスロットリングされ、リクエスト処理リソースを使い果たすことはありません。レート制限は、単一の IP アドレスまたは API コンシューマーからの大量のトラフィックがリソースを使い果たして他のコンシューマーに影響を与えないように、個々のリクエスタを制限します。 

 **このベストプラクティスを活用しない場合のリスクレベル:** 高 

## 実装のガイダンス
<a name="implementation-guidance"></a>

 サービスは、既知のキャパシティのリクエストを処理するように設計する必要があります。このキャパシティは、負荷テストによって確立できます。リクエストの到着率が制限を超えると、適切なレスポンスからリクエストがスロットリングされたことが通知されます。これにより、コンシューマーはエラーを処理して後で再試行できます。 

 サービスにスロットリングの実装が必要な場合は、トークンがリクエストにカウントされるトークンバケットアルゴリズムの実装を検討してください。トークンは 1 秒あたりのスロットルレートで補充され、リクエストごとに 1 つのトークンで非同期に空になります。 

![\[トークンバケットアルゴリズムを説明する図。\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2023-04-10/framework/images/token-bucket-algorithm.png)


 

 [Amazon API Gateway](https://aws.amazon.com/api-gateway/) は、アカウントとリージョンの制限に従ってトークンバケットアルゴリズムを実装し、使用プランを使用してクライアントごとに構成できます。さらに、[Amazon Simple Queue Service (Amazon SQS)](https://aws.amazon.com/sqs/) および [Amazon Kinesis](https://aws.amazon.com/kinesis/) は、リクエストをバッファリングしてリクエストレートをスムーズにし、対応可能なリクエストのスロットリングレートを高くすることができます。最後に、 [AWS WAF](https://aws.amazon.com/waf/) を使用してレート制限を実装し、異常に高い負荷を発生させる特定の API コンシューマーを制限します。 

## 実装手順
<a name="implementation-steps"></a>

 API のスロットリング制限を使用して API Gateway を設定し、制限を超えると `「429 Too Many Requests」(429 リクエストが多すぎます) ` エラーを返すことができます。AWS AppSync および API Gateway エンドポイントで AWS WAF を使用すると、IP アドレスごとにレート制限を有効にできます。さらに、システムが非同期処理に対応できる場合は、メッセージをキューまたはストリームに入れてサービスクライアントへの応答を高速化できます。これにより、より高いスロットルレートにバーストできます。 

 非同期処理では、Amazon SQS を AWS Lambda のイベントソースとして設定すると、 [最大同時実行数を設定して、](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#events-sqs-max-concurrency) ワークロードやアカウント内の他のサービスに必要な、使用可能なアカウントの同時実行クォータを高いイベント率が消費することを回避できます。 

 API Gatewayトークンバケットのマネージド実装を提供していますが、API Gateway を使用できない場合は、サービス用のトークンバケットの言語固有のオープンソース実装 (「参考文献」の関連例を参照) を利用できます。 
+  リージョンごとのアカウントレベル、ステージごとの API、使用プランレベルごとの API キーでの [API Gateway スロットリング制限](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) を理解して設定します。 
+  以下の [AWS WAF レート制限ルールを](https://aws.amazon.com/blogs/security/three-most-important-aws-waf-rate-based-rules/) API Gateway および AWS AppSync エンドポイントに適用して、フラッドから保護し、悪意のある IP をブロックします。A2A コンシューマー向けの AWS AppSync API キーにレート制限ルールを設定することもできます。 
+  AWS AppSync API のレート制限よりも高度なスロットリング制御が必要かどうかを検討し、必要な場合は AWS AppSync エンドポイントの前に API Gateway を設定します。 
+  Amazon SQS キューが Lambda キューコンシューマーに対してアクティブとして設定されている場合は、 [最大同時実行数を](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#events-sqs-max-concurrency) サービスレベル目標を達成するのに十分な処理を行うが、他の Lambda 関数に影響を与える同時実行数の制限を消費しない値に設定します。Lambda でキューを使用する場合は、同じアカウントおよびリージョン内の他の Lambda 関数に予約された同時実行を設定することを検討してください。 
+  API Gateway と Amazon SQS または Kinesis へのネイティブサービス統合を使用して、リクエストをバッファリングします。 
+  API Gateway を使用できない場合は、言語固有のライブラリを調べて、ワークロード用のトークンバケットアルゴリズムを実装してください。サンプルセクションを確認して、適切なライブラリを見つけるために独自の調査を行ってください。 
+  設定する予定の、または引き上げを許可する予定の制限をテストし、テストした制限を文書化します。 
+  テストで設定した上限を超えて制限を増やさないでください。制限を増やす場合は、増やす前に、プロビジョニングされたリソースが既にテストシナリオのものと同等かそれ以上であることを確認してください。 

## リソース
<a name="resources"></a>

 **関連するベストプラクティス:** 
+  [REL04-BP03 継続動作を行う](rel_prevent_interaction_failure_constant_work.md) 
+  [REL05-BP03 再試行呼び出しを制御および制限する](rel_mitigate_interaction_failure_limit_retries.md) 

 **関連するドキュメント:** 
+  [Amazon API Gateway: スループット向上に向けた API リクエストのスロットリング](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) 
+ [AWS WAF: ルートベースのルールステートメント ](https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-statement-type-rate-based.html)
+ [ Amazon SQS をイベントソースとして使用する場合の AWS Lambda の最大同時実行数の導入 ](https://aws.amazon.com/blogs/compute/introducing-maximum-concurrency-of-aws-lambda-functions-when-using-amazon-sqs-as-an-event-source/)
+ [AWS Lambda: 最大同時実行数 ](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#events-sqs-max-concurrency)

 **関連サンプル:** 
+ [ 最も重要な 3 つの AWS WAF レートベースのルール ](https://aws.amazon.com/blogs/security/three-most-important-aws-waf-rate-based-rules/)
+ [ Java Bucket4j ](https://github.com/bucket4j/bucket4j)
+ [ Python トークンバケット ](https://pypi.org/project/token-bucket/)
+ [ ノードトークンバケット ](https://www.npmjs.com/package/tokenbucket)
+ [ .NET システムスレッドのレート制限 ](https://www.nuget.org/packages/System.Threading.RateLimiting)

 **関連動画:** 
+ [AWS AppSync を使用した GraphQL API セキュリティのベストプラクティスの実装 ](https://www.youtube.com/watch?v=1ASMLeJ_15U)

 **関連ツール:** 
+ [ Amazon API Gateway ](https://aws.amazon.com/api-gateway/)
+ [AWS AppSync](https://aws.amazon.com/appsync/)
+ [ Amazon SQS ](https://aws.amazon.com/sqs/)
+ [ Amazon Kinesis ](https://aws.amazon.com/kinesis/)
+ [AWS WAF](https://aws.amazon.com/waf/)