# サステナビリティ
クラウドワークロードを構築するときの持続可能性の柱には、使用しているサービスの影響の理解、ワークロードのライフサイクル全体における影響の数値化、および設計原則とベストプラクティスの適用によるそれらの影響の軽減が含まれます。実装に関する規範的なガイダンスについては、[持続可能性の柱のホワイトペーパー](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sustainability-pillar.html?ref=wellarchitected-wp)を参照してください。
**Topics**
+ [リージョンの選択](a-region-selection.md)
+ [需要に合わせた調整](a-alignment-to-demand.md)
+ [ソフトウェアとアーキテクチャ](a-sus-software-architecture.md)
+ [データ](a-sus-data.md)
+ [ハードウェアとサービス](a-sus-hardware-and-services.md)
+ [プロセスと文化](a-sus-process-and-culture.md)
# リージョンの選択
**Topics**
+ [SUS 1 ワークロードにリージョンを選択する方法](w2aac19c17b7b5.md)
# SUS 1 ワークロードにリージョンを選択する方法
ワークロードのためのリージョンの選択は、パフォーマンス、コスト、カーボンフットプリントなどの KPI に大きく影響します。これらの KPI を効果的に改善するには、ビジネス要件と持続可能性の目標の両方に基づいて、ワークロードのリージョンを選択する必要があります。
**Topics**
+ [SUS01-BP01 ビジネス要件と持続可能性の目標の両方に基づいてリージョンを選択する](sus_sus_region_a2.md)
# SUS01-BP01 ビジネス要件と持続可能性の目標の両方に基づいてリージョンを選択する
パフォーマンス、コスト、カーボンフットプリントなどの KPI を最適化するために、ビジネス要件と持続可能性の目標の両方に基づいて、ワークロードのリージョンを選択します。
**一般的なアンチパターン:**
+ 自分の場所に基づいてワークロードのリージョンを選択する。
+ すべてのワークロードリソースを 1 つの地理的場所に統合する。
**このベストプラクティスを確立するメリット:** Amazon の再生可能エネルギープロジェクトや公開されている炭素強度の低いリージョンの近くにワークロードを配置することで、クラウドワークロードのカーボンフットプリントを削減できます。
**このベストプラクティスを確立しない場合のリスクレベル:** 中
## 実装のガイダンス
AWS クラウド は、リージョンと Point of Presence (PoP) のネットワークを常に拡大し、それらをグローバルなネットワークインフラストラクチャでつないでいます。ワークロードのためのリージョンの選択は、パフォーマンス、コスト、カーボンフットプリントなどの KPI に大きく影響します。これらの KPI を効果的に改善するには、ビジネス要件と持続可能性の目標の両方に基づいて、ワークロードのリージョンを選択する必要があります。
**実装手順**
+ 以下の手順に従って、コンプライアンス、利用可能な機能、コスト、レイテンシーなどのビジネス要件に基づき、ワークロードに適したリージョンを評価し、候補をリストアップします。
+ 必要なリージョンの規制に基づいて、これらのリージョンがコンプライアンスに準拠していることを確認します。
+ [AWS リージョンサービスリスト](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)を使用して、ワークロードの実行に必要なサービスと機能をリージョンが備えているかどうかを確認します。
+ [AWS 料金見積りツール](https://calculator.aws/) を使用して、各リージョンのワークロードのコストを計算します。
+ エンドユーザーの拠点と各 AWS リージョン 間のネットワークレイテンシーをテストします。
+ Amazon の再生可能エネルギープロジェクトに近いリージョンであり、グリッドの公開されている炭素集約度が他の場所 (またはリージョン) よりも低いリージョンを選択します。
+ 関連する持続可能性ガイドラインを特定し、[温室効果ガスプロトコル](https://ghgprotocol.org/) (市場ベースとロケーションベースの方法) に基づいて年間の炭素排出量を追跡および比較します。
+ 炭素排出量の追跡に使用する方法に基づいてリージョンを選択します。持続可能性のガイドラインに基づいてリージョンを選択する方法の詳細については、[持続可能性の目標に基づいてワークロードのリージョンを選択する方法](https://aws.amazon.com/blogs/architecture/how-to-select-a-region-for-your-workload-based-on-sustainability-goals/)を参照してください。
## リソース
**関連するドキュメント:**
+ [炭素排出量の推定の理解](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ccft-estimation.html)
+ [Amazon Around the Globe](https://sustainability.aboutamazon.com/about/around-the-globe?energyType=true) (世界中の Amazon)
+ [Renewable Energy Methodology](https://sustainability.aboutamazon.com/amazon-renewable-energy-methodology) (再生可能エネルギーの方法論)
+ [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/) (ワークロードに応じたリージョンを選択する際の注意点)
**関連動画:**
+ [Architecting sustainably and reducing your AWS carbon footprint](https://www.youtube.com/watch?v=jsbamOLpCr8) (持続可能なアーキテクチャ設計と AWS カーボンフットプリントの削減)
# 需要に合わせた調整
**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)(分散アプリケーションに適したメッセージングサービスを選択する)
# ソフトウェアとアーキテクチャ
**Topics**
+ [SUS 3 ソフトウェアとアーキテクチャのパターンをどのように利用して、持続可能性目標を目指しますか?](sus-03.md)
# SUS 3 ソフトウェアとアーキテクチャのパターンをどのように利用して、持続可能性目標を目指しますか?
負荷平滑化を実行しデプロイされたリソースが一貫して高使用率で維持されるパターンを実装し、リソースの消費を最小化します。時間の経過とともにユーザーの行動が変化したため、コンポーネントが使用されずアイドル状態になることがあります。パターンとアーキテクチャを改定して、使用率の低いコンポーネントを統合し、全体の使用率を上げます。不要になったコンポーネントは使用停止にします。ワークロードコンポーネントのパフォーマンスを理解し、リソースの消費が最も大きいコンポーネントを最適化します。顧客がお客さまのサービスにアクセスするために使用するデバイスを把握し、デバイスをアップグレードする必要性を最小化するパターンを実装します。
**Topics**
+ [SUS03-BP01 非同期のジョブおよびスケジュールされたジョブ向けにソフトウェアとアーキテクチャを最適化する](sus_sus_software_a2.md)
+ [SUS03-BP02 使用率が低い、またはまったく使用しないワークロードのコンポーネントを削除またはリファクタリングする](sus_sus_software_a3.md)
+ [SUS03-BP03 時間やリソースを最も多く消費するコード領域を最適化する](sus_sus_software_a4.md)
+ [SUS03-BP04 デバイスや機器への影響を最適化する](sus_sus_software_a5.md)
+ [SUS03-BP04 データアクセスとストレージパターンのサポートが最も優れたソフトウェアパターンとアーキテクチャを使用する](sus_sus_software_a6.md)
# SUS03-BP01 非同期のジョブおよびスケジュールされたジョブ向けにソフトウェアとアーキテクチャを最適化する
キュー駆動型などの効率的なソフトウェアおよびアーキテクチャパターンを使用して、デプロイされたリソースの使用率を一貫して高く維持します。
**一般的なアンチパターン:**
+ 予期せぬ需要の急増に対応するために、クラウドワークロードのリソースを過剰にプロビジョニングしています。
+ お使いのアーキテクチャでは、メッセージングコンポーネントによって非同期メッセージの送信者と受信者が切り離されていません。
**このベストプラクティスを活用するメリット:**
+ 効率的なソフトウェアとアーキテクチャのパターンは、ワークロード内の未使用リソースを最小限に抑え、全体的な効率を向上させます。
+ 非同期メッセージの受信とは無関係に処理を拡張できます。
+ メッセージングコンポーネントを使用することで、可用性要件が緩和され、より少ないリソースで対応できるようになります。
**このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム
## 実装のガイダンス
[イベント駆動型アーキテクチャ](https://aws.amazon.com/event-driven-architecture/)などの効率的なアーキテクチャパターンを使用することで、コンポーネントを均等に使用し、ワークロードの過剰プロビジョニングを最小限に抑えることができます。効率的なアーキテクチャパターンを使用することで、時間の経過に伴う需要の変化により、使用されずにアイドル状態になるリソースを最小限に抑えることができます。
ワークロードコンポーネントの要件を理解し、リソース全体の利用率を高めるアーキテクチャパターンを採用します。不要になったコンポーネントは廃止します。
**実装手順**
+ ワークロードの需要を分析し、それらに対応する方法を決定します。
+ 同期応答を必要としないリクエストやジョブには、キュー駆動型アーキテクチャとオートスケーリングワーカーを使用して使用率を最大化します。キュー駆動型アーキテクチャを検討する場合の例を次に示します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2023-04-10/framework/sus_sus_software_a2.html)
+ いつでも処理できるリクエストやジョブについては、スケジューリングメカニズムを利用してジョブをバッチ処理することで効率化を図ります。AWS でのスケジューリングメカニズムの例を次に示します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2023-04-10/framework/sus_sus_software_a2.html)
+ ご使用のアーキテクチャでポーリングやウェブフックのメカニズムを使用している場合、それらをイベントに置き換えます。[イベント駆動型アーキテクチャ](https://docs.aws.amazon.com/lambda/latest/operatorguide/event-driven-architectures.html)を使用して、効率性の高いワークロードを構築します。
+ [AWS のサーバーレス](https://aws.amazon.com/serverless/)を活用し、過剰にプロビジョニングされたインフラストラクチャを排除します。
+ アーキテクチャの個別のコンポーネントの適切なサイズを設定し、リソースが入力を待ってアイドル状態になるのを防ぎます。
## リソース
**関連するドキュメント:**
+ [Amazon Simple Queue Service とは](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
+ [Amazon MQ とは](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/welcome.html)
+ [Amazon SQS に基づいたスケーリング](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-using-sqs-queue.html)
+ [AWS Step Functions とは](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
+ [AWS Lambda とは](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
+ [AWS Lambda を Amazon SQS に使用する](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html)
+ [Amazon EventBridge とは](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
**関連動画:**
+ [Moving to event-driven architectures](https://www.youtube.com/watch?v=h46IquqjF3E) (イベント駆動型アーキテクチャへの移行)
# SUS03-BP02 使用率が低い、またはまったく使用しないワークロードのコンポーネントを削除またはリファクタリングする
未使用のコンポーネントや不要になったコンポーネントを削除し、使用率の低いコンポーネントはリファクタリングして、ワークロードの無駄を最小化します。
**一般的なアンチパターン:**
+ ワークロードの個別のコンポーネントの使用率レベルを定期的に確認していない。
+ [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) のような AWS サイズ最適化ツールからのレコメンデーションを確認し分析しない。
**このベストプラクティスを活用するメリット:** 未使用のコンポーネントを削除すると、無駄が最小化され、クラウドワークロード全体の効率が向上します。
**このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム
## 実装のガイダンス
ワークロードを見直して、アイドルや未使用のコンポーネントを特定します。これは、需要の変化や新しいクラウドサービスのリリースに伴う、反復的な改善プロセスです。例えば、[AWS Lambda](https://docs.aws.amazon.com/lambda/) 関数の実行時間が大幅に低下した場合は、メモリーサイズを小さくする指標になり得ます。また、AWS で新しいサービスや機能がリリースされると、ワークロードに最適なサービスやアーキテクチャが変化する可能性があります。
ワークロードのアクティビティを継続的にモニターして、個別のコンポーネントの使用率レベルを改善する機会を見逃さないようにします。アイドルのコンポーネントを削除しアクティビティのサイズ最適化を行って、最小限のクラウドリソースでビジネス要件を満たすようにします。
**実装手順**
+ ワークロードの重要なコンポーネントの使用率メトリクス ([Amazon CloudWatch メトリクス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)の CPU 使用率、メモリ使用率、ネットワークスループットなど) をモニターし、キャプチャします。
+ 安定したワークロードの場合は、[AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) などの AWS サイズ最適化ツールを定期的に確認して、アイドル、未使用、または使用率の低いコンポーネントを特定します。
+ 一次的なワークロードについては、使用率メトリクスを評価して、アイドル、未使用、または使用率の低いコンポーネントを特定します。
+ 不要になったコンポーネントや関連アセット (Amazon ECR イメージなど) を廃止します。
+ 使用率の低いコンポーネントをリファクタリングまたは他のリソースと統合して、使用効率を改善します。例えば、使用率の低い個別のインスタンスでデータベースを実行するのではなく、単体の [Amazon RDS](https://aws.amazon.com/rds/) データベースインスタンスに複数の小さなデータベースをプロビジョニングできます。
+ [作業の単位を完了するためにワークロードによってプロビジョニングされたリソース](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/evaluate-specific-improvements.html)を理解します。
## リソース
**関連するドキュメント:**
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
+ [Amazon CloudWatch とは](https://docs.aws.amazon.com/Amazon/latest/monitoring/WhatIs.html)
+ [Automated Cleanup of Unused Images in Amazon ECR](https://aws.amazon.com/blogs/compute/automated-cleanup-of-unused-images-in-amazon-ecr/) (Amazon ECR における未使用画像の自動クリーンアップ)
**関連する例:**
+ [ Well-Architected Lab - Rightsizing with AWS Compute Optimizer](https://wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/)(Well-Architected ラボ - Compute Optimizer を使用したサイズ最適化)
+ [ Well-Architected Lab - Optimize Hardware Patterns and Observe Sustainability KPIs ](https://wellarchitectedlabs.com/sustainability/200_labs/200_optimize_hardware_patterns_observe_sustainability_kpis/)(Well-Architected ラボ - ハードウェアパターンの最適化と持続可能性 KPI の観察)
# SUS03-BP03 時間やリソースを最も多く消費するコード領域を最適化する
アーキテクチャの異なるコンポーネント内で実行されているコードを最適化して、パフォーマンスを最大化しながらリソースの使用量を最小化します。
**一般的なアンチパターン:**
+ リソースの使用量のためにコードを最適化しない。
+ 通常、パフォーマンスの問題にはリソースを増やすことで対処している。
+ コードの見直しおよび開発プロセスで、パフォーマンスの変化を追跡していない。
**このベストプラクティスを活用するメリット:** 効率的なコードは、リソースの使用量を最小化し、パフォーマンスを向上させます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
クラウドに構築されたアプリケーションのコードを含むあらゆる機能領域を精査して、そのリソース使用量とパフォーマンスを最適化することが重要です。ビルド環境および本稼働環境でワークロードのパフォーマンスを継続的にモニターし、リソースの使用量が特に高いコードスニペットを改善する機会を特定します。定期的な見直しプロセスを導入して、コードの中でリソースを効率的に使用していないバグまたはアンチパターンを特定します。自分のユースケースに合わせて、同じ結果になるシンプルで効率的なアルゴリズムを活用します。
## 実装手順
+ ワークロードを開発する際に、自動化されたコードレビュープロセスを導入して、品質を向上させ、バグやアンチパターンを特定します。
+ [ Automate code reviews with Amazon CodeGuru Reviewer (Amazon CodeGuru Reviewer を使用したコードレビューの自動化) ](https://aws.amazon.com/blogs/devops/automate-code-reviews-with-amazon-codeguru-reviewer/)
+ [ Detecting concurrency bugs with Amazon CodeGuru (Amazon CodeGuru を使用した並列バグの検出) ](https://aws.amazon.com/blogs/devops/detecting-concurrency-bugs-with-amazon-codeguru/)
+ [ Raising code quality for Python applications using Amazon CodeGuru (Amazon CodeGuru を使用して Python アプリケーションのコード品質を向上させる) ](https://aws.amazon.com/blogs/devops/raising-code-quality-for-python-applications-using-amazon-codeguru/)
+ ワークロードを実行しながら、リソースをモニターして、作業単位でリソースを多く必要とするコンポーネントを特定し、コードレビューの対象とします。
+ コードレビューでは、コードプロファイラーを使用して、時間またはリソースを最も多く使用するコードの領域を特定し、最適化の対象とします。
+ [ Reducing your organization's carbon footprint with Amazon CodeGuru Profiler (Amazon CodeGuru Profiler を使用して組織のカーボンフットプリントを削減する) ](https://aws.amazon.com/blogs/devops/reducing-your-organizations-carbon-footprint-with-codeguru-profiler/)
+ [ Understanding memory usage in your Java application with Amazon CodeGuru Profiler (Amazon CodeGuru Profiler を使用して Java アプリケーションのメモリ使用量を理解する) ](https://aws.amazon.com/blogs/devops/understanding-memory-usage-in-your-java-application-with-amazon-codeguru-profiler/)
+ [ Improving customer experience and reducing cost with Amazon CodeGuru Profiler (Amazon CodeGuru Profiler を使用してカスタマーエクスペリエンスを改善しコストを削減する) ](https://aws.amazon.com/blogs/devops/improving-customer-experience-and-reducing-cost-with-codeguru-profiler/)
+ 最も効率的なオペレーティングシステムとプログラム言語をワークロードに使用します。エネルギー効率に優れたプログラム言語 (Rust など) の詳細については、 [Sustainability with Rust を参照してください](https://aws.amazon.com/blogs/opensource/sustainability-with-rust/)。
+ コンピューティング負荷が高いアルゴリズムを、結果が同じであり、よりシンプルでより効率的なバージョンに置き換えます。
+ ソートや書式設定などの不要なコードを削除します。
## リソース
**関連するドキュメント:**
+ [Amazon CodeGuru Profiler とは?](https://docs.aws.amazon.com/codeguru/latest/profiler-ug/what-is-codeguru-profiler.html)
+ [FPGA インスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/fpga-getting-started.html)
+ [The AWS SDKs on Tools to Build on AWS (AWS の構築ツールの AWS SDK)](https://aws.amazon.com/tools/)
**関連動画:**
+ [ Improve Code Efficiency Using Amazon CodeGuru Profiler ](https://www.youtube.com/watch?v=1pU4VddsBRw)
+ [ Automate Code Reviews and Application Performance Recommendations with Amazon CodeGuru ](https://www.youtube.com/watch?v=OD8H63C0E0I)
# SUS03-BP04 デバイスや機器への影響を最適化する
アーキテクチャで使用されているデバイスや機器を理解し、それらの使用量を削減する戦略を使用します。これにより、環境に対するクラウドワークロードの全体的な影響を最小化できます。
**一般的なアンチパターン:**
+ 顧客が使用するデバイスの環境に対する影響を無視する。
+ 顧客が使用するリソースを手動で管理および更新している。
**このベストプラクティスを活用するメリット:** 顧客のデバイスに合わせて最適化されたソフトウェアパターンや機能を実装することで、クラウドワークロード全体の環境に対する影響を削減できます。
**このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム
## 実装のガイダンス
顧客のデバイスに合わせて最適化されたソフトウェアパターンや機能を実装することで、複数の方法で環境に対する影響を削減できます。
+ 後方互換性がある新機能を実装することで、ハードウェアの置換数を削減できます。
+ アプリケーションを最適化してデバイスで効率的に実行できるようにすることで、エネルギー消費を削減し、バッテリー寿命を延ばすことができます (バッテリー駆動の場合)。
+ また、アプリケーションをデバイスに合わせて最適化すると、ネットワーク経由のデータ転送も削減できます。
アーキテクチャで使用されているデバイスや機器、それらの予想ライフサイクル、およびそれらコンポーネントを置換した場合の影響を理解します。デバイスのエネルギー消費、顧客がデバイスを置換する必要性、およびデバイスを手動でアップグレードする必要性を最小限にできるソフトウェアパターンや機能を実装します。
**実装手順**
+ アーキテクチャで使用されているデバイスをリストアップします。デバイスには、モバイル、タブレット、IoT デバイス、スマートライト、さらに工場のスマートデバイスも含まれます。
+ デバイスで実行されているアプリケーションを最適化します。
+ バックグラウンドでのタスク実行などの戦略を使用して、エネルギーの消費量を削減します。
+ ペイロードを構築する際にネットワーク帯域幅とレイテンシーを考慮し、低帯域幅、高レイテンシーのリンクでもアプリケーションが問題なく動作できる能力を実装します。
+ ペイロードやファイルを、デバイスが必要とする最適な形式に変換します。例えば、[Amazon Elastic Transcoder](https://docs.aws.amazon.com/elastic-transcoder/) や [AWS Elemental MediaConvert](https://aws.amazon.com/mediaconvert/) を使用して、サイズが大きい高品質デジタルメディアファイルを、ユーザーがモバイルデバイス、タブレット、ウェブブラウザ、コネクテッドテレビで再生できる形式に変換します。
+ コンピューティングの負荷が高いアクティビティはサーバー側 (画像のレンダリングなど) で実行するか、アプリケーションストリーミングを使用して、古い型のデバイスでのユーザーエクスペリエンスを改善します。
+ 特にインタラクティブセッションの場合は、出力を分割してページ番号を付け、ペイロードを管理しローカルストレージの要件を制限します。
+ 自動化された無線通信 (OTA) の仕組みを使用して、1 つ以上のデバイスに更新をデプロイします。
+ モバイルアプリケーションの更新には、[CI/CD パイプライン](https://aws.amazon.com/blogs/mobile/build-a-cicd-pipeline-for-your-android-app-with-aws-services/)を使用できます。
+ [AWS IoT Device Management](https://aws.amazon.com/iot-device-management/) を使用して、コネクテッドデバイスを大規模にリモートで管理できます。
+ 新機能や更新をテストするには、ハードウェアの代表的なセットを備えたマネージド型 Device Farm を使用し、サポート対象のデバイスを最大化する開発を繰り返します。詳細については、[SUS06-BP04 マネージド型 Device Farm を使用してテストする](sus_sus_dev_a5.md) を参照してください。
## リソース
**関連するドキュメント:**
+ [AWS Device Farm とは何ですか?](https://docs.aws.amazon.com/devicefarm/latest/developerguide/welcome.html)
+ [Amazon AppStream 2.0 のドキュメント](https://docs.aws.amazon.com/appstream2/)
+ [NICE DCV](https://docs.aws.amazon.com/dcv/)
+ [ FreeRTOS を実行するデバイスでファームウェアを更新する OTA チュートリアル](https://docs.aws.amazon.com/freertos/latest/userguide/dev-guide-ota-workflow.html)
**関連動画:**
+ [ Introduction to AWS Device Farm](https://www.youtube.com/watch?v=UiJo_PEZkD4)(AWS Device Farm の紹介)
# SUS03-BP04 データアクセスとストレージパターンのサポートが最も優れたソフトウェアパターンとアーキテクチャを使用する
データがどのようにワークロード内で使用されているか、ユーザーに消費されているか、転送されているか、保存されているかを理解します。データへのアクセスと保存を最適にサポートするソフトウェアパターンとアーキテクチャを使用して、ワークロードのサポートに必要なコンピューティング、ネットワーク、ストレージのリソースを最小化します。
**一般的なアンチパターン:**
+ すべてのワークロードのデータの保存とアクセスのパターンが類似していると考えている。
+ ストレージ階層を 1 つだけ使用し、すべてのワークロードがその階層に適していると考えている。
+ 時間が経過してもデータアクセスパターンが変わらないと考えている。
+ アーキテクチャはデータアクセスの高バーストの可能性をサポートしているが、その結果リソースがほとんどの時間でアイドルのままになる。
**このベストプラクティスを活用するメリット:** データのアクセスパターンおよびストレージパターンにもとづいてアーキテクチャを選択し最適化すると、開発の複雑性が下がり、全体の使用率が増加します。グローバルテーブル、データのパーティショニング、キャッシュをいつ使用するべきかを理解することで、運用上の諸経費を減らし、ワークロードのニーズに応じてスケーリングできるようになります。
**このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム
## 実装のガイダンス
データの特性やアクセスパターンに最も合うソフトウェアやアーキテクチャのパターンを使用します。例えば、お客様独自の分析ユースケースに合わせて最適化された目的別サービスを使用できる、[AWS のモダンデータアーキテクチャ](https://aws.amazon.com/big-data/datalakes-and-analytics/modern-data-architecture/)を使用します。このようなアーキテクチャパターンを使用すると、データ処理が効率的になり、リソースの使用量を削減できます。
**実装手順**
+ データの特性やアクセスパターンを分析して、クラウドリソースに最適な構成を特定します。考慮する主な特徴には次のものがあります。
+ **データタイプ:** 構造、半構造、非構造
+ **データ成長:** 制限あり、制限なし
+ **データ保存期間:** 永続、一時的、一過性
+ **アクセスパターン:** 読み取りまたは書き取り、更新頻度、急増、または安定
+ データアクセスとストレージパターンのサポートが最も優れたアーキテクチャパターンを使用します。
+ [ Let's Architect\$1 Modern data architectures ](https://aws.amazon.com/blogs/architecture/lets-architect-modern-data-architectures/) (構築してみよう\$1 モダンデータアーキテクチャ)
+ [ Databases on AWS: The Right Tool for the Right Job ](https://www.youtube.com/watch?v=-pb-DkD6cWg)(AWS のデータベース: 適材適所で使い分けるツール)
+ 圧縮データをネイティブに操作するテクノロジーを使用します。
+ アーキテクチャ内のデータ処理に、[目的別の分析サービス](https://aws.amazon.com/big-data/datalakes-and-analytics/?nc2=h_ql_prod_an_a)を使用します。
+ 主要なクエリパターンに対して最も優れたサポートをするデータベースエンジンを使用します。データベースインデックスを管理して、効率的なクエリ実行を確実にします。詳細については、[AWS のデータベース](https://aws.amazon.com/products/databases/)を参照してください。
+ アーキテクチャで消費されるネットワーク容量が削減できるネットワークプロトコルを選択します。
## リソース
**関連するドキュメント:**
+ [Athena でサポートされる圧縮ファイル形式](https://docs.aws.amazon.com/athena/latest/ug/compression-formats.html)
+ [Amazon Redshift を使用した列指向のデータ形式からの COPY](https://docs.aws.amazon.com/redshift/latest/dg/copy-usage_notes-copy-from-columnar.html)
+ [Converting Your Input Record Format in Firehose](https://docs.aws.amazon.com/firehose/latest/dev/record-format-conversion.html) (Kinesis Data Firehose の入力レコード形式を変換する)
+ [AWS Glue の ETL 入出力の形式オプション](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-programming-etl-format.html)
+ [列指向形式に変換して Amazon Athena でのクエリパフォーマンスを改善する](https://docs.aws.amazon.com/athena/latest/ug/convert-to-columnar.html)
+ [Amazon Redshift を使用して圧縮されたデータファイルを Amazon S3 からロードする](https://docs.aws.amazon.com/redshift/latest/dg/t_loading-gzip-compressed-data-files-from-S3.html)
+ [Amazon Aurora での Performance Insights を使用した DB 負荷のモニタリング](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html)
+ [Amazon RDS での Performance Insights を使用した DB 負荷のモニタリング](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html)
+ [ Amazon S3 Intelligent-Tiering storage class ](https://aws.amazon.com/s3/storage-classes/intelligent-tiering/)(Amazon S3 Intelligent-Tiering ストレージクラス)
**関連動画:**
+ [ Building modern data architectures on AWS](https://www.youtube.com/watch?v=Uk2CqEt5f0o)(AWS にモダンデータアーキテクチャを構築する)
# データ
**Topics**
+ [SUS 4 データ管理のポリシーとパターンをどのように利用して、持続可能性目標を達成しますか?](sus-04.md)
# SUS 4 データ管理のポリシーとパターンをどのように利用して、持続可能性目標を達成しますか?
データ管理プラクティスを実装して、ワークロードのサポートに必要なプロビジョンされたストレージと、それを使用するために必要なリソースを削減します。データを理解し、データのビジネス価値とデータの使用方法を最もよくサポートするストレージテクノロジーと設定を使用します。必要性が小さくなった場合はより効率的で性能を落としたストレージにデータをライフサイクルし、データが不要になった場合は削除します。
**Topics**
+ [SUS04-BP01 データ分類ポリシーを実装する](sus_sus_data_a2.md)
+ [SUS04-BP02 データのアクセスパターンとストレージパターンをサポートするテクノロジーを使用する](sus_sus_data_a3.md)
+ [SUS04-BP03 ポリシーを使用してデータセットのライフサイクルを管理する](sus_sus_data_a4.md)
+ [SUS04-BP04 伸縮性とオートメーションを使用してブロックストレージまたはファイルシステムを拡張する](sus_sus_data_a5.md)
+ [SUS04-BP04 不要なデータや重複するデータを削除する](sus_sus_data_a6.md)
+ [SUS04-BP06 共有ファイルシステムまたはストレージを使用して共通データにアクセスする](sus_sus_data_a7.md)
+ [SUS04-BP07 ネットワーク間でのデータ移動を最小限に抑える](sus_sus_data_a8.md)
+ [SUS04-BP08 データは再作成が難しい場合にのみバックアップする](sus_sus_data_a9.md)
# SUS04-BP01 データ分類ポリシーを実装する
データを分類してビジネス成果に対する重要度を理解し、データの保存にエネルギー効率の高い適切なストレージ層を選択します。
**一般的なアンチパターン:**
+ 処理または保存されているデータアセットの中で、類似の特徴 (機密度、ビジネス上の重要度、規制要件など) を持つものを特定していない。
+ データアセットのインベントリにデータカタログを実装していない。
**このベストプラクティスを活用するメリット:** データ分類ポリシーを実装すると、データに対して最もエネルギー効率の高いストレージ層を検討できます。
**このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム
## 実装のガイダンス
データ分類には、組織が所有または運用する情報システムで処理中または保存中のデータのタイプの特定を含めます。また、データの重要度と、データの侵害、損失、誤使用によって考えられる影響についても検討します。
データ分類ポリシーは、データを使用する流れから逆算して実装し、あるデータセットの組織の運営における重要度のレベルを考慮に入れて、カテゴリ分けのスキームを作成します。
**実装手順**
+ ワークロードに存在するさまざまなデータタイプのインベントリを実施します。
+ データ分類カテゴリの詳細については、[Data Classification whitepaper](https://docs.aws.amazon.com/whitepapers/latest/data-classification/data-classification.html) (データ分類ホワイトペーパー) をご覧ください。
+ 組織に対するリスクにもとづいて、データの重要度、機密度、整合性、可用性を判断します。このような要件を使用して、導入するデータ分類層のいずれかにデータをグループ分けします。
+ 例として、[Four simple steps to classify your data and secure your startup](https://aws.amazon.com/blogs/startups/four-simple-steps-to-classify-your-data-and-secure-your-startup/) (データを分類しスタートアップを保護する 4 つのシンプルなステップ) を参照してください。
+ 環境を定期的に監査してタグ付けおよび分類されていないデータを探し、そのデータを適切に分類してタグ付けします。
+ 例として、[AWS Glue のデータカタログとクローラー](https://docs.aws.amazon.com/glue/latest/dg/catalog-and-crawler.html)を参照してください。
+ 監査およびガバナンス機能があるデータカタログを作成します。
+ データクラスごとに処理手順を決定して文書化します。
+ 自動化を使用し、環境を継続的に監査してタグ付けおよび分類されていないデータを探し、そのデータを適切に分類してタグ付けします。
## リソース
**関連するドキュメント:**
+ [Leveraging AWS クラウド to Support Data Classification](https://docs.aws.amazon.com/whitepapers/latest/data-classification/leveraging-aws-cloud-to-support-data-classification.html) (AWS クラウドを活用したデータ分類のサポート)
+ [AWS Organizations のタグポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html)
**関連動画:**
+ [ Enabling agility with data governance on AWS](https://www.youtube.com/watch?v=vznDgJkoH7k)(AWS 上でのデータガバナンスで俊敏性を実現する)
# SUS04-BP02 データのアクセスパターンとストレージパターンをサポートするテクノロジーを使用する
データへのアクセス方法や保存方法を最もよくサポートするストレージ技術を使用し、ワークロードをサポートしながらプロビジョニングされるリソースを最小化します。
**一般的なアンチパターン:**
+ すべてのワークロードのデータの保存とアクセスのパターンが類似していると考えている。
+ ストレージ階層を 1 つだけ使用し、すべてのワークロードがその階層に適していると考えている。
+ 時間が経過してもデータアクセスパターンが変わらないと考えている。
**このベストプラクティスを活用するメリット:** データのアクセスとストレージのパターンに基づいてストレージ技術を選択し最適化すると、ビジネスニーズを満たすために必要なクラウドリソースが削減し、クラウドワークロードの全体的な効率が向上します。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
アクセスパターンに最適なストレージソリューションを選択するか、パフォーマンス効率を最大にするためにストレージソリューションに合わせてアクセスパターンを変更することを検討してください。
+ データの特徴とアクセスパターンを評価し、ストレージのニーズにおける主な特徴を収集します。考慮する主な特徴には次のものがあります。
+ **データタイプ:** 構造、半構造、非構造
+ **データの増加:** 制限あり、制限なし
+ **データの耐久性:** 永続、一過性、一時的
+ **アクセスパターン:** 読み取りまたは書き込み、頻度、急増、または安定
+ データの特徴とアクセスパターンをサポートする適切なストレージ技術にデータを移行します。AWS ストレージ技術とその主な特徴を例としていくつか挙げます。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2023-04-10/framework/sus_sus_data_a3.html)
+ Amazon EBS や Amazon FSx など固定サイズのストレージシステムの場合、利用可能なストレージ容量をモニタリングして、しきい値に達した場合のストレージ割り当てを自動化します。Amazon CloudWatch を活用して、 [Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using_cloudwatch_ebs.html) および [Amazon FSx のさまざまなメトリクスを収集および分析できます](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/monitoring-cloudwatch.html)。
+ Amazon S3 ストレージクラスは、オブジェクトレベルで設定でき、単一のバケットのすべてのストレージクラスのオブジェクトを含めることができます。
+ また、Amazon S3 ライフサイクルポリシーを使用して、アプリケーションを変更せずにストレージクラス間でオブジェクトを自動的に移動したり、データを削除したりすることができます。一般的に、このようなストレージメカニズムを考える場合、リソース効率、アクセスのレイテンシー、信頼性の間でトレードオフを行う必要があります。
## リソース
**関連するドキュメント:**
+ [Amazon EBS ボリュームタイプ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html)
+ [Amazon EC2 インスタンスストア](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html)
+ [Amazon S3 Intelligent-Tiering](https://docs.aws.amazon.com/AmazonS3/latest/userguide/intelligent-tiering.html)
+ [ Amazon EBS I/O の特性 ](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ebs-io-characteristics.html)
+ [ Amazon S3 のストレージクラスを使用する ](https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage-class-intro.html)
+ [Amazon Glacier とは?](https://docs.aws.amazon.com/amazonglacier/latest/dev/introduction.html)
**関連動画:**
+ [Architectural Patterns for Data Lakes on AWS](https://www.youtube.com/watch?v=XpTly4XHmqc&ab_channel=AWSEvents)
+ [ Deep dive on Amazon EBS (STG303-R1) ](https://www.youtube.com/watch?v=wsMWANWNoqQ)
+ [ Optimize your storage performance with Amazon S3 (STG343) ](https://www.youtube.com/watch?v=54AhwfME6wI)
+ [ Building modern data architectures on AWS](https://www.youtube.com/watch?v=Uk2CqEt5f0o)
**関連サンプル:**
+ [ Amazon EFS CSI Driver ](https://github.com/kubernetes-sigs/aws-efs-csi-driver)
+ [ Amazon EBS CSI Driver ](https://github.com/kubernetes-sigs/aws-ebs-csi-driver)
+ [ Amazon EFS Utilities ](https://github.com/aws/efs-utils)
+ [ Amazon EBS Autoscale ](https://github.com/awslabs/amazon-ebs-autoscale)
+ [ Amazon S3 のサンプル ](https://docs.aws.amazon.com/sdk-for-javascript/v2/developer-guide/s3-examples.html)
# SUS04-BP03 ポリシーを使用してデータセットのライフサイクルを管理する
すべてのデータのライフサイクルを管理し、自動的に削除を実行することで、ワークロードに必要なストレージの総量を最小限に抑えます。
**一般的なアンチパターン:**
+ データを手動で削除する。
+ ワークロードデータは削除しない。
+ データ保持やアクセス要件に基づいて、よりエネルギー効率の高いストレージ階層にデータを移動することがない。
**このベストプラクティスを活用するメリット:** データライフサイクルポリシーを使用することで、ワークロードのデータアクセスと保持を効率的に行うことができます。
**このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム
## 実装のガイダンス
データセットには通常、そのライフサイクルにおいて異なる保持要件とアクセス要件があります。例えば、限られた期間のみ頻繁にデータセットにアクセスする必要があるアプリケーションもあります。その後、それらのデータセットにアクセスすることはほとんどありません。
データセットをライフサイクル全体で効率的に管理するには、データセットの処理方法を定義するルールであるライフサイクルポリシーを設定します。
ライフサイクル設定ルールを使用すると、特定のストレージサービスに対して、データセットをよりエネルギー効率の高いストレージ層に移行する、アーカイブする、または削除するように指示できます。
**実装手順**
+ [ワークロード内のデータセットを分類します。](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sus_sus_data_a2.html)
+ データクラスごとに処理手順を定義します。
+ ライフサイクルルールを適用するための自動ライフサイクルポリシーを設定します。さまざまな AWS ストレージサービスの自動ライフサイクルポリシーを設定する方法の例を次に示します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2023-04-10/framework/sus_sus_data_a4.html)
+ 未使用のボリューム、スナップショット、保存期間を過ぎたデータを削除します。削除には、Amazon DynamoDB の有効期限や Amazon CloudWatch ログ保持などのネイティブサービス機能を活用します。
+ ライフサイクルルールに基づいて、該当する場合はデータを集約および圧縮します。
## リソース
**関連するドキュメント:**
+ [Optimize your Amazon S3 Lifecycle rules with Amazon S3 Storage Class Analysis ](https://docs.aws.amazon.com/AmazonS3/latest/userguide/analytics-storage-class.html)(Amazon S3 ストレージクラス分析によって Amazon S3 ライフサイクルルールを最適化する)
+ [AWS Config ルール を使用してリソースを評価する](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html)
**関連動画:**
+ [Simplify Your Data Lifecycle and Optimize Storage Costs With Amazon S3 Lifecycle ](https://www.youtube.com/watch?v=53eHNSpaMJI)(Amazon S3 ライフサイクルによってデータライフサイクルを簡素化し、ストレージコストを最適化する)
+ [Reduce Your Storage Costs Using Amazon S3 Storage Lens ](https://www.youtube.com/watch?v=A8qOBLM6ITY)(Amazon S3 ストレージレンズを使用してストレージコストを削減する)
# SUS04-BP04 伸縮性とオートメーションを使用してブロックストレージまたはファイルシステムを拡張する
伸縮性とオートメーションを使用して、データの増加につれてブロックストレージまたはファイルシステムを拡張し、プロビジョニングされるストレージの合計を最小化します。
**一般的なアンチパターン:**
+ 将来必要になるかもしれない大きなブロックストレージやファイルシステムを調達している。
+ ファイルシステムの IOPS (input and output operations per second、入出力操作毎秒) を過剰プロビジョニングしている。
+ データボリュームの使用率をモニターしていない。
**このベストプラクティスを活用するメリット:** ストレージシステムの過剰プロビジョニングを最小化すると、アイドル状態のリソースが削減され、ワークロード全体の効率が向上します。
**このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム
## 実装のガイダンス
ワークロードに適したサイズ割り当て、スループット、レイテンシーで、ブロックストレージやファイルシステムを作成します。伸縮性とオートメーションを使用して、データの増加につれてブロックストレージまたはファイルシステムを拡張し、これらのストレージサービスを過剰プロビジョニングしないようにします。
**実装手順**
+ [Amazon EBS](https://aws.amazon.com/ebs/) などの固定サイズのストレージシステムについては、使用済みのストレージの量を全体的なストレージサイズに照らしてモニタリングし、可能であれば、しきい値に到達したときにストレージサイズを増加させるオートメーションを作成していることを検証します。
+ 伸縮自在なボリュームとマネージド型のブロックデータサービスを使用して、永続的データの増加に応じて追加のストレージの割り当てを自動化します。例えば、[Amazon EBS Elastic Volumes](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modify-volume.html) を使用して、Amazon EBS ボリュームのボリュームサイズやボリュームタイプを変更したり、パフォーマンスを調整したりできます。
+ ファイルシステムに適したストレージクラス、パフォーマンスモード、スループットモードを選択して、ビジネスニーズを超えることなく対処できるようにします。
+ [ Amazon EFS パフォーマンス ](https://docs.aws.amazon.com/efs/latest/ug/performance.html)
+ [ Linux インスタンスでの Amazon EBS ボリュームのパフォーマンス ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSPerformance.html)
+ データボリュームの使用率の目標レベルを設定し、予想される範囲外のボリュームはサイズ変更します。
+ データに合わせて読み取り専用ボリュームのサイズを最適化します。
+ データをオブジェクトストアに移行して、ブロックストレージの固定ボリュームサイズを超える容量をプロビジョンするのを回避します。
+ 伸縮自在なボリュームやファイルシステムを定期的に見直して、アイドルなボリュームを停止し、現在のデータサイズに合わせて過剰プロビジョンされたリソースを縮小します。
## リソース
**関連するドキュメント:**
+ [Amazon FSx ドキュメント](https://docs.aws.amazon.com/fsx/index.html)
+ [What is Amazon Elastic File System?](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html) (Amazon Elastic File System とは)
**関連動画:**
+ [ Deep Dive on Amazon EBS Elastic Volumes ](https://www.youtube.com/watch?v=Vi_1Or7QuOg)(Amazon EBS Elastic Volumes の詳細)
+ [ Amazon EBS and Snapshot Optimization Strategies for Better Performance and Cost Savings ](https://www.youtube.com/watch?v=h1hzRCsJefs)(パフォーマンスとコスト節約の向上を目指した Amazon EBS とスナップショットの最適化戦略)
+ [ Optimizing Amazon EFS for cost and performance, using best practices ](https://www.youtube.com/watch?v=9kfeh6_uZY8)(ベストプラクティスを使用した Amazon EFS のコストとパフォーマンスの最適化)
# SUS04-BP04 不要なデータや重複するデータを削除する
不要なデータや重複するデータを削除し、データセットの保存に必要なストレージリソースを最小限に抑えます。
**一般的なアンチパターン:**
+ 簡単に取得または再作成できるデータを複製している。
+ データの重要性を考慮せず、すべてのデータをバックアップしている。
+ データの削除は、不定期、運用イベント時のみ、または全く行わない。
+ ストレージサービスの耐久性に関係なく、データを冗長に保存している。
+ ビジネス上の正当な理由なく Amazon S3 バージョニングを実行している。
**このベストプラクティスを確立するメリット:** 不要なデータを削除することで、ワークロードに必要なストレージサイズを縮小し、ワークロードの環境に対する影響も軽減します。
**このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム
## 実装のガイダンス
不要なデータを保存しない。不要なデータの削除を自動化する。ファイルおよびブロックレベルでデータの重複を排除するテクノロジーを使用する。サービスのネイティブデータレプリケーションと冗長性機能を活用する。
**実装手順**
+ [AWS Data Exchange](https://aws.amazon.com/data-exchange/) および[Open Data on AWS](https://registry.opendata.aws/)で公開されている既存のデータセットを利用することで、データの保存を回避できないかを評価します。
+ ブロックレベルとオブジェクトレベルでデータを重複排除できる仕組みを使用します。AWS でデータの重複をなくす方法の例を次に示します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2023-04-10/framework/sus_sus_data_a6.html)
+ データアクセスを分析し、不要なデータを特定します。ライフサイクルポリシーを自動化します。削除のための [Amazon DynamoDB 有効期限](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TTL.html)、[Amazon S3 ライフサイクル](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html)、[Amazon CloudWatch ログ保持](https://docs.aws.amazon.com/managedservices/latest/userguide/log-customize-retention.html)などのネイティブサービス機能を活用します。
+ AWS のデータ仮想化機能を使用してデータをソースに保持し、データの重複を回避します。
+ [AWS でのクラウドネイティブデータ仮想化](https://www.youtube.com/watch?v=BM6sMreBzoA)
+ [ラボ: Amazon Redshift データ共有を使用したデータパターンの最適化](https://wellarchitectedlabs.com/sustainability/300_labs/300_optimize_data_pattern_using_redshift_data_sharing/)
+ 増分バックアップが可能なバックアップテクノロジーを使用します。
+ セルフマネージドテクノロジー (RAID (Redundant Array of Independent Disks) など) の代わりに、[Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/DataDurability.html) の耐久性と [Amazon EBS のレプリケーション](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes.html)を活用して、耐久性の目標を達成します。
+ ログおよび追跡データを一元化し、同一のログエントリの重複を排除して、必要に応じて冗長性を調整するメカニズムを確立します。
+ キャッシュの事前入力は、正当な場合にのみ行います。
+ キャッシュのモニタリングとオートメーションを確立し、それに従ってキャッシュをサイズ変更します。
+ ワークロードの新しいバージョンをプッシュする際に、オブジェクトストアとエッジキャッシュから古いデプロイとアセットを削除します。
## リソース
**関連するドキュメント:**
+ [CloudWatch Logs のログデータ保持期間を変更する](https://docs.aws.amazon.com/Amazon/latest/logs/Working-with-log-groups-and-streams.html#SettingLogRetention)
+ [Amazon FSx for Windows File Server でのデータの重複排除](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-data-dedup.html)
+ [データの重複排除を含む Amazon FSx for ONTAP の機能](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/what-is-fsx-ontap.html#features-overview)
+ [Amazon CloudFront でのファイルの無効化](https://docs.aws.amazon.com/Amazon/latest/DeveloperGuide/Invalidation.html)
+ [AWS Backup を使用してバックアップを行い、Amazon EFS ファイルシステムを復元する](https://docs.aws.amazon.com/efs/latest/ug/awsbackup.html)
+ [Amazon CloudWatch Logs とは](https://docs.aws.amazon.com/Amazon/latest/logs/WhatIsLogs.html)
+ [Amazon RDS でのバックアップの操作](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html)
**関連動画:**
+ [Fuzzy Matching and Deduplicating Data with ML Transforms for AWS Lake Formation](https://www.youtube.com/watch?v=g34xUaJ4WI4) (AWS Lake Formation の機械学習トランスフォームによるファジーマッチングとデータの重複排除)
**関連する例:**
+ [Amazon Athena を使用して Amazon S3 サーバーのアクセスログを分析するにはどうすればよいですか?](https://aws.amazon.com/premiumsupport/knowledge-center/analyze-logs-athena/)
# SUS04-BP06 共有ファイルシステムまたはストレージを使用して共通データにアクセスする
共有ファイルシステムまたはストレージを導入して、データの重複を避け、ワークロードのインフラストラクチャの効率を向上させます。
**一般的なアンチパターン:**
+ クライアントそれぞれにストレージをプロビジョンしている。
+ 非アクティブなクライアントからデータボリュームをデタッチしていない。
+ プラットフォームやシステムを横断してストレージに対するアクセスを提供していない。
**このベストプラクティスを活用するメリット:** 共有のファイルシステムやストレージを使用すると、データをコピーすることなく、1 人以上のコンシューマーがデータを共有できます。これにより、ワークロードに必要なストレージリソースを削減できます。
**このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム
## 実装のガイダンス
同じデータセットにアクセスするユーザーやアプリケーションが複数の場合、共有ストレージ技術を使用することが、ワークロードの効率的なインフラストラクチャを実現するために重要です。共有ストレージ技術を利用すると、データセットを 1 か所で保存および管理し、データの重複を避けることができます。また、異なるシステム間でデータの一貫性を維持できます。さらに、共有ストレージ技術を利用すると、複数のコンピューティングリソースが並列して同時にデータにアクセスして処理できるため、コンピューティング性能をより効率的に使用できます。
必要なときにのみ、このような共有ストレージサービスからデータを取得し、未使用のボリュームはデタッチしてリソースを解放します。
**実装手順**
+ データに複数のコンシューマーが存在する場合は、データを共有ストレージに移行します。AWS の共有ストレージ技術の例をいくつか示します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2023-04-10/framework/sus_sus_data_a7.html)
+ 必要なときにのみ、共有ファイルシステムにデータをコピーしたり、共有ファイルシステムからデータを取得したりします。例えば、[Amazon S3 を搭載した Amazon FSx for Lustre ファイルシステム](https://aws.amazon.com/blogs/storage/new-enhancements-for-moving-data-between-amazon-fsx-for-lustre-and-amazon-s3/)を作成して、ジョブの処理に必要なデータのサブセットのみを Amazon FSx にロードできます。
+ [SUS04-BP03 ポリシーを使用してデータセットのライフサイクルを管理する](sus_sus_data_a4.md)に概説されているように、使用パターンに応じてデータを削除します。
+ クライアントがアクティブに使用していないボリュームをクライアントからデタッチします。
## リソース
**関連するドキュメント:**
+ [ Amazon S3 バケットにファイルシステムをリンクする ](https://docs.aws.amazon.com/fsx/latest/LustreGuide/create-dra-linked-data-repo.html)
+ [ Using Amazon EFS for AWS Lambda in your serverless applications ](https://aws.amazon.com/blogs/compute/using-amazon-efs-for-aws-lambda-in-your-serverless-applications/)(サーバーレスアプリケーションの AWS Lambda に Amazon EFS を使用する)
+ [ Amazon EFS Intelligent-Tiering Optimizes Costs for Workloads with Changing Access Patterns ](https://aws.amazon.com/blogs/aws/new-amazon-efs-intelligent-tiering-optimizes-costs-for-workloads-with-changing-access-patterns/)(Amazon EFS Intelligent-Tiering はアクセスパターンを変更しワークロードのコストを最適化する)
+ [ オンプレミスデータリポジトリで Amazon FSx を使用する ](https://docs.aws.amazon.com/fsx/latest/LustreGuide/fsx-on-premises.html)
**関連動画:**
+ [ Storage cost optimization with Amazon EFS ](https://www.youtube.com/watch?v=0nYAwPsYvBo)(Amazon EFS を使用したストレージコストの最適化)
# SUS04-BP07 ネットワーク間でのデータ移動を最小限に抑える
共通データへのアクセスに共有ファイルシステムまたはオブジェクトストレージを使用して、ワークロードにおけるデータ移動をサポートするために必要なネットワークリソースの総量を最小化します。
**一般的なアンチパターン:**
+ データユーザーの所在地とは別の、同じ AWS リージョンにすべてのデータを保存している。
+ データをネットワーク経由で移動する前に、データサイズや形式を最適化していない。
**このベストプラクティスを活用するメリット:** ネットワーク経由のデータの移動を最適化すると、ワークロードに必要なネットワークリソースの総量を削減でき、環境への影響を抑えることができます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
組織のあちこちにデータを移動するには、コンピューティング、ネットワーキング、ストレージのリソースが必要です。データ移動を最小限にするテクニックを使用して、ワークロード全体の効率を向上させます。
## 実装手順
+ ワークロードのリージョンを選択する際は、データまたはユーザーの近接性を [意思決定の要素として考慮します](https://aws.amazon.com/blogs/architecture/how-to-select-a-region-for-your-workload-based-on-sustainability-goals/)。
+ リージョン固有のデータが消費されるリージョン内に保存されるよう、リージョン内で消費されるサービスをパーティションします。
+ 効率的なファイル形式 (Parquet や ORC など) を使用してデータを圧縮してから、ネットワーク経由で移動します。
+ 未使用のデータは移動しないようにします。未使用のデータ移動を防止するために参考となる事例をいくつかご紹介します。
+ API リソースを関連データのみに削減します。
+ データは詳細 (レコードレベルの情報が不要) を集約します。
+ 詳細は、 [Well-Architected Lab - Optimize Data Pattern Using Amazon Redshift Data Sharing を参照してください](https://wellarchitectedlabs.com/sustainability/300_labs/300_optimize_data_pattern_using_redshift_data_sharing/)。
+ 検討 [AWS Lake Formation のクロスアカウントデータ共有を考慮します](https://docs.aws.amazon.com/lake-formation/latest/dg/cross-account-permissions.html)。
+ ワークロードのユーザーの近くでコードを実行できるサービスを使用します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2023-04-10/framework/sus_sus_data_a8.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/)
+ [AWS グローバルインフラストラクチャ](https://aws.amazon.com/about-aws/global-infrastructure/)
+ [Amazon CloudFront の主な特徴 (CloudFront グローバルエッジネットワークなど)](https://aws.amazon.com/cloudfront/features/)
+ [Amazon OpenSearch Service での HTTP リクエストの圧縮](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/gzip.html)
+ [Amazon EMR を使用して中間データを圧縮する](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-output-compression.html#HadoopIntermediateDataCompression)
+ [圧縮されたデータファイルを Amazon S3 から Amazon Redshift にロードする](https://docs.aws.amazon.com/redshift/latest/dg/t_loading-gzip-compressed-data-files-from-S3.html)
+ [Amazon CloudFront を使用して圧縮ファイルを提供する](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/ServingCompressedFiles.html)
**関連動画:**
+ [ Demystifying data transfer on AWS](https://www.youtube.com/watch?v=-MqXgzw1IGA)
**関連サンプル:**
+ [ 持続可能性を考慮したアーキテクチャ - ネットワーク間のデータ移動を最小限に抑える ](https://catalog.us-east-1.prod.workshops.aws/workshops/7c4f8394-8081-4737-aa1b-6ae811d46e0a/en-US)
# SUS04-BP08 データは再作成が難しい場合にのみバックアップする
ビジネス価値のないデータのバックアップを避け、ワークロードに必要なストレージリソースを最小化します。
**一般的なアンチパターン:**
+ データのバックアップ戦略がない。
+ 簡単に再作成できるデータをバックアップしている。
**このベストプラクティスを活用するメリット:** 重要ではないデータのバックアップを避けると、ワークロードに必要なストレージリソースを削減し、環境への影響を減らすことができます。
**このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム
## 実装のガイダンス
必要ではないデータのバックアップを避けると、コストを下げ、ワークロードが使用するストレージリソースを削減できます。ビジネス価値のあるデータまたはコンプライアンス要件を満たすために必要なデータのみをバックアップします。バックアップポリシーを精査し、リカバリーシナリオでは価値のないエフェメラルストレージを除外します。
**実装手順**
+ [SUS04-BP01 データ分類ポリシーを実装する](sus_sus_data_a2.md)で概説されているように、データ分類ポリシーを実装します。
+ データ分類の重要度を使用し、[目標復旧時間 (RTO) および目標復旧時点 (RPO)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_objective_defined_recovery.html) に基づいてバックアップ戦略を策定します。重要ではないデータのバックアップを避けます。
+ 簡単に再作成できるデータを除外します。
+ バックアップから一時データを除外します。
+ 共通の場所からデータを復元するために必要な時間がサービスレベルアグリーメント (SLA) を超える場合を除き、データのローカルコピーを除外します。
+ 自動化されたソリューションまたはマネージドサービスを使用してビジネスクリティカルなデータをバックアップします。
+ [AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) は、フルマネージドサービスで、AWS サービス、クラウド、オンプレミス全体にわたるデータ保護の一元化と自動化を容易にします。AWS Backup を使用した自動パックアップの作成方法に関するハンズオントレーニングについては、[Well-Architected Labs - Testing Backup and Restore of Data](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/) (Well-Architected ラボ - データのバックアップと復元のテスト) を参照してください。
+ [Automate backups and optimize backup costs for Amazon EFS using AWS Backup](https://aws.amazon.com/blogs/storage/automating-backups-and-optimizing-backup-costs-for-amazon-efs-using-aws-backup/) (AWS Backup を使用して Amazon EFS のバックアップを自動化しコストを最適化する)。
## リソース
**関連するベストプラクティス:**
+ [REL09-BP01 バックアップが必要なすべてのデータを特定し、バックアップする、またはソースからデータを再現する](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_backing_up_data_identified_backups_data.html)
+ [REL09-BP03 データバックアップを自動的に実行する](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_backing_up_data_automated_backups_data.html)
+ [REL13-BP02 復旧目標を満たすため、定義された復旧戦略を使用する](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_disaster_recovery.html)
**関連するドキュメント:**
+ [AWS Backup を使用してバックアップを行い、Amazon EFS ファイルシステムを復元する](https://docs.aws.amazon.com/efs/latest/ug/awsbackup.html)
+ [Amazon EBS スナップショット](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html)
+ [Amazon Relational Database Service でのバックアップの操作](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html)
+ [APN パートナー: バックアップを支援できるパートナー](https://partners.amazonaws.com/search/partners?keyword=Backup)
+ [AWS Marketplace: バックアップに活用できる製品](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [ Backing Up Amazon EFS ](https://docs.aws.amazon.com/efs/latest/ug/efs-backup-solutions.html)(Amazon EFS ファイルシステムのバックアップ)
+ [Amazon FSx for Windows File Server のバックアップ](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-backups.html)
+ [ Amazon ElastiCache (Redis OSS) のバックアップと復元 ](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/backups.html)
**関連動画:**
+ [AWS re:Invent 2021 - Backup, disaster recovery, and ransomware protection with AWS](https://www.youtube.com/watch?v=Ru4jxh9qazc)(AWS re:Invent 2021 - AWS によるバックアップ、ディザスタリカバリ、ランサムウェア保護)
+ [AWS Backup Demo: Cross-Account and Cross-Region Backup](https://www.youtube.com/watch?v=dCy7ixko3tE) (AWS Backup デモ: クロスアカウントおよびクロスリージョンバックアップ)
+ [AWS re:Invent 2019: Deep dive on AWS Backup, ft.Rackspace (STG341) ](https://www.youtube.com/watch?v=av8DpL0uFjc)(AWS re:Invent 2019: AWS Backup の詳細、Rackspace 特集 (STG341))
**関連する例:**
+ [ Well-Architected Lab - Testing Backup and Restore of Data ](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)(Well-Architected ラボ - デーのバックアップと復元のテスト)
+ [ Well-Architected Lab - Backup and Restore with Failback for Analytics Workload ](https://wellarchitectedlabs.com/reliability/200_labs/200_backup_restore_failback_analytics/)(Well-Architected ラボ - 分析ワークロードのフェイルバックによるバックアップと復元)
+ [ Well-Architected Lab - Disaster Recovery - Backup and Restore ](https://wellarchitectedlabs.com/reliability/disaster-recovery/workshop_1/)(Well-Architected ラボ - ディザスタリカバリ - バックアップと復元)
# ハードウェアとサービス
**Topics**
+ [SUS 5 アーキテクチャでクラウドのハードウェアとサービスをどのように選択して、持続可能性目標を達成しますか?](sus-05.md)
# SUS 5 アーキテクチャでクラウドのハードウェアとサービスをどのように選択して、持続可能性目標を達成しますか?
ハードウェア管理のプラクティスを変更することで、ワークロードの持続可能性に対する影響を軽減する機会を探します。プロビジョンおよびデプロイする必要があるハードウェア数を最小化し、個別のワークロードにおいて最も効率のいいハードウェアとサービスを選択します。
**Topics**
+ [SUS05-BP01 ニーズに合わせて最小限のハードウェアを使用する](sus_sus_hardware_a2.md)
+ [SUS05-BP02 影響が最も少ないインスタンスタイプを使用する](sus_sus_hardware_a3.md)
+ [SUS05-BP03 マネージドサービスを使用する](sus_sus_hardware_a4.md)
+ [SUS05-BP04 ハードウェアベースのコンピューティングアクセラレーターの使用を最適化する](sus_sus_hardware_a5.md)
# SUS05-BP01 ニーズに合わせて最小限のハードウェアを使用する
ワークロードには最小限のハードウェアを使用し、ビジネスニーズを効率的に満たします。
**一般的なアンチパターン:**
+ リソースの使用率をモニターしていない。
+ アーキテクチャに使用率が低いリソースがある。
+ 静的ハードウェアの使用率を見直してサイズを変更するかどうかを判断していない。
+ ビジネス KPI に基づいたコンピューティングインフラストラクチャのハードウェア使用率目標を設定していない。
**このベストプラクティスを活用するメリット:** クラウドリソースのサイズを最適化すると、環境に対するワークロードの影響を削減し、費用を節約して、パフォーマンスベンチマークを維持できます。
**このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム
## 実装のガイダンス
ワークロードに必要なハードウェアの総数を適切に選択して、全体の効率を改善します。AWS クラウドは、[AWS Auto Scaling](https://aws.amazon.com/autoscaling/) などのさまざまなメカニズムを通じて、リソース数を動的に拡張または縮小する柔軟性を提供し、需要の変化に対応します。AWS には、最低限の労力でリソースを変更できる [API や SDK](https://aws.amazon.com/developer/tools/) も用意されています。これらの機能を使用して、ワークロードの実装を頻繁に変更できます。さらに AWS ツールが提供するサイズ最適化のガイドラインを使用して、クラウドリソースを効率的に運用し、ビジネスニーズを満たすことができます。
**実装手順**
+ ニーズに最適なインスタンスタイプを選択します。
+ [ワークロードに適切な Amazon EC2 インスタンスタイプを選択する方法を教えてください。](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-instance-choose-type-for-workload/)
+ [ Amazon EC2 フリートの属性ベースのインスタンスタイプの選択](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-attribute-based-instance-type-selection.html)
+ [属性ベースのインスタンスタイプの選択を使用して Auto Scaling グループを作成します。](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-asg-instance-type-requirements.html)
+ ワークロードの変動に合わせて少しずつスケールします。
+ 複数のコンピューティング購入オプションを使用して、インスタンスの柔軟性、スケーラビリティ、コスト節約のバランスを取ります。
+ [オンデマンドインスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-on-demand-instances.html)は、インスタンスタイプ、ロケーション、処理時間に柔軟性がないワークロードで、新規かつステートフルな、スパイクが発生するワークロードに最適です。
+ [スポットインスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html)は、耐障害性が高く、柔軟性があるアプリケーションにおいて、他のオプションを補完する優れた方法です。
+ 自分のニーズ (AZ、リージョン、インスタンスファミリー、インスタンスタイプ) が変化した場合に柔軟に対応できる安定した状態のワークロードには、[Compute Savings Plans](https://aws.amazon.com/savingsplans/compute-pricing/) を活用します。
+ さまざまなインスタンスやアベイラビリティーゾーンを使用して、アプリケーションの可用性を最大化し、可能なときは余剰キャパシティを活用します。
+ AWS ツールの適切なサイズのレコメンデーションを使用して、ワークロードを調整します。
+ [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
+ 容量の一時的な削減ができるようにサービスレベルアグリーメント (SLA) を交渉すると同時に、オートメーションを使用して代替リソースをデプロイします。
## リソース
**関連するドキュメント:**
+ [Optimizing your AWS Infrastructure for Sustainability, Part I: Compute ](https://aws.amazon.com/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-i-compute/)(サステナビリティのための AWS インフラストラクチャの最適化、パート I : コンピューティング)
+ [ Attribute based Instance Type Selection for Auto Scaling for Amazon EC2 Fleet ](https://aws.amazon.com/blogs/aws/new-attribute-based-instance-type-selection-for-ec2-auto-scaling-and-ec2-fleet/)(EC2 フリート向け Auto Scaling 用の属性ベースのインスタンスタイプの選択)
+ [AWS Compute Optimizer ドキュメント ](https://docs.aws.amazon.com/compute-optimizer/index.html)
+ [Operating Lambda: Performance optimization](https://aws.amazon.com/blogs/compute/operating-lambda-performance-optimization-part-2/) (Lambda の操作: パフォーマンス最適化 – パート 2)
+ [Auto Scaling のドキュメント](https://docs.aws.amazon.com/autoscaling/index.html)
**関連動画:**
+ [Build a cost-, energy-, and resource-efficient compute environment (コスト面、エネルギー面、リソース面で効率的なコンピューティング環境の構築)](https://www.youtube.com/watch?v=8zsC5e1eLCg)
**関連する例:**
+ [ Well-Architected Lab - Rightsizing with AWS Compute Optimizer and Memory Utilization Enabled (Level 200) ](https://www.wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/5_ec2_computer_opt/)(Well-Architected ラボ - AWS Compute Optimizer およびメモリ使用率の有効化によるサイズ最適化 (レベル 200))
# SUS05-BP02 影響が最も少ないインスタンスタイプを使用する
新しいインスタンスタイプを継続的にモニターして使用し、エネルギー効率の改善を活用します。
**一般的なアンチパターン:**
+ インスタンスの 1 つのファミリーのみを使用する。
+ x86 インスタンスのみを使用する。
+ Amazon EC2 Auto Scaling 設定で 1 つのインスタンスタイプを指定する。
+ AWS インスタンスが設計されていない方法で使用されている (例えば、メモリ集中型のワークロードに計算用に最適化されたインスタンスを使用した場合)。
+ 新しいインスタンスタイプを定期的に評価しない。
+ 次のような AWS サイズ最適化ツールからのレコメンデーションを確認しない : [AWS Compute Optimizer。](https://aws.amazon.com/compute-optimizer/)
**このベストプラクティスを活用するメリット:** エネルギー効率が高く、適切なサイズのインスタンスを使用することで、環境への影響とワークロードのコストを大幅に削減できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
クラウドワークロードに効率的なインスタンスを使用することは、リソースの使用量を下げ、コスト効率を高めるために重要です。新しいインスタンスタイプのリリースを継続的にモニターし、エネルギー効率の改善を活用します。例えば、機械学習のトレーニングや推論、ビデオのトランスコーディングなど、特定のワークロードをサポートするように設計されたインスタンスタイプなどです。
## 実装手順
+ ワークロード環境への影響を削減できるインスタンスタイプを学習し、試します。
+ 例えば、 [AWS の最新情報](https://aws.amazon.com/new/) を購読して、最新の AWS テクノロジーとインスタンスの情報を入手します。
+ さまざまな AWS インスタンスタイプについて学びます。
+ Amazon EC2 のエネルギー使用量 1 ワットあたりで最高のパフォーマンスを発揮する AWS Graviton ベースのインスタンスについて、以下のビデオをご覧ください。 [re:Invent 2020 - Deep dive on AWS Graviton2 processor-powered Amazon EC2 instances (AWS Graviton2 プロセッサ搭載 Amazon EC2 インスタンスの詳細)](https://www.youtube.com/watch?v=NLysl0QvqXU) と [Deep dive into AWS Graviton3 and Amazon EC2 C7g instances](https://www.youtube.com/watch?v=WDKwwFQKfSI&ab_channel=AWSEvents).
+ ワークロードを計画し、最も影響の少ないインスタンスタイプに移行することができます。
+ ワークロードの新機能やインスタンスを評価するプロセスを定義します。クラウドの俊敏性を利用して、新しいインスタンスタイプがワークロード環境の持続可能性をどのように改善するかをすばやくテストします。プロキシメトリクスを使用して、1 つの作業単位を完了するのに必要なリソース数を測定します。
+ 可能な場合は、異なる数の vCPU と異なる量のメモリで動作するようにワークロードを変更して、インスタンスタイプの選択肢を最大化します。
+ ワークロードのパフォーマンス効率を向上させるために、Graviton ベースのインスタンスへの移行を検討します。
+ [AWS Graviton Fast Start](https://aws.amazon.com/ec2/graviton/fast-start/)
+ [Considerations when transitioning workloads to AWS Graviton-based Amazon Elastic Compute Cloud instances](https://github.com/aws/aws-graviton-getting-started/blob/main/transition-guide.md)
+ [AWS Graviton2 for ISVs を参照](https://docs.aws.amazon.com/whitepapers/latest/aws-graviton2-for-isv/welcome.html)
+ 以下の利用において、AWS Graviton オプションの選択を検討します : [AWS マネージドサービス。](https://github.com/aws/aws-graviton-getting-started/blob/main/managed_services.md)
+ 持続可能性に対する影響が最も少なく、かつビジネス要件を満たすインスタンスを提供するリージョンにワークロードを移行します。
+ 機械学習のワークロードには、 [AWS Trainium](https://aws.amazon.com/machine-learning/trainium/)、 [AWS Inferentia](https://aws.amazon.com/machine-learning/inferentia/)、および [Amazon EC2 DL1 など、ワークロードに特化した専用ハードウェアを利用します。](https://aws.amazon.com/ec2/instance-types/dl1/) Inf2 インスタンスなどの AWS Inferentia インスタンスは、同等の Amazon EC2 インスタンスと比較してワットあたりのパフォーマンスが最大 50% 向上します。
+ [Amazon SageMaker AI Inference Recommender](https://docs.aws.amazon.com/sagemaker/latest/dg/inference-recommender.html) を使用して、機械学習推論エンドポイントのサイズを適切に設定します。
+ ワークロードの急増 (追加のキャパシティが必要になることがあまりないワークロード) の場合は、 [バーストパフォーマンスインスタンスを使用します。](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances.html)
+ ステートレスで耐障害性の高いワークロードについては、 [Amazon EC2 スポットインスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html) を使用して、クラウドの全体使用率を高め、未使用のリソースの持続可能性に対する影響を軽減します。
+ ワークロードインスタンスを操作して、最適化します。
+ 一次的なワークロードについては、 [インスタンス Amazon CloudWatch メトリクス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html#ec2-cloudwatch-metrics) ( `CPUUtilization` など) を評価して、インスタンスがアイドルか使用率が低いかを識別します。
+ 安定したワークロードの場合は、AWS サイズ適正化ツール ( [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) など) を定期的にチェックし、インスタンスの最適化とサイズ適正化の機会を識別します。
+ [ Well-Architected Lab - Rightsizing Recommendations (Well-Architected ラボ - サイズ最適化のレコメンデーション) ](https://wellarchitectedlabs.com/cost/100_labs/100_aws_resource_optimization/)
+ [ Well-Architected Lab - Rightsizing with Compute Optimizer (Well-Architected ラボ - Compute Optimizer を使用したサイズ最適化) ](https://wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/)
+ [ Well-Architected Lab - Optimize Hardware Patterns and Observe Sustainability KPIs (Well-Architected ラボ - ハードウェアパターンの最適化と持続可能性 KPI の観察) ](https://wellarchitectedlabs.com/sustainability/200_labs/200_optimize_hardware_patterns_observe_sustainability_kpis/)
## リソース
**関連するドキュメント:**
+ [持続可能性のために AWS インフラストラクチャを最適化する、パート I: コンピューティング](https://aws.amazon.com/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-i-compute/)
+ [AWS Graviton](https://aws.amazon.com/ec2/graviton/)
+ [Amazon EC2 DL1 など、ワークロードに特化した専用ハードウェアを利用します](https://aws.amazon.com/ec2/instance-types/dl1/)
+ [Amazon EC2 キャパシティ予約フリート](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/cr-fleets.html)
+ [Amazon EC2 スポットフリート](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-fleet.html)
+ [関数: Lambda 関数の設定](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html#function-configuration)
+ [ Amazon EC2 フリートの属性ベースのインスタンスタイプの選択 ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-attribute-based-instance-type-selection.html)
+ [AWS での持続可能で効率的、コストが最適化されたアプリケーションの構築](https://aws.amazon.com/blogs/compute/building-sustainable-efficient-and-cost-optimized-applications-on-aws/)
+ [ Contino サステナビリティダッシュボードがお客様のカーボンフットプリントの最適化に役立つ仕組み ](https://aws.amazon.com/blogs/apn/how-the-contino-sustainability-dashboard-helps-customers-optimize-their-carbon-footprint/)
**関連動画:**
+ [Deep dive on AWS Graviton2 processor-powered Amazon EC2 instances (AWS Graviton2 プロセッサ搭載 Amazon EC2 インスタンスの詳細)](https://www.youtube.com/watch?v=NLysl0QvqXU)
+ [Deep dive into AWS Graviton3 and Amazon EC2 C7g instances](https://www.youtube.com/watch?v=WDKwwFQKfSI&ab_channel=AWSEvents)
+ [ Build a cost-, energy-, and resource-efficient compute environment (コスト面、エネルギー面、リソース面で効率的なコンピューティング環境の構築) ](https://www.youtube.com/watch?v=8zsC5e1eLCg)
**関連サンプル:**
+ [ Solution: Guidance for Optimizing Deep Learning Workloads for Sustainability on AWS (ソリューション: AWS における持続可能性に向けた深層学習ワークロードの最適化ガイダンス) ](https://aws.amazon.com/solutions/guidance/optimizing-deep-learning-workloads-for-sustainability-on-aws/)
+ [Well-Architected Lab - Rightsizing Recommendations (Well-Architected ラボ - サイズ最適化のレコメンデーション)](https://wellarchitectedlabs.com/cost/100_labs/100_aws_resource_optimization/)
+ [Well-Architected Lab - Rightsizing with Compute Optimizer (Well-Architected ラボ - Compute Optimizer を使用したサイズ最適化)](https://wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/)
+ [Well-Architected Lab - Optimize Hardware Patterns and Observe Sustainability KPIs (Well-Architected ラボ - ハードウェアパターンの最適化と持続可能性 KPI の観察)](https://wellarchitectedlabs.com/sustainability/200_labs/200_optimize_hardware_patterns_observe_sustainability_kpis/)
+ [ Well-Architected Lab - Migrating Services to Graviton (Well-Architected ラボ - サービスの Graviton への移行) ](https://www.wellarchitectedlabs.com/sustainability/100_labs/100_migrate_services_to_graviton/)
# SUS05-BP03 マネージドサービスを使用する
マネージドサービスを使用して、クラウドでより効率的に運用します。
**一般的なアンチパターン:**
+ アプリケーションの実行に使用率が低い Amazon EC2 インスタンスを使用している。
+ 社内チームはワークロードの管理のみを行っており、イノベーションや簡易化に焦点を当てる時間がない。
+ マネージドサービスではより効率的に実行できるタスク向けの技術をデプロイして維持している。
**このベストプラクティスを活用するメリット:**
+ マネージドサービスを使用すると、AWS に責任を移行できます。AWS は、数百万のお客様から得られたインサイトで、新規イノベーションと効率性を促進しています。
+ マネージドサービスは、マルチテナントコントロールプレーンのおかげで、サービスの環境に対する影響を、多くのお客様に分散します。
**このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム
## 実装のガイダンス
マネージドサービスは、使用率を高く保つ責任と、デプロイされたハードウェアの持続可能性に対する最適化の責任を AWS に移します。また、マネージドサービスによって、サービス維持に伴う運用上および管理上の負担が軽減されるため、チームに時間の余裕ができイノベーションに集中できます。
ワークロードを見直して、AWS マネージドサービスに置き換えることができるコンポーネントを特定します。例えば、[Amazon RDS](https://aws.amazon.com/rds/)、[Amazon Redshift](https://aws.amazon.com/redshift/)、[Amazon ElastiCache](https://aws.amazon.com/elasticache/) は、マネージドデータベースサービスを提供します。[Amazon Athena](https://aws.amazon.com/athena/)、[Amazon EMR](https://aws.amazon.com/emr/)、[Amazon OpenSearch Service](https://aws.amazon.com/opensearch-service/) はマネージド分析サービスを提供します。
**実装手順**
1. サービスとコンポーネントのワークロードをリストアップします。
1. コンポーネントを評価して、マネージドサービスに置き換えることができるものを特定します。マネージドサービスの使用を検討する場合の例を次に示します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2023-04-10/framework/sus_sus_hardware_a4.html)
1. 依存関係を特定して移行計画を作成します。同様にランブックやプレイブックも更新します。
+ [AWS Application Discovery Service](https://aws.amazon.com/application-discovery/) は、アプリケーションの依存関係と使用状況に関する詳細な情報を自動的に収集して提示するサービスです。これにより、充分な情報に基づいて移行計画の意思決定を行うことができます。
1. サービスをテストしてから、マネージドサービスに移行します。
1. 移行計画を使用して、自己ホスト型サービスをマネージドサービスに置き換えます。
1. 移行完了後は、サービスを継続的にモニターして、必要に応じて調整しサービスを最適化します。
## リソース
**関連するドキュメント:**
+ [AWS クラウド 製品](https://aws.amazon.com/products/)
+ [AWS 総保有コスト (TCO) 計算ツール](https://calculator.aws/#/)
+ [Amazon DocumentDB](https://aws.amazon.com/documentdb/)
+ [Amazon Elastic Kubernetes Service (EKS)](https://aws.amazon.com/eks/)
+ [Amazon Managed Streaming for Apache Kafka (Amazon MSK)](https://aws.amazon.com/msk/)
**関連動画:**
+ [ Cloud operations at scale with AWS Managed Services](https://www.youtube.com/watch?v=OCK8GCImWZw)(AWS マネージドサービスを使用した大規模なクラウド運用)
# SUS05-BP04 ハードウェアベースのコンピューティングアクセラレーターの使用を最適化する
高速コンピューティングインスタンスの使用を最適化することで、ワークロードの物理インフラストラクチャの需要を低減します。
**一般的なアンチパターン:**
+ GPU の使用状況を監視していない。
+ 専用インスタンスがより高い性能、低コスト、ワットあたりの性能を実現できるのに対し、ワークロードに汎用インスタンスを使用している。
+ CPU ベースのコンピューティングアクセラレーターを使用した方が効率的なタスクに、ハードウェアベースのコンピューティングアクセラレーターを使用している。
**このベストプラクティスを活用するメリット:** ハードウェアベースのアクセラレーターの使用を最適化することで、ワークロードの物理インフラストラクチャの需要を低減できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
高い処理能力が必要な場合、高速コンピューティングインスタンスを使用すると、グラフィック処理ユニット (GPU) やフィールドプログラマブルゲートアレイ (FPGA) などのハードウェアベースのコンピューティングアクセラレーターを利用できるというメリットが得られます。これらのハードウェアアクセラレーターは、グラフィック処理やデータパターンマッチングなどの特定の機能を、CPU ベースの代替手段よりも効率的に実行します。レンダリング、トランスコーディング、機械学習など、多くの高速ワークロードは、リソースの使用量に大きなばらつきがあります。このハードウェアは必要な時間だけ実行し、不要になったら自動で廃止することで、消費されるリソースを最小化します。
## 実装手順
+ どの [高速コンピューティングインスタンスが](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/accelerated-computing-instances.html) お客様の要件に対応できるかを特定します。
+ 機械学習のワークロードには、 [AWS Trainium](https://aws.amazon.com/machine-learning/trainium/)、 [AWS Inferentia](https://aws.amazon.com/machine-learning/inferentia/)、 [Amazon EC2 DL1 など、ワークロードに特化した専用ハードウェアを利用します](https://aws.amazon.com/ec2/instance-types/dl1/)。Inf2 インスタンスなどの AWS Inferentia インスタンスは、 [Amazon EC2 インスタンスと比較して、ワットあたりのパフォーマンスが最大 50% 向上します](https://aws.amazon.com/machine-learning/inferentia/)。
+ 高速コンピューティングインスタンスの使用状況メトリクスを収集します。例えば、CloudWatch エージェントを使用して、GPU の `utilization_gpu` および `utilization_memory` などのメトリクスを収集できます ( [「Amazon CloudWatch で NVIDIA GPU メトリクスを収集する」を参照)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-NVIDIA-GPU.html)。
+ ハードウェアアクセラレーターのコード、ネットワーク操作、設定を最適化し、基盤となるハードウェアが十分に活用されるようにします。
+ [GPU 設定を最適化する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/optimize_gpu.html)
+ [Deep Learning AMI での GPU のモニタリングと最適化](https://docs.aws.amazon.com/dlami/latest/devguide/tutorial-gpu.html)
+ [Amazon SageMaker AI における深層学習トレーニングの GPU パフォーマンスチューニングのための I/O の最適化](https://aws.amazon.com/blogs/machine-learning/optimizing-i-o-for-gpu-performance-tuning-of-deep-learning-training-in-amazon-sagemaker/)
+ 最新の高性能ライブラリと GPU ドライバーを使用します。
+ 使用しないときは、自動化を使用して GPU インスタンスを解放します。
## リソース
**関連するドキュメント:**
+ [高速コンピューティング](https://aws.amazon.com/ec2/instance-types/#Accelerated_Computing)
+ [ Let's Architect\$1 Architecting with custom chips and accelerators ](https://aws.amazon.com/blogs/architecture/lets-architect-custom-chips-and-accelerators/)
+ [ ワークロードに適切な Amazon EC2 インスタンスタイプを選択する方法を教えてください。 ](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-instance-choose-type-for-workload/)
+ [Amazon EC2 VT1 インスタンス](https://aws.amazon.com/ec2/instance-types/vt1/)
+ [Amazon Elastic Graphics](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/elastic-graphics.html)
+ [ Choose the best AI accelerator and model compilation for computer vision inference with Amazon SageMaker AI ](https://aws.amazon.com/blogs/machine-learning/choose-the-best-ai-accelerator-and-model-compilation-for-computer-vision-inference-with-amazon-sagemaker/)
**関連動画:**
+ [ 深層学習用の Amazon EC2 GPU インスタンスの選択方法 ](https://www.youtube.com/watch?v=4bVrIbgGWEA)
+ [Amazon EC2 Elastic GPU の詳細](https://www.youtube.com/watch?v=HbJ2xxgrcCE)
+ [Deploying Cost-Effective Deep Learning Inference (費用対効果の高い深層学習推論の導入)](https://www.youtube.com/watch?v=WiCougIDRsw)
# プロセスと文化
**Topics**
+ [SUS 6 組織のプロセスは、持続可能性目標の達成にどのように役立ちますか?](sus-06.md)
# SUS 6 組織のプロセスは、持続可能性目標の達成にどのように役立ちますか?
開発、テスト、デプロイのプラクティスを変更することで、持続可能性に対する影響を減らす機会を探します。
**Topics**
+ [SUS06-BP01 持続可能性の改善を迅速に導入できる方法を採用する](sus_sus_dev_a2.md)
+ [SUS06-BP02 ワークロードを最新に保つ](sus_sus_dev_a3.md)
+ [SUS06-BP03 ビルド環境の利用率を高める](sus_sus_dev_a4.md)
+ [SUS06-BP04 マネージド型 Device Farm を使用してテストする](sus_sus_dev_a5.md)
# SUS06-BP01 持続可能性の改善を迅速に導入できる方法を採用する
改善の可能性の検証、テストコストの最小化、小規模な改善の提供を行う手段やプロセスを導入します。
**一般的なアンチパターン:**
+ 持続可能性についてアプリケーションをレビューするのは、プロジェクトの開始時に 1 回だけである。
+ リリースプロセスが複雑すぎてリソース効率化のための小規模な変更を導入しづらいため、ワークロードが古くなった。
+ 持続可能性のためにワークロードを改善する仕組みがない。
**このベストプラクティスを活用するメリット:** 持続可能性に関する改善を導入および追跡するプロセスを確立することで、継続的に新しい機能や能力を導入し、問題を排除して、ワークロードの効率を向上させることができます。
**このベストプラクティスが確立されていない場合のリスクレベル:** 中
## 実装のガイダンス
本稼働環境にデプロイする前に、持続可能性を改善できるかをテストして検証します。改善に際して将来的に起こりうる利点を計算する際のテストにかかるコストを考慮します。低コストのテスト方法を開発し、小規模な改善を実施します。
**実装手順**
+ 持続可能性の改善に関する要件を開発バックログに追加します。
+ 反復的な[改善プロセス](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/improvement-process.html)を使用して、これらの改善を特定、評価、優先順位付け、テスト、デプロイします。
+ 開発プロセスを継続的に改善および合理化します。例えば、[継続的な統合および配信 (CI/CD) パイプラインを使用してソフトウェア配信プロセスを自動化して](https://aws.amazon.com/getting-started/hands-on/set-up-ci-cd-pipeline/)、工数レベルを削減し手動プロセスで発生するエラーを減らす可能性のある改善をテストしデプロイします。
+ 最小限に実行可能である代表的なコンポーネントを使用して、潜在的な改善を開発およびテストし、テストのコストを削減します。
+ 改善の影響を継続的に評価し、必要に応じて調整します。
## リソース
**関連するドキュメント:**
+ [AWS がサステナビリティソリューションを実現](https://aws.amazon.com/sustainability/)
+ [ Scalable agile development practices based on AWS CodeCommit](https://aws.amazon.com/blogs/devops/scalable-agile-development-practices-based-on-aws-codecommit/)(AWS CodeCommit に基づいたスケーラブルなアジャイル開発の実践)
**関連動画:**
+ [ Delivering sustainable, high-performing architectures ](https://www.youtube.com/watch?v=FBc9hXQfat0)(持続可能でパフォーマンスが高いアーキテクチャを実現する)
**関連する例:**
+ [Well-Architected Lab - Turning cost & usage reports into efficiency reports](https://www.wellarchitectedlabs.com/sustainability/300_labs/300_cur_reports_as_efficiency_reports/) (Well-Architected ラボ - コストと使用状況レポートを効率性レポートに変える)
# SUS06-BP02 ワークロードを最新に保つ
ワークロードを最新の状態に保ち、効率的な機能を導入し、問題を排除し、ワークロード全体の効率性を向上させます。
**一般的なアンチパターン:**
+ 現在のアーキテクチャが今後は静的なものとなり、しばらく更新されないと考えている。
+ 更新されたソフトウェアおよびパッケージがワークロードと互換性があるかどうかを評価するためのシステムまたは定期的な予定がない。
**このベストプラクティスを活用するメリット:** ワークロードを最新に保つプロセスを確立することで、新しい機能と能力を採用し、問題を解決し、ワークロードの効率性を高めることができます。
**このベストプラクティスが確立されていない場合のリスクレベル:** 低
## 実装のガイダンス
最新のオペレーティングシステム、ランタイム、ミドルウェア、ライブラリ、アプリケーションを使用すると、ワークロードの効率が上がり、さらに効率的なテクノロジーを簡単に導入できます。最新のソフトウェアにはまた、ワークロードの持続可能性に対する影響をより正確に測定する機能が含まれている場合があります。これは、ベンダーが独自の持続可能性の目標を満たすための機能でもあります。定期的に最新の機能やリリースを導入し、ワークロードを最新に保ちます。
**実装手順**
+ ワークロードに応じた新しい機能やインスタンスを評価するプロセスとスケジュールを定義します。クラウドの俊敏性を利用して、新しい機能がワークロードをどのように改善するかをすばやくテストします。
+ 持続可能性への影響を削減する。
+ パフォーマンスの効率を高める。
+ 計画した改善にとっての障壁を取り除く。
+ 持続可能性に対する影響の測定能力と管理能力を高める。
+ ワークロードソフトウェアおよびアーキテクチャをインベントリに登録して、更新する必要があるコンポーネントを特定する。
+ [AWS Systems Manager インベントリ](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-inventory.html)を使用して、Amazon EC2 インスタンスからオペレーティングシステム (OS)、アプリケーション、インスタンスのメタデータを収集し、どのインスタンスがソフトウェアポリシーで要求されるソフトウェアと設定を実行しているか、どのインスタンスが更新する必要があるかを迅速に把握できます。
+ ワークロードのコンポーネントを更新する方法を理解します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2023-04-10/framework/sus_sus_dev_a3.html)
+ 更新プロセスにオートメーションを使用して、新しい機能をデプロイする労力のレベルを軽減し、手動プロセスに起因するエラーを抑制します。
+ [CI/CD](https://aws.amazon.com/blogs/devops/complete-ci-cd-with-aws-codecommit-aws-codebuild-aws-codedeploy-and-aws-codepipeline/) を使用して、AMI、コンテナイメージ、その他クラウドアプリケーションに関連するアーティファクトを自動的に更新できます。
+ [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) などのツールを使用して、システム更新のプロセスを自動化し、[AWS Systems Manager Maintenance Windows](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-maintenance.html) を使用してアクティビティをスケジュールできます。
## リソース
**関連するドキュメント:**
+ [AWS アーキテクチャセンター](https://aws.amazon.com/architecture)
+ [AWS の最新情報](https://aws.amazon.com/new/?ref=wellarchitected&ref=wellarchitected)
+ [AWS のデベロッパー用ツール](https://aws.amazon.com/products/developer-tools/)
**関連する例:**
+ [ Well-Architected Labs: Inventory and Patch Management ](https://wellarchitectedlabs.com/operational-excellence/100_labs/100_inventory_patch_management/)(Well-Architected ラボ: インベントリおよびパッチ管理)
+ [Lab: AWS Systems Manager](https://mng.workshop.aws/ssm.html) (ラボ: AWS Systems Manager)
# SUS06-BP03 ビルド環境の利用率を高める
リソースの使用率を上げて、ワークロードを開発、テスト、構築します。
**一般的なアンチパターン:**
+ ビルド環境を手動でプロビジョニングおよび停止している。
+ テスト、ビルド、リリースアクティビティとは無関係にビルド環境を実行し続けている (例えば、開発チームメンバーの就業時間外に環境を実行している)。
+ ビルド環境にリソースを過剰プロビジョニングしている。
**このベストプラクティスを活用するメリット:** ビルド環境の使用率を上げることで、構築者が効率的に開発、テスト、構築できるようにリソースを配分しながら、クラウドワークロード全体の効率を上げることができます。
**このベストプラクティスが確立されていない場合のリスクレベル:** 低
## 実装のガイダンス
オートメーションと Infrastructure as Code を使用して、必要に応じてビルド環境を起動し、使用しないときは停止します。一般的なパターンとしては、開発チームのメンバーの勤務時間と重なるように可用性期間のスケジュールを設定することがあります。テスト環境は、本稼働構成とよく似たものにする必要があります。ただし、バーストキャパシティ、Amazon EC2 スポットインスタンス、自動スケールするデータベースサービス、コンテナ、サーバーレステクノロジーを備えたインスタンスタイプを使用して、開発およびテストのキャパシティを使用に合わせて調整できる機会を探ります。データ量を、テスト要件を満たす量だけに制限します。本稼働データをテストに使用する場合は、データを移動するのではなく、本稼働環境とデータを共有できる可能性を探ります。
**実装手順**
+ Infrastructure-as-Code を使用してビルド環境をプロビジョニングします。
+ オートメーションを使用して開発環境とテスト環境のライフサイクルを管理し、ビルド用リソースの効率を最大化します。
+ 開発環境とテスト環境を最大限に活用する戦略を使用します。
+ 最小限に実行可能である代表的な環境を使用して、潜在的な改善を開発およびテストします。
+ 可能な限り、サーバーレス技術を利用します。
+ オンデマンドインスタンスを使用して開発者のデバイスを補完します。
+ バーストキャパシティ、スポットインスタンス、その他のテクノロジーを備えたインスタンスタイプを使用して、ビルドキャパシティを使用状況に合わせて調整します。
+ 踏み台ホストのフリートをデプロイするのではなく、ネイティブなクラウドサービスを採用して、インスタンスシェルのアクセスを保護します。
+ ビルドジョブに合わせてビルドリソースを自動的にスケールします。
## リソース
**関連するドキュメント:**
+ [AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html)
+ [Amazon EC2 バーストパフォーマンスインスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances.html)
+ [AWS CloudFormation の概要](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
+ [AWS CodeBuild とは](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)
+ [AWS での Instance Scheduler ](https://aws.amazon.com/solutions/implementations/instance-scheduler-on-aws/)
**関連動画:**
+ [ Continuous Integration Best Practices ](https://www.youtube.com/watch?v=77HvSGyBVdU)(継続的インテグレーションのベストプラクティス)
# SUS06-BP04 マネージド型 Device Farm を使用してテストする
マネージド型 Device Farm を使用して、ハードウェアの代表的なセットで新機能を効率的にテストします。
**一般的なアンチパターン:**
+ 個別の物理デバイス上で、アプリケーションを手動でテストおよびデプロイしている。
+ アプリケーションテストサービスを使用せずに、実際の物理デバイス上でアプリケーションをテストおよび操作している (Android、iOS、ウェブアプリケーションなど)。
**このベストプラクティスを活用するメリット:** マネージド型 Device Farm を使用してクラウド対応アプリケーションをテストすると、多くのメリットがあります。
+ 幅広い種類のデバイスでアプリケーションをテストする、より効率的な機能などです。
+ これにより、テスト用の社内インフラストラクチャが必要なくなります。
+ あまり使われない古いハードウェアを含む、さまざまデバイスタイプが提供されているため、不要なデバイスをアップグレードする必要がなくなります。
**このベストプラクティスが確立されていない場合のリスクレベル:** 低
## 実装のガイダンス
マネージド型 Device Farm を使用すると、代表的な一連のハードウェアで新機能をテストするプロセスを合理化できます。マネージド型 Device Farm は、あまり使われない古いハードウェアを含むさまざまなデバイスタイプを提供するため、不要なデバイスのアップグレードによるお客様の持続可能性に対する影響を回避できます。
**実装手順**
+ テストの要件と計画 (テストの種類、オペレーティングシステム、テストのスケジュールなど) を定義します。
+ [Amazon CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html) を使用して、クライアント側のデータを収集および分析し、テスト計画を策定できます。
+ テスト要件をサポートできるマネージド型 Device Farm を選択します。例えば、[AWS Device Farm](https://docs.aws.amazon.com/devicefarm/latest/developerguide/welcome.html) を使用して、代表的な一連のハードウェア上での変更の影響をテストし把握できます。
+ 継続的統合/継続的デプロイ (CI/CD) を使用して、テストをスケジュールし実行します。
+ [ Integrating AWS Device Farm with your CI/CD pipeline to run cross-browser Selenium tests ](https://aws.amazon.com/blogs/devops/integrating-aws-device-farm-with-ci-cd-pipeline-to-run-cross-browser-selenium-tests/)(AWS Device Farm を CI/CD パイプラインに統合してブラウザ間で Selenium のテストを実行する)
+ [ Building and testing iOS and iPadOS apps with AWS DevOps and mobile services ](https://aws.amazon.com/blogs/devops/building-and-testing-ios-and-ipados-apps-with-aws-devops-and-mobile-services/)(AWS DevOps およびモバイルサービスを使用して iOS および iPadOS アプリケーションを構築およびテストする)
+ テスト結果を継続的に見直し、必要な改善を行います。
## リソース
**関連するドキュメント:**
+ [AWS Device Farm デバイスリスト ](https://awsdevicefarm.info/)
+ [ CloudWatch RUM ダッシュボードの表示 ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM-view-data.html)
**関連する例:**
+ [AWS Device Farm Sample App for Android ](https://github.com/aws-samples/aws-device-farm-sample-app-for-android)
+ [AWS Device Farm Sample App for iOS ](https://github.com/aws-samples/aws-device-farm-sample-app-for-ios)
+ [ Appium Web tests for AWS Device Farm](https://github.com/aws-samples/aws-device-farm-sample-web-app-using-appium-python)
**関連動画:**
+ [ Optimize applications through end user insights with Amazon CloudWatch RUM ](https://www.youtube.com/watch?v=NMaeujY9A9Y)(Amazon CloudWatch RUM を使用したエンドユーザーインサイトを通してアプリケーションを最適化する)