CGI:n blogi - kirjoituksia eri asiantuntijoilta

CGI Suomen asiantuntijat

Kirjoituksia asiantuntijoiltamme

Vihreä koodi eli green coding kasvattaa suosiotaan ohjelmistokehittäjien keskuudessa. Green Codingilla tarkoitetaan menetelmiä, joilla ohjelmistojen energiankulutus pyritään minimoimaan. Yhtälössä vaikuttavat muun muassa pilvikapasiteetin optimointi, ohjelmistokielen valinta, tiedostojen koko ja formaatti sekä datan prosessointi.

 

Ilmastonmuutos on yksi ihmiskunnan suurimmista haasteista. Tiesitkö, että ICT-alan osuus on 5-9% globaalista sähköenergian kulutuksesta? Arvioiden mukaan se tulee nousemaan jopa 21 prosenttiin vuoteen 2030 mennessä. Vaikka ohjelmistot kuluttavat merkittävästi energiaa, otetaan niiden suunnittelussa ja toteutuksessa energiankulutus harvoin huomioon.

Jos esimerkiksi polttomoottoria, mitä tahansa sähkölaitetta tai vaikka tehdasta suunnitteleva insinööritiimi pystyisi suunnittelemaan ratkaisun, joka kuluttaisi 20% vähemmän energiaa, sitä pidettäisiin merkittävänä läpimurtona.

Useimpien ohjelmistojen energiankulutuksesta saataisiin optimoitua melko helposti 20% pois, mutta tätä ei yleensä huomioida ohjelmistojen kehityksessä.

Ohjelmistojen kehitys on ehkä jopa ainoa insinööriala, jossa energiankulutukseen ei kiinnitetä käytännössä lainkaan huomiota. Aiheeseen ollaan kuitenkin nyt herätty ja tilanne tulee varmasti muuttumaan lähivuosina.

Green Codingilla tarkoitetaan menetelmiä, joilla ohjelmistojen energiankulutus pyritään minimoimaan.

 

Miten ohjelmistot kuluttavat energiaa?

Palvelinkeskukset, tietoliikennelaitteet ja päätelaitteet kuluttavat energiaa. Alla olevassa kuvassa näkyy, miten energiankulutus jakautuu laitteiden kesken. Palvelinkeskuksissa sijaitsevat laitteet kuluttavat 10-20 % energiasta, verkkolaitteet 20-30% ja päätelaitteet noin 60%. Tavalla, jolla ohjelmistoja toteutetaan, voidaan vaikuttaa näiden kaikkien energiankulutukseen.

Energiankulutuksen jakautuminen laitteittain
Lähde: https://www.strategie.gouv.fr/sites/strategie.gouv.fr/files/atoms/files/f_bordage_2019-02-21-francestrategie-ecodesign.pdf

 

Onko pilvi aina vihreä vaihtoehto?

Perinteisten konesalien kiinteä kapasiteetti tuhlaa energiaa. Tyypillisen palvelimen joutokäyntikuorma on noin 10% ja usein palvelin on 90% ajasta joutokäynnillä. Fyysisiin palvelimiin perustuvassa konesalissa tätä on vaikea optimoida.

Mutta onko pilvessä tilanne sen parempi?

Skaalautuvat arkkitehtuurit, jotka vapauttavat resurssit silloin kun työkuormaa ei ole, mahdollistavat radikaalin muutoksen. Parhaimmillaan pilvi on äärimmäisen energiatehokas ajoympäristö sovelluksille. Asialla on kuitenkin myös toinen puoli.

Sovelluskehittäjillä on taipumus hyödyntää kapasiteettia niin paljon kuin sitä on saatavilla. Huomaat tämän selvästi henkilökohtaisen tietokoneesi kanssa. Laitteiden tehot ovat kehittyneet huimasti, mutta sovellukset eivät toimi juurikaan nopeammin. Kun päivität uuden käyttöjärjestelmän vanhaan koneeseen, kaikki toimii hitaammin. Sovellukset rakennetaan niin että ne toimivat vain uusimmissa huipputehokkaissa koneissa.

