Applicazioni cloud scalabili e progettazione dell'affidabilità del sito (SRE)

Frontdoor di Azure
Gestione API di Azure
Servizio Azure Kubernetes (AKS)
Gateway applicazione di Azure

Il successo della soluzione cloud dipende dall'affidabilità. L'affidabilità è la probabilità che il sistema funzioni come previsto, in condizioni specificate, entro un periodo di tempo specificato. Per Site Reliability Engineering (SRE) si intende un set di principi e procedure per la creazione di sistemi software scalabili e altamente affidabili. SRE è un approccio standard per la progettazione di servizi digitali per supportare gli obiettivi di affidabilità nel carico di lavoro.

Questo articolo illustra come applicare i principi SRE a una piattaforma API scalabile. Questa architettura definisce gli indicatori del livello di servizio (SLI) e gli obiettivi del livello di servizio (SLO), modella la scala e le aspettative sulle prestazioni, e stabilisce procedure di monitoraggio. Queste tecniche consentono di garantire affidabilità misurabile e ottenibile.

Per altre informazioni, vedere Sviluppare una strategia SRE.

Architettura

Diagramma che mostra una piattaforma API scalabile.

Scaricare un file di Visio di questa architettura.

Flusso di dati

Il flusso di dati seguente corrisponde al diagramma precedente:

  1. Le applicazioni client, ad esempio app Web, app per dispositivi mobili e applicazioni di servizio, inviano richieste all'endpoint https://api.contoso.comunificato .

  2. Frontdoor di Azure riceve tutte le richieste in ingresso e fornisce la terminazione SSL (Secure Sockets Layer) e la protezione di Web application firewall di Azure.

  3. Frontdoor di Azure instrada le richieste a Gestione API di Azure, che applica criteri per il controllo di accesso, la limitazione della frequenza, la memorizzazione nella cache e la trasformazione delle richieste.

  4. Gestione delle API inoltra le richieste all'Application Gateway per i Contenitori, che bilancia il carico del traffico attraverso il cluster AKS.

  5. Il microservizio appropriato nel servizio Azure Kubernetes elabora la richiesta. I microservizi includono prodotti, profili, ordini e servizi di pagamento e contenuti. Ogni microservizio genera dati di telemetria che contribuiscono ai calcoli SLI per la disponibilità, la latenza e la velocità effettiva.

  6. I microservizi accedono agli archivi dati back-end in base alle esigenze:

    • Azure Cosmos DB per dati a bassa latenza e distribuiti a livello globale
    • SQL di Azure per i dati relazionali
    • Archiviazione di Azure e Azure Data Lake Storage per contenuti e file non strutturati

  7. Microsoft Entra ID autentica e autorizza gli utenti e le entità servizio in tutto il flusso di richiesta.

  8. Monitoraggio di Azure e Application Insights raccolgono i dati di telemetria in modo indipendente a ogni livello:

    • Metriche delle richieste di Frontdoor di Azure
    • Esecuzione dei criteri di Gestione API
    • Bilanciamento del carico del gateway delle applicazioni per container
    • Metriche a livello di pod di AKS
    • Tempi di risposta dell'archivio dati

    I team SRE usano la raccolta per livello per calcolare gli SLI compositi, identificare le fonti di degrado e tenere traccia della conformità agli SLO.

  9. La risposta percorre lo stesso tragitto verso l'applicazione client.

Questa architettura rappresenta una piattaforma API scalabile. La soluzione include più microservizi che usano vari database e servizi di archiviazione.

Lo scenario di esempio illustra i casi d'uso di marketplace e e-commerce di alto livello:

  • Navigazione dei prodotti
  • Registrazione e accesso
  • Visualizzazione di contenuti, ad esempio articoli di notizie
  • Gestione degli ordini e delle sottoscrizioni

Le applicazioni client, ad esempio app Web, app per dispositivi mobili e applicazioni di servizio usano i servizi della piattaforma API tramite un percorso di accesso unificato, https://api.contoso.com.

Componenti

  • Frontdoor di Azure è un moderno servizio di rete per la distribuzione di contenuti cloud che usa la rete perimetrale globale Microsoft per creare applicazioni Web scalabili. In questa architettura funge da punto di ingresso singolo per tutte le richieste client. Fornisce la terminazione SSL e applica le regole del Web Application Firewall di Azure prima di instradare il traffico ad Azure API Management. Per altre informazioni, vedere Panoramica dell'architettura di routing.

  • Gestione API è un servizio gateway API gestito che fornisce una piattaforma ibrida di gestione multicloud per le API in tutti gli ambienti. In questa architettura funziona come gateway API. Applica i criteri di controllo di accesso, applica la limitazione della frequenza, memorizza nella cache le risposte usando Redis gestito di Azure come cache esterna e trasforma le richieste prima di inoltrarle ai servizi back-end. Gestione API supporta la scalabilità automatica nei livelli Standard e Premium.

  • Il servizio Azure Kubernetes è un servizio di orchestrazione di contenitori gestito che fornisce una piattaforma Kubernetes per l'esecuzione di applicazioni in contenitori. In questa architettura ospita tutti i microservizi, inclusi prodotti, profili, ordini e pagamenti e servizi di contenuto. Azure gestisce il piano di controllo e tu gestisci i nodi dell'agente.

  • Il Gateway delle applicazioni per container è un bilanciatore di carico delle applicazioni che fornisce la gestione dinamica del traffico per i carichi di lavoro eseguiti in un cluster Kubernetes. In questa architettura, il sistema fornisce il bilanciamento del carico di livello 7 per il traffico in ingresso nel cluster AKS. Distribuisce le richieste da Gestione API tra i pod di microservizi.

  • Azure Cosmos DB è un servizio di database relazionale e NoSQL gestito con distribuzione globale e scalabilità automatica. In questa architettura archivia i dati del catalogo prodotti e del profilo che richiedono un accesso distribuito a livello globale a bassa latenza. La velocità effettiva con scalabilità automatica regola la capacità in base alla domanda.

  • Azure SQL è una famiglia di servizi di database relazionali gestiti che usano il motore di database di SQL Server in Azure. In questa architettura archivia i dati relazionali per ordini, sottoscrizioni e record transazionali.

  • Archiviazione di Azure è un servizio di archiviazione cloud che include oggetti, file, disco, coda e archiviazione tabelle. Azure Data Lake Storage è un servizio Data Lake altamente scalabile per carichi di lavoro di analisi ad alte prestazioni. In questa architettura questi servizi archiviano contenuti non strutturati, ad esempio asset multimediali, documenti e file.

  • Microsoft Entra ID è un servizio di gestione delle identità e degli accessi basato sul cloud che autentica e autorizza gli utenti ad accedere alle risorse. In questa architettura, fornisce la gestione centralizzata delle identità e degli accessi per gli utenti e le entità servizio in tutti i servizi.

  • Monitoraggio di Azure è un servizio di osservabilità per la raccolta, l'analisi e la risposta ai dati di monitoraggio dagli ambienti cloud e locali. Application Insights è un'estensione di Monitoraggio di Azure che fornisce funzionalità di monitoraggio delle prestazioni delle applicazioni (APM). In questa architettura, questi servizi raccolgono i dati di telemetria in tutti i livelli. Calcolano gli SLI, tengono traccia della conformità agli SLO e forniscono dashboard per avvisi proattivi. Monitoraggio di Azure supporta OpenTelemetry e si integra con Grafana con gestione Azure per il tracciamento distribuito e la visualizzazione.

  • Azure Chaos Studio è un servizio di progettazione chaos gestito che consente di misurare, comprendere e migliorare la resilienza dell'applicazione cloud e del servizio. In questa architettura inserisce errori e convalida la resilienza del sistema durante i test di resilienza e ripristino.

Alternative

Per il piano di calcolo, considerare quanto segue:

  • App Azure Container per microservizi e carichi di lavoro basati su eventi. Supporta i contenitori serverless e la scalabilità automatica basata su KEDA senza richiedere la gestione del cluster Kubernetes. Questa scelta sostituisce sia Azure Kubernetes Service che Application Gateway per i contenitori perché le App per contenitori forniscono l'ingresso integrato.

  • Web App for Containers per i team che hanno familiarità con il Servizio App e necessitano solo di accesso HTTP/HTTPS. Questa scelta sostituisce Azure Kubernetes Service (AKS) e il Gateway applicazioni per i contenitori con una piattaforma completamente gestita, ma offre un controllo di scalabilità meno granulare.

  • Funzioni di Azure per i servizi API serverless in cui è possibile distribuire singoli endpoint API come funzioni indipendenti. Questa scelta sostituisce il modello di microservizio con funzioni per endpoint e si adatta alle API basate su eventi o a traffico ridotto.

Per il livello dati, prendere in considerazione Microsoft Fabric con il mirroring di Azure Cosmos DB nel caso in cui siano necessarie analisi sui dati operativi. Fabric aggiunge un livello di report e analisi accanto agli archivi transazionali esistenti senza utilizzare unità di richiesta.

Dettagli dello scenario

Questo scenario di esempio illustra come applicare procedure SRE a una piattaforma API scalabile che gestisce i casi d'uso del marketplace e dell'e-commerce. L'articolo è incentrato su come definire Indicatori di Livello di Servizio (SLIs) e Obiettivi di Livello di Servizio (SLOs), scala e modellazione delle aspettative sulle prestazioni, e usare tali risultati per stabilire il monitoraggio e gli avvisi.

Potenziali casi d'uso

I concetti illustrati in questo articolo si applicano a:

  • Servizi cloud basati su API.
  • Applicazioni Web pubbliche.
  • Carichi di lavoro basati su Internet delle cose (IoT) o basati su eventi.
  • Piattaforme di e-commerce con l'esplorazione, la registrazione e la gestione degli ordini dei prodotti.
  • Applicazioni per la distribuzione di contenuti per articoli e contenuti multimediali.

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Well-Architected Framework.

Affidabilità

L'affidabilità consente di garantire che l'applicazione possa soddisfare gli impegni assunti dai clienti. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'affidabilità.

Il contesto aziendale determina i requisiti di affidabilità. Le procedure SRE consentono di ottenere il livello di affidabilità appropriato. Si misura l'affidabilità tramite gli obiettivi di livello di servizio (SLO), che impostano traguardi espressi in percentuale su periodi di tempo. Gli indicatori di livello di servizio (SLI) sono le metriche che si misurano per determinare gli obiettivi di livello di servizio (SLO), in base all'esperienza del cliente. Per altre informazioni, vedere Definire le metriche di SLI per calcolare gli obiettivi di livello di servizio.

Questa architettura incorpora diversi modelli di affidabilità:

  • Ridondanza della zona: Frontdoor di Azure, Application Gateway, e AKS supportano la distribuzione nelle zone di disponibilità per alta disponibilità all'interno di una regione.

  • Scalabilità automatica: Frontdoor di Azure viene ridimensionato automaticamente in base al volume di traffico. Il gateway applicativo per i container regola le unità di capacità automaticamente. Il servizio Azure Kubernetes (AKS) utilizza il ridimensionamento automatico del cluster per i nodi e l'Autoscaler Orizzontale dei Pod per i pod. Gestione API supporta la scalabilità automatica nei livelli Standard e Premium. La capacità di throughput autoscalabile di Azure Cosmos DB viene modificata in base al consumo di unità di richiesta. Queste funzionalità consentono al sistema di gestire le variazioni di carico senza intervento manuale.

  • Monitoraggio della salute: Usare Monitoraggio di Azure e Application Insights per tenere traccia degli Indicatori di Livello di Servizio (SLI) e degli Obiettivi di Livello di Servizio (SLO) e identificare in modo proattivo i problemi di affidabilità.

  • Test di resilienza e ripristino: Usare Chaos Studio per convalidare la tolleranza di errore e le procedure di ripristino.

sicurezza

La sicurezza offre garanzie contro attacchi intenzionali e l'uso improprio dei dati e dei sistemi preziosi. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per la sicurezza.

Questa architettura risolve la sicurezza tramite più livelli:

  • Gestione delle identità e degli accessi: Microsoft Entra ID offre una gestione centralizzata delle identità per gli utenti e le entità servizio.

  • Sicurezza di rete: Web application firewall di Azure, integrato con Frontdoor di Azure, offre protezione da exploit Web comuni, tra cui Open Worldwide Application Security Project (OWASP) Principali 10 vulnerabilità. Gestione API applica controlli di accesso a livello di rete, ad esempio il filtro degli indirizzi IP e la limitazione della frequenza.

  • Sicurezza del gateway API: Gestione API applica l'autenticazione e l'autorizzazione a livello di applicazione tramite la convalida del token OAuth 2.0 e l'autenticazione del certificato. Questi criteri convalidano l'identità del chiamante a livello di richiesta API, separate dalle protezioni a livello di rete fornite da Web application firewall e filtro indirizzi IP.

  • Protezione dei dati: Usare le identità gestite per l'autenticazione da servizio a servizio. Attivare la crittografia dei dati inattivi per tutti gli archivi dati.

Ottimizzazione dei costi

L'ottimizzazione dei costi è incentrata sui modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'ottimizzazione dei costi.

Dal punto di vista di un SRE, l'ottimizzazione dei costi si riferisce direttamente al modo in cui effettui il provisioning dell'infrastruttura di monitoraggio, definisci le soglie di scalabilità automatica e allocchi il budget per gli errori. L'overprovisioning degrada l'efficienza dei costi. Il sottodimensionamento delle risorse degrada l'affidabilità.

I principali driver di costo correlati a SRE in questa architettura includono:

  • Monitoraggio e osservabilità: Monitoraggio di Azure, Application Insights e Grafana gestito di Azure comportano costi in base al volume di inserimento dati, ai criteri di conservazione e al conteggio delle regole di avviso. Ottimizzare i tassi di campionamento e i periodi di conservazione per bilanciare la profondità di osservabilità rispetto ai costi.

  • Sovraccarico della scalabilità automatica: Le risorse di calcolo, ad esempio i pool di nodi del servizio Azure Kubernetes e le unità di scala di Gestione API, rappresentano la variabile di costo più grande. Impostare attentamente le soglie minime di scalabilità automatica. Impostarli troppo in alto spreca risorse, mentre impostarli troppo in basso comporta il rischio di violazioni degli SLO durante i picchi di traffico. Usare i dati di monitoraggio per calibrare le soglie.

  • Investimento nel budget di errore: Quando gli errori rimangono entro il budget degli errori, investire in nuove funzionalità. Quando i guasti consumano il tuo budget, investi nell'affidabilità. Questa procedura impedisce la spesa superflua per i miglioramenti dell'affidabilità quando il sistema soddisfa già i relativi contratti di servizio.

Altri fattori di costo includono:

  • Gestione API: I costi variano in base al livello. I livelli Standard e Premium supportano la scalabilità automatica, ma a costi di base più elevati rispetto ai livelli Developer e Basic, che non supportano la scalabilità automatica.

  • Servizi dati: I costi di Azure Cosmos DB dipendono dalla velocità effettiva e dall'archiviazione di cui è stato effettuato il provisioning. Usare il throughput autoscalabile per ottimizzare i carichi di lavoro variabili.

  • Networking: Frontdoor di Azure e Gateway Applicativo per contenitori comportano costi in base al volume di traffico e alle funzionalità attive.

Per ottimizzare i costi:

  • Usare le raccomandazioni di Azure Advisor per le istanze riservate e i piani di risparmio di Azure.
  • Ridimensiona i pool di nodi di AKS in base all'effettivo utilizzo.
  • Configurare le soglie di scalabilità automatica per bilanciare le prestazioni e i costi.
  • Usare la scalabilità automatica di Azure Cosmos DB per evitare il provisioning eccessivo.

