Kaasaegne infrastruktuur: probleemid ja perspektiivid

Mais kuu lõpus meie viidi läbi veebikohtumine teemal „Kaasaegne infrastruktuur ja konteinerid: probleemid ja perspektiivid“. Rääkisime konteineritest, Kubernetesest ja orkestreerimisest üldiselt, infrastruktuuri valimise kriteeriumitest ja paljust muust. Osalejad jagasid oma praktika näiteid.

Osalejad:

• Evgeny Potapov, CEO „ITSumma“. Üle poole tema klientidest kas juba üleminekul või soovivad üleminekul Kubernetesesse.
• Dmitry Stolyarov, CTO „Flant“. Omab enam kui 10 aastat kogemust konteinerite süsteemidega.
• Denis Remchukov (aka Eric Oldmann), COO argotech.io, endine RАО ЕЭС. Lubas jagada „karmidest“ ettevõtte kogemustest.
• Andrei Fedorovsky, CTO „News360.com“Pärast ettevõtte müüki teisele tegijale vastutab mitmete ML ja AI projektide ning infrastruktuuri eest.
• Ivan Kruglov, süsteemiinsener, endine Booking.com.See sama inimene, kes on oma kätega Kubernetesega väga palju ära teinud.

Teemad:

• Osalejate teadmised konteinerite ja orkestreerimise (Docker, Kubernetes jne) kohta; mida on katsetatud või analüüsitud.
• Juhtum: Ettevõttes arendatakse infrastruktuuri arenguplaani aastateks. Kuidas langetatakse otsus ehitada (või tõlkida olemasolev) infrastruktuur konteineritele ja Kubernetesele või mitte?
• Probleemid cloud-native maailmas, mida meil puudub, lase meid kujutada, mida toob homne päev.

Käidi huvitav arutelu, osalejate arvamused osutusid nii erinevaks ja tekitasid nii palju kommentaare, et tahame neid teiega jagada. On kolme tunni video, ja allpool on arutelu kokkuvõte.

Kas Kubernetes on juba standard või lihtsalt hea turundus?

„Me jõudsime selle (Kubernetes — toimetaja) juurde siis, kui sellest keegi veel ei teadnud. Me jõudsime sellele veel siis, kui seda ei olnud. Me tahtsime seda juba varem“ — Dmitry Stolyarov

Pilt Reddit.com’ist

Umbes 5-10 aastat tagasi oli tohutult tööriistu, kuid ühtegi ühtset standardit ei olnud. Iga kuue kuu tagant tuli välja uus toode, mõnikord isegi mitu. Esmalt Vagrant, seejärel Salt, Chef, Puppet… „ja sa pead iga kuue kuu tagant oma infrastruktuuri ümber ehitama. Sul on viis adminn, kes kogu aeg on hõivatud konfiguratsioonide kirjutamisega“ — meenutab Andrei Fedorovsky. Ta usub, et Docker ja Kubernetes „tõi ülejäänud alla“. Docker on muutunud standardiks viimase viie aasta jooksul, Kubernetes — viimase kahe aasta jooksul. Ja see on tööstusele kasulik..

Dmitri Stolyarov ja tema meeskond armastavad Kubernetes'e. Nad soovisid sellist tööriista juba enne selle ilmumist ja jõudsid selle juurde, kui keegi sellest veel ei teadnud. Praegu, mugavuse kaalutlustel, ei võta nad klienti, kui nad mõistavad, et nad ei rakenda Kubernetes'e. Samuti ütleb Dmitri, et ettevõttel on "hulgaliselt tohutuid edulugusid kohutava pärandi ümberkujundamisest."

Kubernetes ei ole mitte ainult konteinerite orkestreerimine, vaid ka konfiguratsioonihalduse süsteem arenenud API, võrgu töötluskomponendi, L3 koormuse tasakaalustamise ja sisseseadmise kontrolleritega, mis võimaldab suhteliselt lihtsalt hallata ressursse, skaleerida ja abstraktselt infrastruktuuri madalama tasemega.

