Modelli di architettura distribuita

Last reviewed 2023-12-14 UTC

Quando esegui la migrazione da un ambiente di computing non ibrido o non multi-cloud a un'architettura ibrida o multi-cloud, considera innanzitutto i vincoli delle applicazioni esistenti e in che modo questi vincoli potrebbero causare un errore dell'applicazione. Questa considerazione diventa più importante quando le applicazioni o i componenti delle applicazioni operano in modo distribuito tra diversi ambienti. Dopo aver valutato i vincoli, sviluppa un piano per evitarli o superarli. Assicurati di considerare le funzionalità uniche di ciascun ambiente di calcolo in un'architettura distribuita.

Note sul layout

Le seguenti considerazioni di progettazione si applicano ai pattern di deployment distribuito. A seconda della soluzione target e degli scopi commerciali, la priorità e l'effetto di ogni considerazione possono variare.

Latenza

In qualsiasi pattern di architettura che distribuisca i componenti dell'applicazione (frontend, backend o microservizi) tra diversi ambienti di elaborazione, può verificarsi una latenza della comunicazione. Questa latenza è influenzata dalla connettività di rete ibrida (Cloud VPN e Cloud Interconnect) e dalla distanza geografica tra il sito on-premise e le regioni cloud o tra le regioni cloud in una configurazione multi-cloud. Di conseguenza, è fondamentale valutare i requisiti di latenza delle tue applicazioni e la loro sensibilità ai ritardi di rete. Le applicazioni in grado di tollerare la latenza sono candidati più adatte per il deployment iniziale distribuito in un ambiente ibrido o multi-cloud.

Architettura dello stato temporanea e finale

Per specificare le aspettative e le eventuali implicazioni potenziali per costi, scalabilità e prestazioni, è importante analizzare il tipo di architettura necessario e la durata prevista nell'ambito della fase di pianificazione. Ad esempio, se prevedi di utilizzare un'architettura ibrida o multi-cloud per un lungo periodo di tempo o definitivamente, ti consigliamo di utilizzare Cloud Interconnect. Per ridurre i costi di trasferimento di dati in uscita e ottimizzare le prestazioni della rete con connettività ibrida, Cloud Interconnect sconta i costi per il trasferimento di dati in uscita che soddisfano le condizioni scontate per la velocità di trasferimento di dati.

Affidabilità

L'affidabilità è un aspetto fondamentale nella progettazione di sistemi IT. La disponibilità dell'uptime è un aspetto essenziale dell'affidabilità del sistema. In Google Cloud, puoi aumentare la resilienza di un'applicazione eseguendo il deployment di componenti ridondanti in più zone all'interno di una singola regione o in più regioni mediante funzionalità di cambio. La ridondanza è uno degli elementi chiave per migliorare la disponibilità complessiva di un'applicazione. Per le applicazioni con una configurazione distribuita in ambienti ibridi e multi-cloud, è importante mantenere un livello di disponibilità coerente.

Per migliorare la disponibilità di un sistema in un ambiente on-premise o in altri ambienti cloud, valuta la ridondanza hardware o software di cui hai bisogno per le applicazioni e i relativi componenti, con i meccanismi di failover. Idealmente, dovresti considerare la disponibilità di un servizio o di un'applicazione nei vari componenti e nell'infrastruttura di supporto (inclusa la disponibilità di connettività ibrida) in tutti gli ambienti. Questo concetto è anche nota come disponibilità composita di un'applicazione o di un servizio.

In base alle dipendenze tra i componenti o i servizi, la disponibilità composita per un'applicazione potrebbe essere superiore o inferiore a quella di un singolo servizio o componente. Per ulteriori informazioni, consulta Disponibilità composita: calcolo della disponibilità complessiva dell'infrastruttura cloud.

Per raggiungere il livello di affidabilità del sistema desiderato, definisci metriche di affidabilità chiare e progetta applicazioni per autoripararsi e resistere in modo efficace alle interruzioni nei diversi ambienti. Per aiutarti a definire i modi appropriati per misurare la customer experience dei tuoi servizi, consulta Definire gli obiettivi di affidabilità.

Connettività ibrida e multi-cloud

I requisiti di comunicazione tra i componenti delle applicazioni distribuite devono influire sulla scelta dell'opzione di connettività di rete ibrida. Ogni opzione di connettività presenta vantaggi e svantaggi, nonché fattori specifici da considerare, come costi, volume di traffico, sicurezza e così via. Per ulteriori informazioni, consulta la sezione Considerazioni sulla progettazione della connettività.

Gestibilità

Strumenti di gestione e monitoraggio coerenti e unificati sono essenziali per configurazioni ibride e multi-cloud di successo (con o senza portabilità dei carichi di lavoro). Nel breve periodo, questi strumenti possono comportare costi operativi, di sviluppo e test. Tecnicamente, più cloud provider usi, più diventa complessa la gestione degli ambienti. La maggior parte dei fornitori di servizi cloud pubblico non solo offre funzionalità diverse, ma dispone anche di strumenti, SLA e API di vario tipo per la gestione dei servizi cloud. Di conseguenza, valuta i vantaggi strategici dell'architettura selezionata rispetto alla potenziale complessità a breve termine rispetto ai vantaggi a lungo termine.

Costo

Ogni fornitore di servizi cloud in un ambiente multi-cloud dispone di metriche e strumenti di fatturazione propri. Per migliorare la visibilità e le dashboard unificate, valuta la possibilità di usare strumenti di ottimizzazione e gestione dei costi multi-cloud. Ad esempio, quando si creano soluzioni cloud-first in più ambienti cloud, i prodotti, i prezzi, gli sconti e gli strumenti di gestione di ogni fornitore possono creare incoerenze dei costi tra questi ambienti.

Consigliamo di utilizzare un metodo unico e ben definito per calcolare tutti i costi delle risorse cloud e per garantire la visibilità dei costi. La visibilità dei costi è essenziale per l'ottimizzazione dei costi. Ad esempio, combinando i dati di fatturazione dei provider cloud che utilizzi e utilizzando Google Cloud Looker Cloud Cost Management Block, puoi creare una visualizzazione centralizzata dei tuoi costi multi-cloud. Questa vista può aiutarti a fornire una vista report consolidata della tua spesa su più cloud. Per maggiori informazioni, consulta La strategia per ottimizzare in modo efficace la gestione dei costi di fatturazione cloud.

Ti consigliamo inoltre di utilizzare la pratica di FinOps per rendere visibili i costi. Nell'ambito di una solida pratica FinOps, un team centrale può delegare il processo decisionale per l'ottimizzazione delle risorse a qualsiasi altro team coinvolto in un progetto per incoraggiare la responsabilità individuale. In questo modello, il team centrale dovrebbe standardizzare il processo, i report e gli strumenti per l'ottimizzazione dei costi. Per ulteriori informazioni sui diversi aspetti e suggerimenti di ottimizzazione dei costi da prendere in considerazione, consulta Framework dell'architettura Google Cloud: ottimizzazione dei costi.

Spostamento dei dati

Lo spostamento dei dati è una considerazione importante per la pianificazione della strategia e dell'architettura ibrida e multi-cloud, in particolare per i sistemi distribuiti. Le aziende devono identificare i diversi casi d'uso aziendali, i dati su cui si basano e come vengono classificati i dati (per i settori regolamentati). Dovrebbero inoltre considerare in che modo l'archiviazione, la condivisione e l'accesso ai dati per i sistemi distribuiti in diversi ambienti possono influire sulle prestazioni delle applicazioni e sulla coerenza dei dati. Questi fattori potrebbero influenzare l'architettura dell'applicazione e della pipeline di dati. Il set completo di opzioni di spostamento dei dati di Google Cloud consente alle aziende di soddisfare le proprie esigenze specifiche e di adottare architetture ibride e multi-cloud senza compromettere la semplicità, l'efficienza o le prestazioni.

Sicurezza

Durante la migrazione delle applicazioni nel cloud, è importante considerare le funzionalità di sicurezza cloud-first, come la coerenza, l'osservabilità e la visibilità unificata della sicurezza. Ciascun cloud provider pubblico ha il proprio approccio, best practice e funzionalità per la sicurezza. È importante analizzare e allineare queste capacità per creare un'architettura di sicurezza standard e funzionale. Controlli IAM efficaci, crittografia dei dati, analisi delle vulnerabilità e conformità alle normative del settore sono aspetti importanti della sicurezza del cloud.

Quando pianifichi una strategia di migrazione, ti consigliamo di analizzare le considerazioni menzionate in precedenza. Possono aiutarti a ridurre al minimo le possibilità di introdurre complessità nell'architettura con l'aumento delle applicazioni o dei volumi di traffico. Inoltre, la progettazione e la creazione di una zona di destinazione è quasi sempre un prerequisito per il deployment di carichi di lavoro aziendali in un ambiente cloud. Una zona di destinazione consente alla tua azienda di eseguire il deployment, utilizzare e scalare i servizi cloud in modo più sicuro in più aree e include diversi elementi, come identità, gestione delle risorse, sicurezza e networking. Per ulteriori informazioni, consulta Progettazione della zona di destinazione in Google Cloud.

I seguenti documenti di questa serie descrivono altri modelli di architettura distribuita: