Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Migrazione online verso Amazon Keyspaces: strategie e best practice
Se devi mantenere la disponibilità delle applicazioni durante una migrazione da Apache Cassandra ad Amazon Keyspaces, puoi preparare una strategia di migrazione online personalizzata implementando i componenti chiave discussi in questo argomento. Seguendo queste best practice per le migrazioni online, puoi garantire che la disponibilità e la read-after-write coerenza delle applicazioni siano mantenute durante l'intero processo di migrazione, riducendo al minimo l'impatto sugli utenti.
Quando si progetta una strategia di migrazione online da Apache Cassandra ad Amazon Keyspaces, è necessario considerare i seguenti passaggi chiave.
1. **Scrittura di nuovi dati**
+ **Proxy ZDM Dual Write per la migrazione di Amazon Keyspaces**: utilizza lo ZDM Dual Write Proxy disponibile su [Github per eseguire la migrazione senza downtime da Apache Cassandra](https://github.com/aws-samples/amazon-keyspaces-examples/blob/main/migration/online/zdm-proxy/README.md) ad Amazon Keyspaces. Il proxy ZDM esegue due scritture senza la necessità di rifattorizzare le applicazioni esistenti ed esegue due letture per la convalida delle query.
+ Scritture doppie delle applicazioni: è possibile implementare la doppia scrittura nell'applicazione utilizzando le librerie e i driver client Cassandra esistenti. Designate un database come leader e l'altro come seguace. Gli errori di scrittura nel database dei follower vengono registrati in una [coda di lettere morte (](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html)DLQ) per l'analisi.
+ Doppia scrittura a livello di messaggistica: in alternativa, puoi configurare la tua piattaforma di messaggistica esistente per inviare scritture sia a Cassandra che ad Amazon Keyspaces utilizzando un consumatore aggiuntivo. Ciò crea alla fine viste coerenti su entrambi i database.
1. **Migrazione dei dati storici**
+ Copiare dati storici: puoi migrare i dati storici da Cassandra ad Amazon Keyspaces utilizzando AWS Glue i nostri script di estrazione, trasformazione e caricamento (ETL) personalizzati. Gestisci la risoluzione dei conflitti tra due scritture e carichi di massa utilizzando tecniche come transazioni leggere o timestamp.
+ Utilizzo Time-To-Live (TTL): per periodi di conservazione dei dati più brevi, puoi utilizzare TTL sia in Cassandra che in Amazon Keyspaces per evitare di caricare dati storici non necessari. Man mano che i vecchi dati scadono in Cassandra e i nuovi dati vengono scritti tramite doppia scrittura, Amazon Keyspaces alla fine recupera il ritardo.
1. **Convalida dei dati**
+ Doppie letture: implementa letture doppie da entrambi i database Cassandra (primario) e Amazon Keyspaces (secondario), confrontando i risultati in modo asincrono. Le differenze vengono registrate o inviate a un DLQ.
+ Letture di esempio: utilizzate le funzioni λ per campionare e confrontare periodicamente i dati su entrambi i sistemi, registrando eventuali discrepanze su un DLQ.
1. **Migrazione dell'applicazione**
+ Strategia blue-green: cambia la tua applicazione per trattare Amazon Keyspaces come principale e Cassandra come archivio dati secondario in un unico passaggio. Monitora le prestazioni ed esegui il rollback in caso di problemi.
+ Implementazione Canary: distribuisci gradualmente la migrazione prima a un sottoinsieme di utenti, aumentando in modo incrementale il traffico verso Amazon Keyspaces come principale fino alla completa migrazione.
1. **Smantellamento di Cassandra**
Una volta completata la migrazione dell'applicazione ad Amazon Keyspaces e convalidata la coerenza dei dati, puoi pianificare la disattivazione del cluster Cassandra in base alle politiche di conservazione dei dati.
Pianificando una strategia di migrazione online con questi componenti, puoi passare senza problemi al servizio Amazon Keyspaces completamente gestito con tempi di inattività o interruzioni minimi. Le seguenti sezioni approfondiscono ogni componente in modo più dettagliato.
**Topics**
+ [Scrittura di nuovi dati durante una migrazione online](migration-online-dw.md)
+ [Caricamento di dati storici durante una migrazione online](migration-online-historical.md)
+ [Convalida della coerenza dei dati durante una migrazione online](migration-online-validation.md)
+ [Migrazione dell'applicazione durante una migrazione online](migration-online-app-migration.md)
+ [Disattivazione di Cassandra dopo una migrazione online](migration-online-decommission.md)
# Scrittura di nuovi dati durante una migrazione online
Il primo passo di un piano di migrazione online consiste nell'assicurare che tutti i nuovi dati scritti dall'applicazione siano archiviati in entrambi i database, nel cluster Cassandra esistente e in Amazon Keyspaces. L'obiettivo è fornire una visione coerente tra i due archivi di dati. È possibile farlo applicando tutte le nuove scritture a entrambi i database. Per implementare la doppia scrittura, considera una delle tre opzioni seguenti.
+ **Proxy ZDM Dual Write per la migrazione di Amazon Keyspaces**: utilizzando il proxy ZDM per Amazon Keyspaces disponibile [su Github, puoi migrare i carichi di lavoro di Apache Cassandra su](https://github.com/aws-samples/amazon-keyspaces-examples/blob/main/migration/online/zdm-proxy/README.md) Amazon Keyspaces senza tempi di inattività delle applicazioni. Questa soluzione avanzata implementa le migliori pratiche ed estende le funzionalità ufficiali di ZDM Proxy. AWS
+ Esegui migrazioni online tra Apache Cassandra e Amazon Keyspaces.
+ Scrivi dati su entrambe le tabelle di origine e di destinazione contemporaneamente senza rifattorizzare le applicazioni.
+ Convalida le query tramite operazioni di doppia lettura.
La soluzione offre i seguenti miglioramenti con cui lavorare e AWS Amazon Keyspaces.
+ **Distribuzione di container**: utilizza un'immagine Docker preconfigurata da Amazon Elastic Container Registry (Amazon ECR) per distribuzioni accessibili tramite VPC.
+ **Infrastruttura come codice**: esegui la distribuzione utilizzando modelli per la configurazione automatica su. AWS CloudFormation AWS Fargate
+ **Compatibilità con Amazon Keyspaces:** accedi alle tabelle di sistema con adattamenti personalizzati per Amazon Keyspaces.
La soluzione viene eseguita su Amazon ECS con Fargate, fornendo scalabilità serverless in base alle richieste del carico di lavoro. Un sistema di bilanciamento del carico di rete distribuisce il traffico delle applicazioni in entrata tra più attività Amazon ECS per un'elevata disponibilità.
![\[Implementazione del proxy dual write ZDM per la migrazione dei dati da Apache Cassandra ad Amazon Keyspaces.\]](http://docs.aws.amazon.com/it_it/keyspaces/latest/devguide/images/migration/online-migration-zdm.png)
+ **Scritture doppie delle applicazioni**: è possibile implementare la doppia scrittura con modifiche minime al codice dell'applicazione sfruttando le librerie e i driver client Cassandra esistenti. È possibile implementare la doppia scrittura nell'applicazione esistente o creare un nuovo livello nell'architettura per gestire le doppie scritture. Per ulteriori informazioni e per un case study di un cliente che mostra come sono state implementate le doppie scritture in un'applicazione esistente, consulta il [case study sulla migrazione di Cassandra](https://aws.amazon.com/solutions/case-studies/intuit-apache-migration-case-study/).
Quando si implementano le doppie scritture, è possibile designare un database come leader e l'altro database come seguace. Ciò consente di continuare a scrivere sul database di origine o leader originale senza che errori di scrittura del database follower o di destinazione interrompano il percorso critico dell'applicazione.
Invece di riprovare le scritture non riuscite al follower, puoi utilizzare Amazon Simple Queue Service per registrare le scritture non riuscite in una [coda di lettere morte](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html) (DLQ). Il DLQ consente di analizzare le scritture non riuscite al follower e determinare il motivo per cui l'elaborazione non è riuscita nel database di destinazione.
Per un'implementazione in doppia scrittura più sofisticata, puoi seguire le AWS migliori pratiche per progettare una sequenza di transazioni locali utilizzando il modello [saga](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/saga.html). Un modello a catena garantisce che, se una transazione fallisce, la saga esegua transazioni di compensazione per ripristinare le modifiche al database apportate dalle transazioni precedenti.
Quando si utilizzano le doppie scritture per una migrazione online, è possibile configurare le doppie scritture seguendo lo schema saga in modo che ogni scrittura sia una transazione locale per garantire operazioni atomiche su database eterogenei. [Per ulteriori informazioni sulla progettazione di applicazioni distribuite utilizzando i modelli di progettazione consigliati per ilCloud AWS, consulta Modelli di progettazione, architetture e implementazioni del cloud.](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/introduction)
![\[Implementazione della doppia scrittura a livello di applicazione durante la migrazione da Apache Cassandra ad Amazon Keyspaces.\]](http://docs.aws.amazon.com/it_it/keyspaces/latest/devguide/images/migration/online-migration-dual-writes.png)
+ **Doppia scrittura a livello di messaggistica**: invece di implementare la doppia scrittura a livello di applicazione, puoi utilizzare il livello di messaggistica esistente per eseguire due scritture su Cassandra e Amazon Keyspaces.
A tale scopo, puoi configurare un utente aggiuntivo sulla tua piattaforma di messaggistica per inviare scritture a entrambi gli archivi di dati. Questo approccio offre una semplice strategia low-code che utilizza il livello di messaggistica per creare due visualizzazioni su entrambi i database che alla fine sono coerenti.
# Caricamento di dati storici durante una migrazione online
Dopo aver implementato la doppia scrittura per garantire che i nuovi dati vengano scritti in entrambi gli archivi di dati in tempo reale, il passaggio successivo del piano di migrazione consiste nel valutare la quantità di dati storici da copiare o caricare in blocco da Cassandra ad Amazon Keyspaces. Ciò garantisce che sia i nuovi dati che i dati storici siano disponibili nel nuovo database Amazon Keyspaces prima della migrazione dell'applicazione.
A seconda dei requisiti di conservazione dei dati, ad esempio della quantità di dati storici da conservare in base alle politiche dell'organizzazione, puoi prendere in considerazione una delle due opzioni seguenti.
+ **Caricamento in blocco di dati storici**: la migrazione dei dati storici dalla distribuzione esistente di Cassandra ad Amazon Keyspaces può essere ottenuta attraverso varie tecniche, ad esempio utilizzando AWS Glue o script personalizzati per estrarre, trasformare e caricare (ETL) i dati. Per ulteriori informazioni sull'utilizzo per caricare dati storici, AWS Glue consulta. [Processo di migrazione offline: da Apache Cassandra ad Amazon Keyspaces](migrating-offline.md)
Quando si pianifica il caricamento in blocco di dati storici, è necessario considerare come risolvere i conflitti che possono verificarsi quando nuove scritture tentano di aggiornare gli stessi dati in fase di caricamento. Si prevede che il caricamento in blocco alla fine sia coerente, il che significa che alla fine i dati raggiungeranno tutti i nodi.
Se si verifica un aggiornamento degli stessi dati contemporaneamente a causa di una nuova scrittura, devi assicurarti che non vengano sovrascritti dal caricamento dei dati storici. Per garantire la conservazione degli aggiornamenti più recenti dei dati anche durante l'importazione in blocco, è necessario aggiungere la risoluzione dei conflitti negli script di caricamento in blocco o nella logica dell'applicazione per le scritture doppie.
Ad esempio, è possibile utilizzare [Transazioni leggere](functional-differences.md#functional-differences.light-transactions) (LWT) per confrontare e impostare le operazioni. A tale scopo, è possibile aggiungere un campo aggiuntivo al modello di dati che rappresenti l'ora o lo stato della modifica.
Inoltre, Amazon Keyspaces supporta la funzione timestamp di Cassandra`WRITETIME`. Puoi utilizzare i timestamp lato client di Amazon Keyspaces per conservare i timestamp del database di origine e implementare la risoluzione dei conflitti. last-writer-wins Per ulteriori informazioni, consulta [Timestamp lato client in Amazon Keyspaces](client-side-timestamps.md).
+ **Utilizzo di Time-to-Live (TTL)**: per periodi di conservazione dei dati inferiori a 30, 60 o 90 giorni, puoi utilizzare TTL in Cassandra e Amazon Keyspaces durante la migrazione per evitare di caricare dati storici non necessari su Amazon Keyspaces. TTL consente di impostare un periodo di tempo dopo il quale i dati vengono rimossi automaticamente dal database.
Durante la fase di migrazione, invece di copiare i dati storici su Amazon Keyspaces, puoi configurare le impostazioni TTL per far scadere automaticamente i dati storici nel vecchio sistema (Cassandra) applicando solo le nuove scritture ad Amazon Keyspaces utilizzando il metodo dual-write. Nel tempo e con i vecchi dati che scadono continuamente nel cluster Cassandra e i nuovi dati scritti utilizzando il metodo dual-write, Amazon Keyspaces recupera automaticamente il ritardo e contiene gli stessi dati di Cassandra.
Questo approccio può ridurre in modo significativo la quantità di dati da migrare, con conseguente processo di migrazione più efficiente e semplificato. È possibile prendere in considerazione questo approccio quando si ha a che fare con set di dati di grandi dimensioni con requisiti di conservazione dei dati diversi. Per ulteriori informazioni su TTL, consulta [Fai scadere i dati con Time to Live (TTL) per Amazon Keyspaces (per Apache Cassandra)](TTL.md).
Considera il seguente esempio di migrazione da Cassandra ad Amazon Keyspaces utilizzando la scadenza dei dati TTL. In questo esempio impostiamo il TTL per entrambi i database su 60 giorni e mostriamo come procede il processo di migrazione in un periodo di 90 giorni. Entrambi i database ricevono gli stessi dati appena scritti durante questo periodo utilizzando il metodo di doppia scrittura. Esamineremo tre diverse fasi della migrazione, ogni fase dura 30 giorni.
Il funzionamento del processo di migrazione per ciascuna fase è illustrato nelle immagini seguenti.
![\[Utilizzo di TTL per far scadere i dati storici durante la migrazione da Apache Cassandra ad Amazon Keyspaces.\]](http://docs.aws.amazon.com/it_it/keyspaces/latest/devguide/images/migration/online-migration-TTL.png)
1. Dopo i primi 30 giorni, il cluster Cassandra e Amazon Keyspaces hanno ricevuto nuove scritture. Il cluster Cassandra contiene anche dati storici che non hanno ancora raggiunto i 60 giorni di conservazione, che rappresentano il 50% dei dati del cluster.
I dati più vecchi di 60 giorni vengono eliminati automaticamente nel cluster Cassandra tramite TTL. A questo punto Amazon Keyspaces contiene il 50% dei dati archiviati nel cluster Cassandra, che è composto dalle nuove scritture meno i dati storici.
1. Dopo 60 giorni, sia il cluster Cassandra che Amazon Keyspaces contengono gli stessi dati scritti negli ultimi 60 giorni.
1. Entro 90 giorni, sia Cassandra che Amazon Keyspaces contengono gli stessi dati e i dati in scadenza hanno la stessa frequenza.
Questo esempio illustra come evitare la fase di caricamento dei dati storici utilizzando TTL con una data di scadenza impostata su 60 giorni.
# Convalida della coerenza dei dati durante una migrazione online
La fase successiva del processo di migrazione online è la convalida dei dati. Le doppie scritture aggiungono nuovi dati al tuo database Amazon Keyspaces e hai completato la migrazione dei dati storici utilizzando il caricamento in blocco o la scadenza dei dati con TTL.
Ora puoi utilizzare la fase di convalida per confermare che entrambi gli archivi dati contengano effettivamente gli stessi dati e restituiscano gli stessi risultati di lettura. Puoi scegliere una delle due opzioni seguenti per verificare che entrambi i database contengano dati identici.
+ **Doppie letture**: per verificare che sia il database di origine che quello di destinazione contengano lo stesso set di dati appena scritti e storici, puoi implementare letture doppie. A tale scopo, leggi sia il database principale Cassandra che quello secondario di Amazon Keyspaces in modo analogo al metodo dual write e confronta i risultati in modo asincrono.
I risultati del database primario vengono restituiti al client e i risultati del database secondario vengono utilizzati per la convalida rispetto al set di risultati primario. Le differenze rilevate possono essere registrate o inviate a una [coda di lettere morte (DLQ](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html)) per una successiva riconciliazione.
Nel diagramma seguente, l'applicazione esegue una lettura sincrona da Cassandra, che è l'archivio dati primario) e una lettura asincrona da Amazon Keyspaces, che è l'archivio dati secondario.
![\[Utilizzo di due letture per convalidare la coerenza dei dati durante una migrazione online da Apache Cassandra ad Amazon Keyspaces.\]](http://docs.aws.amazon.com/it_it/keyspaces/latest/devguide/images/migration/online-migration-dual-reads.png)
+ **Letture di esempio**: una soluzione alternativa che non richiede modifiche al codice dell'applicazione consiste nell'utilizzare AWS Lambda le funzioni per campionare periodicamente e in modo casuale i dati sia dal cluster Cassandra di origine che dal database Amazon Keyspaces di destinazione.
Queste funzioni Lambda possono essere configurate per essere eseguite a intervalli regolari. La funzione Lambda recupera un sottoinsieme casuale di dati sia dal sistema di origine che da quello di destinazione, quindi esegue un confronto tra i dati campionati. Eventuali discrepanze o discrepanze tra i due set di dati possono essere registrate e inviate a una coda di [lettere morte (DLQ) dedicata per una successiva riconciliazione](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html).
Questo processo è illustrato nello schema seguente.
![\[Utilizzo di letture di esempio per convalidare la coerenza dei dati durante la migrazione online da Apache Cassandra ad Amazon Keyspaces.\]](http://docs.aws.amazon.com/it_it/keyspaces/latest/devguide/images/migration/online-migration-sample-reads.png)
# Migrazione dell'applicazione durante una migrazione online
Nella quarta fase di una migrazione online, stai migrando la tua applicazione e passando ad Amazon Keyspaces come archivio dati principale. Ciò significa che passi l'applicazione alla lettura e alla scrittura direttamente da e verso Amazon Keyspaces. Per garantire interruzioni minime agli utenti, questo deve essere un processo ben pianificato e coordinato.
Sono disponibili due diverse soluzioni consigliate per la migrazione delle applicazioni, la strategia blue green cut over e la canary cut over strategy. Le sezioni seguenti descrivono queste strategie in modo più dettagliato.
+ **Strategia blue green**: utilizzando questo approccio, puoi cambiare la tua applicazione per trattare Amazon Keyspaces come data store primario e Cassandra come data store secondario in un unico passaggio. Puoi farlo utilizzando un flag di AWS AppConfig funzionalità per controllare la selezione degli archivi dati primari e secondari nell'istanza dell'applicazione. Per ulteriori informazioni sui feature flag, consultate [Creazione di un profilo di configurazione dei feature flag in AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-creating-configuration-and-profile-feature-flags.html).
Dopo aver reso Amazon Keyspaces l'archivio dati principale, monitora il comportamento e le prestazioni dell'applicazione, assicurandoti che Amazon Keyspaces soddisfi i tuoi requisiti e che la migrazione abbia esito positivo.
Ad esempio, se hai implementato la doppia lettura per la tua applicazione, durante la fase di migrazione dell'applicazione trasferisci le letture primarie da Cassandra ad Amazon Keyspaces e le letture secondarie da Amazon Keyspaces a Cassandra. Dopo la transizione, continuerai a monitorare e confrontare i risultati come descritto nella sezione sulla [convalida dei dati per garantire la coerenza tra entrambi i database prima della disattivazione di Cassandra](migration-online-validation.md).
Se rilevi problemi, puoi tornare rapidamente allo stato precedente tornando a Cassandra come archivio dati principale. Puoi procedere alla fase di smantellamento della migrazione solo se Amazon Keyspaces soddisfa tutte le tue esigenze come data store primario.
![\[Utilizzo della strategia blu-verde per la migrazione di un'applicazione da Apache Cassandra ad Amazon Keyspaces.\]](http://docs.aws.amazon.com/it_it/keyspaces/latest/devguide/images/migration/online-migration-switch.png)
+ **Strategia Canary**: con questo approccio, estendi gradualmente la migrazione a un sottoinsieme dei tuoi utenti o del tuo traffico. Inizialmente, una piccola percentuale del traffico dell'applicazione, ad esempio il 5% di tutto il traffico, viene indirizzato alla versione che utilizza Amazon Keyspaces come data store principale, mentre il resto del traffico continua a utilizzare Cassandra come data store principale.
In questo modo puoi testare a fondo la versione migrata con traffico reale, monitorarne le prestazioni e la stabilità e indagare su potenziali problemi. Se non rilevi alcun problema, puoi aumentare in modo incrementale la percentuale di traffico indirizzato ad Amazon Keyspaces fino a farlo diventare l'archivio dati principale per tutti gli utenti e il traffico.
Questa implementazione graduale riduce al minimo il rischio di interruzioni diffuse del servizio e consente un processo di migrazione più controllato. In caso di problemi critici durante l'implementazione di Canary, puoi tornare rapidamente alla versione precedente utilizzando Cassandra come archivio dati principale per il segmento di traffico interessato. Puoi procedere alla fase di smantellamento della migrazione solo dopo aver verificato che Amazon Keyspaces elabori il 100% degli utenti e del traffico come previsto.
Il diagramma seguente illustra le singole fasi della strategia delle Canarie.
![\[Utilizzo della strategia canary per la migrazione di un'applicazione da Apache Cassandra ad Amazon Keyspaces.\]](http://docs.aws.amazon.com/it_it/keyspaces/latest/devguide/images/migration/online-migration-canary.png)
# Disattivazione di Cassandra dopo una migrazione online
Una volta completata la migrazione dell'applicazione, con l'applicazione completamente in esecuzione su Amazon Keyspaces e aver convalidato la coerenza dei dati per un periodo di tempo, puoi pianificare la disattivazione del cluster Cassandra. Durante questa fase, puoi valutare se i dati rimanenti nel cluster Cassandra devono essere archiviati o possono essere eliminati. Ciò dipende dalle politiche dell'organizzazione per la gestione e la conservazione dei dati.
Seguendo questa strategia e considerando le best practice consigliate descritte in questo argomento durante la pianificazione della migrazione online da Cassandra ad Amazon Keyspaces, puoi garantire una transizione senza interruzioni ad Amazon Keyspaces read-after-write mantenendo al contempo la coerenza e la disponibilità dell'applicazione.
La migrazione da Apache Cassandra ad Amazon Keyspaces può offrire numerosi vantaggi, tra cui riduzione del sovraccarico operativo, scalabilità automatica, maggiore sicurezza e un framework che ti aiuta a raggiungere i tuoi obiettivi di conformità. Pianificando una strategia di migrazione online con doppia scrittura, caricamento storico dei dati, convalida dei dati e implementazione graduale, puoi garantire una transizione fluida con interruzioni minime per l'applicazione e i suoi utenti.
L'implementazione della strategia di migrazione online illustrata in questo argomento consente di convalidare i risultati della migrazione, identificare e risolvere eventuali problemi e, infine, disattivare la distribuzione Cassandra esistente a favore del servizio Amazon Keyspaces completamente gestito.