Operatore alternativo: informazioni aggiuntive per architetture cloud resilienti

Aggiornamento: giugno 2014

Autori: Marc Mercuri, Ulrich Homann, Mark Simms, Jason Wescott e Andrew Townhill

Revisori: Michael Thomassy, Curt Peterson, Stuart Ozer, Fran Dougherty, Tim O’Brien, Hatay Tuna, Patrick Butler Monterde, Mark Kottke, Lewis Curtis, William Bellamy

Data di pubblicazione: giugno 2014

Operatore alternativo nome. Progettato per funzionare automaticamente in modo da impedire l'arresto di un meccanismo, sistema o di altri elementi simili.

I singoli utenti, a prescindere dal fatto che siano dipendenti, cittadini o utenti, richiedono l'accesso immediato ai servizi di applicazioni, calcoli e dati. Il numero di persone connesse e i dispositivi usati per connettersi a questi servizi sono in continua crescita. In questo mondo di servizi sempre attivi, i sistemi che li supportano devono essere progettati in modo da essere disponibili e resilienti.

Questi servizi vengono distribuiti in ambienti cloud con commodity in configurazioni predefinite. In genere, è possibile che sia stato acquistato un prodotto hardware di fascia alta a cui applicare la scalabilità verticale. Al contrario, gli ambienti cloud prevedono la scalabilità orizzontale. I costi degli ambienti cloud vengono mantenuti bassi grazie all'impiego di hardware apposito. Questo hardware è soggetto a errori, pertanto per il cloud è necessario che l'architettura sia in grado di far fronte a tutti gli effetti all'eventualità di errori. In genere, l'attenzione viene posta sulla prevenzione degli errori e sull'ottimizzazione del "tempo medio tra gli errori". In questo nuovo ambiente, l'attenzione si sposta sul "tempo medio per il ripristino con impatto minimo".

Con ogni probabilità, i servizi sviluppati saranno servizi compositi composti da una o più piattaforme proprietarie o di terze parti e da servizi di provider di terze parti. Tali servizi verranno creati su un'infrastruttura cloud soggetta a errori. L'architettura deve inoltre presupporre che i servizi usati saranno soggetti a errori. Come per l'architettura dell'infrastruttura, anche la progettazione dell'architettura delle applicazioni deve prevedere l'eventualità di errori.

L'iniziativa di operatore alternativo di Microsoft è stata progettata per fornire informazioni aggiuntive generali per la creazione di architetture cloud resilienti, nonché per l'implementazione di queste architetture nelle tecnologie Microsoft e per scenari specifici. Gli autori di questo documento sono membri del reparto Cloud ed Enterprise di Microsoft, del Trustworthy Computing e dei Servizi di consulenza Microsoft.

Questo documento illustra considerazioni architetturali relative alla progettazione di sistemi scalabili e resilienti.

Il documento è organizzato nelle sezioni seguenti:

  • Scomporre l'applicazione in base al carico di lavoro: illustra come un approccio basato sul carico di lavoro sia più efficace in termini di disponibilità e resilienza e descrive come tramite esso vengano garantiti un controllo migliore dei costi e una maggiore flessibilità nella scelta delle tecnologie più appropriate per il carico di lavoro.

  • Stabilire un modello di ciclo di vita: se si stabilisce un modello di ciclo di vita dell'applicazione si può definire il comportamento previsto di un'applicazione in produzione. Inoltre, vengono forniti requisiti e informazioni dettagliate per l'intera architettura.

  • Stabilire un modello e un piano di disponibilità: tramite questo modello viene identificato il livello di disponibilità previsto per il carico di lavoro. Si tratta di un elemento molto importante in quanto, tramite esso, verranno presentate molte delle decisioni prese quando si stabilisce il servizio.

  • Identificare i punti, le modalità e le conseguenze degli errori: per creare un'architettura resiliente è importante comprendere e identificare i punti e le modalità di errore. In particolare, se si compie uno sforzo attivo per comprendere e documentare le possibili cause di un'interruzione, si potrà stabilire una struttura da usare durante l'analisi e la pianificazione.

  • Modelli e considerazioni sulla resilienza: si tratta della sezione principale del documento, che include considerazioni fondamentali sui servizi di calcolo, archiviazione e piattaforma. Queste considerazioni riguardano procedure comprovate per fornire un'applicazione integra in termini di servizi di calcolo, archiviazione e piattaforma.

  • Effettuare progettazioni finalizzate alle operazioni: in un mondo in cui gli utenti si aspettano che i servizi siano "sempre attivi", è importante che questi ultimi vengano progettati tenendo in considerazione le operazioni. Questa sezione descrive procedure comprovate per la progettazione di operazioni che si estendono in tutto il ciclo di vita, inclusa la definizione di un modello di integrità per l'implementazione della telemetria al fine di visualizzare le relative informazioni per gli utenti di operazioni e sviluppatori.

In genere, le applicazioni sono costituite da più carichi di lavoro.

A carichi di lavoro diversi possono essere associati, e spesso lo sono, requisiti differenti, nonché livelli diversi di criticità per l'azienda e di considerazione finanziaria. Scomponendo un'applicazione in carichi di lavoro, un'organizzazione si assicura una flessibilità preziosa. Un approccio basato sul carico di lavoro è più efficace in termini di disponibilità e sicurezza e tramite esso vengono garantiti un controllo migliore dei costi, una maggiore flessibilità nella scelta delle tecnologie più appropriate per il carico di lavoro, flessibilità nell'aggiunta e nella distribuzione di nuove funzionalità e così via.

Talvolta, per illustrare la resilienza è utile sfruttare degli scenari tipici, ad esempio:

  • Servizio dati sportivi

    Un cliente offre un servizio dati tramite cui vengono fornite informazioni sportive. Al servizio sono associati due carichi di lavoro principali. Tramite il primo vengono fornite statistiche relative a giocatori e squadre, mentre tramite il secondo punteggi e commenti relativi alle partite attualmente in corso.

  • Sito Web di e-commerce

    Un rivenditore online vende merci tramite un sito Web con un modello affermato. All'applicazione è associata una serie di carichi di lavoro, di cui i più noti sono "ricerca ed esplorazione" e "completamento della transazione".

  • Social networking

    Tramite un sito di social networking di alto profilo viene consentito ai membri di una community di partecipare a esperienze condivise come forum, contenuti generati dagli utenti e giochi. All'applicazione è associata una serie di carichi di lavoro, inclusi registrazione, ricerca ed esplorazione, interazione tramite social networking, giochi, posta elettronica e così via.

  • Web

    Un'organizzazione desidera offrire un'esperienza ai clienti tramite il relativo sito Web. Tramite l'applicazione devono essere fornite esperienze sia nei browser basati su PC sia nei tipi di dispositivi mobili più famosi (telefoni, tablet). All'applicazione è associata una serie di carichi di lavoro, inclusi registrazione, ricerca ed esplorazione, pubblicazione di contenuti, commenti tramite social networking, moderazione, giochi e così via.

Di seguito vengono illustrati nei dettagli uno degli scenari e la relativa scomposizione nei rispettivi carichi di lavoro figlio. A un sito Web di e-commerce può essere associata una serie di carichi di lavoro, ad esempio esplorazione e ricerca, completamento della transazione e gestione, registrazione dell'utente, contenuti generati dagli utenti (verifiche e valutazioni), personalizzazione e così via.

Le definizioni di esempio di due dei carichi di lavoro di base per lo scenario sarebbero:

  • L'esplorazione e la ricerca consentono ai clienti di visualizzare un catalogo di prodotti, cercare elementi specifici ed eventualmente gestire acquisti o elenchi preferenze. A questo carico di lavoro possono essere associati attributi quali accesso di utenti anonimi, tempi di risposta in frazioni di secondo e memorizzazione nella cache. La riduzione delle prestazioni può essere causata da tempi di risposta maggiori con carico dell'utente imprevisto o interruzioni tollerate dall'applicazione per gli aggiornamenti dell'inventario dei prodotti. In questi casi, è possibile scegliere che tramite l'applicazione venga continuata la gestione di richieste di informazioni dalla cache.

  • Il completamento della transazione e la gestione consentono ai clienti di effettuare, registrare e annullare ordini, selezionare i metodi di recapito e le opzioni di pagamento, nonché gestire i profili. A questo carico di lavoro possono essere associati attributi quali accesso sicuro, elaborazione in coda, accesso a gateway di pagamento di terze parti e connettività a sistemi locali di back-end. Poiché possono essere tollerati tempi di risposta maggiori, ma non la perdita di ordini, l'applicazione viene progetta per garantire che gli ordini dei clienti siano sempre accettati e acquisiti, indipendentemente dalla possibilità di elaborazione del pagamento o di organizzazione del recapito tramite l'applicazione.

Tramite un modello di ciclo di vita dell'applicazione viene definito il comportamento previsto di un'applicazione operativa. In fasi e momenti diversi, tramite un'applicazione verranno effettuate richieste diverse al sistema sia a livello funzionale sia di scala. Questa condizione sarà riflessa nei modelli di ciclo di vita.

Per i carichi di lavoro è necessario definire modelli di ciclo di vita per tutti gli scenari pertinenti e applicabili ai livelli appropriati di granularità. I servizi possono presentare differenze di cicli di vita a livello orario, giornaliero, settimanale o stagionale che, se modellati, consentono di identificare nel tempo requisiti specifici di capacità, disponibilità, prestazioni e scalabilità.

Failsafe_03

Figura 1. Esempi di cicli di vita in diversi settori e scenari.

In periodi di tempo specifici il ciclo di vita è unico ed esclusivo, come nei seguenti casi:

  • Picco dovuto a un aumento di richieste durante un periodo festivo.

  • Aumento delle dichiarazioni dei redditi appena prima della scadenza.

  • Finestre temporali di pendolari mattutini e pomeridiani.

  • Archiviazione di fine anno delle verifiche delle prestazioni dei dipendenti.

Molte organizzazioni conoscono questi tipi di scenari e i relativi cicli di vita specifici.

La scomposizione consente di disporre di diversi contratti di servizio interni a livello di carico di lavoro. Un esempio è rappresentato dall'API di dati sportivi, il cui contratto di servizio punta a una disponibilità pari al 99,99%. Tale API può tuttavia essere divisa in due carichi di lavoro: "Punteggi in tempo reale + Commenti" e "Statistiche squadra, giocatore e lega".

Per il carico di lavoro "Punteggi in tempo reale + Commenti", il ciclo di vita è basato su un modello di tipo "attivazione e disattivazione". La disponibilità del carico di lavoro "Statistiche squadra, giocatore e lega" sarà tuttavia costante. La scomposizione in base ai carichi di lavoro consente di disporre di contratti di servizio personalizzati secondo i requisiti di disponibilità del carico di lavoro aggregato del servizio composito.

Failsafe_12

Figura 2

Una volta identificato un modello di ciclo di vita, il passaggio successivo consiste nello stabilire un modello e un piano di disponibilità. Tramite un modello di disponibilità per l'applicazione viene identificato il livello di disponibilità previsto per il carico di lavoro. Si tratta di un elemento molto importante in quanto, tramite esso, verranno presentate molte delle decisioni prese quando si stabilisce il servizio.

Esistono diversi elementi da prendere in considerazione e una serie di potenziali azioni che possono essere effettuate.

Quando si sviluppa il piano di disponibilità, è importante comprendere la disponibilità desiderata per l'applicazione, i carichi di lavoro in questa applicazione e i servizi utilizzati nel recapito di questi carichi di lavoro.

La comprensione del ciclo di vita di un carico di lavoro può essere di aiuto nella scelta del contratto di servizio che si desidera fornire. Un contratto di servizio può non essere fornito pubblicamente. L'architettura deve tuttavia mirare a un riferimento in termini di disponibilità a cui si desidera arrivare.

In base al tipo di soluzione creata, sono disponibili diverse opzioni per fornire una disponibilità maggiore. I provider di servizi commerciali non offrono contratti di servizio con disponibilità del 100% perché la fornitura di un contratto di servizio di tale livello comporta una complessità e costi tali da rendere questa soluzione impraticabile o poco remunerativa. La scomposizione dell'applicazione a livello di carico di lavoro consente di disporre di più opzioni e di adottare specifici approcci in termini di disponibilità. Un tempo di attività pari al 99,99% per l'intera applicazione è senz'altro impraticabile, ma è realizzabile per un carico di lavoro in un'applicazione.

Anche a livello di carico di lavoro, non è possibile scegliere di implementare tutte le opzioni. La scelta relativa agli elementi da implementare dipende dalle esigenze dell'utente. Indipendentemente dalle opzioni selezionate, la scelta deve essere effettuata tenendo in considerazione le informazioni acquisite e tutte le opzioni disponibili.

L'autonomia riguarda l'indipendenza e la riduzione della dipendenza tra le parti che costituiscono il servizio nel complesso. La dipendenza da componenti, dati ed entità esterne deve essere valutata durante la progettazione dei servizi, tenendo in considerazione la compilazione di funzionalità correlate in unità autonome all'interno del servizio. Grazie a questa operazione vengono forniti la flessibilità di aggiornamento delle versioni di unità autonome distinte, un controllo più appropriato sulla scalabilità di queste unità autonome e così via.

Le architetture del carico di lavoro sono spesso costituite da componenti autonomi che non si basano sull'intervento manuale e non hanno esito negativo quando le entità da cui dipendono non sono disponibili. Le applicazioni costituite da parti autonome sono:

  • Disponibili e operative

  • Resilienti e facilmente recuperabili in caso di errore

  • A basso rischio di stati di errore non integri

  • Facili da scalare tramite la replica

  • Caratterizzate da minor probabilità di richiesta di interventi manuali

In queste unità autonome verranno spesso utilizzate la comunicazione asincrona, l'elaborazione dei dati basata su pull e l'automazione per garantire un servizio continuo.

Guardando al futuro, si assisterà a un'evoluzione del mercato fino al punto da poter disporre di interfacce standardizzate per alcuni tipi di funzionalità sia per gli scenari verticali sia per quelli orizzontali. Una volta realizzata questa visione futura, un provider di servizi sarà in grado di impegnarsi con altri provider e fornire implementazioni potenzialmente differenti tramite cui viene valutato il lavoro progettato dell'unità autonoma. Per i servizi continui, questa operazione verrà effettuata in modo autonomo e sarà basata su criteri.

Poiché l'autonomia è un'ambizione, la maggior parte dei servizi dipenderà da un servizio di terze parti, fosse anche solo per l'hosting. È fondamentale comprendere i contratti di questi servizi dipendenti e includerli nel piano di disponibilità.

In questa sezione vengono identificati i diversi tipi di contratti di servizio che possono essere importanti per il servizio. Per ognuno di questi tipi di servizio, sono disponibili considerazioni e approcci principali, nonché domande da porre.

