Questo documento del Google Cloud Well-Architected Framework: prospettiva dei servizi finanziari fornisce una panoramica dei principi e dei consigli per progettare, implementare e gestire carichi di lavoro affidabili per i servizi finanziari in Google Cloud. Il documento esplora come integrare pratiche avanzate di affidabilità e osservabilità nei tuoi progetti architettonici. I consigli contenuti in questo documento sono in linea con il pilastro dell'affidabilità del Well-Architected Framework.
Per gli istituti finanziari, un'infrastruttura affidabile e resiliente è sia un'esigenza aziendale che un imperativo normativo. Per garantire l'affidabilità dei workload FS in Google Cloud , devi comprendere e mitigare i potenziali punti di errore, eseguire il deployment delle risorse in modo ridondante e pianificare il ripristino. La resilienza operativa è un risultato dell'affidabilità. È la capacità di assorbire, adattarsi e riprendersi dalle interruzioni. La resilienza operativa aiuta le organizzazioni di servizi finanziari a soddisfare requisiti normativi rigorosi. Inoltre, contribuisce a evitare danni intollerabili ai clienti.
Gli elementi fondamentali dell'affidabilità in Google Cloud sono regioni, zone e i vari ambiti di località delle risorse cloud: zonale, regionale, multiregionale e globale. Puoi migliorare la disponibilità utilizzando servizi gestiti, distribuendo le risorse, implementando pattern di alta disponibilità e automatizzando i processi.
Requisiti normativi
Le organizzazioni di servizi finanziari operano nel rispetto di rigidi mandati di affidabilità da parte di enti normativi come il Federal Reserve System negli Stati Uniti, l' European Banking Authority nell'UE e la Prudential Regulation Authority nel Regno Unito. A livello globale, gli enti regolatori sottolineano la resilienza operativa, fondamentale per la stabilità finanziaria e la protezione dei consumatori. La resilienza operativa è la capacità di resistere alle interruzioni, ripristinare efficacemente e mantenere i servizi critici. Ciò richiede un approccio armonizzato per la gestione dei rischi tecnologici e delle dipendenze da terze parti.
I requisiti normativi nella maggior parte delle giurisdizioni hanno i seguenti temi comuni:
- Cybersicurezza e resilienza tecnologica: rafforzamento delle difese contro le minacce informatiche e garanzia della resilienza dei sistemi IT.
- Gestione dei rischi di terze parti: gestione dei rischi associati all'outsourcing di servizi a fornitori di tecnologie dell'informazione e della comunicazione (ICT).
- Continuità aziendale e risposta agli incidenti: pianificazione solida per mantenere le operazioni critiche durante le interruzioni e per ripristinarle in modo efficace.
- Protezione della stabilità finanziaria: garantire la solidità e la stabilità del sistema finanziario più ampio.
I consigli sull'affidabilità contenuti in questo documento sono mappati ai seguenti principi fondamentali:
- Dare la priorità ai deployment multizona e multiregionali
- Eliminare i single point of failure (SPOF)
- Comprendere e gestire la disponibilità aggregata
- Implementare una strategia di RE solida
- Sfruttare i servizi gestiti
- Automatizzare i processi di provisioning e ripristino dell'infrastruttura
Dai la priorità ai deployment multizona e multiregionali
Per le applicazioni di servizi finanziari critici, ti consigliamo di utilizzare una topologia multiregionale distribuita in almeno due regioni e in tre zone all'interno di ciascuna regione. Questo approccio è importante per la resilienza contro le interruzioni di zona e regione. I regolamenti spesso prescrivono questo approccio, perché se si verifica un errore in una zona o regione, la maggior parte delle giurisdizioni considera una grave interruzione in una seconda zona una conseguenza plausibile. Il motivo è che quando una posizione non funziona, l'altra posizione potrebbe ricevere un quantitativo eccezionalmente elevato di traffico aggiuntivo.
Prendi in considerazione i seguenti suggerimenti per aumentare la resilienza contro le interruzioni di zona e regione:
- Preferisci le risorse con un ambito geografico più ampio. Se possibile, utilizza risorse regionali anziché risorse di zona e risorse multiregionali o globali anziché risorse regionali. Questo approccio aiuta a evitare la necessità di ripristinare le operazioni utilizzando i backup.
- In ogni regione, utilizza tre zone anziché due. Per gestire i failover, esegui il provisioning della capacità di un terzo in più rispetto alla stima.
- Riduci al minimo i passaggi di ripristino manuale implementando deployment active-active
come i seguenti esempi:
- I database distribuiti come Spanner forniscono ridondanza e sincronizzazione integrate tra le regioni.
- La funzionalità HA di Cloud SQL fornisce una topologia quasi active-active, con repliche di lettura tra le zone. Fornisce un Recovery Point Objective (RPO) tra regioni vicino a 0.
- Distribuisci il traffico degli utenti tra le regioni utilizzando Cloud DNS e implementa un bilanciatore del carico regionale in ogni regione. Un bilanciatore del carico globale è un'altra opzione che puoi valutare in base ai tuoi requisiti e alla criticità. Per saperne di più, consulta Vantaggi e rischi del bilanciamento del carico globale per i deployment multiregionali.
- Per archiviare i dati, utilizza servizi multiregionali come Spanner e Cloud Storage.
Elimina i single point of failure
Distribuisci le risorse in diverse località e utilizza risorse ridondanti per impedire che un singolo punto di errore (SPOF) influisca sull'intero stack dell'applicazione.
Considera i seguenti suggerimenti per evitare SPOF:
- Evita di eseguire il deployment di un solo server delle applicazioni o database.
- Assicurati la ricreazione automatica delle VM non riuscite utilizzando i gruppi di istanze gestite (MIG).
- Distribuisci il traffico in modo uniforme tra le risorse disponibili implementando il bilanciamento del carico.
- Utilizza configurazioni HA per database come Cloud SQL.
- Migliora la disponibilità dei dati utilizzando i dischi permanenti a livello di regione con la replica sincrona.
Per saperne di più, vedi Progettare un'infrastruttura affidabile per i tuoi carichi di lavoro in Google Cloud.
Comprendere e gestire la disponibilità aggregata
Tieni presente che la disponibilità complessiva o aggregata di un sistema è influenzata dalla disponibilità di ogni livello o componente del sistema. Il numero di livelli in uno stack di applicazioni ha una relazione inversa con la disponibilità aggregata dello stack. Considera i seguenti suggerimenti per la gestione della disponibilità aggregata:
Calcola la disponibilità aggregata di uno stack multilivello utilizzando la formula tier1_availability × tier2_availability × tierN_availability.
Il seguente diagramma mostra il calcolo della disponibilità aggregata per un sistema multilivello composto da quattro servizi:
Nel diagramma precedente, il servizio in ogni livello fornisce una disponibilità del 99,9%, ma la disponibilità aggregata del sistema è inferiore, pari al 99,6% (0,999 × 0,999 × 0,999 × 0,999). In generale, la disponibilità aggregata di uno stack multilivello è inferiore alla disponibilità del livello che offre la disponibilità minima.
Ove possibile, scegli la parallelizzazione anziché il concatenamento. Con i servizi parallelizzati, la disponibilità end-to-end è superiore a quella di ogni singolo servizio.
Il seguente diagramma mostra due servizi, A e B, di cui viene eseguito il deployment utilizzando gli approcci di concatenamento e parallelizzazione:
Negli esempi precedenti, entrambi i servizi hanno uno SLA del 99%, il che comporta la seguente disponibilità aggregata a seconda dell'approccio di implementazione:
- I servizi concatenati producono una disponibilità aggregata di solo il 98% (0,99 × 0,99).
- I servizi parallelizzati offrono una disponibilità aggregata superiore pari al 99,99% perché ogni servizio viene eseguito in modo indipendente e i singoli servizi non sono interessati dalla disponibilità degli altri servizi. La formula per i servizi parallelizzati aggregati è 1 − (1 − A) × (1 − B).
Scegli Google Cloud servizi con SLA di uptime che possono aiutarti a raggiungere il livello di uptime complessivo richiesto per il tuo stack di applicazioni.
Quando progetti l'architettura, considera i compromessi tra disponibilità, complessità operativa, latenza e costi. Aumentare il numero di nove di disponibilità generalmente costa di più, ma ti aiuta a soddisfare i requisiti normativi.
Ad esempio, una disponibilità del 99,9% (tre nove) significa un potenziale tempo di inattività di 86 secondi in un giorno di 24 ore. Al contrario, il 99% (due nove) significa un tempo di inattività di 864 secondi nello stesso periodo, ovvero 10 volte superiore rispetto a una disponibilità di tre nove.
Per i servizi finanziari critici, le opzioni di architettura potrebbero essere limitate. Tuttavia, è fondamentale identificare i requisiti di disponibilità e calcolare con precisione la disponibilità. L'esecuzione di una valutazione di questo tipo ti aiuta a valutare le implicazioni delle tue decisioni di progettazione sull'architettura e sul budget.
Implementa una solida strategia di RE
Crea piani ben definiti per diversi scenari di disastro, tra cui interruzioni zonali e regionali. Una strategia di ripristino di emergenza (RE) ben definita ti consente di ripristinare le normali operazioni con un impatto minimo in seguito a un'interruzione.
RE e l'alta affidabilità sono concetti diversi. Con i deployment cloud, in generale, RE si applica ai deployment multiregionali e l'alta affidabilità ai deployment regionali. Questi archetipi di deployment supportano meccanismi di replica diversi.
- HA: molti servizi gestiti forniscono la replica sincrona tra le zone all'interno di una singola regione per impostazione predefinita. Questi servizi supportano un Recovery Time Objective (RTO) e un Recovery Point Objective (RPO) pari a zero o quasi zero. Questo supporto ti consente di creare una topologia di deployment active-active che non ha SPOF.
- DR: per i carichi di lavoro di cui è stato eseguito il deployment in due o più regioni, se non utilizzi servizi multiregionali o globali, devi definire una strategia di replica. La strategia di replica è in genere asincrona. Valuta attentamente in che modo questa replica influisce su RTO e RPO per le applicazioni critiche. Identifica le operazioni manuali o semiautomatiche necessarie per il failover.
Per gli istituti finanziari, la scelta della regione di failover potrebbe essere limitata da normative sulla sovranità dei dati e sulla residenza dei dati. Se hai bisogno di una topologia active-active in due regioni, ti consigliamo di scegliere servizi multiregionali gestiti, come Spanner e Cloud Storage, soprattutto quando la replica dei dati è fondamentale.
Prendi in considerazione i seguenti consigli:
- Utilizza servizi di archiviazione multiregionali gestiti per i dati.
- Crea snapshot dei dati nei Persistent Disk e archiviali in località multiregionali.
- Quando utilizzi risorse regionali o di zona, configura la replica dei dati in altre regioni.
- Convalida l'efficacia dei piani di RE testandoli regolarmente.
- Tieni presente l'RTO e l'RPO e la loro correlazione con la tolleranza all'impatto prevista dai regolamenti finanziari nella tua giurisdizione.
Per saperne di più, consulta Progettare ripristino di emergenza per interruzioni dell'infrastruttura cloud.
Sfruttare i servizi gestiti
Quando possibile, utilizza i servizi gestiti per sfruttare le funzionalità integrate per backup, HA e scalabilità. Considera i seguenti consigli per l'utilizzo dei servizi gestiti:
- Utilizza i servizi gestiti in Google Cloud. Forniscono alta disponibilità supportata da SLA. Offrono anche meccanismi di backup e funzionalità di resilienza integrati.
- Per la gestione dei dati, valuta servizi come Cloud SQL, Cloud Storage e Spanner,
- Per l'hosting di calcolo e applicazioni, valuta la possibilità di utilizzare i gruppi di istanze gestite (MIG) di Compute Engine e i cluster Google Kubernetes Engine (GKE). I MIG regionali e i cluster GKE regionali sono resilienti alle interruzioni di zona.
- Per migliorare la resilienza contro le interruzioni di servizio a livello di regione, utilizza i servizi multiregionali gestiti.
- Identifica la necessità di piani di uscita per i servizi con caratteristiche uniche e definisci i piani richiesti. Gli enti di regolamentazione finanziaria come FCA, PRA ed EBA richiedono alle aziende di disporre di strategie e piani di emergenza per il recupero dei dati e la continuità operativa in caso di interruzione del rapporto con un fornitore di servizi cloud. Le aziende devono valutare la fattibilità dell'uscita prima di stipulare contratti cloud e devono mantenere la possibilità di cambiare provider senza interruzioni operative.
- Verifica che i servizi che scegli supportino l'esportazione dei dati in un formato aperto come CSV, Parquet e Avro. Verifica se i servizi si basano su tecnologie aperte, come il supporto di GKE per il formato Open Container Initiative (OCI) o Managed Service for Apache Airflow basato su Apache Airflow.
Automatizza i processi di provisioning e ripristino dell'infrastruttura
L'Automation contribuisce a ridurre al minimo gli errori umani e a diminuire il tempo e le risorse necessari per rispondere agli incidenti. L'utilizzo dell'automazione può contribuire a garantire un ripristino più rapido dagli errori e risultati più coerenti. Considera i seguenti suggerimenti per automatizzare il provisioning e il recupero delle risorse:
- Ridurre al minimo gli errori umani utilizzando strumenti Infrastructure as Code (IaC) come <x0A>Terraform.
- Ridurre l'intervento manuale automatizzando le procedure di failover. Le risposte automatiche possono anche contribuire a ridurre l'impatto degli errori. Ad esempio, puoi utilizzare Eventarc o Workflows per attivare automaticamente azioni correttive in risposta ai problemi osservati tramite i log di controllo.
- Aumenta la capacità delle risorse cloud durante il failover utilizzando la scalabilità automatica.
- Applica automaticamente criteri e protezioni per i requisiti normativi nell'intera topologia cloud durante il deployment del servizio adottando l'ingegneria della piattaforma.