# 需要に合わせた調整
**Topics**
+ [SUS 2 クラウドリソースを需要に合わせる方法](sus-02.md)
# SUS 2 クラウドリソースを需要に合わせる方法
ユーザーとアプリケーションがワークロードやその他のリソースを使用する方法によって、持続可能性の目標を達成するための改善点を特定できます。需要に合うように継続的にインフラストラクチャをスケールし、ユーザーをサポートするために必要な最小リソースのみを使用していることを検証します。サービスレベルをお客様のニーズと整合させます。ユーザーとアプリケーションがリソースを消費するために必要なネットワークを制限できるようにリソースを配置します。未使用のアセットを削除します。チームメンバーには、ニーズをサポートし持続可能性への影響を最小限にするデバイスを提供します。
**Topics**
+ [SUS02-BP01 ワークロードインフラストラクチャを動的にスケールする](sus_sus_user_a2.md)
+ [SUS02-BP02 SLA を持続可能性の目標に合わせる](sus_sus_user_a3.md)
+ [SUS02-BP03 未使用アセットの創出と維持の停止](sus_sus_user_a4.md)
+ [SUS02-BP04 ネットワーク要件に基づいてワークロードの地理的配置を最適化する](sus_sus_user_a5.md)
+ [SUS02-BP05 実行されるアクティビティに応じてチームメンバーのリソースを最適化する](sus_sus_user_a6.md)
+ [SUS02-BP06 需要曲線を平坦化するためにバッファリングまたはスロットリングを実装する](sus_sus_user_a7.md)
# SUS02-BP01 ワークロードインフラストラクチャを動的にスケールする
クラウドの伸縮性を利用してインフラストラクチャを動的にスケールすることにより、需要に合わせてクラウドリソースを供給し、ワークロード容量の過剰なプロビジョニングを回避します。
**一般的なアンチパターン:**
+ ユーザーの負荷に合わせてインフラストラクチャをスケールしない。
+ 常に手動でインフラストラクチャをスケールする。
+ スケーリングイベントの後、スケールダウンして元に戻すのではなく、キャパシティーを増加させたままにする。
**このベストプラクティスを確立するメリット:** ワークロードの伸縮性を設定およびテストすることで、クラウドリソースの供給を需要に効率的に一致させ、容量の過剰なプロビジョニングを回避できます。クラウドの伸縮性を利用して、需要の急増時や急増後に容量を自動的にスケールすることにより、ビジネス要件を満たすために必要となる適切な数のリソースのみを運用できます。
**このベストプラクティスを確立しない場合のリスクレベル:** 中
## 実装のガイダンス
クラウドは、需要の変化に対応するためのさまざまなメカニズムを通じて、リソースを動的に拡張または縮小する柔軟性を提供します。最適な形で需要と供給を一致させることで、ワークロードに対する環境の影響を最小限に抑えることができます。
需要が一定の場合も変動する場合もあり、管理面の負担を回避するには、メトリクスと自動化が必要になります。アプリケーションのスケールは、インスタンスのサイズを変更して垂直方向 (スケールアップ/スケールダウン)、インスタンス数を変更して水平方向 (スケールイン/スケールアウト)、あるいはこれらの組み合わせで調整できます。
リソースの需要と供給は、さまざまなアプローチで一致させることができます。
+ **ターゲット追跡アプローチ:** スケーリングメトリクスを監視し、必要に応じて容量を自動的に増減します。
+ **予測スケーリング:** 日単位および週単位の傾向を見越してスケールします。
+ **スケジュールベースのアプローチ:** 予測できる負荷の変化に従って、独自のスケーリングスケジュールを設定します。
+ **サービススケーリング:** 設計によってネイティブにスケールされるか、機能として自動スケーリングを提供するサービス (サーバーレスなど) を選択します。
使用率が低い、または使用されていない期間を特定し、リソースをスケールして余分な容量を排除し効率性を改善します。
## 実装手順
+ 伸縮性は、持っているリソースの供給を、それらのリソースに対する需要と一致させます。インスタンス、コンテナ、機能には、伸縮性のためのメカニズムがあり、自動スケーリングと組み合わせて、またはサービスの機能として提供されます。AWS では、ユーザー負荷が低い期間には迅速かつ簡単にワークロードをスケールダウンできるように、幅広い自動スケーリングメカニズムを提供しています。自動スケーリングメカニズムの例を次に示します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2023-04-10/framework/sus_sus_user_a2.html)
+ スケーリングに関する議論は、Amazon EC2 インスタンスや AWS Lambda 関数などのコンピューティングサービスに関連していることが一般的です。需要に合わせて、[Amazon DynamoDB](https://aws.amazon.com/dynamodb/) の読み取り/書き込みキャパシティユニットや [Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/) シャードなどの非コンピューティングサービスに関する設定も検討してみてください。
+ スケールアップまたはスケールダウンのメトリクスが、デプロイされているワークロードのタイプに対して検証されていることを確認します。動画トランスコーディングアプリケーションをデプロイしようとする場合、100% の CPU 使用率が想定されるため、プライマリメトリクスにするべきではありません。必要に応じて、[カスタマイズされたメトリクス](https://aws.amazon.com/blogs/mt/create-amazon-ec2-auto-scaling-policy-memory-utilization-metric-linux/) (メモリ使用率など) をスケーリングポリシーに使用することもできます。適切なメトリクスを選ぶには、Amazon EC2 の以下のガイダンスを考慮してください。
+ メトリクスは有効な利用率メトリクスでなければならず、インスタンスのどの程度ビジーかを記述する必要があります。
+ メトリクス値は、Auto Scaling グループ内のインスタンス数に比例して増減する必要があります。
+ Auto Scaling グループの[手動スケーリング](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-manual-scaling.html)ではなく、[動的スケーリング](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scale-based-on-demand.html)を使用します。また、動的スケーリングで[ターゲット追跡スケーリングポリシー](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-target-tracking.html)を使用することをお勧めします。
+ スケールアウトとスケールインの両方のイベントに対処できるようにワークロードをデプロイします。スケールインイベントのテストシナリオを作成して、ワークロードが期待どおりに動作し、ユーザーエクスペリエンスに影響しない (スティッキーセッションが失われない) ことを確認します。[アクティビティ履歴](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-verify-scaling-activity.html)を使用すると、Auto Scaling グループのスケーリングアクティビティを検証できます。
+ ワークロードを評価して予測可能なパターンを見つけ、あらかじめわかっていた、および計画的な需要の変化を予測してプロアクティブにスケールします。予測スケーリングを使用すると、容量を過剰にプロビジョニングする必要がなくなります。詳細については、[Amazon EC2 Auto Scaling を使用した予測スケーリングに関するブログ](https://aws.amazon.com/blogs/compute/introducing-native-support-for-predictive-scaling-with-amazon-ec2-auto-scaling/)を参照してください。
## リソース
**関連するドキュメント:**
+ [Amazon EC2 Auto Scaling の使用を開始する](https://docs.aws.amazon.com/autoscaling/ec2/userguide/GettingStartedTutorial.html)
+ [機械学習を利用した EC2 の予測スケーリング](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/)
+ [Amazon OpenSearch Service、Amazon Data Firehose、および Kibana を使用してユーザーの行動を分析する](https://aws.amazon.com/blogs/database/analyze-user-behavior-using-amazon-elasticsearch-service-amazon-kinesis-data-firehose-and-kibana/)
+ [Amazon CloudWatch とは](https://docs.aws.amazon.com/Amazon/latest/monitoring/WhatIs.html)
+ [Amazon RDS での Performance Insights を使用した DB 負荷のモニタリング](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html)
+ [Amazon EC2 Auto Scaling での予測スケーリングのネイティブサポートの概要](https://aws.amazon.com/blogs/compute/introducing-native-support-for-predictive-scaling-with-amazon-ec2-auto-scaling/)
+ [Karpenter の概要 - オープンソースの高性能 Kubermetes Cluster Autoscaler](https://aws.amazon.com/blogs/aws/introducing-karpenter-an-open-source-high-performance-kubernetes-cluster-autoscaler/)
+ [Amazon ECS クラスター Auto Scaling の詳細](https://aws.amazon.com/blogs/containers/deep-dive-on-amazon-ecs-cluster-auto-scaling/)
**関連動画:**
+ [Build a cost-, energy-, and resource-efficient compute environment](https://www.youtube.com/watch?v=8zsC5e1eLCg) (コスト面、エネルギー面、リソース面で効率的なコンピューティング環境の構築)
+ [Better, faster, cheaper compute: Cost-optimizing Amazon EC2 (CMP202-R1)](https://www.youtube.com/watch?v=_dvh4P2FVbw) (より良く、より速く、より安価なコンピューティング: Amazon EC2 でのコストの最適化 (CMP202-R1))
**関連する例:**
+ [ラボ: Amazon EC2 Auto Scaling グループの例](https://github.com/aws-samples/amazon-ec2-auto-scaling-group-examples)
+ [ラボ: Karpenter による自動スケーリングの実装](https://www.eksworkshop.com/beginner/085_scaling_karpenter/)
# SUS02-BP02 SLA を持続可能性の目標に合わせる
持続可能性の目標に基づいてワークロードのサービスレベルアグリーメント (SLA) をレビューし最適化して、ビジネスニーズを満たしながらワークロードをサポートするために必要なリソースを最小化します。
**一般的なアンチパターン:**
+ ワークロード SLA がわからない、またはあいまいである。
+ SLA を可用性とパフォーマンスのためにのみ定義している。
+ すべてのワークロードに同じ設計パターン (マルチ AZ アーキテクチャなど) を使用している。
**このベストプラクティスを活用するメリット:** SLA を持続可能性の目標に合わせることで、ビジネスニーズを満たしながら最適なリソース使用量を実現できます。
**このベストプラクティスが確立されていない場合のリスクレベル:** 低
## 実装のガイダンス
SLA は、クラウドワークロードで期待できるサービスのレベルを定義します。応答時間、可用性、データ保持などです。アーキテクチャ、リソース使用量、クラウドワークロードの環境への影響に関わります。定期的に SLA をレビューして、リソースの使用量を大幅に削減できる事項と、サービスレベルの許容できる範囲での低下をトレードオフします。
**実装手順**
+ ビジネス要件を超えるのではなく満たしながら、持続可能性の目標をサポートする SLA を定義または再設計します。
+ 持続可能性への影響を大幅に削減できる事項と、サービスレベルの許容できる範囲での低下をトレードオフします。
+ **持続可能性と信頼性:** 可用性が高いワークロードはより多くのリソースを消費する傾向があります。
+ **持続可能性とパフォーマンス:** より多くのリソースを使用してパフォーマンスを強化すると、環境への影響が大きくなる場合があります。
+ **持続可能性とセキュリティ:** 過剰に保護されたワークロードは環境への影響が大きくなる場合があります。
+ ビジネスクリティカルな機能を優先し、クリティカルでない機能にはサービスレベル (応答時間や回復時間目標など) を引き下げる設計パターン ([AWS のマイクロサービス](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html)など) を使用します。
## リソース
**関連するドキュメント:**
+ [AWS サービスレベルアグリーメント (SLA)](https://aws.amazon.com/legal/service-level-agreements/?aws-sla-cards.sort-by=item.additionalFields.serviceNameLower&aws-sla-cards.sort-order=asc&awsf.tech-category-filter=*all)
+ [Importance of Service Level Agreement for SaaS Providers](https://aws.amazon.com/blogs/apn/importance-of-service-level-agreement-for-saas-providers/) (SaaS プロバイダーにとってのサービスレベルアグリーメントの重要性)
**関連動画:**
+ [ Delivering sustainable, high-performing architectures ](https://www.youtube.com/watch?v=FBc9hXQfat0)(持続可能でパフォーマンスが高いアーキテクチャを実現する)
+ [Build a cost-, energy-, and resource-efficient compute environment (コスト面、エネルギー面、リソース面で効率的なコンピューティング環境の構築)](https://www.youtube.com/watch?v=8zsC5e1eLCg)
# SUS02-BP03 未使用アセットの創出と維持の停止
ワークロードの未使用アセットを廃止して、需要をサポートするために必要なクラウドリソース数を削減し、無駄を最小限に抑えます。
**一般的なアンチパターン:**
+ アプリケーションを分析して冗長または不要になったアセットを見つけていない。
+ 冗長または不要になったアセットを削除していない。
**このベストプラクティスを活用するメリット:** 不要なアセットを削除すると、リソースが解放され、ワークロード全体の効率が向上します。
**このベストプラクティスが確立されていない場合のリスクレベル:** 低
## 実装のガイダンス
未使用のアセットは、ストレージ容量やコンピューティングパワーなどのクラウドリソースを消費します。このようなアセットを特定して排除することで、これらのリソースを解放できるため、クラウドアーキテクチャの効率性が向上します。事前コンパイル済みのレポート、データセット、静的イメージなどのアプリケーションアセットと、アセットのアクセスパターンを定期的に分析し、冗長性、低使用率、および廃止できそうなターゲットを特定します。このような冗長アセットを削除して、ワークロード内のリソースの無駄を削減します。
**実装手順**
+ モニタリングツールを使用して、不要になった静的アセットを特定します。
+ アセットを削除する前に、削除によるアーキテクチャに対する影響を評価します。
+ 計画を立て、不要になったアセットは削除します。
+ 重複して生成されるアセットは統合し、冗長プロセスを排除します。
+ 不要なアセットをこれ以上生成および保存しないようにアプリケーションを更新します。
+ 不要になったアセットをお客様に代わって管理しているサードパーティに、アセットの生成と保存を止めるように指示します。
+ サードパーティに、お客様の代わりに生成されている冗長アセットを統合するように指示します。
+ ワークロードを定期的に見直して、未使用のアセットを特定し削除します。
## リソース
**関連するドキュメント:**
+ [Optimizing your AWS Infrastructure for Sustainability, Part II: Storage](https://aws.amazon.com/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-ii-storage/) (サステナビリティのための AWS インフラストラクチャの最適化、パート II : ストレージ)
+ [AWS アカウントで不要になったアクティブなリソースを終了するにはどうすればよいですか。](https://aws.amazon.com/premiumsupport/knowledge-center/terminate-resources-account-closure/)
**関連動画:**
+ [ How do I check for and then remove active resources that I no longer need on my AWS アカウント? ](https://www.youtube.com/watch?v=pqg9AqESRlg)(AWS アカウントで不要になったアクティブなリソースを確認し削除する方法を教えてください)
# SUS02-BP04 ネットワーク要件に基づいてワークロードの地理的配置を最適化する
ワークロード向けにネットワークトラフィックが経由しなければならない距離を削減できるクラウドのロケーションとサービスを選択し、ワークロードをサポートするために必要なネットワークリソースの総量を減らします。
** 一般的なアンチパターン: **
+ 自分の場所に基づいてワークロードのリージョンを選択する。
+ すべてのワークロードリソースを 1 つの地理的場所に統合する。
+ すべてのトラフィックが既存のデータセンターを通過する。
**このベストプラクティスを活用するメリット:** ワークロードをユーザーの近くに配置することで、ネットワーク上のデータ移動を減らし、環境負荷を低減しながら、最小限のレイテンシーを実現します。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
AWS クラウドインフラストラクチャは、リージョン、アベイラビリティーゾーン、プレイスメントグループ、および [AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html) および [AWS ローカルゾーンといったエッジロケーションなどのロケーションオプションを中心に構築されています](https://aws.amazon.com/about-aws/global-infrastructure/localzones/)。これらのロケーションオプションは、アプリケーションコンポーネント、クラウドサービス、エッジネットワーク、オンプレミスのデータセンター間の接続を維持する役割を担っています。
ワークロードのネットワークアクセスパターンを分析して、このようなクラウドロケーションオプションの使用方法や、ネットワークトラフィックが経由する距離を減らす方法を特定します。
## 実装手順
+ ワークロードのネットワークアクセスパターンを分析して、ユーザーがアプリケーションをどのように使用しているかを特定します。
+ ネットワーク活動に関するデータを収集するため、 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) および [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)のようなツールを使用します。
+ データを分析して、ネットワークアクセスパターンを特定します。
+ 以下の主な要素に基づいて、ワークロードのデプロイに適切なリージョンを選択します。
+ **持続可能性目標:** 以下で説明されています [リージョンの選択](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/region-selection.html).
+ **データの場所:** 大量のデータを使用するアプリケーション (ビッグデータや機械学習など) では、アプリケーションコードをできるだけデータの近くで実行してください。
+ **ユーザーの場所:** ユーザー向けアプリケーションの場合は、ワークロードの顧客に近いリージョン (または複数のリージョン) を選択します。
+ **その他の制約:** 以下で説明されているように、コストやコンプライアンスなどの制約を考慮します。 [What to Consider when Selecting a Region for your Workloads (ワークロードに応じたリージョンを選択する際の注意点)](https://aws.amazon.com/blogs/architecture/what-to-consider-when-selecting-a-region-for-your-workloads/)。
+ ローカルキャッシュまたは [AWS キャッシュソリューション](https://aws.amazon.com/caching/aws-caching/) を、頻繁に使用するアセットに使用すると、パフォーマンスを向上させ、データ移動を削減し、環境への影響を低減できます。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2023-04-10/framework/sus_sus_user_a5.html)
+ ワークロードのユーザーの近くでコードを実行できるサービスを使用します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2023-04-10/framework/sus_sus_user_a5.html)
+ 接続プーリングを使用して、接続の再利用を可能にし、必要なリソースを削減します。
+ 永続的な接続や同期更新に依存しない分散されたデータストアを使用して、リージョンのユーザーに一貫性のあるサービスを提供します。
+ 事前にプロビジョンされた静的ネットワーク容量を、共有の動的容量に置き換え、持続可能性に対するネットワーク容量の影響を他のサブスクライバーと共有します。
## リソース
**関連するドキュメント:**
+ [Optimizing your AWS Infrastructure for Sustainability, Part III: Networking](https://aws.amazon.com/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-iii-networking/)
+ [Amazon ElastiCache のドキュメント](https://docs.aws.amazon.com/elasticache/index.html)
+ [「Amazon CloudFront とは」](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html)
+ [Amazon CloudFront の主な特徴](https://aws.amazon.com/cloudfront/features/)
**関連動画:**
+ [Demystifying data transfer on AWS](https://www.youtube.com/watch?v=-MqXgzw1IGA)
+ [ 次世代 Amazon EC2 インスタンスでのネットワークパフォーマンスのスケーリング ](https://www.youtube.com/watch?v=jNYpWa7gf1A)
**関連サンプル:**
+ [AWS Networking Workshops](https://catalog.workshops.aws/networking/en-US)
+ [ 持続可能性を考慮したアーキテクチャ - ネットワーク間のデータ移動を最小限に抑える ](https://catalog.us-east-1.prod.workshops.aws/workshops/7c4f8394-8081-4737-aa1b-6ae811d46e0a/en-US)
# SUS02-BP05 実行されるアクティビティに応じてチームメンバーのリソースを最適化する
チームメンバーに提供されるリソースを最適化することで、ニーズをサポートしながら環境の持続可能性への影響を最小限に抑えます。
**一般的なアンチパターン:**
+ クラウドアプリケーションの全体的な効率性に関して、チームメンバーが使用するデバイスの影響を無視する。
+ チームメンバーが使用するリソースを手動で管理および更新している。
**このベストプラクティスを活用するメリット:** チームメンバーのリソースを最適化すると、クラウド対応アプリケーションの全体的な効率性が向上します。
**このベストプラクティスが確立されていない場合のリスクレベル:** 低
## 実装のガイダンス
サービスを利用するためにチームメンバーが使用しているリソース、その予想ライフサイクル、および金融および持続可能性に対する影響を理解します。これらのリソースを最適化する戦略を策定します。例えば、レンダリングやコンパイルなどの複雑なオペレーションを、使用率が低く高性能な単一ユーザーのシステムで行うのではなく、使用率の高いスケーラブルなインフラストラクチャで行います。
**実装手順**
+ 使用方法に合わせてワークステーションや他のデバイスをプロビジョンします。
+ 仮想デスクトップとアプリケーションストリーミングを使用して、アップグレードとデバイス要件を制限します。
+ プロセッサーやメモリの負荷が大きいタスクをクラウドに移動して、その伸縮性を活用します。
+ デバイスのライフサイクルにおけるプロセスやシステムの影響を評価し、ビジネス要件を満たしながらデバイスを交換する必要性を最小限にするソリューションを選択します。
+ デバイスのリモート管理を実装して出張を少なくします。
+ [AWS Systems Manager Fleet Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/fleet.html) は、AWS やオンプレミスで実行されているノードをリモートで管理できる、統合ユーザーインターフェイス (UI) エクスペリエンスです。
## リソース
**関連するドキュメント:**
+ [Amazon WorkSpaces とは](https://docs.aws.amazon.com/workspaces/latest/adminguide/amazon-workspaces.html)
+ [ Cost Optimizer for Amazon WorkSpaces ](https://docs.aws.amazon.com/solutions/latest/cost-optimizer-for-workspaces/overview.html)(Amazon WorkSpaces の Cost Optimizer)
+ [Amazon AppStream 2.0 のドキュメント](https://docs.aws.amazon.com/appstream2/)
+ [NICE DCV](https://docs.aws.amazon.com/dcv/)
**関連動画:**
+ [Managing cost for Amazon WorkSpaces on AWS](https://www.youtube.com/watch?v=0MoY31hZQuE) (AWS での Amazon WorkSpaces のコストを管理する)
# SUS02-BP06 需要曲線を平坦化するためにバッファリングまたはスロットリングを実装する
バッファリングやスロットリングは、需要曲線を平坦化し、ワークロードに必要なプロビジョンドキャパシティを削減します。
**一般的なアンチパターン:**
+ 即時対応が不要なクライアントのリクエストを即時処理している。
+ クライアントのリクエストの要件を分析していない。
**このベストプラクティスを活用するメリット:** 需要曲線を平坦化することで、ワークロードに必要なプロビジョンドキャパシティを削減できます。プロビジョンドキャパシティが削減されると、エネルギーの消費量が少なくなり、環境への影響が小さくなります。
**このベストプラクティスが確立されていない場合のリスクレベル:** 低
ワークロードの需要曲線を平坦化することで、ワークロードに必要なプロビジョンドキャパシティを削減し、環境への影響を減らすことができます。以下の図に示す需要曲線を持つワークロードがあるとします。このワークロードには 2 つのピークがあり、これらのピークを処理するために、オレンジの線で示されるリソース容量がプロビジョニングされます。このワークロードで使用されるリソースとエネルギーは需要曲線の下の領域ではなく、プロビジョンドキャパシティのラインの下の領域で示されます。これら 2 つのピークを処理するには、プロビジョンドキャパシティが必要であるためです。
![\[大きな容量をプロビジョニングする必要がある 2 つの大きなピークがあるプロビジョンドキャパシティの波形\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2023-04-10/framework/images/provisioned-capacity-1.png)
バッファリングやスロットリングを使用して需要曲線を変化させ、ピークをならすことができます。つまり、プロビジョンドキャパシティや消費されるエネルギーを減らすことができます。クライアントが再試行を実行できるときはスロットリングを実装します。バッファリングは、リクエストを保存し、後日まで処理を延期するために実装します。
![\[バッファリングまたはスロットリングを使用してピークをならしたワークロードを示す波形図\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2023-04-10/framework/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/) は、1 人のコンシューマーが個別のメッセージを読むことができるキューを提供するマネージドサービスです。
+ [Amazon Kinesis](https://aws.amazon.com/kinesis/) は、多数のコンシューマーが同じメッセージを読み取ることができるストリームを提供します。
+ 全体的な需要、変化率、および要求される応答時間を分析して、必要なスロットルまたはバッファのサイズを適正化します。
## リソース
**関連するドキュメント:**
+ [Getting started with Amazon SQS](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-getting-started.html) (Amazon SQS の開始方法)
+ [ Application integration Using Queues and Messages ](https://aws.amazon.com/blogs/architecture/application-integration-using-queues-and-messages/)(キューとメッセージを使用したアプリケーション統合)
**関連動画:**
+ [ Choosing the Right Messaging Service for Your Distributed App ](https://www.youtube.com/watch?v=4-JmX6MIDDI)(分散アプリケーションに適したメッセージングサービスを選択する)