Fase 2: progettazione e implementazione

Nella fase precedente, avete definito i vostri obiettivi di resilienza. Ora, nella fase di progettazione e implementazione, si prevedono le modalità di guasto e si identificano le scelte di progettazione. Utilizzate gli obiettivi che vi siete prefissati nella fase precedente per guidare le vostre scelte di progettazione.

Utilizzate i limiti di isolamento dei AWS guasti

In Cloud AWS, un limite di isolamento dei guasti è un limite come una zona di disponibilità Regione AWS, un piano di controllo o un piano dati che limita l'effetto di un guasto e aiuta a migliorare la resilienza dei carichi di lavoro. Per raggiungere gli obiettivi di resilienza in un'unica soluzione Regione AWS, concentratevi sull'evitare singoli punti di errore nelle vostre architetture. Se una zona di disponibilità diventa non disponibile, l'impatto si riduce al minimo.

Le startup dovrebbero utilizzare i servizi regionali laddove possibile. AWS gestisce l'elevata disponibilità distribuendo applicazioni e dati su più zone di disponibilità per questi servizi. Ad esempio, Amazon Simple Storage Service (Amazon S3) Simple Storage Service (Amazon S3) è un servizio regionale che distribuisce richieste e dati su più zone di disponibilità. È progettato per il ripristino automatico in seguito a un errore nella zona di disponibilità. L'utente interagisce solo con l'endpoint regionale del servizio.

Se non puoi utilizzare i servizi regionali nella tua progettazione, utilizza i servizi zonali AWS gestiti. AWS i servizi zonali gestiti consentono di distribuire le applicazioni in più zone di disponibilità, garantendo un'elevata disponibilità. AWS offre funzionalità di resilienza integrate con questi servizi, ad esempio un'opzione con un solo clic per distribuire le applicazioni su più zone di disponibilità, reindirizzare il traffico da zone di disponibilità compromesse, gestire i guasti hardware sottostanti e automatizzare i backup dei dati. Ad esempio, Amazon Relational Database Service (Amazon RDS) è un servizio zonale che supporta una configurazione di cluster Multi-AZ che, in caso di guasto, esegue automaticamente il failover su un'istanza di database in standby in un'altra zona di disponibilità.

Per i servizi zonali che non sono completamente gestiti da AWS, è necessario utilizzare le risorse Elastic Load Balancing e Amazon Auto EC2 Scaling per distribuire le applicazioni su più zone di disponibilità. Per i carichi di lavoro di produzione, distribuisci le tue applicazioni su due zone di disponibilità. Per i carichi di lavoro critici rivolti ai clienti, distribuisci l'applicazione su tre zone di disponibilità, per una maggiore disponibilità (HA).

È inoltre necessario utilizzare più limiti di isolamento dei guasti Account AWS come limiti aggiuntivi per separare le risorse di produzione dalle risorse di sviluppo e gestione temporanea. Ciò offre a sviluppatori e ingegneri una maggiore agilità per modificare le risorse, le autorizzazioni AWS Identity and Access Management (IAM) e le autorizzazioni delle risorse, senza influire accidentalmente sui carichi di lavoro di produzione.

Definisci una strategia di disaster recovery

Dal punto di vista del disaster recovery (DR), una strategia di backup e ripristino con ripristino rapido è adeguata per soddisfare gli obiettivi di resilienza fissati nella fase precedente. I backup proteggono dagli scenari di errore più comuni, come il danneggiamento dei dati e l'implementazione di codici errati. È consigliabile utilizzarli AWS Backupper automatizzare centralmente la protezione dei dati nel cloud e in Servizi AWS locale. È necessario creare un runbook per ripristinare o ricreare tutti i componenti del carico di lavoro e aggiornare le dipendenze. È importante includere tutte le procedure di DR, inclusi failover e failback, nel runbook.

Definire una strategia di implementazione

Adottare una pipeline completa di integrazione continua e distribuzione continua (CI/CD) pipeline adds complexity during the early stages of a startup. Start by building infrastructure as code (IaC) and use pipelines to deploy it. This sets a foundation to adopt a complete continuous integration and continuous delivery (CI/CD) man mano che l'organizzazione cresce.

Utilizza le funzionalità di distribuzione canary o blu/green per implementare nuove versioni delle applicazioni. Una distribuzione canaria rilascia una versione lentamente e in modo incrementale. Quando sei sicuro, distribuisci la nuova versione e sostituisci la versione corrente nella sua interezza. Una strategia di distribuzione blu/verde consiste nella creazione di due ambienti distinti ma identici e nell'esecuzione della versione corrente dell'applicazione in un ambiente (blu) e la nuova versione dell'applicazione nell'altro ambiente (verde). Ciò consente ripristini rapidi con un impatto minimo.

Conserva tutto il codice dell'applicazione, le configurazioni e IaC in un repository gestito e controllato dalla versione. Quando possibile, utilizza le funzionalità di controllo delle versioni integrate durante la distribuzione di servizi gestiti, come il controllo delle versioni di Amazon S3.

Crea dipendenze morbide

Se l'applicazione ha una dipendenza da terze parti, qualsiasi problema relativo alla dipendenza può compromettere la capacità di operare o scalare come previsto. Ove possibile, riduci queste dipendenze esterne rigide, in particolare per i carichi di lavoro con scalabilità automatica. Quando create un prodotto per lanciarlo rapidamente sul mercato, potreste utilizzare vari strumenti e componenti open source e di terze parti. Per queste dipendenze, progetta il tuo software con una modalità fail-safe predefinita o un interruttore automatico. L'applicazione può utilizzare risorse alternative o funzionare con funzionalità ridotte anziché fallire completamente.