Questo articolo contiene alcuni modelli comuni per aiutare gli ingegneri a lavorare con servizi su larga scala a cui accedono milioni di utenti.
Secondo l'esperienza dell'autore, questo non è un elenco esaustivo, ma sì efficace consiglio. Quindi, cominciamo.
Tradotto con supporto .
Entry level
Le misure elencate di seguito sono relativamente semplici da attuare ma hanno un impatto elevato. Se non li hai mai provati prima, rimarrai sorpreso dai miglioramenti significativi.
Infrastruttura come codice
La prima parte del consiglio è implementare l'infrastruttura come codice. Ciò significa che è necessario disporre di un modo programmatico per distribuire l'intera infrastruttura. Sembra complicato, ma in realtà stiamo parlando del seguente codice:
Distribuzione di 100 macchine virtuali
- con Ubuntu
- 2 GB di RAM ciascuno
- avranno il seguente codice
- con questi parametri
Puoi tenere traccia delle modifiche alla tua infrastruttura e ripristinarle rapidamente utilizzando il controllo della versione.
Il modernista che è in me dice che puoi usare Kubernetes/Docker per fare tutto quanto sopra, e ha ragione.
Inoltre, puoi fornire automazione utilizzando Chef, Puppet o Terraform.
Integrazione e distribuzione continua
Per creare un servizio scalabile, è importante disporre di una pipeline di compilazione e test per ogni richiesta pull. Anche se il test è molto semplice, garantirà almeno che il codice distribuito venga compilato.
Ogni volta in questa fase rispondi alla domanda: il mio assembly verrà compilato e superato i test, è valido? Può sembrare un livello basso, ma risolve molti problemi.
Non c'è niente di più bello che vedere queste zecche
Per questa tecnologia puoi valutare Github, CircleCI o Jenkins.
Bilanciatori del carico
Quindi, vogliamo eseguire un bilanciatore del carico per reindirizzare il traffico e garantire lo stesso carico su tutti i nodi o il servizio continua in caso di errore:
Un bilanciatore del carico di solito fa un buon lavoro nel distribuire il traffico. La migliore pratica è quella di sbilanciare in modo da non avere un singolo punto di guasto.
In genere, i bilanciatori del carico sono configurati nel cloud che utilizzi.
RayID, ID di correlazione o UUID per le richieste
Hai mai riscontrato un errore dell'applicazione con un messaggio come questo: "Qualcosa è andato storto. Salva questo ID e invialo al nostro team di supporto"?
Un identificatore univoco, ID di correlazione, RayID o qualsiasi variante è un identificatore univoco che consente di tenere traccia di una richiesta durante tutto il suo ciclo di vita. Ciò consente di tenere traccia dell'intero percorso della richiesta nei log.
L'utente effettua una richiesta al sistema A, quindi A contatta B, che contatta C, la memorizza in X, quindi la richiesta viene restituita ad A
Se dovessi connetterti in remoto alle macchine virtuali e provare a tracciare il percorso della richiesta (e correlare manualmente quali chiamate vengono effettuate), diventeresti pazzo. Avere un identificatore univoco rende la vita molto più semplice. Questa è una delle cose più semplici che puoi fare per risparmiare tempo man mano che il tuo servizio cresce.
Livello medio
Qui i consigli sono più complessi dei precedenti, ma gli strumenti giusti facilitano il compito, garantendo un ritorno sull’investimento anche per le piccole e medie imprese.
Registrazione centralizzata
Congratulazioni! Hai distribuito 100 macchine virtuali. Il giorno successivo, il CEO arriva e si lamenta di un errore ricevuto durante il test del servizio. Riporta l'ID corrispondente di cui abbiamo parlato sopra, ma dovrai cercare nei log di 100 macchine per trovare quella che ha causato l'arresto anomalo. E bisogna trovarlo prima della presentazione di domani.
Anche se sembra un'avventura divertente, è meglio assicurarti di avere la possibilità di cercare tutte le riviste in un unico posto. Ho risolto il problema della centralizzazione dei log utilizzando la funzionalità integrata dello stack ELK: supporta la raccolta di log ricercabili. Questo aiuterà davvero a risolvere il problema di trovare un diario specifico. Come bonus, puoi creare grafici e altre cose divertenti del genere.
Funzionalità dello stack ELK
Agenti di monitoraggio
Ora che il tuo servizio è attivo e funzionante, devi assicurarti che funzioni senza intoppi. Il modo migliore per farlo è eseguirne diversi agenti, che funzionano in parallelo e controllano che funzioni e che vengano eseguite le operazioni di base.
A questo punto controllalo la build da corsa sembra buona e funziona bene.
Per progetti di piccole e medie dimensioni, consiglio Postman per il monitoraggio e la documentazione delle API. Ma in generale, vuoi solo assicurarti di avere un modo per sapere quando si è verificata un'interruzione ed essere avvisato in modo tempestivo.
Scalabilità automatica in base al carico
È molto semplice. Se hai richieste di manutenzione di una VM e l'utilizzo della memoria si avvicina all'80%, puoi aumentarne le risorse o aggiungere più VM al cluster. L'esecuzione automatica di queste operazioni è ottima per variazioni di potenza elastica sotto carico. Ma dovresti sempre stare attento a quanti soldi spendi e fissare limiti ragionevoli.
Con la maggior parte dei servizi cloud, puoi configurarli per la scalabilità automatica utilizzando più server o server più potenti.
Sistema di esperimenti
Un buon modo per implementare in sicurezza gli aggiornamenti è poter testare qualcosa per l'1% degli utenti per un'ora. Naturalmente avete visto tali meccanismi in azione. Ad esempio, Facebook mostra a parti del pubblico un colore diverso o modifica la dimensione del carattere per vedere come gli utenti percepiscono i cambiamenti. Questo si chiama test A/B.
Anche il rilascio di una nuova funzionalità può essere avviato come esperimento e poi determinato come rilasciarlo. Hai anche la possibilità di "ricordare" o modificare la configurazione al volo in base alla funzione che sta causando il degrado del tuo servizio.
Livello avanzato
Ecco alcuni suggerimenti che sono piuttosto difficili da implementare. Probabilmente avrai bisogno di un po' più di risorse, quindi un'azienda di piccole o medie dimensioni avrà difficoltà a gestirle.
Schieramenti blu-verdi
Questo è quello che io chiamo il modo di svolgersi "Erlang". Erlang divenne ampiamente utilizzato con la comparsa delle compagnie telefoniche. I softswitch iniziarono ad essere utilizzati per instradare le chiamate telefoniche. Lo scopo principale del software su questi switch era di non interrompere le chiamate durante gli aggiornamenti del sistema. Erlang ha un modo carino di caricare un nuovo modulo senza mandare in crash quello precedente.
Questo passaggio dipende dalla presenza di un bilanciatore del carico. Immaginiamo che tu abbia la versione N del tuo software e quindi desideri distribuire la versione N+1.
Voi potuto basta interrompere il servizio e implementare la versione successiva in un momento adatto ai tuoi utenti e ottenere tempi di inattività. Ma supponiamo di averlo fatto davvero rigorose condizioni SLA. Quindi, SLA del 99,99% significa che puoi andare offline solo di 52 minuti all'anno.
Se vuoi davvero raggiungere tali indicatori, hai bisogno di due implementazioni contemporaneamente:
- quello che è adesso (N);
- versione successiva (N+1).
Dici al bilanciatore del carico di reindirizzare una percentuale di traffico alla nuova versione (N+1) mentre monitori attivamente le regressioni.
Qui abbiamo una distribuzione N verde che funziona correttamente. Stiamo cercando di passare alla versione successiva di questa distribuzione
Per prima cosa inviamo un piccolo test per vedere se la nostra distribuzione N+1 funziona con una piccola quantità di traffico:
Infine, disponiamo di una serie di controlli automatizzati che eseguiamo fino al completamento della distribuzione. Se tu molto molto attenzione, puoi anche salvare la tua distribuzione N per sempre per un rapido rollback in caso di regressione errata:
Se vuoi passare a un livello ancora più avanzato, lascia che tutto nella distribuzione blu-verde venga eseguito automaticamente.
Rilevamento delle anomalie e mitigazione automatica
Dato che disponi di una registrazione centralizzata e di una buona raccolta di registri, puoi già impostare obiettivi più elevati. Ad esempio, prevedere in modo proattivo i guasti. Le funzioni vengono tracciate sui monitor e nei registri e vengono creati vari diagrammi - e puoi prevedere in anticipo cosa andrà storto:
Una volta rilevate le anomalie, si inizia ad esaminare alcuni degli indizi forniti dal servizio. Ad esempio, un picco nel carico della CPU potrebbe indicare che un disco rigido non funziona, mentre un picco nelle richieste potrebbe indicare che è necessario aumentare le prestazioni. Questo tipo di dati statistici permette di rendere il servizio proattivo.
Con queste informazioni, puoi scalare qualsiasi dimensione e modificare in modo proattivo e reattivo le caratteristiche di macchine, database, connessioni e altre risorse.
Questo è tutto!
Questo elenco di priorità ti farà risparmiare molti problemi se stai creando un servizio cloud.
L'autore dell'articolo originale invita i lettori a lasciare i propri commenti e apportare modifiche. L'articolo è distribuito come open source, richieste pull dall'autore .
Cos'altro leggere sull'argomento:
Fonte: habr.com