SCI スコアを使用して Azure アプリの持続可能性を測定する

この記事で説明するソリューションは、Azure でホストされているアプリケーションの持続可能性モデルを作成するのに役立ちます。 このモデルでは、アプリケーションのカーボン インパクトと効率を時系列でスコア付けできるプロキシを使用します。 このスコアは、Software Carbon Intensity (SCI) スコアと呼ばれます。 アプリケーションの炭素排出量の変化を測定するためのベースラインになります。

Architecture

このアーキテクチャの Visio ファイルをダウンロードします。

データフロー

1. SCI スコアの計算に使用するアプリケーション データ ソースを構成します。 データには、Azure portal の [CO2 最適化] ブレードで提供される排出量測定値、または Microsoft 以外のソースやシステムから取得するプロキシ測定値を指定できます。
2. 炭素排出量データをデータ レイクにエクスポートします。
3. SCI スコアを計算するには、Azure Functions や Azure Logic Apps などのイベント ハンドラーを使用します。 出力は、ユニットあたりのグラム数で表される炭素排出量になります。ユニットとは、アプリケーションのスケール ファクター、またはプロキシに基づくその近似値を指します。
4. Azure Functions、Logic Apps、Azure Automation Runbook のようなテクノロジを使用して、アプリケーションで需要形成をトリガーするか、アプリケーションの定義済みエコモードを開始します。
5. Power BI を使用して、スコアとその変動を経時的にレポートおよび視覚化します。

コンポーネント

• Azure portal の [CO2 最適化] ブレードには、Azure ワークロードの炭素排出量の測定値がリソースグループ レベルで表示されます。
• Cloud for Sustainability API では、CO2 最適化の基になるデータが提供されます。 それを使用すると、サブスクリプションの排出量に関する情報を取得できます。
• Application Insights は、アプリケーション パフォーマンス管理 (APM) を提供する Azure Monitor の機能です。 ユーザーがアプリをどのように使用しているかについて強力な分析情報を得るのに役立ちます。 この知識を使用すると、アプリケーションの効率の向上に関してデータドリブンの意思決定を行えます。
• Azure Blob Storage は、Azure CO2 最適化、カスタム計算、または排出量に関するその他プロキシから取得した排出量情報を格納します。
• Azure Data Lake は、大量のデータを元の形式で取り込んで格納する一元化されたリポジトリです。 その後、データを処理し、さまざまな分析ニーズの基礎として使用できます。
• Azure Logic Apps を使用すると、コードを極力使用せずに、自動化されたワークフローを作成して実行できます。 ビジュアル デザイナーを使用し、事前構築済みの操作から選択することで、プロキシ ソース、データ ストレージ、効率計算システムを統合および管理するワークフローを迅速に作成できます。
• Azure Functions を使用すると、小さなコード ユニットを実行できます。 需要に基づいてリソースが自動的にスケーリングされ、実際の実行時間の料金のみが発生します。 これを使用して持続可能性の計算を行い、Blob Storage またはデータ レイクに格納できます。
• Azure Automation では、Runbook を使用したプロセス自動化を使用できます。 Runbook を使用すると、PowerShell コードを使用して、アプリケーションの効率を上げることができる複雑なロジックを実装できます。 このサービスでは、エラーと運用コストを削減してビジネス価値を高めることもできます。
• Power BI によって、リアルタイムの分析情報を提供する分析とレポートにデータを変えることができます。

代替

この記事で説明する Azure サービスは、同様のサービスに置き換えることができます。 既存のリソースの密度と使用を増やすには、環境に既にデプロイされている Azure サービスまたはツールを使用して、インフラストラクチャへの影響を最小限に抑えつつ計算を実行します。

• Power BI ダッシュボードは、Azure Monitor ブックまたは Azure Managed Grafana サービスに置き換えることができます。
• Application Insights は、Elasticsearch アプリケーション パフォーマンス管理 (APM) や OpenAPM などの他のアプリケーション パフォーマンス管理 (APM) ツールに置き換えることができます。
• テーブルまたは非構造化データの形式のデータは、MySQL、MariaDB、Azure Cosmos DB、MongoDB など、任意のレコード システムで保持できます。
• 実行中の Azure Functions または Logic Apps スペースがある場合は、既存のデプロイから定期的に計算を実行できます。
• アプリケーション リソースが複数のリソース グループに分散されている場合は、タグを使用してコスト データを関連付け、アプリケーションから排出される二酸化炭素の量を計算できます。

シナリオの詳細

このアーキテクチャは、Azure やその他のソースから CO2 最適化データを収集して、アプリケーションの環境への影響を包括的に把握できるよう設計されています。 データは、Azure の CO2 最適化から収集されます。 Azure 以外の環境の場合、プロキシを使用して関連するカーボン メトリックを取得します。 データが統合されると、SCI 計算が実行され、全体的な二酸化炭素排出量が評価されます。 その後、結果は Azure Storage アカウントまたはデータ レイクに格納され、長期的なリテンション期間が確保されます。これにより、BI 分析と履歴レポートが可能になります。 このアプローチにより、多様なインフラストラクチャ全体のカーボン インパクトを一元的に追跡でき、戦略的な持続可能性の取り組みを支援できます。

炭素排出量情報は Azure portal の [CO2 最適化] ブレードから部分的に収集され、可能な場合はプロキシ経由で部分的に計算されます。

次の 2 つの主な理由から、Azure の CO2 最適化データを収集するために別々のアーキテクチャを使用する必要があります。

• Azure CO2 最適化データは、過去 12 か月 (ローリング ウィンドウ内) のもののみ格納および表示されます。 二酸化炭素排出量の長期的な追跡が必要な場合は、専用システムで詳細な履歴情報を保持します。
• アプリケーションは複数のインフラストラクチャにまたがる可能性があり、Azure は 1 つのコンポーネントにすぎません。 個別のアーキテクチャを使用すると、すべての環境にわたるカーボン インパクトを一元的に監視して全体を把握し、より包括的な持続可能性の分析情報を確保できます。

データ ソース

一般に、いくつかの変数を持つプロキシ式を作成する必要があります。 選択するプロキシ メトリックは、アプリケーションの動作とパフォーマンスを表す必要があります。

この例では、次のメトリックを使用します。

• 炭素排出量 API から取得されるインフラストラクチャの炭素排出量。 この API は、Azure portal の排出影響ダッシュボードと [CO2 最適化] ブレードの両方のソースになります。 データはリソース グループ レベルで使用できるため、アプリケーションの排出量をより簡単に追跡できます。
• Application Insights から収集した、アプリケーションのパフォーマンスとスケールのメトリック:
  • アプリケーションのスケーリング係数 (API 呼び出し、サーバー要求、またはその他のメトリック)
  • CPU 使用率
  • メモリ使用量
  • 応答時間 (送受信)

Application Insights を設定して必要なメトリックを取得する方法のチュートリアルについては、「ASP.NET Core アプリケーション用の Application Insights」を参照してください。

次のようなその他の変数を数式に追加できます。

• Edge サービスとインフラストラクチャの炭素排出量。
• ユーザーの接続時刻 (電力の生産と需要は時間とともに変化するため)。
• 時間の経過に伴うパフォーマンスの変化がわかる、アプリのその他のメトリック。

ユーザー数も反映できるスコアにこの式を組み込むと、カーボン スコアに最も近い近似値を作成できます。 このスコアは、アプリの持続可能性に向けたさらなる変更と改善のベンチマークです。

コストは、アプリケーションのパフォーマンスに関連するもう 1 つの考慮事項です。 ほとんどの場合、パフォーマンス効率とコストおよび炭素削減量との間に直接的な相関関係が成り立ちます。 この相関関係から、次の仮説が導かれます。

• パフォーマンスが向上しているのにコストが同じである場合は、アプリが最適化され、炭素排出量が削減された。
• コストが減っているのにパフォーマンスが同じである場合は、アプリが最適化され、炭素排出量が削減された。
• パフォーマンスとコストの両方が増加している場合は、アプリは最適化されず、炭素排出量が増加した。
• コストは増加しているがパフォーマンスが低下したか同じ場合は、アプリは最適化されず、炭素排出量が増加した (またはエネルギー コストが高くなった。これは、炭素排出量が増加する原因でもある)。

アプリケーションの SCI スコア、コスト、およびパフォーマンス間のこの相関関係は、すべてのアプリケーションに固有であり、多くの要因に依存します。 これら 3 つの変数のデータを収集することで、3 つの変数の任意のバリエーションを予測し、アプリケーションのアーキテクチャとパターンについて十分な情報に基づいた意思決定を行うことができる相関アルゴリズムを作成できます。

[新しい名前付きセット]

ここで説明するシナリオでは、使用されるプロキシの個別の計算を行うことはできません。 代わりに、排出影響ダッシュボードから収集されたデータを開始点として処理します。 SCI ベースラインの計算を次に示します。

SCI = C*R

この式では、次のようになります。

• C はアプリケーションの炭素排出量です。 この値は、アプリケーションを Azure にデプロイする方法の影響を受けます。 たとえば、すべてのアプリケーション リソースが 1 つのリソース グループ内にある場合、C は、そのリソース グループの炭素排出量になります。

  Note

  現時点では、アプリケーションの他の排出元は、アーキテクチャおよびエッジ/ユーザーの動作に依存するため無視されます。 データにプロキシを使用する場合は、次の手順でこれらのソースを検討できます。

• R はアプリケーションのスケール ファクターです。 これには、時間枠での平均同時ユーザー数、API 要求数、Web 要求数、またはその他のメトリックを指定できます。 この値は、デプロイ フットプリントだけでなく、アプリケーションの使用による全体的な影響を考慮したスコアにつながるため、重要です。

もちろん、時間枠はこの計算のもう 1 つの重要な側面です。エネルギーを消費するデバイスまたはシステムの炭素排出量は時間とともに変化します。これは、エネルギー グリッドには、再生可能エネルギー減または代替エネルギー源 (太陽光発電など) が含まれる時期もあれば、含まれない時期もあるためです。 したがって、精度を高めるためには、できるだけ短い時間枠から始めることが重要です。 たとえば、日単位または時間単位の計算から始めるとよいでしょう。

現在、炭素排出量 API は、サブスクリプション内のサービスに基づいて、リソース グループ レベルで毎月の炭素情報を提供しています。 提供された REST API を使用すると、アプリケーションのすべての持続可能性データを保持するデータ レイクに排出量データをエクスポートできます。

データ ストレージ

ダッシュボードまたはレポートに接続できるソリューションに、収集した炭素情報と炭素プロキシ情報を格納する必要があります。 そうすれば、炭素スコアを時系列で視覚化し、十分な情報に基づいて選択できます。 持続可能性を向上させ、Azure Well-Architected フレームワークのベスト プラクティスに合わせるには、実行可能な最小限のシステムを使用することをお勧めします。 (詳細については、 を参照してください。Azure での持続可能なワークロードのデータとストレージの設計に関する考慮事項 および Azure での持続可能なワークロードに対するアプリケーション プラットフォームの考慮事項)。このアーキテクチャでは、Azure Data Lake Storage が使用されます。

データの相関関係

アプリケーションの炭素、パフォーマンス、コストに関するデータの収集を開始すると、アプリケーションに固有の相関アルゴリズムを作成できる、そしてコスト、パフォーマンス、CO2 最適化を計画する際のガイダンスとなる貴重な情報が得られます。

詳細については、「Azure Machine Learning のアルゴリズムを選択する方法」を参照してください。

データの表示

カスタマイズされた Azure Monitor ダッシュボードや単純な Power BI ダッシュボードなど、さまざまな方法でデータと計算を表示できます。

SCI スコアでトリガーされること

持続可能性スコアを把握した後、どうすればスコアを改善できるのだろうと思うことがあるかもしれません。

プロキシを使用してアプリケーションのカーボン インパクトをスコア付けできるのであれば、次の手順は、スコアの好ましくない条件によってトリガーされる可能性のあるアクションの定義に焦点を当てることです。 これらの条件の例を次に示します。

• エネルギーの生産と需要は常に高いため、生産コストが高くなる。
• 電気が利用できない。 この条件は、自然災害や地政学的な紛争によって引き起こされる可能性があります。
• リソースの過剰消費またはサプライ チェーンの問題によってエッジ インフラストラクチャが突然使用できなくなる。

アプリケーションに影響を与える可能性のある障害ポイントを特定できる場合は、アプリケーションのカーボン スパイクに対する回復性を高めるために実行するアクションを決定できます。

次のうちのいずれかを実行できます。

• Well-Arcchitected フレームワークのドキュメントで説明されているように、アプリのサービスと機能の正常な低下を適用します。

• アプリケーションのエコモード バージョンを作成します。 エコ モードは、最小限の機能を提供するアプリケーションの、よりシンプルで小さく、安価で持続可能なバージョンです。 炭素排出量の急増中にこのバージョンに戻すことができます。 また、特にエコ バージョンを使用するようにエンド ユーザーをトレーニングすることもできます。 炭素排出量の削減と引き換えに、無駄のないインターフェイス、少ないグラフィックス、限定された機能をユーザーが使えるようになる "グリーン ボタン" を提供できます。

