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

  • [アーティクル]

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

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

1 - ビジネス要件の設計

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

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

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

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

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

設計領域:

3— 排出量を理解する

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

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

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

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

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

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

炭素影響の測定と追跡

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

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

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

この場合、

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

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

GitHub の完全な SCI 仕様をお読みください。

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

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

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

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

Microsoft Sustainability Manager を活用する

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

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

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

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

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

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

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

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

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

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

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

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

排出量を削減する方法

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

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

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

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

共同責任

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

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

例を見てみましょう。

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

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

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

次のステップ

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

設計原則