Mäta azure-appens hållbarhet med hjälp av SCI-poängen

Lösningen som beskrivs i den här artikeln kan hjälpa dig att skapa en hållbarhetsmodell för program som finns i Azure. Modellen använder proxyservrar som med tiden gör att du kan bedöma ett programs koldioxidpåverkan och effektivitet. Poängen kallas SCI-poängen (Software Carbon Intensity). Den ger en baslinje för att mäta ändringar i ett programs koldioxidutdata.

Arkitektur

Ladda ned en Visio-fil med den här arkitekturen.

Dataflöde

1. Konfigurera programdatakällor som du ska använda för att beräkna DIN SCI-poäng. Data kan vara de utsläppsmätningar som tillhandahålls av bladet Koldioxidoptimering i Azure Portal, eller så kan de vara proxymätningar från källor eller system som inte kommer från Microsoft.
2. Exportera data om koldioxidutsläpp till din datasjö.
3. Använd händelsehanterare som Azure Functions eller Azure Logic Apps för att beräkna SCI-poängen. Utdata är mängden koldioxid som genereras i gram per enhet, där enheten refererar till programmets skalningsfaktor eller en uppskattning av den som baseras på proxyservrar.
4. Använd tekniker som Azure Functions, Logic Apps eller Azure Automation-runbooks för att utlösa behovsutformning i programmet eller för att initiera programmets fördefinierade ekoläge.
5. Använd Power BI för att rapportera och visualisera poängen och dess variation över tid.

Komponenter

• Bladet Koldioxidoptimering i Azure Portal ger koldioxidutsläppsmätningar av Azure-arbetsbelastningar på resursgruppsnivå.
• Cloud for Sustainability-API:et tillhandahåller underliggande data för koldioxidoptimering. Du kan använda den för att hämta information om prenumerationens utsläpp.
• Application Insights är en funktion i Azure Monitor som tillhandahåller programprestandahantering (APM). Det kan hjälpa dig att få kraftfulla insikter om hur personer använder din app. Du kan använda den här kunskapen för att fatta datadrivna beslut om att förbättra programmets effektivitet.
• Azure Blob Storage lagrar utsläppsinformationen från Azures koldioxidoptimering, från anpassade beräkningar eller från andra proxyservrar för utsläpp.
• Azure Data Lake är en centraliserad lagringsplats som matar in och lagrar stora mängder data i sin ursprungliga form. Data kan sedan bearbetas och användas som grund för olika analysbehov.
• Med Azure Logic Apps kan du skapa och köra automatiserade arbetsflöden med lite eller ingen kod. Genom att använda den visuella designern och välja mellan fördefinierade åtgärder kan du snabbt skapa ett arbetsflöde som integrerar och hanterar dina proxykällor, datalagring och effektivitetsberäkningssystem.
• Med Azure Functions kan du köra små kodenheter. Den skalar automatiskt resurser baserat på efterfrågan och du betalar bara för den faktiska körningstiden. Du kan använda den för att göra hållbarhetsberäkningar och lagra dem i Blob Storage eller en datasjö.
• Azure Automation tillhandahåller processautomatisering via runbooks. Du kan använda runbooks för att implementera komplex logik med hjälp av PowerShell-kod som kan påverka ditt program för att förbättra effektiviteten. Den här tjänsten kan också lägga till affärsvärde genom att minska fel och driftskostnader.
• Med Power BI kan du omvandla dina data till analyser och rapporter som ger insikter i realtid.

Alternativ

De Azure-tjänster som beskrivs i den här artikeln kan ersättas med liknande tjänster. Om du vill öka densiteten och användningen av befintliga resurser utför du beräkningarna med minsta möjliga påverkan på infrastrukturen med hjälp av Azure-tjänster eller -verktyg som redan har distribuerats i din miljö:

• Du kan ersätta Power BI-instrumentpaneler med Azure Monitor-arbetsböcker eller Azure Managed Grafana-tjänster .
• Du kan ersätta Application Insights med andra APM-verktyg (Application Performance Management), till exempel Elasticsearch Application Performance Management (APM) eller OpenAPM.
• Data i form av tabeller eller ostrukturerade data kan behållas i valfritt arkivhandlingssystem, till exempel MySQL eller MariaDB eller Azure Cosmos DB och MongoDB.
• Om du har ett Azure Functions- eller Logic Apps-utrymme som körs kan du köra beräkningen regelbundet från dina befintliga distributioner.
• Om programresurserna distribueras över flera resursgrupper kan du använda taggar för att korrelera kostnadsdata och beräkna mängden koldioxid som genereras av programmet.

Information om scenario

Den här arkitekturen är utformad för att samla in koldioxidoptimeringsdata från Azure och andra källor för att ge en omfattande översikt över ett programs miljöpåverkan. Data samlas in från Azures koldioxidoptimering. För icke-Azure-miljöer används en proxy för att hämta relevanta koldioxidmått. När data har konsoliderats utförs SCI-beräkningar för att utvärdera det totala koldioxidavtrycket. Resultaten lagras sedan i ett Azure Storage-konto eller en datasjö för långsiktig kvarhållning, vilket möjliggör BI-analys och historisk rapportering. Den här metoden säkerställer centraliserad spårning av koldioxidpåverkan i olika infrastrukturer och stöder strategiska hållbarhetsinsatser.

Informationen om koldioxidutsläpp samlas delvis in från bladet Azure Portal Koldioxidoptimering och beräknas delvis, om möjligt, via proxy.

Det är viktigt att använda en separat arkitektur för att samla in data om koldioxidoptimering i Azure av två viktiga orsaker:

• Azures koldioxidoptimeringsdata lagras och visas endast under de senaste tolv månaderna (i ett rullande fönster). När långsiktig spårning av ett koldioxidavtryck krävs säkerställer ett dedikerat system kvarhållningen av detaljerad historisk information.
• Ett program kan omfatta flera infrastrukturer, med Azure som endast en komponent. En separat arkitektur möjliggör centraliserad övervakning av koldioxidpåverkan i alla miljöer för att ge en holistisk vy och säkerställa mer omfattande hållbarhetsinsikter.

Datakällor

I allmänhet bör du skapa en proxyekvation med få variabler. De proxymått som du väljer ska representera programmets beteende och prestanda.

Dessa mått används i det här exemplet:

• Koldioxidutsläppen i infrastrukturen, som hämtas från API:et för koldioxidutsläpp . Det här API:et är källan för både Instrumentpanel för miljöpåverkan och bladet Koldioxidoptimering i Azure Portal. Data är tillgängliga på resursgruppsnivå, vilket gör det enklare att spåra programmets utsläpp.
• Prestanda- och skalningsmått för programmet som samlas in från Application Insights:
  • Skalningsfaktorn (API-anrop, serverbegäranden eller något annat mått) för programmet
  • CPU-användning
  • Minnesanvändning
  • Svarstid (skicka och ta emot)

En självstudiekurs om hur du konfigurerar Application Insights för att hämta de mått som krävs finns i Application Insights för ASP.NET Core-program.

Du kan lägga till andra variabler i ekvationen, till exempel:

• Edge-tjänster och koldioxidutsläpp från infrastrukturen.
• Tiden när användarna ansluter, eftersom elproduktion och efterfrågan varierar med tiden.
• Alla andra mått för appen som kan berätta hur dess prestanda ändras över tid.

Genom att skapa den här ekvationen till en poäng som också kan återspegla antalet användare skapar du den närmaste uppskattningen till en koldioxidpoäng. Den här poängen är ditt riktmärke för ytterligare ändringar och förbättringar av appens hållbarhet.

Kostnaden är en annan faktor som är associerad med programprestanda. I de flesta fall kan en direkt korrelation mellan prestandaeffektivitet och kostnad och koldioxidbesparingar upprättas. Den här korrelationen leder till följande antaganden:

• När prestandan är högre men kostnaderna är desamma har du optimerat appen och minskat koldioxidutsläppen.
• När kostnaderna minskas men prestandan är densamma har du optimerat appen och minskat koldioxidutsläppen.
• När både prestanda och kostnader ökar har du inte optimerat appen och du har ökat koldioxidutsläppen.
• När kostnaderna ökar men prestandan minskar eller är densamma har du inte optimerat appen och har ökat koldioxidutsläppen (eller så är energikostnaden högre, vilket också är en orsak till högre koldioxidutsläpp).

Den här korrelationen mellan SCI-poäng, kostnad och prestanda för ett program är unik för varje program och beror på många faktorer. Genom att samla in data för dessa tre variabler kan du skapa en korrelationsalgoritm som gör att du kan förutse alla varianter av de tre och fatta välgrundade beslut om programarkitekturen och -mönstren.

Beräkningar

I scenariot som beskrivs här går det inte att skapa en diskret beräkning för de proxyservrar som används. I stället bearbetas de data som samlas in från Instrumentpanel för miljöpåverkan som utgångspunkt. Här är SCI-baslinjeberäkningen:

SCI = C*R

I den här ekvationen:

• C är koldioxidutsläppen för programmet. Det här värdet påverkas av hur programmet distribueras i Azure. Om alla programresurser till exempel finns i en enda resursgrupp C är koldioxidutsläppen för den resursgruppen.

  Kommentar

  För tillfället ignoreras andra utsläppskällor för programmet eftersom de är beroende av arkitekturen och beteendet för gränsen/användaren. Om du använder proxyservrar för data kan du överväga dessa källor i nästa steg.

• R är skalningsfaktorn för programmet. Det kan vara antalet genomsnittliga samtidiga användare för tidsfönstret, API-begäranden, webbbegäranden eller något annat mått. Det här värdet är viktigt eftersom det leder till en poäng som står för den totala effekten av användningen av programmet, inte bara dess distributionsfotavtryck.

Tidsfönstret är naturligtvis en annan viktig aspekt av denna beräkning: Koldioxidutsläppen för alla energiförbrukande enheter eller system varierar över tid, eftersom energinätet kan ha förnybara eller alternativa energikällor (till exempel solenergi) vid vissa tillfällen men inte på andra. Det är därför viktigt att börja med kortast möjliga tidsram för att öka precisionen. Du kan till exempel börja med en daglig beräkning eller timberäkning.

API:et för koldioxidutsläpp tillhandahåller för närvarande månatlig koldioxidinformation baserat på tjänsterna i en prenumeration, på resursgruppsnivå. Med hjälp av det tillhandahållna REST-API:et kan du exportera utsläppsdata till en datasjö som innehåller alla hållbarhetsdata för programmet.

Datalagring

Du bör lagra den koldioxid- och koldioxidproxyinformation som du samlar in i en lösning som du kan ansluta till instrumentpaneler eller rapporter. På så sätt kan du visualisera din koldioxidpoäng över tid och göra välgrundade val. För att förbättra hållbarheten och följa metodtipsen för Azure Well-Architected Framework rekommenderar vi att du använder det minsta fungerande systemet. (Mer information finns i Designöverväganden för data och lagring för hållbara arbetsbelastningar på Azure - och programplattformsöverväganden för hållbara arbetsbelastningar i Azure.) Azure Data Lake Storage används i den här arkitekturen.

Datakorrelationer

När du börjar samla in data om programmets koldioxid, prestanda och kostnad har du värdefull information som gör att du kan skapa en korrelationsalgoritm som är specifik för ditt program och som ger vägledning när du planerar för kostnad, prestanda och koldioxidoptimering.

Mer information finns i Så här väljer du algoritmer för Azure Machine Learning.

Datavisning

Du kan visa dina data och beräkningar på olika sätt, inklusive anpassade Azure Monitor-instrumentpaneler och enkla Power BI-instrumentpaneler.

Vad kan din SCI-poängutlösare?

När du vet din hållbarhetspoäng kanske du undrar hur du kan förbättra den.

Om du kan bedöma programmets koldioxidpåverkan med hjälp av proxyservrar är nästa steg att fokusera på att definiera åtgärder som kan utlösas av ogynnsamma villkor i poängen. Några exempel på dessa villkor är:

• Energiproduktionen och efterfrågan är på en all-time-high och är därför dyr att producera.
• Elektricitet är inte tillgängligt. Det här villkoret kan orsakas av en naturkatastrof eller geopolitisk konflikt.
• Plötslig otillgänglighet för gränsinfrastruktur som orsakas av resursöverförbrukning eller problem med leveranskedjan.

När du kan identifiera felpunkter som kan påverka ditt program kan du bestämma vilka åtgärder du ska vidta för att göra ditt program motståndskraftigt mot koltoppar.

Du kan utföra någon av följande åtgärder:

• Tillämpa en graciös försämring av appens tjänster och funktioner enligt beskrivningen i dokumentationen om Well-Arcchitected Framework.

• Skapa en miljölägesversion av ditt program. Ekoläge är en enklare, mindre, billigare och mer hållbar version av programmet som erbjuder minimala funktioner. Du kan återgå till den här versionen vid toppar av koldioxidutsläpp. Du kan också träna slutanvändarna att använda en miljöversion efter val. Du kan ange en "grön knapp" som gör det möjligt för människor att använda ett smalare gränssnitt, färre grafikfunktioner och begränsade funktioner i utbyte mot minskade koldioxidutsläpp.

