Come gestire la migrazione del DB utilizzando gli strumenti di distribuzione AWS

Question

Amazon Web Services offre numerosi strumenti di distribuzione e gestione continui come Elastic Beanstalk, OpsWorks, Cloud Formation e Code Deploy a seconda delle esigenze. L'idea di base è quella di facilitare la distribuzione del codice e l'aggiornamento senza tempi di fermo. Aiutano anche a gestire la migliore pratica architettonica utilizzando le risorse AWS.

Per semplicità consente di assumere un'architettura di base in cui si dispone di una struttura a 2 lacrime; una raccolta di server di applicazioni dietro un bilanciatore del carico e quindi un livello di persistenza che utilizza un DB RDS multizona.

L'effettivo aggiornamento del codice su una flotta di istanze (server delle applicazioni) è facile da comprendere. Per una panoramica molto semplicistica, il servizio AWS aggiorna ciascun nodo a sua volta distribuendo le connessioni in modo che l'istanza in questione non venga utilizzata.

Tuttavia, non riesco a capire come vengono gestiti gli aggiornamenti DB. Supponiamo che stiamo passando dalla versione 1.0.0 alla 2.0.0 di un'applicazione e che è necessario modificare la struttura del DB. Normalmente useresti uno script o una libreria come Flyway per eseguire l'aggiornamento. Tuttavia, se esiste una flotta di server da aggiornare, esiste un punto in cui entrambe le applicazioni 1.0.0 e 2.0.0 esistono all'interno della flotta, ciascuna delle quali richiede una struttura DB diversa.

Ho bisogno di capire come questo sia effettivamente raggiunto (alto livello) per sapere qual è il modo migliore/tempo di eseguire la migrazione del DB. Suppongo che ci siano un paio di modi in cui potrebbero raggiungere questo obiettivo, ma sto cercando di capire come possono farlo e consentire a 1.0.0 e 2.0.0 di mantenere i dati senza perdita.

Se migrano la struttura DB con il primo aggiornamento del nodo di app e allo stesso tempo creano una versione memorizzata nella cache della 1.0.0. Gli utenti connessi all'app 1.0 persistono utilizzando la versione cache del DB e gli utenti connessi all'app 2.0.0 rimangono nel nuovo DB migrato. Una volta migrati tutti i nodi dell'app, i dati memorizzati nella cache vengono uniti nel DB.

Sembra improbabile che possano farlo perché l'unione sarebbe piuttosto complessa ma non riesco a vedere un altro modo. Qualsiasi suggerimento/aiuto sarebbe apprezzato.

Answer 1

Questo è un problema comune che si verifica quando l'infrastruttura dell'applicazione entra in più nodi dell'applicazione. Nei tempi passati, è possibile portare l'applicazione offline per "finestre di manutenzione" durante le quali è possibile:

• Sostituire l'applicazione con una pagina "Manutenzione sistema, torna presto".
• eseguire migrazioni database (schema e/o dati)
• Distribuire codice nuova applicazione
• applicazione Put nuovo online

Nel 2015, e davvero per diversi anni questo approccio non è accettabile. I tuoi utenti si aspettano un funzionamento 24 ore su 24, 7 giorni su 7, quindi deve esserci un modo migliore. Certo che c'è, la risposta è una serie di modelli per Database Refactorings.

Il concetto di base da tenere sempre a mente è di assumere è necessario mantenere due versioni concorrenti della vostra applicazione, e non ci può essere nessuna rottura cambia tra queste due versioni. Ciò significa che hai un'applicazione corrente (v1.0.0) attualmente in produzione e (v2.0.0) che è prevista la distribuzione. Entrambe queste versioni devono funzionare sullo stesso schema. Una volta che la v2.0.0 è stata completamente distribuita su tutti i server delle applicazioni, è possibile sviluppare la v3.0.0 che consente di completare eventuali modifiche al database finale.