# SUS02-BP06 需要曲線を平坦化するためにバッファリングまたはスロットリングを実装する
<a name="sus_sus_user_a7"></a>

バッファリングやスロットリングは、需要曲線を平坦化し、ワークロードに必要なプロビジョンドキャパシティを削減します。

 **一般的なアンチパターン:** 
+ 即時対応が不要なクライアントのリクエストを即時処理している。
+ クライアントのリクエストの要件を分析していない。

 **このベストプラクティスを活用するメリット:** 需要曲線を平坦化することで、ワークロードに必要なプロビジョンドキャパシティを削減できます。プロビジョンドキャパシティが削減されると、エネルギーの消費量が少なくなり、環境への影響が小さくなります。

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

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

 ワークロードの需要曲線を平坦化することで、ワークロードに必要なプロビジョンドキャパシティを削減し、環境への影響を減らすことができます。以下の図に示す需要曲線を持つワークロードがあるとします。このワークロードには 2 つのピークがあり、これらのピークを処理するために、オレンジの線で示されるリソース容量がプロビジョニングされます。このワークロードで使用されるリソースとエネルギーは需要曲線の下の領域ではなく、プロビジョンドキャパシティのラインの下の領域で示されます。これら 2 つのピークを処理するには、プロビジョンドキャパシティが必要であるためです。

![\[高プロビジョニング容量を必要とする 2 つの異なるピークを持つプロビジョニングされた容量の波形。\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/sustainability-pillar/images/provisioned-capacity-1.png)


 

 バッファリングやスロットリングを使用して需要曲線を変化させ、ピークをならすことができます。つまり、プロビジョンドキャパシティや消費されるエネルギーを減らすことができます。クライアントが再試行を実行できるときはスロットリングを実装します。バッファリングを実装して、リクエストを保存し、処理を延期できます。

![\[バッファリングまたはスロットリングを使用して作成された、平坦化されたピークを持つワークロードを示すウェーブフォーム図。\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/sustainability-pillar/images/provisioned-capacity-2.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/) は、多数のコンシューマーが同じメッセージを読み取ることができるストリームを提供します。
+  全体的な需要、変化率、および要求される応答時間を分析して、必要なスロットルまたはバッファのサイズを適正化します。

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

 **関連ドキュメント:** 
+ [Amazon SQS の開始方法](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-getting-started.html)
+ [ キューとメッセージを使用したアプリケーション統合 ](https://aws.amazon.com/blogs/architecture/application-integration-using-queues-and-messages/)
+ [ ワークロードでの API スロットリングの管理と監視 ](https://aws.amazon.com/blogs/mt/managing-monitoring-api-throttling-in-workloads/)
+ [ 階層化されたマルチテナント REST API を API Gateway を使用して大規模にスロットリング ](https://aws.amazon.com/blogs/architecture/throttling-a-tiered-multi-tenant-rest-api-at-scale-using-api-gateway-part-1/)
+ [ キューとメッセージを使用したアプリケーション統合 ](https://aws.amazon.com/blogs/architecture/application-integration-using-queues-and-messages/)

 **関連動画:** 
+ [AWS re:Invent 2022 - Application integration patterns for microservices ](https://www.youtube.com/watch?v=GoBOivyE7PY)
+ [AWS re:Invent 2023 – Smart savings: Amazon EC2 cost-optimization strategies ](https://www.youtube.com/watch?v=_AHPbxzIGV0)
+ [AWS re:Invent 2023 - Advanced integration patterns & trade-offs for loosely coupled systems ](https://www.youtube.com/watch?v=FGKGdUiZKto)