Reformat janĂ« si njĂ« kuti magjike â kĂ«rkon atĂ« qĂ« tĂ« nevojitet dhe burimet thjesht shfaqen nga asgjĂ«. Makina virtuale, bazat e tĂ« dhĂ«nave, rrjeti â gjithçka i takon vetĂ«m ty. Ka edhe tenda tĂ« tjera nĂ« re, por nĂ« universin tĂ«nd je sundimtari i vetĂ«m. Je i sigurt se do tĂ« marrĂ«sh gjithmonĂ« resurset e nevojshme, pa u shqetĂ«suar pĂ«r askĂ«nd dhe e pĂ«rcakton vetĂ« se si do tĂ« jetĂ« rrjeti. Si funksionon kjo magji qĂ« bĂ«n qĂ« reja tĂ« alocojĂ« elastikisht resurset dhe tĂ« izolojĂ« plotĂ«sisht tenda nga njĂ«ra-tjetra?
Reformat AWS Ă«shtĂ« njĂ« sistem super kompleks, i cili Ă«shtĂ« duke u zhvilluar evolutivisht qĂ« nga viti 2006. NjĂ« pjesĂ« e kĂ«saj zhvillimi e pĂ«rjetoi Vasili Pantiukhin â arkitekt i Amazon Web Services. Si arkitekt, ai shikoni nga brenda jo vetĂ«m rezultatet pĂ«rfundimtare, por edhe sfidat qĂ« kalon AWS. Sa mĂ« shumĂ« tĂ« kuptoni funksionimin e sistemit, aq mĂ« shumĂ« besim do tĂ« keni. Prandaj, Vasili do tĂ« ndajĂ« sekretet e shĂ«rbimeve cloud tĂ« AWS. NĂ«n kĂ«tĂ«, do tĂ« shqyrtojmĂ« ndĂ«rtimin e serverĂ«ve fizikĂ« tĂ« AWS, elastikshmĂ«rinĂ« dhe shkallĂ«zueshmĂ«rinĂ« e bazĂ«s sĂ« dhĂ«nash, bazĂ«n e tĂ« dhĂ«nave tĂ« personalizuara Amazon dhe metodat pĂ«r tĂ« pĂ«rmirĂ«suar performancĂ«n e makinave virtuale duke ulur njĂ«kohĂ«sisht kostot e tyre. NjohuritĂ« mbi qasjet arkitektonike tĂ« Amazon do tĂ« ndihmojnĂ« nĂ« pĂ«rdorimin mĂ« efikas tĂ« shĂ«rbimeve tĂ« AWS dhe ndoshta do tĂ« ofrojnĂ« ide tĂ« reja pĂ«r ndĂ«rtimin e zgjidhjeve tuaja tĂ« veta.
Rreth folësit: Vasili Pantyukhin () filloi si administrator Unix në kompanitë .ru, për 6 vjet u angazhua me pajisje të mëdha Sun Microsystem, dhe për 11 vjet predikoi rëndësinë e qendrave të të dhënave në EMC. Në mënyrë natyrale evoluoi në cloud-e private dhe në 2017 u përkushtua në ato publike. Tani ofron këshilla teknike për të jetuar dhe zhvilluar në cloud-in AWS.
Diskleimer: gjithçka më poshtë është mendimi personal i Vasilit dhe mund të mos përputhet me qëndrimin e Amazon Web Services. i prezantimit, mbi të cilin është krijuar artikulli, është në dispozicion në kanalin tonë YouTube.
Pse po flas për aparatin Amazon
Makina ime e parĂ« kishte "dorezĂ«" â me transmetim mekanik. Ishte fantastike pĂ«r shkak tĂ« ndjenjĂ«s se mund tĂ« kontrolloja makinĂ«n dhe ta menaxhoja plotĂ«sisht. Gjithashtu, mĂ« pĂ«lqente qĂ« tĂ« paktĂ«n e kuptoja nĂ« njĂ« farĂ« mase si funksiononte ajo. Natyrisht, e imagjinoja aparatin e kutisĂ« mjaft primitivisht â njĂ«soj si kutinĂ« e transmetimit nĂ« njĂ« biçikletĂ«.
Ishte gjithcka e shkĂ«lqyer, pĂ«rveç njĂ« gjĂ«je â qĂ«ndronte nĂ« trafik. Duket sikur rri dhe nuk bĂ«j asgjĂ«, por vazhdimisht ndĂ«rron transmetimet, shtyp pedalin e lidhjes, gazit, frenave â dhe kjo Ă«shtĂ« realisht lodhĂ«se. Problemi i trafikut u zgjidh disi, kur nĂ« familje erdhi njĂ« makinĂ« me automatik. Pas timonit fillova tĂ« kisha kohĂ« tĂ« mendoja pĂ«r diçka, tĂ« dĂ«gjoja audiokitabe.
Gjithashtu, në jetën time u shfaq një mister, sepse unë në përgjithësi e humba kuptimin se si funksionon makina ime. Automjeti modern është një aparat kompleks. Makina përshtatet njëkohësisht me dhjetëra parametra të ndryshëm: shtypja e gazit, frenimi, stili i drejtimit, cilësia e rrugës. Tani nuk e kuptoj më se si funksionon.
Kur fillova tĂ« merrem me Amazon Cloud, edhe pĂ«r mua kjo ishte njĂ« mister. VetĂ«m ky mister Ă«shtĂ« nĂ« njĂ« shkallĂ« mĂ« tĂ« lartĂ«, sepse nĂ« makinĂ« ka njĂ« drejtues, ndĂ«rsa nĂ« AWS janĂ« miliona. TĂ« gjithĂ« pĂ«rdoruesit njĂ«kohĂ«sisht drejtojnĂ«, shtypin gazin dhe frenin. ĂshtĂ« e habitshme se ata shkojnĂ« atje ku duan â pĂ«r mua kjo Ă«shtĂ« njĂ« mrekulli! Sistemi automatikisht adaptohet, skalon dhe pĂ«rshtatet elastikisht me çdo pĂ«rdorues, saqĂ« atij i duket se Ă«shtĂ« vetĂ«m ai nĂ« kĂ«tĂ« Univers.
Magjia paksa u shpërbë kur më vonë erdha të punoja si arkitekt në Amazon. Pashë se me cilat probleme përballeshim, si i zgjidhnim ato dhe si zhvillonim shërbimet. Me rritjen e kuptimit të funksionit të sistemit, besimi në shërbim rritet. Prandaj dëshiroj të ndaj një pamje të atij që ndodhet nën kapakët e AWS Cloud.
Për çfarë do të flasim
Kam zgjedhur njĂ« qasje tĂ« diversifikuar â kam pĂ«rzgjedhur 4 shĂ«rbime interesante qĂ« meritojnĂ« tĂ« flasim.
Optimizimi i serverëve. Cloud-et efemere me një ekzistencë fizike: qendrat e të dhënave fizike, ku ndodhen serverë fizikë, të cilët humbin, ngrohen dhe ndriçohen me drita.
Funksionet pa server (Lambda) â ndoshta shĂ«rbimi mĂ« i shkallĂ«zuar nĂ« cloud.
Zgjerimi i bazës së të dhënave. Do t'ju tregoj se si krijojmë bazat tona të dhënash të zgjerueshme.
Zgjerimi i rrjetit. Pjesa e fundit, ku do tĂ« zbuloj strukturĂ«n e rrjetit tonĂ«. Kjo Ă«shtĂ« njĂ« gjĂ« e mrekullueshme â secili pĂ«rdorues i njohur i cloud-it mendon se Ă«shtĂ« nĂ« cloud vetĂ«m dhe nuk sheh tenantĂ« tĂ« tjerĂ«.
ShĂ«nim. NĂ« kĂ«tĂ« artikull do tĂ« flas pĂ«r optimizimin e serverĂ«ve dhe zgjerimin e bazave tĂ« tĂ« dhĂ«nave. Zgjerimin e rrjetit do ta trajtojmĂ« nĂ« artikullin e ardhshĂ«m. Ku janĂ« funksionet serverless? PĂ«r to ka dalĂ« njĂ« shkrim i veçantĂ« "". NĂ« tĂ« janĂ« treguar disa mĂ«nyra tĂ« ndryshme tĂ« zgjerimit dhe Ă«shtĂ« shqyrtuar me detaje zgjidhja Firecracker â njĂ« simbiozĂ« e cilĂ«sive mĂ« tĂ« mira tĂ« makinerive virtuale dhe konteinerĂ«ve.
Serverët
Cloud-i Ă«shtĂ« efemer. Por kjo efemĂ«si ka njĂ« shprehje fizike â serverĂ«t. Fillimisht, arkitektura e tyre ishte klasike. NjĂ« chipset standard x86, karta rrjeti, Linux, hypervizori Xen, mbi tĂ« cilin ishin aktivizuar makineritĂ« virtuale.
NĂ« vitin 2012, njĂ« arkitekturĂ« e tillĂ« pĂ«rballonte plotĂ«sisht detyrat e saj. Xen Ă«shtĂ« njĂ« hypervizor i shkĂ«lqyer, por me njĂ« disavantazh tĂ« rĂ«ndĂ«sishĂ«m. Ai ka mjaft shpenzime tĂ« larta pĂ«r emulimin e pajisjeve. Me shfaqjen e kartave rrjet mĂ« tĂ« shpejta ose SSD-ve, kĂ«to shpenzime bĂ«hen shumĂ« tĂ« larta. Si tĂ« veprojmĂ« me kĂ«tĂ« problem? VendosĂ«m tĂ« punojmĂ« nĂ« dy fronte â optimizimin e harduerit dhe hipervizorit. Detyra Ă«shtĂ« shumĂ« serioze.
Optimizimi i harduerit dhe hipervizorit
Nuk Ă«shtĂ« e mundur tĂ« bĂ«het gjithçka menjĂ«herĂ« dhe mirĂ«. ĂfarĂ« do tĂ« thotĂ« «mirë», gjithashtu nuk ishte e qartĂ« nĂ« fillim.
VendosĂ«m tĂ« aplikojmĂ« njĂ« qasje evolucionare â ndryshojmĂ« njĂ« element tĂ« rĂ«ndĂ«sishĂ«m tĂ« arkitekturĂ«s dhe e nxjerrim nĂ« prodhim.
Hapim të gjitha pengesat, dëgjojmë ankesat dhe propozimet. Pastaj ndryshojmë një komponent tjetër. Kështu, me inkrementet e vogla, radikalisht ndryshojmë të gjithë arkitekturën mbi bazën e reagimeve nga përdoruesit dhe mbështetjes.
Transformimet filluan nĂ« 2013 me gjĂ«nĂ« mĂ« tĂ« komplikuar â rrjeti. NĂ« C3 instance, iu shtua njĂ« kartĂ« e veçantĂ« Network Accelerator, e cila lidhej me njĂ« kabllo tĂ« shkurtĂ«r loopback nĂ« panelet e pĂ«rparme. Nuk duket bukur, por nuk Ă«shtĂ« e dukshme nĂ« cloud. MegjithatĂ«, interaksioni i drejtpĂ«rdrejtĂ« me harduerin pĂ«rmirĂ«soi ndjeshĂ«m jitter-in dhe kapacitetin e rrjetit.
MĂ« pas, vendosĂ«m tĂ« pĂ«rmirĂ«sojmĂ« qasjen nĂ« ruajtjen e blokut EBS â Elastic Block Storage. Kjo Ă«shtĂ« njĂ« kombinim i rrjetit dhe ruajtjes. VĂ«shtirĂ«sia ishte se, ndonĂ«se nĂ« treg ekzistonin karta Network Accelerator, nuk kishte mundĂ«si tĂ« blenim harduer Storage Accelerator. Prandaj, iu drejtua njĂ« startup Annapurna Labs, i cili zhvilloi pĂ«r ne çipe tĂ« veçanta ASIC. KĂ«ta na lejuan tĂ« lidhnim volume tĂ« largĂ«ta EBS si pajisje NVMe.
NĂ« instancat C4 , zgjidhĂ«m dy çështje. SĂ« pari â realizuam njĂ« pĂ«rgatitje pĂ«r tĂ« ardhmen tĂ« teknologjisĂ« NVMe, qĂ« ishte e re nĂ« atĂ« kohĂ«. SĂ« dyti â ngarkuam ndjeshĂ«m procesorin qendror duke transferuar pĂ«rpunimin e kĂ«rkesave pĂ«r EBS nĂ« kartĂ«n e re. Kjo rezultoi me sukses, ndaj tani Annapurna Labs Ă«shtĂ« pjesĂ« e Amazon.
Derisa arritëm në nëntor 2017, kuptuam se ishte koha të ndryshonim edhe hipervizorin.
Hipervizori i ri u zhvillua mbi modulat e përmirësuara të kernelit KVM.
Ai lejojti një ulje të rëndësishme të kostove të simulimit të pajisjeve dhe të punonte direkt me ASIC të rinj. Instancat C5 ishin virtualizimet e para, nën kapak të cilave funksiononte hipervizori i ri. Ne e quajtëm atë Nitro.
Evolucioni i instancave në një vijë kohore.
Të gjitha llojet e reja të makinave virtuale, të cilat janë shfaqur që nga nëntori 2017, punojnë mbi këtë hypervisor. Instancat e ndërlikuara Bare Metal nuk kanë një hypervisor, por ato quhen gjithashtu Nitro, pasi përdorin karta të specializuara Nitro.
Në dy vitet e ardhshme, numri i llojeve të instancave Nitro e kaloi disa dhjetëra: A1, C5, M5, T3 dhe të tjerë.
Llojet e instancave.
Si janë ndërtuar makinat moderne Nitro
Ato kanë tre komponentë kryesorë: hypervisori Nitro (për të cilin u përmend më parë), çipi i sigurisë dhe kartat Nitro.
Ăipi i sigurisĂ« Ă«shtĂ« i integruar direkt nĂ« pllakĂ«n e nĂ«nĂ«s. Ai kontrollon shumĂ« funksione tĂ« rĂ«ndĂ«sishme, pĂ«r shembull, kontrollin e ngarkesĂ«s sĂ« sistemit operativ host.
Kartat Nitro â ekzistojnĂ« katĂ«r lloje tĂ« tyre. TĂ« gjitha janĂ« zhvilluar nga Annapurna Labs dhe bazohen nĂ« ASIC tĂ« pĂ«rbashkĂ«t. Disa nga firmware e tyre gjithashtu Ă«shtĂ« e pĂ«rbashkĂ«t.
Katër lloje të kartave Nitro.
NjĂ« nga kartat Ă«shtĂ« e destinuar pĂ«r tĂ« punuar me rrjetinVPC. PikĂ«risht ajo duket nĂ« virtualka si karta rrjeti ENA â Elastic Network Adaptor. Ajo gjithashtu inkapsulon trafikun kur e transferon atĂ« pĂ«rmes rrjetit fizik (pĂ«r kĂ«tĂ« do tĂ« flasim nĂ« pjesĂ«n e dytĂ« tĂ« artikullit), kontrollon firewall Security Groups, pĂ«rgjigjet pĂ«r ruterin dhe çështje tĂ« tjera rrjetesh.
Kartat individuale funksionojnë me ruajtjen bllok EBS dhe disqet që janë të ndërtuara në server. Ato paraqiten në makinat virtuale si adapterë NVMe. Po ashtu, ato janë përgjegjëse për enkriptimin e të dhënave dhe monitorimin e disqeve.
Sistemi i kartave Nitro, hipervizori dhe çipi i sigurisë janë të lidhura në një rrjet SDN ose Rrjet të Definuar me Program. Menaxhimi i këtij rrjeti (Control Plane) është i përgjegjshëm nga karta-kontrollore.
Sigurisht, ne vazhdojmë zhvillimin e ASIC të rinj. Për shembull, në fund të vitit 2018, publikuan çipin Inferentia, i cili lehtëson punën me detyrat e mësimit automat.
Ăipi Inferentia Procesori i MĂ«simit Automat.
Baza e të dhënave e shkallëzuar
Një bazë e dhënash tradicionale ka një strukturë të stratifikuar. Nëse e thjeshtojmë shumë, mund të identifikojmë nivelet e mëposhtme.
- SQL â mbi tĂ« punojnĂ« menaxherĂ«t e klientĂ«ve dhe kĂ«rkesave.
- Sigurimi i transaksioneve â kĂ«tu Ă«shtĂ« e qartĂ«, ACID dhe tĂ« tilla.
- Keƥimi, i cili sigurohet nga grupe buferësh.
- Regjistrimi â siguron punĂ«n me logĂ«t e ripĂ«rsĂ«ritjes. NĂ« MySQL ato quhen Bin Logs, nĂ« PosgreSQL â Write Ahead Logs (WAL).
- Ruajtja â nĂ« mĂ«nyrĂ« tĂ« drejtpĂ«rdrejtĂ« regjistrimin nĂ« disk.
Struktura e stratifikuar e bazës së të dhënave.
Ekzistojnë mënyra të ndryshme për të shkallëzuar bazat e të dhënave: sharding, arkitektura Shared Nothing, disqet e ndara.
MegjithatĂ«, tĂ« gjitha kĂ«to metoda ruajnĂ« tĂ« njĂ«jtĂ«n strukturĂ« monolitike tĂ« bazĂ«s sĂ« tĂ« dhĂ«nave. Kjo e kufizon ndjeshĂ«m shkallĂ«zimin. PĂ«r ta zgjidhur kĂ«tĂ« problem, ne zhvilluam databazĂ«n tonĂ« â Amazon Aurora. Ajo Ă«shtĂ« e pĂ«rputhshme me MySQL dhe PostgreSQL.
Amazon Aurora
Ideja kryesore arkitektonike është ndarja e niveleve të ruajtjes dhe regjistrimit nga baza e të dhënave kryesore.
Duke e kaluar përpara, them se niveli i caching-ut e kemi bërë gjithashtu të pavarur. Arkitektura ndalon të jetë një monolit, dhe ne fitojmë liri të mëtejshme në shkallëzimin e blloqeve të veçanta.
Niveli i regjistrimit dhe ruajtjes është i ndarë nga baza e të dhënave.
Një DBMS tradicional regjistron të dhënat në sistemin e ruajtjes në formë bllokesh. Në Amazon Aurora krijuam një magazinë të "mençur", e cila mund të flasë në gjuhën e regjistrave redo. Brenda vetes, magazina i kthen regjistrat në blloqe të dhënash, monitoron integritetin e tyre dhe bëhet automatikisht backup.
Ky qasje mundëson realizimin e gjërave interesante si klonimi. Ai punon në një mënyrë thelbësisht më të shpejtë dhe më ekonomikisht, sepse nuk kërkon krijimin e një kopjeje të plotë të të dhënave.
Niveli i ruajtjes Ă«shtĂ« realizuar si njĂ« sistem tĂ« shpĂ«rndarĂ«. Ai pĂ«rbĂ«het nga njĂ« numĂ«r shumĂ« tĂ« madh serverash fizikĂ«. Ădo redo-log pĂ«rpunoahet dhe ruhet nĂ« tĂ« njĂ«jtĂ«n kohĂ« nga gjashtĂ« nyje. Kjo siguron mbrojtjen e tĂ« dhĂ«nave dhe shpĂ«rndarjen e ngarkesĂ«s.
Mundëm të sigurojmë shkallëzimin e leximit përmes replikave përkatëse. Ruajtja e shpërndarë eliminon nevojën për sinkronizim midis instancës kryesore të DB-së, përmes së cilës ne shkruajmë të dhëna, dhe replikave të tjera. Të dhënat aktuale janë garantuar të jenë të aksesueshme për të gjitha replikat.
Problemi i vetëm është ruajtja e të dhënave të vjetra në replikat e leximit. Por ky problem mund të zgjidhet me transmetimin e të gjithë redo-logëve tek replikat përmes rrjetit të brendshëm. Nëse logu është në cache, ai shënohet si i pavlefshëm dhe shkruhet përsëri. Nëse nuk është në cache, thjesht hidhet poshtë.
E zgjidhëm çështjen e ruajtjes.
Si të shkallëzojmë nivelet e DBMS
Këtu, shkallëzimi horizontal është shumë më i vështirë. Prandaj, do të ndjekim një rrugë të njohur. shkallës së zakonshme të përmasimit vertikal.
Supozoni se kemi një aplikacion që komunikon me DBMS përmes një nodule master.
Në përmasimin vertikal, dedikojmë një nodule të re, e cila do të ketë më shumë procesorë dhe memorie.
Pastaj kalojmë aplikacionin nga nodule master e vjetër në atë të re. Lindin probleme.
- Kjo do të kërkojë një ndalim të konsiderueshëm të aplikacionit.
- Noduli i ri master do të ketë një cache të ftohtë. Përformanca e DB-së do të jetë maksimale vetëm pas ngrohjes së cache-it.
Si ta përmirësojmë situatën? Të vendosim një proxy midis aplikacionit dhe nodulit master.
ĂfarĂ« do tĂ« na japĂ« kjo? Tani tĂ« gjithĂ« aplikacionet nuk kanĂ« nevojĂ« tĂ« redirektohen manualisht nĂ« nodulin e ri. Kalimi mund tĂ« bĂ«het nĂ«n proxy dhe Ă«shtĂ« gjithashtu esencialisht mĂ« i shpejtĂ«.
Duket se problemi Ă«shtĂ« zgjidhur. Po, ne ende vuajmĂ« nga nevoja pĂ«r ngrohjen e cache-it. PĂ«r mĂ« tepĂ«r, shfaqet njĂ« problem i ri â tani proxy Ă«shtĂ« njĂ« pikĂ« potenciale dĂ«shtimi.
Zgjidhja përfundimtare me Amazon Aurora serverless
Si i zgjidhëm këto probleme?
E lanĂ« proxy-n. Ky Ă«shtĂ« njĂ« flotĂ« e shpĂ«rndarĂ« proksish, pĂ«rmes tĂ« cilĂ«s aplikacionet lidhen me bazĂ«n e tĂ« dhĂ«nave. Ădo nyje mund tĂ« zĂ«vendĂ«sohet pothuajse menjĂ«herĂ« nĂ« rast dĂ«shtimi.
Shtuam një grup nyjesh të ngrohta me përmasa të ndryshme. Prandaj, kur do të nevojitet një nyje e re me më shumë ose më pak kapacitet, ajo është menjëherë e disponueshme. Nuk është e nevojshme të presësh për ngarkimin e saj.
I gjithë procesi i shkallëzimit kontrollohet nga një sistem special monitorimi. Monitorimi ndjek vazhdimisht gjendjen e nyjës kryesore aktuale. Nëse zbulohet, për shembull, se ngarkesa në procesor ka arritur një nivel kritik, atëherë njofton grupin e nyjeve të ngrohta për nevojën e rezervimit të një nyjeje të re.
Proksitë e shpërndara, nyjet e ngrohta dhe monitorimi.
Nyja me fuqinë e kërkuar është e disponueshme. Përdoren rezervat buferike dhe sistemi fillon të presë një moment të sigurt për kalimin.
Zakonisht, momenti për kalimin ndodh mjaft shpejt. Atëherë komunikimi midis proksive dhe nyjës kryesore të vjetër pezullohet, të gjitha sesionet kalojnë në nyjen e re.
Puna me bazën e të dhënave rinis.
Në graf është e qartë se pauza është vërtet shumë e shkurtër. Në grafikun blu është ngarkesa, ndërsa në shkallët e kuqe janë momentet e shkallëzimit. Rëniet e shkurtra në grafikun blu janë pikërisht ajo vonesë shumë të shkurtër.
Për më tepër, Amazon Aurora mund të kursejë ndjeshëm dhe të çaktivizojë DB-në kur nuk përdoret, për shembull, gjatë fundjavës. Pas ndalimit, ngarkesa e DB-së redukton gradualisht fuqinë e saj dhe për një kohë të shkurtër ndizet. Kur ngarkesa të kthehet, ajo rritet përsëri ngadalë.
Në pjesën tjetër të diskutimit mbi strukturën e Amazon-it do të flasim për shkallëzimin e rrjetit. Abonohuni dhe ndiqni përditësimet për të mos humbur artikullin.
NĂ« Vasili Pantiukhin do tĂ« mbajĂ« njĂ« raport "". Cilat janĂ« modelet e dizajnit tĂ« sistemeve tĂ« shpĂ«rndara qĂ« pĂ«rdorin zhvilluesit e Amazon, cilat janĂ« arsyet pĂ«r dĂ«shtimet e shĂ«rbimeve, çfarĂ« Ă«shtĂ« arkitektura e bazuar nĂ« qeliza, Puna e QĂ«ndrueshme, Shuffle Sharding â do tĂ« jetĂ« interesante. MĂ« pak se njĂ« muaj deri nĂ« konferencĂ« â . 24 tetor Ă«shtĂ« data e fundit pĂ«r rritjen e çmimeve.
Burimi: habr.com