Kahjuks tuleb meie elus kõigi asjade eest maksta. Ja see maks on suur, eriti kui rääkida ettevõtte üleminekust Kubernetes'ele, millel on arenenud infrastruktuur, nagu arvab Ivan Kruglov. Ta võiks vabalt töötada nii traditsioonilise infrastruktuuriga ettevõttes kui ka Kubernetes'ega. Peamine on mõista ettevõtte ja turu eripära. Kuid näiteks Evgeny Potapovi jaoks, kes seostaks Kubernetes'e mis tahes konteinerite orkestreerimise tööriistaga, ei ole sellist küsimust.

Evgeny tõi sarnase olukorra välja 1990. aastatest, kui ilmus objektorienteeritud programmeerimine, kui keeruliste rakenduste programmeerimise viis. Sel ajal käidi pidevalt arutelusid ja ilmusid uued tööriistad, mis toetasid OOP-d. Siis ilmusid mikroteenused, kui viis, kuidas kõrvale hiilida monoliitsest kontseptsioonist. See tõi omakorda kaasa konteinerite ja nende haldamise tööriistade ilmumise. "Ma arvan, et peagi jõuame aega, mil küsimus, kas kirjutada mikroteenusena väikest rakendust, ei seisa, seda kirjutatakse vaikimisi mikroteenusena," arvab ta. Sarnaselt muutuvad Docker ja Kubernetes aja jooksul standardlahenduseks ilma valikuvõimaluseta.

Probleemid andmebaasidega on stateless

Foto autor Twitter: @jankolario Unsplash'is

Meie ajal on palju retsepte andmebaaside käivitamiseks Kubernetes'es. Isegi kuidas eraldada osa, mis tegeleb I/O kettaga, näiteks rakenduse — osa andmebaasist. Kas on võimalik, et tulevikus andmebaasid muutuvad nii, et need tarnitakse kastis, kus üks osa orkestreeritakse läbi Docker'i ja Kubernetes'e, ning teises infrastruktuuri osas, läbi eraldi tarkvara, pakutakse salvestamise osa? Kas andmebaasid muutuvad tootena?

See kirjeldus sarnaneb järjekordade haldamisele, kuid nõudmised traditsiooniliste andmebaaside usaldusväärsusele ja informatsiooni sünkroonsusele on palju kõrgemad, arvab Andrei. Cache hit ratio tavalistes andmebaasides püsib 99% tasemel. Kui töötlus kukub, käivitatakse uus ja cache 'soojendatakse' nullist. Seni, kuni cache ei ole soojendatud, töötab töötlus aeglaselt, seega ei tohi sellele suunata kasutaja koormust. Seni, kuni puudub kasutaja koormus, ei soojendata cache't. See on suletud ring.

Dmitri ei nõustu fundamentaalselt: «Kvoorumid ja sharding lahendavad probleemi». Kuid Andrei kinnitab, et lahendus ei sobi kõigile. Mõnel juhul sobib kvoorum, kuid see tekitab lisakoormuse võrgule. NoSQL andmebaasid ei sobi mitte kõikides olukordades.

Meetapi osalejad jagunesid kaheks leeriks.

Denis ja Andrei väidavad, et kõik, mis kirjutatakse kettale — andmebaasid ja muu — on praeguses Kubernetes'i ökosüsteemis võimatu teha. On võimatu säilitada tootlike andmete terviklikkust ja järjepidevust Kubernetes'es. See on fundamentaalne eripära. Lahendus: hübriidne infrastruktuur.

I isegi kaasaegsed pilvepõhised andmebaasid, nagu MongoDB ja Cassandra, või sõnumijärjekorrad, nagu Kafka või RabbitMQ, nõuavad pidevalt andmesalvestusi väljaspool Kubernetes'e.

Evgeni vastab: «Andmebaasid Kuber'is — see on trauma Venemaa lähedal või tagatistes, mis on seotud sellega, et Venemaal ei ole pilve vastuvõttu». Väikesed või keskmised ettevõtted läänes — see on pilv. Amazon RDS andmebaaside kasutamine on lihtsam, kui ise Kubernetes'ega tegeleda. Venemaal kasutatakse Kuberit “on-premise” ja viiakse sinna andmebaasid, kui püütakse lahti saada aiast.

Dmitri nõustub samuti, et ei ole ühtegi andmebaasi, mida ei saa hoida Kubernetes'es: «Andmebaas, andmebaasi üks. Ja kui toppida sinna tohutu relaatorne andmebaas — siis ei mingil juhul. Kui toppida midagi väikest ja pilvepõhist, mis on moraalselt valmis pool-efektiivseks eluks, siis läheb kõik hästi.» Dmitri mainis ka, et andmebaaside haldamise tööriistad ei ole valmis ei Docker'ile ega Kuber'ile, seetõttu tekivad suured probleemid.

Ivan on omalt poolt kindel, et isegi kui kõrvale jätta stateful ja stateless mõisted, ei ole Kubernetes'e ettevõtte lahenduste ökosüsteem veel valmis. Kubersist on keeruline järgida seadusandlikke ja regulatiivseid nõudeid. Näiteks on võimatu luua identiteediandmete süsteemi, kus on vaja rangeid serveri identifitseerimise garantiisid, sealhulgas riistvara, mis on serveritesse paigaldatud. See valdkond areneb, kuid hetkel ei ole lahendust.
Osalejatel ei õnnestunud kokku leppida, seega ei tule selles osas järeldusi. Paremini toome välja paar praktilist näidet.

Juhtum 1. Küberjulgeolek „superregulaatori” andmebaasidega väljaspool Kubernetes't

Arendatud küberjulgeoleku süsteemi korral aitab konteinerite ja orkestreerimise kasutamine ära hoida rünnakuid ja sissetunge. Näiteks ühes superregulaatoris rakendas Denis ja tema meeskond orkestratsiooni ühendust koolitatud SIEM-teenusega, mis analüüsib logisid reaalajas ja tuvastab rünnakute, häkkimise või tõrgete protsessid. Rünnaku korral, katse midagi kinnitada või kui toimib lunavara sissetung, tõstab see orkestreerija kaudu konteinerid rakendustega üles kiiremini, kui need nakatuvad, või kiiremini, kui ründaja neid ründab.

Juhtum 2. Osaline andmebaaside üleviimine Booking.com-is Kubernetes'e

Booking.com-is on peamine andmebaas MySQL koos asünkroonse replikatsiooniga - seal on master ja terve slave-ide hierarhia. Ivan lahkumise ajaks oli käimas projekt, et üle viia sleevide andmebaasid, mida on võimalik teatud kahjuga „mürgitada”.

Peamise andmebaasi kõrval on olemas ka Cassandra installatsioon koos isearendatud orkestreerimisega, mille nad kirjutasid veel enne Kubernetes'e mainstream'i tulekut. Probleem selles osas ei ole, kuid sellel on persistent kohalikul SSD-l. Kaugandmesalvestust, isegi ühes andmekeskuses, ei kasutata kõrge latentsuse probleemi tõttu.

Kolmas andmebaasi klass on Booking.com-i otsinguteenuse, kus iga teenuse sõlm on andmebaas. Katsed viia otsinguteenust Kubernetes'e on ebaõnnestunud, kuna iga sõlm on 60–80 GB kohalikku salvestust, mida on keeruline „üles tõsta” ja „kuumutada”.

Lõppkokkuvõttes ei viidud otsingumootorit Kubernetes'e ja Ivan ei usu, et lähitulevikus oleks uusi katseid. MySQL andmebaas viidi osaliselt üle: ainult slave'id, mida ei olnud hirmus „mürgitada”. Cassandra „sobitus” suurepäraselt.

Valik infrastruktuuri on probleem, millel puudub üldine lahendus

Foto autor Manuel Geissinger, Pexelsist

Kujutame ette, et meil on uus ettevõte või ettevõte, kus osa infrastruktuurist on vanamoodsalt üles ehitatud. Seal töötatakse välja infrastruktuuri arenguplaan, mis katab mitmeid aastaid. Kuidas otsustatakse, kas ehitada infrastruktuur konteinerite ja Kubernetes'e peale või mitte?

