Green IT: il senso della misura

Introduzione

Il concetto di Green IT è riferito ad un IT che sia ecologicamente sostenibile, esattamente come avviene per altri settori nei quali è fondamentale l’ottimizzazione dell’efficienza energetica al fine di contenerne i costi.

I primi approcci si hanno intorno al 2006 ma fino a pochi anni fa l’industria IT si è concentrata sulla produzione di computer sempre più energeticamente efficienti; solo recentemente si è iniziato a considerare che anche la progettazione del software e la sua realizzazione, seguendo specifiche best practice, concorrono significativamente al rispetto della sostenibilità ambientale ed etica, senza andare a discapito dei margini economici e di prestazione.

La ricerca sulle relazioni tra software e sostenibilità ambientale sta lentamente maturando in due aree di interesse, legate al software sostenibile e al software per la sostenibilità.

Il concetto di software sostenibile è quello di più immediata comprensione: non molti sforzi di ricerca sono stati fatti al fine di individuare le best practice necessarie a progettare un software che incrementasse la propria efficienza energetica. Ancor meno sforzi sono stati fatti nell’individuare software per la sostenibilità: questi software hanno un impatto potenziale nel mondo dell’IT attuale ancora più ampio dei precedenti, in quanto possono indirizzare la progettazione del software, o il refactoring di software esistente, verso il concetto di software sostenibile.

Il combinato disposto dei due concetti, applicati ad una software factory, consente alle organizzazioni di avere un IT che contribuisce in maniera attiva agli obiettivi di sostenibilità ambientale e sociale oltre che, naturalmente, economiche.

Al fine di indirizzare correttamente un IT sostenibile, sia il mondo della ricerca, sia quello industriale, suggeriscono l’utilizzo di un Sustainability-Quality Assessment Framework (di seguito SAF)[1] che consiste di strumenti: un modello qualità-sostenibilità del software e una mappa decisionale per la definizione delle architetture.

L’adozione di un framework SAF consente alle organizzazioni di creare una vera e propria forma mentis di approccio sostenibile: una sorta di sustainability by design / sustainability by default analogamente a quanto accade per altri requisiti software non funzionali quali, ad esempio, privacy e sicurezza.

