I nuvuli sò cum'è una scatula magica - dumandate ciò chì avete bisognu, è e risorse appariscenu solu da nunda. Macchine virtuale, basa di dati, rete - tuttu questu appartene solu à voi. Ci sò altri inquilini di nuvola, ma in u vostru Universu site l'unicu regnu. Siate sicuru chì riceverete sempre i risorsi necessarii, ùn pigliate micca in contu à nimu è determinate indipindentamente quale serà a reta. Cumu funziona sta magia chì face chì u nuvulu alloca elasticamente risorse è isolà cumplettamente l'inquilini l'un l'altru?
A nuvola AWS hè un sistema mega-super cumplessu chì hà evolutu evolutivamente da u 2006. Una parte di stu sviluppu hè accadutu Vasily Pantyukhin - Architettu Amazon Web Services. Cum'è un architettu, riceve un sguardu internu micca solu à u risultatu finali, ma ancu à e sfide chì AWS supera. A più grande a cunniscenza di cumu u sistema funziona, più grande a fiducia. Dunque, Vasily sparterà i sicreti di i servizii di nuvola AWS. Quì sottu hè u disignu di i servitori fisici AWS, a scalabilità di a basa di dati elastica, una basa di dati Amazon persunalizata è i metudi per aumentà a prestazione di e macchine virtuali mentre riducendu simultaneamente u so prezzu. A cunniscenza di l'approcciu architetturale di Amazon vi aiuterà à aduprà i servizii AWS in modu più efficace è vi darà idee novi per custruisce e vostre solu suluzione.
À propositu di u parlante: Vasily Pantyukhin () hà iniziatu cum'è amministratore Unix in cumpagnie .ru, hà travagliatu annantu à un grande hardware Sun Microsystem per 6 anni, è hà pridicatu un mondu centratu in dati in EMC per 11 anni. Naturalmente hà evolutu in nuvuli privati, è in 2017 si trasfirìu à i publichi. Avà furnisce cunsiglii tecnichi per aiutà à vive è sviluppà in u nuvulu AWS.
Disclaimer: tuttu quì sottu hè l'opinione persunale di Vasily è ùn pò micca coincide cù a pusizione di Amazon Web Services. U rapportu nantu à quale l'articulu hè basatu hè dispunibule nantu à u nostru canale YouTube.
Perchè parlu di u dispusitivu Amazon?
A mo prima vittura avia una trasmissione manuale. Hè stata fantastica per via di a sensazione chì puderia guidà a vittura è avè un cuntrollu tutale. Mi piacia ancu chì, almenu, aghju capitu u principiu di u so funziunamentu. Naturalmente, aghju imaginatu a struttura di a scatula per esse abbastanza primitiva - qualcosa cum'è una scatula di trasmissione nantu à una bicicletta.
Tuttu era grande, eccettu per una cosa - stuck in traffic jams. Sembra chì site pusatu è ùn fate nunda, ma cambiate constantemente l'ingranaggi, pressendu l'embrague, u gasu, u frenu - hè veramente stancu. U prublema di u trafficu hè stata risolta parzialmente quandu a famiglia hà acquistatu una vittura automatica. Mentre guidava, aghju avutu u tempu di pensà à qualcosa è à sente un audiobook.
Un altru misteru apparsu in a mo vita, perchè ùn aghju micca cumplettamente capitu cumu funziona a mo vittura. Una vittura muderna hè un dispusitivu cumplessu. A vittura si adatta simultaneamente à decine di paràmetri diffirenti: pressendu u gasu, frenu, stile di guida, qualità di strada. Ùn capiscu più cumu funziona.
Quandu aghju cuminciatu à travaglià nantu à a nuvola di Amazon, era ancu un misteru per mè. Solu stu misteru hè un ordine di grandezza più grande, perchè ci hè un cunduttore in a vittura, è in AWS ci sò milioni di elli. Tutti l'utilizatori dirigenu simultaneamente, pressu u gasu è u frenu. Hè maravigghiusu ch'elli vanu induve volenu - hè un miraculu per mè ! U sistema s'adatta automaticamente, scala è s'adatta elasticamente à ogni utilizatore per chì li pare ch'ellu hè solu in questu Universu.
A magia s'hè spenta un pocu quandu dopu vinni à travaglià cum'è architettu in Amazon. Aghju vistu quali prublemi facemu, cumu risolvemu, è cumu sviluppemu servizii. Cù una cunniscenza crescente di u funziunamentu di u sistema, appare più fiducia in u serviziu. Allora vogliu sparte una foto di ciò chì hè sottu u cappucciu di u nuvulu AWS.
Di chì parlemu
Aghju sceltu un approcciu diversificatu - aghju sceltu 4 servizii interessanti chì valenu a pena di parlà.
Ottimisazione di u servitore. Nuvole effimeri cù una incarnazione fisica: centri di dati fisici induve ci sò servitori fisici chì hum, riscaldanu è lampeggianu cù luci.
Funzioni senza server (Lambda) hè probabilmente u serviziu più scalabile in u nuvulu.
Scala di basa di dati. Vi dicu cumu custruemu a nostra propria basa di dati scalabile.
Scala di rete. L'ultima parte in quale aghju apertu u dispusitivu di a nostra reta. Questa hè una cosa maravigliosa - ogni utilizatore di nuvola crede chì hè solu in u nuvulu è ùn vede micca altri inquilini.
Nota. Questu articulu discuterà l'ottimisazione di u servitore è a scala di basa di dati. Avemu da cunsiderà a scala di rete in u prossimu articulu. Induve sò e funzioni senza servitore? Una trascrizione separata hè stata publicata annantu à elli "" Parla di parechji metudi di scaling differente, è discute in detail a suluzione Firecracker - una simbiosi di e migliori qualità di una macchina virtuale è cuntenituri.
I servitori
A nuvola hè effimera. Ma questu ephemeralità hà sempre una incarnazione fisica - i servitori. In principiu, a so architettura era classica. Chipset x86 standard, carte di rete, Linux, ipervisore Xen nantu à quale e macchine virtuali sò state eseguite.
In u 2012, sta architettura facia bè cù i so compiti. Xen hè un grande ipervisore, ma hà un inconveniente maiò. Ne hà abbastanza alta sopratuttu per l'emulazione di u dispositivu. Cum'è novi carte di rete più veloci o unità SSD sò dispunibuli, questu overhead diventa troppu altu. Cumu affruntà stu prublema? Avemu decisu di travaglià in dui fronti à una volta - ottimisate l'hardware è l'hypervisor. U compitu hè assai seriu.
Ottimisazione di hardware è ipervisore
Fà tuttu in una volta è fà bè ùn hà micca travagliatu. Ciò chì era "bonu" era ancu pocu chjaru inizialmente.
Avemu decisu di piglià un accostu evolutivu - cambiamu un elementu impurtante di l'architettura è lanciamu in a produzzione.
Passemu ogni rake, ascoltemu lagnanza è suggerimenti. Allora cambiamu un altru cumpunente. Dunque, in picculi incrementi, cambiamu radicalmente l'architettura sana basatu annantu à i feedback di l'utilizatori è u supportu.
A trasfurmazioni principia in u 2013 cù u più cumplessu - a reta. IN С3 In casi, una carta speciale Network Accelerator hè stata aghjunta à a carta di rete standard. Hè stata cunnessa literalmente cù un cortu cable loopback in u pannellu frontale. Ùn hè micca bellu, ma ùn hè micca visibile in u nuvulu. Ma l'interazzione diretta cù u hardware hà migliuratu fundamentalmente u jitter è u throughput di a rete.
Dopu avemu decisu di migliurà l'accessu per bluccà u almacenamentu di dati EBS - Elastic Block Storage. Hè una cumminazione di rete è almacenamiento. A difficultà hè chì mentre e carte Network Accelerator esistevanu in u mercatu, ùn ci era micca opzione per cumprà solu hardware Storage Accelerator. Allora avemu vultatu à una startup Annapurna Labs, chì hà sviluppatu chips ASIC speciali per noi. Anu permessu à i volumi EBS remoti per esse muntati cum'è dispositi NVMe.
In casi C4 avemu risoltu dui prublemi. U primu hè chì avemu implementatu una fundazione per u futuru di promettenti, ma novu in quellu tempu, tecnulugia NVMe. Siconda, avemu scaricatu significativamente u processatore cintrali trasferendu u prucessu di e dumande à EBS à una nova carta. Hè risultatu bè, cusì avà Annapurna Labs face parte di Amazon.
Da nuvembre 2017, avemu capitu chì era ora di cambià l'ipervisore stessu.
U novu hypervisor hè statu sviluppatu basatu annantu à i moduli di kernel KVM modificati.
Hè permessu di riduce fundamentalmente l'overhead di l'emulazione di u dispusitivu è travaglià direttamente cù novi ASIC. Instanzi С5 eranu i primi machini virtuali cù un novu hypervisor chì curria sottu à u cappucciu. L'avemu chjamatu dima.
Evoluzione di i casi nantu à u timeline.
Tutti i novi tipi di macchine virtuali chì sò apparsu da nuvembre 2017 correnu nantu à questu hypervisor. I casi Bare Metal ùn anu micca un ipervisore, ma sò ancu chjamati Nitro, postu chì utilizanu carte Nitro specializate.
Nant'à i dui anni dopu, u numeru di tippi di istanze Nitro superò un paru di decine: A1, C5, M5, T3 è altri.
Tipi di istanza.
Cumu travaglianu e moderne macchine Nitro
Hanu trè cumpunenti principali: l'ipervisore Nitro (discussu sopra), u chip di sicurezza è e carte Nitro.
Chip di sicurità integrata direttamente in a scheda madre. Cuntrolla assai funzioni impurtanti, cum'è u cuntrollu di a carica di l'OS di l'ospite.
carte nitro - Ci sò quattru tipi di elli. Tutti sò sviluppati da Annapurna Labs è sò basati in ASIC cumuni. Certi di u so firmware hè ancu cumuni.
Quattru tipi di carte Nitro.
Una di e carte hè pensata per travaglià reteVPC. Questu hè ciò chì hè visibile in e macchine virtuale cum'è una carta di rete ENA - Adattatore di rete elastica. Hè ancu incapsula u trafficu quandu u trasmette per una reta fisica (parleremu di questu in a seconda parte di l'articulu), cuntrola u firewall di i Gruppi di Sicurezza, è hè rispunsevule per u routing è altre cose di a rete.
Selezziunate carte funzionanu cù u almacenamentu di bloccu EBS è dischi chì sò integrati in u servitore. Parvenu à a macchina virtuale invitati cum'è adattatori NVMe. Sò ancu rispunsevuli di a criptografia di dati è u monitoraghju di u discu.
U sistema di carte Nitro, ipervisore è chip di sicurità hè integratu in una reta SDN o Rete Definita da u Software. Responsabile di a gestione di sta rete (Plane di cuntrollu) carta di cuntrollu.
Di sicuru, cuntinuemu à sviluppà novi ASIC. Per esempiu, à a fine di 2018 anu liberatu u chip Inferentia, chì vi permette di travaglià in modu più efficau cù i travaglii di machine learning.
Inferentia Machine Learning Processor chip.
Database scalabile
Una basa di dati tradiziunale hà una struttura in strati. Per simplificà assai, i seguenti livelli sò distinti.
- SQL - i clienti è i dispatchers di dumanda travaglianu nantu à questu.
- Pruvisioni transazzioni - tuttu hè chjaru quì, ACID è tuttu ciò.
- caching, chì hè furnitu da i buffer pools.
- Logging - furnisce u travagliu cù redo logs. In MySQL sò chjamati Bin Logs, in PosgreSQL - Write Ahead Logs (WAL).
- Storage - registrazione diretta à u discu.
Struttura di basa di dati in strati.
Ci hè parechje manere di scala di basa di dati: sharding, architettura Shared Nothing, dischi spartuti.
Tuttavia, tutti questi metudi mantenenu a stessa struttura di basa di dati monolitica. Questu limita significativamente a scala. Per risolve stu prublema, avemu sviluppatu a nostra propria basa di dati - Amazon Aurora. Hè cumpatibile cù MySQL è PostgreSQL.
Amazon Aurora
L'idea principale di l'architettura hè di separà i livelli di almacenamento è logu da a basa di dati principale.
In u futuru, dicu chì avemu ancu fattu u livellu di caching indipendente. L'architettura cessa di esse un monolitu, è guadagnemu gradi supplementari di libertà in scaling blocchi individuali.
I livelli di logging è di almacenamiento sò separati da a basa di dati.
Un DBMS tradiziunale scrive dati à un sistema di almacenamiento in forma di blocchi. In Amazon Aurora, avemu creatu un almacenamentu intelligente chì pò parlà lingua rifà i logs. Dentru, l'almacenamiento trasforma i logs in blocchi di dati, monitoreghja a so integrità è automaticamente back up.
Stu approcciu vi permette di implementà e cose interessanti cum'è clonazione. Funziona fundamentalmente più veloce è più economicamente per u fattu chì ùn hè micca bisognu di creà una copia cumpleta di tutti i dati.
A capa di almacenamiento hè implementata cum'è un sistema distribuitu. Hè custituitu da un gran numaru di servitori fisichi. Ogni log redo hè trattatu è salvatu simultaneamente sei nodi. Questu assicura a prutezzione di dati è l'equilibriu di carica.
A scala di lettura pò esse ottenuta usendu repliche adatte. L'almacenamiento distribuitu elimina a necessità di sincronizazione trà l'istanza di a basa di dati principale, per mezu di quale scrivemu dati, è e repliche restante. A data up-to-date hè garantita per esse dispunibule per tutte e repliche.
L'unicu prublema hè a cache di dati antichi nantu à repliche di lettura. Ma stu prublema hè risolta trasferimentu di tutti i redo logs à repliche nantu à a reta interna. Se u logu hè in a cache, hè marcatu cum'è incorrectu è soprascritto. S'ellu ùn hè micca in u cache, hè solu scartatu.
Avemu risoltu u almacenamentu.
Cumu scala i livelli DBMS
Quì, a scala horizontale hè assai più difficiule. Allora andemu per a strada battuta scala verticale classica.
Assumimu chì avemu una applicazione chì cumunica cù u DBMS per un node maestru.
Quandu scaling vertically, assignemu un novu node chì avarà più processori è memoria.
Dopu, cambiamu l'applicazione da u vechju node maestru à u novu. I prublemi sò.
- Questu richiederà un tempu di inattività significativa di l'applicazione.
- U novu nodu maestru averà cache friddu. A prestazione di a basa di dati serà massima solu dopu chì a cache hè riscaldata.
Cumu migliurà a situazione? Configurate un proxy trà l'applicazione è u node maestru.
Chì ci darà questu? Avà tutte l'applicazioni ùn anu micca bisognu di esse redirette manualmente à u novu node. U cambiamentu pò esse fattu sottu un proxy è hè fundamentalmente più veloce.
Sembra chì u prublema hè stata risolta. Ma nò, soffremu sempre da a necessità di riscalda u cache. Inoltre, un novu prublema hè apparsu - avà u proxy hè un puntu potenziale di fallimentu.
Soluzione finale cù Amazon Aurora serverless
Cumu avemu risolve sti prublemi?
Lasciatu un proxy. Questu ùn hè micca un esempiu separatu, ma una flotta intera distribuita di proxy per mezu di quale l'applicazioni si cunnetta à a basa di dati. In casu di fallimentu, qualsiasi di i nodi pò esse rimpiazzati quasi istantaneamente.
Aggiuntu una piscina di nodi caldi di diverse dimensioni. Per quessa, s'ellu hè necessariu di assignà un novu node di una dimensione più grande o più chjuca, hè immediatamente dispunibule. Ùn ci hè bisognu di aspittà per carica.
Tuttu u prucessu di scala hè cuntrullatu da un sistema di surviglianza speciale. U monitoraghju monitora constantemente u statu di u nodu maestru attuale. Se detecta, per esempiu, chì a carica di u processatore hà righjuntu un valore criticu, notifica à a piscina di istanze calde nantu à a necessità di assignà un novu node.
Proxy distribuiti, istanze calde e monitoraggio.
Un node cù u putere necessariu hè dispunibule. I buffer pools sò copiati in questu, è u sistema cumencia à aspittà per un mumentu sicuru per cambià.
Di solitu u mumentu di cambià vene abbastanza rapidamente. Allora a cumunicazione trà u proxy è u vechju node maestru hè sospesa, tutte e sessioni sò cambiate à u novu node.
U travagliu cù a basa di dati riprende.
U graficu mostra chì a sospensjoni hè veramente assai corta. U graficu blu mostra a carica, è i passi rossi mostranu i mumenti di scala. L'immersioni à cortu termine in u graficu blu sò precisamente quellu ritardu curtu.
Per via, Amazon Aurora permette di risparmià cumplettamente soldi è disattivà a basa di dati quandu ùn hè micca in usu, per esempiu, in u weekend. Dopu avè firmatu a carica, a DB riduce gradualmente u so putere è si spegne per qualchì tempu. Quandu a carica torna, risurrerà di novu.
In a prossima parte di a storia di u dispusitivu Amazon, avemu da parlà di scala di rete. Abbonate è stà cunnessu per ùn mancate micca l'articulu.
nantu Vasily Pantyukhin darà un rapportu "" Chì mudelli di cuncepimentu per i sistemi distribuiti sò utilizati da i sviluppatori di Amazon, chì sò i motivi per i fallimenti di u serviziu, ciò chì hè l'architettura basata in Cell, Constant Work, Shuffle Sharding - serà interessante. Meno di un mese finu à a cunferenza - . U 24 d'ottobre aumentu di u prezzu finali.
Source: www.habr.com