Introduction to Microsoft Azure Well Architected Framework in Italian - Session 2 of 6 Introduzione a Microsoft Azure Well Architected Framework in Italiano - Sessione 2 di 6 Modulo 2: affidabilità

1. AZURE WELL-
ARCHITECTED
FRAMEWORK
Sessione 2 di 6

2. ABOUT ME
➤ Rauno De Pasquale, Co-Founder and CTO at Newesis Srl,
constantly trying to reconcile his degree in Philosophy with
a passion for computer science. After almost 18 year at
Deltatre, at the beginning of 2019 he creates Newesis, with
the aim of simplifying the use of the most advanced
services of Cloud platforms even in fields other than sports.
➤ Newesis is a pure technology based, Cloud Native company,
having as a target to support and evolve adoption of
DevOps culture and practices, with particular focus on
Kubernetes as technological platform.
➤ Twitter: @RaunoDepa
➤ Twitter: @newesissrl

3. AZURE WELL-ARCHITECTED FRAMEWORK –
SESSIONE 2 DI 6 - AGENDA
➤ Posizione nel percorso complessivo
➤ Panoramica
➤ Principi
➤ Progettazione
➤ Test
➤ Monitoraggio

4. INTRODUZIONE
Posizione nel percorso

5. AZURE WELL-ARCHITECTED FRAMEWORK –
PERCORSO
➤ I Modulo: introduzione, principi e concetti base
➤ II Modulo: affidabilità
➤ III Modulo: sicurezza
➤ IV Modulo: ottimizzazione dei costi
➤ V Modulo: eccellenza operativa
➤ VI Modulo: efficienza delle prestazioni

6. AFFIDABILITÀ
Panoramica

7. AFFIDABILITÀ - PANORAMICA
➤ L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni presi con i clienti.
➤ Nello sviluppo di applicazioni tradizionali, ci si è concentrati sulla riduzione del tempo medio
tra gli errori (MTBF). L'obiettivo è stato soprattutto quello di evitare l'errore nel sistema.
➤ In cloud computing è necessaria una mentalità diversa, a causa di diversi fattori:
• I sistemi distribuiti sono complessi e un errore in un punto può potenzialmente propagarsi
in tutto il sistema.
• I costi per gli ambienti cloud vengono mantenuti bassi tramite hardware di base, quindi è
necessario che si siano previsti errori hardware occasionali.
• Le applicazioni spesso dipendono da servizi esterni, che possono diventare
temporaneamente non disponibili o limitare gli utenti con volumi elevati.

8. AFFIDABILITÀ - PANORAMICA
➤ Le applicazioni cloud devono essere progettate in modo da prevedere errori occasionali ed
eseguire il ripristino a seguito dell'errore.

9. AFFIDABILITÀ - PANORAMICA
➤ Azure offre numerose funzioni di resilienza già integrate nella piattaforma. Occorre però
conoscere le caratteristiche di ciascun tipo di risorsa e le opzioni disponibili, considerando le
dipendenze interne all’architettura nel suo insieme.

10. AFFIDABILITÀ - PANORAMICA
➤ Malgrado la ridondanza infrastrutturale, è comunque necessario integrare la resilienza
nell'applicazione.
➤ Le strategie di resilienza possono essere applicate a tutti i livelli dell'architettura.
➤ Due tipologie di mitigazione:
• Tattica: ad esempio meccanismi di ripetizione chiamate in caso di errore
• Strategica: ad esempio meccanismi di failover automatico tra aree diverse

11. AFFIDABILITÀ - PANORAMICA
➤ Non tutte le soluzioni necessitano dello stesso livello di affidabilità.
➤ Occorre analizzare i requisiti di business e tenere conto delle condizioni esecutive e
operative del progetto per determinare il giusto livello di affidabilità per ogni soluzione.

12. AFFIDABILITÀ
Principi

