Nolabait, historikoki, informatikako industria bi baldintzapeko esparrutan banatuta dago edozein arrazoirengatik: "alde" daudenak eta "kontra" daudenak. Gainera, auzien gaia guztiz arbitrarioa izan daiteke. Zein sistema eragile da hobea: Win ala Linux? Android edo iOS telefono batean? Dena hodeietan gorde behar al duzu edo RAID biltegiratze hotzean jarri eta torlojuak kutxa seguru batean jarri behar dituzu? PHP jendeak programatzaile deitzeko eskubidea al du? Gatazka hauek, batzuetan, izaera esklusiboki existentziala dute eta ez dute kirol interesa baino beste oinarririk.
Gertatu zen edukiontzien etorrerarekin eta docker eta baldintzapeko k8-ekin egindako sukaldaritza maite hori guztia, backend-eko hainbat arlotan gaitasun berrien erabileraren "alde" eta "kontrako" eztabaidak hasi zirela. (Egin dezagun aldez aurretik erreserba bat eztabaida honetan gehienetan Kubernetes orkestratzaile gisa adieraziko den arren, tresna jakin hau aukeratzeak ez du funtsezko garrantzia. Horren ordez, erosoena eta ezagunena iruditzen zaizun beste edozein ordez dezakezu. .)
Eta, antza, hau txanpon beraren bi aldeen arteko eztabaida soila izango litzateke. Win vs Linux-en arteko betiko konfrontazioa bezain zentzugabea eta gupidagabea, non erdian jende egokia dagoen. Baina edukiontzien kasuan, dena ez da hain erraza. Normalean halako liskarretan ez dago eskuineko alderik, baina datu-baseak gordetzeko βerabiliβ edo βez erabiliβ edukiontzien kasuan, dena hankaz gora jartzen da. Zentzu jakin batean arrazoia baitute ikuspegi honen aldekoek zein aurkariek.
Alde Argia
Light Side-ren argudioa laburki deskriba daiteke esaldi batean: "Kaixo, 2k19 leihotik kanpo dago!" Populismoa dirudi, noski, baina egoera zehatz-mehatz sakonduz gero, baditu abantailak. Ordena ditzagun orain.
Demagun web proiektu handi bat duzula. Hasieran mikrozerbitzuen ikuspegi batean oinarrituta eraiki zitekeen, edo noizbait bide ebolutibo baten bidez iritsi zen; hori ez da oso garrantzitsua, egia esan. Gure proiektua mikrozerbitzu bereizietan banatu duzu, orkestrazioa, karga orekatzea eta eskalatzea konfiguratu duzu. Eta orain, kontzientzia garbi, hamaka batean mojito bat hartzen duzu habra efektuetan eroritako zerbitzariak altxatu beharrean. Baina ekintza guztietan koherentea izan behar duzu. Askotan, aplikazioa bera bakarrik βkodeaβ edukiontzietan dago. Zer gehiago daukagu ββkodeaz gain?
Hori bai, datuak. Edozein proiekturen muina bere datuak dira: hau DBMS tipikoa izan daiteke - MySQL, Postgre, MongoDB, edo bilaketarako erabiltzen den biltegia (ElasticSearch), gako-balioen biltegiratzea cachean gordetzeko - adibidez, redis, etab. Gaur egun ez gara. Datu-basea gaizki idatzitako kontsulten ondorioz huts egiten denean atzeko inplementazio-aukerei buruz hitz egingo dugu, eta horren ordez datu-base honen akatsen tolerantzia bezeroaren kargapean bermatzeaz hitz egingo dugu. Azken finean, gure aplikazioa edukiontzian jartzen dugunean eta sarrerako edozein eskaera prozesatzeko askatasunez eskalatzen uzten dugunean, horrek datu-basearen karga areagotzen du.
Izan ere, datu basera sartzeko kanala eta exekutatzen den zerbitzaria orratzaren begi bihurtzen dira gure edukiontzidun backend ederrean. Aldi berean, edukiontzien birtualizazioaren motibo nagusia egituraren mugikortasuna eta malgutasuna da, eta horri esker, gailur-kargaren banaketa gure eskura dugun azpiegitura osoan ahalik eta modu eraginkorrenean antolatzeko aukera dugu. Hau da, sisteman dauden elementu guztiak edukiontzietan sartzen eta zabaltzen ez baditugu kluster osoan, oso akats larria egiten ari gara.
Askoz logikoagoa da aplikazioa bera ez ezik, datuak gordetzeaz arduratzen diren zerbitzuak ere klusteratzea. K8s-en modu independentean funtzionatzen duten eta karga euren artean banatzen duten web zerbitzariak multzokatuz eta zabalduz, dagoeneko konpontzen ari gara datuen sinkronizazioaren arazoa - argitalpenetako iruzkin berdinak, adibide gisa komunikabide edo blog-plataforma batzuk hartzen baditugu. Nolanahi ere, kluster barneko datu-basearen irudikapena dugu, baita birtuala ere, Kanpo Zerbitzu gisa. Kontua da datu-basea bera ez dagoela oraindik multzokatuta: kuboan inplementatutako web zerbitzariek gure borroka datu-base estatikoko aldaketei buruzko informazioa hartzen dute, bereizita biratzen duena.
Harrapaketarik sumatzen al duzu? K8s edo Swarm erabiltzen ditugu karga banatzeko eta web zerbitzari nagusia huts egitea saihesteko, baina ez dugu datu-baserako hau egiten. Baina datu-baseak huts egiten badu, gure klusteratutako azpiegitura osoak ez du zentzurik - zertarako balio dute datu-basean sartzeko errore bat itzultzen duten web orri hutsek?
Horregatik, beharrezkoa da web zerbitzariak ez ezik, egin ohi den moduan, datu-basearen azpiegitura ere klusteratzea. Horrela bakarrik bermatuko dugu talde batean guztiz funtzionatuko duen egitura bat, baina aldi berean elkarrengandik independentea. Gainera, gure backendaren erdia kargapean "kolapso" bada ere, gainerakoak bizirik iraungo du, eta kluster barruan datu-baseak elkarren artean sinkronizatzeko sistemak eta kluster berriak etengabe eskalatzeko eta zabaltzeko gaitasunak beharrezko ahalmenera azkar lortzen lagunduko du. - datu zentroan bastidoreak egongo balira .
Gainera, klusterretan banatutako datu-base ereduak datu-base hori behar den lekura eramateko aukera ematen du; Zerbitzu global bati buruz ari bagara, orduan nahiko logikoa da web-kluster bat San Frantziskoko nonbait hastea eta, aldi berean, paketeak bidaltzea Mosku eskualdeko datu-base batera sartzean eta atzera.
Gainera, datu-basearen edukiontziak sistemaren elementu guztiak abstrakzio maila berean eraikitzeko aukera ematen du. Horrek, aldi berean, sistema hau bera kodetik zuzenean kudeatzea ahalbidetzen du, garatzaileek, administratzaileen inplikazio aktiborik gabe. Garatzaileek uste zuten azpiproiektu berrirako DBMS bereizi bat behar zela - erraza! yaml fitxategi bat idatzi, klusterera kargatu eta listo.
Eta, jakina, barne funtzionamendua asko errazten da. Esadazu, zenbat aldiz itxi dituzu begiak taldekide berri batek eskuak lanerako borroka datu-basean sartu dituenean? Zein da, hain zuzen, oraintxe bertan duzun eta biraka ari den bakarra? Jakina, denok gara hemen helduak, eta nonbait babeskopia berria dugu, eta are urrunago - amonaren pepinoak eta eski zaharrak dituen apalaren atzean - beste babes bat, agian hotzean ere, zure bulegoa sutan zegoelako behin. Baina, hala ere, borroka-azpiegiturara eta, jakina, borroka-datu-basera sarbidea duen taldekide berri baten sarrera bakoitza inguruko guztientzako baliozko ontzi bat da. Tira, nork ezagutzen du, hasiberria, beharbada gurutzatua? Beldurgarria da, ados egongo zara.
Kontainerizazioak eta, hain zuzen ere, zure proiektuaren datu-basearen topologia fisiko banatuak baliozkotze une horiek saihesten laguntzen du. Ez al zara fidatzen hasiberri batekin? ADOS! Eman diezaiogun bere klusterra lan egiteko eta datu-basea beste kluster batzuetatik deskonektatzeko - eskuzko bultzada eta bi teklaren biraketa sinkronikoaren bidez soilik sinkronizatzea (bat taldeko arduradunarentzat, bestea administratzailearentzat). Eta denak pozik daude.
Eta orain datu-baseen klusterketaren aurkari bihurtzeko garaia da.
Alde iluna
Datu-basea edukiontzian jartzeak eta zerbitzari zentral batean exekutatzen jarraitzeak zergatik ez duen merezi argudiatuz, ez gara makurtuko ortodoxien eta adierazpenen erretorika, "aitonek datu-baseak hardwarean erabiltzen zituzten, eta guk ere bai!" Horren ordez, saia gaitezen edukiontzigintzak benetan dibidendu ukigarriak ordainduko dituen egoera bat sortzen.
Ados, edukiontzi batean oinarri bat benetan behar duten proiektuak esku bateko hatzekin zenbatu daitezke fresatzeko makinen operadore onena ez denak. Gehienetan, k8s-en edo Docker Swarm-en erabilera bera ere erredundantea da - askotan tresna hauek erabiltzen dira teknologien iragarpen orokorragatik eta generoen pertsonan "ahalguztidunaren" jarreragatik dena bultzatzeko. hodeiak eta edukiontziak. Tira, orain modan dagoelako eta denek egiten dutelako.
Gutxienez kasuen erdietan, Kubernetis edo Docker soilik erabiltzea proiektu batean erredundantea da. Arazoa da bezeroaren azpiegitura mantentzeko kontratatutako talde edo azpikontratazio-enpresa guztiek ez dutela horren jakitun. Okerragoa da edukiontziak ezartzen direnean, bezeroari txanpon kopuru bat kostatzen zaiolako.
Orokorrean, docker/cube mafia ergelkeriaz azpiegitura arazo hauek azpikontratatzen dituzten bezeroak birrintzen ari dela iritzia dago. Azken finean, klusterrekin lan egiteko, horretarako gai diren eta orokorrean inplementatutako irtenbidearen arkitektura ulertzen duten ingeniariak behar ditugu. Behin gure kasua deskribatu genuen Errepublikaren argitalpenarekin - han bezeroaren taldea trebatu genuen Kubernetis-en errealitatean lan egiteko, eta denak pozik zeuden. Eta duina zen. Askotan, k8s "inplementatzaileek" bezeroaren azpiegitura bahituta hartzen dute - orain dena nola funtzionatzen duen bakarrik ulertzen baitute; ez dago bezeroaren aldetik espezialistarik.
Orain imajinatu horrela web zerbitzariaren zatia ez ezik, datu-baseen mantentzea ere azpikontratatzen dugula. Esan genuen BD bihotza dela, eta bihotza galtzea hilgarria da edozein organismo bizidunentzat. Laburbilduz, aurreikuspenak ez dira onenak. Beraz, Kubernetis hype-ren ordez, proiektu askok ez lukete AWSren tarifa normalarekin traba egin behar, eta horrek beren gune/proiektuaren kargaren arazo guztiak konponduko ditu. Baina AWS jada ez dago modan, eta ikuskizunek dirua baino gehiago balio dute, zoritxarrez, IT ingurunean ere.
ADOS. Beharbada proiektuak klusterketa behar du, baina estaturik gabeko aplikazioekin dena argi badago, nola antola dezakegu sare-konektibitate duina datu-base kluster baterako?
Ingeniaritza soluziorik gabeko irtenbide bati buruz ari bagara, hau da, k8s-erako trantsizioa, orduan gure buruhauste nagusia datu-base multzo batean erreplikatzea da. DBMS batzuk hasiera batean nahiko leialak dira beren instantzia indibidualen artean datuak banatzeko. Beste asko ez dira hain atseginak. Eta askotan gure proiekturako DBMS bat aukeratzeko argudio nagusia ez da baliabide eta ingeniaritza kostu minimoekin errepikatzeko gaitasuna. Batez ere, proiektua ez bazen hasieran mikrozerbitzu gisa planifikatu, baizik eta norabide horretan eboluzionatu.
Uste dugu ez dagoela sareko unitateen abiaduraz hitz egin beharrik - motelak dira. Horiek. Oraindik ez dugu benetako aukerarik, zerbait gertatzen bada, DBMS instantzia bat berrabiarazteko gehiago dagoen tokian, adibidez, prozesadorearen potentzia edo RAM librea. Oso azkar egingo dugu topo birtualizatutako disko azpisistemaren errendimendua. Ondorioz, DBMSa hurbil kokatuta dagoen bere makina multzo pertsonalean iltzatuta egon behar da. Edo beharrezkoa da nolabait bereizita hoztea datuen sinkronizazio nahikoa azkarra ustezko erreserbetarako.
Fitxategi sistema birtualen gaiarekin jarraituz: Docker Volumes, zoritxarrez, ez dago arazorik. Oro har, epe luzerako datu fidagarrien biltegiratze gisa, eskema teknikoki sinpleenekin konformatu nahiko nuke. Eta edukiontziaren FS-tik abstrakzio-geruza berri bat ostalari nagusiaren FSra gehitzea arriskua da berez. Baina edukiontzien laguntza sistemaren funtzionamenduak geruza horien artean datuak transmititzeko zailtasunak ere aurkitzen dituenean, orduan hondamendia da benetan. Momentuz, badirudi gizateriaren aurrerakoiak ezagutzen dituen arazo gehienak desagerrarazita daudela. Baina ulertzen duzu, mekanismoa zenbat eta konplexuagoa izan, orduan eta errazagoa apurtzen da.
"Abentura" guzti hauen harira, askoz ere errentagarriagoa eta errazagoa da datu-basea leku bakarrean mantentzea, eta aplikazioa edukiontzian jarri behar baduzu ere, utzi bere kabuz exekutatzen eta banaketa atebidearen bidez aldibereko komunikazioa jaso. datu-basea, behin eta leku bakarrean irakurri eta idatziko dena. Ikuspegi honek erroreak eta desinkronizazioaren probabilitatea gutxienera murrizten du.
Zertara eramaten ari gara? Gainera, datu-baseen edukiontzia egokia da benetako beharra dagoen lekuetan. Ezin duzu aplikazio osoko datu-base bat bete eta bira eman bi dozena mikrozerbitzu izango bazenitu bezala - ez du horrela funtzionatzen. Eta hori argi eta garbi ulertu behar da.
Irteera beharrean
Ondorio argi baten zain bazaude βdatu-basea birtualizatzeko edo ezβ, orduan etsita egingo zaitugu: ez da hemen izango. Zeren edozein azpiegitura-irtenbide sortzerakoan, ez da moda eta aurrerapena gidatu behar, baizik eta, lehenik eta behin, sen onak.
Kubernetisekin datozen printzipioak eta tresnak ezin hobeto egokitzen diren proiektuak daude, eta horrelako proiektuetan bakea dago backend eremuan behintzat. Eta badaude edukiontzirik behar ez duten proiektuak, zerbitzariaren azpiegitura normal bat baizik, funtsean ezin dutelako mikrozerbitzuen kluster eredura eskalatu, erori egingo direlako.
Iturria: www.habr.com