Qual è una buona strategia per mantenere il mio sito online quando S3 è offline?

Qual è una buona strategia per mantenere il mio sito online quando S3 è offline?

Se S3 US East 1 non è in linea, come devo configurare / strutturare la mia app per evitare che il mio intero sito sia offline?

Quali sono le migliori strategie per diversificare in questo tipo di situazione?

Nel marzo 2015, Amazon AWS ha annunciato di supportare la replica S3 in tutte le regioni. Quando una determinata area di S3 diventa offline, è possibile pubblicare file dal proprio mirror in un'altra area.

^{fonte: https://aws.amazon.com/blogs/aws/new-cross-region-replication-for-amazon-s3/}

La pratica di mantenere la tua infrastruttura online passando a un'altra regione è complessa, ma S3 è un componente relativamente piccolo e semplice. Netflix ha un ottimo articolo sulla sua esperienza con Chaos Gorilla.

Questo vale anche per il degrado del servizio, come una maggiore latenza. Non solo quando un servizio su cui fai affidamento è completamente offline. Anche Netflix ha pubblicato un articolo su questo: Chaos Engineering aggiornato .

Quello che stai chiedendo è, in sostanza, l'alta disponibilità. Per rendere un sistema altamente disponibile, sono necessarie tre cose:

1. Elimina i singoli punti di errore
2. Un meccanismo per passare da un endpoint a un altro
3. Un modo per rilevare guasti

Elimina i singoli punti di errore

Nel caso di S3, il punto 1 viene affrontato, come Evgeny ha sottolineato, mediante la replica S3 tra regioni .

La replica, tuttavia, non è istantanea e ti consigliamo di verificare se desideri rendere consapevole o meno la replica della tua applicazione. In caso di interruzione, è possibile che qualcosa che è stato scritto nel bucket di origine non sia ancora stato (non replicato) nel bucket di destinazione. Devi pensare a come l'applicazione gestirà tale scenario. Dipende molto dal tipo di dati, da ciò che viene fatto e (potenzialmente) dagli utenti finali o dalle aspettative della direzione.

Un meccanismo per passare da un endpoint a un altro

Per S3, ciò significa che in caso di interruzione, l'applicazione deve interrompere la lettura e la scrittura da / verso il bucket A e utilizzare invece il bucket B.

Come raggiungere questo, per quanto ne so, dipende da te per ora. Alcuni altri servizi AWS offrono fallimenti completamente trasparenti, ma al momento non sono a conoscenza di una cosa del genere per S3.

Ci sono vari modi per raggiungere questo obiettivo. Un esempio è l'utilizzo di un proxy che instraderà il traffico al bucket appropriato. Durante un'interruzione, è necessario aggiornare / modificare il proxy per indirizzare il traffico verso un bucket non interessato dall'interruzione. Un altro esempio potrebbe essere quello di rendere dinamica la configurazione dell'applicazione e archiviarla in un archivio valori-chiave. Se l'applicazione legge l'archivio KV per le proprietà aggiornate abbastanza spesso, puoi passare da dove leggi e scrivi (Spring Cloud ha il supporto per un listener "EnvironmentChange", per esempio).

Un modo per rilevare guasti

Bene, quello è facile, penso. Basta impostare un ciclo di scrittura + lettura e avvisare non appena qualcosa non va bene :)

Note di chiusura

• Se l'applicazione sta scrivendo nel bucket, è necessario pensare a cosa succederebbe in caso di failover. Tutte le scritture sono arrivate al bucket di destinazione (e puoi dirlo)? Puoi consentire le scritture al bucket di destinazione (rendendolo il nuovo "principale")? Un'attenta pianificazione eviterà scenari di aggiornamenti spaccati o persi.
• A seconda dello SLA, è possibile che i punti 2 e 3 siano automatizzati o automatici. Ciò richiede una pianificazione, strumenti e test aggiuntivi, ma script ben scritti reagiranno sempre più rapidamente e in modi più prevedibili rispetto a quelli umani (i fallimenti hanno anche la fastidiosa abitudine di accadere nel cuore della notte quando l'intervento umano è qualcosa di pericoloso.
• Vale la pena ricordare che anche la replica tra regioni non elimina completamente i singoli punti di errore. Certo, se una regione scende, sei coperto. Ma cosa succede se si verifica un'interruzione di AWS negli Stati Uniti? Azure ha avuto un'interruzione parziale ma globale l'anno scorso e anche una nel 2014.