13. AFFIDABILITÀ - PRINCIPI
➤ Invece di provare a evitare completamente gli errori, l'obiettivo deve essere quello di ridurre
al minimo gli effetti di un singolo componente in errore.
➤ Dobbiamo fare quattro assunzioni:
• Gli elementi infrastrutturali avranno dei disservizi
• Il software avrà dei difetti
• Gli essere umani faranno errori
• Le modalità di utilizzo saranno imprevedibili
➤ Il framework definito da Microsoft stabilisce una serie di principi.

14. AFFIDABILITÀ - PRINCIPI
➤ Definire e testare gli obiettivi di disponibilità e ripristino
➤ Gli obiettivi di disponibilità, ad esempio i contratti di servizio e gli obiettivi del livello di
servizio (SLO) e gli obiettivi di ripristino, ad esempio gli obiettivi del tempo di ripristino (RTO)
e gli obiettivi del punto di ripristino (RPO), devono essere definiti e testati per garantire che
l'affidabilità dell'applicazione sia allineata ai requisiti aziendali.

15. AFFIDABILITÀ - PRINCIPI
➤ Progettare applicazioni in modo che siano più resistente agli errori
➤ Le architetture di applicazioni resilienti devono essere progettate per il ripristino in modo
corretto da errori in linea con gli obiettivi di affidabilità definiti.

16. AFFIDABILITÀ - PRINCIPI
➤ Assicurarsi che la capacità e i servizi necessari siano disponibili nelle aree di destinazione
➤ I servizi e la capacità di Azure possono variare in base all'area, quindi è importante
comprendere se le aree di destinazione offrono le funzionalità necessarie.

17. AFFIDABILITÀ - PRINCIPI
➤ Pianificare il ripristino di emergenza
➤ Il ripristino di emergenza è il processo di ripristino delle funzionalità dell'applicazione in
seguito a un errore irreversibile. Potrebbe essere accettabile che alcune applicazioni non
siano disponibili o siano parzialmente disponibili con funzionalità ridotte per un periodo di
tempo, mentre altre applicazioni potrebbero non essere in grado di tollerare funzionalità
ridotte.

18. AFFIDABILITÀ - PRINCIPI
➤ Progettare la piattaforma applicativa per soddisfare i requisiti di affidabilità
➤ La progettazione della resilienza e della disponibilità della piattaforma applicativa è
fondamentale per garantire l'affidabilità complessiva delle applicazioni.

19. AFFIDABILITÀ - PRINCIPI
➤ Progettare la piattaforma dati per soddisfare i requisiti di affidabilità
➤ La progettazione della resilienza e della disponibilità della piattaforma dati è fondamentale
per garantire l'affidabilità complessiva delle applicazioni.

20. AFFIDABILITÀ - PRINCIPI
➤ Eseguire il ripristino in base a errori
➤ Le applicazioni resilienti devono essere in grado di eseguire automaticamente il ripristino
dagli errori sfruttando i modelli di codice moderni delle applicazioni cloud.

21. AFFIDABILITÀ - PRINCIPI
➤ Verificare che la rete e la connettività soddisfino i requisiti di affidabilità
➤ L'identificazione e la mitigazione di potenziali colli di bottiglia o punti di guasto di rete
supportano una base affidabile e scalabile su cui i componenti dell'applicazione resilienti
possono comunicare.

22. AFFIDABILITÀ - PRINCIPI
➤ Consentire l'affidabilità in termini di scalabilità e prestazioni
➤ Le applicazioni resilienti devono essere in grado di ridimensionarsi automaticamente in
risposta alla modifica del carico per mantenere la disponibilità delle applicazioni e soddisfare
i requisiti di prestazioni.

23. AFFIDABILITÀ - PRINCIPI
➤ Affrontare i rischi correlati alla sicurezza
➤ L'identificazione e la gestione dei rischi correlati alla sicurezza consentono di ridurre al
minimo i tempi di inattività delle applicazioni e la perdita di dati causati da attacchi e
vulnerabilità.

24. AFFIDABILITÀ - PRINCIPI
➤ Definire, automatizzare e testare i processi operativi
➤ I processi operativi per la distribuzione delle applicazioni, ad esempio il roll forward e il
rollback, devono essere definiti, sufficientemente automatizzati e testati per garantire
l'allineamento con gli obiettivi di affidabilità.

