Pilviseikkailu 2010

Eilen keskiviikkona Codenton aamiaistapahtuman aiheena oli sisäinen pilvi. Puhujina oli toimitusjohtaja Mårten Mickos Eucalyptus Systemsiltä, joka kertoi miten sisäinen pilvi tehdään, ja teknologiajohtaja Santeri Kangas F-Securelta, joka kertoi miksi (sisäinen) pilvi halutaan. Lisäksi oma väki piti pienet alku- ja loppusanat.

Eucalyptuksen mahdollisuudet

Mårten käsitteli melko laveasti ja pintapuolisesti Eucalyptuksen toimintakenttää ja tuotteen mahdollisuuksia. Läpi käytiin sisäisen pilven tarkoitus, syyt pilven käytön puolesta, sitä vastaan, SaaS/PaaS/IaaS-pinojen erilaisuus eri historiallisista lähteistä johtuen jne. Ja tietysti miksi Eucalyptus on paras ratkaisu privaattipilveen: hyvä elastisuus, avoin koodi, standardi-API, hypervisor-riippumattomuus, konffattavuus.

Kiinnostavimpina asioina pisti korvaan perustelut sille miksi Eucalyptus käyttää AWS:n kontrollirajapintoja. Sen lisäksi, että ne ovat hyvin suunniteltuja ja toimivia, on oleellista, että ne ovat Eucalyptuksessa ja AWS:ssa samat. Näin helpotetaan hybridipilven pystyttämistä, jossa peruskuorman tuottaa oma privaattipilvi, ja ylikuorman syntyessä se tuotetaan Amazonilla. Tällaisia hybridipilviä ei vielä kauheasti maailmalla tunneta, mutta niiden mahdollisuudet kustannusten säästössä ovat siinä määrin ilmeiset, että tilanne korjaantunee nopeasti itsestään.

Sivulauseessa julkistui myös Codenton uusi Eucalyptus Silver Partner -status.

Kustannussäästöä pilvestä – pitkällä aikavälillä

Mickos on tunnettu MySQL:sta, eikä nytkään pystynyt täysin välttämään kyselysession aikana menneisyyttään. Nykypositionsa kanssa virtaviivaisesti hän on kuitenkin sitä mieltä, että NoSQL-ratkaisut ovat pilvessä nousussa. SQL kuitenkaan ei katoa maailmasta minnekään. Ihmiset haluavat yksinkertaisen ja tutun järjestelmän, ja SQL on sitä niille, jotka sen jatkuvuudesta pääsevät päättämään. Perinteisten SQL-ratkaisuiden keskittyminen vertikaaliseen skaalautuvuuteen on kuitenkin pilvimallin horisontaalisen skaalautuvuuden painottamisen kanssa ristiriidassa.

Hintaetua Mårten ei sinänsä painottanut liiaksi, ja itse asiassa korosti että tärkein syy pilven käyttöön on elastisuus. Hintasäästöt ovat mahdollisia pitkällä aikavälillä, mutta koska kyseessä on rakennemuutos, alussa on tiedossa jopa ylimääräisiä kustannuksia, ja tämä on hyvä ymmärtää jo ennen kuin tekee mitään.

Haittaohjelmia tunnistettava jatkuvasti

Kangas kertoi, kuinka F-Secure on ajan kanssa muuttunut tuotetalosta enemmän palvelutaloksi, ja tämän muutoksen loogisena osana on ollut pilvimäisemmän toimintamallin synty. Santeri esitteli numeroina F-Securen palveluissa kokonaisuutena liikkuvia datamääriä, ja ne ovat suuria. Malwaren määrä on kasvanut räjähdysmäisesti, ja kun myös pahoja saitteja tunnistetaan surffatessa, tarvittava tunnistus on jatkuvaa. Nykyisellään erilaista hyökkäyskoodia on niin paljon, ja sitä tulee uutta niin nopeasti, ettei ole mahdollista säilöä tarvittavaa kokonaisälyä asiakkaan koneelle. Niinpä asiakasohjelma toimii yhdessä taustajärjestelmien kanssa tarjoten reaaliaikaista turvaa.

Aamiaistilaisuuden esitykset videoitiin, ja ne tulevat levitykseen, kun ne on saatu editoitua.

