Op weg naar duurzame software

Op weg naar duurzame software
Centric en onderzoeksgroep Software Systems van de Universiteit Utrecht werken aan richtlijnen om software duurzamer te maken en aan een meetlat om die duurzaamheid te beoordelen. Een tussenstand.
Erik Jagroep
Duurzaamheid is in korte tijd een terugkerend onderwerp geworden in de agenda’s van organisaties en overheidsinstanties. De kern van duurzaamheid is het principe dat de huidige generatie functioneert zonder de mogelijkheden voor toekomstige generaties te beperken. Een van de manieren om dat te realiseren en die de afgelopen jaren steeds meer aandacht heeft gekregen, is duurzame ICT. Voor duurzame ICT geldt dat de invulling per organisatie varieert. De een richt zich op het slim schalen van de capaciteit door (server-) racks uit te schakelen wanneer deze niet nodig zijn, de ander verduurzaamt door meer energie-efficiënte hardware in te zetten. De nadruk op hardware is echter slechts een deel van de puzzel. Met software die efficiënter gebruik maakt van de beschikbare middelen is ook winst te behalen. Denk bijvoorbeeld aan een applicatie die minder energie verbruikt voor het uitvoeren van een specifieke taak of meer klanten kan bedienen met dezelfde hoeveelheid energie.
Centric Sustainability Lab
Centric en de onderzoeksgroep Software Systems van de Universiteit Utrecht hebben een promotieonderzoek opgezet naar duurzame software. Het doel is richtlijnen op te stellen om software duurzamer te maken en daarbij een meetlat te ontwikkelen waar de duurzaamheid van software mee kan worden beoordeeld. Gezien de core business van Centric is ervoor gekozen om het onderzoek te richten op productsoftware, en dan te kijken naar zowel het ontwikkelproces als het eindproduct. De uitdaging in dit onderzoek is het feit dat ‘duurzame software’ een onontgonnen gebied is; vergeleken met andere onderzoeksgebieden zijn er weinig rapporten en publicaties beschikbaar. Bovendien bevatten de (onderzoeks-) resultaten die beschikbaar zijn vrijwel geen bevindingen die softwarebedrijven in de praktijk kunnen toepassen.
Een van de oorzaken van deze achterstand is dat we vooralsnog niet in staat zijn om op een betrouwbare manier het energieverbruik van software te meten. In moderne datacenteromgevingen zijn doorgaans verschillende hardwarecomponenten aanwezig, meerdere applicaties geïnstalleerd en virtuele omgevingen ingericht. Om de last van de applicaties zo goed mogelijk over de beschikbare hardware te verdelen, is er ook vaak een ‘load balancer’ aanwezig. Deze verdeling is noodzakelijk om te komen tot een kosteneffectieve en efficiënte dienstverlening, maar hij bemoeilijkt tegelijkertijd het verrichten van metingen met software. Om het energieverbruik van software te meten, moet namelijk het gebruik van software worden gerelateerd aan het energieverbruik van hardware, want de software geeft instructies aan de hardware om taken uit te voeren. Maar als het onduidelijk is welke hardware exact wordt belast en in welke mate dit te wijten is aan een softwareproduct, is het energieverbruik zeer lastig te bepalen. Bovendien is het ook niet zomaar mogelijk om het energieverbruik van hardwarecomponenten te meten. Niet elk component heeft eigen sensoren die het stroomverbruik rapporteren, en waarden die wel worden gerapporteerd kunnen afwijken van de werkelijkheid.
Om het toch mogelijk te maken met productsoftware te experimenteren is het Centric Sustainability Lab (CSL) opgezet. Het CSL is een omgeving waar inzicht kan worden verkregen in de performance en het bijbehorende energieverbruik van hardwarecomponenten. Met deze informatie kan een verbruikte hoeveelheid energie worden toegekend aan een piek in bijvoorbeeld de belasting van de processor veroorzaakt door het gebruik van een softwareproduct. Om de metingen goed te kunnen verrichten, is ervoor gekozen om te werken met één enkele testserver. Zo is het eenduidig dat de hardware van die ene server moet worden gemeten om alle fluctuaties in het energieverbruik inzichtelijk te maken. Maar deze server is wel gehuisvest in een reeds bestaand datacenter van Centric om een situatie te creëren die zo veel mogelijk overeen komt met de praktijk. Hierdoor kan er gebruik worden gemaakt van de reeds aanwezige infrastructuur, koelinstallatie en andere faciliteiten die van belang zijn voor de metingen.
Eerste onderzoek
Het eerste onderzoek dat is uitgevoerd in het CSL is gericht op het in kaart brengen van het verschil tussen single- en multi-tenant productsoftware. Denk aan een softwareproduct dat voor één enkele klant kan worden ingezet (single-tenant), maar ook meerdere klanten kan bedienen met één enkele instantie van het product (multi-tenant) (zie figuur 1) . In een multi-tenant omgeving delen klanten de middelen die nodig zijn om gebruik te maken van het softwareproduct met als doel de totale kosten te verlagen. In plaats van een datacenter per klant (zoals bij een ‘on-premise deployment’) kunnen nu meerdere klanten worden bediend vanuit één groot datacenter. Hierbij is het ook gangbaar dat het beheer en onderhoud van deze middelen de verantwoordelijkheid wordt van een andere partij. Voor de duurzaamheid betekent dit dat deze partij kan profiteren van de schaalvoordelen die deze centrale inrichting met zich mee brengt. Er is bijvoorbeeld slechts één (weliswaar grotere) koelinstallatie nodig, maar deze verbruikt in de regel minder energie dan meerdere kleine installaties.
Figuur 1. Single- en multi-tenant productsoftware. Elke gebruiker (G) heeft toegang tot de data van de specifieke klant
Voor het eerste onderzoek is gekozen om gebruik te maken van het Centric-product Key2Financiën. Key2Financiën is een informatiesysteem voor financieel management en projectbeheersing voor decentrale overheden zoals gemeenten, provincies, waterschappen en samenwerkingsverbanden. Dit product is geko
zen omdat het zowel op een single-als multitenant manier kan worden ingezet, waarbij het specifiek gaat om ‘shared table multi-tenancy’. Dit houdt in dat klanten de hardware en de database met elkaar delen. Uiteraard hebben de klanten alleen toegang tot hun eigen data. Om inzicht te krijgen in de invloed van software op het energieverbruik zijn er experimenten uitgevoerd met een specifieke taak binnen Key2Financiën, zijnde het maken van een rapport dat een overzicht toont van projectbegrotingen over een geselecteerde periode. De testmethode die is toegepast omvat het geautomatiseerd uitvoeren van de genoemde taak waarbij op de achtergrond metingen worden verricht om de belasting en het energieverbruik van verschillende hardwarecomponenten inzichtelijk te maken. Hiertoe zijn drie hulpmiddelen ingezet: NeoLoad, de performancemonitor van Microsoft Windows (Perfmon) en ESSaver voor respectievelijk het automatiseren van de genoemde taak, het meten van de performance en het meten van het energieverbruik. Met behulp van NeoLoad zijn de stappen geregistreerd die moeten worden doorlopen om een rapport te maken. Deze stappen kunnen vervolgens naar keuze meerdere malen simultaan worden afgespeeld om een gebruikerslast te simuleren. Parallel aan deze simulatie houdt Perfmon de performance van verschillende hardwarecomponenten bij en verricht ESSaver metingen op het energieverbruik van het geheel. Er kan er tot op het niveau van individuele hardwarecomponenten worden gemeten.
Om daadwerkelijk het verschil aan te tonen tussen single- en multi-tenant software zijn verschillende scenario’s gemeten met de genoemde tools. Elk scenario omvat een vooraf ingesteld aantal gebruikers die tegelijk een rapport maken in Key-2Financiën. Hierbij is de keuze gemaakt om in de multi-tenant situatie drie tenants in te richten en in zowel de single-tenant als de multi-tenant achtereenvolgens één, twee en drie gelijktijdige gebruikers per tenant te simuleren. Er zit dus een factor drie verschil tussen het aantal gebruikers in de single- en multi-tenant inrichting. Zo is inzicht verkregen in de manier waarop de software schaalt. Hoewel het aantal gebruikers niet overeenkomt met de tientallen gebruikers in de praktijk, is er bewust voor gekozen om dit aantal te beperken tot drie per tenant. Op deze manier wordt namelijk voorkomen dat de testserver constant op de piek van zijn performance zit en daarmee een vertekenend beeld oplevert.
Eerste resultaten
De resultaten van het eerste experiment zijn samengevat in figuur 2 . Die toont per scenario de met ESSaver gemeten waarden voor het energieverbruik in kWh en in de kolom direct rechts daarnaast het energieverbruik per gebruiker van dat scenario. Het getoonde getal is een gemiddelde van twee metingen, waarbij de metingen onderling nagenoeg niet van elkaar verschillen. De tabel toont bijvoorbeeld dat er in een multi-tenant inrichting met twee gebruikers per tenant 0.000484 kWh aan energie wordt verbruikt als alle gebruikers gelijktijdig een rapport maken in de applicatie. Let wel, het betreft alleen de waarden specifiek voor Key2Financiën. Hoewel het zeer waarschijnlijk is dat bijvoorbeeld het operating system andere verbruikswaarden toont, is het op dit moment te complex om deze in de metingen mee te nemen. Over het algemeen tonen de resultaten aan dat het energieverbruik in alle multi-tenant scenario’s hoger is dan in de single-tenant scenario’s. Deze bevinding moet echter in perspectief worden geplaatst voor wat betreft de benodigde hardware en het aantal gebruikers dat wordt bediend.
Figuur 2. Energieverbruik van gemeten scenario’s in kWh volgens ESSaver
In de praktijk komt met enige regelmaat het verzoek om softwareproducten op een single-tenant manier in te zetten. Simpel gezegd betekent dit dat elke klant zijn eigen hardware-infrastructuur heeft om de applicatie aan de eindgebruikers beschikbaar te maken. De gerapporteerde waarden in figuur 2 zijn specifiek voor het gebruik van Key2Financiën en bevatten niet de waarden voor andere processen die nodig zijn om de server draaiende te houden. Deze andere processen zorgen echter wel voor een overhead in het beschikbaar maken van de applicatie en van deze overhead kan worden gesteld dat deze een significant aandeel heeft in het stroomverbruik. In een single-tenant situatie draagt elke klant individueel de last van de overhead, terwijl in een multi-tenant inrichting deze overhead wordt verdeeld over meerdere klanten.
Wat betreft het aantal gebruikers dat wordt bediend, is het van belang om de reeds genoemde factor drie voor de multi-tenant in beschouwing te nemen. In bijvoorbeeld het scenario van twee gebruikers per tenant zijn in de single- en multi-tenant inrichtingen respectievelijk twee en zes gebruikers aanwezig. Om deze situaties met elkaar te vergelijken, berekenen we de toename in energieverbruik per gebruiker. De waarden bij de single-tenant scenario’s tonen een toename van 0.0000884 kWh naar 0.000139 kWh en 0.000329 kWh wanneer er een gebruiker bij komt. Gemiddeld kost het dus 0.00012 kWh om één extra gebruiker te bedienen. In het geval van de multi-tenant scenario’s nemen de waarden toe van 0.00211 kWh naar 0.000484 kWh en 0.000517 kWh. De gemiddelde toename per gebruiker komt daarmee op 0.000051 kWh. Ten opzichte van de single-tenant scenario’s kost het dus 0.0000694 kWh minder energie om één gebruiker te bedienen in een multi-tenant scenario. Deze bevinding toont dat het softwareproduct efficiënter schaalt wanneer deze multi-tenant wordt ingericht.

Figuur 3. Performancemeting multi-tenant scenario met twee gebruikers per tenant
 
Figuur 3 toont een voorbeeld van de performance metingen die zijn verricht in het multi-tenant scenario met twee gebruikers per tenant. In de legenda staat gespecificeerd welke objecten, specifieke instanties en items zijn gemeten specifiek, maar hier moet de kanttekening bij worden geplaatst dat deze selectie specifiek is bedoeld voor Key2Financiën. Voor elk softwareproduct moet individueel worden bepaald welke processen en bijbehorende items van belang zijn. De blauwe lijn toont bijvoorbeeld de processorbelasting veroorzaakt door het ‘oracle proces’ in opdracht van Key2Financiën. Met behulp van de uiteenzetting over tijd op de x-as, kunnen de fluctuaties in de lijnen worden gerelateerd aan specifieke acties in het uitvoeren van de gehele taak. Van links naar rechts kunnen pieken A, B en C worden geïdentificeerd:
A: Het opstarten van de applicatie en het inloggen van een gebruiker. In deze piek is te zien dat het ‘oracle proces’ voornamelijk actief is om de juiste data beschikbaar te stellen aan de gebruiker. Dit gaat gepaard met een piek in het aantal leesbewerkingen op de harde schijf (groene lijn) en het aantal bytes dat wordt gelezen (bruine lijn).
B: De navigatie binnen de applicatie naar het rapport voor projectbegrotingen. Er is weinig belasting afgezien van het ‘oracle proces’, dat ervoor zorgt dat de benodigde informatie beschikbaar wordt gemaakt.
C: Het maken van de rapporten en vervolgens afsluiten van de applicatie. De laatste piek in de grafiek toont de belasting wanneer de rapporten daadwerkelijk worden gemaakt. Hier zijn wederom het ‘oracle proces’ en de performance indicatoren voor de harde schijf te zien voor het aanleveren van de data, maar ook het ‘javaw proces’ is prominent aanwezig om de rapporten aan de gebruiker te tonen.
Figuur 4. ESSaver-meting van het energieverbruik in het multi-tenant scenario met twee gebruikers per tenant
Met behulp van ESSaver kan eenzelfde grafiek worden gemaakt, maar in plaats van de performance wordt het energieverbruik door de tijd getoond. Figuur 4 toont de metingen voor hetzelfde scenario als in figuur 3, waarbij dezelfde pieken kunnen worden aangeduid. Per proces is het mogelijk de verbruikswaarden voor de CPU, het geheugen, de harde schijf en de NIC (netwerkadapter) in de grafiek op te nemen. In figuur 4 zijn echter alleen de waarden voor de CPU opgenomen, aangezien dit de grootste factor is gebleken wat betreft energieverbruik. De waarden voor de andere hardwarecomponenten waren niet hoger dan drie Watt; dit wordt bevestigd door de verbruikswaarden zoals in figuur 5 . Deze toont de drie processen die nodig zijn voor het gebruiken van Key2Financiën en per proces een verbruikswaarde voor specifieke hardwarecomponenten. Voor elk scenario is zo’n tabel gemaakt en dit heeft uiteindelijk geleid tot de resultaten in figuur 2.
Figuur 5. ESSaver-meting van het energieverbruik per component in het multi-tenant scenario met twee gebruikers per tenant
Conclusie
De conclusie van het eerste onderzoek is dat Key2Financiën in een multi-tenant inrichting meer energie verbruikt dan een single-tenant inrichting. Maar wanneer de verbruikswaarden per gebruiker worden berekend, geven de resultaten aan dat een multi-tenant inrichting efficiënter schaalt wanneer het aantal gebruikers toeneemt. Gemiddeld kost het in de single-tenant inrichting 0.00012 kWh om één extra gebruiker te bedienen, ten opzichte van 0.000051 kWh in de multi-tenant inrichting. Deze bevinding toont aan duurzaamheid door het multi-tenant inzetten van software niet alleen toe te schrijven is aan de hardware, maar dat ook software een belangrijke rol kan spelen. Deze rol zal toenemen met het vergroten van de schaal. De resultaten bevestigen ook dat de belasting van de CPU de grootste oorzaak is van fluctuaties in het energieverbruik. Het energieverbruik van de harde schijf, het geheugen en de netwerkcontroller vallen namelijk in het niet vergeleken met de CPU. Let wel, dit geldt specifiek voor Key2Financiën en kan variëren per applicatie, waar andere performance-indicatoren van belang kunnen zijn.
De gepresenteerde resultaten zijn een eerste meting en zijn verkregen uit een speciaal hiervoor ingerichte testomgeving. Een beperking hierbij is het aantal metingen dat is uitgevoerd. De resultaten zijn derhalve een vereenvoudigde voorstelling van een meer complexe productieomgeving. Hoewel de gepresenteerde resultaten specifiek zijn voor Key2Financiën, is de toegepaste methode een stap in de richting van een methode voor productsoftware in het algemeen. Zo kan deze na verfijning bijvoorbeeld worden toegepast om zogenaamde kantelpunten voor een softwareproduct te vinden. Denk aan het maximaal aantal klanten of gebruikers, waarbij het energiezuiniger is om meer hardware te plaatsen in plaats van de klanten of gebruikers toe te voegen aan de huidige infrastructuur.
Wat betreft het onderzoek naar duurzame software in het algemeen biedt dit eerste resultaat voldoende perspectief op vervolgonderzoeken. Denk bijvoorbeeld aan het toevoegen en variëren van parameters en variabelen, het uitbreiden van de testomgeving naar een complexere, meer realistische omgeving of zelfs variaties aanbrengen in de software- en hardware-architectuur. Allemaal gericht op het vinden van de meest energiezuinige oplossingen voor softwareproducten. Het uiteindelijke doel is om richtlijnen op te stellen voor energiezuinige softwareproducten en mogelijk een objectieve meetlat te creëren waarmee deze kunnen worden beoordeeld op hun energiezuinigheid.
 
Erik Jagroep is consultant en PhD candidate bij Centric. E-mail: erik.jagroep@centric.eu
 
 

Tag

Onderwerp



Niet gevonden? Vraag het de redactie!

Heeft u het antwoord op uw vraag niet gevonden, of bent u op zoek naar specifieke informatie? Laat het ons weten! Dan zorgen we ervoor dat deze content zo snel mogelijk wordt toegevoegd, of persoonlijk aan u wordt geleverd!

Stel uw vraag