Blog
Messen Sie Ihren Azure Carbon Footprint mit der Sustainability API

Sie möchten also mit grüner Software in der Azure-Cloud beginnen, indem Sie Ihren CO2-Fußabdruck messen. Aber wo fangen Sie an? Die Sustainability API von Microsoft Azure kann Unternehmen dabei helfen, ihren CO2-Fußabdruck zu messen, um ihn zu analysieren und zu reduzieren. In diesem Blog erfahren Sie mehr über die Daten zum Kohlenstoffausstoß und wie Sie diese für eine nachhaltigere Zukunft nutzen können. Doch zunächst ein Überblick.
Übersicht Azure's Sustainability API
Die Azure Sustainability API ist Teil der umfassenderen Microsoft Cloud for Sustainability (MCfS), einer Suite von Tools, die Unternehmen dabei helfen sollen, ihre Umweltauswirkungen zu verfolgen, zu verwalten und zu reduzieren. Bevor Sie die API nutzen können, müssen Sie einige Voraussetzungen erfüllen, die auf der folgenden Seite näher erläutert werden: Cloud for Sustainability API (Vorschau) Übersicht.
Sie haben die Wahl zwischen einer OData-API und einer Export-API. Lassen Sie uns die JSON-Ausgabe des OData-API-Aufrufs aufschlüsseln, um die Emissionen zu erhalten und zu verstehen, welche Informationen sie liefert. Bitte beachten Sie, dass sich die API zum Zeitpunkt der Erstellung dieses Artikels noch in der Vorschau befindet und die Dokumentation unvollständig ist. Einige Beschreibungen sind also meine Interpretation der Daten. Sehen wir uns den aus meiner Sicht spannendsten Endpunkt in diesem Blogbeitrag an: Der Endpunkt EmissionsByEnrollment!
Zerlegen des Endpunkts EmissionsByEnrollment
Die HTTP-GET-Anfrage zum Abrufen von Emissionen nach Einschreibung, die zum Zeitpunkt des Verfassens dieses Artikels die einzige Option in Azure ist, sieht wie folgt aus: https://api.mcfs.microsoft.com/api/v1.0/instances/{instanceId} /enrollments/{enrollmentId}/emissions[?$apply][&$filter][&$select][&$orderby][&$expand][&$top][&$skip][&$count] und heißt 'EmissionsByEnrollment'.
Wir geben die 'instanceId' ein, die wir zuvor, wie unter dem angegebenen Link beschrieben, erstellt haben, und geben die 'enrollmentId' (lies 'billingId') ein. Die anderen Parameter lassen wir vorerst weg. Wenn wir den Aufruf tätigen, erhalten wir eine EnrollmentEmissionCollection, die aus EnrollmentEmission-Objekten besteht, die im JSON-Format wie folgt aussehen:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15 |
{ "rowNum": 1234, "dateKey": 20230201, "enrollmentId": "GUID1:GUID2_YYYY-MM-DD", "orgName": "", "subscriptionId": "GUID", "subscriptionName": "Subscription Name", "azureServiceName": "Azure Monitor", "subService": "Azure Other", "azureRegionName": "North Central US", "scope": "Scope1", "scopeId": 1, "totalEmissions": 3.3200622506179E-08, "pk": "dataKey + 1 + subscriptionID + subService"} |
Um das JSON-Objekt EnrollmentEmission richtig zu deserialisieren, müssen Sie die folgende Klasse in C#.NET erstellen:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41 |
internal class EnrollmentEmission{ [JsonProperty("rowNum")] public int RowNum { get; set; } [JsonProperty("dateKey")] public long DateKey { get; set; } [JsonProperty("enrollmentId")] public string EnrollmentId { get; set; } [JsonProperty("orgName")] public string OrgName { get; set; } [JsonProperty("subscriptionId")] public string SubscriptionId { get; set; } [JsonProperty("subscriptionName")] public string SubscriptionName { get; set; } [JsonProperty("azureServiceName")] public string AzureServiceName { get; set; } [JsonProperty("subService")] public string SubService { get; set; } [JsonProperty("azureRegionName")] public string AzureRegionName { get; set; } [JsonProperty("scope")] public string Scope { get; set; } [JsonProperty("scopeId")] public int ScopeId { get; set; } [JsonProperty("totalEmissions")] public double TotalEmissions { get; set; } [JsonProperty("pk")] public string Pk { get; set; }} |
|
1
2
3
4
5
6
7
8
9
10
11 |
internal class EnrollmentEmissionCollection{ [JsonProperty("@odata.context")] public string Context { get; set; } [JsonProperty("value")] public List<EnrollmentEmission> Value { get; set; } [JsonProperty("@odata.nextLink")] public string NextLink { get; set; }} |
- rowNum: Ein fortlaufender Bezeichner für die Datenzeile innerhalb eines Datensatzes, der eine einfache Referenz und Verwaltung ermöglicht. In diesem Fall ist die Zeilennummer 1234.
- dateKey: Das mit den Daten verbundene Datum, formatiert als JJJJMMTT. Dieser Eintrag, 20230201, zeigt an, dass die Daten für den 1. Februar 2023 sind. Bitte beachten Sie, dass die Daten, soweit ich das beobachten konnte, monatlich gespeichert werden. Das bedeutet, dass Sie die Veränderungen bei den Kohlenstoffemissionen nur pro Monat verfolgen können!
- enrollmentId: Eine eindeutige Kennung für eine bestimmte Anmeldung oder ein Konto in Azure, die aus zwei GUIDs und einem Datum besteht. Besser bekannt als die Abrechnungs-ID.
- orgName: Der Name der Organisation, die mit den Daten verknüpft ist (in meinen Tests schien dies immer leer zu sein).
- subscriptionId: Ein eindeutiger Bezeichner für ein Azure-Abonnement.
- AbonnementName: Ein benutzerfreundlicher Name für das Azure-Abonnement.
- azureServiceName: Der spezifische Azure-Dienst, der verwendet wird, hier "Azure Monitor".
- subService: Der spezifische Unterdienst, der innerhalb des umfassenderen Azure-Dienstes verwendet wird. In diesem Beispiel als "Azure Other" bezeichnet, handelt es sich um einen Dienst, der nicht in die vordefinierten Kategorien passt oder verschieden ist.
- azureRegionName: Der geografische Standort der Azure-Region, in der der Dienst bereitgestellt wird. Für diesen Datensatz wird "North Central US" angegeben, was auf den physischen Standort der Infrastruktur hinweist.
- Umfang: Dies bezeichnet den Umfang der Kohlenstoffemissionen auf der Grundlage des Unternehmensstandards Greenhouse Gas (GHG) Protocol. "Scope1"-Emissionen sind direkte Emissionen aus eigenen oder kontrollierten Quellen, wie z.B. den Kühlsystemen in Rechenzentren.
- scopeId: Ein numerischer Identifikator, der dem Emissionsbereich entspricht, hier 1 für Scope 1 Emissionen.
- totalEmissionen: Die gesamten Kohlenstoffemissionen (gemessen in Tonnen CO2-Äquivalent) im Zusammenhang mit den angegebenen Ressourcen oder Dienstleistungen für den angegebenen Zeitraum. Der Wert der gesamten Kohlenstoffemissionen 3.3200622506179E-08 ist 0.000033200622506179004 kgs CO2eq.
- pk: Steht wahrscheinlich für 'primary key', einen eindeutigen Bezeichner für den Datensatz. Dieser Wert scheint eine Verkettung von 'dateKey', der Zahl '1', 'subscriptionId' und 'subService' zu sein, die zur Sicherstellung der Eindeutigkeit und möglicherweise zu Indizierungszwecken verwendet wird. Er wird in der Eigenschaft 'nextLink' von EnrollmentEmissionCollection verwendet, über die Sie im nächsten Absatz lesen können.
Microsofts Methode zur Berechnung der Kohlenstoffemissionen
Wie bereits in diesem Blog erwähnt, gibt die API Bereiche zurück (siehe: 'Bereich'). Microsofts Methodik zur Berechnung der Kohlenstoffemissionen entspricht globalen Standards wie dem GHG Protocol. Der Prozess umfasst folgende Punkte:- Umfang der Emissionen: Die Einbeziehung aller drei Bereiche gewährleistet einen umfassenden Blick auf die Emissionen.
- Datenerfassung: Sammeln von Nutzungsdaten von Azure-Diensten (es gibt einen separaten Endpunkt für Nutzungsdaten, den ich mir in meinem nächsten Blogbeitrag ansehen werde).
- Emissionsfaktoren: Anwendung regionsspezifischer Emissionsfaktoren, um die tatsächliche Kohlenstoffintensität widerzuspiegeln.
- Kohlenstoffbuchhaltung: Ein Ansatz zur Erfassung von direkten Emissionen (Scope 1), indirekten Emissionen aus eingekaufter Energie (Scope 2) und anderen indirekten Emissionen (Scope 3).
- Berechnung und Berichterstattung: Aggregieren von Daten zur Berechnung der gesamten Kohlenstoffemissionen, die dann im Feld totalEmissions in der zuvor beschriebenen JSON-Ausgabe wiedergegeben werden.
- Kontinuierliche Verbesserung: Sicherstellen, dass die Methodik durch ständige Verfeinerung und Validierung durch Dritte immer besser wird. Sie erhalten auch ständig mehr und bessere Informationen über verkörperten Kohlenstoff von anderen Parteien.
Die SCI-Spezifikation der GSF
Die SCI-Spezifikation der Green Software Foundation bietet einen standardisierten Ansatz zur Messung der CO2-Bilanz von Software. Er hilft, die Nachhaltigkeit Ihrer digitalen Lösungen zu verstehen und zu verbessern. Der SCI wird wie folgt berechnet:SCI=(O∗E∗I)/R
Wo O steht für betriebliche Emissionen, E ist der Energieanteil, I steht für die standortbezogene Kohlenstoffintensität, und R ist die Basislinie für die Normalisierung.
Das Feld "totalEmissions" aus der Azure Sustainability API kann ein wichtiger Faktor bei der Berechnung des SCI-Scores von Azure sein. Durch den Vergleich der betrieblichen Emissionen (O) mit der insgesamt verbrauchten Energie (ein weiterer Endpunkt, auf den wir ein anderes Mal eingehen werden) und der Kohlenstoffintensität der Energiequelle können Unternehmen ein differenziertes Verständnis der Kohlenstoffintensität ihrer Software erhalten. Wenn diese Kennzahl im Laufe der Zeit verfolgt wird, kann sie als Richtschnur für Strategien zur Verringerung des CO2-Fußabdrucks dienen und die betriebliche Effizienz mit der Nachhaltigkeit in Einklang bringen. Wie bereits erwähnt, müssen Sie sich bei der Diskussion über den 'dataKey' etwas gedulden, denn die Daten werden nur einmal im Monat bereitgestellt, so scheint es mir. Ein Blog-Beitrag mit einem ausgearbeiteten Beispiel für die Berechnung des SCI ist derzeit in Arbeit, während ich dies schreibe.
Jetzt wissen wir, wie wir die wahren Auswirkungen des CO2-Fußabdrucks unserer Software messen können. Wie können Unternehmen diese Daten nutzen?
Die Daten nutzen
Ihren CO2-Fußabdruck zu verstehen, ist nur der erste Schritt. Die wahre Stärke liegt in der Nutzung dieser Daten, um fundierte Entscheidungen zu treffen. Hier sind einige Möglichkeiten, wie Unternehmen diese Daten nutzen können:- Optimieren: Identifizieren Sie Dienste oder Ressourcen mit hohen Emissionen und suchen Sie nach Möglichkeiten, deren Nutzung zu optimieren oder auf effizientere Alternativen umzusteigen. Das kann so einfach sein wie die Verlagerung Ihrer Ressourcen in eine andere Region, was die Green Software Foundation (GSF) als "Carbon Awareness" bezeichnet: "Carbon Awareness". Oder starten Sie einen Batch-Prozess zu einer Zeit mit geringer Kohlenstoffintensität, was als "Time-Shifting" bezeichnet wird, ein Begriff, der von der GSF geprägt wurde. Oder machen Sie weniger Arbeit, wenn die Kohlenstoffintensität hoch ist; machen Sie mehr, wenn die Kohlenstoffintensität niedrig ist, was laut GSF als "Time Shaping" bezeichnet wird.
- Strategische Planung: Nutzen Sie die Daten für die langfristige Planung, um sicherzustellen, dass die Nachhaltigkeit bei zukünftigen Entwicklungen oder Erweiterungen der Infrastruktur entscheidend ist. Integrieren Sie GreenOps in' Ihre Kultur. Das ist natürlich leichter gesagt als getan. Lassen Sie die Transparenz über Ihren CO2-Fußabdruck der erste Schritt sein.
- Berichterstattung & Einhaltung: Da die Umweltverantwortung immer mehr in den Fokus der Gesetzgeber rückt, können diese Daten für die Berichterstattung und die Einhaltung verschiedener Umweltstandards von unschätzbarem Wert sein. Ich denke dabei an die Corporate Sustainability Reporting Directive (CSRD).
Der Weg nach vorn
Auf dem Weg in eine nachhaltigere Zukunft werden Tools wie die Sustainability API von Azure eine entscheidende Rolle spielen. Sie schließen die Lücke zwischen digitaler Transformation und ökologischem Verantwortungsbewusstsein und ermöglichen es Unternehmen, für ihren CO2-Fußabdruck verantwortlich zu sein und proaktive Schritte zu dessen Reduzierung zu unternehmen. Achten Sie auch auf die folgende Seite: https://learn.microsoft.com/en-us/azure/architecture/example-scenario/apps/measure-azure-app-sustainability-sci-score. Da es eine Menge Dynamik an der Front der Software Carbon Intensity (SCI) Bewertung und der auf Microsoft Azure verfügbaren Daten gibt. Bringen Sie jetzt eine MCfS-Instanz zum Laufen und messen Sie die Kohlenstoffemissionen!Verfasst von

Danny van der Kraan
As a Green Software practitioner, I'm dedicated to harnessing the power of code to benefit both our digital landscape and the environment. With a deep passion for software engineering, I specialize in crafting robust distributed systems, encompassing microservices, Domain-Driven Design (DDD), messaging, event sourcing, CQRS, and serverless technologies. Recently, I've delved into AI and Data, continually expanding my skill set. My mission is to assist my clients in adopting sustainable best practices on the Azure cloud, creating a win-win situation for businesses and the planet. Follow my journey and stay updated on my progress at dannyvanderkraan.com.
Unsere Ideen
Weitere Blogs
Contact