25. AFFIDABILITÀ - PRINCIPI
➤ Testare la tolleranza di errore
➤ I carichi di lavoro delle applicazioni devono essere testati per convalidare l'affidabilità
rispetto agli obiettivi di affidabilità definiti.

26. AFFIDABILITÀ - PRINCIPI
➤ Monitorare e misurare l'integrità dell'applicazione
➤ Il monitoraggio e la misurazione della disponibilità delle applicazioni sono fondamentali per
qualificare l'integrità complessiva dell'applicazione e lo stato di avanzamento verso obiettivi
di affidabilità definiti.

27. AFFIDABILITÀ
Progettazione

28. AFFIDABILITÀ - PROGETTAZIONE
➤ I requisiti di destinazione e non funzionali, ad esempio gli obiettivi di disponibilità e gli
obiettivi di ripristino, consentono di misurare il tempo di attività e il tempo di inattività dei
carichi di lavoro.
➤ Avere obiettivi chiaramente definiti è fondamentale per avere l'obiettivo di lavorare e
misurarsi.
➤ Ciascuna tipologia di risorse Azure ha diverse opzioni in termini di affidabilità. Occorre
verificare non solo gli SLA individuali degli elementi ma saper calcolare il contratto di servizio
composito.

29. AFFIDABILITÀ - PROGETTAZIONE
➤ I contratti di servizio compositi prevedono più servizi che supportano un'applicazione,
ognuno con livelli di disponibilità diversi.
➤ SLA individuali:
• Applicazione Web = 99.95%
• Database SQL = 99.99%
➤ SLA composito:
• 99.95% × 99.99% = 99.94%
➤ La probabilità di errore di ogni servizio è indipendente, un'applicazione che si basa su più
servizi ha più potenziali punti di errore.

30. AFFIDABILITÀ - PROGETTAZIONE
➤ È possibile migliorare il contratto di servizio composito creando percorsi di fallback
indipendenti. Ad esempio, se database SQL non è disponibile, inserire le transazioni in una
coda da elaborare in un secondo momento.
➤ Il contratto di servizio composito totale diventa:
• App Web e (database o coda) = 99.95% × 99.99999% = ~99.95%
➤ La logica dell'applicazione è più complessa, si paga per la coda ed è necessario considerare i
problemi di coerenza dei dati.

31. AFFIDABILITÀ - PROGETTAZIONE
➤ Distribuendo in più aree la soluzione, gestendone l’accesso con un traffic manager, si
possono ottenere livelli di servizio composito più elevati.
➤ Il contratto di servizio composito per una distribuzione multiarea viene calcolato come
segue:
• N è il contratto di servizio composito per l'applicazione distribuita in un'area.
• R è il numero di aree in cui viene distribuita l'applicazione.
➤ La probabilità prevista che l'applicazione non riesca in tutte le aree contemporaneamente è (
(1 − N) ^ R ).

32. AFFIDABILITÀ - PROGETTAZIONE
➤ Distribuzione multi-area (region)

33. AFFIDABILITÀ - PROGETTAZIONE
➤ Disponibilità applicata ai dati
➤ I servizi dati e archiviazione devono essere in esecuzione in una configurazione (SKU) a
disponibilità elevata.
➤ I servizi della piattaforma dati di Azure offrono funzionalità di resilienza per supportare
l'affidabilità delle applicazioni, anche se possono essere applicabili solo a un determinato
SKU.
➤ Diverse tipologie di servizi hanno diverse modalità di distribuzione (copia read-only remota,
failover del ruolo master, soluzioni multi-master).

34. AFFIDABILITÀ - PROGETTAZIONE
➤ I tipi di dati devono essere classificati in base ai requisiti di coerenza dei dati.
➤ Il teorema CAP dimostra che è impossibile per un archivio dati distribuito fornire
simultaneamente più di due garanzie tra:
• Coerenza.
• Disponibilità
• Tolleranza di partizione

35. AFFIDABILITÀ - PROGETTAZIONE
➤ Punti chiave per la progettazione di soluzioni affidabili:
• Distribuzione multi-istanza dell’applicazione (N+1)
• Assicurare la scalabilità orizzontale
• Sfruttare le soluzioni PaaS per la migliore integrazione con la piattaforma Cloud
• Preferire soluzioni multi-zona o multi-area
• Utilizzare servizi di backup e ripristino multi-zona o multi-area

36. AFFIDABILITÀ - PROGETTAZIONE
➤ Calcolo del rischio, del budget di errore e del peso delle dipendenze esterne.

37. AFFIDABILITÀ
Test

38. AFFIDABILITÀ - TEST
➤ Le applicazioni devono essere testate per garantire disponibilità e resilienza.
• Disponibilità: la quantità di tempo in cui un'applicazione viene eseguita in uno stato integro
senza tempi di inattività significativi.
• Resilienza: la velocità con cui un'applicazione viene ripristinata in caso di errore.
➤ Disponibilità e resilienza necessitano di distinti meccanismi di misurazione.

39. AFFIDABILITÀ - TEST
➤ I test regolari devono essere eseguiti come parte di ogni modifica importante e, se possibile,
a intervalli regolari per convalidare soglie, obiettivi e presupposti esistenti.
➤ Anche se la maggior parte dei test deve essere eseguita all'interno degli ambienti di test e di
gestione temporanea, è spesso utile eseguire anche un subset di test nel sistema di
produzione.
➤ Automatizzare i test laddove possibile per garantire un code coverage e una riproducibilità
dei test coerenti.
➤ Automatizzare le attività di test comuni e integrarle nei processi di compilazione e rilascio
(CI/CD Pipelines).

40. AFFIDABILITÀ - TEST
➤ Diverse tipologie di test:
• Performance testing
• Load testing
• Stress testing
• Soak testing
• Fault Injection testing
• Simulation testing

41. AFFIDABILITÀ - TEST
➤ Chaos Engineering
➤ Un modo comune per introdurre il chaos è
inserire deliberatamente elementi che
causano errori nei componenti di sistema.
L'obiettivo è osservare, monitorare,
rispondere e migliorare l'affidabilità del
sistema in circostanze negative.
➤ La progettazione di Chaos accetta l'incertezza
dell'ambiente di produzione e cerca di
prevedere risultati rari, imprevedibili e
dirompenti, in modo da ridurre al minimo
qualsiasi potenziale impatto sui clienti.

42. AFFIDABILITÀ - TEST
➤ Piano di ripristino di emergenza
➤ Includere il processo per contattare il supporto tecnico e per i problemi di escalation.
➤ Scegliere un'architettura di ripristino tra aree per le applicazioni cruciali.
➤ Identificare un responsabile specifico per il piano di ripristino di emergenza che comprende
l'automazione e i test.
➤ Documentare il processo, in particolare i passaggi manuali.
➤ Automatizzare il processo il più possibile.
➤ Stabilire una strategia di backup per tutti i dati di riferimento e transazionali e testare regolarmente
il ripristino del backup.
➤ Configurare correttamente meccanismi di osservabilità e gestione allarmi.
➤ Eseguire il training del personale operativo per eseguire il piano.
➤ Eseguire normali simulazioni di emergenza per convalidare e migliorare il piano.

43. AFFIDABILITÀ - PROGETTAZIONE
➤ Strategie di distribuzione multi-area
➤ Ridistribuzione - l'applicazione viene ridistribuita da zero al momento dell'emergenza.
➤ Warm Spare (attiva/passiva) - viene creato un servizio ospitato secondario in un'area
alternativa e i ruoli vengono distribuiti per garantire la capacità minima; i ruoli non ricevono
tuttavia il traffico di produzione.
➤ Hot Spare (attiva/attiva) - l'applicazione è progettata per ricevere il carico di produzione in
più aree. I servizi cloud di ogni area possono essere configurati per una capacità superiore a
quella richiesta per scopi di ripristino di emergenza.

44. AFFIDABILITÀ
Monitoraggio

45. AFFIDABILITÀ - MONITORAGGIO
➤ Il monitoraggio e la diagnostica sono fondamentali per la disponibilità e la resilienza. Se si
verifica un errore, è necessario sapere che ha avuto esito negativo, quando ha avuto esito
negativo e perché .
➤ Il monitoraggio non corrisponde al rilevamento dei singoli errori ma dello stato effettivo del
sistema nel suo complesso.
➤ Gli allarmi o avvisi sono notifiche dei problemi di integrità del sistema rilevati durante il
monitoraggio.
➤ Gli avvisi offrono valore solo se sono utilizzabili e classificati in modo efficace dai tecnici in
servizio tramite procedure operative definite.

46. AFFIDABILITÀ - MONITORAGGIO
➤ Lo spostamento di mentalità tra monitoraggio tradizionale e osservabilità può essere
riassunto come segue:
• Monitorare servizi/applicazioni non macchine
• Applica monitoraggio Black Box + Monitoraggio White Box
• Raccoglie dati
• Raccoglie più dati
• Correlare i dati
• Cerca anomalie

47. AFFIDABILITÀ - MONITORAGGIO
➤ Ogni sistema di monitoraggio dovrebbe rispondere a due domande: cosa è rotto (sintomo) e
perché (causa)
➤ Si possono definire due tipi di monitoraggio:
• Monitoraggio white-box: ispeziona lo stato interno del servizio di destinazione (metriche
dei componenti dell'applicazione, tracce, log). Concentrati sulle cause.
• Monitoraggio black-box: accede ai sistemi dall'esterno, come un utente reale (sonde
httptcp, risoluzione dns, ping di rete). Orientato ai sintomi. Riconoscimento attivo della
condizione di errore.

48. AFFIDABILITÀ - MONITORAGGIO
➤ I sistemi distribuiti sono difficili da monitorare
➤ Ogni sistema e applicazione può fornire una grande quantità di informazioni sul suo stato
➤ È possibile correlare informazioni diverse dallo stesso sistema
• Tracce che segnalano tempi di risposta più elevati + Metriche che segnalano un utilizzo
elevato della CPU
➤ È possibile correlare informazioni diverse provenienti da sistemi diversi
• Tracce dall'applicazione Web che segnalano un alto tasso di errore + Registri dal sistema di
database che segnalano un'elevata occorrenza di deadlock

49. AFFIDABILITÀ - MONITORAGGIO
➤ Verifica di integrità e saturazione
➤ Azure mette a disposizione meccanismi per l’identificazione dello stato di integrità dei propri
servizi e delle singole risorse.
➤ Azure fornisce indicazioni circa i livelli massimi di utilizzo in varie dimensioni:
• Quote in sottoscrizione e area
• Limiti su attributi di risorse in base al dimensionamento come ad esempio:
➤ Numero di dischi per tipologia di VM
➤ IOPS su singolo volume
➤ DTU per SQL
➤ Unità di richiesta CosmosDB

50. AFFIDABILITÀ - MONITORAGGIO
➤ Le metriche sono una parte centrale di qualsiasi processo di monitoraggio, ma anche quando
hai quelle giuste, sei necessariamente limitato dai vincoli del tempo lineare.
➤ Le persone decidono le metriche in base agli errori che hanno già trovato e risolto in passato.
Ma potrebbero esserci delle incognite sconosciute: fallimenti che non hai mai visto prima, e
quindi che non puoi anticipare.
➤ L’identificazione di modelli e anomalie è un'opzione.

51. AFFIDABILITÀ - MONITORAGGIO
➤ Se le metriche devono essere costantemente monitorate, i log vengono di solito guardati
solo quando le tue metriche mostrano qualcosa di strano che vorresti indagare.
➤ I log sono più specifici e dettagliati delle metriche ed esistono per mostrarti cosa è successo
ad ogni evento.
➤ Avere log comprensibili, interrogabili e completi è una componente significativa di ciò che
separa il sistema osservabile da quello non osservabile.
➤ Occorre adottare standard per la realizzazione di log strutturati e centralizzarne la raccolta e
l’analisi.

52. AFFIDABILITÀ - MONITORAGGIO
➤ La telemetria (traces) è un tipo di registrazione progettato per registrare il flusso
dell'esecuzione di un programma.
➤ In genere, la traccia è più granulare del sistema standard di logging ed è particolarmente
utile per il rilevamento degli errori nei sistemi distribuiti, al punto che questo caso d'uso ha il
proprio nome: tracciamento distribuito.
➤ La telemetria viene spesso utilizzata per rilevare problemi di latenza o scoprire quale dei
molti microservizi non funziona.

53. AFFIDABILITÀ - MONITORAGGIO
➤ I 4 segnali principali – latenza
➤ Il tempo necessario per soddisfare una richiesta. È importante distinguere tra la latenza delle
richieste riuscite e la latenza delle richieste non riuscite. Ad esempio, un errore HTTP 500
attivato a causa della perdita di connessione a un database o altro backend critico potrebbe
essere servito molto rapidamente; tuttavia, poiché un errore HTTP 500 indica una richiesta
non riuscita, il calcolare le risposte 500 nella latenza complessiva potrebbe comportare
calcoli fuorvianti.
➤ D'altra parte, un errore lento è anche peggio di un errore veloce! Pertanto, è importante
tenere traccia della latenza degli errori, anziché limitarsi a filtrare gli errori.

54. AFFIDABILITÀ - MONITORAGGIO
➤ I 4 segnali principali – traffico
➤ Una misura del carico che viene portato sul tuo sistema, misurata in una metrica specifica di
ciascun sistema.
➤ Per un servizio Web, questa misurazione è solitamente costituita da richieste HTTP al
secondo, forse suddivise in base alla natura delle richieste (ad esempio, contenuto statico
rispetto a contenuto dinamico).
➤ Per un sistema di streaming audio, questa misurazione potrebbe concentrarsi sulla velocità
di I/O di rete o su sessioni simultanee.
➤ Per un sistema di archiviazione, questa misurazione potrebbe essere transazioni e letture al
secondo.

55. AFFIDABILITÀ - MONITORAGGIO
➤ I 4 segnali principali – errori
➤ La percentuale di richieste che falliscono, in modo esplicito (ad esempio HTTP 500),
implicitamente (ad esempio, una risposta di successo HTTP 200, ma abbinata al contenuto
sbagliato) o per criterio (ad esempio, "qualsiasi richiesta superiore a un secondo è un
errore").
➤ Laddove i codici di risposta del protocollo non siano sufficienti per esprimere tutte le
condizioni di guasto, potrebbero essere necessari protocolli secondari (interni) per tenere
traccia delle modalità di guasto parziale.

56. AFFIDABILITÀ - MONITORAGGIO
➤ I 4 segnali principali – saturazione
➤ Quanto è "pieno" il tuo servizio.
➤ Una misura di una specifica porzione del sistema, che enfatizza le risorse più vincolate (ad
esempio, in un sistema vincolato dalla memoria, mostra memoria; in un sistema vincolato da
I/O, mostra I/O).
➤ Molti sistemi peggiorano nelle prestazioni prima di raggiungere il 100% di utilizzo, quindi è
essenziale disporre di un obiettivo di utilizzo.

57. AFFIDABILITÀ - MONITORAGGIO
➤ r.e.d pattern - servizi
➤ Richieste / Errori / Durata
➤ Per misurare i servizi, generalmente sistemi basati su richieste
• Richieste: richieste ricevute al secondo
• Errori: percentuale di richieste che hanno restituito un errore
• Durata: tempo di risposta per ciascuna richiesta

58. AFFIDABILITÀ - MONITORAGGIO
➤ u.s.e. pattern - risorse
➤ Utilizzo / Saturazione / Errori
➤ Per misurare componenti dell'infrastruttura
• CPU
• Memoria
• Dischi
• Rete

59. THE END – Q&A ?