Usare il calcolatore prezzi di Azure per stimare i costi per questa architettura.

Eccellenza operativa

L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e la mantengono in esecuzione nell'ambiente di produzione. Per ulteriori informazioni, vedere Lista di controllo per la revisione del design per l'Eccellenza Operativa.

Creare un processo olistico di governance delle prestazioni per gestire le prestazioni durante il ciclo di vita del servizio.

  • Obiettivi di prestazioni: Definire obiettivi di livello di servizio aspirazionali in base ai requisiti aziendali.

  • Modellazione delle prestazioni: Identificare i flussi di lavoro critici per l'azienda e le prestazioni previste del modello.

  • Strumentazione: Usare Monitoraggio di Azure e Application Insights per APM, dati di telemetria e analisi delle metriche. Monitoraggio di Azure supporta OpenTelemetry e si integra con Grafana con gestione Azure per il tracciamento distribuito e la visualizzazione.

  • Test delle prestazioni: Eseguire test di carico e stress usando strumenti come K6, Karate e JMeter. Integrare test automatizzati nelle pipeline di distribuzione continua.

  • Monitoraggio continuo: Configurare gli avvisi in base alle soglie SLI e tenere traccia della conformità SLO.

  • Distribuzione basata su anello: Usare strategie di rilascio progressive per minimizzare l'impatto delle modifiche.

Tenere traccia degli obiettivi di prestazioni come storie utente granulari nel backlog per assicurarsi di classificare in ordine di priorità le attività di governance insieme al lavoro delle funzionalità.

Efficienza delle prestazioni

L'efficienza delle prestazioni si riferisce alla capacità del carico di lavoro di ridimensionarsi per soddisfare in modo efficiente le esigenze degli utenti. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'efficienza delle prestazioni.

Progettare applicazioni in modo che le risorse vengano ridimensionate automaticamente per soddisfare il carico. Questa progettazione include l'infrastruttura di calcolo, archiviazione e messaggistica.

Applicare tecniche di scalabilità e modellazione delle prestazioni per ottimizzare l'architettura e la progettazione:

  • Identificare i requisiti di scalabilità.
  • Carico previsto del modello.
  • Definire SLIs e SLOs per gli scenari utente.

Acquisire i requisiti di scalabilità

Presupporre queste metriche di carico di picco:

  • Numero di consumatori: 1,5 milioni
  • Consumatori attivi orari (30%): 450.000
  • Distribuzione del carico:
    • Esplorazione del prodotto: 75%
    • Registrazione e accesso: 10%
    • Ordini e sottoscrizioni: 10%
    • Visualizzazione del contenuto: 5%

Requisiti di scalabilità delle API in base al normale carico di picco:

  • Microservizio prodotto: circa 500 richieste al secondo (RPS)
  • Microservizio profilo: circa 100 richieste al secondo
  • Ordini e microservizi di pagamento: circa 100 RPS
  • Microservizio per i contenuti: circa 50 RPS

Durante eventi speciali, i requisiti di scalabilità possono raggiungere 10 volte il normale carico di picco.

Definire le metriche SLI per calcolare gli SLO

Le metriche SLI indicano il grado in cui un servizio offre un'esperienza soddisfacente, espressa come rapporto tra eventi validi e eventi totali.

La tabella seguente illustra le metriche SLI di esempio.

Metrico Descrizione
Disponibilità Indica se l'API ha risolto la richiesta
Latenza Tempo necessario per l'API per elaborare la richiesta e la risposta
Velocità effettiva Numero di richieste gestite
Tasso di successo Numero di richieste gestite correttamente
Percentuale di errore Numero di errori per le richieste gestite
Freschezza Numero di volte in cui l'utente ha ricevuto i dati più recenti