Ettevõtted, kes võitlevad nanosekundite nimel, on arutelust välistatud. Tervislik konservatiivsus tasub ära usaldusväärsuse tõttu, kuid siiski on ettevõtteid, kes peaksid kaaluma uusi lähenemisi.

Ivan: "Ma alustaksin praegu kindlasti ettevõtet pilves, lihtsalt sellepärast, et see on kiirem", kuigi mitte tingimata odavam. Riski kapitali arengu tõttu ei ole alustavatel ettevõtetel raha saamisega suuri probleeme ja peamine ülesanne on turgu haarata.

Ivan usub, et praeguse infrastruktuuri arenguaste on valiku määrav tegur. Kui minevikus on tehtud tõsiseid investeeringuid ja see töötab, siis pole mõtet ümber ehitada. Kui aga infrastruktuur ei ole arenenu ja on probleeme tööriistade, turvalisuse ja jälgimisega, siis on mõtet vaadata jaotatud infrastruktuuri poole.

Maksu tuleb igal juhul maksta ja Ivan maksaks seda, mis lubaks tal tulevikus maksta vähem. "Sest lihtsalt sellepärast, et ma sõidan rongis, mida juhivad teised, jõuan ma palju kaugemale, kui kui ma istun teise rongi peale, kus ma pean kütust ise juurde panema." - ütleb Ivan. Kui ettevõte on uus ja latentsuse nõuded on kümneid millisekundeid, siis vaataks Ivan suunas "operaatoritele", kuhu täna "suunatakse" klassikalised andmebaasid. Nad tõstavad replikatsiooniahela, mis vahetub ise, kui tekib tõrge jne…

Küsimus on väikese ettevõtte jaoks, kus on paar serverit Kuberneteses, pole mõtet, — kinnitab Andrei. Kuid kui nad plaanivad kasvada sajani või rohkem, siis on vajalik automatiseerimine ja ressursside juhtimissüsteem. 90% juhtudest õigustab kulutusi. Ja olgu see koormus ja ressursid millised tahes. Kõik, alustades alustavatest ettevõtetest ja lõpetades suurte ettevõtetega, kellel on miljoniline publik, peaksid järk-järgult vaatama konteinerite orkestreerimise toodete poole. "Jah, see on tõeliselt tulevik," usub Andrei.

Denis märkis kaks peamist kriteeriumi — skaalitus ja töökindlus. Ta valib need tööriistad, mis sobivad kõige paremini selle ülesande jaoks. "See võib olla kodus kokku pandud kreeker, millel on Nutanix Community Edition. See võib olla teise taseme rakendus Kuberis, millel on andmebaas taustal, mis replikeerib ja millel on seatud RTO ja RPO parameetrid" (taastumisaeg/punktieesmärgid — näited).

Evgeny tõi esile võimaliku probleemi spetsialistidega. Praegu ei ole turul nii palju tippspetsialiste, kes mõistavad "mootoreid". Tõepoolest, kui valitud tehnoloogia on vana, on raske leida kedagi, välja arvatud vanad, igavlevad ja elust väsinud inimesed. Kuigi teised osalejad arvavad, et see on kaadri ettevalmistamise küsimus.
Kui küsida, kas alustada väikest ettevõtet Public Cloudis andmebaasidega Amazon RDS-is või on-premise andmebaasidega Kuberneteses, siis hoolimata teatud puudustest, on osalejate valik Amazon RDS.

Kuna enamik meetup'i kuulajaid ei ole "veres" ettevõtluses, siis jaotatud lahendused on see, mille poole püüelda. Andmete salvestussüsteemid peavad olema jaotatud, usaldusväärsed ja tekitama latentsust, mis mõõdetakse millisekundites, maksimaalselt kümnetes., - kokku võttis Andrei.

Kubernetes'e kasutamise hindamine

Kuulaja Anton Zhbankov esitas küsimuse, mis püüab kinni Kubernetes'e apoloogid: kuidas valiti ja viidi läbi tehnilis-majanduslik põhjendus? Miks Kubernetes, mitte näiteks virtuaalmasinad?

