# SUS 2 ユーザーの行動パターンをどのように利用して、持続可能性目標を目指しますか? ユーザーがワークロードやその他のリソースを使用する方法によって、持続可能性の目標を達成するための改善点を特定できます。継続的にユーザーの負荷に合うようにインフラストラクチャをスケールし、ユーザーをサポートするために必要な最小リソースのみがデプロイされているようにします。サービスレベルをお客様のニーズと整合させます。ユーザーがリソースを消費するために必要なネットワークを制限できるようにリソースを配置します。未使用の既存アセットを削除します。作成されたが未使用のアセットを特定し、作成を止めます。チームメンバーには、必要な機能をサポートし持続可能性への影響を最小限にするデバイスを提供します。 ベストプラクティス: # SUS02-BP01 ユーザーの負荷に合わせてインフラストラクチャをスケールする 使用率が低い、または使用されていない期間を特定し、リソースをスケールダウンして余分な容量を排除し効率性を改善します。 **一般的なアンチパターン:** + ユーザーの負荷に合わせてインフラストラクチャをスケールしない。 + 常に手動でインフラストラクチャをスケールする。 + スケーリングイベントの後、スケールダウンして元に戻すのではなく、キャパシティーを増加させたままにする。 **このベストプラクティスを活用するメリット:** ワークロードの伸縮性を設定してテストすることで、ワークロードの環境への影響を削減し、費用を節減し、パフォーマンスベンチマークを維持できます。クラウドの伸縮性を活用して、ユーザーの負荷の急増時や急増後にキャパシティを自動的にスケールして、お客様のニーズを満たすために必要なリソースのみを正確に使用できるようにすることができます。 **このベストプラクティスを活用しない場合のリスクレベル:** ミディアム ## 実装のガイダンス + 伸縮性は、持っているリソースの供給を、それらのリソースに対する需要と一致させます。インスタンス、コンテナ、機能には、伸縮性のためのメカニズムがあり、自動スケーリングと組み合わせて、またはサービスの機能として提供されます。アーキテクチャの伸縮性を使用して、ユーザーの負荷が低い時間帯にワークロードを迅速かつ容易にスケールダウンできるようにします。 + 予想されるコストと使用状況に合わせたカスタムの予算を設定するには、 [Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) を使用して、アプリケーションのユーザー負荷を処理するための適切な数の Amazon EC2 インスタンスがあることを確認できます。 + 予想されるコストと使用状況に合わせたカスタムの予算を設定するには、 [Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/what-is-application-auto-scaling.html) を使用して、個別の AWS サービス (Lambda 関数や Amazon Elastic Container Service (Amazon ECS) サービスなど) のリソースを、Amazon EC2 を超えて自動的にスケーリングします。 + 予想されるコストと使用状況に合わせたカスタムの予算を設定するには、 [Kubernetes Cluster Autoscaler](https://aws.amazon.com/blogs/aws/introducing-karpenter-an-open-source-high-performance-kubernetes-cluster-autoscaler/) を使用して、AWS の Kubernetes クラスターを自動的にスケーリングします。 + スケールアップまたはスケールダウンのメトリクスが、デプロイされているワークロードのタイプに対して検証されていることを確認します。動画トランスコーディングアプリケーションをデプロイしようとする場合、100% の CPU 使用率が想定されるため、プライマリメトリクスにするべきではありません。必要な場合は、スケーリングポリシーとして [カスタマイズされたメトリクス](https://aws.amazon.com/blogs/mt/create-amazon-ec2-auto-scaling-policy-memory-utilization-metric-linux/) (メモリ使用率など) を使用できます。適切なメトリクスを選ぶには、Amazon EC2 の以下のガイダンスを考慮してください。 + メトリクスは有効な利用率メトリクスでなければならず、インスタンスのどの程度ビジーかを記述する必要があります。 + メトリクス値は、Auto Scaling グループ内のインスタンス数に比例して増減する必要があります。 + 予想されるコストと使用状況に合わせたカスタムの予算を設定するには、 [手動スケーリング](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scale-based-on-demand.html) ではなく [動的スケーリング](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-manual-scaling.html) を Auto Scaling グループに使用します。また、動的スケーリングでは、 [ターゲット追跡スケーリングポリシー](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-target-tracking.html) を使用することをお勧めします。 + ワークロードのデプロイがスケールアップとスケールダウンの両方のイベントに対処できることを確認します。スケールダウンイベントのテストシナリオを作成して、ワークロードが期待どおりに動作することを確認します。専用のインフラストラクチャで **アクティビティ履歴** を使用して、Auto Scaling グループのスケーリングアクティビティをテストし、確認することができます。 + ワークロードを評価して予測可能なパターンを見つけ、あらかじめわかっていた、および計画的な需要の変化を予測してプロアクティブにスケールします。予想されるコストと使用状況に合わせたカスタムの予算を設定するには、 [Amazon EC2 Auto Scaling で予測スケーリング](https://aws.amazon.com/blogs/compute/introducing-native-support-for-predictive-scaling-with-amazon-ec2-auto-scaling/) を使用して、キャパシティを誇張する必要性をなくします。 ## リソース **関連するドキュメント:** + [Getting Started With 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/) + [Analyze user behavior using Amazon OpenSearch Service, Amazon Data Firehose and 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) + [「AWS X-Ray とは何ですか。」](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) + [VPC フローログ](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.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/) + [メモリ利用率メトリクスに基づいて Amazon EC2 Auto Scaling ポリシーを作成する方法 (Linux)](https://aws.amazon.com/blogs/mt/create-amazon-ec2-auto-scaling-policy-memory-utilization-metric-linux/) + [Karpenter の概要 - オープンソースの高性能 Kubermetes Cluster Autoscaler](https://aws.amazon.com/blogs/aws/introducing-karpenter-an-open-source-high-performance-kubernetes-cluster-autoscaler/) **関連動画:** + [Better, faster, cheaper compute: Cost-optimizing Amazon EC2 (CMP202-R1)](https://www.youtube.com/watch?v=_dvh4P2FVbw) **関連する例:** + ラボ: Amazon EC2 Auto Scaling グループの例 + [ラボ: Karpenter による自動スケーリングの実装](https://www.eksworkshop.com/beginner/085_scaling_karpenter/) # SUS02-BP02 SLA を持続可能性の目標に合わせる 可用性やデータ保持期間などに関するサービスレベルアグリーメント (SLA) を定義、更新し、ビジネス要件を満たしながら、ワークロードをサポートするために必要なリソース数を最小化します。 **このベストプラクティスが確立されていない場合のリスクレベル:** 低 ## 実装のガイダンス + ビジネス要件を満たしながら持続可能性の目標をサポートする SLA を定義します。 + ビジネス要件を超えるのではなく、要件に合わせて SLA を再定義します。 + 持続可能性への影響を大幅に削減できる事項と、サービスレベルの許容できる範囲での低下をトレードオフします。 + ビジネスクリティカルな機能を優先し、クリティカルでない機能にはサービスレベル (応答時間や回復時間目標など) を引き下げる設計パターンを使用します。 ## リソース **関連するドキュメント:** + [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/) **関連動画:** + [Building Sustainably on AWS (AWS でサステナブルに構築する)](https://www.youtube.com/watch?v=ARAitMSIxc8) # SUS02-BP03 未使用アセットの創出と維持の停止 アプリケーションアセット (事前コンパイル済みのレポート、データセット、静的イメージなど) とアセットのアクセスパターンを分析し、冗長性、低使用率、および廃止できそうなターゲットを特定します。生成されたアセットを冗長性コンテンツ (重複または共通のデータセットと出力が含まれる月次レポートなど) と統合し、出力が重複する際に消費されるリソースをなくします。使用されていないアセット (既に販売していない製品の画像など) を廃止し、消費されていたリソースを解放して、ワークロードをサポートするために使用されるリソース数を削減します。 **このベストプラクティスが確立されていない場合のリスクレベル:** 低 ## 実装のガイダンス + 静的アセットを管理し、不要になったアセットは削除します。 + 生成されたアセットを管理し、不要になったアセットは生成を止めて削除します。 + 重複して生成されるアセットは統合し、冗長プロセスを排除します。 + 不要になったアセットをお客様に代わって管理しているサードパーティーに、アセットの生成と保存を止めるように指示します。 + サードパーティーに、お客様の代わりに生成されている冗長アセットを統合するように指示します。 ## リソース **関連するドキュメント:** + [Optimizing your AWS Infrastructure for Sustainability, Part II: Storage (サステナビリティのための AWS インフラストラクチャの最適化、パートII : ストレージ)](https://aws.amazon.com/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-ii-storage/) **関連動画:** + [Building Sustainably on AWS (AWS でサステナブルに構築する)](https://www.youtube.com/watch?v=ARAitMSIxc8) # SUS02-BP04 ワークロードの地理的な配置を、ユーザーのロケーションに合わせて最適化する ネットワークのアクセスパターンを分析し、顧客が地理的にどこから接続しているかを特定します。ネットワークトラフィックが経由しなければならない距離を削減できるリージョンとサービスを選択し、ワークロードをサポートするために必要なネットワークリソースの総量を減らします。 ** 一般的なアンチパターン: ** + 自分の場所に基づいてワークロードのリージョンを選択する。 **このベストプラクティスを活用するメリット:** ワークロードを顧客の近くに配置することで、ネットワーク上のデータ移動を減らし、環境負荷を低減しながら、最小限のレイテンシーを実現します。 **このベストプラクティスを活用しない場合のリスクレベル:** ミディアム ## 実装のガイダンス + 以下の主な要素に基づいて、ワークロードのデプロイに適切なリージョンを選択します。 + **持続可能性目標:** 以下で説明されています [リージョンの選択](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/global-infrastructure/localzones/) を使用して、動画レンダリングやグラフィックス集約的な仮想デスクトップアプリケーションなどのワークロードを実行します。ローカルゾーンでは、エンドユーザーの近くにコンピューティングリソースやストレージリソースがあるというメリットが得られます。 + ローカルキャッシュまたは [AWS キャッシュソリューション](https://aws.amazon.com/caching/aws-caching/) を、頻繁に使用するリソースに使用すると、パフォーマンスを向上させ、データ移動を削減し、環境への影響を低減できます。 + 予想されるコストと使用状況に合わせたカスタムの予算を設定するには、 [Amazon CloudFront](https://aws.amazon.com/cloudfront/) を使用すると、画像、スクリプト、動画などの静的コンテンツだけでなく、API 応答やウェブアプリケーションなどの動的コンテンツをキャッシュできます。 + 予想されるコストと使用状況に合わせたカスタムの予算を設定するには、 [Amazon ElastiCache](https://aws.amazon.com/elasticache/) を使用して、ウェブアプリケーションのコンテンツをキャッシュします。 + 予想されるコストと使用状況に合わせたカスタムの予算を設定するには、 [DynamoDB Accelerator](https://aws.amazon.com/dynamodb/dax/) を使用して、DynamoDB テーブルにインメモリアクセラレーションを追加します。 + ワークロードのユーザーの近くでコードを実行できるサービスを使用します。 + 予想されるコストと使用状況に合わせたカスタムの予算を設定するには、 [Lambda@Edge](https://aws.amazon.com/lambda/edge/) は、オブジェクトがキャッシュにないときに実行される、コンピューティング負荷の高いオペレーションに使用します。 + 予想されるコストと使用状況に合わせたカスタムの予算を設定するには、 [Amazon CloudFront 関数](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cloudfront-functions.html) は、HTTP リクエストまたはレスポンス操作など、短時間実行の関数で実行できるシンプルなユースケースに使用します。 + 予想されるコストと使用状況に合わせたカスタムの予算を設定するには、 [AWS IoT Greengrass](https://aws.amazon.com/greengrass/) を使用して、接続されたデバイスのローカルコンピューティング、メッセージング、データキャッシュを実行します。 + コネクションプーリングを使用して、接続の再利用を可能にし、必要なリソースを削減します。 + 永続的な接続や同期更新に依存しない分散されたデータストアを使用して、リージョンのユーザーに一貫性のあるサービスを提供します。 + 事前にプロビジョンされた静的ネットワーク容量を、共有の動的容量に置き換え、持続可能性に対するネットワーク容量の影響を他のサブスクライバーと共有します。 ## リソース **関連するドキュメント:** + [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/) + [Lambda@Edge](https://aws.amazon.com/lambda/edge/) + [CloudFront 関数](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cloudfront-functions.html) + [AWS IoT Greengrass](https://aws.amazon.com/greengrass/) **関連動画:** + [Building Sustainably on AWS (AWS でサステナブルに構築する)](https://www.youtube.com/watch?v=ARAitMSIxc8) **関連する例:** + [AWS Networking Workshops](https://catalog.workshops.aws/networking/en-US) # SUS02-BP05 実行されるアクティビティに応じてチームメンバーのリソースを最適化する チームメンバーに提供されるリソースを最適化することで、ニーズをサポートしながら持続可能性への影響を最小限に抑えます。例えば、レンダリングやコンパイルなどの複雑なオペレーションを、使用率が低く高性能な単一ユーザーのシステムで行うのではなく、使用率の高い共有クラウドデスクトップで行います。 **このベストプラクティスが確立されていない場合のリスクレベル:** 低 ## 実装のガイダンス + 使用方法に合わせてワークステーションや他のデバイスをプロビジョンします。 + 仮想デスクトップとアプリケーションストリーミングを使用して、アップグレードとデバイス要件を制限します。 + プロセッサーやメモリの負荷が大きいタスクをクラウドに移動します。 + デバイスのライフサイクルにおけるプロセスやシステムの影響を評価し、ビジネス要件を満たしながらデバイスを交換する必要性を最小限にするソリューションを選択します。 + デバイスのリモート管理を実装して出張を少なくします。 ## リソース **関連するドキュメント:** + [Amazon WorkSpaces とは?](https://docs.aws.amazon.com/workspaces/latest/adminguide/amazon-workspaces.html) + [Amazon AppStream 2.0 のドキュメント](https://docs.aws.amazon.com/appstream2/) + [NICE DCV](https://docs.aws.amazon.com/dcv/) + [AWS Systems Manager Fleet Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/fleet.html) **関連動画:** + [Building Sustainably on AWS (AWS でサステナブルに構築する)](https://www.youtube.com/watch?v=ARAitMSIxc8)