次の方法で共有

Azure での持続可能なワークロードの設計手法

  • [アーティクル]

任意のクラウド プラットフォームで持続可能なアプリケーションを構築するには、技術的な専門知識と、一般的な持続可能性ガイドラインと特定のクラウド プラットフォームに関する理解が必要です。

この設計手法は、より炭素効率の高いソリューションの製造、炭素への影響の測定、そして最終的には不要なエネルギー使用量と排出量の削減に関する理解を確立することを目的としています。

1 - ビジネス要件の設計

企業はグローバルに異なる要件を持っています。 この設計手法によって提供されるレビューの考慮事項と設計に関する推奨事項によって、さまざまなシナリオや組織に対して異なる設計上の決定とトレードオフが生じすることを期待します。

ビジネス要件と優先順位を確立し、それらの要件に合わせて設計手法を確認します。

2 — 設計原則を使用して設計領域を評価する

持続可能性のワークロードについては、持続可能性 設計の 原則と以下の設計領域を参照してください。

各設計領域内で行われた決定は、他の設計領域に反映されます。 各設計領域の考慮事項と推奨事項を確認して、結果と影響、および既知のトレードオフを理解します。

設計領域:

3 - 排出量を把握する

排出量を削減するには、持続可能性の取り組みを測定する方法を理解する必要があります。

排出量の範囲について簡単に説明します

Microsoft では、温室効果ガス (GHG) の排出量を、温室効果ガス プロトコルと一致する 3 つのカテゴリに分割しています。

  • スコープ 1 の排出量: アクティビティによって作成される直接の排出量。
  • スコープ 2 の排出量: 使用する電気または熱の生産に起因する間接的な排出量。
  • スコープ 3 の排出量: あなたが従事している他のすべての活動からの間接的な排出量。 企業の場合、これらのスコープ 3 の排出量は広範囲に及ぶ可能性があります。 サプライ チェーン全体、建物内の材料、従業員の出張、製品のライフサイクル (製品使用時に顧客が消費する電力を含む) を考慮する必要があります。 ある会社のスコープ 3 の排出量は、多くの場合、スコープ 1 と 2 の排出量を組み合わせたよりもはるかに大きくなります。

お客様は、スコープ 3 の排出量のコンテキストとして、ネットワーク構成と配信、電力消費量、データ センター外のデバイスを使用できます。 アプリケーションが過剰な帯域幅またはパケット サイズを使用している場合、トラフィックがデータ センターからインターネット上のさまざまなホップを経由してエンド ユーザー デバイスに送信された場合に影響を受けます。 そのため、ネットワーク帯域幅の削減は、配信チェーン全体に大きな影響を与える可能性があります。 コンピューティング リソース、データ ストレージ、アプリケーション プラットフォームの決定、アプリケーション設計などにも、同じ考慮事項が適用されます。

詳細な詳細と定義については、2021 年に 発行された Azure の Scope 3 の方法論に関するホワイト ペーパーを参照してください。

炭素影響の測定と追跡

Microsoft は、ソフトウェア カーボン強度 (SCI) 仕様の作成を担当する Green Software Foundation と連携しています。

アプリケーションの炭素影響を測定するために、GSF は SCI と呼ばれるスコアリング手法を提供し、次のように計算しました。

SCI = ((E*I)+M) per R

ここで:

  • E = ソフトウェア システムによって消費されるエネルギー。 kWh で測定します。
  • I = 位置ベースの限界炭素排出量。 エネルギー1kWh当たりの炭素排出量、gCO2/kWh。
  • M = ソフトウェア システムの具体化された排出量。 ソフトウェアが実行されているハードウェアを介して出力される炭素。
  • R = 機能単位。アプリケーションのスケーリング方法です。追加ユーザーごと、API 呼び出しごと、サービスごとなど。

この知識により、環境フットプリントが大幅に変化する可能性があるため、アプリケーション インフラストラクチャとハードウェアだけでなく、ユーザー デバイスとアプリケーションのスケーラビリティも考慮することが不可欠です。

GitHub で SCI 仕様の詳細を 確認します。

Azure CO2 最適化

Azure Carbon Optimization は、クラウド ワークロードの炭素排出量を理解するのに役立つ Azure サービスです。 CO2 最適化は、Azure リソースの炭素排出量に関する分析情報を提供し、持続可能性のためにクラウド ワークロードを最適化するのに役立ちます。

過去 12 か月間のすべての Azure 製品とサービスの使用状況について、Azure Portal 内で詳細な排出量データを取得します。 リージョン、サブスクリプション、リソース グループ別にリソースの炭素排出量を表示することもできます。

排出影響ダッシュボードを使用した炭素の追跡とレポート

Microsoft では、クラウドベースの排出量と炭素削減の可能性を測定するのに役立つ、Azure と Microsoft 365 の排出影響ダッシュボードを提供しています。

このツールを使用して、二酸化炭素排出量を把握し、時間の経過に伴う排出量の測定と追跡に必要な分析情報と透明性を得ることをお勧めします。

Azure 用の 排出影響ダッシュボード Power BI アプリをダウンロードして開始します。

Microsoft Sustainability Manager を活用する

Microsoft Cloud for Sustainability を使用しているお客様は、Microsoft Sustainability Manager を活用できます。 この拡張可能なソリューションは、データ インテリジェンスを統合し、持続可能性の取り組みの任意の段階で、包括的で統合された自動化された持続可能性管理を組織に提供します。 これにより、手動プロセスが自動化され、組織は排出量をより効率的に記録、報告、削減できます。

プロキシ ソリューションを使用して排出量を測定する

ワークロードからの炭素排出量を推定する 1 つの方法は、前述のように SCI モデル に基づいてプロキシ ソリューション アーキテクチャを設計することです。

アプリケーションのプロキシの定義は、さまざまな方法で行うことができます。 たとえば、次の変数を使用します。

  • インフラストラクチャの既知の炭素排出量
  • インフラストラクチャのコスト
  • エッジ サービスとインフラストラクチャの炭素排出量
  • アプリケーションを同時に使用しているユーザーの数
  • 時間の経過に伴うパフォーマンスについて通知するアプリケーションのメトリック

上記の変数を使用して数式を設計することで、炭素スコア (近似値) を見積もることができ、持続可能なソリューションを構築しているかどうかを理解するのに役立ちます。

アプリケーションのパフォーマンスにも側面があります。 パフォーマンスをコストと炭素にリンクし、この関係が価値をもたらすと仮定できます。 この関係を使用すると、次のようにビューを簡略化できます。

アプリケーションのパフォーマンス アプリケーションのコスト 可能性の高い結果
高 Unchanged 最適化されたアプリ
高 低 最適化されたアプリ
変更なし/下 高 グリーン原則によると、エネルギーコストが高いほど炭素排出量が増加する可能性があります。 そのため、アプリで不要な炭素排出量が生成されると想定できます。
高 高 アプリが不要な炭素を生成している可能性がある

そのため、カーボン スコア ダッシュボードを構築すると、次のプロキシを使用できます。

  • コスト
  • パフォーマンス
  • インフラストラクチャの炭素排出量 (既知または利用可能な場合)
  • 時間の経過に伴う使用状況 (要求、ユーザー、API 呼び出しなど)
  • アプリケーションに関連する追加の測定

4 - 持続可能性のための共同責任モデル

排出量の削減は、クラウド プロバイダーと顧客がプラットフォーム上でアプリケーションを設計およびデプロイする間で共通の責任です。

排出量を削減する方法

二酸化炭素排出量の削減は、次の 3 つの解決策で発生する可能性があります。

  • 炭素中和;炭素排出量の補償
  • 炭素回避;最初の場所で炭素を排出していない
  • 炭素除去;大気から炭素を差し引く

グリーンソフトウェアの目標は、最初に不要な排出を避けるため、より持続可能な未来に向けて積極的に取り組んでいます。 また、 炭素除去 は大気からの排出を除去するための好ましい目標です。

Microsoft は、2030 年までにカーボンマイナスに取り組み、2050 年までに、1975 年の設立以来、会社が排出したすべての炭素を取り除くことを約束しています。

共同責任

クラウド プロバイダーとして、Microsoft はアプリケーションをホストするデータ センターを担当します。

ただし、データ センターが持続可能性のために最適化されている場合でも、Microsoft クラウドにアプリケーションをデプロイしても、アプリケーションは自動的に持続可能になりません。 最適化されていないアプリケーションの場合、必要以上に炭素を排出する可能性もあります。

例を見てみましょう。

アプリを Azure サービスにデプロイしますが、割り当てられたリソースの 10% のみを利用します。 プロビジョニングされたリソースの使用率が低くなり、最終的に不要な排出量が発生します。

リソースの適切なレベルへのスケーリング (権限付与) や、同じプロビジョニング済みリソースへのアプリのデプロイを検討した場合に役立ちます。

可能な限り最適な方法でデータ センターの容量を利用するために、アプリケーションをより効率的にすることをお勧めします。 持続可能性は、アプリケーションの設計と実装においてクラウド プロバイダーと顧客の取り組みを組み合わせる必要がある共同責任目標です。

次のステップ

持続可能性に関する設計原則を確認します。

設計原則