使用 SCI 分數測量 Azure 應用程式永續性

本文所述的解決方案可協助您為裝載在 Azure 上的應用程式建立永續性模型。 此模型使用一段時間后，可讓您為應用程式的碳影響和效率評分的 Proxy。 分數稱為軟體碳強度 （SCI） 分數。 它提供基準來測量應用程式碳輸出中的變更。

架構

下載此架構的 Visio 檔案。

資料流程

1. 設定您將用來計算 SCI 分數的應用程式資料來源。 數據可以是 Azure 入口網站 中的 [碳優化] 刀鋒視窗提供的排放量測量，也可以是來自非Microsoft來源或系統的 Proxy 測量。
2. 將碳排放數據匯出至您的數據湖。
3. 使用 Azure Functions 或 Azure Logic Apps 之類的事件處理程式來計算 SCI 分數。 輸出是每單位以克為單位發出的碳量，其中 單位 是指應用程式縮放比例，或以 Proxy 為基礎的近似值。
4. 使用 Azure Functions、Logic Apps 或 Azure 自動化 Runbook 等技術來觸發對應用程式的需求成形，或起始應用程式預先定義的生態模式。
5. 使用 Power BI 來報告分數及其隨時間變化的可視化。

元件

• Azure 入口網站 中的 [碳優化] 刀鋒視窗會在資源群組層級提供 Azure 工作負載的碳排放量測量。
• Cloud for Sustainability API 提供碳優化的基礎數據。 您可以使用它來擷取訂用帳戶排放的相關信息。
• Application Insights 是 Azure 監視器的一項功能，可提供應用程式效能監視。 其可協助您深入了解人員如何使用您的應用程式。 您可以使用這項知識來制定數據驅動決策，以改善應用程式的效率。
• Azure Blob 儲存體 儲存來自 Azure 碳優化、自定義計算或其他排放 Proxy 的排放資訊。
• Azure Data Lake 是一個集中式存放庫，可內嵌並儲存其原始格式的大量數據。 然後，數據可以進行處理，並作為各種分析需求的基礎。
• Azure Logic Apps 可讓您建立及執行自動化工作流程，幾乎不需要任何程序代碼。 藉由使用可視化設計工具並從預先建置的作業中選取，您可以快速建立工作流程，以整合和管理 Proxy 來源、數據儲存和效率計算系統。
• Azure Functions 可讓您執行少量的程式代碼單位。 它會根據需求自動調整資源，而且您只需支付實際運行時間的費用。 您可以使用它來進行永續性計算，並將其儲存在 Blob 記憶體或數據湖中。
• Azure 自動化 透過 Runbook 提供程式自動化。 您可以使用 Runbook 來實作複雜的邏輯，方法是使用 PowerShell 程式代碼來影響您的應用程式來提高效率。 這項服務也可以藉由降低錯誤和營運成本來增加商業價值。
• Power BI 可讓您將資料轉換成提供即時深入解析的分析與報表。

替代項目

本文所述的 Azure 服務可以取代為類似的服務。 若要增加現有資源的密度和使用率，請使用已在環境中部署的 Azure 服務或工具，以對基礎結構造成最低影響來執行計算：

• 您可以將 Power BI 儀錶板取代為 Azure 監視器 活頁簿或 Azure 受控 Grafana 服務。
• 您可以將 Application Insights 取代為任何其他應用程式效能管理工具，例如 Elasticsearch APM 或 OpenAPM。
• 資料表或非結構化數據形式的數據可以保留在任何記錄系統中，例如 MySQL 或 MariaDB，或 Azure Cosmos DB 和 MongoDB。
• 如果您有執行 中的 Azure Functions 或 Logic Apps 空間，您可以從現有的部署定期執行計算。
• 如果應用程式資源分散到多個資源群組，您可以使用標籤來將成本數據相互關聯，並計算應用程式發出的碳量。

案例詳細資料

此架構的設計目的是從 Azure 和其他來源收集碳優化數據，以提供應用程式環境影響的完整檢視。 數據會從 Azure 碳優化收集。 針對非 Azure 環境，Proxy 可用來擷取相關的碳計量。 合併數據之後，會執行SCI計算來評估整體碳足跡。 然後，結果會儲存在 Azure 記憶體帳戶或 Data Lake 中以供長期保留，以啟用 BI 分析和歷程記錄報告。 這種方法可確保跨各種基礎設施集中追蹤碳影響，並支持戰略可持續性工作。

碳排放資訊會從 [Azure 入口網站 碳優化] 刀鋒視窗部分收集，並盡可能透過 Proxy 部分計算。

請務必使用不同的架構來收集 Azure 碳優化數據，原因有兩個重要原因：

• Azure 碳優化數據只會儲存並顯示過去 12 個月（在滾動視窗中）。 需要碳足跡的長期追蹤時，專用系統可確保保留詳細的歷史資訊。
• 應用程式可能會跨越多個基礎結構，而 Azure 只有一個元件。 個別的架構可讓您集中監視所有環境的碳影響，以提供整體檢視，並確保更全面的永續性見解。

