Modelli di architettura distribuita

Last reviewed 2024-10-29 UTC

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

Note sul layout

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

Latenza

In qualsiasi modello di architettura che distribuisce i componenti dell'applicazione (frontend, backend o microservizi) in diversi ambienti di calcolo, può verificarsi la latenza di comunicazione. Questa latenza è influenzata dalla connettività della 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 multicloud. Pertanto, è fondamentale valutare i requisiti di latenza delle applicazioni e la loro sensibilità ai ritardi della rete. Le applicazioni che possono tollerare la latenza sono candidate più adatte per il deployment distribuito iniziale in un ambiente ibrido o multicloud.

Architettura dello stato temporaneo e finale

Per specificare le aspettative e le potenziali implicazioni per costi, scalabilità e rendimento, è importante analizzare il tipo di architettura di cui hai bisogno e la durata prevista nell'ambito della fase di pianificazione. Ad esempio, se prevedi di utilizzare un'architettura ibrida o multi-cloud per molto tempo o in modo permanente, ti consigliamo di utilizzare Cloud Interconnect. Per ridurre i costi di trasferimento dei dati in uscita e ottimizzare le prestazioni della rete di connettività ibrida, Cloud Interconnect sconta gli addebiti per il trasferimento dei dati in uscita che soddisfano le condizioni di tariffa scontata per il trasferimento dei dati.

Affidabilità

L'affidabilità è un aspetto fondamentale nella progettazione di sistemi IT. La disponibilità di uptime è un aspetto essenziale dell'affidabilità del sistema. In Google Cloud, puoi aumentare la resilienza di un'applicazione implementando i componenti ridondanti di quella stessa applicazione in più zone di una singola regione1 o in più regioni, con funzionalità di passaggio. 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, con meccanismi di failover, necessaria per le tue applicazioni e i relativi componenti. Idealmente, dovresti prendere in considerazione la disponibilità di un servizio o di un'applicazione tra i vari componenti e l'infrastruttura di supporto (inclusa la disponibilità della connettività ibrida) in tutti gli ambienti. Questo concetto è noto anche come disponibilità composita di un'applicazione o di un servizio.

In base alle dipendenze tra i componenti o i servizi, la disponibilità composita di 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 che preferisci, definisci metriche di affidabilità chiare e progetta le applicazioni in modo che si riparino autonomamente e resistano alle interruzioni in modo efficace nei diversi ambienti. Per aiutarti a definire metodi appropriati per misurare l'esperienza dei clienti con i tuoi servizi, consulta Definire l'affidabilità in base agli obiettivi relativi all'esperienza utente.

Connettività ibrida e multi-cloud

I requisiti della comunicazione tra i componenti delle applicazioni distribuite devono influire sulla scelta di un'opzione di connettività di rete ibrida. Ogni opzione di connettività presenta vantaggi e svantaggi, nonché fattori specifici da prendere in considerazione, come costo, volume di traffico, sicurezza e così via. Per ulteriori informazioni, consulta la sezione Considerazioni sul design 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 aumentare i costi di sviluppo, test e gestione. Tecnicamente, più provider cloud utilizzi, più complessa diventa la gestione dei tuoi ambienti. La maggior parte dei fornitori di servizi cloud pubblico non solo dispone di funzionalità diverse, ma ha anche vari strumenti, SLA e API per la gestione dei servizi cloud. Pertanto, valuta i vantaggi strategici dell'architettura selezionata rispetto alla potenziale complessità a breve termine e ai vantaggi a lungo termine.

Costo

Ogni provider di servizi cloud in un ambiente multicloud ha le proprie metriche e i propri strumenti di fatturazione. Per una maggiore visibilità e dashboard unificate, valuta la possibilità di utilizzare strumenti di ottimizzazione e gestione dei costi multicloud. Ad esempio, quando si creano soluzioni cloud-first in più ambienti cloud, i prodotti, i prezzi, gli sconti e gli strumenti di gestione di ciascun fornitore possono creare incoerenze nei costi tra questi ambienti.

Ti consigliamo di avere un metodo unico e ben definito per calcolare i costi totali delle risorse cloud e di fornire visibilità sui costi. La visibilità dei costi è essenziale per l'ottimizzazione dei costi. Ad esempio, combinando i dati di fatturazione dei fornitori di cloud che utilizzi e utilizzando il Google Cloud blocco di gestione dei costi cloud di Looker, puoi creare una visualizzazione centralizzata dei costi multicloud. Questa visualizzazione può aiutarti a fornire una visualizzazione consolidata dei report sulla 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 le best practice FinOps per rendere visibili i costi. Nell'ambito di una solida pratica FinOps, un team centrale può delegare la presa di decisioni per l'ottimizzazione delle risorse a qualsiasi altro team coinvolto in un progetto per stimolare la responsabilità individuale. In questo modello, il team centrale deve standardizzare la procedura, i report e gli strumenti per l'ottimizzazione dei costi. Per ulteriori informazioni sui diversi aspetti e consigli di ottimizzazione dei costi da prendere in considerazione, consulta Google Cloud Framework di architettura: ottimizzazione dei costi.

Spostamento dei dati

Lo spostamento dei dati è un aspetto importante per la strategia e la pianificazione dell'architettura ibrida e multi-cloud, in particolare per i sistemi distribuiti. Le aziende devono identificare i diversi casi d'uso aziendali, i dati che li supportano e la classificazione dei dati (per i settori regolamentati). Inoltre, devono considerare in che modo la memorizzazione, la condivisione e l'accesso ai dati per i sistemi distribuiti in più ambienti possono influire sulle prestazioni delle applicazioni e sulla coerenza dei dati. Questi fattori potrebbero influenzare l'applicazione e l'architettura della pipeline di dati. L'insieme completo diGoogle Cloudopzioni di spostamento dei dati consente alle aziende di soddisfare le proprie esigenze specifiche e di adottare architetture ibride e multicloud senza compromettere la semplicità, l'efficienza o le prestazioni.

Sicurezza

Quando esegui la migrazione delle applicazioni al cloud, è importante prendere in considerazione funzionalità di sicurezza cloud-first come coerenza, osservabilità e visibilità della sicurezza unificata. Ogni provider di cloud pubblico ha il proprio approccio, le proprie best practice e le proprie funzionalità per la sicurezza. È importante analizzare e allineare queste funzionalità per creare un'architettura di sicurezza funzionale e standard. Anche controlli IAM efficaci, crittografia dei dati, analisi delle vulnerabilità e conformità alle normative di settore sono aspetti importanti della sicurezza del cloud.

Quando pianifichi una strategia di migrazione, ti consigliamo di analizzare le considerazioni sopra indicate. Possono aiutarti a ridurre al minimo le probabilità di introduzione di complessità nell'architettura man mano che le applicazioni o i volumi di traffico aumentano. Inoltre, la progettazione e la creazione di una landing zone è quasi sempre un prerequisito per il deployment dei carichi di lavoro aziendali in un ambiente cloud. Una zona di destinazione aiuta la tua azienda a 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 reti. Per ulteriori informazioni, consulta Design della zona di destinazione in Google Cloud.

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


  1. Per ulteriori informazioni sulle considerazioni specifiche per regione, consulta Geografia e regioni.