Azureでの持続可能なワークロード

クラウド内のワークロードの持続可能性は、クラウド プロバイダーと組織の間で共有される責任です。 Azureワークロードはカーボン ニュートラルであり、100% 再生可能エネルギーを使用します。 Microsoftは、より多くの土地を保護します。 Azureでワークロードを実行することで、オンプレミスでの実行と比較して、持続可能性への道が既に進んでいます。これは、50 から 98% 低炭素効率の間である可能性があります。

クラウド ソリューション アーキテクトとして、設計上の決定は、ワークロードがクラウド リソースを使用する効率を直接形成します。 意図的な設計の選択がなければ、ワークロードは時間の経過と同時に回避可能なエネルギーを消費し、スケーリングに伴って環境負荷になる可能性があります。

このガイダンスは、最初からアーキテクチャに持続可能性を設計するのに役立ちます。 ここでは、実際のシステムで行う主要な設計と運用上の選択と、信頼性、セキュリティ、パフォーマンスを維持しながらそれらをナビゲートする方法に焦点を当てています。 アーキテクチャに関する一般的な決定がリソースの消費に与える影響、非効率性が通常出現する方法、およびシステム品質を損なうことなく無駄を減らす方法について説明します。

持続可能なワークロードとは

ハイパースケール データセンターの拡大が続き、AI ワークロードがかつてないエネルギー需要を推進し、組織は容量をはるかに下回る運用を行う常時稼働インフラストラクチャを蓄積するため、持続可能性はクラウド アーキテクチャの重要な懸念事項となっています。 最新のクラウド環境では、アイドル状態の仮想マシン、特大の Kubernetes クラスター、過剰なテレメトリ、不要なデータ レプリケーションのすべてが、意味のあるビジネス価値を提供することなくエネルギーを消費します。

持続可能なワークロードは、ビジネス、信頼性、セキュリティ、パフォーマンスの要件を満たしながら、不要なリソース消費を最小限に抑えるように設計されています。 持続可能性は、独立したアーキテクチャの規範ではありません。これは、回復力があり、安全で効率的なシステムを形成するのと同じエンジニアリング上の決定に密接に結び付けられています。 使用率、スケーラビリティ、運用効率に最適化されたワークロードは、通常、無駄なコンピューティング、ストレージ、およびネットワーク リソースを削減するため、より持続可能です。

持続可能性は、Azure Well-Architectedフレームワークのコスト最適化の柱と強く重なります。 自動スケーリングを効果的に使用してインフラストラクチャを適切にサイズ設定し、アイドル状態または冗長なリソースを排除することで、クラウドの効率を向上させ、不要なエネルギー消費と炭素排出量を削減します。 多くの場合、持続可能性への最初のステップは、単にシステムから無駄を取り除くことです。

クラウド効率を実現する方法を示す図。

Important

持続可能性は、コスト効率を超えて拡張されます。 機能的か非機能的かに関係なく、すべての設計上の決定は、炭素排出に影響を与える可能性があります。

ワークロードは低コストで運用できますが、環境的には非効率的です。 過剰なテレメトリ収集、最適化が不十分なアプリケーション フロー、不要なデータ移動、非効率的な API、または過剰に設計された回復性パターンはすべて、インフラストラクチャ コストが許容可能と思われる場合でも、ワークロードの環境フットプリントに寄与する可能性があります。

一般的な課題は何ですか?

持続可能なワークロードの設計は、多くの場合、持続可能性によって、コスト、信頼性、パフォーマンスなどの従来の懸念を超える新しいアーキテクチャのトレードオフが導入されるため、困難です。 多くの持続可能性の向上はクラウドの効率に合わせて行われますが、組織はアプリケーションの設計、運用、測定方法を再考する必要もあります。

チャレンジと説明 持続可能性への影響
持続可能性と信頼性のバランスを取る。 回復性の高いシステムでは、多くの場合、マルチリージョン デプロイまたはアクティブ/アクティブ アーキテクチャを使用して、冗長性、レプリケーション、および余分な容量が必要になります。 過剰にプロビジョニングされたリソースまたは常時オンのリソースからインフラストラクチャの使用量とエネルギー消費量を増やしました。
排出量に対する可視性が制限されています。 多くの組織には、ワークロードの排出量を測定したり、アーキテクチャの決定を環境への影響に関連付けたりするためのツールとテレメトリがありません。 改善を追跡したり、最適化作業によって排出量が削減されているかどうかを検証したりするのは困難です。
オーバープロビジョニングと遊休インフラ。 ワークロードは、多くの場合、実際の使用率ではなくピーク需要用に設計されているため、アイドル状態の VM、特大の AKS クラスター、未使用のリソースが発生します。 不要なコンピューティング、ストレージ、ネットワークの消費量により、コストと炭素排出量の両方が増加します。
パフォーマンスの最適化における持続可能性のトレードオフ。 待機時間とスループットを向上させるには、追加のキャッシュ、レプリケーション、メモリ、またはコンピューティング リソースが必要な場合があります。 パフォーマンスの向上は、運用エネルギー消費量の増加を犠牲にして生じる可能性があります。
過度の可観測性とテレメトリ。 大量のログ、トレース、メトリック、および長いリテンション期間により、ストレージと処理のオーバーヘッドが大幅に増加します。 運用テレメトリからのストレージ、ネットワーク、コンピューティング使用量の増加。
AI とデータの増加。 AI ワークロード、ベクター データベース、急速に増加するデータセットでは、大量の GPU、ストレージ、ネットワーク リソースが消費されます。 高いコンピューティング強度と制御されていないデータの増加により、ワークロードの排出量が大幅に増加する可能性があります。
組織と文化の課題。 持続可能性は、多くの場合、エンジニアリングとプラットフォームの運用とは別に扱われます。 所有権とガバナンスが不足すると、持続可能性の導入が遅くなる可能性があります。 継続的な持続可能性の進化に取り組まなければ、クラウドのスプロールと非効率性は、時間の経過とともに自然に蓄積されます。

適切に設計された結果としての持続可能性

持続可能性は、Azure Well-Architectedフレームワークとは別のものではありません。 多くの場合、持続可能なワークロードは、ワークロードライフサイクル全体にわたって一貫して Well-Architected 原則を適用した直接的な結果です。 効率的なシステムでは、消費するリソースが少なくなり、運用上の無駄が少なくなり、通常は財務と運用の両方でパフォーマンスが向上します。

このガイダンスの使用方法:

✔ 最初に、技術的および運用領域全体の論理的根拠と定期的なテーマの概要を示す 設計手法から始めます。 効率性や持続可能性の目標など、ワークロードの全体的な目標に沿った不確実な選択に直面した場合は、この手法を見直します。

✔ Well-Architected Framework の柱の推奨事項に進み、効率、最適化、および規範的な運用を通じてアーキテクチャの決定が行われます。 持続可能性は当然、次のとおりです。

Well-Architected の柱 持続可能性との関係
信頼性 信頼性の高いシステムでは、回復性と効率のバランスを取る必要があります。 高度に冗長なアーキテクチャ、アクティブ/アクティブなデプロイ、および過剰なフェールオーバー容量は、慎重に設計されていない場合、環境への影響を増大させる可能性があります。 持続可能な信頼性は、不要なオーバープロビジョニングなしで回復性の目標を達成することに重点を置いています。
Security セキュリティは持続可能性にも影響します。 ID 優先アーキテクチャ、マネージド セキュリティ サービス、効率的なガバナンス制御により、インフラストラクチャの複雑さと運用上のオーバーヘッドを軽減できます。 逆に、断片化されたツール、重複するセキュリティ プラットフォーム、および過剰なデータ保持によって、リソースの消費量が大幅に増加する可能性があります。
コストの最適化 最も強い重複は、持続可能性とコストの最適化の間に存在します。 インフラストラクチャの適切なサイズ設定、ワークロードの自動スケール、アイドル状態のリソースの排除、不要なストレージまたはネットワークの使用の削減によって、クラウドの効率が向上し、環境への影響も軽減されます。 ワークロードから無駄を取り除くことは、多くの場合、最初かつ最も効果的な持続可能性の向上です。
オペレーショナル エクセレンス 運用は持続可能性に大きな影響を与えます。 過剰なテレメトリ収集、過度に詳細なログ記録、非効率的なデプロイ パイプライン、アンマネージド運用のスプロールにより、ストレージ、ネットワーク、コンピューティングの使用量が時間の経過と同時に増加する可能性があります。 持続可能な運用には、規範的な可観測性戦略、自動化、ガバナンス、継続的な最適化プロセスが必要です。
パフォーマンス効率 効率的なアプリケーションでは、通常、同じ作業を実行するために消費するコンピューティング リソースが少なくなります。 最適化された API、キャッシュ戦略、非同期処理、効率的なデータベース アクセス パターン、およびイベント ドリブン アーキテクチャによって、不要な処理オーバーヘッドが削減されます。 パフォーマンスの最適化は、多くの場合、持続可能性の最適化です。

Microsoftは、Azure炭素排出量の最適化に取り組んでいます。 その他の材料については、Azureの炭素最適化に関するページを参照してください。

次のステップ

持続可能性の設計手法を確認します。

設計手法

Microsoftでは、温室効果ガス(GHG)排出量に関する業界標準と温室効果ガスプロトコルに準拠しています。 次のその他のリソースを確認します。

  • Microsoft Cloud for Sustainabilityを調べて、ソリューションの機能を拡張します。 この記事シリーズは、Azureで構築または操作するすべてのソリューションに適用されます。

  • クラウド コンピューティングの炭素の利点: Azureがオンプレミスソリューションよりもエネルギー効率と炭素効率が高い可能性があることを示すMicrosoft Cloudの研究を参照してください。

  • Azure内Azureカーボン最適化サービスを使用します。このサービスでは、すべてのサブスクリプションとリソースに対して事前計算された同等の炭素排出量と、排出量を削減する方法に関するワークロード固有の提案が示されます。

  • Azureの排出影響ダッシュボード: Azureのお客様がクラウド関連の炭素排出量を計算して追跡するのに役立つPower BI ソリューションのMicrosoft AppSource一覧です。

  • Microsoftデータセンターが設計によってどのように持続可能であるかを十分に理解するには、「Microsoft データセンターについて」を参照してください。

  • 気候コミットメント、報告された進捗状況、投資、より広範な持続可能性プログラムをカバーする、Microsoftの企業責任の持続可能性ハブを理解することで、持続可能性の向上について説明します。

  • 持続可能性Microsoft Learn Collection で、Microsoftからデジタル持続可能性に関する自習学習コンテンツを見つけられます。

コミュニティ リソース

  • 最終更新: