Servizi zonali

Availability Zone Independence (AZI) consente di AWS offrire servizi zonali, come Amazon EC2 e Amazon EBS. Un servizio zonale è un servizio che offre la possibilità di specificare in quale zona di disponibilità vengono distribuite le risorse. Questi servizi operano in modo indipendente in ogni zona di disponibilità all'interno di una regione e, cosa ancora più importante, falliscono indipendentemente anche in ogni zona di disponibilità. Ciò significa che i componenti di un servizio in una zona di disponibilità non dipendono dai componenti di altre zone di disponibilità. Possiamo farlo perché un servizio zonale ha piani dati zonali. In alcuni casi, come nel caso di EC2, il servizio include anche piani di controllo zonali per operazioni allineate a zone, come l'avvio di un'istanza EC2. Per questi servizi, fornisce AWS anche un endpoint del piano di controllo regionale per facilitare l'interazione con il servizio. Il piano di controllo regionale offre inoltre funzionalità con ambito regionale e funge da livello di aggregazione e routing in aggiunta ai piani di controllo zonali. Ciò è illustrato nella figura seguente.

Un servizio zonale con piani di controllo e piani dati isolati zonalmente

Le zone di disponibilità offrono ai clienti la possibilità di gestire carichi di lavoro di produzione con maggiore disponibilità, tolleranza ai guasti e scalabilità rispetto a quanto sarebbe possibile con un singolo data center. Quando un carico di lavoro utilizza più zone di disponibilità, i clienti sono meglio isolati e protetti dai problemi che influiscono sull'infrastruttura fisica di una singola zona di disponibilità. Questo aiuta i clienti a creare servizi ridondanti tra le zone di disponibilità e, se progettati correttamente, a rimanere operativi anche in caso di guasti in una zona di disponibilità. I clienti possono sfruttare AZI per creare carichi di lavoro resilienti e altamente disponibili. L'implementazione di AZI nell'architettura consente di ripristinare rapidamente un errore isolato in una zona di disponibilità, poiché le risorse in una zona di disponibilità riducono al minimo o eliminano l'interazione con le risorse in altre zone di disponibilità. Questo aiuta a rimuovere le dipendenze tra zone di disponibilità, semplificando così l'evacuazione delle zone di disponibilità. Consulta Advanced Multi-AZ Resilience Patterns per maggiori dettagli sulla creazione di meccanismi di evacuazione delle zone di disponibilità. Inoltre, è possibile sfruttare ulteriormente le zone di disponibilità seguendo alcune delle stesse best practice AWS utilizzate per i propri servizi, ad esempio implementando le modifiche a una sola zona di disponibilità alla volta o rimuovendo una zona di disponibilità dal servizio se una modifica in quella zona di disponibilità va male.

La stabilità statica è anche un concetto importante per le architetture Multi-Availability Zone. Una delle modalità di errore da pianificare con le architetture Multi-Availability Zone è la perdita di una zona di disponibilità, che può comportare la perdita della capacità di una zona di disponibilità. Se non è stata predisposta una capacità sufficiente per gestire la perdita di una zona di disponibilità, la capacità residua potrebbe essere sovraccaricata dal carico corrente. Inoltre, sarà necessario fare affidamento sui piani di controllo dei servizi zonali utilizzati per sostituire la capacità persa, che può essere meno affidabile di un design staticamente stabile. In questo caso, predisporre in anticipo una capacità aggiuntiva sufficiente può aiutarvi a mantenere la stabilità statica in caso di perdita di un dominio di errore, come una zona di disponibilità, grazie alla possibilità di continuare le normali operazioni senza la necessità di modifiche dinamiche.

Puoi scegliere di utilizzare un gruppo di istanze EC2 con scalabilità automatica distribuite su più zone di disponibilità per scalare dinamicamente in entrata e in uscita, in base alle esigenze del tuo carico di lavoro. La scalabilità automatica è ideale per i cambiamenti graduali di utilizzo che si verificano nell'arco di minuti o decine di minuti. Tuttavia, il lancio di nuove istanze EC2 richiede tempo, soprattutto se le istanze richiedono il bootstrap (ad esempio l'installazione di agenti, file binari delle applicazioni o file di configurazione). Durante questo periodo, la capacità residua potrebbe essere sopraffatta dal carico attuale. Inoltre, l'implementazione di nuove istanze tramite la scalabilità automatica si basa sul piano di controllo EC2. Ciò presenta un compromesso: per essere staticamente stabili alla perdita di una singola zona di disponibilità, è necessario predisporre un numero sufficiente di istanze EC2 nelle altre zone di disponibilità per gestire il carico che è stato spostato dalla zona di disponibilità compromessa, invece di affidarsi alla scalabilità automatica per il provisioning di nuove istanze. Tuttavia, il pre-provisioning di capacità aggiuntiva può comportare costi aggiuntivi.

Ad esempio, durante il normale funzionamento, supponiamo che il carico di lavoro richieda sei istanze per servire il traffico dei clienti in tre zone di disponibilità. Per garantire la stabilità statica in caso di guasto di una singola zona di disponibilità, è necessario implementare tre istanze in ciascuna zona di disponibilità, per un totale di nove. Se in una singola zona di disponibilità si guastasse un numero di istanze pari a sei, ne resterebbero comunque sei e saresti in grado di continuare a servire il traffico dei clienti senza dover fornire e configurare nuove istanze in caso di guasto. Il raggiungimento della stabilità statica della capacità EC2 comporta costi aggiuntivi, poiché, in questo caso, si utilizzano istanze aggiuntive del 50%. Non tutti i servizi in cui è possibile effettuare il pre-provisioning delle risorse comportano costi aggiuntivi, come il pre-provisioning di un bucket S3 o di un utente. Dovrai valutare qualsiasi compromesso derivante dall'implementazione della stabilità statica rispetto al rischio di superare il tempo di ripristino desiderato per il tuo carico di lavoro.

AWS Local Zones and Outposts avvicinano il piano dati di AWS servizi selezionati agli utenti finali. I piani di controllo per questi servizi risiedono nella regione madre. L'istanza Local Zone o Outposts avrà dipendenze dal piano di controllo per i servizi zonali come EC2 ed EBS sulla zona di disponibilità in cui hai creato la tua sottorete Local Zone o Outposts. Inoltre dipenderanno dai piani di controllo regionali per i servizi regionali come Elastic Load Balancing (ELB), i gruppi di sicurezza e il piano di controllo Kubernetes gestito da Amazon Elastic Kubernetes Service (Amazon EKS) (se usi EKS). Per ulteriori informazioni specifiche su Outposts, consulta la documentazione e le domande frequenti sull'assistenza e la manutenzione. Implementa la stabilità statica quando usi Local Zones o Outposts per migliorare la resilienza al fine di controllare i problemi o le interruzioni del piano nella connettività di rete verso la regione madre.