• Om du väljer att involvera dina användare skapar du en möjlighet att driva en kulturell förändring tillsammans med den tekniska: – Du kan ange effekten av valet: "Genom att använda eco-versionen sparar du x mängd koldioxid" eller "tar vår koldioxidpoäng till y-mängd." - Du kan få en förståelse för användarbeteende och ändra ekoversionen så att den återspeglar deras val. (De kanske använder 10 % av funktionerna och är en idealisk användare av eco-versionen.) - Eftersom den fullständiga versionen är optimerad för utsläpp, kan du helst så småningom slå samman de två versionerna.

Att tänka på

Dessa överväganden implementerar grundpelarna i Azure Well-Architected Framework, som är en uppsättning vägledande grundsatser som kan användas för att förbättra kvaliteten på en arbetsbelastning. Mer information finns i Microsoft Azure Well-Architected Framework.

Säkerhet

Säkerhet ger garantier mot avsiktliga attacker och missbruk av dina värdefulla data och system. Mer information finns i Översikt över säkerhetspelare.

För ytterligare säkerhet kan du använda tjänstslutpunkter för Azure Virtual Network för att ta bort offentlig Internetåtkomst till Azure-tjänstresurser, vilket endast tillåter trafik från ditt virtuella nätverk.

Med den här metoden skapar du ett virtuellt nätverk i Azure och skapar sedan privata tjänstslutpunkter för Azure-tjänster. Dessa tjänster begränsas sedan till trafik från det virtuella nätverket. Du kan också nå dem från ditt lokala nätverk via en gateway.

Tänk på att för att kunna flytta data från en lokal plats till Azure Storage måste du tillåta offentliga IP-adresser från lokala adresser eller Azure ExpressRoute. Mer information finns i Distribuera dedikerade Azure-tjänster till virtuella nätverk.

Allmän vägledning om hur du utformar säkra lösningar finns i Dokumentation om Azure-säkerhet.

Kostnadsoptimering

Kostnadsoptimering handlar om att minska onödiga utgifter och förbättra drifteffektiviteten. Mer information finns i Översikt över kostnadsoptimeringspelare.

Du kan distribuera den här arkitekturen med hjälp av flera alternativa Azure-tjänster. Det hölls avsiktligt som ett minimum för att spara på kostnader och koldioxidutsläpp.

Vi rekommenderar att du använder motsvarande tjänster som du redan har i programdistributionen, men prisinformation är tillgänglig för varje arkitekturkomponent:

• Rapporterna Instrumentpanel för miljöpåverkan, Azure-koldioxidoptimering och Microsoft Cost Management är kostnadsfria.

• Prissättning för Application Insights.

• Prissättning för Azure Table Storage.

• Prissättning för Azure Logic Apps.

• Prissättning för Azure Functions.

• Prissättning för Azure Automation.

Prestandaeffektivitet

Prestandaeffektivitet är arbetsbelastningens förmåga att skala för att uppfylla användarnas krav på ett effektivt sätt. Mer information finns i Översikt över grundpelare för prestandaeffektivitet.

Det primära syftet med den här arkitekturen är att tillhandahålla en hållbarhetspoäng för dina program via en process som har minimal påverkan på kostnader och koldioxid. De flesta komponenterna är PaaS-tjänster (plattform som en tjänst) och serverlösa Azure-tjänster som kan skalas oberoende baserat på användning och trafik.

I det här scenariot är instrumentpanelen och lagringsgränssnittet inte avsedda för massiv användning och konsultation. Om du planerar att ge det till ett stort antal användare kanske du vill överväga något av följande alternativ:

• Frikoppla extraherade data genom att transformera dem och lagra dem i ett annat system.
• Ersätt Data Lake Storage eller Azure Table Storage med ett mer skalbart datastrukturalternativ, till exempel Azure Cosmos DB.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudsakliga författare:

• Paola Annis | Principal Customer Experience Engineering Manager
• Davide Bedin | Senior Cloud Solution Architect, Application Innovation

Annan deltagare:

• Chad Kittel | Huvudprogramtekniker

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg

Den här artikeln är anpassad till principerna och metodiken i Green Software Foundation. Nästa steg i att skapa ett grönare program är att bädda in Carbon Aware SDK i ditt program så att utlösare kan automatiseras i realtid när specifika koldioxidförhållanden uppfylls.

Rekommendationer för att optimera Azure-arbetsbelastningar finns i Vägledning för arbetsbelastningar i hållbarhetsmoln.

Relaterade resurser

• Välj en dataanalys- och rapporteringsteknik i Azure
• Arbetsbelastningar för dataanalys för reglerade branscher