Eesti keeles on nüüdseks kirjutatud palju artikleid sellest, milliseid pilvetehnoloogiaid on olemas, milliseid eeliseid nad klientidele annavad ja kuidas neid rakendada. Käesoleva kirjatükiga teeme läbi ühe konkreetse ja tehnilise päriselu-teekonna idee sünnist teostuseni Microsoft Azure’i pilvekeskkonnas.

Artikli autor Mark Slavin töötab ettevõttes Solita  andmeinsenerina 2019. aastast ning on spetsialiseerunud pilvepõhistele andmeplatvormidele. IT-sfääri töökogemust on tänaseks kogunenud üle 20 aasta ja seda erinevates valdkondades – arendus, arhitektuur, koolitamine. Palju huvitavaid projekte on tehtud nii Eestis kui ka välismaal. 

Algus

Digiriigi Häkatonil, mis toimus 2019. aasta sügisel, käsitleti ühena teemadest, millega tegeles Solita, kultuurisõnumite edastamist Androidi operatsioonisüsteemiga televiisoritesse läbi ERR äpi.

Paralleelselt käis Siseministeeriumi infotehnoloogia- ja arenduskeskus (SMIT) välja sarnase vajaduse edastada häiresõnumeid süsteemist SITREP (Situation Reporting) mobiilirakendusse “Ole valmis!”. Rakenduse mõte on hoiatada kasutajat tema lähiümbruses juhtunud õnnetusest või ilmastikuolude halvenemisest, mis nõuavad suuremat tähelepanelikkust (näiteks kurikuulus lumetorm Padaorus, või rannikuala üleujutus).

Kokkuvõttes – kuna muster oli sama, siis tundus mõistlik luua ühtne lahendus.

Probleemistik ja eesmärgid

SITREPil puudus avalik liides sõnumite küsimiseks, kuid oli funktsionaalsus sõnumite väljasaatmiseks. Seega oli küll võimalik liidestada süsteem otse “Ole Valmis!” rakenduse back-endiga, aga häkatoni käigus kujunesid välja järgmised eesmärgid, mis viisid eraldiseisva pilvepõhise süsteemi väljakujunemiseni.

• Sõnumite edastamine (push ja pull) paralleelselt mitmesse kanalisse, olgu tarbija parajasti kes iganes.
• Sõnumite vahendamise funktsionaalsus on SITREPist eraldi.
• Liides peab olema turvaline, et pahatahtlik tegutseja ei saaks saata valehäireid.
• Administreerimine peab olema lihtne.
• Sõnumeid peab saama tellida/kategoriseerida nii teema kui asukoha alusel.
• Süsteemi püstipanek on kiire ja lihtne.
• Süsteem on paindlik ja odav ülal pidada.
• Arenduseks on aega kokku paar inimtöökuud.

Miks just Microsoft Azure?

Solita osales häkatonil koostöös Microsoftiga, seetõttu saigi valitud pilvekeskkonnaks Azure – kuigi sarnaseid lahendusi saaks luua ka näiteks AWSi või Google vahenditega. Azure annab ka otseselt mõningaid eeliseid.

• Suuremat osa komponentidest on võimalik Active Directoryga hõlpsasti integreerida (kuigi Active Directory ei olnud esimeses iteratsioonis eesmärk omaette, oli see üks argument, millega tulevikus arvestada).
• Teenusevalik (teisisõnu – valmiva süsteemi “ehitusklotside” arsenal) on tõeliselt muljetavaldav ja sisaldab ka eksklusiivseid komponente – järgnevalt peatume neist mõnel ka lähemalt.

Näiteks API Management on lihtsustatult öelduna skaleeruv API-gateway-teenus ning suure boonusena sisaldab endas avalikku veebiliidest (Developer Portal), mis on mugav nii kasutajale kui ka administraatorile. Lisaks saab liidest ka oma vajaduste järgi ümber kujundada. Peamine väärtus tulenebki kasutuslihtsusest – registreerumiseks, sõnumite saatmiseks/vastuvõtmiseks, lõppsihtpunkti määramiseks, muundamisreeglite kirjeldamiseks ei pea omama kuigi palju Azure-spetsiifilisi teadmisi.

Developer Portal pakub arendajatele juba valmiskirjutatud koodinäidiseid sõnumite tarbimiseks (esindatud näiteks cURL, C# ja Python). Lisaks muidugi ka sisseehitatud tulemüür, säilenõtkus ja vastupidavus DDoS-tüüpi rünnakutele. Kõige eelmainituga kaasneb märkimisväärne aja (ja ka raha!) kokkuhoid nii kasutaja, administraatori kui ka arendaja vaatevinklist.

Taristu loomeprotsess

Arhitekti vaates oli eesmärgiks luua süsteem, mis põhineks võimalikult standardsetel (Azure’i enda pakutud) koostisosadel, ja mille paigaldus oleks jõukohane igaühele, kellel on baasteadmised pilve tööpõhimõttest. Arvestama pidi ka asjaoluga, et lõplikud nõuded olid samuti alles kujunemisjärgus.

Algusest peale tuginesime IaC (infrastructure as code) põhimõttele – kogu lahenduse taristu pilves on üheselt kirjeldatud inim- ja masinloetava koodina. Lisaks paigaldusprotsess oleks inkrementaalne (kui tekib uus versioon, siis olemasolevat infrastruktuuri ei kustutata ilma vajaduseta), konfigureeritav ja automatiseeritav; kood oleks võimalikult arusaadav ja muudetav. Piltlikult öeldes – vajutad “deploy” ja ei olegi eriti muud vaja.

Kõike eelmainitut võimaldab tööriist nimega Terraform, mis on üsna levinud eeskätt nende seas, kes taristuid administreerivad – et mitte öelda, de-facto standard just nimelt pilvetaristute jaoks. See on ettevõtte HashiCorp toodetud tasuta vahend, mis sobib suurepäraselt just sellisteks olukordadeks – inimene kirjeldab koodina ära, milliseid ressursse tal vaja on, ja Terraform tõlgendab koodi (pilve)keskkonnale arusaadavateks käsklusteks nende tekitamiseks, muutmiseks või kustutamiseks.

Terraformil on järgnevad tugevused, mis said otsustavaks:

• levik ja lai platvormitugi,
• võimekus „meeles pidada“ paigaldatud taristu seisu (state),
• lihtne, ent võimalusterohke HCL-keel, millega saab ka keerulisemat loogikat kirjeldada.

Ametlikult Microsofti toetatud variant sama saavutamiseks on ARM mallid (ARM template – sisuliselt kindla struktuuriga staatiline JSON või YAML). Terve Azure’i taristu saab ära kirjeldada, tuginedes puhtalt ARM mallidele, kuid siis tekib rohkem koodi ja võimalused paigaldusloogikat suunata vähenevad tunduvalt.

Muutuvad nõuded ja valikud

Esimene asi, mille kallal töö jätkus, oli sõnumihoidla tekitamine (pull ja debuggingu jaoks).

Algne arusaam sõnumiformaadist oli üsna lihtne:

• ühetasandiline JSON,
• paar kohustuslikku atribuuti (ajatempel, autor jne),
• ülejäänud täiesti vaba ja kirjeldamata.

Lähtuvalt ülalolevast ning põhimõttelisest otsusest kasutada ainult Microsoft Azure komponente + paigaldada kogu lahendus ühe käsuga, oli laual kaks varianti, millega talletada ja kust lugeda JSON andmeid ilma kindlaksmääratud skeemita:

• Table Storage (algne valik; kuigi on tööpõhimõttelt pigem key/attribute tüüpi teenus),
• Cosmos DB.

Table Storage kasuks rääkis võimalus pärida andmeid HTTP päringuga (vähem arendustööd) ning madalam hind (prototüübifaasis eriti oluline), Cosmos DB eeliseks oli säilenõtkus, kuna talletab andmeid mitmes regioonis. Olukorda muutis aga asjaolu, et SITREPist tulid sõnumid mitmetasandilise JSONina, ja osa kriitilise tähtsusega atribuutides olid “sügavamal” tasandil. Seega, Table Storage ei vastanud enam uuele nõudele ja tuli kasutusele võtta hoopis Cosmos DB komponent.

Lisaks tekkis reaalne võimalus, et süsteem oleks kasutuses ka muus kontekstis kui häiresõnumid – tuli arvestada, et süsteemi kaudu edastatakse praktiliselt ükskõik milliseid sõnumeid paljudelt saatjatelt eri kanalitesse eri kombinatsioonides. Sisuliselt sai eesmärgiks luua sõnumivahendusplatvorm (Message Service Provider), mis funktsionaalsuselt meenutaks näiteks Twilio või MessageBirdi toodangut.

Mitte ühtegi rida “päris” koodi

Niisiis, käesolevaks hetkeks oli arhitektuuriliselt paigas järgnev:

• kõik sissetulevad sõnumid ja päringud liiguvad läbi API Management’i,
• kõik sõnumid talletatakse Cosmos DB baasi.

Paralleelselt toimus mõttetegevus ka ümber küsimuse – kuidas sõnumid API Management’i kaudu sihtpunktidesse push’itakse? Ning milline komponent täpsemalt tegeleb sõnumite ja sihtpunktaadressite baasi salvestamisega?

Microsoft Azure pakub valikuid pea igaks stsenaariumiks – alustades virtuaalmasinasse paigutatud rakendusest lõpetades nn serverless komponendiga Azure Function. Samuti saab kasutada tervet rida vahepealseid variante (Docker, Kubernetes, Web App), kus kasutajal võib olla otsene ligipääs rakendust majutavale serverile ja võib ka puududa.

Käesoleva lahenduse kontekstis kõik eelmainitud lahendused oleks tähendanud järgnevat:

• süsteemi loomiseks oleks olnud vaja appi arendaja taustaga inimest,
• süsteemi tervikuna ei oleks enam saanud paigaldada kuigi lihtsalt – rakenduse kood oleks olnud eraldi taristu koodist.

Õnneks on Azure’il välja pakkuda tehnoloogia Logic App, mille abil leidsid ülalolevad punktid lahenduse. Tegemist on viisiga, kuidas kirjeldada äriloogikat voodiagrammina – näiteks saab Azure Portali kaudu veebiliideses Logic App’i “rakenduse” visuaalselt “valmis joonistada”. Tõsi, keerukamatel juhtudel – näiteks muundamisoperatsioonide puhul – tuleb ilmselt rida-paar kirjutada, kuid see on kaugel traditsioonilisest programmeerimisest. Pigem sarnaneb Logic App’i koodi kirjutamine Exceli makrode kui Pythoni või Java arendustööga.

Logic App’i voo koodi on võimalik salvestada ARM malli kujule, ja ARM malli omakorda saab kasutada Terraformi paigaldusskripti osana – seetõttu sobis Logic App käesolevasse konteksti suurepäraselt. Ühe töövoo käivitus antud lahenduses maksab suurusjärgus 0,0005 eurot kord (tarbimispõhise plaani järgi) – jah, on odavamaidki lahendusi nagu Azure Function, kuid sel juhul on vaja taristust eraldi paigaldamist ja eraldi arendamist.

Tugikomponendid

Süsteemi töö jälgimiseks on Azure’il hästi läbimõeldud instrumendid, antud juhul keskendume kahele : Azure Monitor ja Log Analytics. Esimene neist, nagu nimigi ütleb, on Azure’i platvormi pakutav kogum dashboard’e, mis aitavad jälgida (ka reaalajas) rakenduste ja komponentide seisundit – näiteks koormust, mälukasutust, ning kasutaja defineeritud mõõdikuid.

Kuna Monitor on vaikimisi nii ehk naa igal lahendusel “kaasas”, siis ehk ei olegi teda päris korrektne käsitleda eraldi komponendina – küsimus on puhtalt kuvatavates mõõdikutes. Log Analytics seevastu on koht, kuhu suunata kõikide komponentide logid, et neid hiljem mugavalt analüüsida ja nende pealt päringuid teostada. See aitab tuvastada tõrkeid süsteemi töös ning jõuda kiiresti vea jälile. Log Analyticsilt saab pärida isegi mõõdikuid, mida hiljem Monitoris kuvada, näiteks vigade arv ööpäevas.

Tulemused ja tähelepanekud

Kokkuvõttes tuli lahenduse arhitektuur järgmine.

Laias laastus õnnestus alguses kirja pandud eesmärgid saavutada ning ka põhimõtteid järgida (IaC, ainult Azure’i komponendid jt). Selge on, et Microsoft Azure pakub tõeliselt laia teenustepaketti, millel on tüüpiliselt 99,95-99,99% SLA; aga pole harvad ka juhud, kus räägitakse “seitsmest üheksast” (99,99999%). Nii kõrge protsent saavutatakse komponentide ja andmete dubleerimisega, optimeeritud riistvarakasutusega ning erakordselt rangete turvameetmetega regiooni andmekeskustes.

Süsteemi paigaldus nullist Azure’i kontole võtab aega 45-60 minutit ning lõviosa sellest moodustab API Management’i provisioneerimine – tegemist on mingis mõttes Microsoft Azure’i raskekaallasega, kus kasutaja eest on ära peidetud rida komponente (tulemüür, veebiserver, koormusjaotur jt). 

Takistusi ei ilmnenud, kuid arenduse käigus selgus, et Terraform kui kolmanda osapoole vahend jääb Microsoft Azure’ist paari sammu võrra maha – teisisõnu, kui Microsoft loob Azure’i uue teenuse, läheb HashiCorpi arendajatel aega, et lisada vastav funktsionaalsus oma moodulisse. Sel juhul saab näiteks uut komponenti puudutava ARM malli osaliselt pookida Terraformi skriptidesse, nii et taristu loomist saab igal juhul automatiseerida.

Kokkuvõtteks

Avaliku pilveteenuste pakkujatel nagu Microsoft Azure, on sadu erinevaid teenuseid, mida võib käsitleda Lego klotsidena – teenuste kombineerimisel on võimalik luua just selline lahendus, mis täidab vajadusi kõige paremini.

Artiklis on kirjeldatud, kuidas loodi nullist MSP-laadne toode, mis on tänaseks jõudnud prelive’i. Sama toodet on võimalik kokku panna ka teistsugustest komponentidest – kõik sõltub täpsetest vajadustest ja võimalustest kaasata teisi kompetentse, näiteks C# või Java arendaja oma. Avalik pilv on mitmekülgne, turvaline, taskukohane ja aina arenev – on väga vähe põhjuseid, miks mitte selle võimalusi ära kasutada.

Täname: Janek Rozov (SMIT), Timmo Tammemäe (SMIT), Märt Reose (SMIT), Kristjan Kolbre (Ole valmis!), Madis Alesmaa (Ole valmis!), Elisa Jakson (Naiskodukaitse/Ole valmis!), Henrik Veenpere (Päästeamet).