Recent Post
-
AWS-lasku kasvaa huomaamatta – mistä pilvikulut oikeasti syntyvät?
-
Pilviympäristön API-integraatiot eivät aina toimi kuten pitäisi ?
-
Ongelmat tietojen synkronoinnissa pilvisiirron aikana: yleiset syyt ja ratkaisut
-
Konfiguraatiodrifti IT-infrastruktuurissa – mistä se syntyy, miksi se on riski ja miten sitä voidaan hallita
AWS-lasku kasvaa huomaamatta – mistä pilvikulut oikeasti syntyvät?
AWS:n käyttöönotto ei yleensä tunnu kalliilta silloin, kun ensimmäinen palvelu käynnistetään. Kehitysympäristöön luodaan muutama resurssi, sovellus viedään pilveen ja lasku näyttää vielä kohtuulliselta.
Sitten ympäristö kasvaa.
Uusia palveluita otetaan käyttöön. Testiympäristöjä syntyy lisää. Lokit säilytetään pidempään. Tietokantoihin kertyy dataa ja liikennemäärät kasvavat. Jossain vaiheessa AWS-lasku onkin aivan eri tasolla kuin alussa.
Tässä kohtaa ongelma ei yleensä ole yksi kallis palvelu.
Useammin kyse on monesta pienestä päätöksestä, joita ei ole koskaan tarkasteltu yhdessä.
Yksi EC2-instanssi pyörii yöllä ilman käyttäjiä. Kehitysympäristön tietokanta on tuotantoympäristön kokoinen. S3:een kertyy vanhoja tiedostoja. CloudWatchiin lähetetään valtava määrä lokia. Dataliikenteestä maksetaan enemmän kuin alun perin arvioitiin.
Yksittäisenä nämä eivät välttämättä herätä huomiota. Kuukaudesta toiseen ne alkavat näkyä laskussa.
AWS-kustannusten optimointi ei siksi tarkoita sitä, että kaikki palvelut pitäisi vaihtaa halvimpaan mahdolliseen vaihtoehtoon. Ensin pitää selvittää, mistä kustannukset syntyvät ja ovatko ne liiketoiminnan kannalta perusteltuja.
Mikä oikeasti hidastui?
Pilviympäristössä rahaa voi kulua samaan aikaan kymmeniin eri palveluihin.
Käytössä saattaa olla esimerkiksi EC2, RDS, S3, Lambda, CloudFront, CloudWatch ja erilaisia verkko- ja tietoturvapalveluita. Lisäksi samaa ympäristöä voidaan käyttää kehitykseen, testaukseen ja tuotantoon.
Kun lasku tulee, siinä näkyy kustannuksia paljon eri suunnista.
Jos ympäristöä ei ole rakennettu kunnolla tunnistettavaksi, on vaikea vastata yksinkertaiseen kysymykseen:
- Tässä kohtaa AWS:n tagit ja kustannusten kohdistaminen ovat käytännössä tärkeämpiä kuin yksittäisen instanssityypin vaihtaminen.
- Tuotanto, testi ja kehitys kannattaa pystyä erottamaan toisistaan. Samoin eri sovellukset ja liiketoiminta-alueet.
- Muuten optimointikeskustelu jää helposti tasolle “AWS on liian kallis”.
- Se ei vielä kerro mitään siitä, mitä pitäisi tehdä.
Mikä tiimi, sovellus tai ympäristö aiheuttaa tämän kulun?
Käyttämätön kapasiteetti maksaa siinä missä käytettykin
Yksi helpoimmista säästökohteista löytyy usein ympäristöistä, joita kukaan ei enää aktiivisesti käytä.
Kehityksen aikana käynnistetty EC2-instanssi voi jäädä päälle viikonlopuksi. Testitietokanta voi olla käytössä vain muutaman tunnin päivässä, mutta sitä pidetään jatkuvasti käynnissä.
Sama koskee muitakin resursseja.
Pilvessä resurssin olemassaolo ei tarkoita, että siitä olisi juuri nyt hyötyä.
Tämä on yksi syy siihen, miksi kustannuksia kannattaa tarkastella yhdessä käyttöasteen kanssa. Jos resurssia käytetään vähän, mutta siitä maksetaan jatkuvasti, siinä voi olla ensimmäinen selkeä säästökohde.
Kehitysympäristössä ratkaisu voi olla hyvin yksinkertainen: ympäristö sammutetaan automaattisesti silloin, kun sitä ei tarvita.
Tuotannossa tilanne on tietenkin toinen. Siellä kapasiteetin vähentämisessä pitää huomioida kuormitus, saatavuus ja liiketoiminnan vaatimukset.
EC2-optimointi ei tarkoita vain halvempaa instanssia
- EC2-kustannuksissa huomio kiinnittyy helposti instanssityyppiin.
- Se on vain yksi osa kokonaisuutta.
- Jos sovellus tarvitsee jatkuvasti tietyn määrän CPU- ja muistiresursseja, väärän kokoinen instanssi maksaa ylimääräistä joka kuukausi.
- Toisaalta liian pieni instanssi voi aiheuttaa uuden ongelman. Sovellus alkaa käyttää enemmän CPU-aikaa, muistia tai muita resursseja, jolloin suorituskyky kärsii.
- Siksi kokoa ei kannata valita pelkän hinnan perusteella.
- Parempi lähtökohta on katsoa todellista käyttöä.
- Jos palvelin käyttää jatkuvasti vain pienen osan sille varatusta kapasiteetista, kannattaa selvittää, onko nykyinen koko perusteltu. Jos kuorma vaihtelee paljon, myös automaattinen skaalaus voi olla järkevämpi kuin jatkuvasti liian suuri kapasiteetti.
- AWS-ympäristössä kustannus ja suorituskyky kulkevat tässä kohtaa käsi kädessä.
RDS voi kasvaa kalliiksi ilman, että tietokanta "muuttuu"
➠ Tietokantakustannukset ovat toinen kohta, jossa kasvu tapahtuu helposti vähitellen.
➠ Aluksi tietokanta on pieni. Myöhemmin rivejä kertyy miljoonia ja levytilan tarve kasvaa.
➠ Samaan aikaan varmuuskopioita ja muita tietoja säilytetään pitkään.
➠ Jos tietokannan kokoa tai suorituskykyä kasvatetaan aina tarpeen mukaan, mutta vanhoja ratkaisuja ei koskaan tarkisteta, ympäristöön voi jäädä ylimitoitettua kapasiteettia.
➠ Tietokannan optimoinnissa ei kuitenkaan pidä tuijottaa pelkkää kuukausihintaa.
➠ Jos pienempi RDS-instanssi aiheuttaa enemmän hitaita kyselyitä ja kasvattaa sovelluksen kuormaa, säästö voi olla näennäinen.
➠ Tietokannan kustannuksia kannattaa tarkastella yhdessä SQL-kyselyiden, indeksien, yhteyksien, kuormituksen ja datan kasvun kanssa.
➠ Joskus halvin tapa pienentää AWS-laskua onkin korjata yksi huono kysely.
S3 näyttää halvalta, kunnes dataa kertyy vuosien ajan
S3 on helppo ottaa käyttöön.
Tiedosto tallennetaan ja sillä selvä.
Ongelma alkaa myöhemmin.
Sovellus voi tallentaa kuvia, raportteja, varmuuskopioita, lokitiedostoja ja muita aineistoja tuhansittain tai miljoonittain. Kaikkia niitä ei välttämättä enää tarvita samalla tavalla.
Jos vanhaa dataa säilytetään aina samassa tallennusluokassa, kustannuksia kertyy vähitellen.
Tässä kohtaa kannattaa miettiä, mitä datalle oikeasti tapahtuu sen jälkeen, kun se on luotu.
Tarvitaanko viime kuukauden raportteja jatkuvasti? Entä viisi vuotta vanhoja tiedostoja?
S3 Lifecycle -säännöt voivat siirtää harvemmin käytettyä dataa sopivampiin tallennusluokkiin tai poistaa aineistoa, kun säilytysajan vaatimus täyttyy.
Tärkeää on kuitenkin erottaa tekninen optimointi liiketoiminnan ja sääntelyn vaatimuksista. Kaikkea vanhaa dataa ei saa eikä pidä poistaa vain siksi, että sen säilyttäminen maksaa.
Lokit voivat muodostaa yllättävän suuren laskun
Lokitus on välttämätöntä tuotannossa.
Liian vähäinen lokitus tekee vian tutkimisesta vaikeaa. Toisaalta kaikkea ei tarvitse kirjoittaa lokiin.
Jos sovellus lähettää valtavan määrän debug-tason tietoa CloudWatchiin jatkuvasti, kustannus voi kasvaa liikenteen mukana.
Erityisen hankalaa on se, jos samaa tietoa kirjoitetaan useaan paikkaan ilman selvää tarkoitusta.
Lokien optimointi ei tarkoita sitä, että niitä pitäisi poistaa mahdollisimman paljon.
Ensin kannattaa kysyä:
- Mitä tarvitsemme häiriötilanteessa?
- Mitä tarvitsemme tietoturvan vuoksi?
- Mitä tarvitsemme liiketoiminnan seurantaan?
- Ja mikä tieto on vain kehityksen aikana hyödyllistä?
Kun nämä erot tehdään, lokimäärää voidaan usein pienentää ilman, että tuotannon valvonta kärsii.
Verkkoliikenteen kustannukset jäävät helposti huomaamatta
- AWS-laskussa ei ole kyse vain palveluiden laskentatehosta.
- Myös datan siirtäminen palveluiden välillä voi maksaa.
- Tämä korostuu erityisesti ympäristöissä, joissa sovellus käyttää useita AWS-palveluita tai liikennettä kulkee eri alueiden tai verkkojen välillä.
- Jos suuri määrä dataa liikkuu jatkuvasti palvelusta toiseen, kannattaa selvittää, miksi sitä tapahtuu.
- Esimerkiksi suuri tiedosto voidaan joskus käsitellä siellä, missä se sijaitsee, sen sijaan että koko aineisto siirretään toiseen palveluun vain yhtä käsittelyvaihetta varten.
- Tällaiset ratkaisut eivät ole aina mahdollisia, mutta niitä kannattaa ainakin tarkastella.
- Pilvikustannusten optimointi menee tässä kohtaa jo selvästi arkkitehtuurin puolelle.
Lambda ei ole automaattisesti halvin vaihtoehto
➠ Serverless-ratkaisut muuttavat tapaa, jolla kapasiteetista maksetaan.
➠ Lambda voi olla erittäin järkevä ratkaisu tapahtumapohjaisiin ja epäsäännöllisiin työkuormiin. Jos funktiota kutsutaan harvoin, jatkuvasti päällä olevan palvelimen ylläpitäminen ei välttämättä ole järkevää.
➠ Mutta suuren ja jatkuvan kuorman kohdalla tilanne voi olla erilainen.
➠ Kustannuksia kannattaa tarkastella yhdessä kutsumäärän, suoritusajan, muistin, liikenteen ja muun arkkitehtuurin kanssa.
➠ Joskus serverless-ratkaisu säästää rahaa. Joskus jatkuvasti kuormitettu palvelu on kustannustehokkaampi toisella toteutustavalla.
➠ Teknologiaa ei siis kannata valita hinnaston yhden rivin perusteella.
Automaattinen skaalaus on kustannustyökalu
Monessa ympäristössä kapasiteetti mitoitetaan pahimman mahdollisen kuorman mukaan.
Se tarkoittaa käytännössä sitä, että resursseja on jatkuvasti enemmän kuin normaalissa käytössä tarvitaan.
Jos liikenne vaihtelee voimakkaasti, automaattinen skaalaus voi muuttaa kustannusrakennetta merkittävästi.
Pienempi kapasiteetti normaalitilanteessa ja suurempi kapasiteetti kuormapiikin aikana voi olla järkevämpi ratkaisu.
Tässä on kuitenkin yksi tärkeä ehto: skaalaus pitää testata.
Ei riitä, että järjestelmä osaa teknisesti käynnistää uusia instansseja. Myös tietokannan, yhteyspoolien, ulkoisten rajapintojen ja muiden riippuvuuksien pitää kestää kasvanut kuorma.
Muuten kustannusoptimointi voi muuttua suorituskykyongelmaksi.
Reserved Instances ja Savings Plans eivät korjaa huonoa arkkitehtuuria
AWS:n sitoutumiseen perustuvat hinnoittelumallit voivat olla hyödyllisiä, kun kuormitus on riittävän ennustettavaa.
Mutta ennen sitoutumista kannattaa tietää, mitä oikeasti käytetään.
Jos yritys ostaa kapasiteettia pitkäksi aikaa ja ympäristö muuttuu muutaman kuukauden päästä, säästö voi jäädä pieneksi tai suunnitelma voi olla huonosti nykyiseen käyttöön sopiva.
Ensin ympäristö kuntoon.
Sen jälkeen kannattaa tarkastella, mikä kapasiteetti on aidosti jatkuvaa.
Säästömallit toimivat parhaiten silloin, kun käyttö tunnetaan riittävän hyvin.
Miksi kustannusoptimointi epäonnistuu niin helposti?
- Usein ongelma ei ole tekninen.
- Kukaan ei vain omista asiaa.
- Kehittäjä keskittyy sovellukseen. DevOps-tiimi ylläpitää infrastruktuuria. Talousosasto näkee laskun. Liiketoiminta päättää kasvusta.
- Jos nämä näkökulmat eivät kohtaa, kustannukset voivat kasvaa pitkään ilman, että kukaan näkee kokonaisuutta.
- Siksi kustannusten seurannasta kannattaa tehdä normaali osa AWS-ympäristön ylläpitoa.
- Ei kerran vuodessa tehtävä erillinen projekti.
- Kun uusi palvelu otetaan käyttöön, pitäisi jo silloin tietää, miten sen kustannuksia seurataan.
- Kun liikenne kasvaa, pitäisi nähdä, miten kasvu vaikuttaa laskuun.
- Kun ympäristöön jää vanhoja resursseja, niiden omistajan pitäisi olla tiedossa.
Mistä AWS-kustannusten selvittäminen kannattaa aloittaa?
➠ En aloittaisi vaihtamalla kymmentä AWS-palvelua halvempaan vaihtoehtoon.
➠ Aloittaisin laskusta.
➠ Mihin raha tällä hetkellä menee?
➠ Sen jälkeen katsoisin, mikä on muuttunut viime kuukausien aikana.
➠ Onko liikenne kasvanut?
➠ Onko dataa kertynyt enemmän?
➠ Onko uusia ympäristöjä perustettu?
➠ Onko lokien määrä kasvanut?
➠ Onko jokin palvelu jäänyt päälle?
➠ Kun suurimmat kustannuserät ovat tiedossa, niitä voi verrata todelliseen käyttöön.
➠ Siinä vaiheessa löytyy yleensä myös ensimmäinen asia, johon kannattaa puuttua.
➠ Joskus se on hyvin pieni asia. Esimerkiksi käyttämätön testiympäristö.
➠ Toisinaan kyse on isommasta arkkitehtuuripäätöksestä, kuten siitä, miten data liikkuu palveluiden välillä.
➠ Oleellista on, ettei kaikkea yritetä korjata kerralla.
Hyvä optimointi ei tarkoita halvinta mahdollista AWS-ympäristöä
Yrityksen AWS-ympäristö ei ole onnistunut vain siksi, että kuukausilasku on pieni.
Jos säästö saavutetaan heikentämällä saatavuutta, hidastamalla sovellusta tai vaikeuttamalla ylläpitoa, kyse ei välttämättä ole hyvästä optimoinnista.
Parempi tavoite on löytää tasapaino.
Palvelun pitäisi maksaa sen verran kuin sen liiketoiminnallinen tarkoitus vaatii, mutta ei enempää.
Jos tuotantopalvelu tarvitsee jatkuvasti tietyn kapasiteetin, siitä kannattaa maksaa.
Jos kehitysympäristöä tarvitaan vain arkipäivisin, sen ei välttämättä tarvitse olla käynnissä ympäri vuorokauden.
Jos vanhaa dataa tarvitaan harvoin, sen säilytystapaa voi ehkä muuttaa.
Jos lokia syntyy enemmän kuin kukaan käyttää, sen määrää voi vähentää.
Nämä ovat paljon järkevämpiä säästökohteita kuin se, että yritetään vain leikata kaikkea tasaisesti.
Lopuksi
- AWS-kulujen kasvu harvoin johtuu yhdestä väärästä päätöksestä.
- Useammin ympäristö kasvaa vähitellen ja kustannukset kasvavat sen mukana. Jokainen uusi resurssi näyttää aluksi pieneltä kululta. Vasta myöhemmin kokonaisuus alkaa näkyä.
- Siksi AWS-kustannusten optimointi kannattaa nähdä jatkuvana teknisenä työnä, ei pelkkänä laskun pienentämisenä.
- Ensin pitää tietää, mitä käytetään.
- Sen jälkeen pitää ymmärtää, miksi sitä käytetään.
- Vasta sitten voidaan päättää, mistä kannattaa säästää.
- Hyvä optimointi ei riko toimivaa järjestelmää. Se poistaa turhaa kapasiteettia, turhaa dataa, turhaa liikennettä ja turhaa tekemistä tavalla, joka ei vaikeuta sovelluksen normaalia toimintaa.
- Juuri siinä kohtaa pilvikustannusten hallinnasta tulee osa hyvää ohjelmistoarkkitehtuuria eikä vain kuukausittaisen AWS-laskun tarkistamista.