Upravit

Sdílet prostřednictvím


Měření udržitelnosti aplikací Azure pomocí skóre SCI

Azure Monitor
Azure Automation
Azure Logic Apps
Azure Table Storage
Power BI

Řešení popsané v tomto článku vám může pomoct vytvořit model udržitelnosti pro aplikace hostované v Azure. Model používá proxy servery, které v průběhu času umožňují vyhodnotit dopad a efektivitu aplikace na uhlík. Skóre se označuje jako skóre SCI (Software Carbon Intensity). Poskytuje směrný plán pro měření změn ve výstupu uhlíku aplikace.

Architektura

Diagram modelu udržitelnosti, který vyhodnotuje uhlíkový dopad aplikace

Stáhněte si soubor aplikace Visio s touto architekturou.

Tok dat

  1. Nakonfigurujte zdroje dat aplikací, které použijete k výpočtu skóre SCI. Data můžou být měření emisí poskytovaná oknem Optimalizace emisí na webu Azure Portal nebo můžou být proxy měření ze zdrojů nebo systémů jiných společností než Microsoft.
  2. Exportujte data o emisích uhlíku do datového jezera.
  3. K výpočtu skóre SCI použijte obslužné rutiny událostí, jako jsou Azure Functions nebo Azure Logic Apps. Výstupem je množství emisí uhlíku v gramech na jednotku, kde jednotka odkazuje na faktor škálování aplikace nebo aproximaci, která je založena na proxy serverech.
  4. Pomocí technologií, jako jsou Azure Functions, Logic Apps nebo runbooky Azure Automation, můžete aktivovat tvarování poptávky v aplikaci nebo zahájit předdefinovaný ekologický režim aplikace.
  5. Pomocí Power BI můžete hlásit a vizualizovat skóre a její variaci v průběhu času.

Komponenty

  • Okno Optimalizace emisí uhlíku na webu Azure Portal poskytuje měření emisí uhlíku úloh Azure na úrovni skupiny prostředků.
  • Rozhraní API pro cloud pro udržitelnost poskytuje podkladová data pro optimalizaci emisí uhlíku. Můžete ho použít k načtení informací o emisích vašeho předplatného.
  • Application Insights je funkce služby Azure Monitor, která poskytuje správu výkonu aplikací (APM). Může vám pomoct získat výkonné přehledy o tom, jak uživatelé vaši aplikaci používají. Tyto znalosti můžete využít k rozhodování na základě dat o zlepšení efektivity vaší aplikace.
  • Azure Blob Storage ukládá informace o emisích z optimalizace emisí Azure, z vlastních výpočtů nebo z jiných proxy serverů pro emise.
  • Azure Data Lake je centralizované úložiště, které ingestuje a ukládá velké objemy dat v původní podobě. Data je pak možné zpracovávat a používat jako základ pro různé potřeby analýzy.
  • Azure Logic Apps umožňuje vytvářet a spouštět automatizované pracovní postupy s malými až žádným kódem. Pomocí vizuálního návrháře a výběru z předem připravených operací můžete rychle vytvořit pracovní postup, který integruje a spravuje zdroje proxy serveru, úložiště dat a systémy výpočtů efektivity.
  • Azure Functions umožňuje spouštět malé jednotky kódu. Automaticky škáluje prostředky na základě poptávky a platíte jenom za skutečnou dobu provádění. Můžete ho použít k výpočtům udržitelnosti a jejich ukládání ve službě Blob Storage nebo datovém jezeře.
  • Azure Automation poskytuje automatizaci procesů prostřednictvím runbooků. Runbooky můžete použít k implementaci složité logiky pomocí kódu PowerShellu, který může ovlivnit vaši aplikaci, aby se zlepšila efektivita. Tato služba může také přidat obchodní hodnotu snížením chyb a provozních nákladů.
  • Power BI umožňuje převést data na analýzy a sestavy, které poskytují přehledy v reálném čase.

Alternativy

Služby Azure popsané v tomto článku je možné nahradit podobnými službami. Pokud chcete zvýšit hustotu a využití existujících prostředků, proveďte výpočty s minimálním dopadem na vaši infrastrukturu pomocí služeb nebo nástrojů Azure, které jsou už ve vašem prostředí nasazené:

  • Řídicí panely Power BI můžete nahradit sešity Azure Monitoru nebo službami Azure Managed Grafana.
  • Application Insights můžete nahradit jakýmkoli jiným nástrojem pro správu výkonu aplikací (APM), jako je správa výkonu aplikací Elasticsearch (APM) nebo OpenAPM.
  • Data ve formě tabulek nebo nestrukturovaných dat se dají uchovávat v jakémkoli systému záznamů, jako jsou MySQL nebo MariaDB, nebo Azure Cosmos DB a MongoDB.
  • Pokud máte spuštěný prostor Azure Functions nebo Logic Apps, můžete výpočet spustit pravidelně z existujících nasazení.
  • Pokud jsou prostředky aplikace distribuovány napříč několika skupinami prostředků, můžete použít značky ke korelaci nákladových dat a výpočtu množství uhlíku generované aplikací.

Podrobnosti scénáře

Tato architektura je navržená tak, aby shromáždila data optimalizace uhlíku z Azure a dalších zdrojů, aby poskytovala komplexní pohled na dopad aplikace na životní prostředí. Data se shromažďují z optimalizace emisí uhlíku v Azure. V prostředích mimo Azure se k načtení relevantních metrik uhlíku používá proxy server. Po konsolidaci dat se pro posouzení celkové uhlíkové stopy provádějí výpočty SCI. Výsledky se pak uloží do účtu služby Azure Storage nebo datového jezera pro dlouhodobé uchovávání, což umožňuje analýzu BI a historické vytváření sestav. Tento přístup zajišťuje centralizované sledování dopadu uhlíku napříč různorodou infrastrukturou a podporuje strategické úsilí o udržitelnost.

Informace o emisích uhlíku se částečně shromáždí z okna optimalizace emisí uhlíku na webu Azure Portal a pokud je to možné, prostřednictvím proxy serveru.

Snímek obrazovky s oknem Optimalizace emisí uhlíku

Je nezbytné použít samostatnou architekturu ke shromažďování dat optimalizace emisí uhlíku v Azure ze dvou klíčových důvodů:

  • Data optimalizace emisí uhlíku v Azure se ukládají a zobrazují pouze za posledních dvanáct měsíců (v postupném okně). Pokud je vyžadováno dlouhodobé sledování uhlíkové stopy, vyhrazený systém zajišťuje uchovávání podrobných historických informací.
  • Aplikace může zahrnovat více infrastruktur s Azure pouze jednou komponentou. Samostatná architektura umožňuje centralizované monitorování dopadu emisí uhlíku ve všech prostředích, aby poskytovalo ucelený pohled a zajistilo komplexnější přehled o udržitelnosti.

Poznámka:

Skleníkových plynů nejsou tvořeny pouze oxidem uhličitém a nemají stejný dopad na životní prostředí. Například jedna tuna metanu má stejný topný účinek jako 80 tun oxidu uhličitého. V tomto článku je vše normalizováno na ekvivalentní míru CO2. Všechny odkazy na uhlík odkazují na ekvivalent CO2.

Zdroje dat

Obecně byste měli vytvořit proxy rovnici s několika proměnnými. Zvolené proxy metriky by měly představovat chování a výkon aplikace.

V tomto příkladu se používají tyto metriky:

  • Emise uhlíku infrastruktury, která se načítá z rozhraní API pro emise uhlíku. Toto rozhraní API je zdrojem pro Řídicí panel dopadu emisí i okno Optimalizace emisí uhlíku na webu Azure Portal. Data jsou k dispozici na úrovni skupiny prostředků, což usnadňuje sledování emisí vaší aplikace.
  • Metriky výkonu a škálování aplikace shromážděné z Application Insights:
    • Faktor škálování (volání rozhraní API, požadavky serveru nebo jiná metrika) pro aplikaci
    • Využití procesoru
    • Využití paměti
    • Doba odezvy (odesílání a příjem)

Kurz nastavení Application Insights pro získání požadovaných metrik najdete v tématu Application Insights pro aplikace ASP.NET Core.

Do rovnice můžete přidat další proměnné, například:

  • Hraniční služby a emise uhlíku infrastruktury.
  • Doba, kdy se uživatelé připojují, protože výroba elektřiny a poptávka se v čase liší.
  • Jakákoli jiná metrika aplikace, která vám může sdělit, jak se její výkon v průběhu času mění.

Vytvořením této rovnice do skóre, které může odrážet také počet uživatelů, vytvoříte nejbližší aproximaci skóre uhlíku. Toto skóre je vaším srovnávacím testem pro jakoukoli další změnu a vylepšení směrem k udržitelnosti aplikace.

Další aspekty související s výkonem aplikace jsou náklady. Ve většině případů je možné stanovit přímou korelaci mezi efektivitou výkonu a náklady a úsporou uhlíku. Tato korelace vede k následujícím předpokladům:

  • Pokud je výkon vyšší, ale náklady jsou stejné, optimalizovali jste aplikaci a snížili emise uhlíku.
  • Pokud jsou náklady nižší, ale výkon je stejný, optimalizovali jste aplikaci a snížili emise uhlíku.
  • Když se zvýší výkon i náklady, neoptimalizovali jste aplikaci a zvýšili jste emise uhlíku.
  • Pokud se náklady zvětší, ale výkon se sníží nebo stejný, neoptimalizovali jste aplikaci a máte vyšší emise uhlíku (nebo vyšší náklady na energii, což je také příčinou vyšších emisí uhlíku).

Tato korelace mezi skóre SCI, náklady a výkonem aplikace je jedinečná pro každou aplikaci a závisí na mnoha faktorech. Když shromáždíte data pro tyto tři proměnné, můžete vytvořit algoritmus korelace, který vám umožní předpovědět jakoukoli variantu těchto tří proměnných a činit informovaná rozhodnutí o architektuře a vzorech aplikace.

Výpočty

V tomto scénáři není možné vytvořit samostatný výpočet pro proxy servery, které se používají. Místo toho se data shromážděná z Řídicí panel dopadu emisí zpracovávají jako výchozí bod. Tady je výpočet směrného plánu SCI:

SCI = C*R

V této rovnici:

  • C je emise uhlíku pro aplikaci. Tato hodnota je ovlivněna tím, jak je aplikace nasazena v Azure. Pokud jsou například všechny prostředky aplikace v jedné skupině prostředků, C jedná se o emise uhlíku pro tuto skupinu prostředků.

    Poznámka:

    Prozatím se ostatní zdroje emisí pro aplikaci ignorují, protože závisí na architektuře a chování hraničních zařízení a uživatelů. Pokud pro data používáte proxy servery, můžete tyto zdroje zvážit v dalším kroku.

  • R je faktor škálování aplikace. Může to být počet průměrných souběžných uživatelů pro časové období, požadavky rozhraní API, webové požadavky nebo jinou metriku. Tato hodnota je důležitá, protože vede k skóre, které odpovídá celkovému dopadu využití aplikace, nejen na její nároky na nasazení.

Časový interval je samozřejmě dalším důležitým aspektem tohoto výpočtu: emise uhlíku pro jakékoli energeticky náročné zařízení nebo systém se v průběhu času liší, protože energetická síť může mít někdy obnovitelné nebo alternativní zdroje energie (například solární energii), ale ne v jiných. Proto je důležité začít s nejkratším možným časovým rámcem pro zvýšení přesnosti. Můžete například začít denním nebo hodinovým výpočtem.

