REL 10: Come si utilizza l'isolamento dei guasti per proteggere il carico di lavoro?

Le barriere per l'isolamento dei guasti limitano l'effetto di un errore all'interno di un carico di lavoro a un numero limitato di componenti. I componenti al di fuori della barriera non subiscono gli effetti del guasto. Utilizzando più barriere per l'isolamento dei guasti, puoi limitare l'impatto sul carico di lavoro.

Risorse

AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)
Shuffle-sharding: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)
AWS re:Invent 2018: How AWS Minimizes the Blast Radius of Failures (ARC338)
AWS re:Invent 2019: Innovation and operation of the AWS global network infrastructure (NET339)
What is AWS Outposts?
Global Tables: Multi-Region Replication with DynamoDB
AWS Local Zones FAQ
AWS Global Infrastructure
The Amazon Builders' Library: Workload isolation using shuffle-sharding

Best practice:

• Distribuzione del carico di lavoro in diversi luoghi: Distribuisci i dati e le risorse del carico di lavoro su più zone di disponibilità o, se necessario, su diverse regioni AWS. Questi luoghi possono essere diversi a seconda delle necessità.

• Ripristino automatico dei componenti vincolati a una singola posizione: Se i componenti del carico di lavoro possono essere eseguiti solo in una singola zona di disponibilità o in un data center locale, è necessario implementare la capacità di eseguire una ricostruzione completa del carico di lavoro entro gli obiettivi di ripristino definiti.

• Utilizzo di architetture paratie: Come le paratie su una nave, questo modello garantisce che un guasto sia contenuto a un piccolo sottoinsieme di richieste/utenti, in modo che il numero di richieste danneggiate sia limitato e la maggior parte possa continuare senza errori. Le paratie per i dati sono in genere chiamate partizioni o shard, mentre le paratie per i servizi sono note come celle.

Piano di miglioramento

Distribuzione del carico di lavoro in diversi luoghi

Impiego di più zone di disponibilità e regioni AWS: Distribuisci i dati e le risorse del carico di lavoro su più zone di disponibilità o, se necessario, su diverse regioni AWS. Questi luoghi possono essere diversi a seconda delle necessità.

• I servizi regionali sono distribuiti intrinsecamente in zone di disponibilità.
  • Sono inclusi Amazon S3, Amazon DynamoDB e AWS Lambda (quando non è connesso a un VPC)
• Distribuisci il tuo container, istanza e carichi di lavoro basati su funzioni in più zone di disponibilità. Utilizzo di datastore multi-zona, inclusi sistemi di cache: Usa le funzioni di EC2 Auto Scaling, posizionamento di attività ECS, configurazione della funzione AWS Lambda in esecuzione nel tuo VPC, e cluster ElastiCache.
  • Utilizza sottoreti che sono in zone di disponibilità separate nella distribuzione di gruppi Auto Scaling.
    Example: Distributing instances across Availability Zones
    Amazon ECS task placement strategies
    Configuring an AWS Lambda function to access resources in an Amazon VPC
    Choosing Regions and Availability Zones
  • Utilizza sottoreti in zone di disponibilità separate quando distribuisci gruppi Auto Scaling.
    Example: Distributing instances across Availability Zones
  • Utilizza parametri di posizionamento attività ECS, specificando i gruppi di sottorete DB.
    Amazon ECS task placement strategies
  • Utilizza sottoreti in più zone di disponibilità quando configuri una funzione da eseguire nel tuo VPC.
    Configuring an AWS Lambda function to access resources in an Amazon VPC
  • Utilizza più zone di disponibilità con cluster ElastiCache.
    Choosing Regions and Availability Zones

Se il carico di lavoro deve essere distribuito in più regioni, scegli una strategia multi-regione: La maggior parte delle esigenze di affidabilità può essere soddisfatta all'interno di una singola regione AWS utilizzando una strategia a più zone di disponibilità. Quando necessario, utilizza una strategia multi-regione per soddisfare le tue esigenze aziendali.
AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)

• Il backup in un'altra regione AWS può garantire ulteriormente che i dati saranno disponibili quando necessario.
• Alcuni carichi di lavoro hanno requisiti normativi che prevedono l'utilizzo di una strategia multi-regione

Valutazione dell'utilizzo di AWS Outposts per il carico di lavoro: Se il carico di lavoro richiede bassa latenza nel data center locale o ha requisiti di elaborazione dei dati locali. In tal caso esegui l'infrastruttura e i servizi AWS in locale utilizzando AWS Outposts
What is AWS Outposts?

Determinare se le zone locali di AWS ti aiutano a fornire il servizio ai tuoi utenti: Se hai requisiti di bassa latenza, verifica se le zone locali di AWS si trovano vicino ai tuoi utenti. Se sì, utilizzalo per distribuire carichi di lavoro più vicini a tali utenti
AWS Local Zones FAQ

Ripristino automatico dei componenti vincolati a una singola posizione

Implementazione dell'autoriparazione: Distribuisci le tue istanze o container utilizzando, quando possibile, il ridimensionamento automatico. Se non è possibile utilizzare il ridimensionamento automatico, utilizza il ripristino automatico per istanze EC2 o implementa l'automazione di autoriparazione in base agli eventi del ciclo di vita di container Amazon EC2 o ECS.

• Utilizza gruppi Auto Scaling per carichi di lavoro di container e istanze che non richiedono un indirizzo IP di una singola istanza, un indirizzo IP privato, un indirizzo IP elastico o metadati di istanza.
  What Is EC2 Auto Scaling?
  Service automatic scaling
  • È possibile impiegare i dati utente di configurazione del lancio per implementare l'automazione capace di autoriparare la maggior parte dei carichi di lavoro.
• Utilizza il ripristino automatico delle istanze EC2 per carichi di lavoro che richiedono un indirizzo ID di una singola istanza, indirizzo IP privato, indirizzo IP elastico e metadati di istanza.
  Recover your instance.
  • Il ripristino automatico invierà avvisi sullo stato del ripristino a un argomento SNS quando viene rilevato l'errore dell'istanza.
• Utilizza eventi del ciclo di vita di istanze EC2 o eventi ECS per automatizzare l'autoriparazione dove non è possibile utilizzare l'Auto Scaling o il ripristino EC2.
  EC2 Auto Scaling lifecycle hooks
  Amazon ECS events
  • Utilizza gli eventi per invocare l'automazione che riparerà il tuo componente secondo la logica di processo richiesta.

Utilizza il ripristino automatico delle istanze EC2 per carichi di lavoro che richiedono un indirizzo ID di una singola istanza, indirizzo IP privato, indirizzo IP elastico e metadati di istanza.
Recover your instance.

• Il ripristino automatico invierà avvisi sullo stato del ripristino a un argomento SNS quando viene rilevato l'errore dell'istanza.

Utilizza eventi del ciclo di vita di istanze EC2 o eventi ECS per automatizzare l'autoriparazione dove non è possibile utilizzare l'Auto Scaling o il ripristino EC2.
EC2 Auto Scaling lifecycle hooks
Amazon ECS events

• Utilizza gli eventi per invocare l'automazione che riparerà il tuo componente secondo la logica di processo richiesta.

Utilizzo di architetture paratie

Utilizzo di architetture paratie: Come le paratie su una nave, questo modello garantisce che un guasto sia contenuto a un piccolo sottoinsieme di richieste/utenti, in modo che il numero di richieste danneggiate sia limitato e la maggior parte continueranno senza errori. Le paratie per i dati sono in genere chiamate partizioni o shard, mentre le paratie per i servizi sono note come celle
Shuffle-sharding: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)
AWS re:Invent 2018: How AWS Minimizes the Blast Radius of Failures (ARC338)

Valutazione dell'architettura basata su celle per il carico di lavoro: In un'architettura basata su celle, ogni cella è un'istanza completa e indipendente del servizio e ha una dimensione massima fissa. Con l'aumentare del carico, i carichi di lavoro aumentano aggiungendo più celle. Una chiave di partizione viene utilizzata sul traffico in entrata per determinare quale cella elaborerà la richiesta. Qualsiasi guasto è contenuto nella singola cella in cui si verifica, in modo che il numero di richieste danneggiate sia limitato man mano che le altre celle continuano senza errori. È importante identificare la chiave di partizione corretta per ridurre al minimo le interazioni tra celle ed evitare la necessità di coinvolgere servizi di mappatura complessi in ogni richiesta. I servizi che richiedono una mappatura complessa finiscono semplicemente per spostare il problema ai servizi di mappatura, mentre i servizi che richiedono interazioni tra celle riducono l'indipendenza delle celle (e quindi i presunti miglioramenti della disponibilità che ne deriverebbero).

• Nel suo post del blog AWS, Colm MacCarthaigh spiega in che modo Amazon Route 53 utilizza il concetto di sharding casuale per isolare le richieste dei clienti negli shard
  Shuffle Sharding: Massive and Magical Fault Isolation