Prospettiva dei servizi finanziari: affidabilità

Questo documento del Google Cloud Well-Architected Framework: prospettiva FSI fornisce una panoramica dei principi e dei consigli per progettare, implementare e gestire carichi di lavoro affidabili del settore dei servizi finanziari (FSI) in Google Cloud. Il documento illustra come integrare pratiche avanzate di affidabilità e osservabilità nei tuoi progetti architettonici. I suggerimenti 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 carichi di lavoro FSI in Google Cloud , devi comprendere e mitigare i potenziali punti di errore, distribuire le 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 FSI a soddisfare i rigorosi requisiti normativi. Inoltre, contribuisce a evitare danni intollerabili ai clienti.

Gli elementi fondamentali dell'affidabilità in Google Cloud sono le regioni, le 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 FSI operano in base a 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, che è 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:

• Resilienza informatica e 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 suggerimenti sull'affidabilità contenuti in questo documento sono mappati ai seguenti principi fondamentali:

• Dai 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 località non funziona, l'altra potrebbe ricevere un quantità eccezionalmente elevata 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 consente di 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 prossimo a 0.
• Distribuisci il traffico degli utenti tra le regioni utilizzando Cloud DNS ed esegui il deployment di un bilanciatore del carico regionale in ogni regione. Un bilanciatore del carico globale è un'altra opzione che puoi prendere in considerazione a seconda dei tuoi requisiti e della criticità. Per ulteriori informazioni, 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.

Prendi in considerazione 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 a più livelli è 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 soddisfare il livello di uptime complessivo richiesto per lo 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 sulla tua architettura e sul tuo 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 riprenderti da un'interruzione e riprendere le normali operazioni con un impatto minimo.

RE e l'alta disponibilità 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 diversi meccanismi di replica.

• 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. Questo supporto ti consente di creare una topologia di deployment active-active che non presenta 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à 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 multiregionale gestiti per i dati.
• Crea snapshot dei dati nei dischi permanenti 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 ulteriori informazioni, consulta Progettazione 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à. Prendi in considerazione i seguenti consigli per l'utilizzo dei servizi gestiti:

• Utilizza i servizi gestiti in Google Cloud. Forniscono HA 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 regionale, utilizza 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 Cloud Composer 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.
• Riduci 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 nella topologia cloud durante il deployment del servizio adottando l'ingegneria della piattaforma.