Questo documento nel Framework dell'architettura Google Cloud fornisce principi di progettazione per progettare i tuoi servizi in modo che possano è in grado di tollerare gli errori e fare lo scale in risposta alla domanda dei clienti. Un servizio affidabile continua a rispondere alle richieste dei clienti quando c'è una domanda elevata per il servizio o quando c'è un evento di manutenzione. I seguenti principi di progettazione dell'affidabilità le best practice dovrebbero fare parte dell'architettura del sistema e del piano di deployment.
Crea ridondanza per una maggiore disponibilità
I sistemi con esigenze di affidabilità elevate non devono avere single point of failure e le loro risorse devono essere replicate su più domini in errore. Un dominio in errore un pool di risorse che possono generare errori in modo indipendente, come un'istanza VM, una zona o regione. Quando replichi tra domini in errore, ottieni un valore aggregato più elevato rispetto alle singole istanze. Per ulteriori informazioni le informazioni, vedi Regioni e zone.
Come esempio specifico di ridondanza che potrebbe far parte del sistema per isolare gli errori nella registrazione DNS nelle singole zone, utilizzare nomi DNS di zona per consentire l'accesso reciproca tra le istanze sulla stessa rete.
Progetta un'architettura multizona con failover per l'alta disponibilità
Rendi la tua applicazione resiliente agli errori a livello di zona progettandola per usare pool di risorse distribuite in più zone, con replica dei dati e bilanciamento del carico e failover automatico tra zone. Esegui repliche a livello di zona di ogni livello dell'applicazione ed eliminare tutte le dipendenze tra zone nell'architettura.
Replica i dati tra regioni per il ripristino di emergenza
Replica o archivia i dati in una regione remota per abilitare il ripristino di emergenza nel di un'interruzione del servizio o di una perdita di dati a livello di regione. Se si utilizza la replica, il recupero perché i sistemi di archiviazione nella regione remota dispongono già di dati i dati sono quasi aggiornati, a parte la possibile perdita di una piccola quantità a causa di un ritardo di replica. Quando utilizzi l'archiviazione periodica anziché continua replica, ripristino di emergenza prevede il ripristino di dati da backup o archivi in una nuova regione. Questa procedura di solito comporta tempi di inattività più lunghi rispetto all'attivazione continua replica del database aggiornata e potrebbe comportare una maggiore perdita di dati a causa dell'intervallo di tempo tra operazioni di backup consecutive. Qualunque sia l'approccio utilizzato, l'intera applicazione sia necessario eseguire nuovamente il deployment e avviare lo stack nella nuova regione, non sarà disponibile durante l'operazione.
Per una discussione dettagliata sui concetti e le tecniche di ripristino di emergenza, vedi Architettura del ripristino di emergenza per le interruzioni dell'infrastruttura cloud.
Progetta un'architettura multiregionale per la resilienza alle interruzioni regionali
Se il servizio deve essere eseguito ininterrottamente anche nel raro caso in cui un'intera regione un errore, progettala in modo da utilizzare pool di risorse di calcolo distribuite in diverse regioni. Esegui repliche a livello di regione di ogni livello dello stack di applicazioni.
Usa la replica dei dati tra regioni e il failover automatico quando una regione verso il basso. Alcuni servizi Google Cloud hanno varianti multiregionali, ad esempio Spanner. Per garantire resilienza contro gli errori a livello di regione, utilizza questi servizi multiregionali ove possibile. Per ulteriori informazioni su regioni e servizi la disponibilità, consulta Località di Google Cloud.
Assicurati che non ci siano dipendenze tra regioni, in modo che l'ampiezza l'impatto di un errore a livello di regione è limitato a quella regione.
Elimina i single point of failure a livello di regione, ad esempio un database principale a regione singola che potrebbero causare un'interruzione globale quando non sono raggiungibili. Tieni presente che più regioni architetture spesso costano di più, quindi considera le esigenze aziendali rispetto al costo prima di adottare questo approccio.
Per ulteriori indicazioni sull'implementazione della ridondanza tra domini in errore, consulta l'articolo Deployment di archetipi per applicazioni cloud (PDF).
Elimina i colli di bottiglia della scalabilità
Identifica i componenti del sistema che non possono superare i limiti di risorse di un una singola VM o una singola zona. Alcune applicazioni scalano in verticale, dove puoi aggiungere più core CPU, memoria o larghezza di banda di rete su una singola istanza VM per l'aumento del carico. La scalabilità di queste applicazioni presenta limiti rigidi, e spesso devi configurarle manualmente per gestire la crescita.
Se possibile, riprogetta questi componenti per scalarli orizzontalmente, come sharding o parziale tra VM o zone. Per gestire la crescita del traffico all'utilizzo, aggiungi altri shard. Utilizza tipi di VM standard che possono essere aggiunti automaticamente per gestire l'aumento del carico per ogni shard. Per ulteriori informazioni, vedi Pattern per app scalabili e resilienti.
Se non riesci a riprogettare l'applicazione, puoi sostituire i componenti gestiti da te con servizi cloud completamente gestiti progettati per la scalabilità orizzontale senza dell'azione dell'utente.
Esegui la riduzione controllata dei livelli di servizio in caso di sovraccarico
Progetta i tuoi servizi in modo da tollerare il sovraccarico. I servizi devono rilevare il sovraccarico restituire all'utente risposte di qualità inferiore o interrompere parzialmente il traffico, senza errori completamente sotto sovraccarico.
Ad esempio, un servizio può rispondere alle richieste degli utenti con pagine web statiche e disattivare temporaneamente il comportamento dinamico più costoso da elaborare. Oppure può consentire operazioni di sola lettura e disattivare temporaneamente gli aggiornamenti dei dati.
Gli operatori devono essere informati per correggere la condizione di errore quando si degrada.
Previeni e attenua i picchi di traffico
Non sincronizzare le richieste tra i client. Troppi clienti che inviano traffico allo stesso istante causa picchi di traffico che potrebbero causare errori a cascata.
Implementare strategie di mitigazione dei picchi sul lato server come limitazione, in coda, differenza del carico o interruzione di circuito, riduzione controllata, e dare priorità alle richieste critiche.
Le strategie di mitigazione sul cliente includono limitazione lato client e il backoff esponenziale con il jitter.
Elimina e convalida gli input
Per evitare input errati, casuali o dannosi che causano interruzioni del servizio violazioni della sicurezza, sanificare e convalidare parametri di input per le API i nostri strumenti operativi. Ad esempio: Apigee e Google Cloud Armor possono contribuire a proteggerti dagli attacchi di iniezione.
Utilizza regolarmente il fuzz test in cui un sistema di test chiama intenzionalmente le API con casuali, vuoti o troppo grandi. Esegui questi test in un test isolato completamente gestito di Google Cloud.
Gli strumenti operativi devono convalidare automaticamente le modifiche alla configurazione prima vengono implementate e dovrebbero rifiutarle se la convalida non va a buon fine.
Fail Safe in modo da preservare la funzione
In caso di errore dovuto a un problema, i componenti del sistema non dovrebbero riuscire in una che consenta all'intero sistema di continuare a funzionare. Questi problemi potrebbero un bug del software, un input o una configurazione errati, un'interruzione di un'istanza non pianificata o errore umano. Cosa il processo dei tuoi servizi aiuta a determinare se dovresti essere eccessivamente permissivo o eccessivamente semplicistico, piuttosto che eccessivamente restrittivo.
Considera i seguenti scenari di esempio e come rispondere all'errore:
- Di solito è più adatto un componente firewall con una configurazione non valida o vuota per impedire l'apertura e consentire il passaggio del traffico di rete non autorizzato per per un breve periodo di tempo mentre l'operatore corregge l'errore. Questo comportamento mantiene il servizio disponibile, invece di chiuderlo in modo errato e bloccare il 100% del traffico. Il servizio deve basarsi su controlli di autenticazione e autorizzazione più approfonditi e lo stack di applicazioni per proteggere le aree sensibili mentre passa tutto il traffico.
- Tuttavia, è meglio un componente del server delle autorizzazioni che controlli l'accesso. la chiusura dei dati utente potrebbe non riuscire e bloccare tutti gli accessi. Questo comportamento causa un'interruzione del servizio se la configurazione è danneggiata, ma evita il rischio di una fuga di dati utente riservati in caso di errore di apertura.
In entrambi i casi, l'errore dovrebbe generare un avviso ad alta priorità, in modo che può correggere la condizione di errore. I componenti del servizio devono avere un errore laterale di fallimento, a meno che ciò non comporti rischi estremi per l’azienda.
Progettare le chiamate API e i comandi operativi in modo che sia possibile provarli nuovamente
Le API e gli strumenti operativi devono rendere le chiamate sicure per i nuovi tentativi, il più possibile. Un approccio naturale a molte condizioni di errore è riprovare l'azione precedente, ma potresti non sapere se il primo tentativo è riuscito.
L'architettura del sistema dovrebbe rendere le azioni idempotenti, se esegui le un'azione identica su un oggetto due o più volte di seguito, dovrebbe produrre gli stessi risultati di una singola chiamata. Le azioni non idempotenti richiedono più azioni complesso per evitare il danneggiamento dello stato del sistema.
Identificare e gestire le dipendenze dei servizi
I progettisti e i proprietari dei servizi devono mantenere un elenco completo altri componenti del sistema. La progettazione del servizio deve includere anche errori delle dipendenze o riduzione controllata se il ripristino completo non è fattibile. Prendi delle dipendenze dai servizi cloud usati dal tuo sistema e dalle dipendenze esterne, come le API di servizi di terze parti, riconoscendo che ogni dipendenza dal sistema con un tasso di errore diverso da zero.
Quando imposti obiettivi di affidabilità, riconosce che lo SLO per un servizio è matematicamente vincolato dagli SLO di tutte le sue dipendenze critiche. Tu non può essere più affidabile dello SLO più basso di una delle dipendenze. Per ulteriori informazioni le informazioni, vedi il calcolo della disponibilità dei servizi.
Dipendenze di avvio
I servizi si comportano in modo diverso all'avvio rispetto allo stato stabile comportamento degli utenti. Le dipendenze di avvio possono differire significativamente dallo stato stabile delle dipendenze di runtime.
Ad esempio, all'avvio, un servizio potrebbe dover caricare i dati dell'utente o dell'account da un servizio di metadati utente che raramente richiama di nuovo. Quando molti servizi di repliche si riavviano dopo un arresto anomalo o una manutenzione di routine. aumentare il carico sulle dipendenze di avvio, soprattutto quando le cache sono vuote e servono da ricompilare.
Testa l'avvio del servizio sotto carico ed esegui il provisioning delle dipendenze di avvio. Valuta la possibilità di ridurre la qualità di un progetto salvando una copia dei dati recupera dalle dipendenze di avvio critiche. Questo comportamento consente al servizio riavviare con dati potenzialmente inattivi anziché essere in grado di avviarsi quando una dipendenza critica ha un'interruzione. Il servizio può caricare dati aggiornati in un secondo momento, quando possibile per tornare al normale funzionamento.
Le dipendenze di avvio sono importanti anche quando esegui il bootstrap di un servizio in una nuova completamente gestito di Google Cloud. Progetta lo stack di applicazioni con un'architettura a più livelli, senza e dipendenze cicliche tra gli strati. Le dipendenze cicliche possono sembrare tollerabili perché non bloccano le modifiche incrementali a una singola applicazione. Tuttavia, cicliche possono rendere difficile o impossibile il riavvio dopo un disattiverà l'intero stack di servizi.
Riduci al minimo le dipendenze critiche
Riduci al minimo il numero di dipendenze critiche per il servizio, ovvero altri componenti il cui errore causerà inevitabilmente interruzioni del servizio. Per rendere il tuo servizio più resiliente agli errori o alla lentezza degli altri componenti da cui dipende, i seguenti esempi di tecniche e principi di progettazione per convertire le dipendenze critiche in dipendenze non critiche:
- Aumentare il livello di ridondanza nelle dipendenze critiche. Aggiunta di altre repliche riduce le probabilità che un intero componente non sia disponibile.
- Utilizza richieste asincrone ad altri servizi invece di bloccare una risposta o usare i messaggi di pubblicazione/sottoscrizione per disaccoppiare le richieste dalle risposte.
- Memorizza nella cache le risposte di altri servizi per recuperare dopo un'indisponibilità a breve termine delle dipendenze.
Per rendere meno dannosi gli errori o la lentezza del servizio rispetto ad altri componenti che dipendono da questo aspetto, considera i seguenti esempi di tecniche e principi di progettazione:
- Utilizza code di richieste prioritarie e dai una maggiore priorità alle richieste in cui un utente sta aspettando una risposta.
- Fornisci le risposte dalla cache per ridurre latenza e carico.
- Fail Safe in modo da preservare la funzione.
- Esegui la riduzione controllata in caso di sovraccarico di traffico.
Assicurati che sia possibile eseguire il rollback di ogni modifica
Se non esiste un modo ben definito per annullare determinati tipi di modifiche a un servizio, modificare la progettazione del servizio per supportare il rollback. Testa il rollback dei processi aziendali periodicamente. Le API per ogni componente o microservizio devono essere il controllo delle versioni, con compatibilità con le versioni precedenti i client continuano a funzionare correttamente man mano che l'API si evolve. Questo principio di progettazione è essenziale per consentire un'implementazione progressiva delle modifiche alle API, con rollback rapido quando necessaria.
Il rollback può essere costoso da implementare per le applicazioni mobile. Configurazione remota Firebase è un servizio Google Cloud per semplificare il rollback delle funzionalità.
Non puoi eseguire subito il rollback delle modifiche allo schema del database, quindi eseguile in più fasi. Progetta ogni fase per consentire richieste di lettura e aggiornamento sicure dello schema all'ultima versione dell'applicazione e alla versione precedente. Questo di progettazione consente di eseguire il rollback in modo sicuro completamente gestita.
Consigli
Per applicare le indicazioni del framework dell'architettura al tuo ambiente, segui questi consigli:
- Implementare il backoff esponenziale con la randomizzazione nella logica dei nuovi tentativi di errore di delle applicazioni client.
- Implementare un'architettura multiregionale con failover automatico per la disponibilità del servizio.
- Utilizza il bilanciamento del carico per distribuire le richieste degli utenti tra shard e regioni.
- Progetta l'applicazione in modo che esegua una riduzione controllata in caso di sovraccarico. Pubblica una parte risposte o forniscono funzionalità limitate anziché fallire completamente.
- Stabilisci un processo basato sui dati per la pianificazione della capacità e utilizza i test di carico e previsioni di traffico per determinare quando eseguire il provisioning delle risorse.
- Definisci procedure di ripristino di emergenza e testale periodicamente.
Passaggi successivi
- Creare strumenti e processi operativi affidabili (prossimo documento di questa serie)
Esplora altre categorie nella Framework dell'architettura come progettazione dei sistemi, eccellenza operativa, sicurezza, privacy e conformità.