• ユーザーを巻き込むことを選択した場合は、技術的な変更と共に文化的な変化を促進する機会を作成します。-選択の影響を指定できます。"eco バージョンを使用すると、 x の量 炭素を節約できます"、または "炭素スコアを y の量" に設定できます。ユーザーの行動を理解し、その選択を反映するようにエコ バージョンを変更できます。 (おそらく、彼らは機能の10%を使用し、エコバージョンの理想的なユーザーです。- フル バージョンはエミッション用に最適化されているため、最終的には 2 つのバージョンをマージすることが理想的です。

考慮事項

以降の考慮事項には、ワークロードの品質向上に使用できる一連の基本原則である Azure "Well-Architected Framework" の要素が組み込まれています。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。

セキュリティ

セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティの重要な要素の概要」を参照してください。

セキュリティを強化するために、Azure 仮想ネットワーク サービス エンドポイントを使用して、Azure サービス リソースへのパブリック インターネット アクセスを削除し、仮想ネットワークからのトラフィックのみを許可します。

このアプローチでは、Azure 内に仮想ネットワークを作成し、Azure サービス用のプライベート サービス エンドポイントを作成します。 これらのサービスは、その仮想ネットワークからのトラフィックに制限されるようになります。 オンプレミス ネットワークからゲートウェイ経由でアクセスすることもできます。

オンプレミスから Azure Storage にデータを移動するには、オンプレミスまたは Azure ExpressRoute からパブリック IP アドレスを許可する必要があることに注意してください。 詳細については、「仮想ネットワークに専用の Azure サービスをデプロイする」を参照してください。

セキュリティで保護されたソリューションの設計に関する一般的なガイダンスについては、「Azure のセキュリティのドキュメント」を参照してください。

コストの最適化

コストの最適化とは、不要な費用を削減し、運用効率を向上させることです。 詳細については、「コスト最適化の重要な要素の概要」を参照してください。

このアーキテクチャは、いくつかの代替の Azure サービスを使用してデプロイできます。 コストと炭素排出量を削減するために、意図的に最小限に抑えられていました。

アプリケーションのデプロイでは既に用意されている同等のサービスを使用することをお勧めしますが、価格情報はアーキテクチャ コンポーネントごとに入手できます。

• 排出影響ダッシュボード、Azure CO2 最適化、および Microsoft Cost Management レポートは無料です。

• Application Insights の価格。

• Azure Table Storage の価格。

• Azure Logic Apps の価格。

• Azure Functions の価格。

• Azure Automation の価格。

パフォーマンス効率

パフォーマンス効率とは、ユーザーからの要求に合わせて効率的な方法でワークロードをスケーリングできることです。 詳細については、「パフォーマンス効率の重要な要素の概要」を参照してください。

このアーキテクチャの主な目的は、コストと炭素自体への影響を最小限に抑えるプロセスを使用して、アプリケーションの持続可能性スコアを提供することです。 ほとんどのコンポーネントは、使用量とトラフィックに基づいて個別にスケーリングできる、サービスとしてのプラットフォーム (PaaS) とサーバーレス Azure サービスです。

このシナリオでは、ダッシュボードとストレージ インターフェイスは、大量の使用やコンサルテーションを目的としたものではありません。 多数のユーザーに提供する場合は、次のいずれかのオプションを検討することをお勧めします。

• 抽出されたデータを、変換して別のシステムに格納することで分離します。
• Data Lake Storage または Azure Table Storage を、Azure Cosmos DB などのよりスケーラブルなデータ構造に置き換えます。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパルの作成者:

• Paola Annis | プリンシパル カスタマー エクスペリエンス エンジニアリング マネージャー
• Davide Bedin | シニア クラウド ソリューション アーキテクト、アプリケーション イノベーション

その他の共同作成者:

• Chad Kittel | プリンシパル ソフトウェア エンジニア

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ

この記事はグリーン ソフトウェア財団の原則と方法論に沿っています。 より環境に優しいアプリケーションを作成するための次の手順は、Carbon Aware SDK をアプリケーションに埋め込み、特定の炭素条件が満たされたときにトリガーをリアルタイムで自動化できるようにすることです。

Azure ワークロードを最適化するための推奨事項については、持続可能性クラウド ワークロード ガイダンスを参照してください。

関連リソース

• Azure でのデータ分析とレポート テクノロジの選択
• 規制対象業界のデータ分析ワークロード