Foto autor Tatyana Eremina Unsplashist

Mõlemale vastasid Dmitri ja Ivan. Mõlemas olukorras katsete ja vigade meetodil tehti lahenduste järjekord, mille tulemusena jõudsid mõlemad osalejad Kuberneteseni. Praegu hakkab äri iseseisvalt arendama tarkvara, mille üleviimine Kuberi on mõttekas. Räägime mitte klassikalistest kolmanda osapoole süsteemidest, nagu 1C. Kubernetes aitab, kui arendajad peavad kiiresti väljalaskeid tegema jätkuva täiustamise käigus.

Andrei meeskond proovis luua skaleeritavat klastrit virtuaalmasinate põhjal. Nodid langesid nagu domino, mis mõnikord viis klastrite kukkumiseni. "Teoreetiliselt on võimalik see käsitsi lõpetada ja toetada, kuid see on tülikas. Ja kui turul on lahendus, mis võimaldab töötada karbist välja, siis läheme me sellega meeleldi. Ja seetõttu läksime üle," räägib Andrei.

Sarnad selle analüüsi ja arvutamise jaoks on olemas, kuid keegi ei julge öelda, kui õiged nad reaalses riistvaras kasutuses on. Arvutuste jaoks on samuti oluline mõista iga tööriista ja ökosüsteemi, kuid see on võimatu.

Mida me oodata saame

Foto autor Drew Beamer Unsplashist

Kuna tehnoloogiad arenevad, ilmub üha rohkem lahtisi tükke ning seejärel toimub faasisiirde — ilmub tarnija, kes on tapnud piisavalt „rahakotte”, et kõik koos ühte tööriistadesse ühendada.

Kas teile ei tundu, et tuleb aeg, mil tekib tööriist, nagu Ubuntu oli Linuxi maailmas? Võib-olla sisaldab üksnes konteinerimise ja orkestreerimise tööriist ka Kuberit. Sellega on lihtne luua on-premise pilvi.

Ivan vastas: "Google ehitab praegu Anthost — see on nende pakett, mis rakendab pilve ja sisaldab Kuberit, Service Meshi, jälgimist — kogu kraami, mida mikroteenuste jaoks on vaja on-premises. Me oleme peaaegu tulevikus."

Denis mainis ka Nutanixit ja VMWare'i toote vRealize Suite, mis suudavad sellise ülesandega toime tulla ilma konteinerimiseta.

Dmitri jagas arvamust, et „valude” vähendamine ja maksu alandamine on kaks suunda, kus tasub oodata parandusi.

Kokkuvõtteks arutelust tuvastame järgmised kaasaegse infrastruktuuri probleemid

• Kolm osalejat tõid esile stateful probleemid.
• Erinevad probleemid turbe toetamisega, sealhulgas risk, et Dockerisse satub mitu versiooni Pythonit, rakenduste servereid ja komponente.
  Üksikülekandeteemad, millest oleks parem eraldi koosolek teha.
  Koolituse probleem, kuna orkestreerimine on keeruline ökosüsteem.
  Tööstuse üldine probleem on tööriistade vale kasutamine.

  Ülejäänud järeldused lasen teha teil. Praegu jääb tunne, et Docker + Kubernetes ei ole kergeks loomulikuks osaks süsteemist saada. Näiteks operatsioonisüsteemid paigaldatakse riistvaraga esimesena, mida ei saa öelda konteinerite ja orkestreerimise kohta. Võib-olla tulevikus sulanduvad operatsioonisüsteemid ja konteinerid koos pilvahaldustarkvaraga.

  
  Foto autor Gabriel Santos Fotografia Pexelsist

  Kasutades juhust, tahan saata tervitusi emale ja meenutada, et meil on Facebooki grupp „Suured IT-projektide haldamine ja arendamine”, kanal @feedmeto huvitavate postitustega erinevatest tehnoblogidest. Ja minu kanal @rybakalexey, kus ma räägin arendusjuhtimise kohta tooteettevõtetes.

Allikas: habr.com