Piattaforma dati per carichi di lavoro cruciali in Azure

In un'architettura mission-critical, qualsiasi stato deve essere archiviato al di fuori del calcolo il più possibile. La scelta della tecnologia si basa su queste caratteristiche principali dell'architettura:

Caratteristiche	Considerazioni
Prestazioni	Quanto è necessario calcolare?
Latenza	Quale impatto avrà la distanza tra l'utente e l'archivio dati sulla latenza? Qual è il livello di coerenza desiderato con compromesso sulla latenza?
Reattività	L'archivio dati deve essere sempre disponibile?
Scalabilità	Qual è lo schema di partizionamento?
Durabilità	I dati dovrebbero durare a lungo? Che cos'è il criterio di conservazione?
Resilienza	In caso di errore, l'archivio dati è in grado di eseguire automaticamente il failover? Quali misure sono state adottate per ridurre il tempo di failover?
Sicurezza	I dati vengono crittografati? È possibile raggiungere l'archivio dati tramite la rete pubblica?

In questa architettura sono disponibili due archivi dati:

• Database

  Archivia i dati correlati al carico di lavoro. È consigliabile archiviare tutti gli stati a livello globale in un database separato da stamp internazionali. Creare la ridondanza distribuendo il database tra aree. Per i carichi di lavoro cruciali, la sincronizzazione dei dati tra aree deve essere la principale preoccupazione. Inoltre, in caso di errore, le richieste di scrittura nel database devono essere ancora funzionanti.

  La replica dei dati in una configurazione attiva-attiva è altamente consigliata. L'applicazione deve essere in grado di connettersi immediatamente a un'altra area. Tutte le istanze devono essere in grado di gestire le richieste di lettura e scrittura.

• Broker messaggi

  L'unico servizio con stato nel timbro a livello di area è il broker di messaggi, che archivia le richieste per un breve periodo. Il broker serve la necessità di buffering e messaggistica affidabile. Le richieste elaborate vengono rese persistenti nel database globale.

Per altre considerazioni relative ai dati, vedere Linee guida critiche per Misson in Framework ben progettato: Considerazioni sulla piattaforma dati.

Database

Questa architettura usa Azure Cosmos DB per NoSQL. Questa opzione viene scelta perché fornisce le funzionalità più necessarie in questa progettazione:

• Scrittura in più aree

  La scrittura in più aree è abilitata con le repliche distribuite in ogni area in cui viene distribuito un timbro. Ogni stamp può scrivere localmente e Azure Cosmos DB gestisce la replica dei dati e la sincronizzazione tra i timbri. Questa funzionalità riduce significativamente la latenza per gli utenti finali distribuiti geograficamente dell'applicazione. L'implementazione di riferimento Mission-Critical di Azure usa la tecnologia multimaster per offrire la massima resilienza e disponibilità.

  La ridondanza della zona è abilitata anche all'interno di ogni area replicata.

  Per informazioni dettagliate sulle scritture in più aree, vedere Configurare scritture in più aree nelle applicazioni che usano Azure Cosmos DB.

• Gestione dei conflitti

  Con la possibilità di eseguire operazioni di scrittura in più aree, è necessario adottare un modello di gestione dei conflitti perché le scritture simultanee possono introdurre conflitti di record. Last Writer Wins è il modello predefinito e viene usato per la progettazione Mission Critical. L'ultimo writer, come definito dai timestamp associati dei record, vince il conflitto. Azure Cosmos DB per NoSQL consente anche di definire una proprietà personalizzata.

• Ottimizzazione query

  Una raccomandazione generale sull'efficienza delle query per i contenitori con un numero elevato di partizioni consiste nell'aggiungere un filtro di uguaglianza con itemID identificato. Per informazioni dettagliate sulle raccomandazioni sull'ottimizzazione delle query, vedere Risolvere i problemi di query quando si usa Azure Cosmos DB.

• Funzionalità di backup

  È consigliabile usare la funzionalità di backup nativa di Azure Cosmos DB per la protezione dei dati. La funzionalità di backup di Azure Cosmos DB supporta i backup online e il ripristino dei dati su richiesta.

Nota

La maggior parte dei carichi di lavoro non è puramente OLTP. Esiste una domanda crescente di report in tempo reale, ad esempio l'esecuzione di report sul sistema operativo. Questi processo prende il nome di Hybrid Transactional and Analytical Processing (HTAP). Azure Cosmos DB supporta questa funzionalità tramite Azure Collegamento a Synapse per Azure Cosmos DB.

Modello di dati per il carico di lavoro

Il modello di dati deve essere progettato in modo che le funzionalità offerte dai database relazionali tradizionali non siano necessarie. Ad esempio, chiavi esterne, schema di riga/colonna strict, viste e altri.

Il carico di lavoro presenta queste caratteristiche di accesso ai dati:

• Modello di lettura:
  • Letture punto: recupero di un singolo record. L'ID elemento e la chiave di partizione vengono usati direttamente per l'ottimizzazione massima (1 UR per richiesta).
  • Letture elenco: recupero di elementi del catalogo da visualizzare in un elenco. FeedIterator con limite al numero di risultati viene usato.
• Modello di scrittura:
  • Scritture di piccole dimensioni: le richieste in genere inseriscono un singolo o un numero ridotto di record in una transazione.
• Progettato per gestire il traffico elevato da parte degli utenti finali con la possibilità di ridimensionare la domanda di traffico nell'ordine di milioni di utenti.
• Piccole dimensioni del payload o del set di dati, in genere in ordine di KB.
• Tempo di risposta basso (in ordine di millisecondi).
• Bassa latenza (in ordine di millisecondi).

Impostazione

Azure Cosmos DB è configurato come segue:

• Il livello di coerenza è impostato sulla coerenza della sessione predefinita perché è il livello più diffuso per le singole aree e le applicazioni distribuite a livello globale. La coerenza più debole con una velocità effettiva maggiore non è necessaria a causa della natura asincrona dell'elaborazione di scrittura e non richiede bassa latenza per la scrittura del database.

  Nota

  Il livello di coerenza sessione offre un compromesso ragionevole per garantire la latenza, la disponibilità e la coerenza per questa specifica applicazione. È importante comprendere che il livello di coerenza assoluta non è disponibile per i database di scrittura multimaster.

• La chiave di partizione è impostata /id su per tutte le raccolte. Questa decisione si basa sul modello di utilizzo, che è principalmente "scrittura di nuovi documenti con GUID come ID" e "lettura di un'ampia gamma di documenti in base agli ID". Se il codice dell'applicazione mantiene l'univocità dell'ID, i nuovi dati vengono distribuiti uniformemente in partizioni da Azure Cosmos DB, abilitando la scalabilità infinita.

• I criteri di indicizzazione vengono configurati nelle raccolte per ottimizzare le query. Per ottimizzare i costi e le prestazioni delle UR, viene usato un criterio di indicizzazione personalizzato. Questo criterio indicizza solo le proprietà usate nei predicati di query. Ad esempio, l'applicazione non usa il campo di testo del commento come filtro nelle query. È stato escluso dai criteri di indicizzazione personalizzati.

Ecco un esempio dell'implementazione che mostra le impostazioni dei criteri di indicizzazione usando Terraform:

indexing_policy {

  excluded_path {
    path = "/description/?"
  }

  excluded_path {
    path = "/comments/text/?"
  }

  included_path {
    path = "/*"
  }

}

Per informazioni sulla connessione dall'applicazione ad Azure Cosmos DB in questa architettura, vedere Considerazioni sulla piattaforma delle applicazioni per carichi di lavoro cruciali

Servizi di messaggistica

