URUS-yritys kokeili Kubernetesia eri muodoissa: itsenäisenä käyttöönoton paljaalla metallilla, Google Cloudissa, ja siirsi sitten alustansa Mail.ru Cloud Solutions (MCS) -pilveen. Igor Shishkin kertoo kuinka he valitsivat uuden pilvipalveluntarjoajan ja kuinka he onnistuivat siirtymään siihen ennätyskahdessa tunnissa (), vanhempi järjestelmävastaava, URUS.
Mitä URUS tekee?
Kaupunkiympäristön laatua voidaan parantaa monella tavalla, ja yksi niistä on tehdä siitä ympäristöystävällinen. Juuri tätä URUS - Smart Digital Services -yritys työskentelee. Täällä he toteuttavat ratkaisuja, jotka auttavat yrityksiä seuraamaan tärkeitä ympäristöindikaattoreita ja vähentämään niiden kielteisiä ympäristövaikutuksia. Anturit keräävät tietoa ilman koostumuksesta, melutasosta ja muista parametreista ja lähettävät ne sitten yhtenäiselle URUS-Ekomon-alustalle analysoitavaksi ja suositusten tekemiseksi.
Kuinka URUS toimii sisältäpäin
Tyypillinen URUS-asiakas on asuinalueella tai sen läheisyydessä sijaitseva yritys. Tämä voi olla tehdas, satama, rautatievarasto tai mikä tahansa muu laitos. Jos asiakkaamme on jo saanut varoituksen, saanut sakon ympäristön saastumisesta tai haluaa vähentää melua, vähentää haitallisten päästöjen määrää, hän tulee meille, ja tarjoamme hänelle valmiin ratkaisun ympäristön seurantaan.
H2S-pitoisuuksien seurantakäyrä näyttää säännölliset yöpäästöt läheisestä laitoksesta
URUS:lla käyttämämme laitteet sisältävät useita antureita, jotka keräävät tietoa tiettyjen kaasujen pitoisuudesta, melutasoista ja muista tiedoista ympäristötilanteen arvioimiseksi. Antureiden tarkka lukumäärä määräytyy aina tehtävän mukaan.
Mittausten erityispiirteistä riippuen antureilla varustettuja laitteita voidaan sijoittaa rakennusten seiniin, pylväisiin ja muihin mielivaltaisiin paikkoihin. Jokainen tällainen laite kerää tietoa, aggregoi ne ja lähettää sen tiedon vastaanottavalle yhdyskäytävälle. Siellä tallennamme tiedot pitkäaikaista säilytystä varten ja esikäsittelemme ne myöhempää analysointia varten. Yksinkertaisin esimerkki siitä, mitä saamme analyysin tuloksena, on ilmanlaatuindeksi, joka tunnetaan myös nimellä AQI.
Samanaikaisesti alustallamme toimii monia muita palveluita, mutta ne ovat pääosin palveluluonteisia. Esimerkiksi ilmoituspalvelu lähettää ilmoituksia asiakkaille, jos jokin valvotuista parametreista (esimerkiksi CO2-pitoisuus) ylittää sallitun arvon.
Kuinka tallennamme tietoja. Kubernetesin tarina paljaalla metallilla
URUS-ympäristönseurantaprojektissa on useita tietovarastoja. Yhdessä säilytämme "raaka" datan - sen, mitä saimme suoraan laitteilta itseltään. Tämä säilytys on "magneettinen" nauha, kuten vanhat kasettinauhat, jossa on historia kaikista ilmaisimista. Toista tallennustyyppiä käytetään esikäsitellyille tiedoille - laitteista saataville tiedoille, jotka on rikastettu metatiedoilla anturien välisistä yhteyksistä ja laitteiden itse lukemista, yhteyksistä organisaatioihin, sijainteihin jne. Näiden tietojen avulla voit dynaamisesti arvioida, kuinka tietty indikaattori on muuttunut tietyn ajan kuluessa. Käytämme "raaka" datatallennusta muun muassa varmuuskopiona ja esikäsiteltyjen tietojen palauttamiseen, mikäli sellainen ilmenee.
Kun etsimme ratkaisua tallennusongelmaamme useita vuosia sitten, meillä oli kaksi alustavaihtoehtoa: Kubernetes ja OpenStack. Mutta koska jälkimmäinen näyttää melko hirveältä (katso vain sen arkkitehtuuria varmistaaksesi tämän), päädyimme Kubernetesiin. Toinen argumentti sen puolesta oli suhteellisen yksinkertainen ohjelmistoohjaus, kyky leikata joustavammin jopa laitteistosolmuja resurssien mukaan.
Itse Kubernetesin masteroinnin rinnalla tutkimme myös tapoja tallentaa tietoja, samalla kun säilytimme kaiken Kuberneteksen tallennustilan omalla laitteistollamme, saimme erinomaista asiantuntemusta. Kaikki, mitä olimme silloin eläneet Kubernetesissa: tilatäydellinen tallennus, valvontajärjestelmä, CI/CD. Kubernetesista on tullut meille all-in-one-alusta.
Halusimme kuitenkin työskennellä Kuberneteksen kanssa palveluna, emmekä osallistua sen tukemiseen ja kehittämiseen. Lisäksi emme pitäneet siitä, kuinka paljon sen ylläpito paljaalla metallilla maksoi, ja tarvitsimme jatkuvaa kehitystä! Esimerkiksi yksi ensimmäisistä tehtävistä oli integroida Kubernetes Ingress -ohjaimet organisaatiomme verkkoinfrastruktuuriin. Tämä on hankala tehtävä, varsinkin kun otetaan huomioon, että tuolloin mikään ei ollut valmis ohjelmalliseen resurssien hallintaan, kuten DNS-tietueisiin tai IP-osoitteiden jakamiseen. Myöhemmin aloimme kokeilla ulkoista tallennustilaa. Emme koskaan päässeet PVC-ohjaimen käyttöönottoon, mutta jo silloin kävi selväksi, että kyseessä oli laaja työalue, joka vaati omistautuneita asiantuntijoita.
Google Cloud Platformiin vaihtaminen on väliaikainen ratkaisu
Ymmärsimme, että tämä ei voinut jatkua, ja siirsimme tietomme paljaalta metallilta Google Cloud Platformiin. Itse asiassa tuolloin venäläiselle yritykselle ei ollut paljon mielenkiintoisia vaihtoehtoja: Google Cloud Platformin lisäksi vain Amazon tarjosi vastaavaa palvelua, mutta päädyimme silti Googlen ratkaisuun. Silloin se tuntui meistä taloudellisesti kannattavammalta, lähempänä Upstreamia, puhumattakaan siitä, että Google itse on eräänlainen PoC Kubernetes tuotannossa.
Ensimmäinen suuri ongelma ilmaantui horisontissa asiakaskuntamme kasvaessa. Kun meillä oli tarve tallentaa henkilötietoja, olimme valinnan edessä: joko teemme yhteistyötä Googlen kanssa ja rikomme Venäjän lakeja tai etsimme vaihtoehtoa Venäjän federaatiosta. Valinta oli kaiken kaikkiaan ennakoitavissa. 🙂
Näin näimme ihanteellisen pilvipalvelun
Haun alussa tiesimme jo, mitä haluamme saada tulevalta pilvipalveluntarjoajalta. Mitä palvelua etsimme:
- Nopeaa ja joustavaa. Sellainen, että voimme nopeasti lisätä uuden solmun tai ottaa käyttöön jotain milloin tahansa.
- Edullinen. Olimme erittäin huolissamme taloudellisesta ongelmasta, koska resurssimme olivat rajalliset. Tiesimme jo valmiiksi, että haluamme työskennellä Kubernetesin kanssa, ja nyt tehtävänä oli minimoida sen kustannukset, jotta tämän ratkaisun käyttö tehostuu tai ainakin säilyy.
- automatisoitu. Suunnittelimme työskennellä palvelun kanssa API:n kautta ilman esimiehiä ja puheluita tai tilanteita, joissa joudumme manuaalisesti nostamaan useita kymmeniä solmuja hätätilassa. Koska suurin osa prosesseistamme on automatisoituja, odotimme samaa myös pilvipalvelulta.
- Venäjän federaatiossa olevilla palvelimilla. Tietenkin suunnittelimme noudattavamme Venäjän lainsäädäntöä ja samaa 152-FZ:ää.
Tuolloin Venäjällä oli vähän Kubernetes aaS -palveluntarjoajia, ja palveluntarjoajaa valittaessa oli tärkeää, ettemme tinkiisi prioriteeteistamme. Mail.ru Cloud Solutions -tiimi, jonka kanssa aloitimme työskennellä ja teemme edelleen yhteistyötä, tarjosi meille täysin automatisoidun palvelun, API-tuen ja kätevän ohjauspaneelin, joka sisältää Horizonin - sen avulla pystyimme nopeasti nostamaan mielivaltaisen määrän solmuja.
Kuinka onnistuimme siirtymään MCS:ään kahdessa tunnissa
Tällaisissa siirroissa monet yritykset kohtaavat vaikeuksia ja takaiskuja, mutta meidän tapauksessamme niitä ei ollut. Meillä oli onnea: koska työskentelimme Kubernetesin parissa jo ennen migraation alkamista, korjasimme vain kolme tiedostoa ja lanseerasimme palvelumme uudelle pilvialustalle, MCS:lle. Haluan muistuttaa, että siihen mennessä olimme vihdoin jättäneet metallin ja eläneet Google Cloud Platformissa. Siksi itse siirto kesti korkeintaan kaksi tuntia, ja lisäksi kului hieman enemmän aikaa (noin tunti) tietojen kopioimiseen laitteiltamme. Silloin käytimme jo Spinnakeria (monipilvi-CD-palvelu, joka tarjoaa jatkuvan toimituksen). Lisäsimme sen myös nopeasti uuteen klusteriin ja jatkoimme toimintaa normaalisti.
Kehitysprosessien ja CI/CD:n automatisoinnin ansiosta URUS:n Kubernetes on yhden asiantuntijan (ja se olen minä). Jossain vaiheessa toinen järjestelmänvalvoja työskenteli kanssani, mutta sitten kävi ilmi, että olimme jo automatisoineet kaikki päärutiinit ja päätuotteemme puolella tehtäviä oli koko ajan enemmän ja siihen oli järkevää suunnata resursseja.
Saimme mitä odotimme pilvipalveluntarjoajalta, koska aloitimme yhteistyön ilman illuusioita. Jos tapauksia sattui, ne olivat enimmäkseen teknisiä ja sellaisia, jotka selittyvät helposti palvelun suhteellisen tuoreudella. Tärkeintä on, että MCS-tiimi poistaa nopeasti puutteet ja vastaa nopeasti kysymyksiin lähettiläissä.
Jos vertaan kokemuksiani Google Cloud Platformin kanssa, en heidän tapauksessaan edes tiennyt, missä palautepainike oli, koska sille ei yksinkertaisesti ollut tarvetta. Ja jos ongelmia ilmeni, Google lähetti itse ilmoituksia yksipuolisesti. Mutta MCS:n tapauksessa mielestäni suuri etu on se, että ne ovat mahdollisimman lähellä venäläisiä asiakkaita - sekä maantieteellisesti että henkisesti.
Miten näemme pilvien parissa työskentelemisen tulevaisuudessa
Nyt työmme on tiiviisti sidoksissa Kubernetesiin ja sopii meille täysin infrastruktuuritehtävien näkökulmasta. Siksi emme aio siirtyä siitä minnekään, vaikka otamme jatkuvasti käyttöön uusia käytäntöjä ja palveluita rutiinitehtävien yksinkertaistamiseksi ja uusien automatisoimiseksi, palveluiden vakauden ja luotettavuuden lisäämiseksi... Olemme nyt käynnistämässä Chaos Monkey -palvelun (erityisesti , käytämme chaoskubea, mutta tämä ei muuta konseptia: ), jonka alun perin loi Netflix. Chaos Monkey tekee yhden yksinkertaisen asian: se poistaa satunnaisen Kubernetes-kotelon satunnaisesti. Tämä on välttämätöntä, jotta palvelumme toimisi normaalisti esiintymien lukumäärällä n–1, joten koulutamme itsemme varautumaan mahdollisiin ongelmiin.
Nyt näen kolmannen osapuolen ratkaisujen - samojen pilvialustojen - käytön ainoana oikeana asiana nuorille yrityksille. Yleensä heidän matkansa alussa heillä on rajalliset resurssit, sekä henkilö- että talousresurssit, ja oman pilven tai datakeskuksen rakentaminen ja ylläpito on liian kallista ja työvoimavaltaista. Pilvipalveluntarjoajien avulla voit minimoida nämä kustannukset, voit saada heiltä nopeasti palveluiden toimintaan tarvittavat resurssit tässä ja nyt ja maksaa nämä resurssit jälkikäteen. Mitä tulee URUS-yritykseen, pysymme Kubernetesille uskollisina pilvessä toistaiseksi. Mutta kuka tietää, meidän on ehkä laajennettava maantieteellisesti tai toteutettava ratkaisuja, jotka perustuvat tiettyihin laitteisiin. Tai ehkä kulutettujen resurssien määrä oikeuttaa oman Kuberneteksen paljasmetallilla, kuten vanhoina hyvinä aikoina. 🙂
Mitä opimme työskentelystä pilvipalveluiden parissa
Aloimme käyttää Kubernetesia paljaalla metallilla, ja sielläkin se oli omalla tavallaan hyvää. Mutta sen vahvuudet paljastettiin juuri pilven aaS-komponenttina. Jos asetat tavoitteen ja automatisoit kaiken mahdollisimman pitkälle, pystyt välttämään toimittajien lukkiutumisen ja pilvipalveluntarjoajien välillä liikkuminen vie pari tuntia, ja hermosolut jäävät meille. Voimme neuvoa muita yrityksiä: jos haluat käynnistää oman (pilvi)palvelun, jolla on rajalliset resurssit ja maksimaalinen kehitysvauhti, aloita heti vuokraamalla pilviresurssit ja rakenna palvelinkeskuksesi sen jälkeen, kun Forbes kirjoittaa sinusta.
Lähde: will.com