

# ハードウェアパターン
<a name="a-sus-hardware-patterns"></a>

**Topics**
+ [SUS 5 ハードウェアの管理および使用のプラクティスは、持続可能性目標を目指すうえでどのように役立ちますか?](w2aac19c15c13b5.md)

# SUS 5 ハードウェアの管理および使用のプラクティスは、持続可能性目標を目指すうえでどのように役立ちますか?
<a name="w2aac19c15c13b5"></a>

ハードウェア管理のプラクティスを変更することで、ワークロードの持続可能性に対する影響を軽減する機会を探します。プロビジョンおよびデプロイする必要があるハードウェア数を最小化し、個別のワークロードにおいて最も効率のいいハードウェアを選択します。 

 ベストプラクティス: 

# SUS05-BP01 ニーズに合わせて最小限のハードウェアを使用する
<a name="sus_sus_hardware_a2"></a>

 クラウドの能力を使用して、ワークロードの実装を頻繁に変更できます。ニーズの変化に応じて、デプロイされたコンポーネントを更新します。 

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

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  水平スケーリングを有効にし、オートメーションを使用して、負荷の増加に応じてスケールアウトし、負荷の減少に応じてスケールインします。 
+  ワークロードの変動に合わせて少しずつスケールします。 
+  スケーリングを周期的な使用パターンに合わせます (例えば、ペイロードシステムを隔週の負荷の高いプロセッシングアクティビティに合わせます)。負荷は日、週、月、年によって異なるためです。 
+  容量の一時的な削減ができるようにサービスレベルアグリーメント (SLA) を交渉すると同時に、オートメーションを使用して代替リソースをデプロイします。 

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

 **関連するドキュメント:** 
+  [AWS Compute Optimizer のドキュメント](https://docs.aws.amazon.com/compute-optimizer/index.html) 
+  [Lambda のオペレーション: パフォーマンスの最適化](https://aws.amazon.com/blogs/compute/operating-lambda-performance-optimization-part-2/) 
+  [Auto Scaling のドキュメント](https://docs.aws.amazon.com/autoscaling/index.html) 

# SUS05-BP02 影響が最も少ないインスタンスタイプを使用する
<a name="sus_sus_hardware_a3"></a>

 新しいインスタンスタイプのリリースを継続的にモニタリングし、機械学習のトレーニング、推論、ビデオのトランスコーディングなどの特定のワークロードをサポートするように設計されたインスタンスタイプを含む、エネルギー効率の改善を活用します。 

 **一般的なアンチパターン:** 
+  インスタンスの 1 つのファミリーのみを使用する。 
+  x86 インスタンスのみを使用する。 
+  Amazon EC2 Auto Scaling 設定で 1 つのインスタンスタイプを指定する。 
+  AWS インスタンスが設計されていない方法で使用されている (たとえば、メモリ集中型のワークロードに計算用に最適化されたインスタンスを使用した場合)。 
+  新しいインスタンスタイプを定期的に評価しない。 
+  次のような AWS サイズ最適化ツールからのレコメンデーションを確認しない : [AWS Compute Optimizer。](https://aws.amazon.com/compute-optimizer/) 

 **このベストプラクティスを活用するメリット:** エネルギー効率が高く、適切なサイズのインスタンスを使用することで、環境への影響とワークロードのコストを大幅に削減できます。 

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

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  ワークロード環境への影響を削減できるインスタンスタイプを学習し、試します。 
  +  例えば、 [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/) と [AWS Graviton2 for ISVs を参照](https://docs.aws.amazon.com/whitepapers/latest/aws-graviton2-for-isv/welcome.html)) を指定する必要があります。ワークロードを [AWS Graviton ベースの Amazon Elastic Compute Cloud インスタンスに移行する際の考慮事項を覚えておいてください。](https://github.com/aws/aws-graviton-getting-started/blob/main/transition-guide.md) 
  +  以下の利用において、AWS Graviton オプションの選択を検討します : [AWS マネージドサービス。](https://github.com/aws/aws-graviton-getting-started/blob/main/managed_services.md) 
  +  持続可能性に対する影響が最も少なく、かつビジネス要件を満たすインスタンスを提供するリージョンにワークロードを移行します。 
  +  機械学習ワークロードの場合は、次のようなカスタム Amazon Machine Learning チップに基づく Amazon EC2 インスタンスを使用します : [AWS Trainium](https://aws.amazon.com/machine-learning/trainium/)io1 [AWS Inferentia](https://aws.amazon.com/machine-learning/inferentia/)、および [Amazon EC2 DL1。](https://aws.amazon.com/ec2/instance-types/dl1/) 
  +  予想されるコストと使用状況に合わせたカスタムの予算を設定するには、 [Amazon SageMaker AI Inference Recommender](https://docs.aws.amazon.com/sagemaker/latest/dg/inference-recommender.html) を使用して、機械学習推論エンドポイントのサイズを適切に設定します。 
  +  リアルタイムの動画トランスコーディングを伴うワークロードについては、 [Amazon EC2 VT1 インスタンスを使用します。](https://aws.amazon.com/ec2/instance-types/vt1/) 
  +  スパイキーなワークロード (追加のキャパシティが必要になることがあまりないワークロード) の場合は、 [バーストパフォーマンスインスタンスを使用します。](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/) など) を定期的にチェックし、インスタンスの最適化とサイズ適正化の機会を識別します。 

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

 **関連するドキュメント:** 
+  [持続可能性のために 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/) 
+  [AWS Inferentia](https://aws.amazon.com/machine-learning/inferentia/) 
+  [AWS Trainium](https://aws.amazon.com/machine-learning/trainium/) 
+  [Amazon EC2 DL1](https://aws.amazon.com/ec2/instance-types/dl1/) 
+  [Amazon EC2 バーストパフォーマンスインスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances.html) 
+  [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) 
+  [Amazon EC2 スポットインスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html) 
+  [Amazon EC2 VT1 インスタンス](https://aws.amazon.com/ec2/instance-types/vt1/) 
+  [Amazon EC2 インスタンスタイプ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html) 
+  [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) 
+  [関数: Lambda 関数の設定](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html#function-configuration) 

 **関連動画:** 
+  [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) 

 **関連する例:** 
+  [ラボ: 適切なサイズのレコメンデーション](https://wellarchitectedlabs.com/cost/100_labs/100_aws_resource_optimization/) 
+  [ラボ: Compute Optimizer によるサイズ適正化](https://wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/) 
+  [ラボ: ハードウェアパターンの最適化と持続可能性 KPI の観察](https://wellarchitectedlabs.com/sustainability/200_labs/200_optimize_hardware_patterns_observe_sustainability_kpis/) 

# SUS05-BP03 マネージドサービスを使用する
<a name="sus_sus_hardware_a4"></a>

 マネージドサービスは、平均使用率を高く保つ責任と、デプロイされたハードウェアの持続可能性に対する最適化の責任を AWS に移します。マネージドサービスを使用して、サービスの持続可能性に対する影響を、そのサービスのすべてのテナント間に分散し、お客様単体の関与を軽減します。 

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

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  自己ホスト型サービスからマネージドサービスに移行します。例えば、マネージド型の [Amazon Relational Database Service (Amazon RDS)](https://aws.amazon.com/rds/) インスタンスを使用するか (独自の Amazon RDS インスタンスを [Amazon Elastic Compute Cloud (Amazon EC2) ](https://aws.amazon.com/ec2/)で維持する代わりに)、あるいは [AWS Fargate](https://aws.amazon.com/fargate/)のようなマネージドコンテナサービスを (独自のコンテナインフラストラクチャを実装する代わりに) 使用します。 

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

 **関連するドキュメント:** 
+  [AWS Fargate](https://aws.amazon.com/fargate/) 
+  [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/) 
+  [Amazon Redshift](https://aws.amazon.com/redshift/) 
+  [Amazon Relational Database Service (RDS)](https://aws.amazon.com/rds/) 

# SUS05-BP04 GPU の使用を最適化する
<a name="sus_sus_hardware_a5"></a>

 グラフィック処理ユニット (GPU) は高電力消費のソースになることがあります。GPU ワークロードの種類は多く、レンダリング、トランスコーディング、機械学習トレーニング、モデリングなどさまざまです。GPU インスタンスは必要な時間だけ実行し、必要がないときはオートメーションで廃棄して、消費されるリソースを最小化します。 

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

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  GPU は、CPU ベースの代替手段より効率的な場合にのみ、タスクに使用します。 
+  使用しないときは、オートメーションを使用して GPU インスタンスを解放します。 
+  専用の GPU インスタンスではなく、柔軟なグラフィックスアクセラレーションを使用します。 
+  ワークロードに特化したカスタムの専用ハードウェアを活用します。 

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

 **関連するドキュメント:** 
+  [高速コンピューティング](https://aws.amazon.com/ec2/instance-types/#Accelerated_Computing) 
+  [AWS Inferentia](https://aws.amazon.com/machine-learning/inferentia/) 
+  [AWS Trainium](https://aws.amazon.com/machine-learning/trainium/) 
+  [EC2 インスタンスの高速コンピューティング](https://aws.amazon.com/ec2/instance-types/#Accelerated_Computing) 
+  [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) 