Uudised, sündmused ja blogi

Belgia domeeniregistri elu pilves

2017 aasta alguses sai Belgia registrist tõeline innovaator. Nad tegid ära selle, millest nii mõnigi register unistas, mitmed kaalusid ja enamus kartis - nad lülitasid välja oma “viimase” füüsilise serveri ja sellest hetkest alates on kogu registrisüsteem “jooksnud” täielikult “pilves”. See oli julge otsus ka tugeva vastuseisuga organisatsioonis sees, kuid aasta hiljem julges nende juht öelda, et tänaseks pole ettevõttes kedagi, kes arvaks, et see oli vale otsus. Kõik on läinud paremaks.

Belgia sammudest olen siin erinevates kirjutistes ka varem ülevaadet andnud. Proovin välja tuua vaid uuemat teavet. Meeldetuletuseks siiski nii palju, et lahenduseks valisid belglased Amazoni AWSi ning kolimise otsuse taga oli hinnang oma enda ressursi väärtusele - kus peitub registri kompetents, milles on nemad kõige tugevamad ja kus saavad luua enim väärtust. Ühegi küsimuse vastuseks polnud riistvara administreerimine, vaid soov pakkuda parima registri teenust ja seega oli igati loogiline fokuseerida just sellele. Eesmärk ei olnud hoida kokku raha, vaid meeskonna aega võimaldades keskenduda olulisele. Muudatuse tulemusena meeskond ei kahanenud - vastupidi. Oldi valmis kulude suurenemisega ka süsteemi halduse kontekstis, kuid seda ei juhtunud ja on olemas ka reaalne rahaline sääst. Küll mitte väga suur, aga siiski.

Meeskond on keskendunud tarkvara parendamisele ja arendamisele, väga palju on juurde andnud automatiseerimine, mille jaoks enne lihtsalt ei olnud aega. Paranenud on süsteemi kiirus, töökindlus ja üllatus üllatus - ka turvalisus. Parema ülevaate saime ettevalmistustöödest, kuhu kokku investeeriti mitme inimtööaasta jagu aega umbes 6 liikmelise meeskonnaga ja seda olukorras, kus registritarkvara tegelikult ei muudetud - mindi peale täiesti pilve jaoks optimeerimata lahendusega. See ehmatas natuke - meil sellist ressurssi ju pole. Samas tõid nad rahustuseks ka kohe välja, et tegelikult ei ole enamus sellest tööst hädavajalik - nemad olid esimesed ja seega võtsid teema enda jaoks viimse pulgani lahti. Kui kasutada rohkem kõrgema taseme pilve pakkuja teenuseid - AWSi puhul näiteks Beanstalk, ECS, Auto Scaling, … Alustada basic CloudFormation skriptidega täielikult parametriseeritute asemel. Osa serverite seadistamist võib jätta esialgu käsitööks, Ansible/Puppet lahendust kasutada enim muutuvate keskkondade jaoks jne. Ettevalmistust jääb siiski oma jagu järgi, aga seda saab Belgia näitega võrreldes kordades vähendada. Amazon oleks nende kindel valik ka täna - nad ei näe võimekuse ja võimaluste poolest alternatiivi. Isegi Google ja Microsoft on oma arengus väga palju maas, väiksematest tegijatest rääkimata. Oleme viimaseni ka ise jõudnud vaadates ringi ja tutvudes muuhulgas ka meie riigipilve lahendusega.

Ka automatiseeritud konfiguratsiooni halduseta on belglaste arvates pilv parim valik meie suguse väikese registri jaoks. Registri teenusekvaliteet paraneb, säästab tehnilise meeskonna aega, mida saab siis kasutada täiendavalt kvaliteedi ja turvalisuse parandamise peale.

Mõned huvitavad numbrid. Belgia AWSi lahendus koosneb 470 EC2 instantsist, 17TB kettaruumi, 60 loadbalanceri, 45 RDS andmebaasi mis kasutab 2,8TB salvesturuumi (Oracle, Postgres/Mysql/Mariadb).