Pilvessä tämä on erityisen huolestuttavaa, koska kapasiteettia on käytännössä rajattomasti. Kapasiteetin optimointi ei ole sovelluskehittäjien fokuksessa, joten sitä käytetään vastuuttomasti.

Pilvikonsultoinnissa pilvikapasiteetin optimointi on hyvin keskeinen teema tällä hetkellä. Mitä enemmän näemme eri organisaatioiden pilviympäristöjä, sitä selvemmin esiin nousee kapasiteettikustannusten (pahimmillaan hallitsematon) kasvu. DevOps ja kehitystiimien autonomia on ratkaissut kehitystiimien tuottavuuteen liittyvät haasteet, mutta tapahtuuko se kapasiteettikustannusten ja ilmaston kustannuksella?

Varmistathan että organisaatiossasi on riittävän tekninen taho, joka vastaa pilven kapasiteettikustannuksista ja niiden jatkuvasta optimoinnista.

  

Energiatehokkaat ohjelmointikielet

Onko valitulla ohjelmointikielellä vaikutusta energiatehokkuuteen?

Portugalilaisessa Universidade do Minho -yliopistossa on tehty varsin ansiokas tutkimus aiheesta. Alla olevassa taulukossa on tutkimuksen tulokset normalisoidussa muodossa. Taulukko kuvaa siis eri ohjelmointikielien energiankulutusta suhteessa toisiinsa.

Ohjelmointikielien energiankulutus suhteessa toisiinsa
Lähde: https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sleFinal.pdf

Tuloksista näkyy, että esimerkiksi Perl -ohjelmointikieli kuluttaa energiaa peräti 80 -kertaisesti C -kieleen verrattuna. Olemme siis aika merkittävän asian äärellä.

Tämä ei toki tarkoita sitä, että kaikki ratkaisut pitäisi tehdä C -kielellä. Mutta valintatilanne esimerkiksi Javan tai Pythonin välillä tulee helposti eteen ja silloin energiatehokkuus on ehdottomasti yksi näkökulma, joka tulisi ottaa huomioon. Python nimittäin kuluttaa energiaa 38 -kertaisesti Javaan verrattuna. TypeScript puolestaan kuluttaa energiaa viisinkertaisesti JavaScriptiin verrattuna.

Kun seuraavan kerran olet ohjelmointikielen valinnan edessä, huomioithan myös energiatehokkuuden.

  

Huomio datan prosessointiin

Tietotekniikka perustuu siihen, että tietokoneet toistavat saman tehtävän yhä uudestaan. Ne eivät väsy, eivätkä ne laiskottele. Laiskuudella on kuitenkin puolensa. Laiskuus nimittäin estää meitä ihmisiä tuhlaamasta energiaamme turhaan ja ohjaa tekemään asioita älykkäämmin. Tietokoneilla ei tätä ominaisuutta ole ja siksi ne tuhlaavat energiaa.

Tarkastellaan asiaa käytännön esimerkin kautta. Kirjaudut verkkosivulle, jonka etusivulla on dashboard, joka visualisoi kuluvan kuukauden tiedot kauniina graafeina. Sisältö voi liittyä vaikkapa yrityksesi IT -kustannuksiin. Sivu latautuu 500 millisekunissa, käyttökokemus on kunnossa ja kaikki hyvin. Vai onko?

Katsotaan mitä tuon 500 ms aikana konepellin alla tapahtuu:

  • Selain lähettää pyynnön sisällöstä palvelimelle
  • Palvelin tekee kyselyn tietokantoihin
  • Jokaisessa kyselyssä tietokantamoottori rajaa taulujen datamassasta halutun aikavälin tiedot, lataa ne muistiin, yhdistää eri taulujen datat annettujen kriteerien ja avaimien mukaisesti sekä koostaa niistä tulostaulun
  • Palvelin lataa tulostaulun verkon yli muistiin
  • Palvelin yhdistää kyselyiden tulokset
  • Palvelin formatoi datan sovelluksen haluamaan muotoon
  • Selain lataa datan verkon yli
  • Selainsovellus visualisoi datan graafeiksi

Tämä tehtävä toistetaan joka kerta, kun kuka tahansa käyttäjä avaa etusivun. Jos palvelulla on paljon käyttäjiä, tietokoneet toistavat tätä tehtävää jatkuvalla kuormalla. Tehtävä saatetaan suorittaa esimerkiksi 10 000 kertaa päivän aikana.

Esimerkkimme dashboard näyttää historiaan perustuvaa sisältöä, joka ei muutu päivän aikana. Järjestelmä voisi suorittaa tehtävän vain yhden kerran päivässä. Staattiset sivugeneraattorit (esim. Gatsby) ovat erinomainen valinta tällaisiin skenaarioihin.

Tämä oli vain yksittäinen esimerkki – sovellukset ovat täynnä muita vastaavia tehtäviä. Tietokoneet tekevät jatkuvasti samanlaista turhaa työtä kaikissa järjestelmissä, olipa kyseessä verkkosovellukset, data-alustat, integraatiot tai mikä tahansa muu järjestelmä. Tietoa prosessoidaan reaaliajassa, vaikka sisältö ei ole reaaliaikaista.

Jos järjestelmällä on paljon käyttäjiä, ainoastaan reaaliaikainen data tulisi prosessoida reaaliaikaisesti. Muuten prosessoinnin voi tehdä tarpeen mukaan vaikkapa tunneittain, päivittäin, viikoittain tai kuukausittain.

  

Vihreät megatavut ovat pieniä

Vierailin Suomen suosituimman verkkolehden etusivulla. Selain latasi sisältöä 1,5 MB edestä ja lataaminen kesti 4,6 sekuntia. Kyseisellä sivustolla on parhaimmillaan peräti 40 miljoonaa sivulatausta viikossa.

Tietoliikenne, palvelimet ja päätelaitteet kuluttavat energiaa. Kun sivulatauksia saadaan nopeammaksi, energiaa säästyy niin konesalissa, tietoverkon laitteissa kuin päätelaitteissakin.

Nopeasti laskettuna kyseisen sivuston osalta laitteet käyttävät sivulatauksiin huippuviikon aikana yli 2 100 vuorokautta (40 mlj x 4,6 s). Toki osalla käyttäjistä on nopeampi verkkoyhteys kuin minulla ja jos sivustolla käy usein, selaimen välimuisti parantaa tilannetta hieman.

Oletetaan että sisältöä saisi tiivistettyä vähän. Oletetaan, että esimerkiksi kuvien resoluutiota laskemalla sivulatauksen koko saataisiin pienennettyä 1,2 megatavuun, jolloin sivulataukseen kuluva aika laskisi 3,68 sekuntiin. Tällöin laitteiden sivulatauksiin käyttämä aika olisi 1 700 vuorokautta (40 mlj x 3,68 s). Yhdessä viikossa säästettäisiin siis peräti 400 vuorokautta laitteiden käyttöaikaa.

Laskelma on hyvin karkea ja yksinkertaistettu, mutta havainnollistaa tilannetta, eikö? Mediatiedostojen optimoinnilla voi olla suuri vaikutus energiankulutukseen.

Tarkoitukseni ei ole ottaa kantaa kyseisen sivuston vastuullisuuteen, sillä esimerkkinä olisi voinut käyttää mitä tahansa verkkosivustoa. Asia on kuitenkin helppo konkretisoida esimerkillä suositusta sivustosta, jossa sivulatauksia tapahtuu paljon.

Pienilläkin muutoksilla mediatiedostojen optimoinnissa voi olla merkittävä vaikutus energiankulutukseen ja ratkaisun ilmastoystävällisyyteen.

  