資料來源

一般而言，您應該建立具有少數變數的 Proxy 方程式。 您選擇的 Proxy 計量應該代表應用程式的行為和效能。

此範例會使用這些計量：

• 從碳排放 API 擷取的基礎結構碳排放。 此 API 是 排放影響儀表板 和 Azure 入口網站 中的 [碳優化] 刀鋒視窗的來源。 數據可在資源群組層級取得，讓您更輕鬆地追蹤應用程式的排放。
• 從 Application Insights 收集的應用程式效能和調整計量：
  • 應用程式的調整因數（API 呼叫、伺服器要求或其他計量）
  • CPU 使用量
  • 記憶體使用量
  • 回應時間（傳送和接收）

如需如何設定Application Insights 以取得必要計量的教學課程，請參閱 ASP.NET Core 應用程式的Application Insights。

您可以將其他變數新增至方程式，例如：

• 邊緣服務和基礎結構碳排放。
• 使用者連接的時間，因為電力生產和需求隨著時間而有所不同。
• 應用程式的任何其他計量，可告訴您其效能隨著時間的變化。

藉由將此方程式建置成一個分數，也可以反映用戶數目，即可建立最接近碳分數的近似值。 此分數是您針對應用程式可持續性所做的任何進一步變更和改進的基準。

成本是與應用程式效能相關聯的另一個考慮。 在大部分情況下，可以建立效能效率與成本與碳節約之間的直接相互關聯。 這種相互關聯會導致下列假設：

• 當效能較高但成本相同時，您已將應用程式優化並降低碳排放量。
• 當成本降低但效能相同時，您已將應用程式優化並降低碳排放量。
• 當效能和成本增加時，您尚未將應用程式優化，且已增加碳排放量。
• 當成本增加但效能降低或相同時，您尚未優化應用程式並增加碳排放（或能源成本較高，這也是導致碳排放增加的原因）。

應用程式 SCI 分數、成本和效能之間的這種相互關聯對於每個應用程式而言都是唯一的，而且取決於許多因素。 藉由收集這三個變數的數據，您可以建立相互關聯演算法，讓您預測這三個變數的任何變化，以及針對應用程式架構和模式做出明智的決策。

計算

在此所述的案例中，無法為所使用的 Proxy 形成離散計算。 相反地，從 排放影響儀表板 收集的數據會以起點處理。 以下是 SCI 基準計算：

SCI = C∗R

在此方程式中：

• C 是應用程式的碳排放量。 此值會受到應用程式在 Azure 上部署的方式所影響。 例如，如果所有應用程式資源都位於單一資源群組中， C 則為該資源群組的碳排放量。

  注意

  目前，會忽略應用程式的其他排放來源，因為它們相依於架構和邊緣/用戶行為。 如果您使用 Proxy 進行數據，您可以在下一個步驟中考慮這些來源。

• R 是應用程式的縮放比例。 這可以是時間範圍、API 要求、Web 要求或其他一些計量的平均並行用戶數目。 這個值很重要，因為它會導致分數來說明應用程式使用量的整體影響，而不只是其部署使用量。

當然，時間範圍是這項計算的另一個重要方面：任何耗能裝置或系統的碳排放量會隨著時間而有所不同，因為能源電網在某些時候可能會有可再生能源或替代能源（例如太陽能），但在某些時候沒有。 因此，請務必從最短的時間範圍開始，以提高精確度。 例如，您可能從每日或每小時計算開始。

碳排放 API 目前會根據訂用帳戶內的服務，在資源群組層級提供每月碳資訊。 藉由使用提供的 REST API，您可以將 排放數據 匯出至數據湖，以保存應用程式的所有永續性數據。

資料存放區

您應該儲存您在解決方案中收集的碳和碳 Proxy 資訊，以便連線到儀錶板或報表。 這麼做可讓您將一段時間的碳分數可視化，並做出明智的選擇。 若要改善永續性，並符合 Azure 架構架構的最佳做法，建議您使用最低可行的系統。 （請參閱Azure 上可持續工作負載的數據和記憶體設計考慮，以及 Azure 上可持續工作負載的應用程式平台考慮。此架構會使用 Azure Data Lake Storage。

資料相互關聯

當您開始收集應用程式碳、效能和成本的數據時，您將會有寶貴的資訊，可讓您建立應用程式專屬的相互關聯演算法，並在您規劃成本、效能和碳優化時提供指引。

如需詳細資訊，請參閱如何選取 Azure 機器學習 的演算法。

資料顯示

您可以透過各種方式顯示數據和計算，包括自定義 的 Azure 監視器儀錶板 和簡單的 Power BI 儀錶板。

您的 SCI 分數觸發程式為何？

知道您的可持續性分數之後，您可能會想知道如何改善它。