Oma kodu päris riistvara vaba siiski pole - registriandmebaasist on koopia koguaeg olemas, pluss loomulikult tarkvarast endast. Laos hoitakse veel ka “serveripargi jäänuseid”, mida saab äärmisel juhul kasutada registrisüsteemi enda juures tööle panekuks kui koostöö Amazoniga peaks mingil põhjusel katkema.

Värskema muudatusena otsustati avada nn külm varuasukoht Amazoni Frankfurdi serveriruumides - baasi varukoopia jõuab sinna jooksvalt, ette on valmistatud väiksemamahulises seades registrisüsteem, mis ootab vajadusel sisse lülitamist kui midagi peaks Iirimaa asukohtadega juhtuma. Samas hädaolukorra juhend näeb ette Frankfurdi regioonis süsteemi käivitamise vaid juhul kui Iirimaa on maas enam kui 24h.

Tavapärastele pilvega seotud hirmudele nagu vendor lock in, andmeterviklikkuse ja andmelekete riskile mõeldes ja toetudes tänasele kogemusele, jõudsid belglased oma analüüsiga järeldusele, et ka vanas olukorras pidid nad usaldama kolmandaid osapooli - ettevõtteid, kelle serveriruume kasutati ning nende partnereid ja kliente, kellel oli ligipääs serveriruumidele, sideteenuse pakkujaid, elektrifirmasid, riistvara tarnijaid, tarkvara ettevõtted. Nüüd on usaldust vajavaid osapooli isegi vähem. Ka vendor lock in ehk ühest teenusepakkujast sõltumine pole uus teema, näiteks valides oma süsteemile andmebaasiks Oracle või PostgreSQLi ollakse täpselt samas olukorras, sellega tuleb arvestada, sest see pole tavaliselt mõistliku ressursikuluga välditav. Belglased rakendavad oma andmete kaitseks krüpteerimist nii palju kui võimalik nii ketastel kui “kaablis”. Oma Amazoni VPC (virtuaalne privaatne pilv) sees on siiski komponente, mille vahel info krüpteerimata liigub. Võtmete halduseks kasutavad Amazoni KMSi (võtme haldusteenust), mis aga tähendab, et Amazonil on olemas ligipääs nende privaatvõtmetele, kuid nad ei näe selles erilist probleemi, sest neil on hüperviisoritele ligipääs nii kui nii. Krüpteerimine on lisa kaitsekiht ootamatute nende enda või AWSi poolt põhjustatud turvariskide vastu, et kaitsta andmete sattumist teiste AWSi kasutajate kätte mitte aga kaitseks Amazoni eest. Andmeterviklikkuse riski kohapealt ei osanud nad näha oluliselt erinevat riski võrreldes eelneva olukorraga, kus nende serverid olid kellegi teise serveriruumis. Kõike logitakse, paigas on ACLid (ligipääsu nimekirjad), kasutajate turvagrupid, Amazon pakub vaikimisi audit trailsi kõigi APIde ja enamuse teenuste jaoks. Võib jälle öelda, et ülevaade toimuvast on parem kui varem.

Rääkisime ka võimalusest koostöö osas kui peaksime otsustama sarnase tee ette võtta. Detailid jäid veel paika panemata, sest meie poolset otsust ju pole, aga valmisolek nõu ja jõuga panustada on neil olemas.

Kokkuvõttes oli väga huvitav külaskäik. Minu nägemus pilve mõistlikkusest .ee kontekstis sai ainult kinnitust ja jääb üle loota, et kui GDPRi ja oksjonikeskkonna arendused seljataga, saame uuesti selle teema juurde ka oma meeskonnaga tagasi tulla ja ühte või teistpidi otsuse ära teha, et saaks edasisi tegevusi teadlikult planeerida.