Servizi di piattaforme cloud pubbliche

Ai servizi forniti da una piattaforma di calcolo cloud commerciale, ad esempio per calcoli o archiviazioni, sono associati contratti di servizio progettati per supportare un gran numero di clienti in base a una scala significativa. Di conseguenza, i contratti per questi servizi non sono negoziabili. Un provider può fornire più livelli di servizio con contratti diversi, tuttavia questi livelli non saranno negoziabili. Il provider di servizi usa più livelli di servizio con contratti diversi per fornire una qualità dei servizi prevedibile.

Domande da considerare per questo tipo di servizio:

  • Tramite questo servizio viene consentito solo un determinato numero di chiamate all'API del servizio?

  • Tramite il servizio viene posto un limite alla frequenza di chiamate all'API del servizio?

  • Tramite il servizio viene limitato il numero di server attraverso i quali è possibile effettuare chiamate all'API del servizio?

  • Quali sono le informazioni disponibili pubblicamente sulla qualità del servizio rispetto alla disponibilità promessa?

  • In che modo, tramite il servizio, viene comunicato il relativo stato di integrità?

  • Qual è il contratto di servizio dichiarato?

  • Quali sono i servizi di piattaforme equivalenti forniti da terze parti?

Servizi "gratuiti" di terze parti

Molte terze parti offrono servizi "gratuiti" alla community. Per le organizzazioni del settore privato, questi servizi vengono offerti soprattutto come supporto per la creazione di un ecosistema di applicazioni intorno al prodotto o servizio di base, nel caso del settore pubblico, invece, per la fornitura di dati ai cittadini e alle aziende che hanno apparentemente pagato per la relativa raccolta mediante i fondi del governo attraverso imposte.

La maggior parte di questi servizi non viene fornita con i relativi contratti, pertanto la disponibilità non è garantita. I contratti di servizio forniti sono generalmente incentrati sulle restrizioni imposte sull'utilizzo di applicazioni e sui meccanismi che verranno utilizzati per applicarle. Tra le restrizioni è incluso, ad esempio, l'inserimento nell'elenco dei contatti bloccati o la limitazione della soluzione se vengono superati determinati numeri di chiamate al servizio, di chiamate in un periodo di tempo specifico (x al minuto) o il numero di server consentiti per la chiamata al servizio.

Domande da considerare per questo tipo di servizio:

  • Tramite questo servizio viene consentito solo un determinato numero di chiamate all'API del servizio?

  • Tramite il servizio viene posto un limite alla frequenza di chiamate all'API del servizio?

  • Tramite il servizio viene limitato il numero di server attraverso i quali è possibile effettuare chiamate all'API del servizio?

  • Quali sono le informazioni disponibili pubblicamente sulla qualità del servizio rispetto alla disponibilità promessa?

  • In che modo, tramite il servizio, viene comunicato il relativo stato di integrità?

  • Qual è il contratto di servizio dichiarato?

  • Si tratta di un servizio apposito in cui le funzionalità e/o i dati richiesti vengono forniti da più provider di servizi?

  • In caso di servizio apposito, l'interfaccia è interoperativa in altri provider di servizi (direttamente o tramite un livello di astrazione disponibile)?

  • Quali sono i servizi di piattaforme equivalenti forniti da terze parti?

Servizi commerciali di terze parti

Ai servizi commerciali forniti da terze parti sono associati contratti di servizio progettati per soddisfare le esigenze di pagamento dei clienti. Un provider può fornire più livelli di contratti di servizio con diversi livelli di disponibilità, tuttavia questi contratti non saranno negoziabili.

Domande da considerare per questo tipo di servizio:

  • Tramite questo servizio viene consentito solo un determinato numero di chiamate all'API del servizio?

  • Tramite il servizio viene posto un limite alla frequenza di chiamate all'API del servizio?

  • Tramite il servizio viene limitato il numero di server attraverso i quali è possibile effettuare chiamate all'API del servizio?

  • Quali sono le informazioni disponibili pubblicamente sulla qualità del servizio rispetto alla disponibilità promessa?

  • In che modo, tramite il servizio, viene comunicato il relativo stato di integrità?

  • Qual è il contratto di servizio dichiarato?

  • Si tratta di un servizio apposito in cui le funzionalità e/o i dati richiesti vengono forniti da più provider di servizi?

  • In caso di servizio apposito, l'interfaccia è interoperativa in altri provider di servizi (direttamente o tramite un livello di astrazione disponibile)?

  • Quali sono i servizi di piattaforme equivalenti forniti da terze parti?

Servizi cloud della community

Tramite una community di organizzazioni, ad esempio una catena di fornitura, è possibile rendere disponibili i servizi alle organizzazioni dei membri.

Domande da considerare per questo tipo di servizio:

  • Tramite questo servizio viene consentito solo un determinato numero di chiamate all'API del servizio?

  • Tramite il servizio viene posto un limite alla frequenza di chiamate all'API del servizio?

  • Tramite il servizio viene limitato il numero di server attraverso i quali è possibile effettuare chiamate all'API del servizio?

  • Quali sono le informazioni disponibili pubblicamente sulla qualità del servizio rispetto alla disponibilità promessa?

  • In che modo, tramite il servizio, viene comunicato il relativo stato di integrità?

  • Qual è il contratto di servizio dichiarato?

  • Come membro della community, è possibile negoziare un contratto di servizio diverso?

  • Si tratta di un servizio apposito in cui le funzionalità e/o i dati richiesti vengono forniti da più provider di servizi?

  • In caso di servizio apposito, l'interfaccia è interoperativa in altri provider di servizi (direttamente o tramite un livello di astrazione disponibile)?

  • Quali sono i servizi di piattaforme equivalenti forniti da terze parti?

Servizi cloud interni a livello aziendale sviluppati dal produttore

Un'azienda può rendere disponibili ai propri reparti i servizi di base, ad esempio i dati sulle quotazioni dei titoli o i metadati sui prodotti.

Domande da considerare per questo tipo di servizio:

  • Tramite questo servizio viene consentito solo un determinato numero di chiamate all'API del servizio?

  • Tramite il servizio viene posto un limite alla frequenza di chiamate all'API del servizio?

  • Tramite il servizio viene limitato il numero di server attraverso i quali è possibile effettuare chiamate all'API del servizio?

  • Quali sono le informazioni disponibili pubblicamente sulla qualità del servizio rispetto alla disponibilità promessa?

  • In che modo, tramite il servizio, viene comunicato il relativo stato di integrità?

  • Qual è il contratto di servizio dichiarato?

  • Come membro dell'organizzazione, è possibile negoziare un contratto di servizio diverso?

  • Si tratta di un servizio apposito in cui le funzionalità e/o i dati richiesti vengono forniti da più provider di servizi?

  • In caso di servizio apposito, l'interfaccia è interoperativa in altri provider di servizi (direttamente o tramite un livello di astrazione disponibile)?

  • Quali sono i servizi di piattaforme equivalenti forniti da terze parti?

Servizi cloud interni dei reparti sviluppati dal produttore

Un reparto di un'azienda può rendere disponibili i servizi ad altri membri dell'organizzazione principale.

Domande da considerare per questo tipo di servizio:

  • Tramite questo servizio viene consentito solo un determinato numero di chiamate all'API del servizio?

  • Tramite il servizio viene posto un limite alla frequenza di chiamate all'API del servizio?

  • Tramite il servizio viene limitato il numero di server attraverso i quali è possibile effettuare chiamate all'API del servizio?

  • Quali sono le informazioni disponibili pubblicamente sulla qualità del servizio rispetto alla disponibilità promessa?

  • In che modo, tramite il servizio, viene comunicato il relativo stato di integrità?

  • Qual è il contratto di servizio dichiarato?

  • Come membro del reparto, è possibile negoziare un contratto di servizio diverso?

  • Si tratta di un servizio apposito in cui le funzionalità e/o i dati richiesti vengono forniti da più provider di servizi?

  • In caso di servizio apposito, l'interfaccia è interoperativa in altri provider di servizi (direttamente o tramite un livello di astrazione disponibile)?

  • Quali sono i servizi di piattaforme equivalenti forniti da terze parti?

I "9 reali" della disponibilità di servizi compositi

Sfruttando i vantaggi dei servizi esistenti è possibile ottenere un'importante flessibilità nello sviluppo di soluzioni per l'organizzazione o per la vendita commerciale. Sebbene interessanti, è importante comprendere fino in fondo l'impatto che queste dipendenze possono avere sul contratto di servizio globale per il carico di lavoro.

La disponibilità viene generalmente espressa sotto forma di percentuale di tempo di attività in un determinato anno. La percentuale che esprime la disponibilità viene definita attraverso il "numero di nove". Ad esempio, 99,9 rappresenta un servizio con "tre nove", mentre 99,999 rappresenta un servizio con "cinque nove".

 

Percentuale di disponibilità

Inattività per anno

Inattività per mese

Inattività per settimana

90% ("un nove")

36,5 giorni

72 ore

16,8 ore

95%

18,25 giorni

36 ore

8,4 ore

97%

10,96 giorni

21,6 ore

5,04 ore

98%

7,30 giorni

14,4 ore

3,36 ore

99% ("due nove")

3,65 giorni

7,20 ore

1,68 ore

99.5%

1,83 giorni

3,60 ore

50.4 minuti

99.8%

17,52 ore

86,23 minuti

20,16 minuti

99,9% ("tre nove")

8,76 ore

43,2 minuti

10,1 minuti

99.95%

4,38 ore

21,56 minuti

5,04 minuti

99,99% ("quattro nove")

52,56 minuti

4,32 minuti

1,01 minuti

99,999% ("cinque nove")

5,26 minuti

25,9 secondi

6,05 secondi

99,9999% ("sei nove")

31,5 secondi

2,59 secondi

0,605 secondi

99,99999% ("sette nove")

3,15 secondi

0,259 secondi

0,0605 secondi

Al numero di "9" relativi a un servizio composito è associato un preconcetto comune. Spesso si presuppone infatti che se un dato servizio è composto da 5 servizi, ognuno con un tempo di attività dichiarato nel relativo contratto di servizio del 99,99%, la disponibilità del servizio composito risultante sarà del 99,99%. Non è così.

Failsafe_13

Figura 3: Inattività correlata ai numeri "9" più comuni

Il contratto di servizio composito in realtà è frutto di un calcolo in cui viene considerata la quantità di tempo di inattività su base annua. Un servizio con un relativo contratto di "quattro 9" (99,99%) può essere offline per un massimo di 52,56 minuti.

L'unione di 5 servizi con un contratto per una disponibilità del 99,99% in un servizio composito comporta l'inclusione nei contratti di servizio di un rischio effettivo di 262,8 minuti o 4,38 ore. Ancor prima della scrittura di una singola riga di codice, la disponibilità risulta pertanto ridotta al 99,95%.

In genere, non è possibile modificare la disponibilità di un servizio di terze parti, ma durante la scrittura di codice è possibile aumentare la disponibilità complessiva dell'applicazione in base a determinate tecniche, come quelle illustrate in questo documento.

noteNota
Alcuni servizi possono fornire livelli di servizio diversi in base alle fasce di prezzo o a partecipazioni interaziendali.

Si consideri l'API di dati sportivi sopra illustrata. Le partite giocate dagli utenti si svolgono soltanto in determinati giorni e solo per un dato numero di ore. Durante questi intervalli di tempo la disponibilità del contratto di servizio è pari al 100%. Quando non vi sono partite in programma, a questo carico di lavoro è associato un contratto di servizio con disponibilità dello 0%. Il modello di ciclo di vita del carico di lavoro "Statistiche squadra, giocatore e lega" è invece più regolare. Questo carico di lavoro richiede inoltre un contratto di servizio con disponibilità costante del 99%.

Failsafe_14

Figura 4

Quando si usano servizi esterni, non è possibile evidenziare con sufficiente enfasi l'importanza di comprendere i contratti di servizio, sia singolarmente sia in termini di impatto sul servizio composito.

Per creare un'architettura resiliente, è importante capirla, in particolare compiendo uno sforzo attivo per comprendere e documentare le possibili cause di un'interruzione.

Se si capiscono i punti e le modalità di errore di un'applicazione e i relativi servizi di carico di lavoro è possibile prendere decisioni oculate e mirate sulle strategie per la resilienza e la disponibilità.

I punti di errore rappresentano posizioni in cui possono verificarsi errori durante un'interruzione del servizio. Occorre prestare particolarmente attenzione agli elementi di progettazione soggetti a modifiche esterne.

Alcuni esempi di punti di errore sono rappresentati da:

  • Connessioni di database

  • Connessioni di siti Web

  • File di configurazione

  • Chiavi del Registro di sistema

Alcuni esempi di categorie di punti di errore comuni sono rappresentati da:

  • ACL

  • Accesso a database

  • Accesso a servizi/siti Web esterni

  • Transazioni

  • Configurazione

  • Capacità

  • Rete

Mentre tramite i punti di errore vengono definite le aree che possono essere interessate da un'interruzione, attraverso le modalità di errore viene individuato il modo specifico in cui può verificarsi un errore.

Esempi di modalità di errore sono rappresentati da:

  • File di configurazione mancante

  • Traffico notevole che supera la capacità delle risorse

  • Database che raggiunge la capacità massima

Le conseguenze degli errori rappresentano le ripercussioni degli errori sulla funzionalità. La comprensione delle conseguenze causate dagli errori e della frequenza con cui tali errori si verificano consente di classificare in ordine di priorità il momento e il modo in cui gestire i punti e le modalità di errore dell'applicazione o del servizio.

In questo documento sono illustrate considerazioni fondamentali sui servizi di calcolo, archiviazione e della piattaforma. Prima di analizzare questi argomenti, è importante riepilogare diversi argomenti di base che influenzano la resilienza che spesso vengono capiti male e/o non implementati.

Come indicato in precedenza, un'architettura resiliente deve garantire un livello ottimale di autonomia. Una delle modalità per ottenere l'autonomia consiste nel rendere asincrona la comunicazione. In un'architettura resiliente l'interazione asincrona deve avvenire per impostazione predefinita, mentre le interazioni sincrone devono verificarsi solo in caso di eccezioni.

Ciò può essere fornito dai livelli Web senza stato o con cache distribuita nel front-end di una soluzione, mentre le code possono rendere disponibile tale funzionalità per la comunicazione ai fini dell'interazione tra i servizi relativi al carico di lavoro o i servizi all'interno di un servizio relativo al carico di lavoro.

Tramite quest'ultimo è possibile inserire i messaggi nelle code che possono essere recuperati, in un secondo momento, dai servizi secondari. Questa operazione può essere effettuata in base alla logica, al tempo o al volume. Oltre a rendere il processo asincrono, consente inoltre la scala di livelli di cui viene effettuato, a seconda dei casi, il "push" o il "pull".

