Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Progettazione di sistemi distribuiti ad alta disponibilità su AWS
Le sezioni precedenti hanno riguardato principalmente la disponibilità teorica dei carichi di lavoro e i risultati che possono ottenere. Si tratta di un insieme importante di concetti da tenere a mente quando si creano sistemi distribuiti. Ti aiuteranno a orientare il processo di selezione delle dipendenze e a come implementare la ridondanza.
Abbiamo anche esaminato la relazione e MTBF la MTTD MTTR disponibilità. Questa sezione introdurrà una guida pratica basata sulla teoria precedente. In breve, i carichi di lavoro ingegneristici per l'alta disponibilità mirano ad aumentare MTBF e diminuire il MTTRMTTD.
Sebbene l'eliminazione di tutti i guasti sarebbe l'ideale, non è realistico. Nei sistemi distribuiti di grandi dimensioni con dipendenze fortemente impilate, si verificheranno dei guasti. «Tutto fallisce sempre» (vedi Werner Vogels, Amazon.comCTO, [10 lezioni da 10 anni di Amazon Web Services](https://www.allthingsdistributed.com/2016/03/10-lessons-from-10-years-of-aws.html).) e «non puoi legiferare contro i fallimenti [quindi] concentrati su un rilevamento e una risposta rapidi». (vedi Chris Pinkham, membro fondatore del EC2 team Amazon, [ARC335Designing for failure: Architecting resilient](https://d1.awsstatic.com/events/reinvent/2019/REPEAT_1_Designing_for_failure_Architecting_resilient_systems_on_AWS_ARC335-R1.pdf) systems on) AWS
Ciò significa che spesso non si ha il controllo sull'eventualità che si verifichi un guasto. Ciò che puoi controllare è la rapidità con cui rilevi l'errore e fai qualcosa al riguardo. Pertanto, sebbene l'aumento MTBF sia ancora una componente importante dell'elevata disponibilità, i cambiamenti più importanti che i clienti possono controllare sono la riduzione MTTD e la riduzioneMTTR.
**Topics**
+ [Ridurre MTTD](reducing-mttd.md)
+ [Ridurre MTTR](reducing-mttr.md)
+ [In aumento MTBF](increasing-mtbf.md)
# Ridurre MTTD
Ridurre la probabilità MTTD di un guasto significa scoprirlo il più rapidamente possibile. L'abbreviazione si MTTD basa sull'osservabilità o sul modo in cui hai strumentato il tuo carico di lavoro per comprenderne lo stato. I clienti devono monitorare le metriche relative all'*esperienza dei clienti* nei sottosistemi critici del carico di lavoro per identificare in modo proattivo quando si verifica un problema (consulta l'[Appendice 1) MTTD e MTTR](appendix-1-mttd-and-mttr-critical-metrics.md) le metriche critiche per ulteriori informazioni su queste metriche. ). I clienti possono utilizzare [Amazon CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) per *creare* canarini che monitorano le APIs tue console e misurare in modo proattivo l'esperienza utente. Esistono diversi altri meccanismi di controllo dello stato che possono essere utilizzati per ridurli al minimoMTTD, come i controlli di integrità di [Elastic Load Balancing (ELB), i controlli di integrità](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-add-elb-healthcheck.html) di [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-types.html) e altro ancora. (Vedi [Amazon Builders' Library — Implementazione](https://aws.amazon.com/builders-library/implementing-health-checks/) dei controlli sanitari.)
Il monitoraggio deve inoltre essere in grado di rilevare guasti parziali sia del sistema nel suo insieme che nei singoli sottosistemi. [Le metriche di disponibilità, guasto e latenza devono utilizzare la dimensionalità dei limiti di isolamento dei guasti come dimensioni metriche. CloudWatch ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Dimension) Ad esempio, si consideri una singola EC2 istanza che fa parte di un'architettura basata su celle, in use1-az1 AZ, nella regione us-east-1, che fa parte dell'aggiornamento API del carico di lavoro che fa parte del relativo sottosistema del piano di controllo. Quando il server inserisce le proprie metriche, può utilizzare l'id dell'istanza, AZ, la regione, il nome e il nome del sottosistema come dimensioni. API Ciò consente di garantire l'osservabilità e di impostare allarmi su ciascuna di queste dimensioni per rilevare i guasti.
# Ridurre MTTR
Dopo l'individuazione di un guasto, il MTTR tempo restante è dedicato all'effettiva riparazione o mitigazione dell'impatto. Per riparare o mitigare un guasto, è necessario sapere cosa c'è che non va. Esistono due gruppi chiave di metriche che forniscono informazioni dettagliate durante questa fase: 1/ metriche di *Impact Assessment* e 2/ Metriche *Operational* Health. Il primo gruppo indica l'ambito dell'impatto durante un guasto, misurando il numero o la percentuale di clienti, risorse o carichi di lavoro interessati. Il secondo gruppo aiuta a identificare il *motivo* dell'impatto. Dopo aver scoperto il motivo, gli operatori e l'automazione possono rispondere e risolvere il problema. Per ulteriori informazioni su queste metriche[, consulta l'Appendice 1 MTTD e le metriche MTTR critiche](appendix-1-mttd-and-mttr-critical-metrics.md).
**Regola 9**
L'osservabilità e la strumentazione sono fondamentali per ridurre e. MTTD MTTR
## Percorso per aggirare il fallimento
L'approccio più rapido per mitigare l'impatto consiste nell'utilizzare sottosistemi fail-fast che evitino il guasto. Questo approccio utilizza la ridondanza per ridurre il problema MTTR spostando rapidamente il lavoro di un sottosistema guasto su un sottosistema di riserva. La ridondanza può variare da processi software, a EC2 istanze, a più o meno regioni. AZs
I sottosistemi di riserva possono MTTR ridurla quasi a zero. Il tempo di ripristino è solo quello necessario per reindirizzare il lavoro alla riserva di stand-by. Ciò avviene spesso con una latenza minima e consente di completare il lavoro entro i limiti definitiSLA, mantenendo la disponibilità del sistema. MTTRsCiò produce ritardi percepiti come lievi, forse anche impercettibili, piuttosto che periodi prolungati di indisponibilità.
Ad esempio, se il servizio utilizza EC2 istanze basate su un Application Load Balancer ALB (), è possibile configurare i controlli di integrità a intervalli di soli cinque secondi e richiedere solo due controlli di integrità non riusciti prima che un oggetto venga contrassegnato come non integro. Ciò significa che entro 10 secondi è possibile rilevare un errore e interrompere l'invio di traffico all'host non funzionante. In questo caso, MTTR è effettivamente la stessa, MTTD poiché non appena viene rilevato l'errore, anche questo viene mitigato.
Questo è ciò che i carichi di lavoro *ad alta disponibilità* o *disponibilità continua stanno cercando* di ottenere. Vogliamo ovviare rapidamente ai guasti del carico di lavoro rilevando rapidamente i sottosistemi guasti, contrassegnandoli come guasti, interrompendo l'invio di traffico verso di essi e inviando invece il traffico a un sottosistema ridondante.
Tieni presente che l'utilizzo di questo tipo di meccanismo rapido rende il carico di lavoro molto sensibile agli errori transitori. Nell'esempio fornito, assicurati che i controlli sullo stato del bilanciamento del carico eseguano controlli *superficiali* o attivi [https://aws.amazon.com/builders-library/implementing-health-checks/](https://aws.amazon.com/builders-library/implementing-health-checks/), senza testare le dipendenze o i flussi di lavoro (spesso denominati controlli *approfonditi* dello stato). Ciò contribuirà a prevenire la sostituzione non necessaria delle istanze in caso di errori transitori che influiscono sul carico di lavoro.
L'osservabilità e la capacità di rilevare i guasti nei sottosistemi sono fondamentali per il corretto instradamento del sistema. È necessario conoscere la portata dell'impatto in modo che le risorse interessate possano essere contrassegnate come non integre o guaste e disattivate e messe fuori servizio in modo da poter essere instradate. Ad esempio, se una singola AZ subisce un'interruzione parziale del servizio, la strumentazione dovrà essere in grado di identificare l'esistenza di un problema localizzato in AZ che riguarda il routing di tutte le risorse in quella zona fino al ripristino.
La capacità di aggirare i guasti potrebbe inoltre richiedere strumenti aggiuntivi a seconda dell'ambiente. Utilizzando l'esempio precedente con EC2 le istanze che si basano su unaALB, immaginate che le istanze di una zona possano superare i controlli sanitari locali, ma che un problema isolato della AZ impedisca loro di connettersi al database in un'altra AZ. In questo caso, i controlli di integrità del bilanciamento del carico non metteranno fuori servizio tali istanze. Sarebbe necessario un meccanismo automatizzato diverso per [rimuovere l'AZ dal sistema di bilanciamento del carico](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-subnets.html) o costringere le istanze a non superare i controlli di integrità, il che dipende dall'identificazione dell'ambito di impatto di una AZ. Per i carichi di lavoro che non utilizzano un sistema di bilanciamento del carico, sarebbe necessario un metodo simile per evitare che le risorse di una zona specifica accettino unità di lavoro o sottraggano del tutto capacità alla zona AZ.
In alcuni casi, il trasferimento del lavoro verso un sottosistema ridondante non può essere automatizzato, come il failover di un database primario su un database secondario in cui la tecnologia non prevede la scelta del proprio leader. [Si tratta di uno scenario comune per le architetture multiregionali.AWS](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/) Poiché questi tipi di failover richiedono una certa quantità di downtime per essere eseguiti, non possono essere immediatamente annullati e lasciano il carico di lavoro senza ridondanza per un periodo di tempo, è importante avere un operatore umano nel processo decisionale.
I carichi di lavoro che possono adottare un modello di coerenza meno rigoroso possono ridursi utilizzando l'automazione del failover multiregionale per aggirare i guasti. MTTRs Funzionalità come la [replica interregionale di Amazon S3 o le [tabelle globali](https://aws.amazon.com/dynamodb/global-tables/) di Amazon](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html) DynamoDB forniscono funzionalità multiregionali attraverso una replica alla fine coerente. Inoltre, l'utilizzo di un modello di coerenza rilassato è utile se consideriamo il teorema. CAP Durante i guasti di rete che influiscono sulla connettività ai sottosistemi stateful, se il carico di lavoro preferisce la disponibilità alla coerenza, può comunque fornire risposte prive di errori, un altro modo per aggirare il problema.
Il routing in caso di guasto può essere implementato con due strategie diverse. La prima strategia consiste nell'implementare la stabilità statica predisponendo risorse sufficienti per gestire il carico completo del sottosistema guasto. Può trattarsi di una singola EC2 istanza o di un'intera AZ di capacità. Il tentativo di fornire nuove risorse durante un errore aumenta MTTR e aggiunge una dipendenza da un piano di controllo nel percorso di ripristino. Tuttavia, comporta un costo aggiuntivo.
La seconda strategia consiste nell'instradare parte del traffico dal sottosistema guasto ad altri sottosistemi e [caricare il traffico in eccesso](https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload) che non può essere gestito dalla capacità residua. Durante questo periodo di degrado, è possibile aumentare le nuove risorse per sostituire la capacità guasta. Questo approccio è più lungo MTTR e crea una dipendenza da un piano di controllo, ma costa meno in caso di capacità inutilizzata e in standby.
## Ritorno a uno stato di buono stato conosciuto
Un altro approccio comune per la mitigazione durante la riparazione consiste nel riportare il carico di lavoro al precedente buono stato noto. Se una modifica recente potrebbe aver causato l'errore, ripristinare tale modifica è un modo per tornare allo stato precedente.
In altri casi, l'errore potrebbe essere stato causato da condizioni transitorie, nel qual caso il riavvio del carico di lavoro potrebbe mitigare l'impatto. Esaminiamo entrambi questi scenari.
Durante un'implementazione, la riduzione al minimo dell'energia MTTR si basa sull'osservabilità MTTD e sull'automazione. Il processo di implementazione deve monitorare costantemente il carico di lavoro per verificare l'introduzione di un aumento dei tassi di errore, di una maggiore latenza o di anomalie. Una volta riconosciuti, dovrebbe arrestare il processo di distribuzione.
Esistono varie [strategie di implementazione](https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/deployment-strategies.html), come le implementazioni sul posto, le implementazioni blu/verdi e le implementazioni continue. Ognuno di questi potrebbe utilizzare un meccanismo diverso per tornare a uno stato di buono stato riconosciuto. Può tornare automaticamente allo stato precedente, riportare il traffico all'ambiente blu o richiedere un intervento manuale.
CloudFormation [offre la possibilità di eseguire automaticamente il rollback](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-rollback-triggers.html) come parte delle operazioni di creazione e aggiornamento dello stack, così come fa. [AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployments-rollback-and-redeploy.html#deployments-rollback-and-redeploy-automatic-rollbacks) CodeDeploy supporta anche implementazioni blu/green e rotative.
Per sfruttare queste funzionalità e ridurre al minimo le tueMTTR, prendi in considerazione l'automazione di tutta l'infrastruttura e le implementazioni del codice tramite questi servizi. Negli scenari in cui non è possibile utilizzare questi servizi, prendi in considerazione l'implementazione del [modello Saga AWS Step Functions per ripristinare](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/implement-the-serverless-saga-pattern-by-using-aws-step-functions.html) le distribuzioni non riuscite.
Quando si considera *il riavvio*, esistono diversi approcci. Questi vanno dal riavvio di un server, l'operazione più lunga, al riavvio di un thread, l'operazione più breve. Ecco una tabella che descrive alcuni degli approcci di riavvio e i tempi approssimativi di completamento (rappresentativi della differenza di ordini di grandezza, non sono esatti).
| Meccanismo di ripristino degli errori | Stimato MTTR |
| --- | --- |
| Avvia e configura un nuovo server virtuale | 15 minuti |
| Ridistribuisci il software | 10 minuti |
| Riavviare il server | 5 minuti |
| Riavvia o avvia il contenitore | 2 secondi |
| Invoca una nuova funzione serverless | 100 ms |
| Processo di riavvio | 10 ms |
| Riavvia il thread | 10 μs |
Esaminando la tabella, ci sono alcuni chiari vantaggi derivanti dall'uso di contenitori e funzioni serverless (come [AWS Lambda](https://aws.amazon.com/lambda/)). MTTR Sono ordini MTTR di grandezza più rapidi rispetto al riavvio di una macchina virtuale o al lancio di una nuova macchina virtuale. Tuttavia, anche l'utilizzo dell'isolamento dei guasti tramite la modularità del software è vantaggioso. Se è possibile contenere gli errori di un singolo processo o thread, il ripristino da tale errore è molto più rapido rispetto al riavvio di un contenitore o di un server.
Come approccio generale al ripristino, è possibile passare dal basso verso l'alto: 1/Restart, 2/Reboot, 3/Re-image/Redeploy, 4/Replace. Tuttavia, una volta che si arriva alla fase di riavvio, l'instradamento in caso di guasto è in genere un approccio più rapido (in genere richiede al massimo 3-4 minuti). Quindi, per mitigare più rapidamente l'impatto dopo un tentativo di riavvio, aggira l'errore e poi, in background, continua il processo di ripristino per ripristinare la capacità del carico di lavoro.
**Regola 10**
Concentrati sulla mitigazione degli impatti, non sulla risoluzione dei problemi. Riprendi il percorso più rapido per tornare alla normale operatività.
## Diagnosi dell'errore
Parte del processo di riparazione dopo il rilevamento è il periodo di diagnosi. Questo è il periodo di tempo in cui gli operatori cercano di determinare cosa c'è che non va. Questo processo potrebbe comportare l'interrogazione dei log, la revisione delle metriche di Operational Health o l'accesso agli host per la risoluzione dei problemi. Tutte queste azioni richiedono tempo, quindi la creazione di strumenti e runbook per velocizzarle può contribuire anche a ridurle. MTTR
## Runbook e automazione
Analogamente, dopo aver determinato cosa non va e quale linea di condotta consentirà di riparare il carico di lavoro, gli operatori in genere devono eseguire una serie di passaggi per eseguire questa operazione. Ad esempio, dopo un errore, il modo più rapido per riparare il carico di lavoro potrebbe essere riavviarlo, operazione che può comportare più passaggi ordinati. L'utilizzo di un runbook che automatizzi questi passaggi o fornisca istruzioni specifiche a un operatore velocizzerà il processo e contribuirà a ridurre il rischio di azioni involontarie.
# In aumento MTBF
L'ultimo componente per migliorare la disponibilità è l'aumento diMTBF. Ciò può applicarsi sia al software che ai AWS servizi utilizzati per eseguirlo.
## Aumento del sistema distribuito MTBF
Un modo per aumentare MTBF è ridurre i difetti del software. Esistono vari modi per eseguire questa operazione. I clienti possono utilizzare strumenti come [Amazon CodeGuru Reviewer](https://aws.amazon.com/codeguru/) per trovare e correggere errori comuni. È inoltre necessario eseguire revisioni complete del codice tra pari, test unitari, test di integrazione, test di regressione e test di carico sul software prima che venga distribuito in produzione. L'aumento della copertura del codice nei test contribuirà a garantire che vengano testati anche i percorsi di esecuzione del codice non comuni.
L'implementazione di modifiche minori può anche aiutare a prevenire risultati imprevisti riducendo la complessità delle modifiche. Ogni attività offre l'opportunità di identificare e correggere i difetti prima che possano essere invocati.
Un altro approccio per prevenire i guasti è costituito dai [test regolari](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html). L'implementazione di un programma di ingegneria del caos può aiutare a verificare gli errori del carico di lavoro, a convalidare le procedure di ripristino e a individuare e correggere le modalità di errore prima che si verifichino in produzione. I clienti possono utilizzare [AWS Fault Injection Simulator](https://aws.amazon.com/fis/) come parte del loro set di strumenti per esperimenti di ingegneria del caos.
La tolleranza ai guasti è un altro modo per prevenire i guasti in un sistema distribuito. Moduli fail-fast, nuovi tentativi con backoff e jitter esponenziali, transazioni e idempotenza sono tutte tecniche che contribuiscono a rendere i carichi di lavoro tolleranti ai guasti.
Le transazioni sono un gruppo di operazioni che aderiscono alle proprietà. ACID Essi sono i seguenti:
+ **Atomicità**: o tutte le azioni si verificano o nessuna di esse accadrà.
+ **Coerenza**: ogni transazione lascia il carico di lavoro in uno stato valido.
+ **Isolamento**: le transazioni eseguite contemporaneamente lasciano il carico di lavoro nello stesso stato come se fossero state eseguite in sequenza.
+ **Durabilità**: una volta completata la transazione, tutti i suoi effetti vengono preservati anche in caso di errore del carico di lavoro.
I nuovi tentativi con [backoff e jitter esponenziali](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/) consentono di superare i guasti transitori causati da Heisenbug, sovraccarico o altre condizioni. Quando le transazioni sono idempotenti, possono essere ritentate più volte senza effetti collaterali.
Se consideriamo l'effetto di un Heisenbug su una configurazione hardware tollerante ai guasti, non saremmo affatto preoccupati, poiché la probabilità che l'Heisenbug compaia sia sul sottosistema primario che su quello ridondante è infinitesimale. (Vedi [Jim Gray, "Perché i computer si fermano e cosa si può](https://pages.cs.wisc.edu/~remzi/Classes/739/Fall2018/Papers/gray85-easy.pdf) fare al riguardo? «, giugno 1985, Tandem Technical Report 85.7.) Nei sistemi distribuiti, vogliamo ottenere gli stessi risultati con il nostro software.
Quando viene richiamato un Heisenbug, è fondamentale che il software rilevi rapidamente l'operazione errata e fallisca in modo che possa essere riprovato. Ciò si ottiene attraverso una programmazione difensiva e la convalida degli input, dei risultati intermedi e dell'output. Inoltre, i processi sono isolati e non condividono lo stato con altri processi.
Questo approccio modulare garantisce che l'ambito di impatto in caso di guasto sia limitato. I processi falliscono indipendentemente. Quando un processo fallisce, il software deve utilizzare delle «coppie di processi» per riprovare a eseguire il lavoro, il che significa che un nuovo processo può assumere il funzionamento di un processo fallito. Per mantenere l'affidabilità e l'integrità del carico di lavoro, ogni operazione deve essere trattata come una transazione. ACID
Ciò consente il fallimento di un processo senza alterare lo stato del carico di lavoro, interrompendo la transazione e ripristinando le modifiche apportate. Ciò consente al processo di ripristino di ritentare la transazione da uno stato riconosciuto valido e di riavviarla correttamente. Questo è il modo in cui il software può essere tollerante ai guasti nei confronti di Heisenbugs.
Tuttavia, non dovresti mirare a rendere il software tollerante ai guasti nei confronti di Bohrbugs. Questi difetti devono essere individuati e rimossi prima che il carico di lavoro entri in produzione, poiché nessun livello di ridondanza porterà mai a risultati corretti. (Vedi Jim Gray, "[Perché i computer si fermano e cosa si può fare](https://www.hpl.hp.com/techreports/tandem/TR-85.7.pdf) al riguardo? «, giugno 1985, Tandem Technical Report 85.7.)
L'ultimo modo per aumentare MTBF è ridurre la portata dell'impatto derivante da un guasto. L'utilizzo [dell'isolamento dei guasti](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html) mediante la modularizzazione per creare contenitori di guasti è un modo fondamentale per farlo, come illustrato in precedenza in *Tolleranza agli errori e isolamento dei guasti*. La riduzione del tasso di errore migliora la disponibilità. AWS utilizza tecniche come la suddivisione dei servizi in piani di controllo e piani dati, [l'indipendenza dalla zona di disponibilità](https://aws.amazon.com/builders-library/static-stability-using-availability-zones) (AZI), l'[isolamento regionale](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/), [le architetture basate su celle](https://www.youtube.com/watch?v=swQbA4zub20) e lo [shuffle-sharding](https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding) per fornire l'isolamento dai guasti. Questi sono modelli che possono essere utilizzati anche dai clienti. AWS
Ad esempio, esaminiamo uno scenario in cui un carico di lavoro ha collocato i clienti in diversi contenitori di guasto della sua infrastruttura che servivano al massimo il 5% del totale dei clienti. In uno di questi contenitori di errore si verifica un evento che ha aumentato la latenza oltre il timeout del client per il 10% delle richieste. Durante questo evento, per il 95% dei clienti, il servizio era disponibile al 100%. Per il restante 5%, il servizio sembrava disponibile al 90%. Ciò si traduce in una disponibilità di 1 − (5% *o* *f* *c* *u* *s* *t* *o* *m* *e* *r* *s* × 10% *o* *f* *t* *h* *e* *i* *r *r** *e* *q* *u* *e* *s *t* *s**) = 99,5% anziché il 10% delle richieste non riuscite per il 100% dei clienti (con una disponibilità del 90%).
**Regola 11**
L'isolamento dei guasti riduce la portata dell'impatto e aumenta il carico MTBF di lavoro riducendo il tasso di guasto complessivo.
## Aumento della dipendenza MTBF
Il primo metodo per aumentare la AWS dipendenza MTBF consiste nell'utilizzare l'isolamento dei [guasti](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html). Molti AWS servizi offrono un livello di isolamento in una AZ, il che significa che un guasto in una AZ non influisce sul servizio in un'altra AZ.
L'utilizzo di istanze ridondanti in più EC2 istanze AZs aumenta la disponibilità del sottosistema. AZIoffre una funzionalità di risparmio all'interno di una singola regione, che consente di aumentare la disponibilità dei servizi. AZI
Tuttavia, non tutti i AWS servizi funzionano a livello di AZ. Molti altri offrono l'isolamento regionale. In questo caso, se la disponibilità prevista del servizio regionale non supporta la disponibilità complessiva richiesta per il carico di lavoro, potresti prendere in considerazione un approccio multiregionale. Ogni regione offre un'istanza isolata del servizio, equivalente a sparing.
Esistono vari servizi che aiutano a semplificare la creazione di un servizio multiregionale. Per esempio:
+ [Database globale Amazon Aurora](https://aws.amazon.com/rds/aurora/global-database/)
+ [Tabelle globali Amazon DynamoDB](https://aws.amazon.com/dynamodb/global-tables/)
+ [Amazon ElastiCache (RedisOSS) — Datastore globale](https://aws.amazon.com/elasticache/redis/global-datastore/)
+ [AWS Acceleratore globale](https://aws.amazon.com/global-accelerator/)
+ [Replica tra regioni Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html)
+ [Controller di ripristino delle applicazioni Amazon Route 53](https://aws.amazon.com/route53/application-recovery-controller/)
Questo documento non approfondisce le strategie di creazione di carichi di lavoro multiregionali, ma è necessario valutare i vantaggi in termini di disponibilità delle architetture multiregionali con i costi aggiuntivi, la complessità e le pratiche operative necessarie per raggiungere gli obiettivi di disponibilità desiderati.
Il metodo successivo per aumentare la dipendenza consiste nel progettare il carico di lavoro in modo che MTBF sia staticamente stabile. Ad esempio, hai un carico di lavoro che serve informazioni sul prodotto. Quando i tuoi clienti richiedono un prodotto, il tuo servizio invia una richiesta a un servizio di metadati esterno per recuperare i dettagli del prodotto. Quindi il carico di lavoro restituisce tutte queste informazioni all'utente.
Tuttavia, se il servizio di metadati non è disponibile, le richieste effettuate dai clienti hanno esito negativo. Puoi invece estrarre o inviare localmente i metadati in modo asincrono al tuo servizio in modo asincrono per utilizzarli per rispondere alle richieste. In questo modo si elimina la chiamata sincrona al servizio di metadati dal percorso critico.
Inoltre, poiché il servizio è ancora disponibile anche quando il servizio di metadati non lo è, puoi rimuoverlo come dipendenza nel calcolo della disponibilità. Questo esempio si basa sul presupposto che i metadati non vengano modificati frequentemente e che la pubblicazione di metadati obsoleti sia preferibile all'esito negativo della richiesta. Un altro esempio simile è [serve-stale](https://www.rfc-editor.org/rfc/rfc8767) for DNS che consente di conservare i dati nella cache oltre la TTL scadenza e di utilizzarli per le risposte quando una risposta aggiornata non è prontamente disponibile.
L'ultimo metodo per aumentare la dipendenza consiste nel ridurre la portata dell'impatto MTBF derivante da un errore. Come accennato in precedenza, il fallimento non è un evento binario, ma vi sono diversi gradi di fallimento. Questo è l'effetto della modularizzazione; l'errore è limitato solo alle richieste o agli utenti serviti da quel contenitore.
Ciò si traduce in un minor numero di errori durante un evento, il che in ultima analisi aumenta la disponibilità del carico di lavoro complessivo limitando l'ambito dell'impatto.
## Riduzione delle fonti di impatto comuni
Nel 1985, Jim Gray scoprì, durante uno studio presso Tandem Computers, che il fallimento era causato principalmente da due fattori: il software e le operazioni. (Vedi Jim Gray, "[Perché i computer si fermano e cosa si può fare al riguardo](https://www.hpl.hp.com/techreports/tandem/TR-85.7.pdf)? «, giugno 1985, Tandem Technical Report 85.7.) Anche dopo 36 anni, questo continua ad essere vero. Nonostante i progressi tecnologici, non esiste una soluzione semplice a questi problemi e le principali fonti di fallimento non sono cambiate. La risoluzione dei guasti nel software è stata discussa all'inizio di questa sezione, quindi l'attenzione sarà rivolta alle operazioni e alla riduzione della frequenza dei guasti.
### Stabilità rispetto alle funzionalità
Se facciamo riferimento al grafico dei tassi di errore per software e hardware nella sezione[Disponibilità del sistema distribuito](distributed-system-availability.md), possiamo notare che i difetti vengono aggiunti in ogni versione del software. Ciò significa che qualsiasi modifica al carico di lavoro comporta un aumento del rischio di fallimento. Queste modifiche sono in genere cose come nuove funzionalità, che ne forniscono un corollario. Una maggiore disponibilità dei carichi di lavoro favorirà la stabilità rispetto alle nuove funzionalità. Pertanto, uno dei modi più semplici per migliorare la disponibilità consiste nell'implementare meno spesso o fornire meno funzionalità. I carichi di lavoro che vengono implementati più frequentemente avranno intrinsecamente una disponibilità inferiore rispetto a quelli che non lo fanno. Tuttavia, i carichi di lavoro che non aggiungono funzionalità non tengono il passo con la domanda dei clienti e possono diventare meno utili nel tempo.
Quindi, come possiamo continuare a innovare e rilasciare funzionalità in modo sicuro? La risposta è la standardizzazione. Qual è il modo corretto di implementazione? Come si ordinano le distribuzioni? Quali sono gli standard per i test? Quanto tempo aspetti tra una fase e l'altra? I vostri test unitari coprono una parte sufficiente del codice software? Si tratta di domande a cui la standardizzazione può rispondere e prevenire problemi causati da fattori come il mancato test di carico, il salto delle fasi di implementazione o l'implementazione troppo rapida su troppi host.
Il modo in cui si implementa la standardizzazione avviene attraverso l'automazione. Riduce la possibilità di errori umani e consente ai computer di fare ciò in cui sono bravi, ovvero fare la stessa cosa più e più volte nello stesso modo ogni volta. Il modo per unire standardizzazione e automazione consiste nel fissare degli obiettivi. Obiettivi come l'assenza di modifiche manuali, l'accesso all'host solo tramite sistemi di autorizzazione contingente, la stesura di test di carico per tutti API e così via. L'eccellenza operativa è una norma culturale che può richiedere cambiamenti sostanziali. Stabilire e monitorare le prestazioni rispetto a un obiettivo aiuta a promuovere un cambiamento culturale che avrà un ampio impatto sulla disponibilità del carico di lavoro. Il pilastro [AWS Well-Architected Operational Excellence fornisce best practice complete per l'eccellenza operativa](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html).
### Sicurezza degli operatori
L'altro fattore importante che contribuisce agli eventi operativi che determinano il fallimento sono le persone. Gli esseri umani commettono errori. Potrebbero utilizzare le credenziali sbagliate, immettere il comando sbagliato, premere Invio troppo presto o perdere un passaggio fondamentale. L'esecuzione di azioni manuali comporta costantemente errori, con conseguente fallimento.
Una delle cause principali degli errori degli operatori sono le interfacce utente confuse, poco intuitive o incoerenti. Jim Gray ha anche osservato nel suo studio del 1985 che «le interfacce che richiedono informazioni all'operatore o gli chiedono di eseguire alcune funzioni devono essere semplici, coerenti e tolleranti ai guasti dell'operatore». (Vedi Jim Gray, "[Perché i computer si fermano e cosa si può fare](https://www.hpl.hp.com/techreports/tandem/TR-85.7.pdf) al riguardo? «, giugno 1985, Tandem Technical Report 85.7.) Questa intuizione continua ad essere vera oggi. Negli ultimi tre decenni in tutto il settore ci sono numerosi esempi in cui un'interfaccia utente confusa o complessa, la mancanza di conferme o istruzioni o anche solo un linguaggio umano ostile hanno indotto un operatore a fare la cosa sbagliata.
**Regola 12**
Fai in modo che gli operatori facciano facilmente la cosa giusta.
### Prevenzione del sovraccarico
L'ultimo fattore comune che contribuisce all'impatto sono i vostri clienti, gli utenti effettivi del vostro carico di lavoro. I carichi di lavoro efficaci tendono a essere utilizzati spesso, ma a volte tale utilizzo supera la capacità di scalabilità del carico di lavoro. Ci sono molte cose che possono succedere, i dischi possono riempirsi, i pool di thread potrebbero esaurirsi, la larghezza di banda della rete potrebbe essere saturata o si possono raggiungere i limiti di connessione al database.
Non esiste un metodo infallibile per eliminarli, ma il monitoraggio proattivo della capacità e dell'utilizzo tramite le metriche di Operational Health fornirà avvisi tempestivi quando potrebbero verificarsi questi guasti. Tecniche come la riduzione del [carico, [gli interruttori automatici](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-interactions-in-a-distributed-system-to-mitigate-or-withstand-failures.html) e i](https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload) nuovi [tentativi con backoff e jitter esponenziali possono contribuire a ridurre al minimo l'impatto e aumentare la percentuale di successo, ma queste](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/) situazioni rappresentano comunque un fallimento. La scalabilità automatizzata basata su metriche di Operational Health può aiutare a ridurre la frequenza dei guasti dovuti al sovraccarico, ma potrebbe non essere in grado di rispondere abbastanza rapidamente ai cambiamenti di utilizzo.
Se è necessario garantire la disponibilità continua della capacità per i clienti, è necessario scendere a compromessi in termini di disponibilità e costi. Un modo per garantire che la mancanza di capacità non porti all'indisponibilità è fornire a ciascun cliente una quota e garantire che la capacità del carico di lavoro sia scalata in modo da fornire il 100% delle quote assegnate. Quando i clienti superano la loro quota, vengono limitati, il che non è un problema e non influisce sulla disponibilità. Dovrai inoltre monitorare attentamente la tua base clienti e prevedere l'utilizzo futuro per mantenere una capacità sufficiente. Ciò garantisce che il carico di lavoro non sia ricondotto a scenari di errore dovuti a un consumo eccessivo da parte dei clienti.
+ [Amazon Builders' Library: utilizzo del load shedding per evitare il sovraccarico](https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload/)
+ [Amazon Builders' Library: equità nei sistemi multi-tenant](https://aws.amazon.com/builders-library/fairness-in-multi-tenant-systems)
Ad esempio, esaminiamo un carico di lavoro che fornisce un servizio di storage. Ogni server del carico di lavoro può supportare 100 download al secondo, ai clienti viene fornita una quota di 200 download al secondo e i clienti sono 500. Per poter supportare questo volume di clienti, il servizio deve fornire una capacità di 100.000 download al secondo, il che richiede 1.000 server. Se un cliente supera la propria quota, viene limitato, il che garantisce una capacità sufficiente per tutti gli altri clienti. Questo è un semplice esempio di un modo per evitare il sovraccarico senza scartare le unità di lavoro.