Este documento no Google Cloud Well-Architected Framework: FSI perspective oferece uma vista geral dos princípios e das recomendações para conceber, implementar e operar cargas de trabalho fiáveis da indústria de serviços financeiros (FSI) no Google Cloud. O documento explora como integrar práticas de fiabilidade avançadas e observabilidade nos seus planos arquitetónicos. As recomendações neste documento estão alinhadas com o pilar de fiabilidade da framework bem arquitetada.
Para as instituições financeiras, uma infraestrutura fiável e resiliente é uma necessidade empresarial e um imperativo regulamentar. Para garantir que as cargas de trabalho de FSI no Google Cloud são fiáveis, tem de compreender e mitigar potenciais pontos de falha, implementar recursos de forma redundante e planear a recuperação. A resiliência operacional é um resultado da fiabilidade. É a capacidade de absorver, adaptar-se e recuperar de interrupções. A resiliência operacional ajuda as organizações de FSI a cumprir requisitos regulamentares rigorosos. Também ajuda a evitar danos intoleráveis aos clientes.
Os elementos essenciais da fiabilidade são as regiões, as zonas e os vários âmbitos de localização dos recursos na nuvem: zonal, regional, multirregional e global. Google Cloud Pode melhorar a disponibilidade usando serviços geridos, distribuindo recursos, implementando padrões de alta disponibilidade e automatizando processos.
Requisitos regulamentares
As organizações de ISF operam sob mandatos de fiabilidade rigorosos de agências reguladoras, como o Federal Reserve System nos EUA, a Autoridade Bancária Europeia na UE e a Prudential Regulation Authority no Reino Unido. A nível global, os reguladores enfatizam a resiliência operacional, que é vital para a estabilidade financeira e a proteção do consumidor. A resiliência operacional é a capacidade de resistir a interrupções, recuperar de forma eficaz e manter serviços críticos. Isto requer uma abordagem harmonizada para gerir os riscos tecnológicos e as dependências de terceiros.
Os requisitos regulamentares na maioria das jurisdições têm os seguintes temas comuns:
- Cibersegurança e resiliência tecnológica: reforçar as defesas contra ciberameaças e garantir a resiliência dos sistemas de TI.
- Gestão de riscos de terceiros: gestão dos riscos associados à subcontratação de serviços a fornecedores de tecnologias de informação e comunicação (TIC).
- Continuidade do negócio e resposta a incidentes: planeamento robusto para manter as operações críticas durante as interrupções e para recuperar de forma eficaz.
- Proteger a estabilidade financeira: garantir a solidez e a estabilidade do sistema financeiro em geral.
As recomendações de fiabilidade neste documento estão mapeadas para os seguintes princípios fundamentais:
- Dê prioridade às implementações multizona e multirregião
- Elimine pontos únicos de falha (SPOFs)
- Compreenda e faça a gestão da disponibilidade agregada
- Implemente uma estratégia de recuperação de desastres robusta
- Tire partido dos serviços geridos
- Automatize os processos de aprovisionamento e recuperação da infraestrutura
Dê prioridade a implementações multirregionais e em várias zonas
Para aplicações de serviços financeiros críticas, recomendamos que use uma topologia de várias regiões distribuída por, pelo menos, duas regiões e por três zonas em cada região. Esta abordagem é importante para a resiliência contra indisponibilidades de zonas e regiões. Os regulamentos prescrevem frequentemente esta abordagem, porque se ocorrer uma falha numa zona ou região, a maioria das jurisdições considera uma interrupção grave numa segunda zona uma consequência plausível. A razão é que, quando uma localização falha, a outra localização pode receber uma quantidade excecionalmente elevada de tráfego adicional.
Considere as seguintes recomendações para criar resiliência contra interrupções ao nível da zona e da região:
- Preferir recursos com um âmbito geográfico mais amplo. Sempre que possível, use recursos regionais em vez de recursos zonais e use recursos multirregionais ou globais em vez de recursos regionais. Esta abordagem ajuda a evitar a necessidade de restaurar operações através de cópias de segurança.
- Em cada região, tire partido de três zonas em vez de duas. Para processar as comutações por falha, aumente a capacidade em um terço em relação à estimativa.
- Minimize os passos de recuperação manual implementando implementações ativas-ativas, como os seguintes exemplos:
- As bases de dados distribuídas, como o Spanner, oferecem redundância incorporada e sincronização entre regiões.
- A funcionalidade de HA do Cloud SQL oferece uma topologia quase ativa-ativa, com réplicas de leitura em várias zonas. Oferece um objetivo de ponto de recuperação (OPR) entre regiões próximo de 0.
- Distribua o tráfego de utilizadores por várias regiões através do Cloud DNS e implemente um balanceador de carga regional em cada região. Um equilibrador de carga global é outra opção que pode considerar consoante os seus requisitos e criticidade. Para mais informações, consulte o artigo Vantagens e riscos do balanceamento de carga global para implementações em várias regiões.
- Para armazenar dados, use serviços multirregionais como o Spanner e o Cloud Storage.
Elimine pontos únicos de falha
Distribua os recursos por diferentes localizações e use recursos redundantes para evitar que um único ponto de falha (SPOF) afete toda a pilha de aplicações.
Considere as seguintes recomendações para evitar SPOFs:
- Evite implementar apenas um servidor de aplicações ou uma base de dados.
- Garanta a recriação automática de VMs com falhas através de grupos de instâncias geridas (GIGs).
- Distribua o tráfego uniformemente pelos recursos disponíveis implementando o equilíbrio de carga.
- Use configurações de HA para bases de dados como o Cloud SQL.
- Melhore a disponibilidade dos dados usando discos persistentes regionais com replicação síncrona.
Para mais informações, consulte o artigo Crie uma infraestrutura fiável para as suas cargas de trabalho no Google Cloud.
Compreenda e faça a gestão da disponibilidade agregada
Tenha em atenção que a disponibilidade geral ou agregada de um sistema é afetada pela disponibilidade de cada nível ou componente do sistema. O número de camadas numa pilha de aplicações tem uma relação inversa com a disponibilidade agregada da pilha. Considere as seguintes recomendações para gerir a disponibilidade agregada:
Calcule a disponibilidade agregada de uma pilha de vários níveis através da fórmula disponibilidade_nível1 × disponibilidade_nível2 × disponibilidade_nívelN.
O diagrama seguinte mostra o cálculo da disponibilidade agregada para um sistema de vários níveis composto por quatro serviços:
No diagrama anterior, o serviço em cada nível oferece uma disponibilidade de 99,9%, mas a disponibilidade agregada do sistema é inferior, de 99,6% (0,999 × 0,999 × 0,999 × 0,999). Em geral, a disponibilidade agregada de uma pilha de vários níveis é inferior à disponibilidade do nível que oferece a menor disponibilidade.
Sempre que possível, escolha a paralelização em vez da encadeamento. Com os serviços paralelizados, a disponibilidade ponto a ponto é superior à disponibilidade de cada serviço individual.
O diagrama seguinte mostra dois serviços, A e B, implementados através das abordagens de encadeamento e paralelização:
Nos exemplos anteriores, ambos os serviços têm um SLA de 99%, o que resulta na seguinte disponibilidade agregada, consoante a abordagem de implementação:
- Os serviços encadeados geram uma disponibilidade agregada de apenas 98% (0,99 × 0,99).
- Os serviços paralelizados geram uma disponibilidade agregada mais elevada de 99,99%, porque cada serviço é executado de forma independente e os serviços individuais não são afetados pela disponibilidade dos outros serviços. A fórmula para serviços paralelizados agregados é 1 − (1 − A) × (1 − B).
Escolha Google Cloud serviços com SLAs de tempo de atividade que podem ajudar a cumprir o nível necessário de tempo de atividade geral para a sua pilha de aplicações.
Quando cria a sua arquitetura, considere os compromissos entre a disponibilidade, a complexidade operacional, a latência e o custo. Aumentar o número de noves de disponibilidade geralmente custa mais, mas fazê-lo ajuda a cumprir os requisitos regulamentares.
Por exemplo, uma disponibilidade de 99,9% (três noves) significa um potencial tempo de inatividade de 86 segundos num dia de 24 horas. Em contrapartida, 99% (dois noves) significa um tempo de inatividade de 864 segundos durante o mesmo período, o que representa 10 vezes mais tempo de inatividade do que com três noves de disponibilidade.
Para serviços financeiros críticos, as opções de arquitetura podem ser limitadas. No entanto, é fundamental identificar os requisitos de disponibilidade e calcular a disponibilidade com precisão. A realização de tal avaliação ajuda a avaliar as implicações das suas decisões de design na sua arquitetura e orçamento.
Implemente uma estratégia de recuperação de desastres robusta
Crie planos bem definidos para diferentes cenários de desastre, incluindo interrupções zonais e regionais. Uma estratégia de recuperação de desastres (RD) bem definida permite-lhe recuperar de uma interrupção e retomar as operações normais com um impacto mínimo.
A RD e a alta disponibilidade (AD) são conceitos diferentes. Com as implementações na nuvem, em geral, a recuperação de desastres aplica-se a implementações multirregionais e a alta disponibilidade aplica-se a implementações regionais. Estes arquétipos de implementação suportam diferentes mecanismos de replicação.
- HA: muitos serviços geridos oferecem replicação síncrona entre zonas numa única região por predefinição. Estes serviços suportam um objetivo de tempo de recuperação (RTO) e um objetivo de ponto de recuperação (RPO) de zero ou quase zero. Este suporte permite-lhe criar uma topologia de implementação ativa-ativa que não tem nenhum SPOF.
- DR: para cargas de trabalho implementadas em duas ou mais regiões, se não usar serviços multirregionais ou globais, tem de definir uma estratégia de replicação. Normalmente, a estratégia de replicação é assíncrona. Avalie cuidadosamente como essa replicação afeta o RTO e o RPO para aplicações críticas. Identifique as operações manuais ou semiautomáticas necessárias para a comutação por falha.
Para instituições financeiras, a sua escolha da região de alternativa pode estar limitada por regulamentos relativos à soberania e à residência dos dados. Se precisar de uma topologia ativo-ativo em duas regiões, recomendamos que escolha serviços multirregionais geridos, como o Spanner e o Cloud Storage, especialmente quando a replicação de dados é fundamental.
Considere as seguintes recomendações:
- Use serviços de armazenamento multirregionais geridos para dados.
- Tire capturas instantâneas de dados em discos persistentes e armazene-as em localizações multirregionais.
- Quando usa recursos regionais ou zonais, configure a replicação de dados para outras regiões.
- Valide se os seus planos de recuperação de desastres são eficazes testando-os regularmente.
- Tenha em atenção o RTO e o RPO, bem como a respetiva correlação com a tolerância ao impacto estipulada pelos regulamentos financeiros na sua jurisdição.
Para mais informações, consulte o artigo Arquitetar a recuperação de desastres para interrupções da infraestrutura na nuvem.
Aproveite os serviços geridos
Sempre que possível, use serviços geridos para tirar partido das funcionalidades incorporadas para cópias de segurança, HA e escalabilidade. Considere as seguintes recomendações para usar serviços geridos:
- Use serviços geridos no Google Cloud. Oferecem HA com base em SLAs. Também oferecem mecanismos de cópia de segurança integrados e funcionalidades de resiliência.
- Para a gestão de dados, considere serviços como o Cloud SQL, Cloud Storage, e o Spanner,
- Para a computação e o alojamento de aplicações, considere os grupos de instâncias geridas (GIGs) do Compute Engine e os clusters do Google Kubernetes Engine (GKE). Os GIGs regionais e os clusters regionais do GKE são resilientes a falhas de zonas.
- Para melhorar a resiliência em caso de interrupções regionais, use serviços multirregionais geridos.
- Identifique a necessidade de planos de saída para serviços com características únicas e defina os planos necessários. Os reguladores financeiros, como a FCA, a PRA e a EBA, exigem que as empresas tenham estratégias e planos de contingência para a obtenção de dados e a continuidade operacional se a relação com um fornecedor de nuvem terminar. As empresas têm de avaliar a viabilidade da saída antes de celebrar contratos de nuvem e têm de manter a capacidade de alterar fornecedores sem interrupções operacionais.
- Verifique se os serviços que escolher suportam a exportação de dados para um formato aberto, como CSV, Parquet e Avro. Verifique se os serviços se baseiam em tecnologias abertas, como o suporte do GKE para o formato da Open Container Initiative (OCI) ou o Cloud Composer criado no Apache Airflow.
Automatize os processos de aprovisionamento e recuperação de infraestruturas
A automatização ajuda a minimizar os erros humanos e a reduzir o tempo e os recursos necessários para responder a incidentes. A utilização da automatização pode ajudar a garantir uma recuperação mais rápida de falhas e resultados mais consistentes. Considere as seguintes recomendações para automatizar o aprovisionamento e a recuperação de recursos:
- Minimize os erros humanos através de ferramentas de infraestrutura como código (IaC), como o Terraform.
- Reduza a intervenção manual automatizando os processos de comutação por falha. As respostas automáticas também podem ajudar a reduzir o impacto das falhas. Por exemplo, pode usar o Eventarc ou os Workflows para acionar automaticamente ações corretivas em resposta a problemas observados através dos registos de auditoria.
- Aumente a capacidade dos seus recursos na nuvem durante a comutação por falha através do dimensionamento automático.
- Aplique automaticamente políticas e salvaguardas para requisitos regulamentares na topologia da nuvem durante a implementação de serviços através da adoção da engenharia de plataformas.