Questo documento introduce alcuni pattern e pratiche per la creazione di app resiliente e scalabile, due obiettivi essenziali di molte architetture moderne allenamenti. Un'app ben progettata fa lo scale up e lo scale down man mano che la domanda aumenta e diminuisci ed è sufficientemente resiliente da resistere a interruzioni del servizio. Edifici e il funzionamento delle app che soddisfano questi requisiti richiede un'attenta pianificazione e la 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 è che funziona bene con uno o più utenti e che gestisce i picchi in modo efficiente e cali nel traffico.
La flessibilità nell'adeguare le risorse utilizzate da un'app è un'attività chiave che incentiva il passaggio al cloud. Con una progettazione corretta, puoi ridurre i costi rimuovendo le risorse sottoutilizzate senza compromettere le prestazioni o un'esperienza senza intervento manuale. Puoi allo stesso modo garantire una buona esperienza utente durante periodi di a traffico elevato aggiungendo altre risorse. In questo modo, la tua app può consumare le risorse necessarie per far fronte alla domanda.
Google Cloud fornisce prodotti e funzionalità per aiutarti a creare contenuti scalabili, app efficienti:
- Compute Engine di macchine virtuali Google Kubernetes Engine (GKE) i cluster si integrano con gestori della scalabilità automatica che ti consentono di aumentare o ridurre le risorse il consumo effettivo in base a metriche che definisci.
- di Google Cloud piattaforma serverless fornisce computing gestito, database e altri servizi scalabili rapidamente da zero a volumi elevati di richieste 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 su app e infrastruttura, aiutandoti a 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. Ciò è particolarmente vero per ad app distribuite, che possono contenere più livelli di infrastruttura reti e servizi. Si verificano errori e interruzioni e il miglioramento la resilienza della tua app è un percorso continuo. Con un'attenta pianificazione, puoi migliorare la capacità della tua app di resistere ai guasti. Con procedure appropriate e della cultura organizzativa, puoi anche imparare dagli errori per aumentare ulteriormente la resilienza della tua app.
Google Cloud fornisce strumenti e servizi per aiutarti a creare una disponibilità elevata e le app resilienti:
- 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.
- Google Compute Engine dischi permanenti a livello di regione vengono replicate 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
- di Google Cloud piattaforma serverless include prodotti gestiti per computing e database che offrono ridondanza e bilanciamento del carico.
- Google Cloud supporta CI/CD tramite strumenti e integrazioni nativi con le più diffuse soluzioni open source, per automatizzare la creazione e il deployment delle app.
- Cloud Monitoring fornisce metriche per tutte le app e infrastruttura, aiutandoti a prendere decisioni basate sui dati relative 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à
Tra i fattori che più si pongono in ambito commerciale rientrano i seguenti:
- Ottimizza i costi e il consumo di risorse.
- Riduci al minimo il tempo di inattività delle 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 chiave dello 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 ripristino automatico dagli errori.
- Riduci al minimo il lavoro ripetitivo grazie all'automazione.
- Riduci al minimo l'impatto dell'errore di un particolare componente.
Vincoli
I vincoli potrebbero limitare la capacità di aumentare la scalabilità e la resilienza della tua app. Assicurati che le decisioni relative alla progettazione non introducano o contribuiscano a questi vincoli:
- Dipendenze da hardware o software difficili da scalare.
- Dipendenze da hardware o software difficili da utilizzare in un configurazione ad alta disponibilità.
- Dipendenze tra le app.
- Limitazioni di licenza.
- Mancanza di competenze o esperienza nei team operativi e di sviluppo.
- Resistenza dell'organizzazione all'automazione.
Modelli e pratiche
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.
Negli schemi sono evidenti tre temi:
- Automazione. La creazione di app scalabili e resilienti richiede l'automazione. Automatizzare il provisioning, i test e i deployment delle app dell'infrastruttura aumenta la coerenza e la velocità e riduce al minimo l'errore umano.
- Basso accoppiamento. Considerare il sistema come una raccolta di informazioni componenti indipendenti accoppiati consentono flessibilità e resilienza. L'indipendenza copre il modo in cui distribuisci fisicamente le tue risorse e devi progettare l'app e progettare il tuo spazio di archiviazione.
- Progettazione basata sui dati. Raccolta di metriche per comprendere il comportamento la tua app è fondamentale. Decisioni su quando scalare la tua app oppure se un particolare servizio non è integro, devono essere basati sui dati. Metriche e 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, così come faresti 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, puoi usare Config Connector ti consente di gestire le risorse usando tecniche e flussi di lavoro Kubernetes. Google Cloud offre inoltre supporto integrato per gli strumenti IaC di terze parti più diffusi, tra cui Terraform, Chef e Puppet.
Crea un'infrastruttura immutabile
Un'infrastruttura immutabile è una filosofia che si basa sui vantaggi Infrastructure as Code. Un'infrastruttura immutabile impone che le risorse possono essere 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 invece di modificare le risorse, puoi ricrearle.
La creazione di un'infrastruttura immutabile porta a deployment più prevedibili e e rollback. Riduce anche i problemi comuni nelle infrastrutture mutabili, come la deviazione della configurazione server fiocco di neve. 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. Nel in termini più semplici, raggiungere una disponibilità elevata di solito implica la distribuzione di risorse di computing, bilanciamento del carico e replica dei dati.
Distribuzione fisica delle 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.
Puoi migliorare allo stesso modo la disponibilità e la resilienza delle app di cui hai 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).
Preferenza ai servizi gestiti
Anziché installare, supportare e utilizzare in modo indipendente tutte le parti del lo stack di applicazioni, puoi utilizzare i servizi gestiti per consumare parti dei tuoi come servizi. Ad esempio, anziché installare e gestire un database MySQL su macchine virtuali (VM), puoi utilizzare un database MySQL fornita 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 gestione dell'infrastruttura e più tempo per migliorare l'affidabilità della tua app.
Molti dei servizi gestiti di computing, database e archiviazione di Google Cloud offrono la ridondanza integrata, che può aiutarti a raggiungere i tuoi obiettivi di disponibilità. Molti di questi servizi offrono un modello regionale, ovvero l'infrastruttura che esegue la tua app si trova in una regione specifica ed è gestita da Google in modo ridondante in tutte le zone all'interno della regione. Se una zona diventa se non è disponibile, la tua app o i tuoi dati vengono pubblicati automaticamente da un'altra zona regione.
Alcuni servizi di database e archiviazione offrono anche la disponibilità multiregionale, Ciò significa che l'infrastruttura che esegue la tua app si trova in diverse regioni. I servizi multiregionali possono tollerare la perdita di un'intera regione, ma generalmente a scapito di una latenza maggiore.
Bilanciamento del carico a ogni livello
Il bilanciamento del carico 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 di controllo dello stato di integrità per garantire che il traffico non venga instradato a uno stato non integro 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 di bilanciatore del carico più appropriato a seconda del tipo, dell'origine e di altre aspetti del traffico. Per ulteriori informazioni, consulta Panoramica del bilanciamento del carico e GKE Panoramica del networking.
In alternativa, alcuni servizi gestiti da Google Cloud, come App Engine e Cloud Run, con bilanciamento del carico automatico.
È pratica comune bilanciare il carico delle richieste ricevute da origini esterne, ad esempio da client web o mobile. Tuttavia, l'uso di bilanciatori del carico diversi servizi o livelli all'interno della tua app possono anche aumentare la resilienza una maggiore flessibilità. Google Cloud offre servizi interni livello 4 e livello 7 del carico per questo scopo.
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à del un'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 le applicazioni strumenti di monitoraggio del codice sorgente, che forniscono un "pannello centralizzato" con per 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 l'integrità e le prestazioni di base per la tua app. Questo approccio al monitoraggio acquisisce informazioni come la CPU carico massimo, memoria utilizzata e numero di byte scritti su 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 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 offre 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 analizzare i dati di telemetria esportati.
Monitoraggio dei servizi
Per le app distribuite e basate su microservizi, è importante monitorare Interazioni tra i diversi servizi e componenti nelle tue app. Questi metriche possono aiutare a diagnosticare problemi quali un maggior numero di errori o e la latenza tra i servizi.
Istio è uno strumento open source che fornisce insight un controllo completo della rete di microservizi. Istio genera dati dettagliati per tutte le comunicazioni di 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, esegue i test esternamente un comportamento visibile come viene visto dall'utente. Questo tipo di monitoraggio controlla se un utente è in grado di completare azioni critiche entro le soglie che hai definito. Questo Un monitoraggio granulare può rilevare errori o latenza più granulare il monitoraggio potrebbe non funzionare e mostra la disponibilità percepita dall'utente.
Scopri lo stato delle tue app
Un sistema ad alta disponibilità deve avere un modo per determinare quali parti che il sistema sia integro e funzioni correttamente. Se vengono visualizzate determinate risorse se non è integro, il sistema può inviare richieste altrove. In genere i controlli di integrità comporta l'estrazione dei dati da un endpoint per determinare lo stato o l'integrità di una completamente gestito di Google Cloud.
Il controllo di integrità è una responsabilità chiave dei bilanciatori del carico. Quando crei un associato a un gruppo di istanze di macchine virtuali, definiscono anche 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 in esecuzione su GKE e bilanciare il carico del traffico esterno tramite risorsa in entrata, GKE crea automaticamente l'integrità appropriata per il bilanciatore del carico.
Kubernetes offre il supporto integrato per i probe di attività e di idoneità. Questi probe aiutano l'agente di orchestrazione Kubernetes a decidere come gestire pod e richieste nel tuo cluster. Se il deployment della tua app è stato eseguito su Kubernetes, è una buona idea esporre l'integrità della tua app a questi probe tramite endpoint appropriati.
Stabilisci 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 certo insieme di condizioni. Con Cloud Monitoring, puoi creare metriche personalizzate per acquisire queste condizioni. I sostenitori del libro sulla SRE di Google quattro segnali aurei per il monitoraggio di un sistema rivolto agli utenti: latenza, traffico, errori e saturazione.
Considera anche la tua tolleranza nei confronti dei valori anomali. Usare un valore medio o mediano per misurare lo stato di salute o le prestazioni potrebbero 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.
Definire gli obiettivi del livello di servizio (SLO)
Puoi usare le metriche raccolte dal sistema di monitoraggio per definire gli obiettivi del livello di servizio (SLO). Gli SLO specificano un livello target di prestazioni l'affidabilità per il tuo servizio. Gli SLO sono un pilastro fondamentale delle pratiche SRE e sono descritti in dettaglio nel obiettivi del livello di servizio capitolo sulla SRE, ma anche nel implementazione degli SLO capitolo SRE.
Puoi utilizzare la modalità monitoraggio dei servizi 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.
Archivia 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 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 una 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 le interdipendenze tra le app. Puoi utilizzare i dati anche per creare e e convalidare test significativi.
I dati storici possono anche aiutarti a verificare che la tua app supporti l'attività obiettivi durante i periodi chiave. Ad esempio, i dati possono aiutarti ad analizzare il modo in cui dell'app scalata durante eventi promozionali a traffico elevato nel corso qualche trimestre o addirittura qualche anno fa.
Per maggiori dettagli su come esportare e archiviare le metriche, consulta Esportazione delle metriche di Cloud Monitoring soluzione.
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 come una rappresentazione semplificata della scalabilità di un'app profilo. L'app mantiene un livello di base di risorse e utilizza la scalabilità automatica per rispondere ai cambiamenti della domanda.
Trova il giusto equilibrio tra costo ed esperienza utente
La decisione di scalare l'app riguarda fondamentalmente il bilanciamento dai costi in base all'esperienza utente. Stabilisci il tuo livello minimo accettabile delle prestazioni e potenzialmente anche dove fissare un tetto. 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 una latenza rigorosa obiettivi. Programmi di ricerca che anche piccoli ritardi possono influire negativamente su come gli utenti percepiscono la tua app. generando meno conversioni e meno 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 legati all'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. Pertanto, del 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 risorse di riferimento
Un altro componente fondamentale del profilo di scalabilità è la scelta di un un insieme minimo di risorse.
In genere le macchine virtuali di Compute Engine o i cluster GKE lo scale up 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, Cloud Functions e Cloud Run sono progettati per scalare fino a zero scalare rapidamente, anche in caso di avvio a freddo. In base al tipo di profilo del traffico e dell'app, queste tecnologie possono garantire 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 determinate condizioni 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 computing di Google Cloud dispongono di funzionalità di scalabilità automatica. Serverless e servizi gestiti come Cloud Run, Cloud Functions 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 scalare in base vari input, incluse metriche personalizzate di Cloud Monitoring e gestione del bilanciatore del carico e la capacità di archiviazione. Puoi impostare limiti minimo e massimo per il comportamento di scalabilità 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 della scalabilità automatica in base all'app chiave metriche, nel profilo di costo e nel livello minimo obbligatorio definito Google Cloud.
Riduci al minimo il tempo di avvio
Affinché la scalabilità sia efficace, deve avvenire abbastanza rapidamente aumentando il carico. Ciò è particolarmente vero quando si aggiungono risorse e la capacità di archiviazione.
Utilizza immagini precotte
Se la tua app viene eseguita su VM di Compute Engine, probabilmente dovrai installare e configurare le istanze per eseguire l'app. Sebbene sia possibile utilizzare script di avvio configurare nuove istanze, un modo più efficiente è creare immagine personalizzata. Un'immagine personalizzata è un disco di avvio che hai configurato con il software specifico della tua app e configurazione.
Per ulteriori informazioni sulla gestione delle immagini, consulta best practice per la gestione delle immagini .
Quando hai creato l'immagine, puoi definire modello di istanza. I modelli di istanza combinano l'immagine del disco di avvio, il tipo di macchina e altre istanze proprietà. 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 ulteriori informazioni, consulta bilanciare configurazione dell'immagine e velocità di deployment documenti.
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 portabilità, maggiore facilità di deployment e più facile da gestire su larga scala rispetto alle machine learning. 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 di app. Cloud Run offre una piattaforma di serverless computing gestita per ospitare i tuoi oggetti containerizzati. La L'ambiente flessibile di App Engine che ospita i tuoi container in una soluzione Platform as a Service (PaaS) gestita. GKE un ambiente Kubernetes gestito per l'hosting e l'orchestrazione containerizzate. Puoi anche eseguire l'app su Compute Engine quando devi assumere il controllo completo dell'ambiente dei container.
Ottimizza la tua app per un avvio rapido
Oltre a garantire che sia possibile eseguire il deployment dell'infrastruttura e dell'app nel modo più efficiente possibile, è importante anche assicurarti che la tua app sia 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 la tecnica lazy l'inizializzazione, in particolare di risorse costose.
- Riduci al minimo le dipendenze dell'app che potrebbero dover essere caricate al momento dell'avvio.
Preferisci le 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 di errore 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 a basso accoppiamento, può aumentare la flessibilità della tua app. Se adotti un design a basso accoppiamento, e consente il rilascio e il deployment di servizi in modo indipendente. Oltre a vantaggi, questo approccio consente ai servizi di usare stack tecnici e di gestione da parte di team diversi. Questo approccio a basso accoppiamento è il tema chiave dei pattern di architettura come microservizi e SOA.
Quando stai valutando come tracciare dei confini tra servizi, disponibilità e i requisiti di scalabilità sono dimensioni chiave. Ad esempio, se un determinato componente ha requisiti di disponibilità o profilo di scalabilità diversi dall'altro componenti, potrebbe essere un buon candidato come servizio autonomo.
Punta all'stateless
Un'app o un servizio stateless non conserva alcun dato o stato locale permanente. Un modello stateless assicura che sia possibile gestire ogni richiesta o interazione al 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 tal caso, in modo esplicito riguardo ai servizi che richiedono uno stato. Garantendo una separazione netta tra stateless e stateful, puoi garantire una semplice scalabilità stateless adottando un approccio più i servizi di machine learning.
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 aumenteranno anche le interdipendenze dei servizi. Non vuoi che l'errore di un servizio per causare il malfunzionamento di altri, a volte chiamato errore a cascata.
Puoi contribuire a ridurre il traffico verso un servizio sovraccarico o in caso di errore del servizio adottando tecniche come interruttore di sicurezza sequenza, backoff esponenziali, e una 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 che collega i servizi e aiuta a disaccoppiare la logica di business networking. Un mesh di servizi in genere fornisce funzionalità di resilienza come le richieste come tentativi, failover e interruttori di sicurezza.
Usare database e tecnologie di archiviazione appropriate
Alcuni database e tipi di archiviazione sono difficili da scalare e rendere resiliente. Assicurati che le scelte del database non prevedano limiti la disponibilità e la scalabilità dell'app.
Valuta le esigenze del tuo 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. Sono spesso difficili da scalare e richiedono un'attenta gestione 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, utilizzano una un approccio diverso. Sebbene i dettagli varino da un prodotto all'altro, i database NoSQL di solito sacrificano alcune caratteristiche dei database relazionali a favore di maggiori la disponibilità e la scalabilità più semplice. In termini Teorema della CAP, I database NoSQL spesso scelgono la disponibilità piuttosto che la coerenza.
L'adeguatezza di un database NoSQL spesso si riduce al grado richiesto per garantire la coerenza. 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.
Nell'ambito della gestione dei dati, i database relazionali e non relazionali vengono spesso visti come tecnologie complementari piuttosto che concorrenti. Utilizzando entrambi tipo di database in modo strategico, le organizzazioni possono sfruttare i punti di forza ciascuna 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, a elevata coerenza, disponibilità elevata e database distribuito a livello globale 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 fornisce un servizio completamente gestito basato su Redis in memoria datastore. Memorystore for Redis offre accesso a bassa latenza e velocità effettiva elevata per i dati ad alto accesso. Può essere implementato in un ambiente ad alta disponibilità che offre replica tra zone e failover automatico.
Modernizza i tuoi processi di sviluppo e la tua cultura
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. DevOps mirano a migliorare la qualità e l'affidabilità del software.
Una discussione dettagliata su DevOps esula dall'ambito di questo documento, ma alcuni aspetti chiave relativi al miglioramento dell'affidabilità e della resilienza dell'app sono trattati nelle sezioni seguenti. Per ulteriori dettagli, consulta Google Cloud Pagina DevOps.
Progettazione per la verificabilità
I test automatici sono un componente fondamentale delle moderne pratiche di distribuzione del software. La capacità di eseguire un insieme completo di unità, integrazioni e sistemi è essenziale per verificare che l'app funzioni come previsto e che possa alla fase successiva del ciclo di deployment. La testabilità è una progettazione fondamentale criterio per la tua app.
Ti consigliamo di utilizzare i test delle unità per la maggior parte dei test perché sono rapide da eseguire e in genere semplici da gestire. Abbiamo anche è consigliabile automatizzare l'integrazione di livello più alto e i test di sistema. Questi i test vengono semplificati notevolmente se adotti tecniche di Infrastructure as Code perché è possibile creare risorse e ambienti di test dedicati on demand. e poi verrà rimosso una volta completati i test.
Con l'aumento della percentuale del codebase coperta dai test, riduci dell'incertezza e della potenziale diminuzione dell'affidabilità causata da 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 set di test automatici su ogni commit di codice fornisce feedback sulle modifiche, migliorando la qualità e l'affidabilità del software. Strumenti nativi di Google Cloud come Cloud Build e strumenti di terze parti, come Jenkins può aiutarti a implementare l'integrazione continua.
Automazione dei deployment
L'integrazione continua e l'automazione completa dei test ti assicurano sicurezza la stabilità del software. Una volta implementati, il passaggio successivo è automatizzare il deployment della tua app. Il livello di automazione del deployment varia a seconda della 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, possono aumentare gradualmente l'esposizione delle nuove versioni a segmenti di pubblico più ampi, verificare il comportamento durante il processo. Puoi anche impostare disposizioni chiare per il rollback in caso di problemi.
Adottare pratiche SRE per gestire gli errori
Per le app distribuite che operano su larga scala, un certo grado di errore in uno o più componenti è comune. Se adotti gli schemi 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, altri servizi o infrastrutture che la tua app dipendono da dove 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 gli avvisi previsti generate e le metriche appropriate. Consigliamo un modello strutturato in cui introdurre semplici errori e poi riassegnare la richiesta.
Ad esempio, potresti procedere come segue, convalidando e documentando il comportamento in ogni fase:
- Introdurre 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 imitano gli errori nei sistemi upstream.
Testa 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 è abbinata a prestazioni test 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 diversi. Ad esempio, se stai testando la scalabilità del tuo sito di utenti, potresti misurare le latenze medie delle richieste per volumi picchi di richieste. Analogamente, per una funzionalità di elaborazione 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 delle attività di backend non supera un certo valore.
Inoltre, è importante testare i casi limite. Qual è la comportamento della tua app o del tuo servizio quando vengono raggiunti i limiti massimi di scalabilità? Che cos'è il comportamento se il servizio effettua lo scale down e il caricamento aumenta improvvisamente di nuovo?
Progettazione continua
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 principi per l'architettura cloud-native post del blog, essere sempre alla ricerca di 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 principi per l'architettura cloud-native post del blog.
- Leggi Libri sulla SRE per maggiori dettagli su come viene gestito l'ambiente di produzione 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.