Hyvä, paha avoin lähdekoodi

Avoimen lähdekoodin kirjastot ovat mullistaneet ohjelmistojen kehityksen. Kun sovelluskehittäjä haluaa näyttää käyttäjälle esimerkiksi graafin, parsia merkkijonoja tai tehdä paikkatietoon liittyvä laskelmia, käytännössä aina löytyy valmis kirjasto hyödynnettäväksi. Avoin lähdekoodi on hieno asia, mutta siihen liittyy myös haasteita.

Kun sovelluskehittäjä valitsee kirjaston esimerkiksi pylväsdiagrammin esittämiseen, kirjaston mukana tulee lähdekoodit myös palkkikaavioiden, ympyrädiagrammien, pistekaavioiden, teemakarttojen, aluekaavioiden ja sädekaavioiden tekemiseen. Kirjastosta 90% on sovelluksen kannalta turhaa koodia, koska sovellus hyödyntää siitä vain pylväsdiagrammin. Sama pätee kaikkiin käytettäviin kirjastoihin. Kirjastoja käytetään niin paljon, että sovelluksiin paketoiduista lähdekoodeista suurin osa on itse asiassa turhaa koodia.

Miksi sovelluksen koko on ongelma?

Nykyaikaiset verkkosovellukset toteutetaan niin, että ne ladataan käyttäjän selaimeen kokonaisuudessaan ensimmäisen sivulatauksen yhteydessä. Kun sovelluspaketti on suuri, se kuluttaa runsaasti palvelinten, tietoliikennelaitteiden ja päätelaitteiden energiaa.

Toinen haaste liittyy järjestelmän skaalaamiseen. Jos taustapalveluissa käytettävät ohjelmistot (mikropalvelut ja API -sovellukset) ovat isoja, palveluiden skaalaaminen on raskasta ja kuluttaa paljon energiaa. Järjestelmän tulisi vapauttaa resurssit silloin kun työkuormaa ei ole. Kun kuormaa on, järjestelmä allokoi tarvittavat resurssit automaattisesti. Jos skaalattava sovellus on suuri, alustan pitää tehdä allokoinnin yhteydessä raskaita kopiointeja palvelinten välillä, mikä kuluttaa runsaasti energiaa.

Sovelluksen kehitysvaiheessa tulisi minimoida asennuspaketin eli "bundlen" koko ja välttää tarpeettoman koodin paketoimista asennuspakettiin.

  

Tiedostomuotojen valinnalla on väliä

Verkon yli siirrettävät tiedostot kuluttavat palvelinten, tietoliikennelaitteiden ja päätelaitteiden energiaa. Sama pätee myös sovellusten väliseen kommunikointiin, jota tapahtuu paljon.

Tarkastellaan esimerkkinä muutamaa yleistä tiedostoformaattia.

XML-muotoinen data

Aikanaan XML-muotoisia tiedostoja käytettiin paljon ja ne ovat melko suosittuja edelleen. Syntaksi näyttää tältä:

<henkiloidenLukumaara>3</henkiloidenLukumaara>

Esimerkissä on hyötykuormaa, eli "payloadia" tasan yksi merkki eli 3. Lisäksi siinä on peräti 45 merkkiä ns. "overheadia", joka kuvaa sisältöä, mutta ei sisällä itse dataa.

JSON -muotoinen data

Nykyään hyvin suositussa JSON-muodossa, esitystapa näyttää tältä:

{ henkiloidenLukumaara: 3 }

Hyötykuormaa on edelleen yksi merkki. Overheadia on 24 merkkiä.

Perinteinen CSV-tiedostomuoto

Perinteinen CSV -tiedostomuoto sisältää puolipisteellä eroteltuja arvoja:

;3

Hyötykuormaa on yksi merkki ja overheadia vain yksi merkki. CSV ei kuitenkaan ole kovin vahva muoto, jos tarpeena on esittää rakenteellista dataa.