I sistemi cruciali usano spesso servizi di messaggistica per l'elaborazione di messaggi o eventi. Questi servizi promuovono l'accoppiamento libero e fungono da buffer che isola il sistema contro picchi imprevisti della domanda.

• bus di servizio di Azure è consigliabile per i carichi di lavoro basati su messaggi quando si gestiscono messaggi di valore elevato.
• Hub eventi di Azure è consigliabile per i sistemi basati su eventi che elaborano volumi elevati di eventi o dati di telemetria.

Di seguito sono riportate considerazioni sulla progettazione e raccomandazioni per bus di servizio di Azure premium e Hub eventi di Azure in un'architettura cruciale.

Gestire il carico

Il sistema di messaggistica deve essere in grado di gestire la velocità effettiva richiesta (come in MB al secondo). Considerare quanto segue:

• I requisiti non funzionali (NFR) del sistema devono specificare la dimensione media dei messaggi e il numero massimo di messaggi al secondo ogni stamp deve supportare. Queste informazioni possono essere usate per calcolare il picco richiesto MB/secondo per timbro.
• L'impatto di un failover deve essere considerato quando si calcola il picco massimo richiesto MB/secondo per timbro.
• Per bus di servizio di Azure, le route definite dall'utente devono specificare qualsiasi funzionalità di bus di servizio avanzata, ad esempio sessioni e messaggi di deduplicazione. Queste funzionalità influiscono sulla velocità effettiva di bus di servizio.
• La velocità effettiva di bus di servizio con le funzionalità necessarie deve essere calcolata tramite test come MB/secondo per unità di messaggistica (MU). Per altre informazioni su questo argomento, vedere bus di servizio livelli di messaggistica Premium e Standard.
• La velocità effettiva di Hub eventi di Azure deve essere calcolata tramite test come MB/secondo per unità elaborate (TU) per il livello standard o l'unità di elaborazione (PU) per il livello Premium. Per altre informazioni su questo argomento, vedere Ridimensionamento con Hub eventi.
• I calcoli precedenti possono essere usati per verificare che il servizio di messaggistica possa gestire il carico necessario per stamp e il numero richiesto di unità di scala necessarie per soddisfare tale carico.
• La sezione operazioni illustra il ridimensionamento automatico.

Ogni messaggio deve essere elaborato

bus di servizio di Azure livello Premium è la soluzione consigliata per i messaggi di alto valore per cui l'elaborazione deve essere garantita. Di seguito sono riportati i dettagli relativi a questo requisito quando si usa bus di servizio di Azure Premium:

• Per assicurarsi che i messaggi vengano trasferiti e accettati correttamente dal broker, i producer di messaggi devono usare uno dei client API supportati bus di servizio. Le API supportate restituiranno correttamente da un'operazione di invio solo se il messaggio è stato salvato in modo permanente nella coda o nell'argomento.

• Per assicurarsi che i messaggi sul bus vengano elaborati, è consigliabile usare la modalità di ricezione PeekLock. Questa modalità abilita almeno una volta l'elaborazione. Di seguito viene descritto il processo:

  • Il consumer di messaggi riceve il messaggio da elaborare.
  • Al consumer viene assegnato un blocco esclusivo sul messaggio per un determinato periodo di tempo.
  • Se il consumer elabora correttamente il messaggio, invia un riconoscimento al broker e il messaggio viene rimosso dalla coda.
  • Se un riconoscimento non viene ricevuto dal broker nel periodo di tempo assegnato o il gestore abbandona esplicitamente il messaggio, il blocco esclusivo viene rilasciato. Il messaggio è quindi disponibile per consentire ad altri consumer di elaborare il messaggio.
  • Se un messaggio non viene elaborato correttamente un numero configurabile di volte o il gestore inoltra il messaggio alla coda di messaggi non recapitabili.
    • Per assicurarsi che i messaggi inviati alla coda dei messaggi non recapitabili vengano eseguiti, è necessario monitorare la coda dei messaggi non recapitabili e impostare gli avvisi.
    • Il sistema deve disporre di strumenti per consentire agli operatori di controllare, correggere e inviare di nuovo i messaggi.

• Poiché i messaggi possono essere elaborati più volte, i gestori di messaggi devono essere resi idempotenti.

Elaborazione dei messaggi Idempotenti

In RFC 7231, il protocollo di trasferimento ipertestuale indica " A ... il metodo viene considerato idempotente se l'effetto previsto sul server di più richieste identiche con tale metodo è uguale all'effetto di una singola richiesta".

Una tecnica comune di rendere idempotente la gestione dei messaggi consiste nel controllare un archivio permanente, ad esempio un database, se il messaggio è già stato elaborato. Se è stato elaborato, non si eseguirà la logica per elaborarla di nuovo.

• In alcuni casi l'elaborazione del messaggio include operazioni di database, in particolare l'inserimento di nuovi record con identificatori generati dal database. È possibile generare nuovi messaggi nel broker, che contengono tali identificatori. Poiché non sono presenti transazioni distribuite che includono sia il database che il broker di messaggi, può verificarsi una serie di complicazioni che possono verificarsi se il processo che esegue il codice non riesce. Vedere le situazioni di esempio seguenti:
  • Il codice che genera i messaggi può essere eseguito prima del commit della transazione di database, ovvero il numero di sviluppatori che usano il modello Unit of Work. Tali messaggi possono essere preceduti da escape, se si verifica l'errore tra la chiamata al broker e la richiesta di commit della transazione di database. Quando viene eseguito il rollback della transazione, vengono annullati anche gli ID generati dal database, che le lasciano disponibili ad altro codice che potrebbe essere in esecuzione contemporaneamente. Ciò può causare ai destinatari dei messaggi di escape di elaborare le voci di database errate, che danneggiano la coerenza complessiva e la correttezza del sistema.
  • Se gli sviluppatori inseriscono il codice che genera il messaggio al termine della transazione di database, il processo può comunque non riuscire tra queste operazioni (transaction committed - message sent). In questo caso, il messaggio passerà nuovamente all'elaborazione, ma questa volta la clausola di protezione dell'idempotenza noterà che è già stata elaborata (in base ai dati archiviati nel database). La clausola ignorerà il messaggio che emette codice, credendo che tutto sia stato eseguito correttamente l'ultima volta. I sistemi downstream, che si aspettavano di ricevere notifiche sul processo completato, non ricevono nulla. Questa situazione comporta di nuovo uno stato complessivo di incoerenza.
• La soluzione ai problemi precedenti comporta l'uso del modello Outbox transazionale, in cui i messaggi in uscita vengono archiviati sul lato, nello stesso archivio transazionale dei dati aziendali. I messaggi vengono quindi trasmessi al broker di messaggi, quando il messaggio iniziale è stato elaborato correttamente.
• Poiché molti sviluppatori non hanno familiarità con questi problemi o le relative soluzioni, per garantire che queste tecniche vengano applicate in modo coerente in un sistema mission-critical, è consigliabile avere la funzionalità della posta in uscita e l'interazione con il broker di messaggi incapsulato in un certo tipo di libreria. Tutte le elaborazioni del codice e l'invio di messaggi transazionale significativi devono usare tale libreria, anziché interagire direttamente con il broker di messaggi.
  • Le librerie che implementano questa funzionalità in .NET includono NServiceBus e MassTransit.

Disponibilità elevata e ripristino di emergenza

Il broker di messaggi deve essere disponibile per consentire ai produttori di inviare messaggi e consumer per riceverli. Di seguito sono riportati i dettagli relativi a questo requisito:

• Per garantire la massima disponibilità con bus di servizio, usare il livello Premium, che include il supporto per le zone di disponibilità nelle aree di supporto. Con le zone di disponibilità, i messaggi e i metadati vengono replicati in tre data center diversi nella stessa area.
• Usare gli SDK supportati bus di servizio o Hub eventi per ripetere automaticamente gli errori di lettura o scrittura.
• Prendere in considerazione la replica attiva-attiva o i modelli di replica attiva-passiva per isolare le emergenze a livello di area.

Nota

bus di servizio di Azure il ripristino di emergenza geografico replica solo i metadati tra aree. Questa funzionalità non replica i messaggi.

Monitoraggio

Il sistema di messaggistica funge da buffer tra producer di messaggi e consumer. Esistono tipi di indicatori chiave da monitorare in un sistema mission-critical che fornisce informazioni dettagliate preziose descritte di seguito:

• Limitazione: la limitazione indica che il sistema non dispone delle risorse necessarie per elaborare la richiesta. Sia bus di servizio che hub eventi supportano il monitoraggio delle richieste limitate. È consigliabile avvisare su questo indicatore.
• Profondità coda: una profondità della coda in aumento può indicare che i processori di messaggi non funzionano o che non sono presenti processori sufficienti per gestire il carico corrente. La profondità della coda può essere usata per informare la logica di ridimensionamento automatico dei gestori.
  • Per bus di servizio, la profondità della coda viene esposta come conteggio dei messaggi
  • Per Hub eventi, i consumer devono calcolare la profondità della coda per partizione ed eseguire il push della metrica nel software di monitoraggio. Per ogni lettura, il consumer ottiene il numero di sequenza dell'evento corrente e le proprietà dell'evento dell'ultimo evento accodato. Il consumer può calcolare l'offset.
• Coda di messaggi non recapitabili: i messaggi nella coda dei messaggi non recapitabili rappresentano messaggi che non possono essere elaborati. Questi messaggi richiedono in genere un intervento manuale. Gli avvisi devono essere impostati nella coda dei messaggi non recapitabili.
  • bus di servizio include una coda di messaggi non recapitabili e una metrica DeadLetteredMessages.
  • Per Hub eventi, questa funzionalità deve essere una logica personalizzata incorporata nel consumer.
• Utilizzo cpu/memoria : la CPU e la memoria devono essere monitorate per garantire che il sistema di messaggistica disponga di risorse sufficienti per elaborare il carico corrente. Sia bus di servizio Premium che hub eventi premium espongono l'utilizzo della CPU e della memoria.
  • Le unità di messaggistica (MU) vengono usate in bus di servizio per isolare risorse come CPU e memoria per uno spazio dei nomi. L'aumento della CPU e della memoria al di sopra di una soglia può indicare che non sono state configurate sufficienti UNITÀ MU, mentre scende al di sotto di altre soglie può indicare che sono presenti troppe UNITÀ MU configurate. Questi indicatori possono essere usati per ridimensionare automaticamente le unità MU.
  • Il livello Premium di Hub eventi usa unità di elaborazione (PU) per isolare le risorse, mentre il livello Standard usa unità elaborate (UR). Questi livelli non richiedono l'interazione con CPU/memoria per gonfiare automaticamente le UNITÀ RICHIESTA o le UNITÀ elaborate.

Controllo integrità

L'integrità del sistema di messaggistica deve essere considerata nei controlli di integrità per un'applicazione cruciale. Prendere in considerazione i fattori seguenti:

• Il sistema di messaggistica funge da buffer tra producer di messaggi e consumer. Il timbro può essere visualizzato come integro se i produttori sono in grado di inviare correttamente messaggi al broker e se i consumer sono in grado di elaborare correttamente i messaggi dal broker.
• Il controllo integrità deve assicurarsi che i messaggi possano essere inviati al sistema di messaggi.

Passaggi successivi

Distribuire l'implementazione di riferimento per ottenere una conoscenza completa delle risorse e della relativa configurazione usata in questa architettura.

Implementazione: Mission-Critical Online