Generalmente gli errori temporanei si verificano nel punto in cui viene eseguita la connessione dell'architettura a un servizio o una risorsa, ad esempio un database. Quando si utilizzano questi servizi, è pratica comune implementare la logica tramite cui viene introdotto il concetto di timeout. Tramite questa logica viene identificato un intervallo di tempo accettabile in cui è prevista una risposta e verrà generato un errore identificabile in caso di superamento di questo intervallo. A seconda del tipo di errore di timeout, verranno adottate le misure necessarie in base al contesto in cui si verifica. Nel contesto possono essere inclusi il numero di volte in cui si è verificato questo errore, il potenziale impatto della risorsa non disponibile, le garanzie del servizio di contratto per il periodo di tempo corrente per il cliente specificato e così via.

Quando si progettano i servizi tramite cui verrà fornito il carico di lavoro, è necessario accettare che si verificheranno errori e che è necessario adottare le misure appropriate per risolverli.

Gli errori temporanei rappresentano uno degli scenari comuni da risolvere. Poiché nessun servizio garantisce il 100% di attività, è realistico aspettarsi di non potersi connettere a un servizio da cui dipende un carico di lavoro. L'impossibilità di connettersi o la presenza di errori in uno di questi servizi può essere transitoria (inferiore a un secondo) o permanente (chiusura di un provider).

Gestire gli errori in modo appropriato

Per il servizio di carico di lavoro si deve ambire a gestire questi errori temporanei in modo appropriato. In Netflix, ad esempio, durante un'interruzione a livello del provider di cloud è stata utilizzata una coda video precedente per i clienti quando l'archivio dati primario non era disponibile. Un altro esempio potrebbe essere un sito di e-commerce in cui la raccolta degli ordini viene continuata anche se il gateway di pagamento non è disponibile. In questo modo sarà possibile elaborare gli ordini quando il gateway di pagamento sarà di nuovo disponibile o dopo aver eseguito il failover su un gateway di pagamento secondario.

Considerazioni di alto livello sulla riduzione del funzionamento

Per comprendere come ridurre gradualmente il funzionamento, occorre tenere presenti le seguenti considerazioni fondamentali:

  • I componenti che non dispongono del contesto completo della richiesta dovrebbero semplicemente generare un errore e trasmettere il messaggio di eccezione. Per risolvere questo problema, si può implementare un interruttore, come descritto più avanti in questo documento, per generare un errore immediato quando si raggiungono determinate soglie di conteggio degli errori.

  • Gli errori di natura temporanea sono comuni. È possibile gestirli mediante il modello della logica di tentativi, descritto più avanti in questo documento.

  • Il chiamante può tentare di ripetere l'operazione di richiesta usando parametri diversi o un percorso differente in modo da correggere alcune richieste non riuscite.

  • Se il completamento della richiesta non costituisce una condizione fondamentale per questo scenario, l'errore può essere gestito mediante una semplice omissione.

  • Per gestire gli errori si può restituire un messaggio di operazione completata e inserire nella coda le richieste non riuscite in modo che vengano elaborate in seguito, quando lo stato della risorsa ritorna normale.

  • Possono essere restituiti elementi in precedenza corretti, ad esempio credenziali memorizzate nella cache, dati non aggiornati della cache e così via.

  • Alcuni errori possono essere gestiti fornendo informazioni quasi corrette, ad esempio un accesso temporaneo, valori approssimati o più probabili, NoScript e così via.

  • Anziché generare un errore, si può tentare di fornire elementi alternativi, ad esempio valori casuali, diritti anonimi, immagini predefinite e così via.

Considerazioni sulla gestione degli errori temporanei

È possibile fare diverse considerazioni essenziali per l'implementazione della gestione degli errori temporanei, come descritto dettagliatamente nelle sezioni seguenti.

  • Logica di tentativi

    Il modo più semplice per gestire un errore temporaneo consiste nel ritentare l'operazione che non è riuscita. Se si utilizza un servizio commerciale di terze parti, tramite l'implementazione della "logica di tentativi" sarà spesso possibile risolvere il problema.

    Si noti che è consigliabile che nelle progettazioni venga limitato il numero di volte in cui la logica verrà ritentata. In genere, tramite la logica verrà effettuato un certo numero di tentativi di esecuzione delle azioni e, nel caso in cui l'errore non venga risolto, questo verrà registrato o si utilizzerà un servizio o un flusso di lavoro secondario.

  • Backoff esponenziale

    Se il risultato dell'errore temporaneo è dovuto alla limitazione del servizio causata dal carico elevato, i tentativi ripetuti di chiamare il servizio comporteranno solo l'estensione della limitazione e un impatto sulla disponibilità complessiva.

    Spesso è consigliabile ridurre il volume delle chiamate al servizio per evitare o diminuire la limitazione. Questa operazione viene in genere eseguita a livello algoritmico, ad esempio effettuando un tentativo subito dopo il primo errore, aspettando 1 secondo dopo il secondo errore, 5 secondi dopo il terzo errore e così via, fino a quando non viene infine raggiunta la soglia degli errori stabilita da un'applicazione.

    Questo approccio viene definito "backoff esponenziale".

  • Idempotenza

    Secondo un presupposto di base relativo ai servizi connessi, la disponibilità totale di questi ultimi non verrà garantita e la gestione degli errori temporanei con la logica di tentativi rappresenta un approccio di implementazione fondamentale. Nei casi in cui viene implementata la logica di tentativi, esiste il rischio che lo stesso messaggio venga inviato più volte, se si tratta di messaggi da inviare fuori sequenza e così via.

    Le operazioni devono essere progettate per essere idempotenti, garantendo che l'invio dello stesso messaggio più volte non comporti un archivio dati imprevisto o inquinato.

    Ad esempio, l'inserimento dei dati di tutte le richieste può determinare l'aggiunta di più record se l'operazione del servizio viene chiamata più volte. Un approccio alternativo consiste nell'implementare il codice come operazione di aggiornamento/inserimento ("upsert") intelligente. Per identificare i nuovi messaggi elaborati da quelli precedenti è possibile utilizzare un timestamp o un identificatore globale, inserendo nel database solo i messaggi più recenti e aggiornando i record esistenti qualora il messaggio sia più recente rispetto a quello ricevuto in precedenza.

  • Comportamento di compensazione

    Oltre all'idempotenza, un altro aspetto da prendere in considerazione riguarda il concetto di comportamento di compensazione. In un mondo caratterizzato da set di sistemi connessi in continuo aumento e dall'emergenza di servizi compositi, l'importanza di comprendere come gestire il comportamento di compensazione è essenziale.

    Per molti sviluppatori di applicazioni line-of-business, i concetti di transazioni non sono nuovi, ma la cornice di riferimento è spesso legata alla funzionalità transazionale esposta dalle tecnologie di dati locali e dalle librerie di codice correlate. Esaminando il concetto in termini di cloud, per un approccio di questo tipo è opportuno tener conto delle nuove considerazioni correlate all'orchestrazione di servizi distribuiti.

    Un'orchestrazione di servizi può estendersi a più sistemi distribuiti ed essere a esecuzione prolungata e con stato. La stessa orchestrazione è raramente sincrona, può estendersi a più sistemi e da secondi ad anni in base allo scenario aziendale.

    In uno scenario di catena di fornitura che potrebbe unire 25 organizzazioni nella stessa attività di carico di lavoro, ci potrebbe essere, ad esempio, un set di 25 o più sistemi collegati tra loro in una o più orchestrazioni di servizi.

    In tal caso, il completamento dell'attività deve essere noto ai 25 sistemi. Per ogni punto di connessione nell'attività, tramite i sistemi dei partecipanti è possibile fornire un ID di correlazione per i messaggi ricevuti dagli altri sistemi. A seconda del tipo di attività, tramite la ricezione dell'ID di correlazione in questione può essere indicato alla parte il completamento della transazione a livello teorico. In altri casi, al termine delle interazioni di tutte le 25 parti, può essere inviato un messaggio di conferma a tutte le parti, direttamente da un singolo servizio o tramite i punti specifici di interazione dell'orchestrazione per ogni sistema.

    Per gestire gli errori di attività composite e/o distribuite, tramite ogni servizio vengono esposte operazioni e un'interfaccia di servizio per ricevere le richieste di annullamento di una transazione specificata da un identificatore univoco. Dietro ai servizi sono presenti flussi di lavoro per compensare l'annullamento di questa attività. Queste procedure sarebbero idealmente automatiche, ma possono essere semplici quanto il routing a un utente nell'organizzazione per una soluzione manuale.

Un interruttore è un dispositivo mediante il quale viene interrotto automaticamente il flusso di corrente elettrica qualora venga superato il limite prestabilito. Gli interruttori vengono in genere utilizzati come misura di sicurezza laddove può sussistere il rischio di corrente eccessiva attraverso un circuito. A differenza di un fusibile, un interruttore può essere reimpostato e riutilizzato.

Lo stesso modello è applicabile alla progettazione software e, in particolare, ai servizi in cui la disponibilità e la resilienza sono fattori chiave.

In caso di mancata disponibilità di una risorsa, l'implementazione di un interruttore a livello software può rispondere con l'azione appropriata.

Un interruttore presenta tre stati: chiuso, aperto e semiaperto.

Lo stato chiuso rappresenta lo stato normale per un'applicazione o per un servizio. Quando lo stato dell'interruttore è chiuso, le richieste vengono indirizzate attraverso il percorso standard. Un contatore tiene traccia della percentuale degli errori e verifica che questa non superi una determinata soglia. Se la percentuale di errori supera tale soglia, lo stato dell'interruttore passa ad aperto. Se una chiamata a una risorsa del database non riesce dopo 100 tentativi consecutivi di connessione, probabilmente sarà inutile continuare a effettuare chiamate al database. È possibile attivare un interruttore a un determinato valore di soglia e intraprendere le azioni appropriate.

Quando lo stato dell'interruttore è aperto, le richieste vengono indirizzate verso uno o più percorsi di attenuazione. Questo può comportare un esito negativo rapido o un'altra forma di riduzione del funzionamento. Quando lo stato dell'interruttore passa ad aperto, viene avviato anche un timer. Allo scadere del timer, lo stato passa a semiaperto.

Lo stato semiaperto inizia a indirizzare un numero limitato di richieste attraverso il percorso ordinario. Se le richieste hanno esito positivo, lo stato dell'interruttore passerà a chiuso. Se invece hanno esito negativo, lo stato dell'interruttore passerà nuovamente ad aperto.

Quando si include il modello di interruttore nell'architettura, prestare attenzione alle seguenti considerazioni:

  • In base al tipo di eccezione generata dall'operazione, un interruttore può richiamare diverse migrazioni o momenti diversi quando si trova nello stato aperto.

  • È necessario che un interruttore registri tutti gli stati di transizione. In questo modo gli operatori possono monitorare i passaggi di stato dell'interruttore e ottimizzare i timer in modo da evitare che l'interruttore rimanga per troppo tempo nello stato aperto o per impedire continue oscillazioni tra lo stato aperto e quello semiaperto.

  • Anziché usare un timer per passare dallo stato aperto a quello semiaperto, l'interruttore può testare il percorso standard a intervalli regolari per determinare se è tornato a essere il percorso ordinario.

  • Prestare attenzione all'impiego di un interruttore quando si è in presenza di un'operazione che comporta l'uso di più partizioni. In questo caso il pericolo per l'integrità può manifestarsi a livello della partizione e può portare a due scenari indesiderati:

    • Passaggio allo stato aperto quando l'errore si verifica in una sola partizione.

    • Passaggio accidentale allo stato chiuso quando una o più partizioni non presentano errori.

Un'implementazione comune di questo modello è correlata all'accesso a database o a servizi dati. In caso di errore del tipo e del livello stabiliti di attività, l'interruttore si aziona. Con i dati, questo problema viene in genere causato dall'impossibilità di connessione a un database o a un relativo servizio dati.

Se una chiamata a una risorsa del database non riesce dopo 100 tentativi consecutivi di connessione, probabilmente sarà inutile continuare a effettuare chiamate al database. È possibile attivare un interruttore a un determinato valore di soglia e intraprendere le azioni appropriate.

In alcuni casi, in particolare durante la connessione ai servizi dati, questa situazione potrebbe essere dovuta alla limitazione basata sul superamento del numero di chiamate consentite entro un periodo di tempo specificato da parte di un client. Tramite l'interruttore è possibile inserire ritardi tra le chiamate, fino a quando non vengono stabilite le connessioni, e soddisfare i livelli di tolleranza.

In altri casi, è possibile che l'archivio dati non sia disponibile. Se è presente una copia ridondante dei dati, si potrebbe eseguire il failover del sistema sulla replica in questione. Se una replica effettiva non è disponibile o se il servizio di database non è attivo in alcun data center di un provider, è possibile adottare un approccio secondario, ad esempio generare dati da una versione dei dati richiesti tramite un provider di servizi dati alternativo. Questa origine alternativa può essere rappresentata da una cache, un tipo di archivio dati persistente alternativo nel provider di cloud corrente, un provider di cloud separato oppure un data center locale. Se un'alternativa di questo tipo non è disponibile, potrebbe essere restituito anche un errore riconoscibile dal servizio che può essere gestito correttamente dal client.

Esempio di modello di interruttore: Netflix

Netflix, società che offre servizi di flussi multimediali, viene spesso presa in considerazione come un ottimo esempio di architettura resiliente. Quando viene illustrato il modello di interruttore presso Netflix, il team pone l'attenzione su diversi relativi criteri presentati nel blog sulla tecnologia Netflix. Tra questi sono inclusi:

  1. Timeout di una richiesta al servizio remoto.

  2. Capacità del 100% del pool dei thread e della coda di attività associata utilizzati per l'interazione con una dipendenza del servizio.

  3. Eccezione generata dalla libreria client utilizzata per l'interazione con una dipendenza del servizio.

Tutti questi elementi contribuiscono alla frequenza complessiva degli errori. Se i relativi valori di soglia definiti vengono superati, l'interruttore viene azionato e tramite il circuito del servizio in questione vengono utilizzati immediatamente dei fallback senza tentare la connessione al servizio remoto.

Nello stesso intervento nel blog, il team di Netflix afferma che tramite l'interruttore di ognuno dei servizi viene implementato un fallback utilizzando uno dei tre approcci seguenti:

  1. Fallback personalizzato: tramite una libreria client del servizio viene fornito un metodo di fallback richiamabile o vengono utilizzati i dati disponibili in locale in un server API, ad esempio un cookie o una cache locale, per generare una risposta di fallback.

  2. Esito negativo senza generazione di avviso: tramite un metodo viene restituito un valore Null al client di richiesta, che funziona correttamente se i dati necessari sono facoltativi.

  3. Esito negativo rapido: se i dati sono obbligatori o non è disponibile alcun fallback ottimale, viene restituita una risposta 5xx al client. Questo approccio pone l'attenzione sul mantenere integri i server API e sull'abilitare un recupero rapido quando i servizi interessati tornano online, ma con conseguenze negative per il client UX.

Per applicare un contratto di servizio, un'organizzazione deve tener conto della modalità con cui le due categorie di outlier, cioè le parti attendibili e i cattivi attori, verranno considerate dal servizio dati.

Parti attendibili ed elenco approvato

Le parti attendibili sono le società con cui l'organizzazione può stipulare accordi speciali e per cui è possibile apportare determinate eccezioni ai contratti di servizio standard.

  • Terze parti con contratti personalizzati

    È possibile che alcuni utenti di un servizio desiderino negoziare termini o criteri speciali relativi ai prezzi. In alcuni casi, un volume elevato di chiamate al servizio dati potrebbe richiedere prezzi speciali. In altri casi, la domanda per un determinato servizio dati potrebbe superare il volume specificato nei livelli standard di utilizzo. È consigliabile definire clienti di questo tipo come parti attendibili per evitare di contrassegnarli inavvertitamente come cattivi attori.

  • Elenco approvato

    L'approccio generale per gestire le parti attendibili consiste nel definire un elenco approvato. Questo strumento, tramite cui viene identificato un elenco di parti attendibili, viene utilizzato dal servizio per stabilire le regole di business da applicare durante l'elaborazione dell'utilizzo del cliente. L'elenco approvato viene in genere creato autorizzando un intervallo di indirizzi IP o una chiave API.

    Quando si stabiliscono i criteri di utilizzo, un'organizzazione deve verificare se l'elenco approvato è supportato, quali caratteristiche deve avere un cliente per esservi inserito, la relativa modalità di aggiunta e in base a quali circostanze un cliente viene rimosso dall'elenco approvato in questione.

  • Gestione dei cattivi attori

    Se le parti attendibili si trovano a un'estremità dello spettro dei clienti, il gruppo all'estremo opposto è rappresentato da quelli che vengono definiti "cattivi attori". Questi ultimi inseriscono un carico nel servizio, in genere derivante da un tentativo di "uso eccessivo". In alcuni casi il cattivo comportamento è realmente accidentale, in altri intenzionale e, in alcune situazioni, è invece dannoso. Questi attori vengono definiti "cattivi", in quanto le loro azioni, intenzionali o di altro tipo, possono influire sulla disponibilità di uno o più servizi.

    Il carico inserito dai cattivi attori può comportare costi non necessari al provider del servizio dati e compromettere l'accesso a utenti che rispettano fedelmente le condizioni di utilizzo e che si aspettano risultati ragionevoli, come dichiarato in un contratto di servizio. I cattivi attori devono pertanto essere gestiti secondo una modalità stabilita e coerente. Le risposte tipiche ai cattivi attori consistono nella limitazione e nella creazione di un elenco di contatti bloccati.

  • Limitazione

    È consigliabile che le organizzazioni definiscano una strategia per la gestione dei picchi di utilizzo da parte degli utenti del servizio dati. Aumenti significativi di traffico da parte degli utenti possono comportare un carico imprevisto nel servizio dati. Quando si verificano picchi di questo tipo, è necessario che l'organizzazione limiti l'accesso dell'utente in questione per un determinato periodo di tempo. In questo caso, tutte le richieste dell'utente vengono rifiutate dal servizio per un determinato periodo di tempo, ad esempio per uno, cinque o dieci minuti. Durante questo periodo, viene generato dalle richieste di servizio dell'utente di destinazione un messaggio di errore che ne indica la limitazione per sovrautilizzo.

    L'utente che effettua le richieste può rispondere di conseguenza, ad esempio modificando il relativo comportamento.

    È consigliabile che l'organizzazione stabilisca se desidera implementare la limitazione e impostare le relative regole di business. Se si determina che è possibile limitare gli utenti, l'organizzazione dovrà anche stabilire i comportamenti in base ai quali deve essere attivata la risposta di limitazione.

  • Contatti bloccati

    Anche se il comportamento di cattivi attori dovrebbe essere corretto dalla limitazione, è probabile che questa soluzione non sempre produca il risultato desiderato. Nei casi in cui questa strategia non funziona, è possibile che l'organizzazione escluda un utente. A differenza di un elenco approvato, tramite un elenco di contatti bloccati vengono identificati gli utenti che sono esclusi dall'accesso al servizio. Alle richieste di accesso provenienti da clienti iscritti nell'elenco dei contatti bloccati verranno fornite risposte appropriate da parte del servizio e in modo da ridurre al minimo l'utilizzo delle risorse del servizio dati.

    Analogamente all'elenco approvato, l'elenco dei contatti bloccati viene in genere creato usando una chiave API o con un intervallo di indirizzi IP.

    Quando si stabiliscono i criteri di utilizzo, è consigliabile che l'organizzazione specifichi i comportamenti in base ai quali un utente verrà inserito nell'elenco dei contatti bloccati, nonché le modalità con cui è possibile ricorrervi e con cui un utente ne può essere rimosso.

Tutti gli utenti possono commettere errori. Ad esempio, una modifica al codice apportata da uno sviluppatore può determinare conseguenze impreviste, un amministratore di database può eliminare accidentalmente una tabella di un database oppure un responsabile delle operazioni apporta una modifica senza però tenerne traccia. Sono tante le circostanze per cui un utente può rendere inavvertitamente un servizio meno resiliente.

Per ridurre l'errore umano, un approccio logico consiste nel diminuire il numero di utenti nel processo. Grazie all'introduzione dell'automazione, viene limitata la possibilità di variabili ad hoc e involontarie diverse dai comportamenti previsti a causa delle quali il servizio viene compromesso.

In un meme disponibile nella community di DevOps con un personaggio di cartoni animati si afferma che tutte le operazioni possono essere automatizzate. Nel cloud la maggior parte dei servizi è esposta con un'API. Dagli strumenti di sviluppo, all'infrastruttura virtualizzata, ai servizi della piattaforma, alle soluzioni offerte come SaaS, la maggior parte degli elementi che li compongono è gestibile tramite script.

La generazione di script è fortemente consigliata, infatti tramite questa operazione la distribuzione e la gestione risultano coerenti e stimabili; di conseguenza, è consigliabile utilizzare dividendi significativi per questo tipo di investimento.

Automatizzazione della distribuzione

La compilazione e la distribuzione di una soluzione rappresentano uno delle aree principali dell'automazione. Grazie a quest'ultima, il test e la distribuzione in più ambienti da parte di un team di sviluppo possono risultare semplici. Lo sviluppo, il test, la gestione temporanea, la versione beta e la produzione possono essere tutti distribuiti in modo immediato e coerente attraverso compilazioni automatizzate. La possibilità di eseguire distribuzioni in modo coerente negli ambienti ha come fine la garanzia che ciò che è in produzione rappresenti ciò che è stato testato.

I seguenti elementi possono essere considerati come "codice": script, file di configurazione e metadati relativi alla distribuzione. Il codice include inoltre la gestione di tali elementi nel controllo del codice sorgente, grazie alla quale è possibile eseguire queste operazioni:

  • Modifiche dei documenti.

  • Consentire il controllo delle versioni.

  • Fornire il controllo di accesso basato sui ruoli.

  • Assicurare che venga eseguito il backup del contenuto.

  • Fornire un'unica fonte di veridicità.

Definizione e automatizzazione di un test harness

Il test è un'altra area che può essere automatizzata. Come per la distribuzione automatica, la definizione di un test automatizzato è essenziale per assicurare che il sistema sia resiliente attualmente e lo rimanga nel tempo. Durante l'evoluzione del codice e dell'utilizzo del servizio è importante assicurarsi che vengano effettuati tutti i test necessari, sia a livello funzionale sia di scala.

Automatizzazione dell'archiviazione e dell'eliminazione dei dati

L'archiviazione e l'eliminazione dei dati rappresentano due altre operazioni a cui occorre prestare attenzione. Il volume dei dati sta aumentando e continuerà sempre più e con una grande varietà mai vista nella storia. A seconda della tecnologia del database e dei tipi di query richiesti, a causa dei dati non necessari è possibile che venga ridotto il tempo di risposta del sistema e, di conseguenza, che i costi aumentino inutilmente. Per i piani di resilienza in cui sono incluse una o più repliche di un archivio dati, tramite la rimozione di tutti i dati, tranne quelli necessari, è possibile velocizzare le attività di gestione, ad esempio il backup e il ripristino dei dati.

È consigliabile identificare i requisiti per la soluzione correlata ai dati necessari per la funzionalità principale, a quelli richiesti per motivi di conformità che possono essere archiviati e a quelli che non sono più necessari e possono essere eliminati.

Inoltre è consigliabile utilizzare le API disponibili dei prodotti e dei servizi correlati per automatizzare l'implementazione di questi requisiti.

Quando si compila un'architettura resiliente, è anche importante comprendere i concetti di domini di errore e di aggiornamento.

Domini di errore

Tramite i domini di errore viene vincolata la posizione dei servizi in base ai limiti noti dell'hardware e alla probabilità che un particolare tipo di interruzione influisca su un set di computer. Un dominio di errore è definito come una serie di computer in cui si possono verificare contemporaneamente degli errori e definiti generalmente da proprietà fisiche (un rack particolare di computer, una serie di computer da cui viene condivisa la stessa alimentazione e così via).

Domini di aggiornamento

I domini di aggiornamento sono simili ai domini di errore. Tramite i domini di aggiornamento viene definito un set fisico di servizi che vengono aggiornati contemporaneamente dal sistema. I domini di aggiornamento devono essere noti al servizio di bilanciamento del carico disponibile presso il provider di cloud al fine di garantire che, in caso di aggiornamento di un dominio particolare, i servizi rimangano disponibili e tutto il sistema bilanciato.

Gli aggiornamenti possono essere eseguiti ai seguenti livelli:

  • Livello hypervisor ("aggiornamento sistema operativo host").

  • Livello del sistema operativo ("aggiornamento sistema operativo guest").

  • Come risultato della distribuzione di un aggiornamento di un'applicazione o di un servizio nell'ambiente.

A seconda del provider di cloud e dei servizi della piattaforma utilizzati, i domini di errore e di aggiornamento potrebbero essere forniti in modo automatico, rappresentare degli elementi scelti dal servizio attraverso le API o richiedere una soluzione del produttore o di terze parti.

Resilienza durante un'operazione non riuscita del dominio di errore nel corso di un aggiornamento

Anche se i domini di errore e i domini di aggiornamento sono diversi, si intersecano in uno scenario specifico. In questo scenario, a causa di un guasto hardware una macchina virtuale viene portata offline durante un aggiornamento in un'altra istanza di macchina virtuale. In questo caso, due macchine virtuali verrebbero portate offline. Se la distribuzione di un servizio contiene solo due macchine virtuali, il servizio sarà offline. Si consiglia di tenere in considerazione questo scenario durante la scelta del numero di istanze necessarie per fornire il contratto di servizio desiderato.

Le piattaforme cloud offrono spesso la possibilità di identificare un livello di affinità per un gruppo di risorse. Tali risorse costituiscono i "gruppi di affinità", che contribuiscono ad agevolare il raggruppamento di risorse correlate nella piattaforma sottostante e facilitano l'allocazione di istanze nei domini di errore e aggiornamento.

Le soluzioni locali sono state spesso basate sulla ridondanza per facilitare la disponibilità e la scalabilità. Da un punto di vista della disponibilità, tramite i data center ridondanti è stato possibile aumentare la probabilità di continuità aziendale in caso di errori dell'infrastruttura in un data center specifico o in parte di esso.

Per le applicazioni con utenti distribuiti a livello geografico, tramite la gestione del traffico e le implementazioni ridondanti è stato possibile indirizzare gli utenti verso le risorse locali, spesso con una latenza ridotta.

noteNota
La resilienza dei dati, in cui è inclusa la ridondanza, viene illustrata come argomento separato della sezione Definizione di un approccio per la resilienza dei dati.

Ridondanza e cloud

A livello locale, la ridondanza è stata solitamente ottenuta tramite set di duplicati di hardware, software e rete. Talvolta viene implementata in un unico punto di un cluster o distribuita tra più data center.

Quando si concepisce una strategia per il cloud, è importante razionalizzare la necessità di ridondanza nei tre vettori. In questi ultimi sono inclusi codice distribuito all'interno dell'ambiente di un provider di cloud, ridondanza di provider stessi e ridondanza tra il cloud e l'istanza locale.

Ridondanza di distribuzione

Quando un'organizzazione ha selezionato un provider di cloud, è importante stabilire una strategia di ridondanza per la distribuzione nel provider.

In caso di distribuzione nella piattaforma come servizio (PaaS), gran parte di essa può essere gestita dalla piattaforma sottostante, mentre ciò non è possibile in caso di infrastruttura come modello di servizio (IaaS).

  • Distribuire un numero n di ruoli in un data center

    La forma più semplice di ridondanza consiste nel distribuire la soluzione in più istanze all'interno di un unico provider di cloud. Effettuando la distribuzione in più istanze, tramite la soluzione è possibile limitare il tempo di inattività che si verificherebbe quando viene distribuito un solo nodo.

    In molti ambienti di piattaforma come servizio lo stato della macchina virtuale in cui è ospitato il codice è monitorato e le eventuali macchine virtuali non integre possono essere sostituite automaticamente con un codice integro.

  • Distribuire in più data center

    Anche se la distribuzione di più nodi in un unico data center comporta vantaggi, nelle architetture occorre tenere conto che potrebbe essere non disponibile un intero data center. Sebbene non sia un'occorrenza comune, eventi quali calamità naturali, guerra e così via potrebbero determinare un'interruzione del servizio in una posizione geografica particolare.

    Per garantire il contratto di servizio, potrebbe essere opportuno distribuire la soluzione in più data center per il provider di cloud selezionato. A tal fine, sono disponibili diversi approcci, come specificato di seguito.

    1. Distribuzioni completamente ridondanti in più data center

      La prima opzione consiste in una soluzione completamente ridondante in più data center offerta insieme a un provider di gestione del traffico. Per questo approccio è necessario tenere in considerazione l'impatto sui costi correlati al calcolo per questo tipo di ridondanza, in quanto aumenteranno del 100% per ogni distribuzione aggiuntiva in data center.

    2. Distribuzione parziale in data center secondari per il failover

      Un altro approccio consiste nell'effettuare una distribuzione parziale in un data center secondario di dimensioni ridotte. Ad esempio, se nella configurazione standard sono state usate 12 istanze di calcolo, il data center secondario conterrebbe una distribuzione con 6 istanze di calcolo.

      Questo approccio, utilizzato insieme alla gestione del traffico, consentirebbe la continuità aziendale anche in caso di servizio ridotto in seguito a un evento imprevisto che ha interessato soltanto il data center principale.

      Dato il numero limitato di volte in cui un data center passa alla modalità offline completamente, questo approccio è spesso considerato economico per i calcoli, in particolare se tramite una piattaforma l'organizzazione può caricare immediatamente nuove istanze nel data center secondario.

    3. Distribuzioni divise in più data center con nodi di backup

      Per certi carichi di lavoro, in particolare quelli nei mercati verticali dei servizi finanziari, è necessario elaborare una grande quantità di dati in un intervallo di tempo breve e fisso. In queste circostanze, il lavoro viene eseguito in burst più brevi e, con i costi della ridondanza, viene garantito l'ottenimento di risultati entro questo intervallo.

      In questi casi, il codice viene distribuito in più data center. Il lavoro viene diviso e distribuito nei nodi per l'elaborazione. Nel caso in cui un data center diventi non disponibile, il lavoro previsto per questo nodo viene recapitato al nodo di backup tramite cui verrà completata l'attività.

    4. Distribuzioni in più data center con ridimensionamento geografico appropriato per data center

      In questo approccio vengono utilizzate le distribuzioni ridondanti presenti in più data center, ma ridimensionate in modo appropriato per la scala di un gruppo di destinatari pertinente dal punto di vista geografico.

Ridondanza del provider

Anche se la ridondanza incentrata sul data center è ottima, i contratti di servizio riguardano il livello di servizio piuttosto che il data center. Attualmente, molti servizi commerciali preferiscono distribuire nuove versioni in una "sezione" della produzione per convalidare il codice prodotto. È tuttavia possibile che i servizi forniti da un provider risultino non disponibili in più data center o in tutti.

In base ai contratti di servizio per una soluzione, potrebbe essere utile anche incorporare la ridondanza del provider. A tal fine, è necessario identificare i prodotti distribuibili nel cloud o i servizi cloud che verranno utilizzati in più piattaforme cloud. Microsoft SQL Server, ad esempio, può essere distribuito in una macchina virtuale all'interno delle offerte di infrastruttura come servizio della maggior parte dei fornitori.

Per i servizi forniti dal cloud, questa operazione è più complessa poiché non sono presenti interfacce standard, neanche per i servizi di base come calcolo, archiviazione, code e così via. L'eventuale ridondanza del provider che si desidera ottenere per questi servizi spesso può essere acquisita solo tramite un livello di astrazione. Tramite quest'ultimo possono essere fornite funzionalità sufficienti per una soluzione, tuttavia non ne verrà garantita un'innovazione tanto rapida quanto i servizi sottostanti e un'organizzazione potrebbe non essere in grado di utilizzare immediatamente le nuove funzionalità fornite da un provider.

La garanzia dei servizi del provider ridondanti può essere assicurata a uno dei diversi livelli, cioè l'intera applicazione, un carico di lavoro o un aspetto di quest'ultimo. Al livello appropriato, valutare la necessità di servizi di calcolo, dati e della piattaforma e determinare quali elementi devono essere veramente ridondanti e quali possono essere gestiti tramite approcci che forniscono una riduzione del funzionamento.

Ridondanza locale

Anche se l'accettazione di una dipendenza da un provider di cloud può essere utile dal punto di vista fiscale, per alcuni fattori aziendali è richiesta la ridondanza locale per questioni di conformità e/o di continuità aziendale.

In base ai contratti di servizio per una soluzione, potrebbe essere utile anche incorporare la ridondanza locale. A tal fine, è necessario identificare i prodotti distribuibili nel cloud privato o i servizi cloud che verranno utilizzati in più tipi di cloud. Come nel caso della ridondanza del provider, Microsoft SQL Server è un ottimo esempio di prodotto che può essere distribuito localmente in un'offerta IaaS.

Per i servizi forniti dal cloud, questa operazione è più complessa in quanto, spesso, non sono disponibili equivalenti locali con simmetria di interfacce e funzionalità.

L'eventuale richiesta di presenza locale di servizi del provider ridondanti può essere assicurata a uno dei diversi livelli, cioè l'intera applicazione, un carico di lavoro o un aspetto di quest'ultimo. Al livello appropriato, valutare la necessità di servizi di calcolo, dati e della piattaforma e determinare quali elementi devono essere veramente ridondanti e quali possono essere gestiti tramite approcci che forniscono una riduzione del funzionamento.

Approcci di configurazione della ridondanza

Quando si identificano gli approcci di configurazione della ridondanza vengono applicate anche le classificazioni esistenti prima del cloud. A seconda dei tipi di servizi utilizzati nella soluzione, alcuni di essi potrebbero essere gestiti automaticamente dalla piattaforma sottostante. In altri casi, questa funzionalità è gestita tramite tecnologie quali Windows Fabric.

  1. Attivo/attivo: il traffico destinato a un nodo con errore viene passato a un nodo esistente o gli viene associato un carico bilanciato nei nodi rimanenti. Questa operazione è generalmente solo possibile quando nei nodi viene utilizzata una configurazione di software omogenea.

  2. Attivo/passivo: viene fornita un'istanza completamente ridondante di ogni nodo che viene portato online solo quando il relativo nodo primario associato ha esito negativo. Per questa configurazione viene generalmente richiesto dell'hardware aggiuntivo.

  3. N+1: viene fornito un singolo nodo aggiuntivo che viene portato online per assumere il ruolo del nodo che ha avuto esito negativo. In caso di configurazione del software eterogenea in ogni nodo primario, il nodo aggiuntivo deve essere in grado di assumere completamente uno qualsiasi dei ruoli dei nodi primari di cui è responsabile. In genere si fa riferimento ai cluster in cui sono disponibili più servizi eseguiti contemporaneamente; in caso di singolo servizio, si passa all'approccio attivo/passivo.

  4. N+M: nei casi in cui tramite un singolo gruppo vengono gestiti molti servizi, se si dispone di un solo nodo di failover dedicato potrebbe non essere garantita una ridondanza sufficiente. In questi casi, sono inclusi e disponibili più server di standby (M). Il relativo numero è un compromesso tra costi e requisiti di affidabilità.

  5. Da N a 1: consente al nodo di standby di failover di diventare temporaneamente quello attivo, finché non è possibile ripristinare o riportare online il nodo originale; a questo punto, è necessario impostare il failback dei servizi o delle istanze su questo nodo per ripristinare la disponibilità elevata.

  6. Da N a N: grazie a una combinazione di attivo/attivo e N+M, tramite l'approccio da N a N vengono ridistribuiti i servizi, le istanze o le connessioni dal nodo con errore fra i nodi attivi rimanenti, eliminando così (come nel caso dell'approccio attivo/attivo) l'esigenza di un nodo "standby", ma introducendo la necessità di funzionalità aggiuntive in tutti i nodi attivi.

Indipendentemente dal fatto che il traffico sia sempre distribuito geograficamente o indirizzato verso data center diversi per soddisfare gli scenari di continuità aziendale, la funzionalità di gestione del traffico è importante per garantire che le richieste alla soluzione vengano indirizzate alle istanze appropriate.

È importante notare che l'accettazione di una dipendenza da un servizio di gestione del traffico comporta un singolo punto di errore. Inoltre, è anche fondamentale consultare il contratto di servizio relativamente alla gestione del traffico principale dell'applicazione e determinare se, in base alle esigenze dell'utente, è garantita una funzionalità di gestione del traffico alternativa.

Sebbene in molte applicazioni cloud con scalabilità elevata sia stato eseguito un ottimo processo di partizionamento a livello Web, la scalabilità a livello dati nel cloud produce risultati meno soddisfacenti. Con una varietà sempre in aumento di dispositivi connessi, si sta assistendo a una crescita del livello di dati generati e sottoposti a query senza precedenti. La necessità di essere in grado di supportare 500.000 nuovi utenti al giorno, ad esempio, è attualmente considerata ragionevole.

Disporre di una strategia di partizionamento è estremamente importante in più dimensioni, tra cui l'archiviazione, l'esecuzione di query o la gestione dei dati in questione.

Scomposizione e partizionamento

Grazie ai vantaggi e ai compromessi legati alle differenti tecnologie, è pratica comune utilizzare le più appropriate per il carico di lavoro specificato.

Disporre di una soluzione scomposta in base ai carichi di lavoro offre la possibilità di scegliere le tecnologie di dati ottimali per un determinato carico di lavoro. Ad esempio, in un sito Web è possibile utilizzare l'archiviazione tabelle per il contenuto di un utente, utilizzando le partizioni a livello utente per un'esperienza di risposta. Le righe della tabella possono essere aggregate periodicamente in un database relazionale per la creazione di report e l'analisi dei dati.

Le strategie di partizionamento possono variare con grande probabilità in base alle tecnologie scelte.

Quando si definisce una strategia, è importante identificare gli outlier che possono richiedere una strategia modificata o alternativa. Ad esempio, se si distribuisce un sito di social networking, occorre tenere presente che un utente ordinario può avere 500 connessioni, mentre un personaggio famoso può averne anche 5.000.000.

Se si prevede che il sito sarà usato da 100.000.000 di utenti e che il numero di personaggi famosi non superi 50.000, la strategia fondamentale di partizionamento sarà ottimizzata per gli utenti ordinari. I personaggi famosi dovranno essere gestiti in modo diverso. È ad esempio possibile raggruppare un numero elevato di utenti in una sola partizione, mentre un personaggio famoso può essere allocato in una partizione separata.

Informazioni sulla teoria delle 3 V

Per poter definire correttamente una strategia di partizionamento, un'organizzazione deve innanzitutto comprenderne il concetto.

In base alla teoria delle 3 V, resa nota da Gartner, vengono esaminati tre diversi aspetti dei dati. Comprendere la modalità di correlazione delle 3 V ai dati in uso consentirà di prendere decisioni oculate sulle strategie di partizionamento.

  • Volume

    Con il termine volume viene fatto riferimento alle dimensioni dei dati. Il volume ha conseguenze effettive sulla strategia di partizionamento. Le limitazioni di volume in una tecnologia di dati specifica possono forzare l'applicazione del partizionamento a causa delle limitazioni delle dimensioni, della velocità delle query relativamente al volume e così via.

  • Velocità

    Con il termine velocità viene fatto riferimento alla velocità di aumento dei dati. È probabile che venga definita una diversa strategia di partizionamento in caso di un archivio dati caratterizzato da un aumento lento rispetto a uno nel quale devono essere inseriti 500.000 nuovi utenti al giorno.

  • Varietà

    Con il termine varietà viene fatto riferimento ai diversi tipi di dati che sono correlati al carico di lavoro. È importante capire se si tratta di dati relazionali, coppie chiave-valore, profili social media, immagini, file audio, video o di altri tipi di dati. Queste informazioni sono fondamentali sia per scegliere la tecnologia di dati appropriata sia per prendere decisioni oculate circa la strategia di partizionamento.

Partizionamento orizzontale

Probabilmente l'approccio più comune al partizionamento dei dati è quello orizzontale. In questo caso, una decisione viene presa secondo i criteri per partizionare un archivio dati in più partizioni. In ogni partizione è contenuto l'intero schema, con i criteri mediante i quali viene stabilita la posizione dei dati nelle partizioni appropriate.

Questa operazione può essere eseguita in modalità diverse in base al tipo e all'utilizzo dei dati. Ad esempio, un'organizzazione potrebbe scegliere di partizionare i dati in base al cognome del cliente. In un altro caso, la partizione può essere incentrata sulla data, effettuando il partizionamento nel relativo intervallo di calendario di ora, giorno, settimana o mese.

Diagramma del partizionamento orizzontale

Figura 5: Esempio di partizionamento orizzontale in base al cognome

Partizionamento verticale

Un altro approccio è rappresentato dal partizionamento verticale. In questo modo è possibile ottimizzare la posizione dei dati in archivi diversi, spesso associati alla varietà dei dati. Nella figura 5 viene mostrato un esempio in cui i metadati relativi a un cliente vengono posizionati in un archivio mentre le anteprime e le foto in archivi separati.

Il partizionamento verticale può determinare un'archiviazione e un recapito ottimizzati dei dati. Nella figura 5, ad esempio, se la foto di un cliente viene visualizzata di rado, la restituzione di 3 MB per ogni record può aggiungere costi non necessari in un modello di uso prepagato.

Diagramma del partizionamento verticale

Figura 6: Esempio di partizionamento verticale.

Partizionamento ibrido

In molti casi sarà opportuno scegliere una strategia di partizionamento ibrido. In questo modo è possibile avvalersi delle efficienze di entrambi gli approcci in una singola soluzione.

Nella figura 6 viene mostrato un esempio di questa strategia, dove il partizionamento verticale illustrato in precedenza viene aumentato per sfruttare i vantaggi del partizionamento orizzontale dei metadati del cliente.

Diagramma del partizionamento orizzontale

Figura 7: Esempio di partizionamento orizzontale.

La parte centrale del cloud computing è rappresentata dalla rete. Quest'ultima è infatti un elemento essenziale in quanto fornisce l'infrastruttura o la backbone dei dispositivi per la connessione ai servizi, nonché i servizi tramite cui si effettua la connessione ad altri servizi. In un'applicazione di tipo operatore alternativo è opportuno considerare tre limiti della rete.

Questi limiti vengono illustrati di seguito con Azure utilizzato come esempio per fornire il contesto:

  1. I limiti di ruolo vengono in genere definiti livelli. Ne sono esempi comuni un livello Web o un livello di logica di business. Se si esamina Azure come esempio, si noterà che in esso i ruoli sono stati formalmente introdotti come parte del progetto di base per fare in modo che l'infrastruttura supporti la natura multilivello delle applicazioni moderne distribuite. Tramite Azure viene garantito che le istanze dei ruoli che appartengono allo stesso livello vengano ospitate nell'ambito di un singolo ambiente di rete e gestite da un unico controller di infrastruttura.

  2. I limiti di servizio rappresentano le dipendenze dalle funzionalità fornite da altri servizi. Ne sono esempi comuni un ambiente SQL per l'accesso al database relazionale e la funzionalità Service Bus per il supporto di messaggistica di pubblicazione-sottoscrizione. In Azure, ad esempio, i limiti di servizio vengono applicati attraverso la rete. Non viene fornita alcuna garanzia che una dipendenza del servizio faccia parte dello stesso ambiente di rete o del controller di infrastruttura. Questa situazione potrebbe verificarsi, ma il presupposto di progettazione per qualsiasi applicazione responsabile deve essere che ogni dipendenza del servizio si trovi in una rete differente gestita da un diverso controller di infrastruttura.

    Diagramma delle istanze del ruolo del servizio cloud
    Figura 8

  3. I limiti dell'endpoint sono esterni al cloud. Rientra in questo tipo di limite qualsiasi endpoint di utilizzo, che generalmente si presuppone essere un dispositivo, tramite cui viene stabilita la connessione al cloud per l'utilizzo dei servizi. È necessario fare delle considerazioni particolari in questa fase di progettazione a causa della natura variabile e inaffidabile della rete. I limiti di ruolo e di servizio rientrano nei limiti dell'ambiente cloud e si può presupporre un determinato livello di affidabilità e di larghezza di banda. Nel caso delle dipendenze esterne, non si possono fare ipotesi, né ulteriori considerazioni circa la possibilità di utilizzo dei servizi, vale a dire dati e interazioni, da parte del dispositivo.

    Tramite la rete, per sua natura, viene generata latenza durante il passaggio delle informazioni da un punto delle rete a un altro. Per ottenere un utilizzo ottimale sia per gli utenti sia come servizi o ruoli dipendenti, nell'architettura e nella progettazione dell'applicazione si devono tener conto di modalità per ridurre al massimo la latenza e per gestire in modo esplicito quella inevitabile. Una delle modalità più comuni per ridurre la latenza consiste nell'evitare le chiamate di servizi che interessano la rete. L'accesso locale ai dati e ai servizi rappresenta un approccio di base per ridurre la latenza e introdurre una velocità di risposta più elevata. L'utilizzo dei dati e dei servizi locali fornisce anche un altro livello di sicurezza in caso di errore; finché le richieste dell'utente o dell'applicazione possono essere soddisfatte dall'ambiente locale, non è necessario interagire con altri ruoli o servizi, eliminando la possibilità di indisponibilità del componente dipendente come punto di errore.

Caching

La memorizzazione nella cache è una tecnica utilizzabile per migliorare la velocità di accesso ai dati quando non è possibile un'archiviazione di questi ultimi in locale. Viene utilizzata per aumentare gli effetti nella maggior parte del servizio cloud attualmente operativo nella scala. In base alla definizione fornita da Wikipedia, tramite una cache viene fornito l'accesso locale ai dati richiesti ripetutamente dalle applicazioni. La memorizzazione nella cache si basa su due elementi:

  • I modelli di utilizzo per i dati degli utenti e delle applicazioni dipendenti sono prevalentemente di sola lettura. In determinati scenari, ad esempio i siti Web di e-commerce, la percentuale massima di accesso in sola lettura, talvolta definita esplorazione, è pari al 95% di tutte le interazioni utente con il sito.

  • Tramite il modello informativo dell'applicazione viene fornito un ulteriore livello di informazioni semantiche che supportano l'identificazione di dati stabili e singolari, ottimali per la memorizzazione nella cache.

Memorizzazione nella cache del dispositivo

Sebbene non sia l'elemento chiave dell'iniziativa di operatore alternativo, la memorizzazione nella cache del dispositivo è una delle modalità più valide per aumentare l'usabilità e l'affidabilità di un'applicazione costituita da dispositivi e servizi. Sono disponibili numerose modalità per fornire servizi di memorizzazione nella cache nel dispositivo o a livello client, dalla specifica HTML5 tramite cui vengono fornite funzionalità native di memorizzazione nella cache implementate in tutti i browser standard, alle istanze del database locale quale SQL Server Compact Edition o simili.

Cache distribuita

La cache distribuita è un potente set di funzionalità, ma il suo scopo non è quello di sostituire un database relazionale o un altro archivio persistente, bensì di aumentare la velocità di risposta alle applicazioni distribuite che, per natura, sono incentrate sulla rete e, pertanto, sensibili alla latenza. Un vantaggio legato all'introduzione della memorizzazione nella cache consiste nella riduzione del traffico verso l'archivio dati persistente, con conseguente numero minimo di interazioni con il servizio dati.

  • Modelli informativi ottimizzati per la memorizzazione nella cache

    noteNota
    Molto del contenuto di questa sezione è basato sul grande lavoro svolto da Pat Helland quando pensava ai dati in un mondo di architetture orientate ai servizi. L'interoarticolo è disponibile per la lettura in Microsoft Developer Network.

    I dati memorizzati nella cache sono, per loro natura, non aggiornati, vale a dire dati che non devono più essere necessariamente aggiornati. Un ottimo esempio di dati memorizzati nella cache, anche se da un dominio molto diverso, è un catalogo dei prodotti inviato a migliaia di unità familiari. I dati utilizzati per generare il catalogo dei prodotti sono stati aggiornati al momento della creazione del catalogo. Una volta avviate le macchine da stampa, i dati diventano non aggiornati entro il tempo necessario per il processo di produzione del catalogo. A causa di dati non aggiornati memorizzati nella cache, i relativi attributi correlati a stabilità e singolarità sono essenziali nella progettazione della memorizzazione:

    • Stabilità: dati con un'interpretazione non ambigua nello spazio e nel tempo. Questa caratteristica spesso indica che i valori dei dati non vengono modificati. Ad esempio, la maggior parte delle organizzazioni non ricicla mai gli ID dei clienti o i numeri SKU. Un'altra tecnica per creare dati stabili consiste nell'aggiunta di date di scadenza ai dati esistenti. Il catalogo dei prodotti stampato, citato in precedenza, è un ottimo esempio. I rivenditori accettano in genere gli ordini da qualsiasi catalogo specificato per 2 periodi di pubblicazione. Se si pubblica un catalogo quattro volte l'anno, i relativi dati sono stabili per 6 mesi e possono essere utilizzati per l'elaborazione di informazioni, ad esempio per effettuare ed evadere ordini.

      I dati stabili vengono spesso definiti master o dati di riferimento. Nell'iniziativa di operatore alternativo il termine dati di riferimento verrà utilizzato come semanticamente più inclusivo rispetto al termine dati master. In molte organizzazioni il significato di dati master è più specifico e più limitato rispetto ai dati di riferimento.

    • Singolarità: dati che possono essere isolati tramite l'associazione a istanze identificabili in modo univoco senza alcun aggiornamento o con aggiornamenti simultanei non elevati. Si prenda, ad esempio, un carrello acquisti. Anche se il carrello acquisti verrà chiaramente aggiornato, gli aggiornamenti vengono effettuati in modo relativamente raro e possono essere completamente isolati dall'archiviazione, nonché dalla prospettiva di elaborazione.

      I dati isolabili, come descritto in precedenza, vengono definiti dati dell'attività o dati di sessione.

      Tenendo presente questi due attributi, viene generato lo schema seguente:

      Diagramma dei tipi di dati
      Figura 9

  • Modello informativo

    Molti architetti o sviluppatori di applicazioni tengono in considerazione i modelli a oggetti e di entità quando pensano al modello informativo. Anche se questi modelli fanno parte dell'arte e della scienza del modello informativo, gli aspetti che li caratterizzano nel caso di un'applicazione di tipo operatore alternativo sono molti altri.

    La stabilità e la singolarità rappresentano una prima finalità dei processi sviluppati necessari per l'attuale mondo distribuito. Un altro elemento chiave è comprendere la modalità di utilizzo dei dati nell'interazione con l'utente o con il dispositivo oppure come parte dei processi aziendali da implementare. La modellazione orientata agli oggetti deve far parte del progetto informativo in diverse modalità:

    • Nascondere le informazioni: nascondere o non fornire accesso alle informazioni che non sono utili all'utente o al processo aziendale è una delle modalità migliori per evitare conflitti con la risorsa o con i dati condivisi archiviati e gestiti in un database relazionale.

      Un valido esempio del modo in cui nascondendo le informazioni viene potenziato l'effetto correlato al miglioramento delle concorrenza è la differenza tra un sistema ERP tipico e la modalità con cui Amazon.com gestisce la maggior parte degli scenari di inventario. In un'implementazione tipica di un sistema ERP, la tabella di magazzino è una delle più congestionate o a cui si accede con maggiore frequenza, se si presuppone un'implementazione del database relazionale. Tramite l'applicazione ERP si tenta in genere di bloccare le scorte fino a quando l'utente non ha completato la transazione, fornendo il numero di scorte esatte all'applicazione al momento dell'inizio della transazione commerciale. Tramite alcuni sistemi, ad esempio SAP, il blocco del database viene evitato, ma viene acquisito un blocco a livello di applicazione nel sistema di accodamento. Molte tecniche a livello di database sono state sviluppate a supporto di questa congestione: controllo della concorrenza ottimistica, letture dirty e così via. Tuttavia, nessuna operazione viene effettuata senza problemi e tutte presentano effetti collaterali. In determinati scenari si desidera bloccare la tabella, ma questa operazione deve essere effettuata di rado e con intervalli prolungati.

      In Amazon.com il problema è stato risolto in un modo molto più semplice: all'utente è stata data la possibilità di accettare o rifiutare un obiettivo del livello di servizio (SLO, Service-level objective). L'obiettivo SLO è stato generalmente definito come "di solito disponibile in N ore": l'utente non ha visualizzato il conteggio effettivo di libri disponibili o di altri articoli, tuttavia gli sono state fornite informazioni sulla disponibilità. Non è stato richiesto alcun blocco del database; in realtà, non era richiesta alcuna connettività del database. Se tramite il sistema non è stato possibile soddisfare l'obiettivo SLO, verranno inviate delle scuse all'acquirente (generalmente tramite posta elettronica) a cui verrà anche offerto un obiettivo SLO aggiornato.

    • Risorse fungibili: il dizionario definisce fungibile, soprattutto se riferito a beni, un tipo di elemento che può essere scambiato o sostituto liberamente, in tutto o in parte, con un altro elemento simile. Il fulcro dell'idea, insieme all'obiettivo di ridurre ulteriormente l'attrito correlato all'accesso ai dati condivisi, è l'utilizzo delle informazioni sulla modellazione per fare in modo che l'utente interagisca con un'istanza fungibile di dati anziché un'istanza specifica. Un valido esempio è la prenotazione di una camera di albergo. È possibile indicare numerosi dettagli, ad esempio numero di letti, vista sull'oceano, camera per fumatori/non fumatori e così via senza dover fare sempre riferimento al numero della camera. Utilizzando una modellazione come questa, è possibile memorizzare nella cache informazioni sui pool di dati fungibili, eseguire il processo aziendale nel pool e assegnare una camera specifica esterna a questo pool solo in seguito alla finalizzazione del processo di accettazione. Sono comunque possibili anche modelli ibridi in cui una camera specifica viene rimossa da un pool all'inizio del processo di accettazione.

  • Gestione delle cache

    La memorizzazione nella cache delle informazioni corrette nel momento appropriato è un aspetto fondamentale per garantire una strategia di memorizzazione ottimale. Per il caricamento della cache sono disponibili numerose tecniche. Nell'articolo relativo alla memorizzazione nella cache nell'ambiente distribuito viene presentata un'ottima panoramica. Inoltre, nelle sezioni seguenti vengono descritte alcune considerazioni sulla progettazione di applicazioni di tipo operatore alternativo che dipende dalla memorizzazione nella cache distribuita.

    • Dati di riferimento: se nell'ambiente host (controller di infrastruttura o data center) viene rilevata un'emergenza, l'applicazione verrà spostata in un altro ambiente. Nel caso in cui un'istanza attiva dell'applicazione sia già attiva (approccio attivo-attivo), è molto probabile che nella cache siano già contenute molte delle informazioni pertinenti (in particolare i dati di riferimento). Nel caso in cui una nuova istanza dell'applicazione venga riattivata, nei nodi della cache non saranno presenti informazioni. È consigliabile che l'applicazione venga progettata in modo che in caso di mancato riscontro nella cache vengono caricati automaticamente i dati desiderati. In presenza di una nuova istanza, è possibile utilizzare una routine di avvio tramite cui viene effettuato il caricamento bulk dei dati di riferimento nella cache. È consigliabile utilizzare una combinazione poiché gli utenti potrebbero essere attivi non appena l'applicazione viene gestita dall'infrastruttura del cloud.

    • Dati dell'attività: le tecniche di base descritte per i dati di riferimento sono valide anche per i dati dell'attività. Tuttavia, questi ultimi presentano una caratteristica specifica. Si presuppone che i dati di riferimento siano disponibili in qualsiasi archivio persistente dell'applicazione. Poiché verranno modificati con una frequenza inferiore, la sincronizzazione non dovrebbe essere un problema, è comunque necessario tenerla in considerazione. Tuttavia, i dati dell'attività, sebbene siano aggiornati singolarmente e con una frequenza ridotta, saranno più volatili rispetto ai dati di riferimento. Idealmente, tramite la cache distribuita i dati dell'attività vengono resi persistenti in base a una specifica frequenza e vengono replicati tra le varie istanze dell'applicazione. Assicurarsi che gli intervalli di persistenza e sincronizzazione siano abbastanza distanziati da evitare contese, ma abbastanza ravvicinati per ridurre al minimo le eventuali perdite di dati.

Spesso, la relazione tra la piattaforma e l'applicazione, in particolare le aree di responsabilità, non viene compresa correttamente. Una delle aree più problematiche è quella relativa ai dati.

Sebbene tramite una piattaforma come Azure venga fornita localmente l'archiviazione di più copie di dati (e in alcuni servizi venga persino assicurata la ridondanza a livello geografico), la scelta relativa a quali dati archiviare viene determinata dall'applicazione, dal carico di lavoro e dai servizi dei relativi componenti. Se tramite l'applicazione viene intrapresa un'azione a causa della quale i dati dell'applicazione vengono danneggiati, ne verranno archiviate più copie.

Quando si stabiliscono le modalità e i punti di errore, è importante identificare le aree dell'applicazione che potrebbero comportare un danneggiamento dei dati. Anche se il punto di origine potrebbe variare da un codice errato a messaggi non elaborabili per il servizio, è importante identificare le modalità e i punti di errore correlati.

Risoluzione a livello di applicazione

  • Idempotenza

    Secondo un presupposto di base relativo ai servizi connessi, la disponibilità totale di questi ultimi non verrà garantita e la gestione degli errori temporanei con la logica di tentativi rappresenta un approccio di implementazione fondamentale. Nei casi in cui viene implementata la logica di tentativi, esiste il rischio che lo stesso messaggio venga inviato più volte, se si tratta di messaggi da inviare fuori sequenza e così via.

    Le operazioni devono essere progettate per essere idempotenti, garantendo che l'invio dello stesso messaggio più volte non comporti un archivio dati imprevisto o inquinato.

    Ad esempio, l'inserimento dei dati di tutte le richieste può determinare l'aggiunta di più record se l'operazione del servizio viene chiamata più volte. Un approccio alternativo consisterebbe nell'implementare il codice come operazione di aggiornamento/inserimento ("upsert") intelligente tramite cui viene effettuato un aggiornamento, in presenza di un record, oppure un inserimento, nel caso in cui il record non sia disponibile. Per identificare i nuovi messaggi elaborati da quelli precedenti è possibile utilizzare un timestamp o un identificatore globale, inserendo nel database solo i messaggi più recenti e aggiornando i record esistenti qualora il messaggio sia più recente rispetto a quello ricevuto in precedenza.

  • Attività del carico di lavoro e comportamento di compensazione

    Oltre all'idempotenza, un altro aspetto da prendere in considerazione riguarda il concetto di comportamento di compensazione.

    Un esempio realistico di comportamento di compensazione è la restituzione di un prodotto che è stato pagato con carta di credito. In questo scenario, un utente si reca presso un rivenditore, paga con la carta di credito e la spesa viene addebitata sul conto legato alla carta di credito del cliente. Se quest'ultimo restituisce il prodotto al rivenditore, vengono valutati i criteri e se la restituzione è conforme ai criteri, il rivenditore emette un credito pari all'importo dell'acquisto sul conto legato alla carta di credito del cliente.

    In un mondo caratterizzato da set di sistemi connessi in continuo aumento e dall'emergenza di servizi compositi, l'importanza di comprendere come gestire il comportamento di compensazione è essenziale.

    Per molti sviluppatori di applicazioni line-of-business, i concetti di transazioni non sono nuovi, ma la cornice di riferimento è spesso legata alla funzionalità transazionale esposta dalle tecnologie di dati locali e dalle librerie di codice correlate. Esaminando il concetto in termini di cloud, per un approccio di questo tipo è opportuno tener conto delle nuove considerazioni correlate all'orchestrazione di servizi distribuiti.

    Un'orchestrazione di servizi può estendersi a più sistemi distribuiti ed essere a esecuzione prolungata e con stato. La stessa orchestrazione è raramente sincrona e può estendersi da secondi ad anni in base allo scenario aziendale.

    In uno scenario di catena di fornitura tramite questa operazione potrebbero essere correlate 25 organizzazioni nella stessa attività di carico di lavoro. Ad esempio, potrebbe essere presente un set di almeno 25 sistemi interconnessi in una o più orchestrazioni di servizi.

    In tal caso, il completamento dell'attività deve essere noto ai 25 sistemi. Per ogni punto di connessione nell'attività, tramite i sistemi dei partecipanti è possibile fornire un ID di correlazione per i messaggi ricevuti dagli altri sistemi. A seconda del tipo di attività, tramite la ricezione dell'ID di correlazione in questione può essere indicato alla parte il completamento della transazione a livello teorico. In altri casi, al termine delle interazioni di tutte le 25 parti, può essere inviato un messaggio di conferma a tutte le parti, direttamente da un singolo servizio o tramite i punti specifici di interazione dell'orchestrazione per ogni sistema.

    Per gestire gli errori di attività composite e/o distribuite, tramite ogni servizio vengono esposte operazioni e un'interfaccia di servizio per ricevere le richieste di annullamento di una transazione specificata da un identificatore univoco. Dietro ai servizi sono presenti flussi di lavoro per compensare l'annullamento di questa attività. Queste procedure sarebbero idealmente automatiche, ma possono essere semplici quanto il routing a un utente nell'organizzazione per una soluzione manuale.

Backup

Oltre alla soluzione a livello di applicazione per evitare il danneggiamento dei dati, esiste un'altra soluzione tramite cui vengono fornite diverse opzioni se la soluzione dell'applicazione non riesce.

È consigliabile che i processi per la creazione e il ripristino di copie di backup dell'archivio dati, sia interamente sia in parte, siano inclusi nel piano di resilienza. Sebbene i concetti di backup e ripristino dei dati non siano nuovi, nel cloud presentano delle modifiche.

È consigliabile che la strategia di backup venga definita tenendo in considerazione i requisiti aziendali per il ripristino dei dati. Se un archivio dati è danneggiato o portato offline a causa di uno scenario di emergenza, è necessario conoscere il tipo di dati e il volume da ripristinare, nonché la velocità richiesta per l'attività aziendale. Questa operazione influisce su tutto il piano di disponibilità ed è quindi consigliabile che se ne tenga conto durante la pianificazione di backup e ripristino.

  • Database relazionali

    Il backup di database relazionali non è un concetto nuovo. In molte organizzazioni sono disponibili strumenti, approcci e processi per eseguire il backup dei dati e garantire quindi un ripristino di emergenza o rispettare le esigenze di conformità. In molti casi, gli strumenti, gli approcci e i processi di backup tradizionali funzionano con poche modifiche o persino nessuna. Inoltre, è possibile prendere in considerazione alternative nuove o diverse, ad esempio il backup dei dati e l'archiviazione di una copia nell'archiviazione BLOB basata su cloud.

    Quando si valutano i processi e gli strumenti esistenti, è importante individuare quale sia l'approccio appropriato per la soluzione basata su cloud. In molti casi, verrà applicato almeno uno degli approcci elencati di seguito per risolvere diverse modalità di errore.

    1. Backup totale: si tratta del backup di un intero archivio dati. È consigliabile che i backup totali vengano eseguiti in base a una pianificazione che dipende dal volume e dalla velocità dei dati. Un backup totale consiste nel set di dati completo da offrire nel contratto di servizio. I meccanismi per questo tipo di backup vengono in genere messi a disposizione dal database o dal relativo provider di servizi oppure dall'ecosistema di fornitori correlato.

    2. Momento preciso: in questo tipo di backup viene riflesso un momento preciso dell'esistenza del database. Se nel pomeriggio si è verificato un errore che ha danneggiato, ad esempio, l'archivio dati, si potrebbe ripristinare un backup effettuato a mezzogiorno per ridurre l'impatto sull'attività aziendale.

      Dal momento che il livello di connettività dei singoli utenti è in continua crescita, l'aspettativa di utilizzare il servizio in qualsiasi momento fa sì che la possibilità di un ripristino rapido in un momento recente diventi una necessità.

    3. Sincronizzazione: oltre ai backup tradizionali, un'altra opzione è la sincronizzazione dei dati. I dati possono essere archiviati in più data center, ad esempio con una relativa sincronizzazione periodica da un data center a un altro. Oltre a fornire dati sincronizzati nelle soluzioni in cui viene utilizzata la gestione del traffico come parte di un normale piano di disponibilità, la sincronizzazione può essere utilizzata anche per eseguire il failover su un secondo data center in caso di problema di continuità aziendale.

      Data la costante connettività dei singoli utenti che utilizzano i servizi, i periodi di inattività sono sempre meno accettati in numerosi scenari e, di conseguenza, la sincronizzazione può risultare un ottimo approccio.

      Nei modelli per la sincronizzazione possono essere inclusi:

      - da data center a data center di uno specifico provider di cloud

      - da data center a data center in più provider di cloud

      - da data center a data center da un'istanza locale a un provider di cloud specifico

      - da data center alla sincronizzazione dei dispositivi per sezioni di dati specifiche del cliente

  • Database relazionali partizionati

    Per molti, il passaggio al cloud è determinato dalla necessità di consentire un grande numero di utenti e scenari di traffico elevato, ad esempio quelli relativi alle applicazioni mobili o di social networking. In questi scenari, nel modello dell'applicazione è spesso incluso anche il passaggio da un singolo modello di database a diverse partizioni di database contenenti parte del set di dati complessivo e ottimizzate per l'utilizzo su larga scala. Un recente progetto di social networking basato su Azure è stato avviato con un totale di 400 partizioni di database.

    Ogni partizione è un database autonomo e tramite l'architettura e la gestione dovrebbero essere semplificati i backup totali, quelli effettuati in un momento preciso, nonché il ripristino dei backup sia per le singole partizioni sia per il set di dati completo in cui sono incluse tutte le partizioni.

  • Archivi dati NoSQL

    Oltre agli archivi dati relazionali, è consigliabile considerare i criteri di backup anche per gli archivi dati NoSQL o "non solo SQL". Il formato più comune di database NoSQL fornito dai principali provider di cloud è quello di un archivio della coppia chiave-valore a disponibilità elevata, spesso definito archivio tabelle.

    Gli archivi NoSQL possono essere estremamente disponibili. In alcuni casi saranno anche ridondanti da un punto di vista geografico, impedendo in questo modo perdite qualora si verificasse un errore irreversibile in un data center specifico. Questi archivi in genere non garantiscono protezione alle applicazioni relativamente alla sovrascrittura o all'eliminazione non intenzionali del contenuto. Gli errori dell'utente o dell'applicazione non vengono gestiti automaticamente dai servizi della piattaforma, ad esempio l'archiviazione BLOB, ed è pertanto consigliabile valutare una strategia di backup.

    Sebbene i database relazionali dispongano in genere di strumenti esistenti e consolidati per l'esecuzione dei backup, molti archivi NoSQL ne sono privi. Un approccio architetturale comune consiste nel creare una copia duplicata dei dati in un archivio NoSQL di replica e di utilizzare una tabella di ricerca di un determinato tipo per l'identificazione delle righe dell'archivio di origine che sono state inserite nell'archivio di replica. Per il ripristino dei dati, verrà utilizzata questa stessa tabella e verrà effettuata una lettura in quest'ultima per identificare il contenuto da ripristinare nell'archivio di replica disponibile.

    A seconda delle esigenze di continuità aziendale, questa replica può essere ospitata con lo stesso provider di cloud, nello stesso data center e/o nello stesso archivio dati NoSQL. Può inoltre trovarsi in un altro data center, in un provider di cloud differente e/o in un tipo di archivio dati NoSQL diverso. La scelta della posizione sarà influenzata principalmente dal contratto desiderato del servizio di carico di lavoro e da qualsiasi considerazione correlata sulla conformità normativa.

    Un fattore da considerare quando si effettua questa scelta è la determinazione del costo, in particolare quando si crea la relazione tra i dati in ingresso e quelli in uscita. I provider di cloud possono fornire la libera circolazione dei dati nei data center e consentire il libero passaggio dei dati nell'ambiente. Nessun provider di cloud fornisce dati in ingresso gratuiti e il costo di spostamento dei dati a un provider secondario della piattaforma cloud può comportare costi significativi nella scala.

    noteNota
    La tabella di ricerca diventa un potenziale punto di errore ed è consigliabile considerare una relativa replica durante la pianificazione della resilienza.

  • Archiviazione BLOB

    Come avviene per gli archivi dati NoSQL e relazionali, un preconcetto comune è che la disponibilità delle funzionalità implementate per un'offerta di archiviazione BLOB potrà evitare la necessità di implementare i criteri di backup.

    L'archiviazione BLOB può inoltre essere ridondante da un punto di vista geografico, tuttavia, come illustrato in precedenza, non assicura la protezione da eventuali errori dell'applicazione. Gli errori dell'utente o dell'applicazione non vengono gestiti automaticamente dai servizi della piattaforma, ad esempio l'archiviazione BLOB, ed è pertanto consigliabile valutare una strategia di backup.

    Le strategie di backup potrebbero essere molto simili a quelle utilizzate per gli archivi NoSQL. A causa delle dimensioni potenzialmente rilevanti dei BLOB, i costi e i tempi di spostamento dei dati rappresenteranno aspetti importanti di una strategia di backup e ripristino.

  • Ripristino dei backup

    A questo punto alla maggior parte degli utenti sono note le decisioni cautelative dell'organizzazione che ha stabilito e seguito con zelo i criteri di backup, ma che non ha mai testato il ripristino dei dati. Pertanto, il giorno in cui si è verificata l'emergenza, quando stavano per ripristinare il backup del database hanno scoperto che non era stato configurato correttamente e che nei nastri inviati all'esterno per anni non erano contenute le informazioni di cui necessitavano.

    Per tutti i processi di backup che vengono eseguiti, è importante stabilire l'esecuzione del test per verificare che i dati possano essere ripristinati in modo corretto e per garantire che il ripristino si verifichi tempestivamente e con un impatto minimo sull'azienda.

Le reti per la distribuzione di contenuti (CDN) rappresentano una modalità comune per fornire disponibilità ed esperienza utente avanzata per i file richiesti di frequente. Il contenuto di una rete CDN viene copiato in un nodo locale al primo utilizzo e viene fornito da quest'ultimo, in un secondo momento, per le richieste successive. Al contenuto verrà assegnata una scadenza precisa dopo la quale dovrà essere copiato di nuovo nel nodo locale alla successiva richiesta.

L'utilizzo di una rete CDN offre numerosi vantaggi, ma aggiunge anche una dipendenza, pertanto la soluzione per un errore del servizio deve essere prontamente esaminata.

Utilizzo appropriato di una rete CDN

Un preconcetto comune è che le reti CDN rappresentino un rimedio valido per la scala. In uno scenario in cui un cliente era certo che si trattasse della soluzione giusta per un archivio ebook online, questa scelta non si è rivelata tuttavia appropriata, Perché? in un catalogo con un milione di libri, solo un piccolo subset di questi viene richiesto di frequente (le "occorrenze"), mentre una parte più consistente viene richiesta con meno prevedibilità. I titoli più richiesti vengono copiati nel nodo locale alla prima richiesta e offrono una scala locale economica, nonché un'esperienza utente piacevole. Per la parte più consistente, quasi tutte le richieste vengono copiate due volte, la prima nel nodo locale, la seconda per il cliente, dal momento che le richieste rare determinano una scadenza su base regolare del contenuto. Questo esempio è la prova che una rete CDN produrrà l'effetto contrario a quello desiderato, si rivelerà cioè una soluzione più lenta e più dispendiosa.

In molti casi, le operazioni di una soluzione possono essere pianificate solo in una fase avanzata del ciclo di vita. Per compilare applicazioni effettivamente resilienti, esse devono essere progettate per le operazioni. In questo tipo di progettazione verranno in genere incluse attività chiave quali la definizione del modello di integrità, l'acquisizione di informazioni di telemetria, l'incorporamento di flussi di lavoro e di servizi di monitoraggio dello stato, nonché la resa di questi dati utilizzabili sia dalle operazioni sia dagli sviluppatori.

I team di sviluppo spesso trascurano, e talvolta ignorano del tutto, l'"integrità" dell'applicazione. Di conseguenza, l'ingresso in produzione dei servizi avviene di frequente con due stati noti, vale a dire attivo o inattivo. I responsabili della progettazione di servizi resilienti devono sviluppare modelli di integrità mediante i quali vengono definiti i criteri di integrità dell'applicazione, lo stato di integrità ridotto, l'errore e le dipendenze di integrità.

Se si sviluppa in modo tempestivo un modello di integrità è possibile delineare punti e modalità di errore per cui sono richieste l'identificazione e l'analisi da parte degli sviluppatori di scenari di simulazione nelle fasi di progettazione dell'applicazione. Affinché un modello di integrità funzioni, un servizio deve essere in grado di comunicare la relativa integrità. Deve disporre di una modalità a livello di programmazione per trasmettere informazioni di questo tipo, fornire un'interfaccia per lo stato di integrità in questione da sottoporre a query in modo interattivo, offrire meccanismi (o hook nei meccanismi esistenti) tramite i quali gli amministratori possano monitorare l'integrità dell'applicazione in tempo reale, nonché definire i meccanismi attraverso i quali gli amministratori possano, quando necessario, fornire la soluzione appropriata per il ripristino dello stato di integrità dell'applicazione.

Definire le caratteristiche

Per un determinato servizio o applicazione specifica, è consigliabile eseguire la diagnostica per identificare i punti dati e gli intervalli di valori mediante i quali vengono indicate almeno tre categorie di integrità, cioè integro, con integrità ridotta e non integro. Queste informazioni possono essere utilizzate per automatizzare la riparazione automatica dei servizi.

Definire le interfacce

Con gli stati di integrità definiti, tramite un servizio devono essere esposte le interfacce correlate all'integrità. Tramite queste interfacce vengono fornite le seguenti categorie di operazioni.

  • Creazione dello stato di integrità nei servizi sottoscritti del partner

    Tramite un servizio devono essere create informazioni di integrità nei servizi sottoscritti del partner. Lo stato di integrità deve essere conciso, con diagnostica di base e integrità di livello elevato.

    Tramite il servizio deve essere garantita la possibilità di sottoscrizione di messaggi di integrità per un servizio del partner. Il recapito dei messaggi di integrità può essere eseguito attraverso percorsi appropriati della soluzione. In un percorso potrebbero essere inclusi gli aggiornamenti di stato di integrità sul posto del servizio in una coda recuperabile dai sottoscrittori.

    Un approccio alternativo consiste nel consentire ai sottoscrittori di fornire un endpoint in cui viene esposta un'interfaccia nota di segnalazione dell'integrità. In caso di modifiche alle informazioni di integrità, è possibile creare informazioni nei sottoscrittori in corrispondenza dei relativi endpoint forniti.

  • Esposizione delle interfacce per il recapito dei dati di telemetria

    La telemetria è una tecnologia valida per le operazioni in quanto consente di identificare l'integrità corrente dell'applicazione e/o dei servizi a più livelli. Può inoltre consentire di identificare rapidamente un eventuale evento atipico nell'ambiente. In questo modo è possibile avvalersi di una vista piuttosto granulare del servizio, utile per il personale addetto alle operazioni, per i servizi e per i dashboard del provider di servizi.

    Tra le metriche di telemetria relative alle operazioni si possono includere, ad esempio, la percentuale media di CPU, gli errori, le connessioni e le code per ruoli, servizi e applicazioni composite differenti compilate nei servizi.

    La telemetria specifica dell'applicazione non viene in genere abilitata automaticamente, né monitorata direttamente dalla piattaforma stessa, pertanto deve essere abilitata dal servizio e dall'applicazione.

  • Esposizione delle interfacce per interrogare il servizio per informazioni aggiuntive sulla diagnostica dell'integrità

    Tramite un servizio devono essere idealmente fornite anche interfacce per interrogare le informazioni aggiuntive sulla diagnostica dell'integrità. Tramite i servizi del sottoscrittore, basati sulle informazioni di livello elevato ricevute nello stato di integrità, è possibile richiedere informazioni aggiuntive per determinare lo sviluppo della relativa relazione con il servizio tramite cui vengono forniti i dettagli di integrità.

    In particolare, se lo stato di integrità del servizio non sembra ottimale, grazie alle informazioni aggiuntive si potrebbe consentire la continuazione del servizio in uso o l'esecuzione del failover su un provider alternativo.

  • Esposizione delle interfacce per risolvere l'integrità del servizio a livello di servizio e di applicazione

    Se il consumer di informazioni di integrità è un servizio interno o correlato, è possibile abilitare il servizio per una risoluzione automatica dei problemi noti. Proprio come una medicina per l'essere umano, la comprensione dell'integrità del servizio evolverà nel tempo e, tramite dati integri, sarà possibile giungere a soluzioni differenti.

    Tramite un servizio deve essere esposta un'interfaccia per consentire il recapito di una soluzione di questo tipo. Nella sua forma più semplice, si potrebbe trattare dell'attivazione di un riavvio o della reimpostazione di un servizio per eseguire il failover su dati interni o su un provider di servizi differente.

    La comprensione dell'integrità di un servizio può consentire al provider di servizi di identificare rapidamente l'eventuale stato non integro di un servizio. Le operazioni automatizzate possono offrire soluzioni rapide, coerenti e conformi alle norme per problemi noti, nonché la riparazione automatica del servizio. In questa sezione vengono esaminati più dettagliatamente i diversi aspetti dell'integrità.

La telemetria viene definita come "il processo d'uso di speciali attrezzature per la misurazione di determinati valori (come la pressione, la velocità o la temperatura) e per la trasmissione via radio di tali valori a un altro luogo".

È importante raccogliere i dati di telemetria elaborati dal servizio. La telemetria è solitamente suddivisa in quattro tipi: utente, business, applicazione e infrastruttura.

La telemetria utente si rivolge al comportamento dei singoli utenti. Fornisce informazioni accurate sul comportamento dei singoli utenti e favorisce pertanto la distribuzione di esperienze personalizzate.

La telemetria business contiene dati relativi alle attività commerciali e indicatori di prestazioni chiave (KPI, Key Performance Indicators) relativi a tali attività. Il numero di utenti univoci attivi in un sito, il numero di video visualizzati e così via sono esempi di telemetria business.

La telemetria dell'applicazione contiene dettagli relativi all'integrità, alle prestazioni e all'attività a livello dell'applicazione e dei servizi dipendenti. Ad esempio, la telemetria dell'applicazione può includere dettagli relativi agli account di accesso e alle chiamate dei client di dati, alle eccezioni, alle chiamate API, alle sessioni e così via.

La telemetria dell'infrastruttura contiene dettagli relativi all'integrità dell'infrastruttura di sistema sottostante, ad esempio dati relativi a risorse come CPU, memoria, rete, capacità disponibile e così via.

Quando si stabilisce quali dati si desidera raccogliere e il modo in cui farlo, è importante comprendere il valore e la funzione dei dati.

In primo luogo, si deve determinare se lo scopo dei dati raccolti è quello di fornire informazioni o di avviare un'azione. Il problema principale riguarda la rapidità con cui si deve reagire. I dati di telemetria verranno usati quasi in tempo reale per avviare un'eventuale azione? In alternativa, verranno usati per un report di tendenza su base mensile? La risposta a queste domande costituirà le tecnologie di telemetria e l'approccio telemetrico da usare all'interno dell'architettura.

Successivamente, si deve identificare il tipo di domanda o di domande che si desidera applicare ai dati di telemetria raccolti. Si può scegliere se usare la telemetria per rispondere a domande note oppure a scopo di analisi. Ad esempio, per un'azienda gli indicatori di prestazioni chiave rappresentano risposte a domande note. Tuttavia, un produttore che intendesse analizzare i dati di un dispositivo per individuare modelli che generano errori si inoltrerebbe in un campo sconosciuto. Per questo produttore, gli errori derivano da uno o più elementi del sistema, ma per condurre l'indagine sono necessari dati aggiuntivi.

Quando si usa la telemetria per ottenere informazioni, occorre tenere in considerazione il tempo necessario per conseguire tale risultato. In alcuni casi, la telemetria viene impiegata per rilevare un picco nella lettura di un sensore di un dispositivo caratterizzato da una finestra di secondi o di minuti. In altri casi, si può usare la telemetria per identificare l'incremento su base settimanale dell'uso di un sito Web caratterizzato da una finestra temporale molto più ampia.

Infine, si consideri la quantità di dati che è possibile raccogliere dall'origine di un segnale all'interno dell'intervallo di tempo necessario a ottenere le informazioni desiderate. Si deve conoscere la quantità di dati trasmessi dal segnale sorgente che si desidera raccogliere. Si potrà così determinare il modo migliore per partizionare il segnale e stabilire la combinazione appropriata di calcolo locale e globale.

Un'altra considerazione riguarda la modalità di registrazione della sequenza di eventi nella telemetria. Numerose organizzazioni usano i timestamp per impostazione predefinita. L'uso dei timestamp può però rappresentare un problema, perché gli orologi dei server presentano incoerenze all'interno dello stesso data center e tra data center diversi. Anche se è possibile sincronizzare il tempo a intervalli regolari, esistono prove documentate secondo cui gli orologi dei server sono soggetti a oscillazioni, ossia registrano un progressivo aumento dell'imprecisione. Queste oscillazioni producono modifiche che possono pregiudicare l'efficacia dell'analisi. Per scenari in cui è richiesto un alto livello di precisione, considerare soluzioni alternative, come l'uso di un'implementazione di un orologio vettoriale.

Dopo aver stabilito un approccio telemetrico, si può passare alla caratterizzazione del segnale.

Il segnale può essere classificato come continuo o discreto. I dati degli eventi in tempo reale sono un esempio di segnale continuo. Le voci dei file di log fanno invece parte di un segnale discreto.

Per soddisfare le esigenze richieste dall'approccio che si è adottato, è necessario identificare la quantità di dati contenuta nel segnale. Se le informazioni sono di tipo continuo, sarà necessario impostare una frequenza di campionamento. Se sono di tipo discreto, sarà necessario identificare i record da mantenere o da filtrare.

È inoltre necessario identificare il tipo di accesso. In alcuni casi sarà opportuno eseguire il push dei dati di telemetria, mentre in altri per recuperare i dati sarà necessario eseguire il pull.

In sistemi più evoluti è possibile che le informazioni ottenute dalla telemetria esistente sottoposta a push possano richiedere il ricorso a un'operazione di pull per ottenere informazioni aggiuntive. Ad esempio, se la telemetria sottoposta a push evidenzia un risultato non ottimale, è possibile recuperare altri dati di diagnostica mediante un'operazione di pull.

Tutti i dati raccolti possono essere rilevanti in determinate condizioni, ma non è necessario che tutti i dati di telemetria vengano inviati continuamente. A seconda del tipo di telemetria usato e della quantità di dati richiesti per ottenere informazioni approfondite, è possibile recuperare una quantità inferiore di dati. Si possono generare aggregazioni, campionamenti o subset mediante il calcolo locale e inviare questi dati al servizio. Se i dati ricevuti dalla telemetria standard evidenziano uno stato non ottimale, ad esempio, il servizio può richiedere dati aggiuntivi.

Durante lo sviluppo di una strategia di telemetria è opportuno considerare i criteri più appropriati. La telemetria richiede la disponibilità di una connessione e l'invio di dati tramite tale connessione prevede un costo. Creare criteri che includono il contesto, la connettività e i costi e regolare la telemetria di conseguenza.

I criteri devono tenere conto del contesto dello stato corrente per stabilire quale sia la telemetria più appropriata da inviare. Le informazioni ottenute dai dati di telemetria ricevuti in precedenza e le esigenze aziendali correlate costituiscono il contesto, che contribuisce a organizzare e dare priorità alla raccolta di dati di telemetria.

A seconda del dispositivo usato è possibile disporre di vari tipi di connettività (WiFi, LTE, 4G, 3G e così via) e la stessa connettività può essere variabile. Il tipo di connettività del dispositivo corrente è rilevante per determinare i dati da trasmettere. In scenari in cui la connettività non è affidabile o la velocità di connessione è bassa, grazie ai criteri è possibile assegnare una priorità ai dati di telemetria trasmessi.

La connettività viene spesso fornita a fronte di un costo. I criteri dovranno tenere in considerazione se una connessione è a consumo o meno. Se la connessione è a consumo, i criteri individueranno i relativi costi ed eventualmente i limiti d'uso, se presenti. Molti dispositivi usano diversi tipi di connessioni nel corso della stessa giornata. È possibile assegnare o cancellare la priorità di una telemetria specifica in base ai costi necessari per inviarne i dati.

I dati di telemetria vengono spesso visualizzati da diversi tipi di utenti. Utenti di operazioni e sviluppatori rappresentano due categorie di utenti per i quali è importante poter visualizzare i dati di telemetria. Le esigenze di ciascun tipo di utenti richiedono tuttavia livelli diversi di granularità, come descritto di seguito.

La visualizzazione dello stato delle operazioni di livello elevato e dei dati di telemetria di livello inferiore è importante per il personale addetto alle operazioni. In base ai dati di telemetria verranno probabilmente usate le notifiche automatiche. Gli utenti di operazioni desidereranno tuttavia disporre di un dashboard per visualizzare più facilmente le prestazioni correnti e cronologiche dei servizi.

Per le applicazioni di una certa entità queste informazioni possono contribuire a identificare rapidamente i problemi correnti o a prevedere problemi futuri e possono aiutare gli utenti di operazioni a identificare le cause principali di tali problemi e a valutarne il potenziale impatto.

Diagramma del dashboard delle prestazioni

Figura 10

Nel diagramma sopra indicato relativo a un sito di social networking di grandi dimensioni vengono esaminati la percentuale media di CPU del ruolo API, gli errori API, gli utenti online, le connessioni Web attive, la percentuale di CPU del ruolo Web, gli errori Web, le connessioni hardware Web, le connessioni in pool Web, la coda dell'applicazione Web e le connessioni software Web.

La telemetria e il tipo di report mostrati sopra risultano particolarmente utili nei casi in cui tramite le operazioni sia possibile risolvere gli errori senza modifiche al codice nei servizi stessi. Tra gli esempi di attività eseguibili dalle operazioni sono inclusi la distribuzione di più ruoli e il riciclo delle istanze.

La visualizzazione dei dati di telemetria cronologici e in tempo reale è utile per i seguenti ambiti:

  • Risoluzione dei problemi.

  • Relazioni finali eseguite per problemi di siti live.

  • Formazione di nuovo personale addetto alle operazioni.

Oltre al personale addetto alle operazioni, gli sviluppatori di software sono utenti importanti dei dati di telemetria. È possibile che gli errori non siano associati all'ambiente operativo, bensì al codice dell'applicazione sottostante. Disporre di un dashboard di telemetria per gli sviluppatori consente loro di eseguire l'azione diretta.

Le due schermate seguenti raffigurano un'utilità di esempio creata a questo scopo. Tramite il dashboard vengono forniti dettagli sul numero di errori, sulle categorie interessate dagli errori e su dati specifici correlati a ognuna di queste categorie. Nei dettagli sono inclusi i dati dell'analisi, tra cui i numeri totali di errori, di istanze del ruolo in cui si verificano gli errori e di database con errore.

Diagramma del dashboard

Figura 11

Diagramma del dashboard

Figura 12

Nel caso di siti di grandi dimensioni con milioni di utenti impegnati, si verificheranno i conti errori più elevati e potranno essere perfettamente accettabili. Disporre di un dashboard incentrato sugli sviluppatori tramite cui viene interpretata la telemetria consente di individuare l'effettiva presenza di problemi, se è opportuno impegnarsi nella relativa risoluzione e il punto del codice in cui si verificano.

Vedere anche

Mostra: