# 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/latest/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/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
+ [Amazon RDS での Performance Insights を使用した DB 負荷のモニタリング](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html)
+ [Introducing Native Support for Predictive Scaling with Amazon EC2 Auto Scaling](https://aws.amazon.com/blogs/compute/introducing-native-support-for-predictive-scaling-with-amazon-ec2-auto-scaling/)
+ [Karpenter の概要 - オープンソースの高性能 Kubernetes 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/)
**関連動画:**
+ [AWS re:Invent 2023 - Scaling on AWS for the first 10 million users ](https://www.youtube.com/watch?v=JzuNJ8OUht0)
+ [AWS re:Invent 2023 - Sustainable architecture: Past, present, and future ](https://www.youtube.com/watch?v=2xpUQ-Q4QcM)
+ [AWS re:Invent 2022 - Build a cost-, energy-, and resource-efficient compute environment](https://www.youtube.com/watch?v=8zsC5e1eLCg)
+ [AWS re:Invent 2022 - Scaling containers from one user to millions ](https://www.youtube.com/watch?v=hItHqzKoBk0)
+ [AWS re:Invent 2023 - Scaling FM inference to hundreds of models with Amazon SageMaker AI ](https://www.youtube.com/watch?v=6xENDvgnMCs)
+ [AWS re:Invent 2023 - Harness the power of Karpenter to scale, optimize & upgrade Kubernetes ](https://www.youtube.com/watch?v=lkg_9ETHeks)
**関連する例:**
+ [Autoscaling](https://www.eksworkshop.com/docs/autoscaling/)
# SUS02-BP02 SLA を持続可能性の目標に合わせる
持続可能性の目標に基づいてワークロードのサービスレベルアグリーメント (SLA) をレビュー、最適化して、ビジネスニーズを満たしながらワークロードをサポートするために必要なリソースを最小化します。
**一般的なアンチパターン:**
+ ワークロード SLA がわからない、またはあいまいである。
+ SLA を可用性とパフォーマンスのためにのみ定義している。
+ すべてのワークロードに同じ設計パターン (マルチ AZ アーキテクチャなど) を使用している。
**このベストプラクティスを活用するメリット:** SLA を持続可能性の目標と整合すると、ビジネスニーズを満たすと同時にリソース使用を最適化できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
SLA は、クラウドワークロードで期待できるサービスのレベルを定義します。応答時間、可用性、データ保持などです。アーキテクチャ、リソース使用量、クラウドワークロードの環境への影響にかかわります。定期的に SLA をレビューして、リソースの使用量を大幅に削減できる事項と、サービスレベルの許容できる範囲での低下をトレードオフします。
### 実装手順
+ **持続可能性の目標を理解する:** 炭素削減やリソース使用率の向上など、組織内の持続可能性の目標を特定します。
+ **SLA の確認:** SLA を評価して、ビジネス要件をサポートしているかどうかを評価します。SLA を超えている場合は、さらに見直しを行います。
+ **トレードオフを理解する:** ワークロードの複雑さ (大量の同時接続ユーザーなど)、パフォーマンス (レイテンシーなど)、持続可能性への影響 (必要なリソースなど) のトレードオフを理解します。通常、2 つの要素に優先順位を付けると、3 つ目の要素が犠牲になります。
+ **SLA を調整する:** 持続可能性への影響を大幅に削減できる事項と、サービスレベルの許容できる範囲での低下をトレードオフします。
+ **持続可能性と信頼性:** 可用性の高いワークロードは、より多くのリソースを消費する傾向があります。
+ **持続可能性とパフォーマンス:** より多くのリソースを使用してパフォーマンスを向上させると、環境への影響が大きくなる可能性があります。
+ **持続可能性とセキュリティ:** ワークロードが過度に安全であれば、環境への影響が大きくなる可能性があります。
+ **可能であれば持続可能性 SLA を定義する:** ワークロードに持続可能性 SLA を含めます。例えば、コンピューティングインスタンスの持続可能性に関する SLA として最小の使用率レベルを定義します。
+ **効率的な設計パターンを使用する:** ビジネスクリティカルな機能を優先し、クリティカルでない機能にはサービスレベル (応答時間や回復時間目標など) を引き下げる AWS 上のマイクロサービスなどの設計パターンを使用します。
+ **説明責任を伝達して確立する:** 開発チームや顧客を含む関連するすべての関係者と SLA を共有します。レポートを使用して SLA を追跡およびモニタリングします。SLA の持続可能性目標を達成するための説明責任を割り当てます。
+ **インセンティブと報酬を使用する:** インセンティブと報酬を使用して、持続可能性の目標に沿った SLA を達成または超過します。
+ **見直しと反復:** SLA を定期的に見直して調整し、進化する持続可能性とパフォーマンスの目標に合致していることを確認します。
## リソース
**関連ドキュメント:**
+ [ 回復性のパターンとトレードオフを理解して、効率的なクラウド設計を実現 ](https://aws.amazon.com/blogs/architecture/understand-resiliency-patterns-and-trade-offs-to-architect-efficiently-in-the-cloud/)
+ [SaaS プロバイダにとってのサービスレベルアグリーメントの重要性](https://aws.amazon.com/blogs/apn/importance-of-service-level-agreement-for-saas-providers/)
**関連動画:**
+ [AWS re:Invent 2023 - Capacity, availability, cost efficiency: Pick three](https://www.youtube.com/watch?v=E0dYLPXrX_w)
+ [AWS re:Invent 2023 - Sustainable architecture: Past, present, and future ](https://www.youtube.com/watch?v=2xpUQ-Q4QcM)
+ [AWS re:Invent 2023 - Advanced integration patterns & trade-offs for loosely coupled systems ](https://www.youtube.com/watch?v=FGKGdUiZKto)
+ [AWS re:Invent 2022 - Delivering sustainable, high-performing architectures](https://www.youtube.com/watch?v=FBc9hXQfat0)
+ [AWS re:Invent 2022 - Build a cost-, energy-, and resource-efficient compute environment ](https://www.youtube.com/watch?v=8zsC5e1eLCg)
# SUS02-BP03 未使用アセットの創出と維持の停止
ワークロードの未使用アセットを廃止して、需要をサポートするために必要なクラウドリソース数を削減し、無駄を最小限に抑えます。
**一般的なアンチパターン:**
+ アプリケーションを分析して冗長または不要になったアセットを見つけていない。
+ 冗長または不要になったアセットを削除していない。
**このベストプラクティスを活用するメリット:** 未使用アセットを削除すると、リソースが解放され、ワークロードの全体的な効率が向上します。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
未使用のアセットは、ストレージ容量やコンピューティングパワーなどのクラウドリソースを消費します。このようなアセットを特定して排除することで、これらのリソースを解放できるため、クラウドアーキテクチャの効率性が向上します。事前コンパイル済みのレポート、データセット、静的イメージなどのアプリケーションアセットと、アセットのアクセスパターンを定期的に分析し、冗長性、低使用率、および廃止できそうなターゲットを特定します。このような冗長アセットを削除して、ワークロード内のリソースの無駄を削減します。
### 実装手順
+ **棚卸しを実施する:** 包括的な棚卸しを実施して、ワークロード内のすべてのアセットを特定します。
+ **使用率を分析する:** モニタリングツールを使用して、不要になった静的アセットを特定します。
+ **未使用のアセットを削除する:** 不要になったアセットを削除する計画を立てます。
+ アセットを削除する前に、削除によるアーキテクチャに対する影響を評価します。
+ 重複して生成されるアセットは統合し、冗長プロセスを排除します。
+ 不要なアセットをこれ以上生成および保存しないようにアプリケーションを更新します。
+ **サードパーティーに伝達する:** 不要になったアセットをお客様に代わって管理しているサードパーティーに、アセットの生成と保存を止めるように指示します。冗長アセットを統合するように依頼します。
+ **ライフサイクルポリシーを使用する:** ライフサイクルポリシーを使用して、未使用のアセットを自動的に削除します。
+ [Amazon S3 ライフサイクル](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html)を使用すると、オブジェクトのライフサイクル全体を管理できます。
+ [Amazon Data Lifecycle Manager](https://docs.aws.amazon.com/ebs/latest/userguide/snapshot-lifecycle.html) を使用して、EBS スナップショットと Amazon EBS-backed AMI の作成、保持、削除を自動化できます。
+ **確認と最適化をする:** ワークロードを定期的に見直して、未使用のアセットを特定し削除します。
## リソース
**関連ドキュメント:**
+ [サステナビリティのための AWS インフラストラクチャの最適化、パート II : ストレージ](https://aws.amazon.com/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-ii-storage/)
+ [AWS アカウントで不要になったアクティブなリソースを終了するにはどうすればよいですか?](https://aws.amazon.com/premiumsupport/knowledge-center/terminate-resources-account-closure/)
**関連動画:**
+ [AWS re:Invent 2023 - Sustainable architecture: Past, present, and future ](https://www.youtube.com/watch?v=2xpUQ-Q4QcM)
+ [AWS re:Invent 2022 - Preserving and maximizing the value of digital media assets using Amazon S3 ](https://www.youtube.com/watch?v=8OI0Uu-YvD8)
+ [AWS re:Invent 2023 - Optimize costs in your multi-account environments](https://www.youtube.com/watch?v=ie_Mqb-eC4A)
# SUS02-BP04 ネットワーク要件に基づいてワークロードの地理的配置を最適化する
ワークロード向けにネットワークトラフィックが経由しなければならない距離を削減できるクラウドのロケーションとサービスを選択し、ワークロードをサポートするために必要なネットワークリソースの総量を減らします。
**一般的なアンチパターン:**
+ 自分の場所に基づいてワークロードのリージョンを選択する。
+ すべてのワークロードリソースを 1 つの地理的場所に統合する。
+ すべてのトラフィックが既存のデータセンターを通過する。
**このベストプラクティスを活用するメリット:** ワークロードをユーザーの近くに配置することで、ネットワーク上のデータ移動を減らし、環境負荷を低減しながら、最小限のレイテンシーを実現します。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
AWS クラウドインフラストラクチャは、リージョン、アベイラビリティーゾーン、プレイスメントグループなどのロケーションオプション、そして [AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html)、[AWS Local Zones](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)」を参照してください。
+ **データがある場所:** 大量のデータを使用するアプリケーション (ビッグデータや機械学習など) では、アプリケーションコードをできるだけデータの近くで実行してください。
+ **ユーザーがいる場所:** ユーザー向けアプリケーションの場合は、ワークロードのユーザーに近いリージョン (1 つまたは複数) を選択します。
+ **その他の制約**:「[ワークロードのリージョンを選択する際の考慮事項](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/latest/framework/sus_sus_user_a5.html)
+ 以下のように、ワークロードのユーザーの近くでコードを実行できるサービスを使用します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/sus_sus_user_a5.html)
+ 接続プーリングを使用して、接続の再利用を可能にし、必要なリソースを削減します。
+ 永続的な接続や同期更新に依存しない分散されたデータストアを使用して、リージョンのユーザーに一貫性のあるサービスを提供します。
+ 事前にプロビジョンされた静的ネットワーク容量を、共有の動的容量に置き換え、持続可能性に対するネットワーク容量の影響を他のサブスクライバーと共有します。
## リソース
**関連ドキュメント:**
+ [サステナビリティのための AWS インフラストラクチャの最適化、パート III : ネットワーキング](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/)
+ [AWS グローバルインフラストラクチャ ](https://aws.amazon.com/about-aws/global-infrastructure/)
+ [AWS Local Zones および AWS Outposts などエッジワークロードに適したテクノロジーの選択 ](https://aws.amazon.com/blogs/compute/aws-local-zones-and-aws-outposts-choosing-the-right-technology-for-your-edge-workload/)
+ [ プレイスメントグループ ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html)
+ [AWS Local Zones ](https://aws.amazon.com/about-aws/global-infrastructure/localzones/)
+ [AWS Outposts](https://aws.amazon.com/outposts/)
**関連動画:**
+ [Demystifying data transfer on AWS](https://www.youtube.com/watch?v=-MqXgzw1IGA)
+ [ Scaling network performance on next-gen Amazon EC2 instances ](https://www.youtube.com/watch?v=jNYpWa7gf1A)
+ [AWS Local Zones 解説動画 ](https://www.youtube.com/watch?v=JHt-D4_zh7w)
+ [AWS Outposts: 概要と機能紹介 ](https://www.youtube.com/watch?v=ppG2FFB0mMQ)
+ [AWS re:Invent 2023 - エッジワークロードとオンプレミスワークロードの移行戦略 ](https://www.youtube.com/watch?v=4wUXzYNLvTw)
+ [AWS re:Invent 2021 - AWS Outposts: Bringing the AWS experience on premises ](https://www.youtube.com/watch?v=FxVF6A22498)
+ [AWS re:Invent 2020 - AWS Wavelength: Run apps with ultra-low latency at 5G edge ](https://www.youtube.com/watch?v=AQ-GbAFDvpM)
+ [AWS re:Invent 2022 - AWS Local Zones: Building applications for a distributed edge ](https://www.youtube.com/watch?v=bDnh_d-slhw)
+ [AWS re:Invent 2021 - Amazon CloudFront で低レイテンシーウェブサイトを構築 ](https://www.youtube.com/watch?v=9npcOZ1PP_c)
+ [AWS re:Invent 2022 - AWS Global Accelerator でパフォーマンスと可用性を向上](https://www.youtube.com/watch?v=s5sjsdDC0Lg)
+ [AWS re:Invent 2022 - AWS でグローバルなワイドエリアネットワークを構築](https://www.youtube.com/watch?v=flBieylTwvI)
+ [AWS re:Invent 2020 - Amazon Route 53 でグローバルなトラフィック管理を実現 ](https://www.youtube.com/watch?v=E33dA6n9O7I)
**関連する例:**
+ [AWS ネットワーキングワークショップ](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 実行されるアクティビティに応じてチームメンバーのリソースを最適化する
チームメンバーに提供されるリソースを最適化することで、ニーズをサポートしながら環境の持続可能性への影響を最小限に抑えます。
**一般的なアンチパターン:**
+ クラウドアプリケーションの全体的な効率性に関して、チームメンバーが使用するデバイスの影響を無視する。
+ チームメンバーが使用するリソースを手動で管理および更新している。
**このベストプラクティスを活用するメリット:** チームメンバーリソースを最適化すると、クラウド対応アプリケーションの全体的な効率が向上します。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
サービスを利用するためにチームメンバーが使用するリソース、その予想ライフサイクル、および経営と持続可能性に対する影響を理解します。これらのリソースを最適化する戦略を策定します。例えば、レンダリングやコンパイルなどの複雑なオペレーションを、使用率が低く高性能な単一ユーザーのシステムで行うのではなく、使用率の高いスケーラブルなインフラストラクチャで行います。
### 実装手順
+ **省エネ型ワークステーションを使用する:** チームメンバーに省エネ型ワークステーションと周辺機器を支給します。これらのデバイスで効率的な電源管理機能 (低電力モードなど) を使用して、エネルギー使用量を削減します。
+ **仮想化を利用する:** 仮想デスクトップとアプリケーションストリーミングを使用して、アップグレードの必要性とデバイス要件を軽減します。
+ **リモートコラボレーションを奨励する:** [Amazon Chime](https://aws.amazon.com/chime/) および [AWS Wickr](https://aws.amazon.com/wickr/) などのリモートコラボレーションツールを使用するようチームメンバーに奨励して、出張の必要性や出張に関連する炭素排出量を削減します。
+ **エネルギー効率が優れたソフトウェアを使用する:** 不要な機能やプロセスを削除または無効にして、チームメンバーにエネルギー効率が優れたソフトウェアを支給します。
+ **ライフサイクルを管理する:** デバイスのライフサイクルにおけるプロセスやシステムの影響を評価し、ビジネス要件を満たしながらデバイスを交換する必要性を最小限にするソリューションを選択します。ワークステーションまたはソフトウェアの定期的なメンテナンスと更新を行って、効率性を維持、改善します。
+ **リモートデバイス管理を実施する:** デバイスのリモート管理を実装して出張を少なくします。
+ [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)
+ [ Amazon WorkSpaces のコストオプティマイザー ](https://docs.aws.amazon.com/solutions/latest/cost-optimizer-for-workspaces/overview.html)
+ [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)
# SUS02-BP06 需要曲線を平坦化するためにバッファリングまたはスロットリングを実装する
バッファリングやスロットリングは、需要曲線を平坦化し、ワークロードに必要なプロビジョンドキャパシティを削減します。
**一般的なアンチパターン:**
+ 即時対応が不要なクライアントのリクエストを即時処理している。
+ クライアントのリクエストの要件を分析していない。
**このベストプラクティスを活用するメリット:** 需要曲線を平坦化することで、ワークロードに必要なプロビジョンドキャパシティを削減できます。プロビジョンドキャパシティが削減されると、エネルギーの消費量が少なくなり、環境への影響が小さくなります。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
ワークロードの需要曲線を平坦化することで、ワークロードに必要なプロビジョンドキャパシティを削減し、環境への影響を減らすことができます。以下の図に示す需要曲線を持つワークロードがあるとします。このワークロードには 2 つのピークがあり、これらのピークを処理するために、オレンジの線で示されるリソース容量がプロビジョニングされます。このワークロードで使用されるリソースとエネルギーは需要曲線の下の領域ではなく、プロビジョンドキャパシティのラインの下の領域で示されます。これら 2 つのピークを処理するには、プロビジョンドキャパシティが必要であるためです。
![\[高プロビジョニング容量を必要とする 2 つの異なるピークを持つプロビジョニングされた容量の波形。\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/images/provisioned-capacity-1.png)
バッファリングやスロットリングを使用して需要曲線を変化させ、ピークをならすことができます。つまり、プロビジョンドキャパシティや消費されるエネルギーを減らすことができます。クライアントが再試行を実行できるときはスロットリングを実装します。バッファリングを実装して、リクエストを保存し、処理を延期できます。
![\[バッファリングまたはスロットリングを使用して作成された、平坦化されたピークを持つワークロードを示すウェーブフォーム図。\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/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/) は、単独のコンシューマーが個別のメッセージを読むことができるキューを提供するマネージドサービスです。
+ [Amazon Kinesis](https://aws.amazon.com/kinesis/) は、多数のコンシューマーが同じメッセージを読み取ることができるストリームを提供します。
+ 全体的な需要、変化率、および要求される応答時間を分析して、必要なスロットルまたはバッファのサイズを適正化します。
## リソース
**関連ドキュメント:**
+ [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)