Le nuvole sono simili a una magica scatola: chiedi ciò di cui hai bisogno e le risorse appaiono dal nulla. Macchine virtuali, database, rete: tutto appartiene solo a te. Esistono anche altri tenant nel cloud, ma nel tuo universo sei l'unico sovrano. Sei sicuro di ricevere sempre le risorse necessarie, senza dover rendere conto a nessuno, e decidi autonomamente come sarà la rete. Come funziona questa magia che fa sì che il cloud assegni risorse in modo elastico e isoli completamente i tenant tra di loro?
Il cloud AWS è un sistema estremamente complesso che si è evoluto dal 2006. Parte di questa evoluzione ha visto Vasily Pantyukhin — l'architetto Amazon Web Services. Come architetto, vede non solo il risultato finale, ma anche le complessità che AWS affronta. Più comprendi il funzionamento del sistema, maggiore è la fiducia. Perciò, Vasily condividerà i segreti dei servizi cloud AWS. Sotto il titolo, la struttura dei server fisici di AWS, la scalabilità elastica dei database, il database personalizzato di Amazon e i metodi per migliorare le prestazioni delle macchine virtuali, riducendo nel contempo i costi. Conoscere gli approcci architettonici di Amazon aiuterà a utilizzare in modo più efficace i servizi AWS e, forse, fornirà nuove idee per costruire soluzioni proprie.
Chi è il relatore: Vasily Pantyukhin () ha iniziato come amministratore Unix in aziende .ru, ha lavorato per 6 anni su grandi server Sun Microsystem, e per 11 anni ha predicato la centralità dei dati nel mondo in EMC. Si è evoluto naturalmente verso i cloud privati e nel 2017 si è lanciato nei cloud pubblici. Ora offre consigli tecnici per vivere e prosperare nel cloud AWS.
Dichiarazione: tutto ciò che segue è l'opinione personale di Vasily e potrebbe non coincidere con la posizione di Amazon Web Services. del discorso, sulla base del quale è stato redatto l'articolo, è disponibile sul nostro canale YouTube.
Perché parlo della struttura di Amazon
La mia prima auto era con il 'cambio manuale' — con cambio meccanico. Era fantastico per la sensazione di poter controllare l'auto e averne il controllo totale. Mi piaceva anche che avessi almeno una comprensione approssimativa del suo funzionamento. Naturalmente, immaginavo la struttura della trasmissione in modo piuttosto primitivo — più o meno come un cambio di una bicicletta.
Tutto è stato meraviglioso, tranne un aspetto: stare bloccato nel traffico. Sembra che tu stia seduto e non faccia nulla, ma continui a cambiare marcia, premere la frizione, l'acceleratore, il freno — e tutto ciò ti stanca davvero. Il problema del traffico si è parzialmente risolto quando in famiglia è arrivata un'auto con cambio automatico. Alla guida ho avuto il tempo di pensare a qualcosa, di ascoltare un audiolibro.
Inoltre, nella mia vita è apparso un mistero, perché ho smesso di capire come funziona la mia auto. Un'auto moderna è un dispositivo complesso. Si adatta contemporaneamente a decine di parametri diversi: pressione sull'acceleratore, freno, stile di guida, qualità della strada. Non capisco più come funziona.
Quando ho iniziato a lavorare con Amazon Cloud, anche per me era un mistero. Solo che questo mistero è a un livello superiore, perché nell'auto c'è un solo conducente, mentre in AWS ce ne sono milioni. Tutti gli utenti guidano contemporaneamente, premendo l'acceleratore e il freno. È sorprendente che riescano ad andare dove vogliono — per me è un miracolo! Il sistema si adatta automaticamente, si scalda ed è elasticamente configurato per ogni utente, al punto che sembra che sia l'unico in questo universo.
La magia è svanita un po' quando poi sono venuto a lavorare come architetto in Amazon. Ho visto quali problemi affrontiamo, come li risolviamo, come sviluppiamo i servizi. Con la crescita della comprensione del funzionamento del sistema, aumenta la fiducia nel servizio. Perciò voglio condividere l'immagine di ciò che c'è sotto il cofano del cloud AWS.
Di cosa parleremo
Ho scelto un approccio diversificato: ho selezionato 4 servizi interessanti di cui vale la pena parlare.
Ottimizzazione dei server. Nuvole effimere con incarnazione fisica: data center fisici, dove si trovano server fisici che ronzano, si scaldano e lampeggiano.
Funzioni serverless (Lambda) — probabilmente il servizio più scalabile nel cloud.
Scalabilità del database. Racconterò come costruiamo i nostri database scalabili.
Scalabilità della rete. Ultima parte, in cui svelerò l'architettura della nostra rete. È una cosa meravigliosa — ogni utente del cloud sente di essere l'unico nel cloud e non vede affatto gli altri tenant.
Nota. In questo articolo si parlerà dell'ottimizzazione dei server e della scalabilità dei database. La scalabilità della rete verrà trattata nel prossimo articolo. Dove sono le funzioni serverless? Ne è stata pubblicata una spiegazione separata «». In essa vengono discussi diversi metodi di scalabilità, e viene analizzata in dettaglio la soluzione Firecracker, un connubio delle migliori qualità delle macchine virtuali e dei container.
Server
Il cloud è effimero. Ma questa effimereità ha pur sempre una rappresentazione 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, tale architettura gestiva perfettamente i propri compiti. Xen è un ottimo hypervisor, ma ha un serio svantaggio. Ha costi di overhead piuttosto elevati per l'emulazione dei dispositivi. Con l'emergere di nuove schede di rete più veloci o di dischi SSD, questi overhead diventano troppo elevati. Come affrontare questo problema? Abbiamo deciso di lavorare su due fronti: ottimizzare sia l'hardware che l'hypervisor. È un compito molto serio.
Ottimizzazione dell'hardware e dell'hypervisor
Non sarà possibile fare tutto bene e in una volta sola. Cosa significhi "bene" non era chiaro fin dall'inizio.
Abbiamo deciso di applicare un approccio evolutivo: cambiamo un elemento importante dell'architettura e lo mettiamo in produzione.
Incontriamo tutte le difficoltà, ascoltiamo reclami e suggerimenti. Poi modifichiamo un altro componente. Così, con piccoli incrementi, cambiamo radicalmente tutta l'architettura sulla base del feedback da parte degli utenti e del supporto.
Le trasformazioni sono iniziate nel 2013 con la parte più complessa: la rete. In C3 gli istanze, è stata aggiunta una scheda speciale Network Accelerator accanto alla scheda di rete standard. Essa si collegava letteralmente con un cavo di loopback corto sulla parte anteriore. Brutto da vedere, ma nel cloud non si nota. Tuttavia, l'interazione diretta con l'hardware ha migliorato in modo sostanziale il jitter e la capacità di rete.
Successivamente, abbiamo deciso di migliorare l'accesso allo storage a blocchi EBS - Elastic Block Storage. Questa è una combinazione di rete e storage. La difficoltà è che se sul mercato esistevano schede Network Accelerator, non c'era la possibilità di acquistare hardware Storage Accelerator. Pertanto, ci siamo rivolti alla startup Annapurna Labs, che ha sviluppato chip ASIC speciali per noi. Questi hanno permesso di collegare volumi EBS remoti come dispositivi NVMe.
Negli istanze C4 abbiamo risolto due problemi. Il primo è stato quello di realizzare un futuro promettente, ma nuovo all'epoca, con la tecnologia NVMe. Il secondo è stato quello di alleggerire significativamente il processore centrale spostando l'elaborazione delle richieste a EBS su una nuova scheda. È andata bene, quindi ora Annapurna Labs è parte di Amazon.
Entro novembre 2017, abbiamo capito che era giunto il momento di cambiare anche l'ipercloud.
Il nuovo ipervisor è stato sviluppato sulla base di moduli migliorati del kernel KVM.
Ha permesso di ridurre significativamente le spese generali per l'emulazione dei dispositivi e di lavorare direttamente con i nuovi ASIC. Le istanze C5 sono state le prime virtual machine sotto il cofano delle quali opera il nuovo ipervisor. Lo abbiamo chiamato Nitro.
Evoluzione delle istanze su una linea temporale.
Tutti i nuovi tipi di macchine virtuali introdotti da novembre 2017 funzionano su questo ipervisor. Le istanze Bare Metal non hanno un ipervisor, ma vengono anch'esse chiamate Nitro, poiché utilizzano schede Nitro specializzate.
Nei successivi due anni, il numero di tipi di istanze Nitro ha superato diverse decine: A1, C5, M5, T3 e altri.
Tipi di istanze.
Come sono strutturate le moderne macchine Nitro
Hanno tre componenti principali: l'ipercloud Nitro (di cui si è già parlato), il chip di sicurezza e le schede Nitro.
Il chip di sicurezza è integrato direttamente nella scheda madre. Controlla molte funzioni importanti, come il controllo di avvio del SO host.
Le schede Nitro – ne esistono quattro tipi. Tutte sono sviluppate da Annapurna Labs e si basano su ASIC comuni. Parte del loro firmware è anch'esso condiviso.
Quattro tipi di schede Nitro.
Una delle schede è destinata a lavorare con la reteVPC. Questa è visibile nelle virtual machine come scheda di rete ENA — Elastic Network Adaptor. Inoltre incapsula il traffico quando viene trasferito attraverso la rete fisica (di questo parleremo nella seconda parte dell'articolo), controlla il firewall delle Security Groups, si occupa del routing e di altre cose di rete.
Schede separate lavorano con lo storage a blocchi EBS e con i dischi integrati nel server. Per la virtual machine guest, vengono presentati come adattatori NVMe. Inoltre si occupano della crittografia dei dati e del monitoraggio dei dischi.
Il sistema delle schede Nitro, dell'ipercloud e del chip di sicurezza è integrato in una rete SDN o Software Defined Network. Il controllo di questa rete (Control Plane) è gestito da controller della mappa.
Certo, stiamo continuando a sviluppare nuovi ASIC. Ad esempio, alla fine del 2018 abbiamo rilasciato il chip Inferentia, che consente di lavorare in modo più efficiente su compiti di apprendimento automatico.
Chip Inferentia Machine Learning Processor.
Database scalabile
Un database tradizionale ha una struttura a strati. Se semplifichiamo molto, possiamo individuare i seguenti livelli.
- SQL — su di esso operano i gestori dei clienti e delle richieste.
- Forniture transazioni — qui è tutto chiaro, ACID e tutto il resto.
- Caching, che è garantito dai pool di buffer.
- Registrazione — gestisce i redo log. In MySQL sono chiamati Bin Logs, in PosgreSQL — Write Ahead Logs (WAL).
- Archiviazione – scrittura diretta su disco.
Struttura a strati del database.
Esistono diversi modi per scalare i database: sharding, architettura Shared Nothing, dischi condivisi.
Tuttavia, tutti questi metodi mantengono la stessa struttura monolitica del database. Questo limita notevolmente la scalabilità. Per risolvere questo problema, abbiamo sviluppato il nostro database — Amazon Aurora. È compatibile con MySQL e PostgreSQL.
Amazon Aurora
L'idea architettonica principale è separare i livelli di archiviazione e logging dal database principale.
Anticipando, posso dire che abbiamo reso il livello di caching anche indipendente. L'architettura smette di essere un monolite e otteniamo ulteriori gradi di libertà nella scalabilità dei singoli blocchi.
I livelli di logging e archiviazione sono separati dal database.
Un DBMS tradizionale scrive i dati sul sistema di archiviazione in blocchi. In Amazon Aurora abbiamo creato un'archiviazione "intelligente" che può comunicare nel linguaggio dei redo log. All'interno, l'archiviazione converte i log in blocchi di dati, ne controlla l'integrità e realizza automaticamente i backup.
Questo approccio consente di realizzare cose interessanti come il cloning. Funziona in modo significativamente più veloce ed economico poiché non richiede la creazione di una copia completa di tutti i dati.
Il livello di archiviazione è realizzato come un sistema distribuito. Esso consiste in un numero molto elevato di server fisici. Ogni redo log viene elaborato e salvato contemporaneamente da sei nodi. Questo garantisce protezione dei dati e distribuzione del carico.
La scalabilità in lettura può essere garantita attraverso replica appropriate. Lo storage distribuito elimina la necessità di sincronizzazione tra l'istanza principale del database, da cui scriviamo i dati, e le altre repliche. I dati aggiornati sono garantiti come accessibili a tutte le repliche.
L'unico problema è la memorizzazione nella cache di dati obsoleti sulle repliche di lettura. Ma questo problema si risolve trasferendo tutti i redo-log alle repliche tramite la rete interna. Se il log è in cache, viene contrassegnato come non valido e sovrascritto. Se non è presente in cache, viene semplicemente scartato.
Abbiamo chiarito la questione dello storage.
Come scalare i livelli del DBMS
Qui la scalabilità orizzontale è molto più complessa. Dunque, seguiremo la strada già battuta della scalabilità verticale classica..
Supponiamo di avere un'applicazione che interagisce con il DBMS tramite un nodo master.
Con la scalabilità verticale, dedichiamo un nuovo nodo che avrà più processori e memoria.
Successivamente, spostiamo l'applicazione dal vecchio nodo master al nuovo. Ci sono problemi.
- Questo richiederà un notevole downtime 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? Inserire un proxy tra l'applicazione e il nodo master.
Cosa ci garantirà questo? Ora tutte le applicazioni non devono essere reindirizzate manualmente al nuovo nodo. Il passaggio può avvenire sotto il proxy e sarà sostanzialmente più veloce.
Sembra che il problema sia risolto. Ma no, soffriamo ancora della necessità di riscaldamento della cache. Inoltre, è emerso un nuovo problema: ora il proxy è un potenziale punto di guasto.
La soluzione finale con Amazon Aurora serverless
Come abbiamo risolto questi problemi?
Abbiamo mantenuto il proxy. Non è un'istanza separata, ma un'intera flotta distribuita di proxy, attraverso la quale le applicazioni si connettono al database. Qualsiasi nodo, in caso di guasto, può essere sostituito praticamente in un istante.
Abbiamo aggiunto un pool di nodi caldi di diverse dimensioni. Quindi, quando è necessario allocare un nuovo nodo di dimensioni maggiori o minori, è subito disponibile. Non è necessario aspettare che venga caricato.
L'intero processo di scalabilità è controllato da un sistema di monitoraggio speciale. Il monitoraggio controlla costantemente lo stato dell'attuale master node. Se rileva, ad esempio, che il carico della CPU ha raggiunto un valore critico, avverte il pool di istanze pronte della necessità di allocare un nuovo nodo.
Proxy distribuiti, istanze pronte e monitoraggio.
Un nodo con la potenza richiesta è disponibile. I buffer pool vengono copiati su di esso e il sistema inizia ad aspettare un momento sicuro per il switch.
Di solito, il momento per il switch arriva piuttosto rapidamente. La comunicazione tra il proxy e il vecchio master node viene quindi interrotta, tutte le sessioni vengono reindirizzate al nuovo nodo.
Il lavoro con il database riprende.
Nel grafico è evidente che l'interruzione è davvero molto breve. Nel grafico blu c'è il carico, mentre nei gradini rossi ci sono i momenti di scalabilità. Le brevi cadute nel grafico blu rappresentano proprio quel breve ritardo.
A proposito, Amazon Aurora permette di risparmiare e di spegnere il database quando non è utilizzato, ad esempio, nel fine settimana. Dopo lo spegnimento, il carico del database riduce gradualmente la sua potenza e si spegne per un certo periodo. Quando il carico ritorna, esso risale nuovamente gradualmente.
Nella prossima parte del racconto sull'architettura di Amazon parleremo della scalabilità della rete. Iscriviti e segui gli aggiornamenti per non perdere l'articolo.
A Vasily Pantiukhin presenterà la relazione "". Quali pattern di design dei sistemi distribuiti usano gli sviluppatori di Amazon, quali possono essere le cause di guasti nei servizi, cosa significa architettura basata su celle, lavoro costante, shuffle sharding – sarà interessante. Meno di un mese alla conferenza – . Il 24 ottobre ci sarà un aumento dei prezzi definitivo.
Fonte: habr.com
