このワークロードの例は、使用可能なプロキシに基づいて持続可能性モデルを作成するのに役立ちます。 このモデルを使用すると、アプリケーションの炭素効率をスコアリングできます。 このソフトウェア炭素強度 (SCI) スコアは、アプリケーションの炭素排出量の変化を測定するためのベースラインを提供します。
注意
二酸化炭素以外の温室効果ガスは、異なる影響を環境に及ぼします。 例えば、1 トンのメタンには 80 トンの二酸化炭素と同じ温熱効果があります。 慣例により、この記事ではすべてを "CO2 換算" の基準に正規化します。 "炭素" と言った場合は常に CO2 換算を意味します。
アーキテクチャ
このアーキテクチャの Visio ファイルをダウンロードします。
データフロー
- SCI スコアの計算に使用するアプリケーション データ ソースを構成します。
- Azure Storage アカウントの Azure Table Storage にデータを保存します。
- イベント ハンドラーを使用して SCI スコアを計算します。 イベント ハンドラーには、Azure Functions、Azure Logic Apps、Azure Blob Storage が含まれる場合があります。 スコアは、単位あたりのグラム数で表す炭素排出量です。単位は、アプリケーションのスケール ファクター、またはプロキシを使用したその近似値を指します。
- Azure Functions、Logic Apps、Automation Runbook を使用して、アプリケーションで需要形成をトリガーするか、アプリケーションの定義済みエコモードを開始します。
- Power BI を使用して、時間の経過に伴うスコアのレポートと視覚化を行います。
コンポーネント
- Azure の排出量影響ダッシュボード は、クラウドベースの排出量と二酸化炭素削減可能量を測定するのに役立ちます。 これは、クラウドの使用に関連する直接的および間接的な温室効果ガスの排出量を追跡します。
- Application Insights は、アプリケーション パフォーマンス管理 (APM) を行う Azure Monitor の拡張機能です。 Application Insights は、ユーザーのアプリケーションがどのように使用されているかを把握するのに役立ちます。 この知識を使用して、アプリケーションの効率を向上させます。
- Azure Table Storage は、非リレーショナル構造化データ ("構造化 NoSQL データ" とも呼ばれます) を格納するサービスです。 これにより、スキーマレスな設定でキー/属性ストアが提供されます。 多くの種類のアプリケーションにとって、Table Storage データへのアクセスは、高速でコスト効率が高くなります。 Table Storage では通常、同様のデータ量で従来の SQL よりもコストが低くなります。
- Azure Logic Apps は、コードをほとんど、またはまったく使用せずに、自動化されたワークフローを作成して実行できるプラットフォームです。 ビジュアル デザイナーを使用し、事前構築済みの操作から選択することで、プロキシ ソース、データ ストレージ、効率計算システムを統合および管理するワークフローを構築します。
- Azure Functions は、記述するコードと管理するインフラストラクチャを減らし、コストを節約できるサーバーレス ソリューションです。 クラウド インフラストラクチャによって、アプリケーションの実行を維持するために必要な最新のリソースがすべて提供されます。
- Power BI によって、リアルタイムな分析情報を提供する分析とレポートにデータを変えることができます。 データがクラウドベースかオンプレミスかに関係なく、Azure と Power BI には視覚化と分析を実現するための統合と接続性が備わっています。
代替
このドキュメントで使用されている Azure サービスは、同様のサービスに置き換えることができます。 インフラストラクチャに及ぼす影響を最小限にして計算を行い、既存のリソースの密度と使用を増やすには、環境に既にデプロイされている Azure サービスまたはツールを使用します。
- Power BI ダッシュボードの代わりに、 Azure Monitor ブック または Azure Managed Grafana サービスを使用します。
- Application Insights の場合は、 Elasticsearch や Open APM などの別の APM ツールを代わりに使用します。
- データ テーブルは、 MySQL や MariaDB などの別のレコード システムを使用して保存できます。
- Azure Functions または Logic Apps アプリケーションを実行している場合は、既存のデプロイから定期的に計算を開始することを検討してください。
- アプリケーション リソースが複数のリソース グループに分散されている場合は、タグを使用してコスト データを関連付け、アプリケーションから排出される二酸化炭素の量を計算します。
シナリオの詳細
これらのセクションでは、炭素排出量の変化を測定するためのベースラインを計算する上で必要な詳細事項について説明します。
データ ソース
変数が少ないプロキシ式を作成してみてください。 アプリケーションの動作とパフォーマンスを表すプロキシ メトリックを選択します。 この例では、次のメトリックを使用します。
- Azure の排出量影響ダッシュボードからのインフラストラクチャの炭素排出量
- リソース グループによる毎日または毎月の支出で測定されたインフラストラクチャのコスト (Microsoft Cost Management から)
- Application Insights からのアプリケーションのパフォーマンスとスケールのメトリック:
- アプリケーションに接続されているユーザー、API 呼び出し、またはサーバー要求の数
- CPU 使用率
- メモリ使用量
- 送受信の応答時間
メトリックの Application Insights を設定する方法のチュートリアルについては、「ASP.NET Core アプリケーション用の Application Insights SDK」を参照してください。
次のような変数を数式に追加できます。
- インフラストラクチャとエッジサービスの炭素排出量
- ユーザーの接続時刻 (電力の生産と需要は時間とともに変化するため)
- 時間の経過に伴うパフォーマンスの変化を説明できる、アプリケーションのその他の独特なメトリック
ユーザー数も反映できるスコアにこの式を組み込むことで、カーボン スコアに最も近い近似値を表します。 この値は、アプリケーションの持続可能性の変化と改善のためのベンチマークです。
アプリケーションのパフォーマンスに関するもう 1 つの考慮事項はコストです。 ほとんどの場合、コストに対するパフォーマンス効率と二酸化炭素の節減には直接的な相関関係があります。
| 説明 | まとめ |
|---|---|
| パフォーマンスが高くなるが、コストは同じ | アプリケーションが最適化されており、炭素排出量が低下している |
| コストが低くなるが、パフォーマンスは同じ | アプリケーションが最適化されており、炭素排出量が低下している |
| パフォーマンスとコストが高くなる | アプリケーションが最適化されておらず、炭素排出量が増加している |
| コストが高くなるが、パフォーマンスは低いか等しい | アプリケーションが最適化されておらず、炭素排出量が増加しているか、エネルギーコストが高くなり、これによって炭素排出量も増加する |
アプリケーション SCI スコア、コスト、パフォーマンスの間のこの相関関係は、すべてのアプリケーションに固有です。 これは多くの要因に依存します。 これら 3 つの変数のデータを収集すると、バリエーションを予測するアルゴリズムを作成できます。 SCI は、アプリケーションのアーキテクチャとパターンに関する情報に基づいた意思決定を行うのに役立ちます。
計算
このシナリオでは、排出量影響ダッシュボードから収集されたデータを開始点として処理します。 SCI ベースラインの計算は次のとおりです。
SCI = C * R
コンポーネントは次のとおりです。
SCI. ソフトウェア炭素強度の結果。C. アプリケーションの炭素排出量。この値は、アプリケーションが Azure にデプロイされる方法によって異なります。 たとえば、すべてのアプリケーション リソースが 1 つのリソース グループ内にある場合、このリソース グループの炭素排出量は
C変数になります。注意
このシナリオでは、アーキテクチャとエッジまたはユーザーの動作に依存するアプリケーションの他の排出元は考慮されません。 これらの考慮事項は、カーボン プロキシを使用する次の手順で扱います。
R. アプリケーションのスケール ファクター。この値には、考慮された時間枠での平均同時ユーザー数、API 要求または Web 要求の数を指定できます。 スケール ファクターを使用すると、デプロイ フットプリントだけでなく、アプリケーションの使用の全体的な影響がスコアで考慮できます。
時間枠は、この計算のもう 1 つの重要な側面です。 エネルギー グリッドに、再生可能エネルギー源や代替エネルギー源がある場合もあれば、ない場合もあるため、炭素排出量はエネルギー消費デバイスやシステムによって異なります。 たとえば、太陽光発電は変化します。 できるだけ正確にするには、可能な限り短い時間枠 (たとえば、日単位または時間単位の計算) から始めます。
排出量影響ダッシュボードでは、サブスクリプション内のサービスに基づいて月単位の炭素情報が提供されます。 1 つのリソース グループに対してこの数値を取得するには、次の式を使用します。
Carbon (res-group) = (Carbon(subscription) * Cost(res-group)) / Cost(subscription)
次のセクションで説明するように、リソース グループの月次炭素情報と残りのデータを格納します。
データ ストレージ
前のセクションで収集したカーボンおよびカーボン プロキシ情報を格納します。 情報をダッシュボードまたはレポートにエクスポートして、カーボン スコアを時系列で視覚化し、情報に基づいた選択を行うことができます。 持続可能性の理由と、Well Architected Framework のベスト プラクティスに合わせて、 Azure Table Storageなどの実用最小限のレコード システムを使用します。
収集されたデータを記述するテーブルでは、次の例のようなデータが使用されます。
レポートからのデータ:
- Date
- リソース グループ名
- ダッシュボード C からの炭素排出量
- コスト
APM からのデータ:
- CPU
- メモリ
- 応答時間の比率 (送受信) スケール ファクター R
計算: SCI
詳細については、次を参照してください。
データの相関関係
アプリケーションの炭素、パフォーマンス、コストに関するデータを使用すると、アプリケーションに固有の相関アルゴリズムを構築できます。 この情報は、コスト、パフォーマンス、炭素の最適化を計画する際のガイダンスとなります。
注意
Azure の予約やコスト削減プランなど、割引するコストを含む数式によって、相関アルゴリズムに不一致が生じます。
アルゴリズムの選択の詳細については、「Azure Machine Learning のアルゴリズムの選択方法」を参照してください。
データの表示
データと計算はいくつかの方法で表示できます (たとえば、カスタマイズした Azure Monitor ブックや単純な Power BI ダッシュボードなどがあります)。 詳細については、「Application Insights を使ってカスタム主要業績評価指標 (KPI) ダッシュボードを作成する」および「レポートから Power BI ダッシュボードを作成する」を参照してください。
SCI スコア アクション トリガー
プロキシを使用してアプリケーションの炭素効果をスコア付けしたら、次の手順では、カーボン スコアで好ましくない条件がトリガーされるアクションを定義します。 これらの条件の例を次に示します。
- エネルギーの生産と需要が高く、エネルギーの生産コストが高い
- 自然災害や地政学的紛争のため、電気を利用できない
- リソースの過剰消費またはサプライ チェーンの問題により、エッジ インフラストラクチャが使用できない
アプリケーションに影響を与える可能性のある障害ポイントを特定したら、アプリケーションの "カーボン スパイクに対する回復性" を高めるために実行するアクションを決定します。
アプリケーションの "エコモード" バージョンを構築することを検討してください。 エコモード バージョンは、完全なアプリケーションの、シンプルで小さく、安価で環境に優しいバージョンです。 炭素排出量の急増がある場合、アプリケーションはこれらの最小限の機能に戻ります。
エンドユーザーにエコモードバージョンを選択するよう促すことを検討してください。 炭素排出量の削減と引き換えに、無駄のないインターフェイス、少ないグラフィックス、限定された機能に同意することをユーザーが宣言するための "グリーン ボタン" を提供します。 ユーザーを巻き込むことで、技術的な変化と共に文化的な変化を促進する機会を提供します。
- この選択の効果を指定します。"グリーン バージョンを使用することで、炭素 の量を <X> だけ減らす" または "炭素スコアを <Y >にする" ことができます。
- ユーザーの行動について学習し、選択内容を反映するようにエコモード バージョンを変更します。 たとえば、アプリケーション機能の 10% しか使用していないユーザーは、グリーン バージョンの理想的なユーザーになる可能性があります。
- 理想的には、時間が経つにつれてフルバージョンの排出は最適化され、バージョンは最終的に収束します。
考慮事項
以降の考慮事項には、ワークロードの品質向上に使用できる一連の基本原則である Azure "Well-Architected Framework" の要素が組み込まれています。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。
セキュリティ
セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティの重要な要素の概要」を参照してください。
さらにセキュリティを強化するには、 Azure Virtual Network サービス エンドポイントを使用して、仮想ネットワークに対してのみ Azure サービス リソースをセキュリティで保護することができます。 この方法では、これらのリソースに対するパブリック インターネット アクセスが閉じられ、自分の仮想ネットワークからのトラフィックのみが許可されます。
このアプローチでは、Azure 内に仮想ネットワークを作成し、Azure サービス用のプライベート サービス エンドポイントを作成します。 これらのサービスは、その仮想ネットワークからのトラフィックに制限されるようになります。 オンプレミス ネットワークからゲートウェイ経由でサービスにアクセスすることもできます。
注意
オンプレミスから Azure Storage にデータを移動するには、オンプレミス コンピューターからのパブリック IP アドレスを許可するか、 Azure ExpressRouteを使用する必要があります。 詳細については、「仮想ネットワークに専用の Azure サービスをデプロイする」を参照してください。
セキュリティで保護されたソリューションの設計に関する一般的なガイダンスについては、「Azure のセキュリティのドキュメント」を参照してください。
コスト最適化
コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳しくは、 コスト最適化の柱の概要に関する記事をご覧ください。
Emissions Impact Dashboard と Microsoft Cost Management レポートは無料です。 この例は、コストと炭素排出量を節減するために意図的に最小限となっています。 このアーキテクチャは、いくつかの代替の Azure サービスを使用してデプロイできます。
ご使用のアプリケーションのデプロイに既に存在する同等のサービスを使用してください。 次のリソースには、コンポーネントの価格情報が提供されています。
- App Insights の価格
- Azure Table Storage の価格
- Azure Logic Apps の価格
- Azure Functions の価格
- Azure Automation の価格
- Power BI の料金
パフォーマンス効率
パフォーマンス効率とは、ユーザーによって行われた要求に合わせて効率的な方法でワークロードをスケーリングできることです。 詳細については、「パフォーマンス効率の柱の概要」を参照してください。
このアーキテクチャの主な目的は、コストと炭素自体への影響を最小限に抑えつつ、アプリケーションの持続可能性スコアを提供することです。 ほとんどのコンポーネントは、使用量とトラフィックに基づいて個別にスケーリングできる、サービスとしてのプラットフォーム (PaaS) とサーバーレス Azure サービスです。
この例のダッシュボードとストレージ インターフェイスは、高い使用率やコンサルテーションには適していません。 このソリューションを多くのユーザーに提供する予定の場合は、次の代替手段を検討してください。
- 抽出されたデータを変換し、別のレコード システムに格納することによって分離する
- Azure Table Storage を、 Azure Cosmos DBなどのよりスケーラブルなデータ構造の代替手段に切り替える
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパルの作成者:
- Paola Annis | プリンシパル SVC エンジニアリング マネージャー
- Jennifer Wagman | サービス エンジニア
その他の共同作成者:
- Chad Kittel | プリンシパル SDE
パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。
次のステップ
この作業は グリーン ソフトウェア財団の原則と方法論に沿っています。
より環境に優しいアプリケーションを構築するための次の手順は、カーボン対応の SDK をアプリケーションに埋め込むことです。 特定の炭素条件を満たしたら、トリガーをリアルタイムで自動化できます。 詳細については、「グリーン ソフトウェア財団のカーボン対応 SDK」を参照してください。
Well Architected Framework の持続可能性クラウド ワークロード ガイダンスについては、 持続可能性ワークロードのドキュメントを参照してください。
持続可能性の詳細については、次の記事を参照してください。