# ベストプラクティス
<a name="sus-bp"></a>

**Topics**
+ [リージョンの選択](sus-region-selection.md)
+ [需要に合わせた調整](sus-user-behavior-patterns.md)
+ [ソフトウェアとアーキテクチャ](sus-software-architecture-patterns.md)
+ [データ管理](sus-data-patterns.md)
+ [ハードウェアとサービス](sus-hardware-patterns.md)
+ [プロセスと文化](sus-development-deployment-patterns.md)

# リージョンの選択
<a name="sus-region-selection"></a>

ワークロードのためのリージョンの選択は、パフォーマンス、コスト、カーボンフットプリントなどの KPI に大きく影響します。これらの KPI を改善するには、ビジネス要件と持続可能性の目標の両方に基づいて、ワークロードのリージョンを選択する必要があります。

 以下の質問は、持続可能性に関する考慮事項に焦点を当てています。(持続可能性に関する質問とベストプラクティスの一覧については、[付録](a-sustainability.md)をご覧ください)。


| SUS 1: ワークロードにリージョンを選択する方法 | 
| --- | 
| ワークロードのためのリージョンの選択は、パフォーマンス、コスト、カーボンフットプリントなどの KPI に大きく影響します。これらの KPI を改善するには、ビジネス要件と持続可能性の目標の両方に基づいて、ワークロードのリージョンを選択する必要があります。 | 

# 需要に合わせた調整
<a name="sus-user-behavior-patterns"></a>

ユーザーとアプリケーションがワークロードやその他のリソースを使用する方法によって、持続可能性の目標を達成するための改善点を特定できます。継続的に需要に合うようにインフラストラクチャをスケールし、ユーザーをサポートするために必要な最小リソースのみを使用していることを検証します。サービスレベルをお客様のニーズと整合させます。ユーザーとアプリケーションがリソースを消費するために必要なネットワークを制限できるようにリソースを配置します。未使用のアセットを削除します。チームメンバーには、ニーズをサポートし持続可能性への影響を最小限にするデバイスを提供します。

 以下の質問は、持続可能性に関する、この考慮事項に焦点を当てています。


| SUS 2: クラウドリソースを需要に合わせる方法 | 
| --- | 
|  ユーザーとアプリケーションがワークロードやその他のリソースを使用する方法によって、持続可能性の目標を達成するための改善点を特定できます。継続的に需要に合うようにインフラストラクチャをスケールし、ユーザーをサポートするために必要な最小リソースのみを使用していることを検証します。サービスレベルをお客様のニーズと整合させます。ユーザーとアプリケーションがリソースを消費するために必要なネットワークを制限できるようにリソースを配置します。未使用のアセットを削除します。チームメンバーには、ニーズをサポートし持続可能性への影響を最小限にするデバイスを提供します。  | 

ユーザーの負荷に応じてインフラストラクチャをスケールする: 使用率が低い、または使用されていない期間を特定し、リソースをスケールして、余分な容量を削減し効率性を改善します。

持続可能性目標に応じた SLA の調整: 可用性やデータ保持期間などに関するサービスレベルアグリーメント (SLA) を定義し更新して、引き続きビジネス要件を満たしながら、ワークロードをサポートするために必要なリソース数を最小化します。

使用されていないアセットの作成と保守をなくす: アプリケーションアセット (事前コンパイル済みのレポート、データセット、静的イメージなど) とアセットのアクセスパターンを分析し、冗長性、低使用率、および廃止できそうなターゲットを特定します。生成されたアセットを冗長性コンテンツ (重複または共通のデータセットと出力が含まれる月次レポートなど) と統合し、出力が重複する際に消費されるリソースを削減します。使用されていないアセット (既に販売していない製品の画像など) を廃止し、消費されていたリソースを解放して、ワークロードをサポートするために使用されるリソース数を削減します。

ユーザーの場所に応じてワークロードの地理的配置を最適化する: ネットワークのアクセスパターンを分析し、顧客が地理的にどこから接続しているかを特定します。ネットワークトラフィックが経由しなければならない距離を削減できるリージョンとサービスを選択し、ワークロードをサポートするために必要なネットワークリソースの総量を減らします。

実行されるアクティビティに応じてチームメンバーのリソースを最適化する: チームメンバーに提供されるリソースを最適化することで、ニーズをサポートしながら持続可能性への影響を最小限に抑えます。例えば、レンダリングやコンパイルなどの複雑なオペレーションを、使用率が低く高パワーの単一のユーザーシステムで行うのではなく、使用率の高い共有クラウドデスクトップで行います。

# ソフトウェアとアーキテクチャ
<a name="sus-software-architecture-patterns"></a>

負荷平滑化を実行しデプロイされたリソースが一貫して高使用率で維持されるパターンを実装し、リソースの消費を最小化します。時間の経過とともにユーザーの行動が変化したため、コンポーネントが使用されずアイドル状態になることがあります。パターンとアーキテクチャを改定して、使用率の低いコンポーネントを統合し、全体の使用率を上げます。不要になったコンポーネントは廃止します。ワークロードコンポーネントのパフォーマンスを理解し、リソースの消費が最も大きいコンポーネントを最適化します。顧客がお客様のサービスにアクセスするために使用するデバイスを把握し、デバイスをアップグレードする必要性を最小化するパターンを実装します。

 以下の質問は、持続可能性に関する考慮事項に焦点を当てています。


| SUS 3: ソフトウェアとアーキテクチャのパターンをどのように利用して、持続可能性目標を目指しますか? | 
| --- | 
|  負荷平滑化を実行しデプロイされたリソースが一貫して高使用率で維持されるパターンを実装し、リソースの消費を最小化します。時間の経過とともにユーザーの行動が変化したため、コンポーネントが使用されずアイドル状態になることがあります。パターンとアーキテクチャを改定して、使用率の低いコンポーネントを統合し、全体の使用率を上げます。不要になったコンポーネントは廃止します。ワークロードコンポーネントのパフォーマンスを理解し、リソースの消費が最も大きいコンポーネントを最適化します。顧客がお客様のサービスにアクセスするために使用するデバイスを把握し、デバイスをアップグレードする必要性を最小化するパターンを実装します。  | 

スケジュールされた非同期のジョブに応じてソフトウェアとアーキテクチャを最適化する: 効率的なソフトウェア設計とアーキテクチャを使用し、作業単位ごとに必要な平均リソースを最小化します。コンポーネントの使用率が平均化されるメカニズムを実装し、タスクの合間でアイドルになるリソースを削減して、負荷のスパイクの影響を最小化します。

低使用率または使用されてないワークロードコンポーネントを削除またはリファクタリングする: ワークロードアクティビティをモニタリングして、個別のコンポーネントの時間経過による使用率の変化を特定します。未使用や不要のコンポーネントを削除し、使用率が低いコンポーネントはリファクタリングして、無駄になるリソースを制限します。

時間またはリソースの大部分を消費しているコード領域を最適化する: ワークロードアクティビティをモニタリングして、リソースを最も多く消費しているアプリケーションコンポーネントを特定します。それらのコンポーネント内で実行されているコードを最適化して、パフォーマンスを最大化しながらリソースの使用量を最小化します。

顧客のデバイスや機器への影響を最適化する: お客様のサービスを利用するために顧客が使用しているデバイスや機器、その予想ライフサイクル、およびそれらのコンポーネントを交換することによる財務および持続可能性に対する影響を理解します。顧客のデバイスの交換や機器のアップグレードの必要性を最小化するソフトウェアパターンとアーキテクチャを実装します。例えば、新機能の実装には、より古いハードウェアやオペレーティングシステムのバージョンと後方互換性のあるコードを使用します。また、ペイロードのサイズを管理して、対象デバイスのストレージ容量を超えないようにします。

データアクセスとストレージのパターンを最も効果的にサポートできるソフトウェアパターンとアーキテクチャを使用する: データがワークロード内でどのように使用され、ユーザーによってどのように消費され、どのように転送および保存されているかを理解します。データの処理と保存の要件を最小化するテクノロジーを選択します。

# データ管理
<a name="sus-data-patterns"></a>

 以下の質問は、持続可能性に関する考慮事項に焦点を当てています。


| SUS 4: データ管理のポリシーとパターンをどのように利用して、持続可能性目標を達成しますか? | 
| --- | 
|  データ管理プラクティスを実装して、ワークロードのサポートに必要なプロビジョンされたストレージと、それを使用するために必要なリソースを削減します。データを理解し、データのビジネス価値とデータの使用方法を最も効果的にサポートするストレージテクノロジーと設定を使用します。必要性が小さくなった場合はより効率的で性能を落としたストレージにデータをライフサイクルし、データが不要になった場合は削除します。  | 

データ分類ポリシーを実装する: データを分類して、ビジネス成果にとっての重要性を理解します。この情報を使用して、データをよりエネルギー効率が高いストレージに移動するタイミングや、安全に削除するタイミングを検討します。

データアクセスとストレージのパターンをサポートするテクノロジーを使用する: データへのアクセス方法や保存方法を最も効果的にサポートするストレージを使用し、ワークロードをサポートしながら、プロビジョニングされるリソースを最小化します。例えば、ソリッドステートドライブ (SSD) は磁気式ドライブよりもエネルギー消費が大きいため、アクティブなデータのユースケースのみに使用するべきです。アクセスの少ないデータに対して、エネルギー効率の高いアーカイブクラスのストレージを使用します。

ライフサイクルポリシーを使用して、不要なデータを削除する: すべてのデータのライフサイクルを管理し、削除タイムラインを自動的に適用して、ワークロードに必要な合計ストレージを最小化します。

ブロックストレージの過剰プロビジョニングを最小化する: プロビジョニングされる合計ストレージを最小化するには、ワークロードに適したサイズ割り当てのブロックストレージを作成します。伸縮自在なボリュームを使用し、データの増加に合わせて、コンピューティングリソースに添付されたストレージをサイズ変更することなく拡張します。伸縮自在なボリュームを定期的に確認し、現在のデータサイズに合わせてプロビジョンされたボリュームを縮小します。

不要なデータまたは冗長なデータを削除する: データの複製は必要なときにのみ行い、消費される合計ストレージを最小化します。ファイルおよびブロックレベルでデータの重複を排除するバックアップテクノロジーを使用します。SLA の要件を満たすために必要な場合を除き、RAID (Redundant Array of Independent Drives) 設定の仕様を制限します。

共有データへのアクセスには共有ファイルシステムまたはオブジェクトストレージを使用する: 共有ストレージと単一の信頼できるソースを採用し、データの複製を避けてワークロードに必要な合計ストレージを削減します。必要に応じて共有ストレージからデータを取得します。未使用なボリュームをデタッチしてリソースを解放します。ネットワーク間でのデータ移動を最小限に抑える: 共有ストレージを使用し、その地域のデータストアからデータにアクセスして、ワークロードにおけるデータ移動をサポートするために必要なネットワークリソースの総量を最小化します。

再作成が困難なときのみデータをバックアップする: ストレージの消費を最小化するには、ビジネス価値のあるデータまたはコンプライアンス要件を満たすために必要なデータのみをバックアップします。バックアップポリシーを精査し、リカバリシナリオでは価値のないエフェメラルストレージを除外します。

# ハードウェアとサービス
<a name="sus-hardware-patterns"></a>

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

 以下の質問は、持続可能性に関する考慮事項に焦点を当てています。


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

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

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

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

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

# プロセスと文化
<a name="sus-development-deployment-patterns"></a>

開発、テスト、デプロイのプラクティスを変更することで、持続可能性に対する影響を減らす機会を探します。

 以下の質問は、持続可能性に関する考慮事項に焦点を当てています。


| SUS 6: 組織のプロセスは、持続可能性目標の達成にどのように役立ちますか? | 
| --- | 
|  開発、テスト、デプロイのプラクティスを変更することで、持続可能性に対する影響を減らす機会を探します。  | 

持続可能性の改善を迅速に導入できるオペレーションを採用する: 潜在的な改善をテストおよび検証してから、本稼働環境にデプロイします。改善に際して将来的に起こりうる利点を計算する際のテストにかかるコストを考慮します。低コストのテストオペレーションを開発し、小規模な改善を推進します。

ワークロードを最新に保つ: 最新のオペレーティングシステム、ライブラリ、およびアプリケーションを使用すると、ワークロードの効率が高まり、より効率的なテクノロジーを実現できます。最新のソフトウェアにはまた、ワークロードの持続可能性に対する影響をより正確に測定する機能が含まれている場合があります。これは、ベンダーが独自の持続可能性の目標を満たすための機能でもあります。

ビルド環境の利用率を高める: オートメーションと Infrastructure as Code を使用して、必要に応じて本番稼働前の環境を起動し、使用しないときは停止します。一般的なパターンとしては、開発チームのメンバーの勤務時間と重なるように可用性期間のスケジュールを設定することがあります。休止は、状態を維持し、必要なときにのみインスタンスを迅速にオンラインにする便利な手段です。バーストキャパシティ、スポットインスタンス、伸縮自在なデータベースサービス、コンテナ、その他のテクノロジーを備えたインスタンスタイプ使用して、開発およびテストのキャパシティを使用に合わせて調整します。

テストにマネージド型のデバイスファームを使用する: マネージド型のデバイスファームは、ハードウェアの製造やリソースの使用が持続可能性に及ぼす影響を複数のテナントに分散させます。マネージド型 Device Farm は、さまざまなデバイスタイプを提供するため、あまり使われない古いハードウェアをサポートすることで、不要なデバイスのアップグレードによるお客様の持続可能性に対する影響を回避できます。