Misurare la sostenibilità delle app di Azure usando il punteggio SCI

La soluzione descritta in questo articolo consente di creare un modello di sostenibilità per le applicazioni ospitate in Azure. Il modello usa proxy che, nel tempo, consentono di assegnare punteggi all'impatto e all'efficienza di un'applicazione. Il punteggio è noto come punteggio sci (Software Carbon Intensity). Fornisce una linea di base per misurare le modifiche nell'output di carbonio di un'applicazione.

Architettura

Scaricare un file di Visio di questa architettura.

Flusso di dati

1. Configurare le origini dati dell'applicazione che verranno usate per calcolare il punteggio SCI. I dati possono essere le misurazioni delle emissioni fornite dal pannello Ottimizzazione carbonio nel portale di Azure oppure possono essere misurazioni proxy da origini o sistemi non Microsoft.
2. Esportare i dati sulle emissioni di carbonio nel data lake.
3. Usare gestori eventi come Funzioni di Azure o App per la logica di Azure per calcolare il punteggio SCI. L'output è la quantità di carbonio emessa in grammi per unità, dove unità fa riferimento al fattore di ridimensionamento dell'applicazione o un'approssimazione di essa basata su proxy.
4. Usare tecnologie come Funzioni di Azure, App per la logica o Automazione di Azure runbook per attivare il data shaping della domanda sull'applicazione o per avviare la modalità eco predefinita dell'applicazione.
5. Usare Power BI per creare report e visualizzare il punteggio e la relativa variazione nel tempo.

Componenti

• Il pannello Ottimizzazione carbonio nel portale di Azure fornisce misurazioni delle emissioni di carbonio dei carichi di lavoro di Azure a livello di gruppo di risorse.
• L'API Cloud for Sustainability fornisce i dati sottostanti per l'ottimizzazione del carbonio. È possibile usarlo per recuperare informazioni sulle emissioni della sottoscrizione.
• Application Insights è una funzionalità di Monitoraggio di Azure che fornisce la gestione delle prestazioni delle applicazioni (APM). Può essere utile per ottenere informazioni approfondite sul modo in cui gli utenti usano l'app. È possibile usare queste informazioni per prendere decisioni basate sui dati per migliorare l'efficienza dell'applicazione.
• Archiviazione BLOB di Azure archivia le informazioni sulle emissioni dall'ottimizzazione del carbonio di Azure, dai calcoli personalizzati o da altri proxy per le emissioni.
• Azure Data Lake è un repository centralizzato che inserisce e archivia grandi volumi di dati nel formato originale. I dati possono quindi essere elaborati e usati come base per diverse esigenze di analisi.
• App per la logica di Azure consente di creare ed eseguire flussi di lavoro automatizzati con poco o nessun codice. Usando la finestra di progettazione visiva e selezionando le operazioni predefinite, è possibile creare rapidamente un flusso di lavoro che si integra e gestisce le origini proxy, l'archiviazione dei dati e i sistemi di calcolo dell'efficienza.
• Funzioni di Azure consente di eseguire piccole unità di codice. Ridimensiona automaticamente le risorse in base alla richiesta e si paga solo per il tempo di esecuzione effettivo. È possibile usarlo per eseguire calcoli di sostenibilità e archiviarli nell'archiviazione BLOB o in un data lake.
• Automazione di Azure fornisce l'automazione dei processi tramite runbook. È possibile usare i runbook per implementare logica complessa, usando il codice di PowerShell, che può influenzare l'applicazione per migliorare l'efficienza. Questo servizio può anche aggiungere valore aziendale riducendo gli errori e i costi operativi.
• Power BI consente di trasformare i dati in analisi e report che forniscono informazioni dettagliate in tempo reale.

Alternative

I servizi di Azure descritti in questo articolo possono essere sostituiti con servizi simili. Per aumentare la densità e l'utilizzo delle risorse esistenti, eseguire i calcoli con l'impatto minimo sull'infrastruttura usando i servizi o gli strumenti di Azure già distribuiti nell'ambiente:

• È possibile sostituire i dashboard di Power BI con le cartelle di lavoro di Monitoraggio di Azure o i servizi Grafana gestiti di Azure.
• È possibile sostituire Application Insights con qualsiasi altro strumento di gestione delle prestazioni delle applicazioni (APM), ad esempio Elasticsearch Application Performance Management (APM) o OpenAPM.
• I dati sotto forma di tabelle o dati non strutturati possono essere conservati in qualsiasi sistema di record, ad esempio MySQL o MariaDB o Azure Cosmos DB e MongoDB.
• Se si dispone di uno spazio di Funzioni di Azure o app per la logica in esecuzione, è possibile eseguire il calcolo a intervalli regolari dalle distribuzioni esistenti.
• Se le risorse dell'applicazione vengono distribuite tra più gruppi di risorse, è possibile usare i tag per correlare i dati sui costi e calcolare la quantità di carbonio generata dall'applicazione.

Dettagli dello scenario

Questa architettura è progettata per raccogliere dati di ottimizzazione del carbonio da Azure e altre origini per offrire una panoramica completa dell'impatto ambientale di un'applicazione. I dati vengono raccolti dall'ottimizzazione del carbonio di Azure. Per gli ambienti non Azure, viene usato un proxy per recuperare le metriche di carbonio pertinenti. Dopo aver consolidato i dati, i calcoli SCI vengono eseguiti per valutare l'impronta complessiva del carbonio. I risultati vengono quindi archiviati in un account Archiviazione di Azure o in un data lake per la conservazione a lungo termine, che consente l'analisi bi e la creazione di report cronologici. Questo approccio garantisce un monitoraggio centralizzato dell'impatto sul carbonio in infrastrutture diverse e supporta gli sforzi strategici per la sostenibilità.

Le informazioni sulle emissioni di carbonio vengono raccolte parzialmente dal pannello portale di Azure Ottimizzazione carbonio e parzialmente calcolate, quando possibile, tramite proxy.

È essenziale usare un'architettura separata per raccogliere i dati di ottimizzazione delle emissioni di carbonio di Azure per due motivi chiave:

• I dati di ottimizzazione delle emissioni di carbonio di Azure vengono archiviati e visualizzati solo per gli ultimi dodici mesi (in una finestra mobile). Quando è necessario il rilevamento a lungo termine di un'impronta di carbonio, un sistema dedicato garantisce la conservazione di informazioni cronologiche dettagliate.
• Un'applicazione può estendersi su più infrastrutture, con Azure come un solo componente. Un'architettura separata consente il monitoraggio centralizzato dell'impatto sul carbonio in tutti gli ambienti per fornire una visione olistica e garantire informazioni più complete sulla sostenibilità.

Origini dati

In generale, è consigliabile creare un'equazione proxy con poche variabili. Le metriche proxy scelte devono rappresentare il comportamento e le prestazioni dell'applicazione.

Queste metriche vengono usate in questo esempio:

• L'emissione di carbonio dell'infrastruttura, recuperata dall'API delle emissioni di carbonio. Questa API è l'origine sia per il dashboard impatto sulle emissioni che per il pannello Ottimizzazione carbonio nel portale di Azure. I dati sono disponibili a livello di gruppo di risorse, che semplificano la registrazione delle emissioni dell'applicazione.
• Metriche di prestazioni e scalabilità dell'applicazione, raccolte da Application Insights:
  • Fattore di ridimensionamento (chiamate API, richieste server o altre metriche) per l'applicazione
  • Utilizzo CPU
  • Utilizzo memoria
  • Tempo di risposta (invio e ricezione)

Per un'esercitazione su come configurare Application Insights per ottenere le metriche necessarie, vedere Application Insights per le applicazioni principali ASP.NET.

È possibile aggiungere altre variabili all'equazione, ad esempio:

• Servizi perimetrali e emissioni di carbonio dell'infrastruttura.
• Il momento in cui gli utenti si connettono, in quanto la produzione di energia elettrica e la domanda variano in base al tempo.
• Qualsiasi altra metrica dell'app che può indicare il modo in cui le prestazioni cambiano nel tempo.

Creando questa equazione in un punteggio che può anche riflettere il numero di utenti, si crea l'approssimazione più vicina a un punteggio di carbonio. Questo punteggio è il benchmark per qualsiasi ulteriore modifica e miglioramento verso la sostenibilità dell'app.

Il costo è un'altra considerazione associata alle prestazioni dell'applicazione. Nella maggior parte dei casi, è possibile stabilire una correlazione diretta tra efficienza delle prestazioni e risparmio di costo e carbonio. Questa correlazione porta ai presupposti seguenti:

• Quando le prestazioni sono superiori, ma i costi sono gli stessi, l'app è stata ottimizzata e le emissioni di carbonio sono ridotte.
• Quando i costi sono ridotti, ma le prestazioni sono le stesse, l'app è stata ottimizzata e le emissioni di carbonio ridotte.
• Quando le prestazioni e i costi aumentano, non hai ottimizzato l'app e hai aumentato le emissioni di carbonio.
• Quando i costi aumentano, ma le prestazioni sono ridotte o uguali, non hai ottimizzato l'app e hanno aumentato le emissioni di carbonio (o il costo energetico è superiore, che è anche una causa di emissioni di carbonio più elevate).

Questa correlazione tra il punteggio SCI, il costo e le prestazioni di un'applicazione è univoco per ogni applicazione e dipende da molti fattori. Raccogliendo dati per queste tre variabili, è possibile creare un algoritmo di correlazione che consente di prevedere qualsiasi variazione dei tre e di prendere decisioni informate sull'architettura e sui modelli dell'applicazione.

Calcoli

Nello scenario descritto qui non è possibile formare un calcolo discreto per i proxy usati. I dati raccolti dal dashboard impatto sulle emissioni vengono invece elaborati come punto di partenza. Ecco il calcolo della baseline SCI:

SCI = C*R

In questa equazione:

• C sono le emissioni di carbonio per l'applicazione. Questo valore è influenzato dal modo in cui l'applicazione viene distribuita in Azure. Ad esempio, se tutte le risorse dell'applicazione si trovano in un singolo gruppo di risorse, C corrisponde alle emissioni di carbonio per tale gruppo di risorse.

  Nota

  Per il momento, altre fonti di emissioni per l'applicazione vengono ignorate perché dipendono dall'architettura e dal comportamento edge/utente. Se si usano proxy per i dati, è possibile prendere in considerazione queste origini nel passaggio successivo.

• R è il fattore di ridimensionamento per l'applicazione. Può trattarsi del numero di utenti simultanei medi per l'intervallo di tempo, le richieste API, le richieste Web o altre metriche. Questo valore è importante perché porta a un punteggio che rappresenta l'impatto complessivo dell'utilizzo dell'applicazione, non solo del footprint di distribuzione.

L'intervallo di tempo è, naturalmente, un altro aspetto importante di questo calcolo: le emissioni di carbonio per qualsiasi dispositivo o sistema che consumano energia variano nel tempo, perché la rete energetica potrebbe avere fonti di energia rinnovabili o alternative (ad esempio, energia solare) in qualche momento, ma non in altri. È quindi importante iniziare con l'intervallo di tempo più breve possibile per aumentare la precisione. Ad esempio, è possibile iniziare con un calcolo giornaliero o orario.

L'API per le emissioni di carbonio fornisce attualmente informazioni mensili sul carbonio in base ai servizi all'interno di una sottoscrizione, a livello di gruppo di risorse. Usando l'API REST fornita, è possibile esportare i dati sulle emissioni in un data lake che contiene tutti i dati di sostenibilità per l'applicazione.

Archiviazione di dati

È consigliabile archiviare le informazioni sul proxy di carbonio e carbonio raccolte in una soluzione che è possibile connettere ai dashboard o ai report. In questo modo è possibile visualizzare il punteggio di carbonio nel tempo e fare scelte informate. Per migliorare la sostenibilità e allinearsi alle procedure consigliate di Azure Well-Architected Framework, è consigliabile usare il sistema minimo funzionante. Per altre informazioni, vedere Considerazioni sulla progettazione dei dati e dell'archiviazione per carichi di lavoro sostenibili in Azure e sulla piattaforma delle applicazioni per carichi di lavoro sostenibili in Azure. Azure Data Lake Storage viene usato in questa architettura.

Correlazioni dei dati

Quando si inizia a raccogliere dati sul carbonio, sulle prestazioni e sui costi dell'applicazione, si avranno informazioni preziose che consentono di creare un algoritmo di correlazione specifico per l'applicazione e che fornirà indicazioni quando si pianificano costi, prestazioni e ottimizzazione del carbonio.

Per altre informazioni, vedere Come selezionare gli algoritmi per Azure Machine Learning.

Visualizzazione dati

È possibile visualizzare i dati e i calcoli in vari modi, inclusi dashboard personalizzati di Monitoraggio di Azure e dashboard di Power BI semplici.

Cosa può attivare il punteggio SCI?

Dopo aver conosciuto il punteggio di sostenibilità, ci si potrebbe chiedere come migliorarlo.

Se è possibile assegnare un punteggio all'impatto di carbonio dell'applicazione usando proxy, il passaggio successivo consiste nel definire azioni che possono essere attivate da condizioni sfavorevoli nel punteggio. Di seguito sono riportati alcuni esempi di queste condizioni:

• La produzione e la domanda di energia sono sempre elevate ed è quindi costoso da produrre.
• L'elettricità non è disponibile. Questa condizione potrebbe essere causata da una calamità naturale o da un conflitto geopolitico.
• Improvvisa indisponibilità dell'infrastruttura perimetrale causata da problemi di consumo eccessivo delle risorse o della supply chain.

Quando è possibile identificare i punti di errore che possono influire sull'applicazione, è possibile decidere quali azioni eseguire per rendere l'applicazione resiliente ai picchi di carbonio.

È possibile eseguire una delle azioni seguenti:

• Applicare una riduzione normale dei servizi e delle funzionalità dell'app, come descritto nella documentazione di Well-Arcchitected Framework.

• Creare una versione in modalità eco dell'applicazione. La modalità Eco è una versione più semplice, più piccola, più economica e sostenibile dell'applicazione che offre funzionalità minime. È possibile ripristinare questa versione durante i picchi di emissioni di carbonio. È anche possibile formare semplicemente gli utenti finali per usare una versione eco a scelta. È possibile fornire un "pulsante verde" che consente alle persone di usare un'interfaccia più snella, meno grafica e funzionalità limitate in cambio di emissioni di carbonio ridotte.

• Se si sceglie di coinvolgere gli utenti, si crea un'opportunità per guidare un cambiamento culturale insieme a quello tecnico: - È possibile specificare l'impatto della scelta: "Utilizzando la versione eco, si risparmia x quantità di carbonio" o "portando il punteggio di carbonio a y quantità". - È possibile ottenere una comprensione del comportamento dell'utente e modificare la versione eco per riflettere le loro scelte. (Forse usano il 10% delle funzionalità e sono un utente ideale della versione eco. - Poiché la versione completa è ottimizzata per l'emissione, è possibile unire idealmente le due versioni.

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Microsoft Azure Well-Architected Framework.

Sicurezza

La sicurezza offre garanzie contro attacchi intenzionali e l'abuso di dati e sistemi preziosi. Per altre informazioni, vedere Panoramica del pilastro della sicurezza.

Per una maggiore sicurezza, è possibile usare gli endpoint di servizio di Azure Rete virtuale per rimuovere l'accesso a Internet pubblico alle risorse del servizio di Azure, consentendo il traffico solo dalla rete virtuale.

Con questo approccio, si crea una rete virtuale in Azure e quindi si creano endpoint di servizio privati per i servizi di Azure. Questi servizi vengono quindi limitati al traffico proveniente da tale rete virtuale. È anche possibile raggiungerli dalla rete locale tramite un gateway.

Tenere presente che, per spostare i dati dall'ambiente locale a Archiviazione di Azure, è necessario consentire indirizzi IP pubblici dall'ambiente locale o da Azure ExpressRoute. Per informazioni dettagliate, vedere Distribuire servizi di Azure dedicati in reti virtuali.

Per indicazioni generali sulla progettazione di soluzioni sicure, vedere la documentazione sulla sicurezza di Azure.

Ottimizzazione dei costi

L'ottimizzazione dei costi riguarda la riduzione delle spese non necessarie e il miglioramento dell'efficienza operativa. Per maggiori informazioni, consultare la sezione Panoramica del pilastro di ottimizzazione dei costi.

È possibile distribuire questa architettura usando diversi servizi di Azure alternativi. È stato intenzionalmente mantenuto almeno per risparmiare sui costi e sulle emissioni di carbonio.

Sebbene sia consigliabile usare servizi equivalenti già presenti nella distribuzione dell'applicazione, le informazioni sui prezzi sono disponibili per ogni componente dell'architettura:

• Il dashboard impatto sulle emissioni, l'ottimizzazione del carbonio di Azure e i report di Gestione costi Microsoft sono gratuiti.

• Prezzi di Application Insights.

• Prezzi di Archiviazione tabelle di Azure.

• Prezzi di App per la logica di Azure.

• Funzioni di Azure prezzi.

• Automazione di Azure prezzi.

Efficienza delle prestazioni

L'efficienza delle prestazioni è la capacità di dimensionare il carico di lavoro per soddisfare in modo efficiente le richieste poste dagli utenti. Per altre informazioni, vedere Panoramica del pilastro dell'efficienza delle prestazioni.

Lo scopo principale di questa architettura è fornire un punteggio di sostenibilità per le applicazioni tramite un processo che ha un impatto minimo sui costi e sul carbonio. La maggior parte dei componenti sono paaS (Platform as a Service) e servizi di Azure serverless che possono essere ridimensionati in modo indipendente in base all'uso e al traffico.

In questo scenario, il dashboard e l'interfaccia di archiviazione non sono destinati a un utilizzo e una consultazione massicce. Se si prevede di fornirlo a un numero elevato di utenti, è consigliabile prendere in considerazione una di queste opzioni:

• Separare i dati estratti trasformandoli e archiviandoli in un sistema diverso.
• Sostituire Data Lake Storage o Archiviazione tabelle di Azure con un'alternativa alla struttura dei dati più scalabile, ad esempio Azure Cosmos DB.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autori principali:

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

Altro collaboratore:

• Chad Kittel | Principal Software Engineer

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

Questo articolo è allineato ai principi e alla metodologia di Green Software Foundation. Il passaggio successivo nella creazione di un'applicazione più verde consiste nell'incorporare Carbon Aware SDK nell'applicazione in modo che i trigger possano essere automatizzati in tempo reale quando vengono soddisfatte specifiche condizioni di carbonio.

Per consigli su come ottimizzare i carichi di lavoro di Azure, vedere Linee guida per il carico di lavoro cloud per la sostenibilità.

Risorse correlate

• Scegliere una tecnologia per l'analisi dei dati e la creazione di report in Azure
• Aree di lavoro di analisi dei dati per settori regolamentati