Approfondimento sulle esigenze in termini di disponibilità

Di solito si pensa alla disponibilità di un'applicazione come a un singolo obiettivo per l'applicazione nel suo insieme. Tuttavia, a un'analisi più attenta, spesso scopriamo che alcuni aspetti di un'applicazione o di un servizio presentano requisiti di disponibilità diversi. Ad esempio, alcuni sistemi potrebbero dare priorità alla capacità di ricevere e archiviare nuovi dati prima del recupero dei dati esistenti. Altri sistemi danno la priorità alle operazioni in tempo reale rispetto a quelle che modificano la configurazione o l'ambiente di un sistema. I servizi potrebbero avere requisiti di disponibilità molto elevati durante determinate ore del giorno, ma possono tollerare periodi di interruzione molto più lunghi al di fuori di questi orari. Questi sono alcuni dei modi in cui è possibile scomporre una singola applicazione in parti costitutive e valutarne i requisiti in termini di disponibilità. Il vantaggio di questo approccio è concentrare gli sforzi (e le spese) sulla disponibilità in base alle esigenze specifiche, piuttosto che progettare l'intero sistema in base ai requisiti più rigidi.

All'interno di AWS, dividiamo di solito i servizi in "piano dati" e "piano di controllo (control-plane)". Il piano dati è responsabile della fornitura del servizio in tempo reale mentre i piani di controllo (control-plane) consentono di configurare l'ambiente. Ad esempio, le istanze Amazon EC2, i database Amazon RDS e le operazioni di lettura/scrittura su tabelle di Amazon DynamoDB sono tutte operazioni sul piano dati. Al contrario, l'avvio di nuove istanze EC2 o database RDS o l'aggiunta o la modifica di metadati delle tabelle di DynamoDB sono tutte considerate operazioni sul piano di controllo (control-plane). Sebbene elevati livelli di disponibilità siano importanti per tutte queste funzionalità, i piani dati hanno in genere obiettivi di progettazione di disponibilità più elevati rispetto ai piani di controllo (control-plane). Pertanto, i carichi di lavoro con requisiti di alta disponibilità dovrebbero evitare dipendenze di runtime su operazioni sul piano di controllo (control-plane).

Molti clienti AWS adottano un approccio analogo alla valutazione critica delle loro applicazioni e all'identificazione di componenti secondari con diverse esigenze di disponibilità. Gli obiettivi di progettazione della disponibilità vengono quindi adattati ai diversi aspetti e si adottano le opportune iniziative di lavoro per progettare il sistema. AWS vanta una grande un'esperienza nella progettazione di applicazioni con una serie di obiettivi di progettazione della disponibilità, inclusi servizi con una disponibilità del 99,999% o superiore. AWS I Solution Architects (SA) possono aiutarti a effettuare una progettazione adeguata ai tuoi obiettivi di disponibilità. Il coinvolgimento di AWS nelle prime fasi del processo di progettazione migliora la nostra capacità di aiutarti a raggiungere i tuoi obiettivi di disponibilità. La pianificazione della disponibilità non viene eseguita solo prima dell'avvio del carico di lavoro, ma in modo continuo per perfezionare la progettazione man mano che acquisisci esperienza operativa, impari da eventi reali e superi guasti di diversi tipi. È quindi possibile applicare l'iniziativa di lavoro opportuna per migliorare l'implementazione.

Le esigenze di disponibilità necessarie per un carico di lavoro devono essere allineate a esigenze e criticità aziendali. Definendo innanzitutto il framework di criticità aziendale con RTO, RPO e disponibilità definiti, è possibile valutare ciascun carico di lavoro. Tale approccio richiede che le persone coinvolte nell'implementazione del carico di lavoro conoscano framework e impatto del loro carico di lavoro sulle esigenze aziendali.