Questo documento introduce alcuni pattern e pratiche per creare app resilienti e scalabili, due obiettivi essenziali di molti esercizi di architettura moderna. Un'app ben progettata si espande e si riduce in base all'aumento e alla diminuzione della domanda ed è sufficientemente resiliente per resistere alle interruzioni del servizio. La creazione e il funzionamento di app che soddisfano questi requisiti richiedono un'attenta pianificazione e progettazione.
Scalabilità: regolazione della capacità per soddisfare la domanda
Scalabilità è la misura della capacità di un sistema di gestire quantità variabili di lavoro aggiungendo o rimuovendo risorse dal sistema. Ad esempio, un'app web scalabile è un'app che funziona bene con un utente o con molti utenti e gestisce in modo elegante i picchi e i cali di traffico.
La flessibilità di adeguare le risorse consumate da un'app è un fattore chiave per le aziende che vogliono passare al cloud. Con una progettazione corretta, puoi ridurre i costi rimuovendo le risorse sottoutilizzate senza compromettere le prestazioni o un'esperienza senza intervento manuale. Analogamente, puoi mantenere una buona esperienza utente durante i periodi di traffico elevato aggiungendo altre risorse. In questo modo, la tua app può consumare solo le risorse necessarie per soddisfare la domanda.
Google Cloud offre prodotti e funzionalità per aiutarti a creare app scalabili ed efficienti:
- Le macchine virtuali Compute Engine e i cluster Google Kubernetes Engine (GKE) si integrano con gli autoscaler che ti consentono di aumentare o ridurre il consumo di risorse in base alle metriche che definisci.
- La piattaforma serverless di Google Cloud fornisce servizi di calcolo, database e altri servizi gestiti che scalano rapidamente da zero a volumi di richieste elevati e paghi solo per ciò che utilizzi.
- Prodotti di database come BigQuery, Spanner e Bigtable possono fornire prestazioni coerenti su grandi dimensioni di dati.
- Cloud Monitoring fornisce metriche per le tue app e la tua infrastruttura, aiutandoti a prendere decisioni di scalabilità basate sui dati.
Resilienza: progettazione per far fronte agli errori
Un'app resiliente è un'app che continua a funzionare nonostante i guasti del sistema componenti. La resilienza richiede una pianificazione a tutti i livelli dell'architettura. it influenza il layout della tua infrastruttura e della tua rete e il modo in cui progetti l'archiviazione delle app e dei dati. La resilienza si estende anche alle persone e alla cultura.
Creare e gestire app resilienti è difficile. Questo è particolarmente vero per le app distribuite, che potrebbero contenere più livelli di infrastrutture, reti e servizi. Gli errori e le interruzioni del servizio possono capitare e migliorare la resilienza della tua app è un percorso continuo. Con una pianificazione attenta, puoi migliorare la capacità della tua app di resistere agli errori. Con processi e cultura organizzativa adeguati, puoi anche imparare dagli errori per aumentare ulteriormente la resilienza della tua app.
Google Cloud fornisce strumenti e servizi per aiutarti a creare app resilienti e ad alta disponibilità:
- I servizi Google Cloud sono disponibili in regioni e zone in tutto il mondo, consentendoti di implementare la tua app nel modo più adatto alle tue esigenze obiettivi di disponibilità.
- Gruppi di istanze Compute Engine e cluster GKE può essere distribuito e gestito nelle zone disponibili in una regione.
- I dischi permanenti a livello di regione di Compute Engine vengono replicati in modo sincrono tra le zone di una regione.
- Google Cloud offre una gamma opzioni di bilanciamento del carico per gestire il traffico dell'app, incluso il bilanciamento del carico globale che può indirizzare verso una regione integra
- La piattaforma serverless di Google Cloud include prodotti di calcolo e database gestiti che offrono ridondanza e bilanciamento del carico integrati.
- Google Cloud supporta CI/CD tramite strumenti nativi e integrazioni con tecnologie open source di uso comune, per aiutarti ad automatizzare la creazione e il deployment delle tue app.
- Cloud Monitoring fornisce metriche per tutte le app e dell'infrastruttura, aiutandoti a prendere decisioni basate sui dati le prestazioni e l'integrità delle tue app.
Driver e vincoli
Ci sono diversi requisiti e motivazioni per migliorare la scalabilità e la resilienza della tua app. Potrebbero esserci anche vincoli che limitano capacità di raggiungere gli obiettivi di scalabilità e resilienza. L'importanza relativa di questi requisiti e vincoli varia in base al tipo di app, profilo degli utenti, nonché la scala e la maturità della tua organizzazione.
Driver
Per stabilire le priorità dei tuoi requisiti, prendi in considerazione i conducenti dei diversi all'interno dell'organizzazione.
Fattori chiave dell'attività
Alcuni fattori comuni dal punto di vista delle attività commerciali sono i seguenti:
- Ottimizza i costi e il consumo di risorse.
- Riduci al minimo i tempi di inattività dell'app.
- Assicurati che la domanda degli utenti possa essere soddisfatta durante i periodi di utilizzo elevato.
- Migliorare la qualità e la disponibilità del servizio.
- Assicurati che l'esperienza e la fiducia degli utenti vengano mantenute durante qualsiasi interruzione del servizio.
- Aumenta la flessibilità e l'agilità per gestire le mutevoli richieste del mercato.
Fattori di sviluppo
Alcuni fattori comuni del lato sviluppo sono i seguenti:
- Riduci al minimo il tempo dedicato all'analisi degli errori.
- Aumentare il tempo dedicato allo sviluppo di nuove funzionalità.
- Riduci al minimo il lavoro ripetitivo grazie all'automazione.
- Crea app utilizzando gli ultimi pattern e pratiche del settore.
Fattori chiave delle operazioni
I requisiti da prendere in considerazione dal punto di vista delle operazioni includono i seguenti:
- Riduci la frequenza dei guasti che richiedono l'intervento umano.
- Aumenta la capacità di recuperare automaticamente dai guasti.
- Riduci al minimo il lavoro ripetitivo grazie all'automazione.
- Riduci al minimo l'impatto del guasto di un determinato componente.
Vincoli
I vincoli potrebbero limitare la tua capacità di aumentare la scalabilità e la resilienza della tua app. Assicurati che le tue decisioni di progettazione non introducano o contribuiscano a questi vincoli:
- Dipendenze da hardware o software difficili da scalare.
- Dipendenze da hardware o software difficili da gestire in una configurazione di alta disponibilità.
- Dipendenze tra le app.
- Limitazioni relative alle licenze.
- Mancanza di competenze o esperienza nei team operativi e di sviluppo.
- Resistenza dell'organizzazione all'automazione.
Modelli e best practice
La parte restante di questo documento definisce pattern e pratiche per aiutarti a creare scalabili e scalabili. Questi pattern riguardano tutte le parti della tua app del ciclo di vita, inclusi progettazione dell'infrastruttura, architettura delle app, archiviazione scelte, processi di deployment e cultura organizzativa.
Nei pattern sono evidenti tre temi:
- Automazione. La creazione di app scalabili e resilienti richiede l'automazione. L'automazione del provisioning, dei test e dei deployment delle app dell'infrastruttura aumenta la coerenza e la velocità e riduce al minimo gli errori umani.
- Basso accoppiamento. Trattare il sistema come una raccolta di componenti indipendenti e debolmente accoppiati consente flessibilità e resilienza. L'indipendenza riguarda il modo in cui distribuisci fisicamente le risorse, come progetti la tua app e come progetti lo spazio di archiviazione.
- Progettazione basata sui dati. Raccogliere metriche per comprendere il comportamento la tua app è fondamentale. Le decisioni su quando scalare l'app o su se un determinato servizio non è integro devono essere basate sui dati. Le metriche e i log devono essere funzionalità principali.
Automatizza il provisioning dell'infrastruttura
Creare un'infrastruttura immutabile attraverso l'automazione per migliorare la coerenza dei tuoi ambienti e aumenta il successo dei tuoi deployment.
Tratta la tua infrastruttura come codice
Infrastructure as Code (IaC) è una tecnica che incoraggia a trattare il provisioning e la configurazione dell'infrastruttura come gestisci il codice dell'applicazione. La logica di provisioning e di configurazione è archiviata nell'origine in modo che sia rilevabile e possa essere sottoposto a controllo delle versioni. Perché in un repository di codice, puoi sfruttare i vantaggi dell'integrazione continua pipeline di deployment continuo (CI/CD), in modo che eventuali modifiche la configurazione può essere testata e distribuita automaticamente.
Eliminando i passaggi manuali dal provisioning dell'infrastruttura, IaC riduce al minimo errori umani e migliora la coerenza e la riproducibilità delle tue app ambienti cloud-native. In questo modo, l'adozione di IaC aumenta la resilienza delle tue app.
Cloud Deployment Manager consente di automatizzare la creazione e la gestione delle risorse Google Cloud con modelli flessibili. In alternativa, Config Connector ti consente di gestire le risorse utilizzando tecniche e flussi di lavoro di Kubernetes. Google Cloud offre anche il supporto integrato per i più diffusi strumenti IaC di terze parti, tra cui Terraform, Chef e Puppet.
Crea un'infrastruttura immutabile
Un'infrastruttura immutabile è una filosofia che si basa sui vantaggi della Infrastructure as Code. L'infrastruttura immutabile prevede che le risorse non vengano mai modificate dopo il deployment. Se una macchina virtuale, un cluster Kubernetes regola firewall deve essere aggiornata, puoi aggiornare la configurazione risorsa nel repository di origine. Dopo aver testato e convalidato modifiche, eseguirai nuovamente il deployment della risorsa utilizzando la nuova configurazione. In altre parole, anziché modificare le risorse, le ricrei.
La creazione di un'infrastruttura immutabile porta a deployment e rollback più prevedibili. Inoltre, riduce i problemi comuni nelle infrastrutture mutabili, come la deriva della configurazione e i server snowflake. In questo modo, l'adozione di un'infrastruttura immutabile migliora ulteriormente la coerenza e l'affidabilità dei tuoi ambienti.
Progetta per l'alta disponibilità
La disponibilità è una misura della frazione di tempo in cui un servizio è utilizzabile. La disponibilità viene spesso utilizzata come chiave indicatore dell'integrità complessiva del servizio. Le architetture a disponibilità elevata mirano a massimizzare la disponibilità del servizio, in genere mediante il deployment ridondante dei componenti. In termini più semplici, per ottenere un'alta disponibilità in genere è necessario distribuire le risorse di calcolo, il bilanciamento del carico e la replica dei dati.
Distribuisci fisicamente le risorse
I servizi Google Cloud sono disponibili in località in tutto il mondo. Questi le località sono suddivise regioni e zone. Il modo in cui esegui il deployment della tua app in queste regioni e zone influisce sulle la disponibilità, la latenza e altre proprietà della tua app. Per ulteriori informazioni, consulta le best practice per la selezione della regione per Compute Engine.
La ridondanza è la duplicazione dei componenti di un sistema per aumentare la disponibilità complessiva del sistema. In Google Cloud, la ridondanza in genere ottenuti eseguendo il deployment dell'app o del servizio o anche in più regioni. Se un servizio esiste in più zone o regioni, può resistere meglio alle interruzioni del servizio in una particolare zona regione. Sebbene Google Cloud faccia il possibile per prevenire queste interruzioni, certi eventi sono imprevedibili ed è meglio essere preparati.
Con Compute Engine gruppi di istanze gestite, puoi distribuire istanze di macchine virtuali su più zone all'interno di una regione, e gestire le istanze come unità logica. Inoltre, Google Cloud offerte dischi permanenti a livello di regione per replicare automaticamente i dati in due zone di una regione.
Analogamente, puoi migliorare la disponibilità e la resilienza delle app di cui è stato eseguito il deployment su GKE creando cluster regionali. Un cluster a livello di regione distribuisce i componenti del piano di controllo GKE, nodi e pod in più zone all'interno di una regione. Poiché il controllo vengono distribuiti i componenti del piano, puoi continuare ad accedere anche durante un'interruzione del servizio che coinvolge una o più zone (ma non tutte).
Favorire i servizi gestiti
Anziché installare, supportare e gestire in modo indipendente tutte le parti del tuo stack di applicazioni, puoi utilizzare i servizi gestiti per utilizzare parti del tuo stack di applicazioni come servizi. Ad esempio, anziché installare e gestire un database MySQL su macchine virtuali (VM), puoi utilizzare un database MySQL fornito da Cloud SQL. Quindi ottieni una disponibilità Accordo sul livello del servizio (SLA) e puoi affidarti a Google Cloud per gestire la replica dei dati, i backup l'infrastruttura sottostante. Utilizzando i servizi gestiti, puoi dedicare meno tempo alla gestione dell'infrastruttura e più tempo al miglioramento dell'affidabilità della tua app.
Molti dei servizi di calcolo, database e archiviazione gestiti di Google Cloud offrono ridondanza integrata, che può aiutarti a raggiungere i tuoi obiettivi di disponibilità. Molti di questi servizi offrono un modello regionale, il che significa che l'infrastruttura che esegue la tua app si trova in una regione specifica ed è gestita da Google in modo da essere disponibile in modo ridondante in tutte le zone all'interno di quella regione. Se una zona diventa non disponibile, l'app o i dati vengono pubblicati automaticamente da un'altra zona della regione.
Alcuni servizi di database e archiviazione offrono anche disponibilità multi-regionale, il che significa che l'infrastruttura che esegue la tua app si trova in diverse regioni. I servizi multi-regionali possono resistere alla perdita di un'intera regione, ma tipicamente a un costo di latenza più elevato.
Bilanciamento del carico a ogni livello
Il bilanciamento del carico ti consente di distribuire il traffico tra gruppi di risorse. Quando distribuisci il traffico, aiuti a garantire che le singole risorse non si sovraccarichi mentre gli altri sono inattivi. La maggior parte dei bilanciatori del carico fornisce anche funzionalità di controllo di integrità per garantire che il traffico non venga indirizzato a risorse non integre o non disponibili.
Google Cloud offre diverse opzioni di bilanciamento del carico. Se l'app viene eseguita su in Compute Engine o GKE, puoi scegliere il tipo appropriato di bilanciatore del carico a seconda del tipo, dell'origine e di altri aspetti del traffico. Per ulteriori informazioni, consulta la panoramica del bilanciamento del carico e la panoramica del networking di GKE.
In alternativa, alcuni servizi gestiti da Google Cloud, come App Engine e Cloud Run, con bilanciamento del carico automatico.
È prassi comune bilanciare il carico delle richieste ricevute da origini esterne, come da client web o mobile. Tuttavia, l'utilizzo di bilanciatori del carico tra diversi servizi o livelli all'interno dell'app può anche aumentare la resilienza e la flessibilità. A questo scopo, Google Cloud fornisce il bilanciamento del carico interno per il livello 4 e il livello 7.
Il seguente diagramma mostra un bilanciatore del carico esterno che distribuisce
in due regioni, us-central1
e asia-east1
. Mostra inoltre
bilanciamento del carico interno che distribuisce il traffico dal livello Web all'infrastruttura
ogni livello all'interno di ogni regione.
Monitora l'infrastruttura e le app
Prima di poter decidere come migliorare la resilienza e la scalabilità della tua app, devi comprenderne il comportamento. Accesso a un set completo di metriche e serie temporali pertinenti sulle prestazioni e sullo stato della tua app può aiutarti a scoprire potenziali problemi prima che causino un'interruzione. Possono è utile anche per diagnosticare e risolvere eventuali interruzioni. La monitorare sistemi distribuiti questo capitolo del team Libro sull'SRE offre una buona panoramica di alcuni approcci al monitoraggio.
Oltre a fornire informazioni sullo stato della tua app, le metriche possono anche per controllare il comportamento di scalabilità automatica per i tuoi servizi.
Cloud Monitoring è lo strumento di monitoraggio integrato di Google Cloud. Cloud Monitoring importa eventi, metriche e metadati e fornisce insight tramite dashboard e avvisi. La maggior parte dei servizi Google Cloud invia automaticamente metriche a Cloud Monitoring e Google Cloud supporta inoltre molti database fonti. Cloud Monitoring può essere utilizzato anche come backend per i più diffusi strumenti di monitoraggio open source, fornendo un "pannello unico" con cui osservare la tua app.
Monitoraggio a tutti i livelli
La raccolta di metriche a vari livelli o livelli all'interno dell'architettura fornisce un quadro olistico dello stato e del comportamento della tua app.
Monitoraggio dell'infrastruttura
Il monitoraggio a livello di infrastruttura fornisce lo stato e le prestazioni di riferimento per la tua app. Questo approccio al monitoraggio acquisisce informazioni come il carico della CPU, l'utilizzo della memoria e il numero di byte scritti sul disco. Queste metriche può indicare che una macchina è sovraccarica o non funziona come previsto.
Oltre alle metriche raccolte automaticamente, Cloud Monitoring offre agente che può essere installato per raccogliere informazioni più dettagliate VM di Compute Engine, incluse quelle di app di terze parti in esecuzione machine learning.
Monitoraggio delle app
Ti consigliamo di acquisire le metriche a livello di app. Ad esempio, potresti volere per misurare quanto tempo ci vuole per eseguire una determinata query o quanto tempo per eseguire una sequenza correlata di chiamate di servizio. Sei tu a definire metriche a livello di app. Acquisiscono le informazioni che gli strumenti Le metriche di Cloud Monitoring non possono, Le metriche a livello di app possono acquisire condizioni aggregate che riflettono più da vicino i flussi di lavoro chiave, rivelano i problemi che le metriche di basso livello non rilevano.
Ti consigliamo anche di utilizzare OpenTelemetry per acquisire metriche a livello di app. OpenTelemetry fornisce un unico standard aperto per i dati di telemetria. Utilizza OpenTelemetry per raccogliere ed esportare dati dal tuo e l'infrastruttura cloud-first. Puoi quindi monitorare e analizzare i dati di telemetria esportati.
Monitoraggio dei servizi
Per le app distribuite e basate su microservizi, è importante monitorare le interazioni tra i diversi servizi e componenti delle app. Queste metriche possono aiutarti a diagnosticare problemi come un aumento del numero di errori o la latenza tra i servizi.
Istio è uno strumento open source che fornisce insight un controllo completo della rete di microservizi. Istio genera telemetria dettagliata per tutte le comunicazioni del servizio e può essere configurato per inviare le metriche a Cloud Monitoring.
Monitoraggio end-to-end
Il monitoraggio end-to-end, chiamato anche monitoraggio black box, testa il comportamento visibile dall'esterno come lo vede un utente. Questo tipo di monitoraggio verifica se un utente è in grado di completare azioni critiche entro le soglie definite. Questo monitoraggio a granularità elevata può rilevare errori o latenze che un monitoraggio più granulare potrebbe non rilevare e rivela la disponibilità percepita dall'utente.
Mostrare l'integrità delle app
Un sistema ad alta disponibilità deve avere un modo per determinare quali parti del sistema sono in buone condizioni e funzionano correttamente. Se vengono visualizzate determinate risorse se non è integro, il sistema può inviare richieste altrove. In genere, i controlli di integrità prevedono il recupero dei dati da un endpoint per determinare lo stato o l'integrità di un servizio.
Il controllo di integrità è una responsabilità chiave dei bilanciatori del carico. Quando crei un bilanciatore del carico associato a un gruppo di istanze di macchine virtuali, definisci anche un controllo di integrità. Il controllo di integrità definisce il modo in cui il bilanciatore del carico comunica con l'infrastruttura per valutare se determinate istanze devono continuare a ricevere per via del traffico. I controlli di integrità del bilanciatore del carico possono essere utilizzati anche riparazione automatica di istanze in modo tale da ricreare le macchine in stato non integro. Se utilizzi GKE e esegui il bilanciamento del carico del traffico esterno tramite una risorsa Ingress, GKE crea automaticamente i controlli di salute appropriati per il bilanciatore del carico.
Kubernetes offre il supporto integrato per i probe di attività e di idoneità. Questi controlli aiutano l'orchestratore Kubernetes a decidere come gestire i pod e le richieste all'interno del cluster. Se l'app è dipiattaforma su Kubernetes, è buona norma esporre il suo stato a questi controlli tramite endpoint appropriati.
Definisci le metriche chiave
Il monitoraggio e il controllo di integrità forniscono metriche sul comportamento e lo stato dell'app. Il passaggio successivo consiste nell'analizzare queste metriche per determinare sono quelle più descrittive o più efficaci. Le metriche principali variano a seconda piattaforma su cui viene eseguito il deployment dell'app e sul lavoro che svolge.
È improbabile che troverai una sola metrica che indichi se applicare la scalabilità o che un determinato servizio non sia integro. Spesso si tratta di una combinazione di fattori che insieme indicano un determinato insieme di condizioni. Con Cloud Monitoring, puoi creare metriche personalizzate per acquisire queste condizioni. Il libro di Google sulla SRE consiglia quattro indicatori fondamentali per il monitoraggio di un sistema rivolto agli utenti: latenza, traffico, errori e saturazione.
Prendi in considerazione anche la tua tolleranza per i valori anomali. Usare un valore medio o mediano per misurare lo stato di salute o il rendimento potrebbe non essere la scelta migliore, perché misure possono nascondere ampi squilibri. Per questo motivo è importante considerare distribuzione delle metriche; il 99° percentile potrebbe essere una misura più informativa rispetto alla media.
Definisci gli obiettivi del livello di servizio (SLO)
Puoi utilizzare le metriche raccolte dal sistema di monitoraggio per definire gli obiettivi del livello di servizio (SLO). Gli SLO specificano un livello target di prestazioni o affidabilità per il servizio. Gli SLO sono un pilastro fondamentale delle pratiche SRE e sono descritti in dettaglio nel capitolo sugli obiettivi del livello di servizio del libro SRE e anche nel capitolo sull'implementazione degli SLO del foglio di lavoro SRE.
Puoi utilizzare il monitoraggio del servizio per definire gli SLO in base alle metriche di Cloud Monitoring. Puoi creare criteri di avviso sugli SLO per farti sapere se sei in pericolo uno SLO.
Memorizza le metriche
Le metriche del sistema di monitoraggio sono utili nel breve periodo per aiutarti a controlli di integrità in tempo reale o per indagare su problemi recenti. Cloud Monitoring conserva le metriche per diverse settimane per soddisfare al meglio questi casi d'uso.
Tuttavia, è anche importante archiviare le metriche di monitoraggio un'analisi a lungo termine. L'accesso a dati storici può aiutarti ad adottare un un approccio basato sui dati per perfezionare l'architettura dell'app. Puoi usare i dati raccolti durante e dopo un'interruzione per identificare i colli di bottiglia e le interdipendenze tra le app. Puoi anche utilizzare i dati per creare e convalidare test significativi.
I dati storici possono anche aiutarti a verificare che la tua app supporti gli scopi commerciali durante i periodi chiave. Ad esempio, i dati possono aiutarti ad analizzare la scalabilità della tua app durante gli eventi promozionali con traffico elevato nel corso degli ultimi trimestri o addirittura anni.
Per informazioni dettagliate su come esportare e archiviare le metriche, consulta la soluzione Esportazione delle metriche di Cloud Monitoring.
Determina il profilo di scalabilità
Vuoi che la tua app soddisfi gli obiettivi relativi all'esperienza utente e al rendimento senza delle risorse in overprovisioning.
Il seguente diagramma mostra una rappresentazione semplificata del profilo di scalabilità di un'app. L'app mantiene un livello di base di risorse e utilizza la scalabilità automatica per rispondere ai cambiamenti della domanda.
Trova un equilibrio tra costo ed esperienza utente
Decidere se scalare la tua app significa fondamentalmente bilanciare il costo rispetto all'esperienza utente. Decidi qual è il livello minimo di rendimento accettabile e, eventualmente, dove impostare un limite massimo. Queste soglie variano da un'app all'altra e anche potenzialmente tra componenti o all'interno di un'unica app.
Ad esempio, un'app web o mobile rivolta ai consumatori potrebbe avere obiettivi di latenza rigorosi. La ricerca mostra che anche piccoli ritardi possono influire negativamente sulla percezione della tua app da parte degli utenti, conseguente riduzione delle conversioni e un numero inferiore di registrazioni. Pertanto, è importante Assicurati che la tua app abbia una capacità di pubblicazione sufficiente per rispondere rapidamente all'utente richieste. In questo caso, i costi più elevati per l'esecuzione di più server web potrebbero essere giustificati.
Il rapporto costo/prestazioni potrebbe essere diverso per un'offerta non business-critical in cui gli utenti sono probabilmente più tolleranti nei confronti dei piccoli ritardi. Di conseguenza, il tuo profilo di scalabilità può essere meno aggressivo. In questo caso, mantenere i costi bassi potrebbe essere di maggiore importanza rispetto all'ottimizzazione dell'esperienza utente.
Imposta le risorse di riferimento
Un altro componente chiave del profilo di scalabilità è la scelta di un insieme minimo di risorse appropriato.
In genere, lo scale up delle macchine virtuali Compute Engine o dei cluster GKE richiede tempo, perché è necessario creare e inizializzare nuovi nodi. Pertanto, potrebbe essere necessario mantenere un insieme minimo di risorse, anche se non c'è traffico. Anche in questo caso, la portata delle risorse di riferimento è influenzata dalla il tipo di app e il profilo di traffico.
Al contrario, le tecnologie serverless come App Engine, le funzioni Cloud Run e Cloud Run sono progettate per scalare fino a zero e per avviarsi e scalare rapidamente, anche in caso di avvio a freddo. A seconda del tipo di app e del profilo di traffico, queste tecnologie possono garantire l'efficienza di alcune parti della tua app.
Configura scalabilità automatica
Scalabilità automatica consente di scalare automaticamente le risorse di calcolo utilizzate dalla tua app. In genere, la scalabilità automatica si verifica quando vengono superate determinate metriche o vengono soddisfatte sono soddisfatti. Ad esempio, se le latenze delle richieste al livello web iniziano a superare un un certo valore, potresti voler aggiungere automaticamente altre macchine per aumentare e capacità di distribuzione.
Molti prodotti di calcolo di Google Cloud dispongono di funzionalità di scalabilità automatica. I servizi gestiti serverless come Cloud Run, le funzioni Cloud Run e App Engine sono progettati per scalare rapidamente. Questi servizi in genere offrono opzioni di configurazione per limitare o influenzare la scalabilità automatica ma, in generale, gran parte del comportamento del gestore della scalabilità automatica è nascosto operatore.
Compute Engine e GKE offrono più opzioni per controllare comportamento di scalabilità. Con Compute Engine, puoi eseguire la scalabilità in base a vari input, tra cui le metriche personalizzate di Cloud Monitoring e la capacità di gestione del bilanciatore del carico. Puoi impostare limiti minimi e massimi per il comportamento di ridimensionamento e puoi definire un criterio di scalabilità automatica con più indicatori per gestire scenari diversi. Come con GKE, puoi per configurare gestore della scalabilità automatica dei cluster per aggiungere o rimuovere nodi in base al carico di lavoro o al pod, metriche, o sulle metriche esterni nel cluster.
Ti consigliamo di configurare il comportamento di scalabilità automatica in base alle metriche chiave dell'app, al profilo di costo e al livello minimo di risorse richiesto definito.
Riduci al minimo il tempo di avvio
Affinché il ridimensionamento sia efficace, deve avvenire abbastanza rapidamente da gestire il carico in aumento. Questo è particolarmente vero quando aggiungi capacità di calcolo o di pubblicazione.
Utilizza immagini precotte
Se la tua app viene eseguita su VM Compute Engine, probabilmente devi installare il software e configurare le istanze per eseguirla. Sebbene tu possa utilizzare gli script di avvio per configurare nuove istanze, un modo più efficiente è creare un'immagine personalizzata. Un'immagine personalizzata è un disco di avvio configurato con il software e la configurazione specifici dell'app.
Per ulteriori informazioni sulla gestione delle immagini, consulta best practice per la gestione delle immagini .
Dopo aver creato l'immagine, puoi definire un modello di istanze. I modelli di istanza combinano l'immagine del disco di avvio, il tipo di macchina e altre proprietà dell'istanza. Puoi quindi utilizzare un modello di istanza per creare una singola VM o un deployment gruppo di istanze gestite. I modelli di istanza sono un modo conveniente per salvare la configurazione di un'istanza VM puoi usarlo in un secondo momento per creare nuove istanze VM identiche.
Sebbene la creazione di immagini personalizzate e modelli di istanza possa aumentare la velocità di deployment, può anche aumentare i costi di manutenzione, potrebbe richiedere un aggiornamento più frequente. Per saperne di più, consulta la documentazione relativa al bilanciamento della configurazione delle immagini e della velocità di implementazione.
Containerizza la tua app
Un'alternativa alla creazione di istanze VM personalizzate è containerizzare la tua app. R contenitore è un pacchetto di software leggero, autonomo ed eseguibile che include tutto il necessario per eseguire un'app: codice, runtime, strumenti di sistema, sistema librerie e impostazioni. Queste caratteristiche rendono le app containerizzate più portatili, facili da implementare e da gestire su larga scala rispetto alle macchine virtuali. In genere i container sono anche rapidi da avviare, il che li rende adatti per le app scalabili e resilienti.
Google Cloud offre diversi servizi per eseguire i container delle app. Cloud Run fornisce una piattaforma di calcolo serverless gestita per ospitare i tuoi container stateless. L'ambiente App Engine Flexible ospita i container in una piattaforma PaaS (Platform as a Service) gestita. GKE fornisce un ambiente Kubernetes gestito per ospitare e orchestrare le tue applicazioni containerizzate. Puoi anche eseguire l'app su Compute Engine quando devi assumere il controllo completo dell'ambiente dei container.
Ottimizza l'app per un avvio rapido
Oltre ad assicurarti che l'infrastruttura e l'app possano essere implementate nel modo più efficiente possibile, è importante anche assicurarti che l'app venga messa online rapidamente.
Le ottimizzazioni appropriate per la tua app variano in base al caratteristiche e piattaforma di esecuzione. È importante effettuare le seguenti operazioni:
- Individua ed elimina i colli di bottiglia profilando le sezioni critiche del all'app che vengono richiamate all'avvio.
- Riduci il tempo di avvio iniziale implementando tecniche come l'inizializzazione lazy, in particolare delle risorse costose.
- Riduci al minimo le dipendenze dell'app che potrebbero dover essere caricate al momento dell'avvio.
Favorire architetture modulari
Puoi aumentare la flessibilità della tua app scegliendo architetture che consente di eseguire il deployment, gestire e scalare i componenti in modo indipendente. Questo pattern può anche migliorare la resilienza eliminando i single point of failure.
Suddividi la tua app in servizi indipendenti
Se progetti la tua app come un insieme di servizi indipendenti e a basso accoppiamento, puoi aumentare la sua flessibilità. Se adotti un design a basso accoppiamento, e consente il rilascio e il deployment di servizi in modo indipendente. Oltre a molti altri vantaggi, questo approccio consente a questi servizi di utilizzare diversi stack tecnologici e di essere gestiti da team diversi. Questo approccio a basso accoppiamento è il tema chiave dei pattern di architettura come microservizi e SOA.
Quando decidi come definire i confini dei tuoi servizi, i requisiti di disponibilità e scalabilità sono dimensioni chiave. Ad esempio, se un determinato componente ha un requisito di disponibilità o un profilo di scalabilità diverso rispetto agli altri componenti, potrebbe essere un buon candidato per un servizio autonomo.
Punta all'stateless
Un'app o un servizio stateless non conserva alcun dato o stato locale permanente. Un modello stateless ti consente di gestire ogni richiesta o interazione con il servizio indipendentemente dalle richieste precedenti. Questo modello facilita scalabilità e recuperabilità, perché significa che il servizio può crescere, ridurre o riavviare senza perdere i dati necessari eventuali processi o richieste in corso. Lo stateless è particolarmente importante quando utilizzi un gestore della scalabilità automatica, poiché le istanze, i nodi o i pod servizio può essere creato ed eliminato in modo imprevisto.
Potrebbe non essere possibile che tutti i tuoi servizi siano stateless. In questo caso, fornisci informazioni esplicite sui servizi che richiedono lo stato. Garantendo una separazione chiara tra i servizi stateless e stateful, puoi garantire una scalabilità semplice per i servizi stateless, adottando al contempo un approccio più ponderato per i servizi stateful.
Gestire le comunicazioni tra i servizi
Una delle sfide delle architetture di microservizi distribuiti è per la gestione delle comunicazioni tra i servizi. Man mano che la tua rete di servizi cresce, è probabile che aumenti anche le interdipendenze tra i servizi. Non vuoi che l'errore di un servizio provochi l'errore di altri servizi, a volte chiamato errore a cascata.
Puoi contribuire a ridurre il traffico verso un servizio sovraccaricato o in stato di errore adottando tecniche come il pattern di interruttore di sicurezza, i backoff esponenziali e la riduzione controllata. Questi pattern aumentano la resilienza della tua app fornendo contenuti sovraccarichi o di recuperare gli stati di errore tramite la gestione controllata. Per maggiori informazioni informazioni, consulta risoluzione degli errori a cascata capitolo sulla SRE di Google.
L'utilizzo di un mesh di servizi può aiutarti a gestire il traffico tra i tuoi servizi distribuiti. Un mesh di servizi è un software che collega i servizi e aiuta a disaccoppiare la logica di business dalla rete. Un mesh di servizi in genere fornisce funzionalità di resilienza come le richieste come tentativi, failover e interruttori di sicurezza.
Utilizza la tecnologia di archiviazione e del database appropriata
Alcuni database e tipi di archiviazione sono difficili da scalare e rendere resiliente. Assicurati che le tue scelte di database non limitino la disponibilità e la scalabilità della tua app.
Valuta le tue esigenze di database
Anche il pattern di progettazione dell'app come insieme di servizi indipendenti si estende ai database e allo spazio di archiviazione. Potrebbe essere opportuno scegliere tipi di archiviazione per parti diverse dell'app, con il risultato di avere archiviazione.
Le app convenzionali spesso funzionano esclusivamente con database relazionali. Relazionale offrono funzionalità utili come le transazioni, l'accesso coerenza, integrità referenziale e query sofisticate tra le tabelle. Queste funzionalità rendono i database relazionali una buona scelta per molte app comuni le funzionalità di machine learning. Tuttavia, anche i database relazionali presentano alcuni vincoli. Generalmente sono difficili da scalare e richiedono una gestione attenta in una configurazione ad alta disponibilità. Un database relazionale potrebbe non essere il massimo per tutte le esigenze del tuo database.
I database non relazionali, spesso indicati come database NoSQL, adottano un approccio diverso. Sebbene i dettagli variano in base ai prodotti, i database NoSQL tipicamente sacrificano alcune funzionalità dei database relazionali a favore di una maggiore disponibilità e una scalabilità più semplice. In termini di teorema CAP, i database NoSQL scelgono spesso la disponibilità rispetto alla coerenza.
Spesso la scelta di un database NoSQL dipende dal grado di coerenza richiesto. Se il modello dei dati per un determinato servizio non richiede le funzionalità di RDBMS e può essere progettato per essere coerente, la scelta di un database NoSQL può offrire disponibilità e scalabilità maggiori.
Nel campo della gestione dei dati, i database relazionali e non relazionali sono spesso considerati tecnologie complementari anziché concorrenti. Utilizzando entrambi i tipi di database in modo strategico, le organizzazioni possono sfruttare i punti di forza di ciascuno per ottenere risultati ottimali in termini di archiviazione, recupero e analisi dei dati.
Oltre a una gamma di database relazionali e NoSQL, Google Cloud offre anche Spanner, un database molto coerente, altamente disponibile e distribuito a livello globale con supporto per SQL. Per informazioni sulla scelta di un database appropriato per Google Cloud, consulta database Google Cloud.
Implementa la memorizzazione nella cache
Lo scopo principale di una cache è aumentare le prestazioni di recupero dati riducendo dalla necessità di accedere al livello di archiviazione sottostante.
La memorizzazione nella cache migliora la scalabilità riducendo la dipendenza dalle soluzioni basate su disco archiviazione. Poiché le richieste possono essere fornite dalla memoria, le latenze delle richieste di archiviazione sono ridotti, consentendo in genere al servizio di richieste. Inoltre, la memorizzazione nella cache può ridurre il carico sui servizi a valle dell'app, in particolare i database, consentendo ad altri componenti interagire con quel servizio downstream anche per scalare di più o del tutto.
La memorizzazione nella cache può anche aumentare la resilienza grazie al supporto di tecniche come una riduzione controllata. Se il livello di archiviazione sottostante è sovraccarico o non disponibile, la cache può continuano a gestire le richieste. Anche se i dati restituiti dalla cache potrebbero essere incomplete o non aggiornate, che potrebbero essere accettabili per alcune diversi scenari.
Memorystore per Redis offre un servizio completamente gestito basato sull'archiviazione dei dati in memoria di Redis. Memorystore for Redis offre accesso a bassa latenza e velocità effettiva elevata per i dati ad alto accesso. Può essere implementato in una configurazione ad alta disponibilità che fornisce la replica tra zone e il failover automatico.
Modernizza i tuoi processi e la tua cultura di sviluppo
Le DevOps possono essere considerate una vasta raccolta di processi, cultura e strumenti che promuovono l'agilità e il time-to-market ridotto per app e funzionalità abbattendo le barriere tra i team di sviluppo, operativi e correlati. Le tecniche di DevOps hanno lo scopo di migliorare la qualità e l'affidabilità del software.
Una discussione dettagliata di DevOps non rientra nell'ambito di questo documento, ma alcuni aspetti chiave relativi al miglioramento dell'affidabilità e della resilienza della tua app sono trattati nelle sezioni seguenti. Per maggiori dettagli, consulta la pagina DevOps di Google Cloud.
Progettazione per la testabilità
I test automatici sono un componente chiave delle pratiche di distribuzione del software moderne. La possibilità di eseguire un insieme completo di test di unità, integrazione e sistema è essenziale per verificare che l'app si comporti come previsto e possa procedere alla fase successiva del ciclo di implementazione. La testabilità è un criterio di progettazione fondamentale per la tua app.
Ti consigliamo di utilizzare i test delle unità per la maggior parte dei test perché sono veloci da eseguire e in genere semplici da gestire. Ti consigliamo inoltre di automatizzare i test di sistema e di integrazione di livello superiore. Questi i test sono notevolmente semplificati se adotti tecniche di Infrastructure as Code perché è possibile creare risorse e ambienti di test dedicati on demand. quindi verrà rimosso al termine dei test.
Con l'aumento della percentuale di codice coperta dai test, riduci l'incertezza e la potenziale diminuzione dell'affidabilità di ogni modifica al codice. Un'adeguata copertura dei test significa che è possibile apportare più modifiche prima l'affidabilità è inferiore a un livello accettabile.
I test automatici sono parte integrante di integrazione continua. L'esecuzione di un solido insieme di test automatici su ogni commit del codice fornisce un feedback rapido sulle modifiche, migliorando la qualità e l'affidabilità del software. Gli strumenti nativi di Google Cloud come Cloud Build e gli strumenti di terze parti come Jenkins possono aiutarti a implementare l'integrazione continua.
Automazione dei deployment
L'integrazione continua e l'automazione dei test completa ti garantiscono la stabilità del software. Una volta implementati, il passaggio successivo consiste nell'automatizzare il deployment della tua app. Il livello di automazione del deployment varia a seconda del livello di maturità della tua organizzazione.
La scelta di una strategia di deployment appropriata è essenziale per ridurre al minimo i rischi associati al deployment di nuovo software. Con la strategia giusta, puoi aumentare gradualmente l'esposizione delle nuove versioni a segmenti di pubblico più ampi, verificando il comportamento lungo il percorso. Puoi anche impostare disposizioni chiare per il rollback in caso di problemi.
Adotta le pratiche di SRE per gestire gli errori
Per le app distribuite che operano su larga scala, è comune un certo grado di errore in uno o più componenti. Se adotti i pattern trattati in questo documento, la tua app può gestire meglio le interruzioni causate da una release software difettosa, arresto imprevisto delle macchine virtuali o persino un'interruzione dell'infrastruttura che interessa un'intera zona.
Tuttavia, anche con un'attenta progettazione dell'app, potresti inevitabilmente imbatterti in che richiedono l'intervento umano. Se implementi processi strutturati per gestire questi eventi, puoi ridurne notevolmente l'impatto e risolverli più rapidamente. Inoltre, se esamini le cause e le risposte all'evento, puoi proteggere la tua app da eventi simili in futuro.
Processi rigorosi per gestione degli incidenti e delle prestazioni Analisi post mortem senza attribuzione delle colpe sono i principi fondamentali dell'SRE. Sebbene implementi le pratiche complete di Google SRE potrebbe non essere pratico per la tua organizzazione, se adotti anche un insieme minimo di linee guida, puoi migliorare la resilienza della tua app. Le appendici del Libro sull'SRE contengono alcuni modelli che possono aiutarti a modellare i tuoi processi.
Convalida e rivedi l'architettura
Man mano che la tua app si evolve, il comportamento degli utenti, i profili di traffico e persino le priorità possono cambiare. Analogamente, anche altri servizi o l'infrastruttura di cui dipende la tua app possono evolversi. Pertanto, è importante testare e testare periodicamente convalidare la resilienza e la scalabilità della tua app.
Testa la tua resilienza
È fondamentale verificare che la tua app risponda agli errori nel modo previsto. Il tema generale è che il modo migliore per evitare il fallimento è introdurre fallimento e imparare da questi.
Simulare e introdurre gli errori è un'operazione complessa. Oltre a verificare il comportamento della tua app o del tuo servizio, devi anche assicurarti che vengano generati gli avvisi previsti e le metriche appropriate. Consigliamo una struttura in cui introdurre semplici errori e poi riassegnare la richiesta.
Ad esempio, puoi procedere nel seguente modo, convalidando e documentando il comportamento in ogni fase:
- Introduci errori intermittenti.
- Bloccare l'accesso alle dipendenze del servizio.
- Blocca tutte le comunicazioni di rete.
- Terminare gli host.
Per maggiori dettagli, consulta Infrangere i sistemi per renderli infrangibili di Google Cloud Next 2019.
Se utilizzi un mesh di servizi come Istio per gestire i servizi delle tue app, puoi inserisci guasti a livello dell'applicazione, invece di terminare pod o macchine oppure il danneggiamento dei pacchetti a livello di TCP. Puoi introdurre ritardi per simulare latenza di rete o un sistema upstream sovraccarico. Puoi anche introdurre interruzioni, che simulano i guasti nei sistemi a monte.
Testare il comportamento di scalabilità
Ti consigliamo di utilizzare test automatici non funzionali per verificare che il tuo la scalabilità dell'app nel modo previsto. Spesso questa verifica è associata a test di prestazioni o di carico. Puoi usare semplici strumenti come ehi per inviare un carico a un'app web. Per un esempio più dettagliato che mostra come eseguire il caricamento test su un endpoint REST, consulta Test di carico distribuito con Google Kubernetes Engine.
Un approccio comune è garantire che le metriche chiave rimangano entro i livelli previsti per carichi di lavoro variabili. Ad esempio, se stai testando la scalabilità del tuo livello web, potresti misurare le latenze medie delle richieste per volumi elevati di richieste degli utenti. Analogamente, per una funzionalità di elaborazione di backend, potresti misurare il tempo medio di elaborazione delle attività quando il volume delle attività aumenta improvvisamente.
Inoltre, i test devono misurare che il numero di risorse creato per gestire il carico di prova rientra nell'intervallo previsto. Ad esempio, i test potrebbero verificare che il numero di VM create per gestire le attività di backend non superano un certo valore.
È importante anche testare i casi limite. Qual è il comportamento della tua app o del tuo servizio quando vengono raggiunti i limiti massimi di scalabilità? Qual è il comportamento se il servizio viene ridotto e poi il carico aumenta di nuovo improvvisamente?
Progetta sempre
Il mondo della tecnologia si muove velocemente, e questo è particolarmente vero per il cloud. Nuovi prodotti e funzionalità vengono rilasciati di frequente, emergono nuovi modelli e le richieste da parte degli utenti e degli stakeholder interni continuano a crescere.
Come definito nel post del blog relativo ai principi dell'architettura cloud-native, cerca sempre modi per perfezionare, semplificare e migliorare l'architettura delle tue app. I sistemi software sono esseri viventi e devono si adattano in base alle priorità in continua evoluzione.
Passaggi successivi
- Leggi il post del blog sui principi per l'architettura cloud-native.
- Leggi i libri SRE per informazioni dettagliate su come viene gestito l'ambiente di produzione di Google.
- Scopri di più su come DevOps su Google Cloud può migliorare la qualità e l'affidabilità del software.
- Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Dai un'occhiata al nostro Centro architetture cloud.