Seuraavan aamiaistilaisuuden ajankohdan kerromme myöhemmin, mutta arviolta se olisi tammi-helmikuussa 2011. Tiedon tulevasta tapahtumasta saat suoraan sähköpostiisi liittymällä tiedotuslistallemme. Voit myös seurata Codenton Facebook-ryhmää tai Twitteriä.

Tämän artikkelin on kirjoittanut Teemu Kalvas ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.

Google keittää kahvia

Olen viime aikoina tutustunut Googlen uuteen datatyökaluun Percolatoriin. Se onkin erikoinen kone, vahvasti C-luokkaa.

Mennään ajassa kuusi vuotta taaksepäin. Google julkaisee MapReduce-laskentamallin ja kertoo toteuttaneensa indeksointijärjestelmänsä sen päälle. Sen lisäksi M/R luikertelee osaksi lähes jokaista Googlen merkittävää tuotetta. Googleplexin ulkopuolella MapReduce todetaan skaalautuvuudeltaan hyväksi ja avoimen lähdekoodin mullasta ponnistaa Hadoop — MapReduce meille muille.

Nyt kuitenkin syyskuussa 2010 Google paljastaa, että heidän uusi indeksointijärjestelmänsä ei enää käytäkään MapReducea vaan upouutta Percolator-nimistä järjestelmää. Mitä ihmettä? Onko taivas pudonnut? Onko MapReduce out ja Percolator in?

Vastaus ei ole aivan yksinkertainen. Lainaan Ricky Ho:lta analyysiä siitä, milloin Hadoopia/MapReducea ei kannata käyttää:

  • Perform online data access where low latency is critical
  • Perform random ad/hoc processing of a small subset of data within a large data set
  • Perform real-time, stream-based processing where data is arrived continuously and immediate processing is needed.

Googlen hakurobotit päivittävät vuorokauden aikana noin 5-10% kaikista varastoiduista sivuista. Tietoa tulee jatkuvasti pienissä erissä robottien kulkiessa webin halki. Ja olisihan oikein mukavaa, että sivujen muutokset näkyisivät hakukoneessa heti eivätkä vaikkapa viikon päästä.

MapReduce, vaikka onki hyvä työkalu moneen dataintensiiviseen ongelmaan, ei erityisen hyvin sovi alkuperäiseen käyttötarkoitukseensa. Edes Googlella ei ole käytössään kristallipalloa.

Vaan asiaan. Google julkaisi kuun alussa kuvauksen uudesta järjestelmästään. Itse paperi on kirjoitettu hyvin tiiviiseen tyyliin, mutta sen salaisuudet aukesivat muutaman tunnin työllä. Registerin ja InfoQ:n tiivistelmät voivat mahdollisesti avittaa sunnuntaitiedemiestä.

Hyvin tiivistettynä Percolatorissa on kolme mielenkiintoista ratkaisua.

  • Indeksin konsistenssin säilyttämiseksi Bigtable-tietokannan päälle rakennettiin useamman rivin kattavat transaktiot
  • Datan ohjailua varten lisättiin ns. observerit, jotka käynnistävät (laiskasti) laskennan seuraavan vaiheen syöterivien muuttuessa.
  • Lukko- ja aikaleimapalvelut, joiden avulla edelliset pysyvät ruodussa.

Percolator tuo hieman järjestystä Bigtablen anarkiaan ja ottaa askeleen perinteisempien tietokantojen suuntaan. Ironisesti Googlen insinöörien oli tarkoitus lisätä Bigtableen laajempi transaktiotuki, mutta se jätettiin pois tarpeettomana.

Suorituskyvyltään Percolatorin päälle tehty indeksointijärjestelmä (koodinimeltään Caffeine) on MapReduce-serkkuaan huonompi. Se pystyy kuitenkin käsittelemään sivut heti, kun ne tulevat hakuroboteilta ja saa yksittäisen sivun putken läpi noin 100 kertaa nopeammin kuin M/R-pohjainen indeksoija. Tämä merkittävä latenssiero selittyy kahdella tekijällä. Ensiksikin Percolatorin ei tarvitse käsitellä koko sivuvarastoa kerralla. Toisekseen MapReducessa laskentavaihe ei voi alkaa ennen edellisen päättymistä. Vanhemmassa järjestelmässä oli 100 perättäistä vaihetta, jolloin yksittäiset viiveet alkoivat kasautua. Fillarilla pääsee autoa nopeammin, jos auto jää jumittamaan jokaiseen liikennevaloon.