Affronteremo nei prossimi paragrafi sia il modello qualità-sostenibilità proposto da CAST, sia un’ipotesi general purpose di mappa decisionale, che dovrà essere personalizzata dalle singole organizzazioni che vorranno adottare questo approccio, supportati dai consulenti della divisione CAST Advisory.

 [1] P. Lago, R. Verdecchia, N. Condori-Fernandez, E. Rahmadian, J. Sturm, T. van Nijnanten, R. Bosma, C. Debuysscher, P. Ricardo - Designing for Sustainability: Lessons Learned from Four Industrial Projects (https://www.researchgate.net/publication/347660122_Designing_for_Sustainability_Lessons_Learned_from_Four_Industrial_Projects)

Il modello qualitativo e il Green IT Index

Come noto, CAST rileva le violazioni del codice analizzato sia delle weakness architetturali e di codifica incluse nelle CISQ Structural Quality Measure, oltre a quelle considerate dalla ISO/IEC 5055:2021, correlati a degli aspetti di sicurezza e di qualità del software, mappabili, sul modello delle medesime caratteristiche proposto dalla ISO/IEC 25010:2011 che riportiamo in Figura 1.

Figura 1 - Modello di qualità proposto dalla ISO/IEC 25010:2011

La famiglia ISO 25000 solo recentemente ha espresso un modello di indicatori implementabile per la misura delle caratteristiche di qualità del software, con particolare riferimento alla norma ISO/IEC 25023:2016, le cui relazioni con la ISO/IEC 25010:2011 sono schematizzate in Figura 3.

Al fine di rendere effettive delle modalità di misura, ISO, di concerto con il CISQ, ha emanato la norma la ISO/IEC 5055:2021 che definisce, appunto, detto modello.

La relazione tra la ISO/IEC 5055:2021 e la famiglia ISO 25000 è schematizzata in Figura 2.

Figura 2 - Relazione tra modello di qualità e modello di misura nella famiglia ISO 25000 e modello di misura ISO/IEC 5055:2021

La ISO/IEC 5055: 2021 è l’anello di congiunzione tra il mondo ISO e il modello CISQ implementato anch’esso, come quello ISO 5005 nella suite CAST. Il modello CISQ, si differenzia per avere quattro indicatori che, de facto, misurano altrettanti aspetti qualitativi del software.

Se, però il mondo ISO, nella ISO/IEC 25023:2016 definisce solo le metriche, il modello CISQ definisce anche come un software per la sostenibilità possa misurare gli indicatori proposti schematizzati in Figura 3, facilmente riconducibili a quelli proposti dalla famiglia ISO 25000.

Figura 3 - CISQ Quality Characteristic Measures

In Figura 4 si vede come le singole metriche rilevate tramite specifici code-checks concorrono, tramite appositi algoritmi, al calcolo degli Health Factor.

L’unicità della suite CAST consta nella sua capacità di rilevare degli architectural code checks che evidenziano violazioni a dei pattern di tipo architetturale e non solo di codifica. Questa capacità, unica nel panorama degli strumenti software eleggibili a software per la sostenibilità, è assolutamente necessaria per rilevare i criteri definiti per il calcolo del Green IT Index.

Figura 4 - Relazione tra architectural code check e indicatori

I quattro CAST Health Factor, e i relativi criteri di analisi, che intervengono nel calcolo del Green IT Index, un indicatore reso disponibile dalla suite CAST, in ossequio alle Linee guida per lo sviluppo di software sostenibile del CISQ, nel documento sono evidenziati di seguito:

• Efficiency – capacità del software in esercizio di ottimizzare le risorse, incluse quelle energetiche;
• Complexity – semplificazione del software al fine di richiedere meno risorse e meno supporto;
• Best Programming Practice: rispetto da parte del software delle practice di programmazioni indicate;
• Security: evitare che il software venga utilizzato per scopi diversi da quelli per il quale è stato progettato.

In particolare, il Green IT Index è basato su 5 criteri legati all’Health Factor Efficiency e 3 criteri legati all’Health Factor Robustness, che elenchiamo di seguito:

• Efficiency
  • Efficiency – Expensive Calls in Loops
  • Efficiency – Memory, Network and Disk Space Management
  • Efficiency – SQL and Data Handling Performance
  • Complexity – Dynamic Instantiation
  • Complexity – SQL Queries
• Robustness
  • Programming Practices – Error and Exception Handling
  • Programming Practices – Unexpected Behavior
  • Secure Coding – Time and State

Scendendo ad un maggiore livello di dettaglio, andiamo ad elencare le misure individuate dal CISQ (https://www.it-cisq.org/wiki/cisq-automated-source-code-green-measure/) e che CAST utilizza nel calcolo del Green IT Index; dette misure elementari (cfr. Tabella 1) sono state tratte, come evidenziato in Figura 4, dalle seguenti categorie:

• ASCPEM - Automated Source Code Performance Efficiency Measure (http://www.omg.org/spec/ASCPEM)
• ASCRM - Automated Source Code Reliability Measure (http://www.omg.org/spec/ASCRM/)
• ASCSM - Automated Source Code Security Measure (http://www.omg.org/spec/ASCSM/)

Tabella 1 - Misure elementari che compongono il Green IT Index

Con l’introduzione del Green IT Index, CAST ha anticipato uno scenario futuro, seppur prossimo: queste misure, opportunamente integrate da altre, relative sia alle misure di efficienza (ASCPEM), sia da altri ASCxM, andranno a costituire una misura di sostenibilità specifica denominata Automated Source Code Resource Sustainability Measure (ASCRSM).

Appare palese che violazioni ai check code di Efficiency generano uno spreco di energia, potenzialmente dovuto ai cicli di CPU non necessari che creano un altrettanto non necessario consumo di kWh e conseguente emissione di CO_2.

Analogamente anche le violazioni ai check code di Complexity e Best Programming Practice generano delle inefficienze dal punto di vista del consumo di risorse, ivi incluse quelle energetiche: all’interno della piattaforma CAST è possibile individuare puntualmente dette violazioni, ivi incluse le singole linee di codice, sì da consentire una loro rapida ed efficace risoluzione.

Energy saving nello sviluppo del codice

Il fatto che del software di buona qualità ed efficienza complessiva consenta dei costi di gestione minori rispetto ad uno spaghetti-code è facilmente intuibile oltre che misurabile come visto nel paragrafo precedente.

Risulta molto più difficile quantificare l’effettivo risparmio energetico che deriva dall’adozione di specifiche programming practice per una serie di motivi: ad esempio, l’interazione tra il codice sviluppato e librerie o framework di terze parti rende più complessa e meno attendibile la misurazione.

In uno studio del 2009, ancora valido in seno alla comunità scientifica[2], la ripartizione dell’energia consumata in un datacenter è schematizzabile nella figura che segue:

Figura 5 - Ripartizione di come si consuma l'energia in un datacenter

All’interno di quel 56% all’interno dei server cerchiamo di comprendere, tramite delle misurazioni oggettive, quali costrutti sintattici, sia a livello di primitive, sia a livello di programming best practices, consentano un minor consumo di energia provando a dare una quantificazione di detto “risparmio”.

Gli esiti di una sperimentazione tra le più significative[3], condotta sulle primitive in linguaggio JAVA, ha indicato come, ad esempio, la definizione delle variabili utilizzate all’interno di un metodo JAVA, consumino un minore o maggiore quantitativo di Joule.

È stato rilevato che una instanced variable consuma il 60% in meno di energia di una static variable, così come il consumo di energia dipende dalla tipo dati della variabile: i tipi più semplici (byte, short, int, long) impiegano meno energia dei tipi più complessi (char, float, boolean, double), o dei loro wrapper.

La Figura 7, tratta dallo studio Energy Consumption in Java: An Early Experience3 riporta la misura del consumo di energia di un semplice metodo JAVA (cfr. Figura 6) al variare della tipologia della sua variabile

Figura 6 - JAVA code snippet usato per la misura

Figura 7 - Consumo in (J)oule dei vari tipi dati delle variabili in JAVA

Come si evince facilmente, anche il tempo di esecuzione del metodo coi tipi dati di minor consumo energetico è significativamente più basso, contribuendo alla necessità di un minor numero di cicli di CPU e quindi un ulteriore risparmio complessivo.

La Figura 8, invece, indica il differente consumo in Joule a fronte del fatto che la variabile sia dichiarata statica o sia istanziata con la classe di appartenenza, e sia di tipo int o integer a fronte dell’esecuzione del medesimo code snippet di Figura 6.

Figura 8 – Consumo di energia in Joule per variabili Instance e static (a) oltre che int e Integer (b)

Come si può notare il consumo di una instance variable è del 60% inferiore rispetto ad una static variable per un tempo più breve di oltre il 50%; altresì, l’uso corretto di un tipo int consente un risparmio ancora più grande rispetto all’utilizzo del suo wrapper Integer: questo comportamento resta valido, in maniera pressocché lineare anche nella definizione degli array.

Un comportamento del tutto analogo è valido per i cosiddetti short circuit operators (|| e &&) e per gli operatori stringa. Le operazioni effettuate all’interno di loop, quali ad esempio, l’istanziare classi e utilizzarne i metodi sono fortemente dipendenti dalle ottimizzazioni del compilatore.

Per quanto concerne, invece la gestione delle eccezioni, questi seguono un andamento differente e tutto sommato molto simile sia nell’utilizzo di un costrutto try-catch, sia nell’utilizzo di un costrutto if-then-else, come riportato in Figura 9.

Figura 9 - Consumo di energia in Joule nell'utilizzo di costrutti try-catch e if-then-else nella gestione delle eccezioni.

Tirando le somme, lo studio Energy Consumption in Java: An Early Experience3 ci consente di quantificare il risparmio energetico in funzione delle primitive utilizzate in linguaggio JAVA, con dei picchi che vanno dal 60% per la definizione dei tipi variabili al 33% in caso di utilizzo di instance variable invece che di un array, al 10% del corretto utilizzo degli short circuit operator.

Allargandone lo scenario di applicabilità, questo studio, fornisce una misura puntuale del risparmio energetico spazzando via eventuali nubi di scetticismo sulla effettiva possibilità di ridurre i consumi energetici a fronte di una maggiore “qualità” del codice nella sua accezione più ampia.

Nell’evoluzione dei paradigmi di programmazione, l’utilizzo diretto di primitive, come quelle viste sin qui, tende a limitarsi progressivamente. L’utilizzo “intensivo” di framework e librerie messe a disposizione dalle community di sviluppatori, riduce il quantitativo di codice sviluppato (e di primitive utilizzate) a favore di una integrazione di componenti; questo introduce la problematica della misurazione del consumo energetico di software applicativi complessi.

Numerosi studi hanno dimostrato come l’efficienza del software influenzi i consumi anche degli altri livelli infrastrutturali, ed è correlata all’efficienza computazionale spesa per svolgere quanto previsto dallo sviluppatore, come dimostrato nei paragrafi precedenti.

Questo include il fatto che l'efficienza energetica complessiva del software non è correlata solo alla velocità con cui il codice esegue un'attività, ma anche alla correttezza della sua esecuzione, in quanto sia l’efficienza del codice che le sue prestazioni sono legate alla qualità dello stesso.

Entrambi questi fattori, come tutte le altre caratteristiche di qualità del codice sono influenzate da come il software è progettato e implementato: pertanto, andremo ad esplorare inizialmente la relazione tra qualità del codice e consumo di energia correlato alle prestazioni; successivamente, prenderemo in considerazione la relazione tra qualità e difettosità del codice.

Queste relazioni sono state approfonditamente trattate nello studio condotto da CAST Italia, Accenture e dall’Università degli Studi di Napoli Federico II dal titolo: An effort allocation method to optimal code sanitization for quality-aware energy efficiency improvement[4].

In questo studio si esprime, a ragione, la qualità del codice in termini di grado di aderenza ad un insieme di best practices di programmazione, la cui violazione viene verificata tramite uno strumento di analisi statica quale, ad esempio, CAST MRI.

Tramite la misurazione di specifiche violazioni, in primis quelle espresse in Tabella 1, è possibile rilevare le applicazioni software che hanno maggiore probabilità di incidere sul consumo di energia legato alle prestazioni del codice, considerando che dette applicazioni hanno una maggiore difettosità.

Questo è dimostrato tramite algoritmi che alimentano modelli predittivi della relazione tra le violazioni individuabili da CAST MRI e le caratteristiche di efficienza energetica e la difettosità.

Se questo consente di quantificare il risparmio energetico, un altro aspetto fondamentale è quello di quantificare gli effort necessari alla correzione delle violazioni, individuate da CAST MRI, volta a ridurre sia l’impatto energetico del codice, sia la sua difettosità indotta.

[2] S.Pelley, D.Meisner, T.F.Wenisch, and J.W.VanGilder. Understanding and abstracting total datacenter power. In WEED2009
[3] Mohit Kumar, Youhuizi Li, Weisong Shi: Energy Consumption in Java: An Early Experience. In 2017 IGSC Track on Contemporary Issues on Sustainable Computing
[4] Marco Bessi , Gabriella Carrozza, Roberto Pietrantuono, Stefano Russo: An effort allocation method to optimal code sanitization for quality-aware energy efficiency improvement (http://ceur-ws.org/Vol-1708/paper-05.pdf)

Modello di consumo energetico basato sull’analisi del codice tramite CAST 

Il sopramenzionato studio, a sua volta, si basa si precedenti lavori[5,6]^, che introducono un modello di misurazione del consumo di energia da parte del software che separa il consumo delle risorse di calcolo da quello delle risorse di infrastruttura quali database e networking.

Questo modello, che riportiamo semplificando i passaggi matematici per i quali rimandiamo agli studi originali citati, esprime il consumo di energia come:

Dove:

• E_idle è il prodotto del consumo di CPU nel suo stato idle per il tempo nel quale resta in detto stato;
• E_CPU è il consumo di energia della CPU tenendo conto della crescita di consumo al variare dell’utilizzo;
• E_DB è il consumo di energia utilizzato per lo storage dei dati
• E_NET è il consumo di energia utilizzato per la trasmissione dei dati via rete.

In questa espressione, i fattori E_DB e E_NET sono minimamente dipendenti dal codice, mentre per il resto dipendono dalla infrastruttura hardware; considerando che il software applicativo per la massima parte utilizza CPU, detti fattori possono essere trascurati, E_CPU diventa l’elemento primario del consumo energetico espresso da E_TOT.

Le misure sono state effettuate utilizzando morsetti amperometrici collegati alla fonte elettrica della CPU del server sul quale sono state condotte le misure.

È possibile, quindi considerare le indicazioni prestazionali, e conseguentemente di consumo energetico, indicate da CAST MRI a valle dell’analisi statica del codice sorgente. L’adozione o la violazione alle best practices di programmazione oltre a determinare un rischio di difettosità in ambiente di collaudo, se non addirittura in esercizio, influisce sul consumo di energia e quindi sul valore E_CPU che, come visto, è il principale contributore del consumo complessivo E_TOT.

Si è, pertanto, rilevato il coefficiente di correlazione di Spearman (indicato con ρ) tra alcune violazioni rilevate con CAST MRI (Quality Metrics Subset di cui in Figura 2)e il consumo energetico del codice, come espresso in Tabella 2.

Tabella 2 - Correlazione tra violazioni rilevate con CAST MRI e il consumo energetico

Risulta evidente la correlazione diretta, e pressocché lineare, tra i Quality Metric Subset e il consumo di energia.

Come è intuitivo, la stessa cosa, sebbene con minore linearità, accade anche tra i Criteria, visti sempre in Figura 2, e il consumo energetico, come espresso in Tabella 3.

Tabella 3 - Correlazione tra i criteri di violazioni rilevati con CAST MRI e il consumo energetico

Ringraziando gli autori degli studi citati nel presente articolo, la roadmap prevedere ulteriori articoli di approfondimento  volti a correlare l’effort di risoluzione delle violazioni e il risparmio energetico risultante.

[5] M. Bessi, E. Capra, and C. Francalanci, “A benchmarking methodology to assess the energy performance of mis applications,” in 34th International Conference on Information Systems, 2013.
[6] G. Agosta, M. Bessi, E. Capra, and C. Francalanci, “Automatic memorization for energy efficiency in financial applications,” Sustainable Computing: Informatics and Systems, vol. 2, no. 2, pp. 105 – 115, 2012.