Le nuvole sono simili a una scatola magica: chiedi ciò di cui hai bisogno e le risorse compaiono dal nulla. Macchine virtuali, database, rete: tutto ciò appartiene solo a te. Ci sono anche altri tenant nel cloud, ma nel tuo universo sei il solo sovrano. Sei sicuro di ricevere sempre le risorse richieste, senza dover renderne conto a nessuno e decidi autonomamente come sarà la rete. Come funziona questa magia che consente al cloud di allocare risorse in modo elastico e di isolare completamente i tenant dagli altri?
Il cloud AWS è un sistema super complesso che si è evoluto dal 2006. Parte di questo sviluppo ha visto Vasili Pantuichin — architetto di Amazon Web Services. In qualità di architetto, ha una visione interna non solo del risultato finale, ma anche delle sfide affrontate da AWS. Maggiore è la comprensione del funzionamento del sistema, maggiore è la fiducia. Pertanto, Vasiliy condividerà i segreti dei servizi cloud di AWS. Scoprite la struttura dei server fisici AWS, la scalabilità elastica del database, il database personalizzato di Amazon e i metodi per migliorare le prestazioni delle macchine virtuali riducendo al contempo i costi. La conoscenza degli approcci architettonici di Amazon aiuterà a utilizzare più efficacemente i servizi AWS e potrebbe dare nuove idee per costruire soluzioni proprie.
Sul relatore: Vasiliy Pantyukhin () ha iniziato come amministratore Unix in aziende .ru, ha lavorato per 6 anni con grandi macchine Sun Microsystems e per 11 anni ha predicato la centralità dei dati in EMC. È evoluto naturalmente verso i cloud privati e nel 2017 è passato ai pubblici. Attualmente offre consigli tecnici per vivere e svilupparsi nel cloud AWS.
Disclaimer: tutto ciò che segue è l'opinione personale di Vasiliy e potrebbe non corrispondere alla posizione di Amazon Web Services. della presentazione da cui è stato creato l'articolo è disponibile sul nostro canale YouTube.
Perché parlo del dispositivo Amazon
La mia prima automobile aveva il cambio manuale. Era fantastico per via della sensazione di poter controllare completamente l'auto. Mi piaceva anche l'idea di capire bene il suo funzionamento. Naturalmente, avevo una concezione piuttosto primitiva della trasmissione, più o meno come quella di una bicicletta.
Tutto andava bene, tranne una cosa: stare nel traffico. È come se stessi seduto e non facessi nulla, ma continui a cambiare marcia, ad azionare la frizione, a accelerare e frenare — ti stanchi davvero. Il problema del traffico si è parzialmente risolto quando in famiglia è arrivata un'auto automatica. Alla guida, ho avuto tempo per riflettere su alcune cose e ascoltare un audiolibro.
È comparsa anche un'enigma nella mia vita, perché ho smesso di capire come funziona la mia auto. Un'auto moderna è un dispositivo complesso. Si adatta simultaneamente a decine di parametri diversi: accelerazione, frenata, stile di guida, qualità della strada. Non capisco più come funzioni.
Quando ho iniziato a lavorare con Amazon Cloud, anche per me era un mistero. Solo che questo mistero è su un altro livello, perché in un veicolo c'è un solo guidatore, mentre in AWS ce ne sono milioni. Tutti gli utenti sterzano, accelerano e frenano contemporaneamente. È sorprendente che riescano ad andare dove vogliono — per me è un miracolo! Il sistema si adatta automaticamente, si scalda e si adatta in modo elastico per ogni utente, tanto che sembra che sia l'unico in quest'universo.
La magia è svanita un po' quando ho iniziato a lavorare come architetto in Amazon. Ho visto quali problemi affrontiamo, come li risolviamo e come sviluppiamo i servizi. Con una maggiore comprensione del funzionamento del sistema, aumenta la fiducia nel servizio. Perciò voglio condividere un quadro di ciò che c'è dietro le quinte 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 ci sono server fisici che ronzano, si riscaldano e lampeggiano.
Funzioni serverless (Lambda) — probabilmente il servizio più scalabile nel cloud.
Scalabilità del database. Vi parlerò di come costruiamo i nostri database scalabili.
Scalabilità della rete. Nella parte finale, svelerò la struttura della nostra rete. È una meraviglia: ogni utente del cloud si sente come se fosse solo nel cloud e non vede affatto gli altri tenant.
Nota. In questo articolo si parlerà di ottimizzazione dei server e scalabilità dei database. La scalabilità della rete verrà trattata nel prossimo articolo. E le funzioni serverless? Su di esse è stata pubblicata una trascrizione separata «». In essa sono descritti diversi modi di scalare e viene analizzata in dettaglio la soluzione Firecracker, un'autentica fusione delle migliori caratteristiche delle macchine virtuali e dei container.
Server
Il cloud è effimero. Tuttavia, questa effimera qualità ha comunque una rappresentazione fisica: i server. Inizialmente, la loro architettura era classica. Un chipset standard x86, schede di rete, Linux, un hypervisor Xen, su cui venivano eseguite le macchine virtuali.
Nel 2012, tale architettura gestiva perfettamente i propri compiti. Xen è un ottimo hypervisor, ma presenta un grave svantaggio. Ha una abbastanza elevati costi di emulazione dei dispositivi. Con l'arrivo di nuove schede di rete più veloci o dischi SSD, questi costi diventano troppo elevati. Come affrontare questo problema? Abbiamo deciso di lavorare su due fronti contemporaneamente — ottimizzare sia l'hardware che l'ipervisor. Il compito è molto serio.
Ottimizzazione dell'hardware e dell'ipervisor
Non sarà possibile fare tutto bene subito. Cosa significhi "bene" non era chiaro fin dall'inizio.
Abbiamo deciso di adottare un approccio evolutivo — cambiamo un elemento importante dell'architettura e lo lanciamo in produzione.
Affrontiamo tutte le sfide, ascoltiamo lamentele e suggerimenti. Poi modifichiamo un altro componente. Così, con piccoli incrementi, cambiamo radicalmente l'intera architettura basandoci sul feedback degli utenti e del supporto.
Le trasformazioni sono iniziate nel 2013 con la parte più complessa — la rete. In C3 negli istanze, abbiamo aggiunto alla scheda di rete standard una scheda speciale chiamata Network Accelerator. Veniva collegata letteralmente con un breve cavo loopback nella parte anteriore. Non esteticamente gradevole, ma nel cloud non è visibile. Tuttavia, l'interazione diretta con l'hardware ha migliorato drasticamente jitter e larghezza di banda della rete.
Abbiamo deciso di migliorare l'accesso all'archiviazione a blocchi EBS — Elastic Block Storage. Questa è una combinazione di rete e archiviazione. La difficoltà era che, sebbene esistessero schede Network Accelerator sul mercato, non c'era la possibilità di acquistare hardware Storage Accelerator. Quindi, ci siamo rivolti a una startup Annapurna Labs, che ha sviluppato per noi chip ASIC speciali. Questi ci hanno permesso di collegare i volumi EBS remoti come dispositivi NVMe.
Negli istanze C4 abbiamo risolto due problemi. Il primo — abbiamo realizzato una base per il futuro utilizzando la promettente, ma allora nuova, tecnologia NVMe. Il secondo — abbiamo notevolmente alleggerito il processore centrale spostando l'elaborazione delle richieste verso EBS su una nuova scheda. È andato bene, quindi ora Annapurna Labs è parte di Amazon.
Entro novembre 2017, abbiamo capito che era tempo di cambiare anche l'hypervisor stesso.
Il nuovo hypervisor è stato sviluppato sulla base di moduli core KVM migliorati.
Questo ha consentito di ridurre drasticamente l'overhead di emulazione dei dispositivi e di lavorare direttamente con i nuovi ASIC. Le istanze C5 sono state le prime virtual machines a avere sotto il cofano il nuovo hypervisor. Lo abbiamo chiamato Nitro.
L'evoluzione delle istanze sulla linea temporale.
Tutti i nuovi tipi di macchine virtuali emersi da novembre 2017 operano su questo hypervisor. Le istanze Bare Metal non hanno un hypervisor, ma vengono comunque chiamate Nitro, poiché utilizzano schede Nitro specializzate.
Nei due anni successivi, il numero di tipologie di istanze Nitro ha superato diverse decine: A1, C5, M5, T3 e altre.
Tipi di istanze.
Come sono strutturate le moderne macchine Nitro
Esse hanno tre componenti principali: l'hypervisor Nitro (di cui si è parlato prima), un chip di sicurezza e le schede Nitro.
Chip di sicurezza è integrato direttamente nella scheda madre. Controlla molte funzioni importanti, come il controllo dell'avvio del sistema operativo host.
Schede Nitro — esistono quattro tipi. Tutte sono sviluppate da Annapurna Labs e si basano su ASIC comuni. Parte del loro firmware è anch'esso comune.
Quattro tipi di schede Nitro.
Una delle schede è progettata per lavorare con la reteVPC. Essa è visibile nelle macchine virtuali come scheda di rete ENA — Elastic Network Adaptor. Inoltre, incapsula il traffico quando viene inviato attraverso la rete fisica (di questo parleremo nella seconda parte dell'articolo), controlla il firewall Security Groups, gestisce il routing e altre questioni di rete.
Le schede separate funzionano con lo storage a blocchi EBS e i dischi integrati nel server. Per la macchina virtuale, vengono presentati come adattatori NVMe. Sono responsabili anche della crittografia dei dati e del monitoraggio dei dischi.
Il sistema delle schede Nitro, dell'hypervisor e del chip di sicurezza è connesso a una rete SDN o Software Defined Network. La gestione di questa rete (Control Plane) è affidata a una scheda controller.
Naturalmente, continuiamo a sviluppare nuovi ASIC. Ad esempio, alla fine del 2018 abbiamo lanciato il chip Inferentia, che consente di lavorare in modo più efficiente con i compiti di machine learning.
Chip Inferentia Machine Learning Processor.
Database scalabile
Un database tradizionale ha una struttura a strati. Se semplifichiamo molto, possiamo individuare i seguenti livelli.
- SQL — gestisce i client e le richieste.
- Gestione delle transazioni — qui è tutto chiaro, ACID e tutto il resto.
- Caching, che è fornito da pool di buffer.
- Log — gestisce i redo log. In MySQL sono chiamati Bin Logs, in PostgreSQL — Write Ahead Logs (WAL).
- Archiviazione – scrittura diretta su disco.
Struttura a strati del database.
Esistono diversi metodi 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 è quella di separare i livelli di archiviazione e logging dal database principale.
Anticipando, posso dire che anche il livello di caching è stato reso indipendente. L'architettura smette di essere un monolite, e otteniamo maggiore flessibilità nella scalabilità dei singoli componenti.
I livelli di logging e archiviazione sono separati dal database.
Un tradizionale DBMS registra i dati su un sistema di archiviazione in blocchi. In Amazon Aurora abbiamo creato uno storage «intelligente» che può comunicare nel linguaggio dei redo log. Al suo interno, lo storage trasforma i log in blocchi di dati, ne controlla l'integrità e esegue automaticamente backup.
Questo approccio consente di realizzare cose molto interessanti come clonazione. Funziona in modo significativamente più veloce e conveniente grazie al fatto che non richiede la creazione di una copia completa di tutti i dati.
Il livello di archiviazione è realizzato come un sistema distribuito. Esso è composto da un numero molto elevato di server fisici. Ogni redo-log viene elaborato e salvato simultaneamente da sei nodi. Questo garantisce la protezione dei dati e la distribuzione del carico.
La scalabilità in lettura può essere assicurata tramite repliche appropriate. L'archiviazione distribuita elimina la necessità di sincronizzazione tra l'istanza principale del database, attraverso la quale registriamo i dati, e le altre repliche. I dati attuali sono garantiti disponibili a tutte le repliche.
L'unico problema è la memorizzazione nella cache di vecchi dati sulle repliche di lettura. Ma questo compito è risolvibile trasmettendo tutti i redo-log alle repliche tramite una rete interna. Se il log è nella cache, viene contrassegnato come non valido e riscritto. Se non è presente nella cache, viene semplicemente scartato.
Abbiamo chiarito l'archiviazione.
Come scalare i livelli del DBMS
Qui, la scalabilità orizzontale diventa molto più complessa. Quindi, seguiamo un percorso ben battuto. scalabilità verticale classica.
Immaginiamo di avere un'applicazione che comunica con un DBMS attraverso un nodo master.
Con la scalabilità verticale, creiamo un nuovo nodo con più processori e memoria.
Poi spostiamo l'applicazione dal vecchio nodo master al nuovo. Si presentano dei problemi.
- Questo comporterà un significativo downtime dell'applicazione.
- Il nuovo nodo master avrà una cache fredda. Le prestazioni del DB saranno massime solo dopo il riscaldamento della cache.
Come migliorare la situazione? Posizionare un proxy tra l'applicazione e il nodo master.
Cosa ci porterà questo? Ora tutte le applicazioni non devono essere reindirizzate manualmente al nuovo nodo. Lo switch può avvenire attraverso il proxy e sarà sostanzialmente più veloce.
Sembra che il problema sia risolto. Ma no, stiamo ancora affrontando la necessità di riscaldare la cache. Inoltre, è emerso un nuovo problema: ora il proxy è un potenziale punto di errore.
Soluzione finale con Amazon Aurora serverless
Come abbiamo risolto questi problemi?
Abbiamo mantenuto il proxy. Non si tratta di un'istanza isolata, ma di un'intera flotta distribuita di proxy tramite cui le applicazioni si collegano al database. Qualsiasi nodo può essere sostituito praticamente istantaneamente in caso di guasto.
Abbiamo aggiunto un pool di nodi caldi di diverse dimensioni. Pertanto, se è necessario allocare un nuovo nodo di dimensioni superiori o inferiori, è subito disponibile. Non è necessario aspettare che venga caricato.
L'intero processo di scalabilità è controllato da un sistema di monitoraggio specializzato. Il monitoraggio tiene costantemente d'occhio lo stato dell'attuale nodo master. Se rileva, ad esempio, che il carico della CPU ha raggiunto un valore critico, avvisa il pool di istanze calde della necessità di allocare un nuovo nodo.
Proxy distribuiti, istanze calde e monitoraggio.
Un nodo della potenza richiesta è disponibile. I pool di buffer vengono copiati su di esso e il sistema inizia ad attendere un momento sicuro per il passaggio.
Di solito, il momento per il passaggio arriva abbastanza rapidamente. Allora la comunicazione tra il proxy e il vecchio nodo master viene sospesa, tutte le sessioni vengono trasferite sul nuovo nodo.
Il lavoro con il database riprende.
Nel grafico si può vedere che l'interruzione è davvero molto breve. Nel grafico blu c'è il carico, e sui gradini rossi ci sono i momenti di scalabilità. I brevi cali nel grafico blu sono esattamente quella breve latenza.
A proposito, Amazon Aurora permette di risparmiare davvero disattivando il database quando non è in uso, ad esempio nei fine settimana. Dopo l'arresto, il carico del database diminuisce gradualmente e viene disattivato per un certo tempo. Quando il carico ritorna, si riattiva dolcemente.
Nella prossima parte del racconto sull'architettura di Amazon parleremo della scalabilità della rete. Iscriviti e rimani aggiornato per non perdere l'articolo.
Su Vasiliy Pantyukhin presenterà il suo intervento “”. Quali pattern di progettazione dei sistemi distribuiti usano gli sviluppatori di Amazon, quali possono essere le cause dei guasti dei servizi, che cos'è l'architettura Cell-based, il lavoro costante, lo Shuffle Sharding — sarà interessante. Mancano meno di un mese alla conferenza — . Il 24 ottobre ci sarà l'ultimo aumento dei prezzi.
Fonte: habr.com