如果您可以使用 Proxy 為應用程式的碳影響評分，下一個步驟是專注於定義分數中不利條件可觸發的動作。 這些條件的部分範例包括：

• 能源生產和需求一直處於高位，因此生產成本昂貴。
• 電力無法使用。 這種情況可能是由自然災害或地緣政治衝突造成的。
• 資源過度耗用量或供應鏈問題所造成的邊緣基礎結構突然無法使用。

當您識別可能會影響應用程式的失敗點時，您可以決定要採取哪些動作，讓您的應用程式能夠彈性地復原碳尖峰。

您可以採取下列其中一個動作：

• 如 Well-Arcchitected Framework 檔中所述，套用應用程式的服務和功能正常降低。
• 建立應用程式的生態模式版本。 生態模式是一種更簡單、更小、更便宜、更可持續的應用程式版本，可提供最少的功能。 您可以在碳排放尖峰期間還原為此版本。 您也可以直接將終端使用者定型為依選擇使用生態版本。 您可以提供「綠色按鈕」，讓用戶能夠使用更精簡的介面、較少的圖形，以及有限的功能，以換取減少碳排放。
• 如果您選擇牽涉到您的使用者，您可以建立一個機會來推動文化變更，以及技術變更：
  • 您可以指定選擇的影響：「使用生態版本，可節省 x 碳量 」或「將碳分數 帶入 y 量」。
  • 您可以了解用戶行為，並修改生態版本以反映其選擇。 （也許他們使用 10% 的功能，並且是生態版的理想使用者。
  • 由於完整版本已針對排放進行優化，因此您最好最終合併這兩個版本。

考量

這些考量能實作 Azure Well-Architected Framework 的支柱，其為一組指導原則，可以用來改善工作負載的品質。 如需更多資訊，請參閱 Microsoft Azure 結構完善的架構。

安全性

安全性可提供保證，以避免刻意攻擊和濫用您寶貴的資料和系統。 如需詳細資訊，請參閱安全性支柱的概觀。

如需其他安全性，您可以使用 Azure 虛擬網絡 服務端點來移除對 Azure 服務資源的公用因特網存取，只允許來自虛擬網路的流量。

透過這種方法，您會在 Azure 中建立虛擬網路，然後為 Azure 服務建立私人服務端點。 然後，這些服務僅限提供給來自該虛擬網路的流量。 您也可以透過閘道從內部部署網路連線它們。

請記住，若要將資料從內部部署移至 Azure 記憶體，您必須允許來自內部部署或 Azure ExpressRoute 的公用 IP 位址。 如需詳細資訊，請參閱將專用 Azure 服務部署至虛擬網路。

如需設計安全解決方案的一般指引，請參閱 Azure 安全性檔。

成本最佳化

成本最佳化與減少不必要費用，及提升營運效率有關。 如需詳細資訊，請參閱成本最佳化支柱的概觀。

您可以使用多個替代的 Azure 服務來部署此架構。 這是故意保持至少節省成本和碳排放。

雖然我們鼓勵您使用已在應用程式部署中擁有的對等服務，但每個架構元件都有定價資訊：

• 排放影響儀表板、Azure 碳優化和Microsoft成本管理報告是免費的。
• Application Insights 定價。
• Azure 數據表記憶體定價。
• Azure Logic Apps 定價。
• Azure Functions 定價。
• Azure 自動化 定價。

效能效率

效能效率可讓您的工作負載進行調整，以有效率的方式符合使用者對其放置的需求。 有關更多資訊，請參閱性能效率支柱概述。

此架構的主要目的是透過對成本和碳影響最小的程式，為您的應用程式提供永續性分數。 大部分元件都是平台即服務 (PaaS) 和無伺服器 Azure 服務，可根據使用狀況和流量獨立調整。

在此案例中，儀錶板和儲存介面不適合大量使用和諮詢。 如果您打算將它提供給大量使用者，您可能會想要考慮下列其中一個選項：

• 藉由轉換擷取的數據，並將其儲存在不同的系統中，來分離擷取的數據。
• 以更可調整的數據結構替代方式取代 Data Lake Storage 或 Azure 數據表記憶體，例如 Azure Cosmos DB。

參與者

本文由 Microsoft 維護。 原始投稿人如下。

主要作者：

• Paola Annis |主要客戶體驗工程經理
• Davide Bedin |資深雲端解決方案架構師，應用程式創新

其他投稿人：

• Chad Kittel | 首席軟體工程師

若要查看非公開的 LinkedIn 設定檔，請登入 LinkedIn。

下一步

本文符合綠色軟體基金會的原則和方法。 建立更綠色應用程式的下一個步驟是將碳感知 SDK 內嵌至您的應用程式，以便在符合特定碳條件時即時自動化觸發程式。

如需優化 Azure 工作負載的建議，請參閱 永續性雲端工作負載指引。

相關資源

• 在 Azure 中選擇資料分析和報告技術
• 受監管產業的資料分析工作負載