Ettevõte «УРУС» on proovinud Kubernetes'e erinevates vormides: iseseisev juurutamine bare metal'i peale, Google Cloud'is ning seejärel kolis oma platvormi Mail.ru Cloud Solutions'i (MCS). Kuidas valiti uut pilvteenuse pakkujat ja kuidas õnnestus sellele migreeruda rekordilise kahe tunni jooksul räägib Igor Shishkin (), vanem süsteemiadministraator «УРУС».
Millega tegeleb «УРУС»
Linna keskkonna kvaliteedi parandamiseks on palju võimalusi, ja üks neist on muuta see ökoloogiliselt ohutuks. Just selle nimel töötavad ettevõttes «УРУС — Nutikad digiteenused». Siin rakendatakse lahendusi, mis aitavad ettevõtetel jälgida olulisi ökoloogilisi näitajaid ja vähendada keskkonnale negatiivset mõju. Sensorid koguvad andmeid õhu koostise, müra taseme ja muude parameetrite kohta ning saadavad need analüüsiks ja soovituste koostamiseks ühte platvormi «УРУС — Ekomon».
Kuidas on «УРУС» seestpoolt korraldatud
«URUS» tüüpiline klient on ettevõte, mis asub eluruumi või selle lähedal. See võib olla tehas, sadam, raudteede depoo või mõni muu objekt. Kui meie klient on juba saanud hoiatuse, saanud karistuse keskkonna saastamise eest või soovib ta ise müra vähendada ning kahjulike heitmete hulka vähendada, pöördub ta meie poole ning me pakume talle valmis lahendust keskkonnamonitorimiseks.
H2S kontsentratsiooni jälgimise graafikult on näha regulaarseid öiseid heitmeid läheduses asuvast ettevõttest.
«URUS» kasutatavad seadmed sisaldavad mitmeid sensoreid, mis koguvad teavet teatud gaaside sisalduse, mürataseme ning teiste andmete kohta, et hinnata keskkonnaolusid. Sensooride täpne arv määratakse alati konkreetse ülesande järgi.
Sõltuvalt mõõtmiste eripärast võivad sensoritega seadmed asuda hoonete seintel, postidel ja teistes juhuslikes kohtades. Iga seade kogub teavet, koondab selle ja saadab edasi andmete vastuvõtugateway'le. Seal salvestame andmed pikaajaliseks säilitamiseks ja töötleme need edasiseks analüüsiks. Lihtsaim näide sellest, mida me analüüsi tulemuseks saame, on õhukvaliteedi indeks ehk AQI.
Sama ajal töötab meie platvormil palju teisi teenuseid, kuid peamiselt on need teenindava iseloomuga. Näiteks saadab teavitusteenus klientidele teateid, kui mõni jälgitav parameeter (näiteks CO2 tase) ületab lubatud väärtust.
Kuidas me andmeid salvestame. Loo Kubernetesest bare metal-lahendusel
E-kommonitoringu projektis "URUS" on mitu andmehoidlat. Ühes hoiame "tooresid" andmeid – seda, mida oleme saanud otse seadmetelt. See hoidla on nagu "magneetiline" lint, nagu vanadel kassettidel, kõigi näitajate ajalugu. Teist tüüpi hoidlat kasutatakse eelnevalt töödeldud andmete jaoks – seadmetelt saadud andmed, mis on rikastatud metaandmetega sensorite seoste ja seadmete näitajate, kuuluvuse organisatsioonidele, asukohtade kohta jne. See teave võimaldab dünaamiliselt hinnata, kuidas on teatud näitaja aja jooksul muutunud. "Toores" andmehoidlat kasutame ka varukoopiana ja eelnevalt töödeldud andmete taastamiseks, kui sellest vajadus peaks tõusma.
Mõni aasta tagasi, kui otsisime lahendust salvestamise probleemile, oli meil valida kahe platvormi vahel: Kubernetes ja OpenStack. Kuna viimane näeb aga üsna koletu välja (vaadake lihtsalt tema arhitektuuri, et selles veenduda), valisime lõpuks Kubernetes'e. Teiseks argumendiks tema kasuks oli suhteliselt lihtne tarkvaraline haldamine ja võimalus paindlikumalt jaotada isegi füüsilisi node'ide ressursse.
Samas, kui õppisime Kubernetes'e, uurisime ka andmete salvestamise võimalusi. Kuigi hoidsime kõiki oma salvestusseadmeid Kubernetes'es oma riistvaral, saime suurepärase ekspertiisi. Kõik, mis meil siis oli, töötas just Kubernetes'es: stateful-salvestus, monitooringusüsteem, CI/CD. Kubernetes on saanud meie jaoks all-in-one platvormiks.
Kuid me soovisime töötada Kubernetes'ega teenusena, mitte tegeleda selle hooldamise ja arendamisega. Pluss, meile ei meeldinud, kui palju maksis selle hoidmine füüsilisel riistvaral, samas kui arendust oli meil pidevalt vaja! Näiteks üks esimesi ülesandeid oli integreerida Kubernetes'e Ingress-kontrollerid meie organisatsiooni võrgu infrastruktuuri. See on mahukas töö, eriti arvestades, et sel hetkel ei olnud valmis midagi, mis võimaldaks programmeerida ressursside, nagu DNS-kirjed või eraldamine, haldamist. IP-aadresse. Hiljem hakkasime katsetama välise andmesalvestuse kasutamist. PVC-kontrolleri implementeerimiseni me ei jõudnud, kuid juba siis oli selge, et see on suur töömaht, mille jaoks on vaja eraldi spetsialiste välja panna.
Üleminek Google Cloud Platformile on ajutine lahendus
Me olime mõistnud, et nii ei saa edasi minna, ja kolisime oma andmed bare metalilt Google Cloud Platformi. Tol ajal ei olnud Venemaa ettevõttena palju huvitavaid valikuid: peaaegu ainus sarnane teenus oli Amazon, kuid valisime ikkagi Google'i lahenduse. See tundus meile toona majanduslikult kasulikum, lähemal Upstreamile, rääkimata sellest, et Google on ise nagu PoC Kubernetes tootmises.
Esimene tõsine probleem ilmus silmapiirile koos meie kasvava kliendibaasiga. Kui meil tekkis vajadus isiklike andmete hoidmise järele, seisime valiku ees: kas töötame koos Google'iga ja rikume Venemaa seadusi või otsime alternatiivi Venemaalt. Valik oli üldiselt siiski etteennustatav. 🙂
Milline nägime ette ideaalse pilveteenuse
Otsingute alguseks teadsime juba, mida soovime tulevaselt pilveteenuse pakkujalt. Millist teenust me otsisime:
- Kiire ja paindlik. Nii, et saaksime igal ajal kiiresti juurde lisada uue nodo või midagi üles seada.
- Odav. Meie muretsesime finantsküsimuste pärast, kuna olime ressursside poolest piiratud. Me teadsime juba, et soovime töötada Kubernetesega, ja nüüd seisis ees ülesanne vähendada selle kulusid, et suurendada või vähemalt säilitada tõhusust selle lahenduse kasutamisel.
- Automatiseeritud. Me kavasime töötada teenusega läbi API, ilma juhtide ja telefonikõnede või olukordadeta, kus tuleb käsitsi käivitada mitukümmend nodi kiirusrežiimis. Kuna enamik meie protsesse on automatiseeritud, ootasime samasugust ka pilveteenuselt.
- Serveritega Venemaal. Loomulikult kavasime järgida Venemaa seadusandlust ja 152-FZ seadust.
Sel ajal oli Venemaal vähe Kubernetes teenusepakkujaid aaS mudelil, seetõttu oli meie prioriteetide järgimine pakkuja valimisel oluline. Mail.ru Cloud Solutions meeskond, kellega hakkasime töötama ja kellega koostööd teeme siiani, pakkus meile täielikult automatiseeritud teenust API toe ja mugava juhtpaneeliga, kus on Horizon — selle abil saime kiiresti käivitada suvalise arvu nodi.
Kuidas me suutsime kahe tunni jooksul MCS-ile migratsiooni teha
Sarnaste üleviimistega seisavad paljud ettevõtted silmitsi raskuste ja ebaõnnestumistega, kuid meie puhul neid ei olnud. Meil vedas: kuna töötasime juba Kubernetesel, muutsime lihtsalt kolme faili ja käivitasime oma teenused uuel pilveplatvormil MCS. Kordan, et tol ajal olime täielikult lahkunud bare metalist ja elasime Google Cloud Platformis. Seetõttu võttis üleviimine aega mitte rohkem kui kaks tundi, pluss veidi aega (umbes tund) andmete kopeerimiseks meie seadmetest. Siis kasutasime juba Spinnakerit (mitme pilve CD-teenus pideva kohaletoimetamise tagamiseks). Selle lisasime kiiresti ka uude klastrisse ja jätkasime tavapärast tööd.
Tänu Kubernetes’i arendusprotsesside ja CI/CD automatiseerimisele tegeleb „URUS” sellega üks spetsialist (ja see olen mina). Mingi hetk töötas minuga veel üks süsteemiadministraator, kuid selgus, et oleme juba enamiku rutiinist automatiseerinud ja meie põhitoote ülesandeid on järjest rohkem ning on mõistlik suunata ressursid sellele.
Me saime pilteid, mida ootasime pilveteenuse pakkujalt, kuna alustasime koostööd ilma valeootusteta. Kui mingeid juhtumeid ette tuli, olid need enamasti tehnilised, ja sellised, mida on lihtne seletada teenuse suhtelise uudsusega. Peamine on, et MCS meeskond kõrvaldab puudused kiiresti ja reageerib sõnumirakendustes küsimustele kiiresti.
Kui võrrelda kogemust Google Cloud Platformiga, siis seal ma isegi ei teadnud, kus asub tagasiside nupp, kuna seda ei olnud tõeliselt vaja. Kui mingid probleemid ka tekkisid, siis Google saatis ise ühel küljel teateid. Aga MCS puhul pean suurimaks plussiks, et nad asuvad maksimaalselt lähedal Venemaa klientidele — nii territoriaalselt kui ka vaimselt.
Kuidas näeme pilveteenuste tööd tulevikus
Praegu on meie töö tihedalt seotud Kubernetesega, ja see rahuldab meid täielikult infrastruktuuriülesannete täitmisel. Seetõttu ei plaani me sellest kuhugi migreeruda, kuigi pidevalt toome sisse uusi praktikaid ja teenuseid rutiinsete ülesannete lihtsustamiseks ja uute automatiseerimiseks, et suurendada teenuste stabiilsust ja usaldusväärsust… Hetkel käivitame Chaos Monkey teenuse (konkreetselt kasutame chaoskube'i, kuid kontseptsioon jääb samaks :), mis loodi algselt Netflixis. Chaos Monkey teeb üht lihtsat asja: eemaldab juhuslikul ajal juhusliku aluse Kuberneteses. See on vajalik selleks, et meie teenus saaks normaalselt töötada instantside arvuga n–1, nii harjutame end olema valmis igasugusteks tõrgeteks.
Praegu näen ma kolmandate osapoolte lahenduste, nagu pilveplatvormide, kasutamist noorte ettevõtete jaoks ainsa õige lahendusena. Tüüpiliselt on nad oma teekonna alguses ressursside, nii inimeste kui ka rahaliste, poolest piiratud, samas kui oma pilve või andmekeskuse rajamine ja hooldamine on liiga kallis ja töömahukas. Pilveteenuse pakkujad võimaldavad neid kulusid minimeerida, pakkudes võimalust kiiresti saada vajalikud ressursid teenuste toimimiseks just siin ja praegu ning maksta nende eest vastavalt kasutusele. Mis puudutab ettevõtet „УРУС“, siis jääme esialgu truuks Kubernetes'ele pilves. Kuid kes teab, võib-olla peame geograafiliselt laienema või rakendama lahendusi mingi spetsiifilise riistvara põhjal. Või siis võib ressursside tarbimise kasv õigustada oma Kubernetes'e bare-metal'l, nagu vanadel headel päevadel. 🙂
Mida oleme õppinud pilveteenustega töötamisest
Oleme hakanud kasutama Kubernetes'i bare metalil ja isegi seal oli see omal viisil hea. Kuid selle tugevusi suudeti tõeliselt esile tuua just aaS-komponendina pilves. Kui seada eesmärk ja kõik maksimaalselt automatiseerida, siis on võimalik vältida vendor lock-in'i ja üleminek erinevate pilveteenuse pakkujate vahel võtab paar tundi, samas kui närvirakud jäävad meiega. Teistele ettevõtetele saame soovitada: kui soovite käivitada oma (pilve) teenust piiratud ressurssidega ja maksimaalse arenduskiirusena — alustage kohe pilveressursside rentimisega, oma andmekeskust ehitage pärast seda, kui teie kohta kirjutab Forbes.
Allikas: habr.com