Percolator on myös vähentänyt liikkuvien osien määrää. Sadan MapReduce-askeleen sijaan Caffeine tarvitsee vain 10 observeria. Yksittäinen Percolator-kone on myös vaadittavien softakomponenttien osalta kohtalaisen yksinkertainen, mikä helpottaa ylläpitoa.

Veikkaan, että tämä toteutuksellinen yksinkertaisuus johtaa Percolatorin ideoiden leviämiseen. MapReducen laskentamalli on teoreettisesti miellyttävä. Worse is Better -filosofian mukaan kuitenkin Percolatorin observerit ja multirow locking löytävät tiensä Hadooppiin ja moneen muuhun työkaluun. Tämä siitä huolimatta, että mikään ei estä käsistään kätevää koodaajaa luomasta vaikkapa kolmen prosessointivaiheen silmukkaa…

Mikään “MapReducen tappaja” Percolator ei ole. Kummallakin on omat ekologiset lokeronsa, joihin ne sopivat mainioisti. Kirjoittajat toteavat jo paperin etusivulla, että Percolatoria ennen tulisi harkita tavanomaisia tietokantoja, Bigtablea tai MapReducea. (Vaihda näiden tilalle oma vapaa tai kaupallinen suosikkisi, jos et ole Googlella töissä.) Ihan heti en suosittele oman kahvinkeittimen rakentamista. Vapaita vaihtoehtoja ilmestynee nopeasti ja kunkin työkalun vahvuudet paljastuvat ajallaan.

Tämän artikkelin on kirjoittanut Antti Rasinen ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.

Mikä kannattaa suunnitella, kannattaa ylisuunnitella

Tänä tehokkuuden ihannoinnin aikakautena yleisenä totuutena pidetään, ettei mitään tehtävää pidä hieroa liian pitkään. Pitää olla selkeä näkemys siitä, milloin homma on valmis, ja silmät avoinna niin että havaitaan kun tila on saavutettu.

Ajatusmallissa on kaksi vikaa. Toinen on yksinkertainen ja selkeä, toinen vähän filosofisempi ja hankalahko.

Ensimmäinen on tietysti se, että osaava tekijä tietää kaikessa tekemisessä olevan aina läsnä virhemarginaalin. Tämä pätee myös valmiusasteeseen. Jos virhettä ei huomioida ja lopetetaan tehtävä 100,0% valmiusasteeseen, saattaa pienelläkin toleranssilla tosiasia olla, että ollaan vielä epsilonin päässä todellisesta valmiudesta. Tärkeissä tehtävissä pienikin puute voi osoittautua epämiellyttäväksi, kalliiksi tai ammatillista ylpeyttä rapauttavaksi.

Valmius ei tietenkään ole lineaarinen suure niin kuin jokin rakennuksen kuormituskestävyys (ei ole sekään, mutta siitä lisää alempana). Vaikka olisi mittaustuloksia valmiusarvion virhemarginaalista, ei millään ylivalmiiksi tekemisellä voida varmistaa todellista valmiutta. Ainoastaan pahojen kämmien todennäköisyyttä voidaan reilusti laskea.

Toinen tehokkuusajattelun ongelma liittyy osaamisen perusteisiin.

Asiantuntijatehtävissä pääsääntöisesti ei tehdä isompia kokonaisuuksia, jotka ovat vanhan toistoa. Helpossa projektissa kaikki projektin pienet osat voivat olla entuudestaan tuttuja, mutta kokonaisuutena projekti on ainutkertainen. Hankalammassa projektissa tyypillisesti on yksi tai kaksi kokonaan uutta yksityiskohtaakin (jos niitä on enemmän, projekti epäonnistuu).

Tämä on sekä se, miksi asiantuntijat tekevät töitä (uuden oppiminen on asiantuntijatyypin mielestä miellyttävää), että toimenkuvan epävarmuuden ja sitä kautta epävarmuuden hallintaan käytettävien vaatimusten suurin aiheuttaja.

Tärkein epävarmuuden hallinnan väline on tietysti se asiantuntemus. Koska ei kuitenkaan toisteta aina samaa työsuoritetta, tarvitaan laaja-alaista ymmärrystä ei pelkästään siitä, mitä tehdään, vaan myös siitä, mitä ei tehdä, ainakin siltä osalta, kun ollaan tekemisen rajan välittömässä läheisyydessä.

Yleensä on koko joukko ratkaisuja, joita ei annettuun ongelmaan kannata käyttää. Mistä tieto kannattamattomuudesta tulee? Se tulee siitä, että on kokeillut ja todennut, ettei kannattanut.

Konsulttibisneksessä asiakasprojekteissa ei kannata kauheasti aikaa käyttää näihin kokeiluihin, ellei asiakas täydessä ymmärryksessä osta juuri tällaista kokeilua. Meillä onneksemme on asiakkaita, jotka ovat sen verran valveutuneita asiantuntemuksen olemuksesta, että ovat joskus ostaneetkin.

Jos näitä kokeiluja ei voi tehdä laskutettavana työnä, ne on tehtävä sitten jollakin muulla momentilla. Usein IT-nörtit tekevätkin vapaa-ajan projekteinaan todella omituisia asioita. Pohjimmiltaan niissä on kyse juuri tästä tuntemattomalla alueella tekemisestä. Eräs IT-alan yritys, jonka jätän tässä nimeämättä, voimakkaasti rohkaisi työntekijöitään osallistumasta mihinkään vapaasoftaprojekteihin. Minusta tämä oli pahinta oman jalkansa sahaamista, mitä olen alalla ikinä nähnyt.

Mutta miten se ylisuunnittelu tähän liittyy?

Oikean ja väärän rajan luotaaminen väärää kokeilemalla tulee halvimmaksi suunnitteluvaiheessa tehtynä.

Turhaan koodatun koodin pois heittäminen tuntuu ikävältä. Turhaan piirretyn arkkitehtuuridiagrammin hävittäminen ei ole yhtä emotionaalisesti latautunutta. Joidenkin ohjelmoijien on todella hankala hävittää kirjoittamaansa koodia, ja lopputuloksen näkee kun lukee suuria järjestelmiä.

Joitakin asioita pitää suunnitella, vaikka ne ovat tyhmiä. Vain tällä tavalla voi oikeasti ymmärtää miksi ne ovat tyhmiä.

Kesällä harjoittelin tätä tekemällä ohjelmointikielen kielioppia, jossa tavoitteena oli tehdä C:stä derivoituva kielioppi modernille oliokielelle. Kieliopin rakentamisen monet konfliktit ja niiden ratkaisuyritykset kertoivat emotionaalisella tasolla, miksi Scala on tehnyt selkeän pesäeron Javaan ulkoisessa syntaksissa, vaikka sisuskaluissa onkin paljon samaa. Pääasiallinen eroavaisuushan on tyyppien siirto loppuun, kun Javassa ne ovat alussa. Tyyppien alussaolo deklaraatioissa ymmärrettiin kieliopin ongelmaksi jo 70-luvulla, mutta yllättävän sitkeästi siitä on pidetty kiinni. Mitä monimutkaisemmiksi kieliopit menevät, sitä voimakkaammin tämän vääryyden tuntee, kun tekee mitään syntaksia tiedostavaa työtä, oli se sitten kääntäjä tai editorilaajennus.

En myöskään tietäisi, miksi ristikkopalkkirakenteita ei yleensä tehdä puusta, jos en olisi suunnitellut sellaista. Rakennusnosturissa rakenteena on teräksinen ristikkopalkki. Lyhyissä silloissakin käytettiin aikanaan paljon teräksistä ristikkopalkkia, erityisesti rautatiellä.

No, ajattelin että puurakenteisen talon vaakasuorat kantavat rakenteet ovat turhan materiaalia tuhlailevia, kun tyypillisesti käytetään joko umpinaisia liimapuupalkkeja tai laudoista ja vanerista liimattuja I-palkkeja. Suunnittelin nopeasti ristikkopalkkirakenteen, jonka lisäetuna olisi, ettei sitä tarvitse tehdä talon mittaisesta tavarasta vaan lyhyempikin riittää. Sain puuosatkin laskettua ja olin jo liitoksen kimpussa, kun huomasin että puolet vino-osista on vedossa, ja vetoa siirtävän liitoksen tekeminen puuhun niin että liitos olisi lähellekään niin luja kuin itse osa on lievästi ilmaistuna mahdotonta.

Nyt ymmärrän, miksi niin ei tehdä. Aikaisemmin tiesin vain, että niin ei tehdä. Tämä on se, mitä onnistuneesta ylisuunnittelutapahtumasta tulee ulos.

Tämän artikkelin on kirjoittanut Teemu Kalvas ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.