Rozhraní API pro emise uhlíku v současné době poskytuje měsíční informace o emisích uhlíku na základě služeb v rámci předplatného na úrovni skupiny prostředků. Pomocí poskytnutého rozhraní REST API můžete exportovat data o emisích do datového jezera, ve které jsou všechna data udržitelnosti pro danou aplikaci.

Úložiště dat

Informace o emisích uhlíku a uhlíku byste měli uložit v řešení, které můžete připojit k řídicím panelům nebo sestavám. Díky tomu můžete vizualizovat skóre emisí uhlíku v průběhu času a provádět informované volby. Pokud chcete zlepšit udržitelnost a v souladu s osvědčenými postupy architektury Azure Well-Architected Framework, doporučujeme používat minimální realizovatelný systém. (Další informace najdete v tématu Aspekty návrhu dat a úložiště pro udržitelné úlohy v Azure a aplikační platformě pro udržitelné úlohy v Azure.) Azure Data Lake Storage se používá v této architektuře.

Korelace dat

Když začnete shromažďovat data o emisích uhlíku, výkonu a nákladech vaší aplikace, získáte cenné informace, které vám umožní vytvořit korelační algoritmus, který je specifický pro vaši aplikaci a který vám poskytne pokyny při plánování nákladů, výkonu a optimalizace emisí uhlíku.

Další informace najdete v tématu Jak vybrat algoritmy pro Azure Machine Learning.

Zobrazení dat

Data a výpočty můžete zobrazit různými způsoby, včetně přizpůsobených řídicích panelů Azure Monitoru a jednoduchých řídicích panelů Power BI.

Co může trigger skóre SCI aktivovat?

Jakmile znáte své skóre udržitelnosti, může vás zajímat, jak ho můžete vylepšit.

Pokud můžete určit dopad aplikace na uhlík pomocí proxy serverů, dalším krokem je zaměřit se na definování akcí, které můžou být aktivovány nežádoucími podmínkami ve skóre. Mezi příklady těchto podmínek patří:

  • Výroba energie a poptávka je vždy vysoká a proto je nákladná pro výrobu.
  • Elektřina není dostupná. Tento stav může být způsoben přírodní katastrofou nebo geopolitickým konfliktem.
  • Náhlá nedostupnost hraniční infrastruktury způsobená problémy s nadměrnou spotřebou prostředků nebo dodavatelským řetězcem

Když můžete identifikovat body selhání, které můžou ovlivnit vaši aplikaci, můžete rozhodnout, jaké akce se mají provést, aby byla aplikace odolná vůči špičce uhlíku.

Můžete provést jednu z následujících akcí:

  • Využijte elegantní snížení výkonu služeb a funkcí aplikace, jak je popsáno v dokumentaci k rozhraní Well-Arcchitected Framework.

  • Vytvořte ekologii verzi aplikace. Ekologický režim je jednodušší, menší, levnější a trvalejší verze aplikace, která nabízí minimální funkce. K této verzi se můžete vrátit během špiček emisí uhlíku. Můžete také jednoduše vytrénovat koncové uživatele tak, aby používali eko verzi podle volby. Můžete poskytnout "zelené tlačítko", které lidem umožňuje používat štíhlé rozhraní, méně grafiky a omezené funkce výměny za snížení emisí uhlíku.

  • Pokud se rozhodnete zapojit uživatele, vytvoříte příležitost řídit kulturní změnu spolu s technickou změnou: - Můžete určit dopad volby: "Pomocí ekologické verze ušetříte x množství uhlíku" nebo "přinesete naše skóre emisí uhlíku na y". - Můžete získat představu o chování uživatelů a upravit ekologickou verzi tak, aby odrážela jejich volby. (Možná používají 10 % funkcí a jsou ideálním uživatelem ekologické verze.) - Vzhledem k tomu, že plná verze je optimalizovaná pro emise, můžete v ideálním případě sloučit dvě verze.

Důležité informace

Tyto aspekty implementují pilíře dobře architektuře Azure, což je sada hlavních principů, které je možné použít ke zlepšení kvality úlohy. Další informace naleznete v tématu Microsoft Azure Well-Architected Framework.

Zabezpečení

Zabezpečení poskytuje záruky proti záměrným útokům a zneužití cenných dat a systémů. Další informace najdete v tématu Přehled pilíře zabezpečení.

Kvůli dalšímu zabezpečení můžete pomocí koncových bodů služby Azure Virtual Network odebrat veřejný internetový přístup k prostředkům služby Azure a povolit provoz jenom z vaší virtuální sítě.

Pomocí tohoto přístupu vytvoříte virtuální síť v Azure a pak vytvoříte koncové body privátní služby pro služby Azure. Tyto služby jsou pak omezeny na provoz z této virtuální sítě. Můžete k nim také přistupovat z místní sítě přes bránu.

Mějte na paměti, že pokud chcete přesunout data z místního prostředí do Azure Storage, musíte povolit veřejné IP adresy z místního prostředí nebo z Azure ExpressRoute. Podrobnosti najdete v tématu Nasazení vyhrazených služeb Azure do virtuálních sítí.

Obecné pokyny k návrhu zabezpečených řešení najdete v dokumentaci k zabezpečení Azure.

Optimalizace nákladů

Optimalizace nákladů se týká snížení zbytečných výdajů a zlepšení efektivity provozu. Další informace najdete v tématu Přehled pilíře Optimalizace nákladů.

Tuto architekturu můžete nasadit pomocí několika alternativních služeb Azure. Záměrně se zachovala minimálně, aby se ušetřily náklady a emise uhlíku.

Doporučujeme vám používat ekvivalentní služby, které už máte v nasazení aplikace, ale informace o cenách jsou k dispozici pro každou komponentu architektury:

Efektivita výkonu

Efektivita výkonu je schopnost vaší úlohy škálovat tak, aby splňovala požadavky, které na ni mají uživatelé efektivním způsobem. Další informace najdete v tématu Přehled pilíře efektivity výkonu.

Hlavním účelem této architektury je poskytnout skóre udržitelnosti pro vaše aplikace prostřednictvím procesu, který má minimální dopad na náklady a uhlík. Většina komponent je platforma jako služba (PaaS) a bezserverové služby Azure, které se můžou škálovat nezávisle na základě použití a provozu.

V tomto scénáři není řídicí panel a rozhraní úložiště určené pro masivní využití a konzultace. Pokud ho plánujete poskytnout velkému počtu uživatelů, můžete zvážit jednu z těchto možností:

  • Extrahovaná data oddělte jejich transformací a uložením do jiného systému.
  • Nahraďte Službu Data Lake Storage nebo Azure Table Storage škálovatelnou alternativou datové struktury, jako je Azure Cosmos DB.

Přispěvatelé

Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.

Hlavní autoři:

  • Paola Annis | Hlavní manažer pro technické pracovníky na úrovni zákaznického prostředí
  • Davide Bedin | Vedoucí architekt cloudových řešení, inovace aplikací

Další přispěvatel:

Pokud chcete zobrazit neveřejné profily LinkedIn, přihlaste se na LinkedIn.

Další kroky

Tento článek je v souladu s principy a metodologií zeleného softwarového základu. Dalším krokem při vytváření zelenější aplikace je vložení sady Carbon Aware SDK do vaší aplikace, aby triggery bylo možné automatizovat v reálném čase, když jsou splněny konkrétní podmínky emisí uhlíku.

Doporučení k optimalizaci úloh Azure najdete v doprovodných materiálech k cloudovým úlohám Sustainability.