Questo documento illustra la configurazione ed esecuzione del processo di migrazione del database, inclusi gli scenari di errore. Questo documento è la seconda parte di un'intera serie. La Parte 1 introduce i concetti, i principi e la terminologia della migrazione dei database con tempi di inattività quasi nulli per gli architetti del cloud che devono eseguire la migrazione dei database da Google Cloud ambiente on-premise o da altri ambienti cloud.
Configurazione della migrazione del database
Questa sezione descrive le varie fasi di una migrazione del database. Innanzitutto, configura la migrazione. Dopo aver completato la migrazione e trasferito i client ai database di destinazione, rimuovi i database di origine o, se necessario, implementa un piano di riserva a causa di problemi con la migrazione dopo il trasferimento. Un piano di riserva contribuisce a garantire la continuità aziendale.
Durante la migrazione, devi prestare particolare attenzione a eventuali modifiche dello schema o dei dati che potrebbero essere introdotte. Per ulteriori informazioni sull'impatto di queste modifiche, consulta la sezione Modifiche dinamiche durante la migrazione più avanti in questo documento.
Specifica dello schema di destinazione
Per ogni sistema di database di destinazione, devi definire e creare lo schema. Per le migrazioni di database omogenee, puoi creare questa specifica più rapidamente esportando lo schema del database di origine nel database di destinazione, creando così lo schema del database di destinazione.
Il nome dello schema è importante. Un'opzione è associare i nomi degli schemi di origine e di destinazione. Tuttavia, anche se semplifica il passaggio da un client all'altro, questo approccio potrebbe confondere gli utenti se gli strumenti si connettono contemporaneamente agli schemi di database di origine e di destinazione, ad esempio per confrontare i dati. Se astratti il nome dello schema utilizzando un file di configurazione, assegnare nomi diversi agli schemi del database di destinazione rispetto a quelli dell'origine semplifica la loro differenziazione.
Con le migrazioni di database eterogenee, devi creare ogni schema del database di destinazione. Questo processo di progettazione può richiedere diverse iterazioni. Prima di poter eseguire la migrazione, potrebbe essere necessario modificare ulteriormente gli schemi per adattarli al processo di migrazione e alle eventuali modifiche dei dati.
Poiché è probabile che tu crei i database di destinazione più volte durante il test e l'esecuzione della migrazione, la procedura di creazione dello schema deve essere ripetibile (idealmente eseguita tramite script di installazione). Puoi utilizzare un sistema di gestione del codice per controllare la versione degli script, garantire la coerenza e accedere alla cronologia delle modifiche degli script.
Semântica di migrazione ed esecuzione delle query
Alla fine, dovrai passare i client dall'accesso ai sistemi di database di origine all'accesso ai sistemi di database di destinazione. Nelle integrazioni di database omogenee, le query possono rimanere invariate se gli schemi non vengono modificati. Sebbene i client debbano essere testati sui sistemi di database di destinazione, non devono essere modificati a causa delle query.
Per le migrazioni di database eterogenee in generale, devi modificare le query perché gli schemi dei database di origine e di destinazione sono diversi. La differenza potrebbe essere un mancato accoppiamento dei tipi di dati tra i database di origine e di destinazione. Inoltre, non tutte le funzionalità del linguaggio di query disponibili nei sistemi di database di origine potrebbero essere disponibili nei sistemi di database di destinazione o viceversa. In casi estremi, potrebbe essere necessario convertire una query da un sistema di database di origine in più query sul sistema di destinazione. In uno scenario opposto, in cui nel database di destinazione sono disponibili più funzionalità del linguaggio di query rispetto a quello di origine, potrebbe essere necessario combinare più query dal database di origine in un'unica query sul database di destinazione corrispondente.
Anche la semantica delle query può variare. Ad esempio, alcuni sistemi di database materializzano un aggiornamento all'interno di una transazione immediatamente al suo interno, quindi quando viene letto lo stesso elemento di dati, viene recuperato il valore aggiornato. Altri sistemi non materializzano immediatamente un aggiornamento e aspettano il commit della transazione. Se la logica nel sistema di database di origine si basa sulla materializzazione della scrittura, la stessa logica nel database di destinazione può causare dati errati o addirittura errori.
Se devi eseguire la migrazione delle query, devi testare tutte le funzionalità per assicurarti che il comportamento dei client sia lo stesso prima e dopo la migrazione. Puoi anche eseguire test a livello di dati, ma questi test non sostituiscono i test a livello di client. I client eseguono query dal punto di vista della logica di business e possono essere testati solo a questo livello.
Processi di migrazione
Per le migrazioni di database eterogenee, i processi di migrazione specificano in che modo i dati estratti dai sistemi di database di origine vengono modificati e inseriti nei database di destinazione. Le modifiche ai dati, come quelle descritte nella sezione Modifiche ai dati di questo documento, vengono definite ed eseguite mentre gli elementi di dati vengono estratti dai database di origine e trasferiti ai database di destinazione.
Con le migrazioni dei database omogenee, quando gli schemi dei database di origine e di destinazione sono equivalenti, la modifica dei dati non è richiesta. I dati vengono inseriti nei database di destinazione come sono stati estratti dai database di origine.
A seconda del sistema di migrazione del database, potrebbero essere necessarie diverse configurazioni. Ad esempio, devi specificare se i dati modificati e trasferiti devono essere archiviati intermittentemente nel sistema di migrazione del database. L'archiviazione dei dati potrebbe rallentare il processo di migrazione complessivo, ma accelerare notevolmente il recupero in caso di errore. Potrebbe esserti richiesto di specificare il tipo di verifica. Ad esempio, alcuni sistemi di migrazione del database eseguono query sui sistemi di origine e di destinazione per stabilire l'equivalenza del set di dati sottoposto a migrazione fino al punto della query. La gestione degli errori richiede che tu specifichi il comportamento di recupero in caso di errore. Anche in questo caso, il requisito dipende dal sistema di migrazione del database in uso.
È inutile dire che devi testare la migrazione dei dati in modo accurato e ripetuto. Idealmente, la migrazione viene testata per assicurarsi che venga eseguita la migrazione di tutti gli elementi di dati noti, che non si verifichino errori di modifica dei dati, che il rendimento e il throughput siano sufficienti e che sia possibile completare la migrazione in un determinato periodo di tempo.
Procedure di riserva
Durante una migrazione del database, i database di origine rimangono operativi (a meno che la migrazione non preveda un tempo di riposo pianificato). Se la migrazione del database non va a buon fine in qualsiasi momento, puoi (nello scenario peggiore) interrompere la migrazione e reimpostare il database di destinazione sullo stato iniziale. Dopo aver risolto gli errori, puoi riavviare la migrazione del database. L'errore e la risoluzione non influiscono sui sistemi di database di origine operativi.
Se si verificano errori dopo il completamento della migrazione del database e i client vengono trasferiti ai database di destinazione, la procedura di errore e risoluzione potrebbe influire sui client impedendo loro di funzionare correttamente. Nel migliore dei casi, l'errore viene risolto rapidamente e il tempo di inattività per i clienti è breve. Nel peggiore delle ipotesi, l'errore non viene risolto o la risoluzione richiede molto tempo e devi ripristinare i client nei database di origine.
Per ripristinare i client nei database di origine, devi eseguire la migrazione di tutte le modifiche ai dati nei database di destinazione ai database di origine. Puoi configurare ed eseguire questa procedura come migrazione completa e separata del database. Tuttavia, poiché a questo punto i client non sono operativi nei database di destinazione, si verificheranno downtime significativi.
Per evitare tempi di riposo del client in questo scenario, devi avviare le operazioni di migrazione immediatamente dopo il completamento della migrazione del database originale. Ogni modifica applicata ai sistemi di database di destinazione viene applicata immediatamente ai sistemi di database di origine. Questo approccio garantisce che i sistemi di database di destinazione e di origine vengano mantenuti sincronizzati in ogni momento.
La preparazione di un piano di riserva dai database di destinazione ai database di origine richiede un impegno significativo. È fondamentale decidere se implementare e testare le procedure di riserva o comprendere le conseguenze del mancato adempimento, ovvero un tempo di riposo significativo.
Esecuzione della migrazione del database
L'esecuzione di una migrazione del database prevede cinque fasi distinte, descritte in questa sezione. Una sesta fase è un piano di riserva, ma si tratta di un caso estremo e viene considerata un'eccezione a una normale esecuzione della migrazione del database.
Il processo descritto in questa sezione è una migrazione di database eterogeneo con tempi di riposo quasi nulli. Se puoi permetterti un tempo di riposo significativo, puoi combinare le prime tre fasi (caricamento iniziale, migrazione continua e svuotamento) in una sola fase utilizzando l'approccio di backup e ripristino o di esportazione e importazione.
La migrazione di un database omogeneo rappresenta un caso speciale. Con questo tipo di migrazione, puoi utilizzare la funzionalità di replica del sistema di gestione del database (per i sistemi che la supportano) che esegue la migrazione dei dati mentre i sistemi di database di origine rimangono operativi.
Le fasi descritte qui illustrano un approccio che potrebbe essere necessario modificare in base ai requisiti del processo di migrazione del database.
Fase 1: caricamento iniziale
Il punto di partenza è la migrazione di tutti i dati specificati da tutti i database di origine. All'inizio della migrazione dei dati, i database di origine hanno un determinato stato, che cambia durante la migrazione.
Un suggerimento per avviare una migrazione mentre le modifiche si verificano contemporaneamente è annotare l'ora di sistema del database subito prima dell'estrazione del primo elemento di dati. Con questo timestamp, puoi dedurre tutte le modifiche al database dal log delle transazioni a partire da quel momento. Inoltre, il caricamento iniziale deve leggere uno stato del database coerente in tutti i dati. Potresti aver bisogno di un blocco di breve durata sul database per impedire la lettura di un set di dati incoerente.
Questa fase è costituita da quanto segue:
- Prendi nota dell'ora di sistema del database subito prima dell'inizio della migrazione del database.
- Eseguire un processo di migrazione del caricamento iniziale che esegue query sul set di dati
(completo o parziale) dai database di origine di cui è necessaria la migrazione e la migrazione del set di dati. In un modello di database relazionale, le procedure di migrazione del caricamento iniziale eseguono query come
SELECT *
o query con selezione o proiezione o entrambe. Il processo di migrazione esegue la modifica dei dati come specificato nel processo.
Durante l'esecuzione dei processi di migrazione del caricamento iniziale, i client in genere apportano modifiche ai database di origine. Poiché registri l'ora di sistema del database all'inizio, puoi ricavare queste modifiche dal log delle transazioni in un secondo momento.
Il risultato della fase di caricamento iniziale è la migrazione completa del set di dati iniziale dai sistemi di database di origine ai sistemi di database di destinazione. Tuttavia, i database di origine e di destinazione non sono ancora sincronizzati perché è probabile che i client abbiano modificato i database di origine durante la migrazione. La fase 2 prevede l'acquisizione e la migrazione di queste modifiche.
Fase 2: continua la migrazione
La migrazione continua ha due scopi. Innanzitutto, legge le modifiche che si sono verificate nei database di origine dopo l'avvio del caricamento iniziale. In secondo luogo, acquisisce e trasferisce queste modifiche ai database di destinazione.
Questa fase è costituita da quanto segue:
- Avvio dei processi di migrazione continua dal sistema di database nel momento registrato nella Fase 1. La migrazione legge il log delle transazioni da quel momento e applica ogni modifica al sistema di database di destinazione.
- Eseguire qualsiasi modifica dei dati. Il processo di migrazione esegue questo passaggio come da tua specifica.
A volte le modifiche registrate dopo l'ora del sistema del database vengono trasferite durante il caricamento iniziale. Pertanto, è possibile che queste modifiche possano essere applicate una seconda volta durante la migrazione. Devi definire le tue procedure di migrazione per assicurarti che le modifiche non vengano applicate due volte, ad esempio utilizzando gli identificatori. Supponiamo che un elemento di dati modificato venga trasferito durante il caricamento iniziale e che l'inserimento venga registrato nel log delle transazioni. Applicando un identificatore all'elemento dati, il sistema di migrazione può determinare dal log delle transazioni che non è necessario un altro inserimento perché l'elemento dati esiste già.
Il risultato della fase di migrazione in corso è che i database di destinazione sono completamente sincronizzati o quasi completamente sincronizzati con i database di origine. Quando non viene eseguita la migrazione di una modifica in un sistema di database di origine, hai un database quasi sincronizzato.
A seconda di come configuri il sistema di migrazione del database, le discrepanze possono essere piccole o grandi. Ad esempio, per aumentare l'efficienza, non è necessario eseguire la migrazione di ogni modifica immediatamente, altrimenti potresti creare un carico elevato sull'origine se le modifiche all'origine aumentano in modo significativo. In genere, le modifiche vengono raccolte e migrate in batch come operazioni collettive. Con batch più piccoli, si verificano meno discrepanze tra l'origine e la destinazione, ma l'origine può comportare un carico più elevato se le modifiche vengono apportate di frequente.
Se la dimensione del batch è configurata in modo dinamico, è meglio sincronizzare inizialmente batch più grandi nella fase di migrazione continua e poi sincronizzare batch di dimensioni gradualmente ridotte quando i database sono quasi aggiornati. Questo approccio rende più efficiente il processo di aggiornamento e riduce la discrepanza tra i database di origine e di destinazione in un secondo momento.
Fase 3: svuotamento
Per prepararti a spostare i client dai database di origine a quelli di destinazione, devi assicurarti che i database di origine e di destinazione siano completamente sincronizzati. Il traferimento è il processo di migrazione delle modifiche rimanenti dai database di origine ai database di destinazione.
Questa fase è costituita da quanto segue:
- Mettere in stato di attesa i sistemi di database di origine. Ciò significa che non possono verificarsi modifiche ai dati nel database di origine e che il log delle transazioni non riceve voci di modifica aggiuntive.
- In attesa del completamento della migrazione di tutte le modifiche ai database di destinazione. Questa procedura è l'effettivo svuotamento delle modifiche.
- Al termine dello svuotamento, esegui il backup dei database di destinazione per avere un punto di partenza definito per i futuri backup incrementali.
Il risultato della fase di svuotamento è che i sistemi di database di origine e di destinazione vengono sincronizzati e non verranno apportate modifiche ai dati.
Per assicurarti che lo svuotamento sia stato completato, puoi scrivere un elemento dati "ultimo insert" in un database di origine. Una volta visualizzato l'elemento dati "ultimo insert" nel database di destinazione corrispondente, la fase di svuotamento è completata.
Fase 4: passaggio
Al termine della fase di svuotamento, puoi spostare i client dal database di origine a quello di destinazione. Consigliamo le seguenti best practice:
- Prima di attivare l'accesso al database di produzione, testa la funzionalità di base per assicurarti che i client siano operativi e si comportino come previsto. Il numero di casi di test determinerà il tempo di riposo effettivo del database di produzione.
- Esegui il backup dei database di destinazione prima di attivare l'accesso client. Questa best practice garantisce che lo stato iniziale dei database di destinazione sia recuperabile.
Al termine del passaggio, i client sono completamente operativi e iniziano ad accedere ai database di produzione (fino a questo punto indicati in questo documento come database di destinazione).
Fase 5: eliminazione del database di origine
Una volta completato il passaggio ai database di produzione, puoi eliminare i database di origine. È buona norma eseguire un backup finale di ogni database di origine in modo da avere uno stato finale definito e accessibile. I regolamenti relativi ai dati potrebbero richiedere anche backup finali per motivi di conformità.
Fase 6: piano di riserva
L'implementazione di un piano di riserva, in particolare per i client di database altamente critici, può essere un buon sistema di protezione contro i problemi e le difficoltà della migrazione. Un piano di riserva è simile a una migrazione, ma al contrario. In altre parole, con un piano di riserva configuri una migrazione dai database di destinazione ai database di origine. Con le migrazioni di database eterogenee, il fallback è più complesso. Per questo motivo, consigliamo di eseguire il passaggio solo dopo aver verificato a fondo che la procedura di migrazione del database e le applicazioni collegate al database di destinazione soddisfino gli accordi sul livello del servizio (SLA).
Dopo aver svuotato i database di origine e aver eseguito il backup di tutti i database, puoi attivare le procedure di migrazione che identificano le modifiche nei database di destinazione e le eseguono nei database di origine prima del passaggio.
La creazione di queste procedure di migrazione garantisce che, dopo che i client apportano modifiche ai database di destinazione, i database di origine vengano sincronizzati e che lo stato dei dati venga mantenuto aggiornato. Potrebbe essere necessario un piano di riserva alcuni giorni o alcune settimane dopo il passaggio. Ad esempio, i client potrebbero accedere alla funzionalità per la prima volta e essere bloccati a causa di una funzionalità non funzionante che non può essere riparata rapidamente. In questo caso, i client possono tornare ad accedere ai database di origine. Prima di ripristinare i client, tutte le modifiche ai database di destinazione devono essere trasferite ai database di origine.
In questo approccio, alcune circostanze richiedono un'attenzione particolare:
- Devi progettare gli schemi di destinazione in modo che sia possibile una migrazione inversa (dai database di destinazione ai database di origine). Ad esempio, se il processo di migrazione iniziale (dall'origine alla destinazione) include unioni o aggregazioni, una migrazione inversa non è banale o addirittura impossibile. In questo caso, i singoli dati devono essere disponibili anche nei database di destinazione.
- Potrebbe verificarsi un problema in cui i database di origine dispongono di log delle transazioni, ma i database di destinazione non forniscono una funzionalità non funzionale di questo tipo. In questo caso, una migrazione inversa (dalla destinazione all'origine) deve basarsi su query differenziali. Questa configurazione deve essere progettata e preparata negli schemi del database di destinazione.
- I client che in origine operavano sui database di origine devono essere mantenuti disponibili e operativi in modo da poter essere attivati in caso di piano di riserva. Per garantire l'equivalenza funzionale, qualsiasi modifica funzionale apportata ai client che accedono ai database di destinazione deve essere apportata anche ai client che accedono al database di origine.
Sebbene un piano di riserva sia l'ultima risorsa, la sua implementazione è essenziale e deve essere considerata come una migrazione completa del database, che include i test.
Modifiche dinamiche durante la migrazione
In generale, i database sono sistemi dinamici perché i valori di schema e dati possono cambiare. Gli schemi di database possono cambiare in base a fattori quali i requisiti aziendali e i valori dei dati possono cambiare insieme alle modifiche dello schema o indipendentemente da queste. Le modifiche ai valori dei dati possono avvenire in modo dinamico in qualsiasi momento con le modifiche corrispondenti dell'implementazione di un'applicazione. Le sezioni seguenti illustrano alcune delle possibili modifiche e le relative implicazioni per una migrazione del database.
Modifiche allo schema
I database possono essere classificati in sistemi che richiedono uno schema predefinito o che sono senza schema o senza schema. In generale, i sistemi che richiedono uno schema predefinito supportano le operazioni di modifica dello schema, ad esempio l'aggiunta di attributi o colonne in un sistema relazionale.
In questi sistemi, controlli le modifiche tramite un processo di gestione dei cambiamenti. Un procedura di gestione dei cambiamenti consente di apportare modifiche in modo controllato. Eventuali operazioni che dipendono dallo schema, come query o procedure di migrazione dei dati, vengono modificate contemporaneamente per garantire una modifica complessivamente coerente.
I sistemi di database che non richiedono uno schema predefinito possono essere modificati in qualsiasi momento. Una modifica dello schema non può essere eseguita solo da un utente autorizzato, in alcuni casi è possibile tramite programmazione. In questi casi, una modifica dello schema può avvenire in qualsiasi momento. Le operazioni che dipendono dallo schema potrebbero non riuscire, ad esempio le query o i processi di migrazione dei dati. Per evitare modifiche non controllate dello schema in questi sistemi di database, devi implementare una procedura di gestione delle modifiche come convenzione e regola accettata anziché tramite l'applicazione forzata del sistema.
Modifiche ai dati
In generale, gli schemi controllano i possibili valori dei dati per i vari attributi. I sistemi senza schema non hanno vincoli sui valori dei dati.
In entrambi i casi, possono essere visualizzati valori di dati non memorizzati in precedenza. Ad esempio, i tipi di enumerazione vengono spesso implementati come un insieme di stringhe nei sistemi di database. A livello di linguaggio di programmazione, questi valori potrebbero essere implementati nei client come tipi di enumerazione veri e propri, ma non necessariamente. È possibile che un client memorizzi ciò che considera un valore di enumerazione valido, mentre altri client non lo considerano valido. Inoltre, un processo di migrazione dei dati potrebbe disattivare la funzionalità dei valori di enumerazione. Se vengono visualizzati nuovi valori, la procedura di migrazione dei dati potrebbe non riuscire.
Un altro esempio si trova nella memorizzazione delle strutture JSON. In molti casi le strutture JSON vengono memorizzate in una stringa di tipo di dati, ma vengono interpretate come valori JSON al momento dell'accesso. Se la struttura JSON cambia, il sistema di database non lo rileva. I processi di migrazione dei dati che interpretano una stringa come valore JSON potrebbero non riuscire.
Modifiche al processo di migrazione
La gestione delle modifiche durante una migrazione del database in corso è difficile e complessa e può comportare errori o incoerenze nei dati. È ottimale che le modifiche richieste vengano ritardate fino alla fine della fase di svuotamento, al termine della quale i sistemi di database di origine e di destinazione sono sincronizzati. A questo punto, le modifiche sono limitate ai database di destinazione e ai relativi client (a meno che non sia implementato anche un piano di riserva).
Se devi modificare la procedura di migrazione durante la migrazione dei dati, ti consigliamo di ridurre al minimo le modifiche e, se possibile, di apportare diverse piccole modifiche anziché una più complessa. Inoltre, ti consigliamo di eseguire prima un test di queste modifiche utilizzando istanze di test dei database di origine e di destinazione. Idealmente, carichi l'origine di test con i dati di produzione di cui poi esegui la migrazione al target di test. Con questo approccio, puoi verificare le modifiche proposte senza influire sulla migrazione in produzione in corso. Dopo aver testato e verificato le modifiche, puoi applicarle al sistema di produzione.
Affinché le modifiche siano possibili durante una migrazione dei dati in corso, devi essere in grado di interrompere il sistema di migrazione dei dati e riavviarlo, eventualmente con procedure di migrazione dei dati modificate. In questo caso, non devi iniziare dall'inizio con una fase di caricamento iniziale dei dati. Se il sistema di migrazione dei dati supporta una funzionalità di esecuzione di migrazione di prova, puoi utilizzarla anche.
Ti consigliamo di evitare di modificare lo schema, i valori dei dati o i processi di migrazione dei dati durante una migrazione dei dati. Se devi apportare modifiche, ti consigliamo di riavviare la migrazione dei dati dall'inizio per assicurarti di avere uno stato iniziale definito. In ogni caso, è fondamentale eseguire il test utilizzando i dati di produzione ed eseguire il backup dei database prima di applicare le modifiche in modo da poter ripristinare lo stato coerente del sistema, se necessario.
Mitigazione degli errori di migrazione
Durante una migrazione del database possono verificarsi problemi imprevisti. Di seguito sono evidenziate alcune aree che possono richiedere una pianificazione preliminare:
- Throughput insufficiente. Un sistema di migrazione può non avere un throughput sufficiente nonostante i test di carico. Questo problema potrebbe avere molte cause, ad esempio un aumento imprevisto della frequenza delle modifiche al database di origine o la limitazione della rete. Per prepararti a questo caso, puoi predisporre risorse aggiuntive per il ridimensionamento dinamico di tutti i componenti coinvolti.
- Instabilità del database. I database di origine o di destinazione possono essere in stato di instabilità, il che può rallentare i processi di migrazione dei dati o impedire l'accesso in modo intermittente. I processi di migrazione dei dati potrebbero dover essere recuperati di frequente. In questo caso, un passaggio intenzionale ad HA o RE potrebbe risolvere il problema. Il passaggio cambia l'ambiente non funzionale (macchine e spazio di archiviazione) e potrebbe contribuire a mitigare il problema. In questo caso, devi testare i processi di passaggio e di recupero della migrazione del database per assicurarti che il passaggio non causi incoerenze nei dati nei database di destinazione.
- Dimensioni del file del log delle transazioni esaurite. In alcuni casi, i log delle transazioni vengono archiviati in file con un limite superiore. È possibile che questo limite superiore venga raggiunto e la migrazione del database non vada a buon fine. È importante comprendere quali parti di un sistema di database possono essere riconfigurate dinamicamente per risolvere le limitazioni delle risorse man mano che si presentano. Se alcuni aspetti non possono essere configurati dinamicamente, le dimensioni iniziali devono essere determinate con attenzione.
Più rendi realistici e completi i test preliminari, più è probabile che tu riesca a trovare potenziali problemi da risolvere in anticipo.
Passaggi successivi
- Consulta le seguenti risorse sulla migrazione del database:
- Per altre guide alla migrazione dei database, consulta Migrazione del database.
- Esplora architetture di riferimento, diagrammi e best practice su Google Cloud. Consulta il nostro Cloud Architecture Center.