持続可能性

持続可能性の柱には、持続可能性を守ることで、お客さまのビジネスが環境、経済、社会に与える長期的な影響を解決します。国際連合の「環境と開発に関する世界委員会」は、持続可能な開発を「将来の世代のニーズを満たす能力を損なうことなく、現在のニーズを満たす開発」と定義しています。 お客様の企業または組織が、環境によくない影響を与える可能性があります。直接的または間接的な炭素排出量、再利用できない廃棄物、清浄水などの共有資源に対するダメージなどです。が含まれます。

クラウドワークロードの構築において、持続可能性の実践とは、使用しているサービスの影響の理解、ワークロードのライフサイクル全体における影響の数値化、および設計原則とベストプラクティスの適用によるそれら影響の軽減化です。持続可能性の柱は、環境に対する影響、特にエネルギーの消費と効率性に焦点を当てています。アーキテクトにとって、リソースの使用量を削減するための直接的な対応がわかる重要な手段であるためです。

設計の原則

クラウドでの持続可能性には、6 つの設計原則があります。

定義

クラウドでの持続可能性には、6 つのベストプラクティスの分野があります。

アーキテクチャは、ワークロードの持続可能性に影響を与えます。ワークロードの配置を最適化します。また、ユーザー、ソフトウェア、データ、ハードウェア、開発とデプロイパターンのアーキテクチャを最適化して、エネルギー効率を高めます。それぞれの分野で、クラウドワークロードの持続可能性に対する影響を削減するためのベストプラクティスがあります。使用率を最大化し、無駄や、ワークロードをサポートするためにデプロイされ電力を消費するリソース総量を最小化する方法です。

アーキテクチャの改善プロセスには、現状と改善策の把握、改善対象の選択、改善のテスト、優れた改善策の採用、成功例の定量化、他でも再現できるように得られた知見の共有、サイクルの繰り返しがあります。

改善の目標には次のようなものがあります。

最適化の初期段階では、まず無駄が多く使用率が低い分野に焦点を当て、次に特定のワークロードに合った、ターゲットを絞った最適化に移行します。

リソースの消費量の変化を経時的にモニターします。変化の蓄積によりリソース消費が非効率的または著しく増加している箇所を特定します。消費の変化を解決するために改善が必要かどうかを検討し、優先順位の高い改善を実装します。

ベストプラクティス

リージョンの選択

ビジネス要件と持続可能性目標の両方に基づいて、ワークロードを実装するリージョンを選択します。

AWS はどのクラウドプロバイダーよりも広範なフットプリントを世界中で提供しており、お客様が世界のどこでも確実に利用できるように、新しいリージョンを急ピッチで開設しています。AWS は、複数の地理的リージョンを維持しています。例えば北米、南米、欧州、中国、アジア太平洋、南アフリカ、中東などのリージョンです。

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

SUS 1: リージョンをどのように選択して、持続可能性目標を目指しますか?

Amazon の再生可能エネルギープロジェクトに近いリージョンであり、グリッドの公開されている炭素集約度が他の場所 (またはリージョン) よりも低いリージョンを選択します。

ユーザーパターン

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

AWS では、マネージドモニタリングツールを使用して、ユーザーパターンの分析、デプロイされたリソースのオートスケーリングの管理、AWS のグローバルインフラストラクチャを活用したワークロードの地理的な配置の最適化を実現できます。

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

SUS 2: ユーザーの行動パターンをどのように利用して、持続可能性目標を目指しますか?

次のプラクティスを検討してください。

  • 使用率が低い、または使用されていない期間を特定し、リソースをスケールして余分な容量を排除し効率性を改善します。
  • 可用性やデータ保持期間などに関するサービスレベルアグリーメント (SLA) を定義し更新して、引き続きビジネス要件を満たしながら、ワークロードをサポートするために必要なリソース数を最小化します。
  • アプリケーションアセット (事前コンパイル済みのレポート、データセット、静的イメージなど) とアセットのアクセスパターンを分析し、冗長性、低使用率、および廃止できそうなターゲットを特定します。生成されたアセットを冗長性コンテンツ (重複または共通のデータセットと出力が含まれる月次レポートなど) と統合し、出力が重複する際に消費されるリソースをなくします。使用されていないアセット (既に販売していない製品の画像など) を廃止し、消費されていたリソースを解放して、ワークロードをサポートするために使用されるリソース数を削減します。
  • ネットワークのアクセスパターンを分析し、顧客が地理的にどこから接続しているかを特定します。ネットワークトラフィックが経由しなければならない距離を削減できるリージョンとサービスを選択し、ワークロードをサポートするために必要なネットワークリソースの総量を減らします。
  • チームメンバーに提供されるリソースを最適化することで、ニーズをサポートしながら持続可能性への影響を最小限に抑えます。例えば、レンダリングやコンパイルなどの複雑なオペレーションを、使用率が低く高パワーの単一のユーザーシステムで行うのではなく、使用率の高い共有クラウドデスクトップで行います。

ソフトウェアとアーキテクチャのパターン

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

AWS では、ワークロードのデベロッパーが自分の好きな言語とテクノロジーを使用できるため、特定の問題に対して最適なテクノロジーを選択できます。

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

SUS 3: ソフトウェアとアーキテクチャのパターンをどのように利用して、持続可能性目標を目指しますか?

次のプラクティスを検討してください。

  • ソフトウェアの効率的な設計とアーキテクチャを使用し、作業単位で必要な平均リソースを最小化します。コンポーネントの使用率が平均化されるメカニズムを実装し、タスクの合間でアイドルになるリソースを削減して、負荷のスパイクの影響を最小化します。
  • ワークロードアクティビティをモニターして、個別のコンポーネントの時間経過による使用率の変化を特定します。未使用や不要のコンポーネントを削除し、使用率が低いコンポーネントはリファクタリングして、無駄になるリソースを制限します。
  • ワークロードアクティビティをモニターして、リソースの消費が最も大きいアプリケーションコンポーネントを特定します。それらのコンポーネント内で実行されているコードを最適化して、パフォーマンスを最大化しながらリソースの使用量を最小化します。
  • お客さまのサービスを利用するために顧客が使用しているデバイスや機器、その予想ライフサイクル、およびそれらのコンポーネントを交換することによる金融および持続可能性に対する影響を理解します。顧客のデバイスの交換や機器のアップグレードの必要性を最小化するソフトウェアパターンとアーキテクチャを実装します。例えば、新機能の実装には、より古いハードウェアやオペレーティングシステムのバージョンと後方互換性のあるコードを使用します。また、ペイロードのサイズを管理して、対象デバイスのストレージ容量を超えないようにします。
  • データがどのようにワークロード内で使用されているか、ユーザーに消費されているか、転送されているか、保存されているかを理解します。データの処理と保存の要件を最小化するテクノロジーを選択します。

データパターン

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

AWS では、データアセットのライフサイクルにタグ付けして管理できます。これにより、ワークロードに最も適切なストレージクラスの選択を自動化できます。

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

SUS 4: データのアクセスパターンおよび使用パターンをどのように利用して、持続可能性目標を目指しますか?

次のプラクティスを検討してください。

  • データを分類して、ビジネス成果にとっての重要性を理解します。この情報を使用して、データをよりエネルギー効率が高いストレージに移動するタイミングや、安全に削除するタイミングを検討します。
  • データへのアクセス方法や保存方法をもっともよくサポートするストレージを使用し、ワークロードをサポートしながらプロビジョニングされるリソースを最小化します。例えば、ソリッドステートドライブ (SSD) は磁気式ドライブよりもエネルギー消費が大きいため、アクティブなデータのユースケースのみに使用するべきです。アクセスの少ないデータに対して、エネルギー効率の高いアーカイブクラスのストレージを使用します。
  • データすべてのライフサイクルを管理し、削除のタイムラインを自動的に適用して、ワークロードに必要な合計ストレージを最小化します。
  • プロビジョニングされる合計ストレージを最小化するには、ワークロードに適したサイズ割り当てのブロックストレージを作成します。伸縮自在なボリュームを使用し、データの増加に合わせて、コンピューティングリソースに添付されたストレージをサイズ変更することなく拡張します。伸縮自在なボリュームを定期的に確認し、現在のデータサイズに合わせてプロビジョンされたボリュームを縮小します。
  • データの複製は必要なときにのみ行い、消費される合計ストレージを最小化します。ファイルおよびブロックレベルでデータの重複を排除するバックアップテクノロジーを使用します。SLA の要件を満たすために必要な場合を除き、RAID (Redundant Array of Independent Drives) 設定の仕様を制限します。
  • 共有ストレージと単一の信頼できるソースを採用し、データの複製を避けてワークロードに必要な合計ストレージを削減します。必要に応じて共有ストレージからデータを取得します。未使用なボリュームをデタッチしてリソースを解放します。ネットワーク間でのデータ移動を最小限に抑える: 共有ストレージを使用し、その地域のデータストアからデータにアクセスして、ワークロードにおけるデータ移動をサポートするために必要なネットワークリソースの総量を最小化します。
  • ストレージの消費を最小化するには、ビジネス価値のあるデータまたはコンプライアンス要件を満たすために必要なデータのみをバックアップします。バックアップポリシーを精査し、リカバリーシナリオでは価値のないエフェメラルストレージを除外します。

ハードウェアパターン

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

AWS では、ワークロードに合わせて最適なものを選択できる最新のプロセッサー、ストレージ、ネットワーク、オペレーティングシステムが揃っています。また、デプロイしたリソースのスケーリングおよびモニタリングを自動化するツールも選択できます。

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

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

次のプラクティスを検討してください。

  • クラウドの能力を使用して、ワークロードの実装を頻繁に変更できます。ニーズの変化に応じて、デプロイされたコンポーネントを更新します。
  • 新しいインスタンスタイプのリリースを継続的にモニターし、エネルギー効率の改善を活用します。例えば、機械学習のトレーニングや推論、ビデオのトランスコーディングなど、特定のワークロードをサポートするように設計されたインスタンスタイプなどです。
  • マネージドサービスは、平均使用率を高く保つ責任と、デプロイされたハードウェアの持続可能性に対する最適化を、AWS に移します。マネージドサービスを使用して、サービスの持続可能性に対する影響を、そのサービスのすべてのテナント間に分散し、お客様単体の関与を軽減します。
  • グラフィック処理ユニット (GPU) は高電力消費のソースになることがあります。GPU ワークロードの種類は多く、レンダリング、トランスコーディング、機械学習トレーニング、モデリングなどさまざまです。GPU インスタンスは必要な時間だけ実行し、必要がないときはオートメーションで廃棄して、消費されるリソースを最小化します。

開発とデプロイのプロセス

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

AWS では、オートメーションと AWS デベロッパーツールを使用して、持続可能性のイノベーションを促進し、デプロイされたリソースの影響を最小化できます。

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

SUS 6: 開発およびデプロイのプロセスは、持続可能性目標を目指すうえでどのように役立ちますか?

次のプラクティスを検討してください。

  • 本稼働環境にデプロイする前に、潜在的な改善をテストして検証します。改善に際して将来的に起こりうる利点を計算する際のテストにかかるコストを考慮します。低コストのテスト方法を開発し、小規模な改善を実施します。
  • 最新のオペレーティングシステム、ライブラリ、およびアプリケーションを使用すると、ワークロードの効率が上がり、さらに効率的なテクノロジーを簡単に導入できます。最新のソフトウェアにはまた、ワークロードの持続可能性に対する影響をより正確に測定する機能が含まれている場合があります。これは、ベンダーが独自の持続可能性の目標を満たすための機能でもあります。
  • オートメーションと、Infrastructure as Code を使用して、必要に応じて本番稼働前の環境を起動し、使用しないときは停止します。一般的なパターンとしては、開発チームのメンバーの勤務時間と重なるように可用性期間のスケジュールを設定することがあります。休止は、状態を維持し、必要なときにのみインスタンスを迅速にオンラインにする便利な手段です。バーストキャパシティ、スポットインスタンス、伸縮自在なデータベースサービス、コンテナ、その他のテクノロジーを備えたインスタンスタイプ使用して、開発およびテストのキャパシティを使用に合わせて調整します。
  • マネージド型の Device Farm は、ハードウェアの製造やリソースの使用の持続可能性に対する影響を複数のテナントに分散させます。マネージド型 Device Farm は、さまざまなデバイスタイプを提供するため、あまり使われない古いハードウェアをサポートすることで、不要なデバイスのアップグレードによるお客様の持続可能性に対する影響を回避できます。

リソース

持続可能性に関する AWS のベストプラクティスの詳細については、以下のリソースを参照してください。

AWS Well-Architected
AWS Architecture Center
Sustainability in the Cloud
AWS enables sustainability solutions
The Climate Pledge
United Nations Sustainable Development Goals
Greenhouse Gas Protocol