Yksi hyvä ja energiatehokas tapa rakenteellisen datan siirtämiseen tehokas serialisointi. Googlen Protocol Buffer on hyvä esimerkki erittäin tehokkaasta tavasta pakata ja välittää rakenteellista dataa sovellusten välillä.

Tiedostoformaatin valinnalla voi vaikuttaa merkittävästi siirrettävän datan energiatehokkuuteen. JSON on energiatehokkaampi kuin XML, ja CSV on tehokas jos tarpeena on välittää taulukkomuotoista dataa.

Nämä ovat vain yksittäisiä esimerkkejä yleisesti käytetyistä tiedostomuodoista. Erilaisia tiedostomuotoja eri tyyppiselle sisällölle (esim. kuvat, videot tai teksti) on tuhansia ja niiden energiatehokkuudessa on huimia eroja. Energiatehokkuus on siis tärkeä näkökulma, joka tulee ottaa huomioon käytettävien tiedostomuotojen valinnassa.

  

Olisiko uudelleenkäytettävyys mahdollista?

Näemme aika paljon tilanteita, joissa asiakkaalla työskentelevät eri toimittajien tiimit keksivät pyörän yhä uudestaan ja kaikki sovellukset rakennetaan tyhjästä. Samat asiat opetellaan kantapään kautta, samat virheet tehdään ja kaiken lisäksi lopputuloksena on hyvin erilaisia ja hajanaisia ratkaisuja saman asian ratkaisemiseen. Tämä on paitsi kallista, myös ilmastoa kuormittavaa.

Tässä muutamia vinkkejä, miten voit tehostaa uudelleenkäytettävyyttä:

  • Osa IaC -automaatiosta kannattaa rakentaa keskitetysti
  • DevOps CI/CD -pipelinejen malliratkaisut ja käytännöt kannattaa rakentaa keskitetysti
  • Hyvin kuvatut parhaat käytänteet ja ohjeet ovat erinomainen tapa jakaa tietoa tiimien välillä
  • Mikropalveluille ja muille toistuville sovelluksille kannattaa rakentaa geneerinen pohja
  • Monitorointi, hälytykset ja keskitetty lokienhallinta kannattaa määritellä keskitetysti
  • ”Design system” on hyviä tapa jakaa ja hallita käyttöliittymäkomponentteja
  • Yhteisöllisen kehittämisen alusta (esim. GitHub), mahdollistaa lähdekoodien tehokkaan jakamisen ja yhteistoiminnan tiimien välillä

  

Koko elinkaari vihreämmäksi

Tässä kirjoituksessa olen nostanut esimerkinomaisesti esiin käytännön asioita, joilla ohjelmistojen energiankulutusta voidaan pienentää. Kirjoitus on kuitenkin vain pintaraapaisu valtavan laajaan aiheeseen. Sovelluksen koko elinkaareen, sen rakentamisesta, ajonaikaiseen toimintaa, käytettävyyteen ja odotusaikoihin liittyy valtava määrä asioita, joissa energiankulutus tulisi huomioida yhtenä näkökulmana.

Kannustan organisaatioita miettimään ensin omia käytäntöjään, kuvaamaan omat Green Coding -menetelmänsä sekä jalkauttamaan ne sovelluksen elinkaaren kaikkiin vaiheisiin.

Blogin on kirjoittanut Matti Koljonen.

Kuuntele lisää aiheesta Podcastissa

 

Kuuntele Spotifyssa

 Kuuntele Sound Cloudissa

Kirjoittajasta

CGI:n blogi - kirjoituksia eri asiantuntijoilta

CGI Suomen asiantuntijat

Kirjoituksia asiantuntijoiltamme

CGI on kansainvälisesti suomalainen digitalisaatiokumppani.  Suomessa noin 3 800 asiantuntijaa konsultoivat asiakkaitamme liiketoiminnan ja ICT-ratkaisujen kehittämisessä. Tällä profiililla julkaisemme kirjoituksia CGI:n eri asiantuntijoilta.