Le nuvole sono come una scatola magica: chiedi ciò di cui hai bisogno e le risorse appaiono dal nulla. Macchine virtuali, database, rete: tutto questo appartiene solo a te. Ci sono altri inquilini del cloud, ma nel tuo Universo sei l'unico sovrano. Sei sicuro che riceverai sempre le risorse richieste, non prendi in considerazione nessuno e determini autonomamente come sarà la rete. Come funziona questa magia che fa sì che il cloud allochi in modo elastico le risorse e isoli completamente gli inquilini gli uni dagli altri?
Il cloud AWS è un sistema mega-supercomplesso che si è evoluto in modo evolutivo dal 2006. Parte di questo sviluppo ha avuto luogo Vasily Pantyukhin - Architetto di servizi Web di Amazon. In qualità di architetto, può dare uno sguardo approfondito non solo al risultato finale, ma anche alle sfide che AWS supera. Maggiore è la comprensione di come funziona il sistema, maggiore è la fiducia. Pertanto, Vasily condividerà i segreti dei servizi cloud AWS. Di seguito è riportata la progettazione dei server fisici AWS, la scalabilità del database elastico, un database Amazon personalizzato e metodi per aumentare le prestazioni delle macchine virtuali riducendone contemporaneamente il prezzo. La conoscenza degli approcci architetturali di Amazon ti aiuterà a utilizzare i servizi AWS in modo più efficace e potrebbe darti nuove idee per creare le tue soluzioni.
Informazioni sull'oratore: Vasily Pantyukhin () ha iniziato come amministratore Unix presso aziende .ru, ha lavorato su hardware Sun Microsystem di grandi dimensioni per 6 anni e ha predicato un mondo incentrato sui dati in EMC per 11 anni. Si è evoluto naturalmente nei cloud privati, per poi passare nel 2017 a quelli pubblici. Ora fornisce consulenza tecnica per aiutare a vivere e sviluppare nel cloud AWS.
Dichiarazione di non responsabilità: tutto ciò che segue rappresenta l'opinione personale di Vasily e potrebbe non coincidere con la posizione di Amazon Web Services. Il rapporto su cui si basa l'articolo è disponibile sul nostro canale YouTube.
Perché sto parlando del dispositivo Amazon?
La mia prima macchina aveva il cambio manuale. È stato fantastico perché avevo la sensazione di poter guidare la macchina e di averne il controllo completo. Mi è piaciuto anche il fatto di aver compreso almeno approssimativamente il principio del suo funzionamento. Naturalmente, ho immaginato che la struttura della scatola fosse piuttosto primitiva, qualcosa come il cambio di una bicicletta.
Tutto è andato benissimo, tranne una cosa: bloccato nel traffico. Sembra che tu sia seduto e non faccia nulla, ma cambi continuamente marcia, premi la frizione, l'acceleratore, il freno: ti rende davvero stanco. Il problema degli ingorghi è stato parzialmente risolto quando la famiglia ha acquistato un'auto con cambio automatico. Durante la guida, ho avuto il tempo di pensare a qualcosa e di ascoltare un audiolibro.
Un altro mistero è apparso nella mia vita, perché ho smesso completamente di capire come funziona la mia macchina. Un'auto moderna è un dispositivo complesso. L'auto si adatta contemporaneamente a decine di parametri diversi: pressione del gas, freno, stile di guida, qualità della strada. Non capisco più come funziona.
Quando ho iniziato a lavorare sul cloud di Amazon, anche per me era un mistero. Solo che questo mistero è un ordine di grandezza maggiore, perché c'è un conducente nell'auto e ce ne sono milioni in AWS. Tutti gli utenti sterzano, premono l'acceleratore e frenano contemporaneamente. È incredibile che vadano dove vogliono: per me è un miracolo! Il sistema si adatta, ridimensiona e si adatta automaticamente in modo elastico a ciascun utente in modo che gli sembri solo in questo Universo.
La magia svanì un po’ quando più tardi cominciai a lavorare come architetto presso Amazon. Ho visto quali problemi affrontiamo, come li risolviamo e come sviluppiamo i servizi. Con una maggiore comprensione di come funziona il sistema, appare maggiore fiducia nel servizio. Quindi voglio condividere un'immagine di cosa c'è sotto il cofano del cloud AWS.
Di cosa dovremmo parlare
Ho scelto un approccio diversificato: ho selezionato 4 servizi interessanti di cui vale la pena parlare.
Ottimizzazione del server. Nuvole effimere con un'incarnazione fisica: data center fisici dove ci sono server fisici che ronzano, si riscaldano e lampeggiano con le luci.
Funzioni senza server (Lambda) è probabilmente il servizio più scalabile nel cloud.
Ridimensionamento del database. Ti parlerò di come costruiamo i nostri database scalabili.
Scalabilità della rete. L'ultima parte in cui aprirò il dispositivo della nostra rete. Questa è una cosa meravigliosa: ogni utente del cloud crede di essere solo nel cloud e di non vedere affatto gli altri inquilini.
Nota. Questo articolo discuterà dell'ottimizzazione del server e del ridimensionamento del database. Considereremo la scalabilità della rete nel prossimo articolo. Dove sono le funzioni serverless? Su di loro è stata pubblicata una trascrizione separata “" Parla di diversi metodi di ridimensionamento e discute in dettaglio la soluzione Firecracker: una simbiosi delle migliori qualità di una macchina virtuale e di contenitori.
Server
La nuvola è effimera. Ma questa effimera ha ancora un'incarnazione fisica: i server. Inizialmente, la loro architettura era classica. Chipset x86 standard, schede di rete, Linux, hypervisor Xen su cui venivano eseguite le macchine virtuali.
Nel 2012, questa architettura ha affrontato abbastanza bene i suoi compiti. Xen è un ottimo hypervisor, ma presenta un grosso inconveniente. Ne ha abbastanza sovraccarico elevato per l'emulazione del dispositivo. Man mano che diventano disponibili nuove schede di rete o unità SSD, questo sovraccarico diventa troppo elevato. Come affrontare questo problema? Abbiamo deciso di lavorare su due fronti contemporaneamente: ottimizzare sia l'hardware che l'hypervisor. Il compito è molto serio.
Ottimizzazione dell'hardware e dell'hypervisor
Fare tutto in una volta e farlo bene non funzionerà. Inizialmente non era chiaro nemmeno cosa fosse “buono”.
Abbiamo deciso di adottare un approccio evolutivo: cambiamo un elemento importante dell'architettura e lo mettiamo in produzione.
Calpestiamo ogni rastrello, ascoltiamo lamentele e suggerimenti. Quindi cambiamo un altro componente. Quindi, con piccoli incrementi, cambiamo radicalmente l'intera architettura in base al feedback degli utenti e al supporto.
La trasformazione è iniziata nel 2013 con la cosa più complessa: la rete. IN S3 In alcuni casi, alla scheda di rete standard è stata aggiunta una speciale scheda Network Accelerator. Era collegato letteralmente con un breve cavo loopback sul pannello frontale. Non è carino, ma non è visibile nel cloud. Ma l'interazione diretta con l'hardware ha sostanzialmente migliorato il jitter e il throughput della rete.
Successivamente abbiamo deciso di migliorare l'accesso allo storage dei dati a blocchi EBS - Elastic Block Storage. È una combinazione di rete e archiviazione. La difficoltà è che, sebbene sul mercato esistessero le schede Network Accelerator, non esisteva la possibilità di acquistare semplicemente l'hardware Storage Accelerator. Quindi ci siamo rivolti ad una startup Laboratori Annapurna, che ha sviluppato per noi speciali chip ASIC. Hanno consentito il montaggio di volumi EBS remoti come dispositivi NVMe.
In alcuni casi C4 abbiamo risolto due problemi. Il primo è che abbiamo implementato le basi per il futuro della tecnologia NVMe promettente, ma nuova per quel momento. In secondo luogo, abbiamo alleggerito in modo significativo il processore centrale trasferendo l'elaborazione delle richieste a EBS su una nuova carta. È andata bene, quindi ora Annapurna Labs fa parte di Amazon.
A novembre 2017 ci siamo resi conto che era giunto il momento di cambiare l’hypervisor stesso.
Il nuovo hypervisor è stato sviluppato sulla base di moduli kernel KVM modificati.
Ha permesso di ridurre sostanzialmente il sovraccarico dell'emulazione del dispositivo e di lavorare direttamente con i nuovi ASIC. Istanze S5 sono state le prime macchine virtuali con un nuovo hypervisor in esecuzione sotto il cofano. Gli abbiamo dato un nome Nitro.
Evoluzione delle istanze sulla sequenza temporale.
Tutti i nuovi tipi di macchine virtuali apparsi da novembre 2017 funzionano su questo hypervisor. Le istanze Bare Metal non hanno un hypervisor, ma sono anche chiamati Nitro, poiché utilizzano carte Nitro specializzate.
Nei due anni successivi, il numero di tipi di istanze Nitro ha superato un paio di dozzine: A1, C5, M5, T3 e altri.
Tipi di istanza.
Come funzionano le moderne macchine Nitro
Hanno tre componenti principali: l'hypervisor Nitro (discusso sopra), il chip di sicurezza e le carte Nitro.
Chip di sicurezza integrato direttamente nella scheda madre. Controlla molte funzioni importanti, come il controllo del caricamento del sistema operativo host.
Carte Nitro - Ce ne sono quattro tipi. Tutti sono sviluppati da Annapurna Labs e si basano su ASIC comuni. Anche alcuni dei loro firmware sono comuni.
Quattro tipi di carte Nitro.
Una delle carte è progettata per funzionare con ReteVPC. Questo è ciò che è visibile nelle macchine virtuali come scheda di rete ENA - Adattatore di rete elastica. Incapsula anche il traffico quando lo trasmette attraverso una rete fisica (ne parleremo nella seconda parte dell'articolo), controlla il firewall dei gruppi di sicurezza ed è responsabile del routing e di altri aspetti della rete.
Alcune carte funzionano con l'archiviazione a blocchi EBS e dischi integrati nel server. Appaiono alla macchina virtuale guest come Adattatori NVMe. Sono anche responsabili della crittografia dei dati e del monitoraggio del disco.
Il sistema di carte Nitro, hypervisor e chip di sicurezza è integrato in una rete SDN o Rete definita dal software. Responsabile della gestione di questa rete (piano di controllo) scheda di controllo.
Naturalmente continuiamo a sviluppare nuovi ASIC. Ad esempio, alla fine del 2018 è stato rilasciato il chip Inferentia, che consente di lavorare in modo più efficiente con attività di machine learning.
Chip del processore di apprendimento automatico Inferentia.
Database scalabile
Un database tradizionale ha una struttura a strati. Per semplificare notevolmente si distinguono i seguenti livelli.
- SQL — il client e i dispatcher delle richieste ci lavorano.
- Disposizioni transazioni - qui è tutto chiaro, ACID e tutto il resto.
- Caching, fornito dai pool buffer.
- Registrazione — fornisce lavoro con i registri di ripetizione. In MySQL si chiamano Bin Logs, in PosgreSQL - Write Ahead Logs (WAL).
- Conservazione – registrazione diretta su disco.
Struttura del database a strati.
Esistono diversi modi per ridimensionare i database: sharding, architettura Shared Nothing, dischi condivisi.
Tuttavia, tutti questi metodi mantengono la stessa struttura di database monolitica. Ciò limita notevolmente il ridimensionamento. Per risolvere questo problema, abbiamo sviluppato il nostro database − Amazon Aurora. È compatibile con MySQL e PostgreSQL.
Amazon Aurora
L'idea architettonica principale è quella di separare i livelli di archiviazione e registrazione dal database principale.
Guardando al futuro, dirò che abbiamo reso indipendente anche il livello di memorizzazione nella cache. L'architettura cessa di essere un monolite e otteniamo ulteriori gradi di libertà nel ridimensionare i singoli blocchi.
I livelli di registrazione e archiviazione sono separati dal database.
Un DBMS tradizionale scrive i dati su un sistema di archiviazione sotto forma di blocchi. Noi di Amazon Aurora abbiamo creato uno storage intelligente in grado di parlare il linguaggio redo-log. All'interno, lo spazio di archiviazione trasforma i registri in blocchi di dati, ne monitora l'integrità ed esegue automaticamente il backup.
Questo approccio ti consente di implementare cose interessanti come clonazione. Funziona sostanzialmente più velocemente ed economicamente perché non richiede la creazione di una copia completa di tutti i dati.
Il livello di archiviazione è implementato come un sistema distribuito. È costituito da un numero molto elevato di server fisici. Ogni registro di ripristino viene elaborato e salvato simultaneamente sei nodi. Ciò garantisce la protezione dei dati e il bilanciamento del carico.
Il ridimensionamento della lettura può essere ottenuto utilizzando repliche appropriate. Lo storage distribuito elimina la necessità di sincronizzazione tra l'istanza del database principale, attraverso la quale scriviamo i dati, e le restanti repliche. È garantita la disponibilità dei dati aggiornati per tutte le repliche.
L'unico problema è la memorizzazione nella cache dei vecchi dati sulle repliche di lettura. Ma questo problema è in via di risoluzione trasferimento di tutti i registri di ripetizione alle repliche sulla rete interna. Se il registro è nella cache, viene contrassegnato come errato e sovrascritto. Se non è nella cache, viene semplicemente scartato.
Abbiamo sistemato lo spazio di archiviazione.
Come scalare i livelli DBMS
Qui il ridimensionamento orizzontale è molto più difficile. Quindi andiamo lungo i sentieri battuti scala verticale classica.
Supponiamo di avere un'applicazione che comunica con il DBMS tramite un nodo master.
Quando si scala verticalmente, allochiamo un nuovo nodo che avrà più processori e memoria.
Successivamente, trasferiamo l'applicazione dal vecchio nodo master a quello nuovo. Sorgono problemi.
- Ciò richiederà tempi di inattività significativi dell'applicazione.
- Il nuovo nodo master avrà una cache fredda. Le prestazioni del database saranno massime solo dopo il riscaldamento della cache.
Come migliorare la situazione? Configura un proxy tra l'applicazione e il nodo master.
Cosa ci darà questo? Ora tutte le applicazioni non devono essere reindirizzate manualmente al nuovo nodo. Il passaggio può essere effettuato tramite proxy ed è fondamentalmente più veloce.
Sembra che il problema sia stato risolto. Ma no, soffriamo ancora della necessità di scaldare la cache. Inoltre, è apparso un nuovo problema: ora il proxy è un potenziale punto di fallimento.
Soluzione finale con Amazon Aurora serverless
Come abbiamo risolto questi problemi?
Ha lasciato una delega. Questa non è un'istanza separata, ma un'intera flotta distribuita di proxy attraverso i quali le applicazioni si connettono al database. In caso di guasto, qualsiasi nodo può essere sostituito quasi istantaneamente.
Aggiunto un pool di nodi caldi di varie dimensioni. Pertanto, se è necessario allocare un nuovo nodo di dimensione maggiore o minore, esso è immediatamente disponibile. Non c'è bisogno di aspettare che venga caricato.
L'intero processo di ridimensionamento è controllato da uno speciale sistema di monitoraggio. Il monitoraggio monitora costantemente lo stato del nodo master corrente. Se rileva, ad esempio, che il carico del processore ha raggiunto un valore critico, notifica al pool di istanze warm la necessità di allocare un nuovo nodo.
Proxy distribuiti, istanze warm e monitoraggio.
È disponibile un nodo con la potenza richiesta. I pool di buffer vengono copiati su di esso e il sistema inizia ad attendere un momento sicuro per effettuare il passaggio.
Di solito il momento di cambiare arriva abbastanza rapidamente. Quindi la comunicazione tra il proxy e il vecchio nodo master viene sospesa, tutte le sessioni vengono trasferite al nuovo nodo.
Il lavoro con il database riprende.
Il grafico mostra che la sospensione è effettivamente molto breve. Il grafico blu mostra il carico e i gradini rossi mostrano i momenti di scala. I cali a breve termine nel grafico blu rappresentano esattamente quel breve ritardo.
A proposito, Amazon Aurora ti consente di risparmiare completamente denaro e di disattivare il database quando non è in uso, ad esempio nei fine settimana. Dopo aver fermato il carico, il DB riduce gradualmente la sua potenza e si spegne per qualche tempo. Quando il carico ritorna, salirà di nuovo senza intoppi.
Nella parte successiva della storia del dispositivo Amazon, parleremo della scalabilità della rete. sottoscrivi e rimanete sintonizzati per non perdere l'articolo.
Su Vasily Pantyukhin farà un rapporto “" Quali modelli di progettazione per i sistemi distribuiti vengono utilizzati dagli sviluppatori Amazon, quali sono le ragioni dei guasti del servizio, cos'è l'architettura basata su celle, Constant Work, Shuffle Sharding: sarà interessante. Meno di un mese alla conferenza - . 24 ottobre ultimo aumento di prezzo.
Fonte: habr.com