Per ogni SLI, si calcola il rapporto tra eventi validi e eventi totali, come osservato dal cliente. Gli esempi seguenti illustrano questo calcolo per diversi scenari utente:

  • SLI di latenza per l'esplorazione del prodotto:Numero di richieste completate correttamente in <1.000 ms diviso per il numero di richieste. Questo SLI tiene traccia del fatto che il microservizio del prodotto risponda entro la soglia di latenza accettabile.

  • Aggiornamento SLI per la ricerca:Numero di risultati della ricerca restituiti entro tre secondi divisi per il numero di ricerche. Questo SLI misura la frequenza con cui l'esperienza di ricerca rispetta l'obiettivo di freschezza dopo gli aggiornamenti del catalogo.

Dopo aver definito gli SLI, determinare i dati di telemetria da acquisire a ogni livello dell'architettura, tra cui Frontdoor di Azure, API Management, Application Gateway, pod AKS e archivi dati. Per i servizi HTTP, usare i codici di stato per classificare l'esito positivo e negativo. Monitoraggio di Azure e Application Insights forniscono supporto di diagnostica e monitoraggio per tutti i livelli.

Usare le distribuzioni percentili per calcolare alcuni indicatori di livello di servizio ed escludere valori anomali. Ad esempio, se la latenza del 95° percentile rientra nella soglia, il sistema soddisfa lo SLO.

Definire i periodi di misurazione SLO per acquisire l'attività, non l'inattività. La finestra può variare da cinque minuti a 24 ore.

Definire obiettivi del livello di servizio ambiziosi per la soluzione di destinazione

Si considerino i seguenti esempi di SLO proposti:

  • Le richieste READ rispondono entro un secondo per 95% di chiamate.
  • Le richieste CREATE e UPDATE rispondono entro tre secondi per 95% di chiamate.
  • Tutte le richieste rispondono entro cinque secondi senza errori per 99% di chiamate.
  • Tutte le richieste hanno esito positivo senza errori per 99.9% di chiamate.
  • Durante l'ora di punta, meno di 1% di richieste generano errori.

Personalizzare gli obiettivi di livello di servizio in base ai requisiti dell'applicazione.

Misurare gli obiettivi di livello di servizio iniziali in base ai dati dei registri

Si supponga una settimana di dati:

  • Richieste: 123.456
  • Richieste riuscite: 123,204
  • Latenza al 90° percentile: 497 ms
  • Latenza al 95° percentile: 870 ms
  • Latenza al 99° percentile: 1.024 ms

Contratti di servizio iniziali:

  • Disponibilità = (123.204 / 123.456) = 99,8%.
  • Le richieste vengono gestite entro 500 ms per 90% di chiamate.
  • Le richieste vengono gestite entro 1.000 ms per 98% di chiamate.

Confrontare i dati di log con gli obiettivi SLO per valutare la conformità.

Indicazioni per la mitigazione dei rischi tecnici

Seguire queste procedure consigliate:

  • Progettare tenendo presenti scalabilità e prestazioni.

    • Acquisire i requisiti di scalabilità per tutti gli scenari, inclusi i picchi.
    • Prestazioni del modello per identificare i vincoli.

  • Gestire il debito tecnico.

    • Traccia le metriche delle prestazioni.
    • Usare strumenti come K6, Karate e JMeter per i test di carico.
    • Integrare test automatizzati nella distribuzione continua.

  • Adottare una mentalità di produzione.

    • Regolare le soglie di scalabilità automatica in base alle statistiche sulle prestazioni.
    • Preferisce la scalabilità orizzontale.
    • Usare la distribuzione basata su anelli.
    • Usare i budget degli errori per determinare quando investire in miglioramenti dell'affidabilità rispetto alle nuove funzionalità. Un margine d'errore è la differenza tra il 100% e il tuo obiettivo SLO. Ad esempio, un SLO del 99,9% consente un budget di errore dello 0,1%. Se i guasti effettivi utilizzano questo budget, assegnare priorità agli interventi per migliorare l'affidabilità al fine di ridurre i tassi di guasto. Se gli errori rimangono entro il budget, investire nella sperimentazione e nel recapito delle funzionalità.
    • Usare Chaos Studio per i test di resilienza.

Collaboratori

Microsoft gestisce questo articolo. I collaboratori seguenti hanno scritto questo articolo.

Autore principale:

Altro collaboratore:

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi