Este documento do Google Cloud Well-Architected Framework: perspectiva de instituições financeiras fornece uma visão geral dos princípios e recomendações para projetar, implantar e operar cargas de trabalho confiáveis do setor de serviços financeiros (FSI, na sigla em inglês) no Google Cloud. O documento explica como integrar práticas avançadas de confiabilidade e capacidade de observação aos seus projetos arquitetônicos. As recomendações neste documento estão alinhadas ao pilar de confiabilidade do framework bem arquitetado.
Para instituições financeiras, uma infraestrutura confiável e resiliente é uma necessidade comercial e um imperativo regulatório. Para garantir a confiabilidade das cargas de trabalho de FSI em Google Cloud , é necessário entender e reduzir possíveis pontos de falha, implantar recursos de forma redundante e planejar a recuperação. A resiliência operacional é um resultado da confiabilidade. É a capacidade de absorver, se adaptar e se recuperar de interrupções. A resiliência operacional ajuda as organizações de serviços financeiros a atender a requisitos regulamentares rigorosos. Isso também ajuda a evitar danos intoleráveis aos clientes.
Os principais elementos de confiabilidade no Google Cloud são regiões, zonas e os vários escopos de localização dos recursos de nuvem: zonal, regional, multirregional e global. É possível melhorar a disponibilidade usando serviços gerenciados, distribuindo recursos, implementando padrões de alta disponibilidade e automatizando processos.
Requisitos regulatórios
As organizações de serviços financeiros operam sob mandatos de confiabilidade rigorosos de agências regulatórias, como o Federal Reserve System (em inglês) nos EUA, a Autoridade Bancária Europeia (em inglês) na UE e a Autoridade de Regulamentação Prudencial (em inglês) no Reino Unido. No mundo todo, 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, se recuperar de maneira eficaz e manter serviços críticos. Isso exige uma abordagem harmonizada para gerenciar riscos tecnológicos e dependências de terceiros.
Os requisitos regulamentares na maioria das jurisdições têm os seguintes temas em comum:
- Segurança cibernética e resiliência tecnológica: fortalecimento das defesas contra ameaças cibernéticas e garantia da resiliência dos sistemas de TI.
- Gerenciamento de riscos de terceiros: gerenciamento dos riscos associados à terceirização de serviços para provedores de tecnologia da informação e comunicação (TIC).
- Continuidade de negócios e resposta a incidentes: planejamento robusto para manter as operações críticas durante interrupções e se recuperar de maneira eficaz.
- Proteção da estabilidade financeira: garantir a integridade e a estabilidade do sistema financeiro em geral.
As recomendações de confiabilidade neste documento são mapeadas para os seguintes princípios básicos:
- Priorize implantações multirregionais e de várias zonas
- Elimine pontos únicos de falha (SPOFs)
- Entender e gerenciar a disponibilidade agregada
- Implementar uma estratégia de DR robusta
- Aproveite os serviços gerenciados
- Automatizar os processos de provisionamento e recuperação de infraestrutura
Priorizar implantações multizona e multirregionais
Para aplicativos financeiros críticos, recomendamos o uso de uma topologia multirregional distribuída em pelo menos duas regiões e três zonas em cada região. Essa abordagem é importante para a resiliência contra interrupções de zona e região. As regulamentações costumam prescrever essa abordagem porque, se ocorrer uma falha em uma zona ou região, a maioria das jurisdições considera uma interrupção grave em uma segunda zona como uma consequência plausível. A lógica é que, quando um local falha, o outro pode receber uma quantidade excepcionalmente alta de tráfego adicional.
Considere as seguintes recomendações para criar resiliência contra falhas de zona e região:
- Prefira recursos com um escopo geográfico mais amplo. Sempre que possível, use recursos regionais em vez de zonais e multirregionais ou globais em vez de regionais. Essa abordagem ajuda a evitar a necessidade de restaurar operações usando backups.
- Em cada região, use três zonas em vez de duas. Para lidar com failovers, faça um superprovisionamento de capacidade em um terço a mais do que a estimativa.
- Minimize as etapas de recuperação manual implementando implantações ativas-ativas, como os exemplos a seguir:
- Bancos de dados distribuídos, como o Spanner, oferecem redundância e sincronização integradas em todas as regiões.
- O recurso de alta disponibilidade do Cloud SQL oferece uma topologia quase ativa-ativa, com réplicas de leitura em todas as zonas. Ele oferece um objetivo de ponto de recuperação (RPO) entre regiões próximo a 0.
- Distribua o tráfego de usuários entre regiões usando o Cloud DNS e implante um balanceador de carga regional em cada região. Outra opção que você pode considerar, dependendo dos seus requisitos e da importância, é um balanceador de carga global. Para mais informações, consulte Benefícios e riscos do balanceamento de carga global para implantações multirregionais.
- Para armazenar dados, use serviços multirregionais, como o Spanner e o Cloud Storage.
Eliminar pontos únicos de falha
Distribua recursos em diferentes locais e use recursos redundantes para evitar que um único ponto de falha (SPOF) afete toda a pilha de aplicativos.
Considere as seguintes recomendações para evitar SPOFs:
- Evite implantar apenas um servidor de aplicativos ou banco de dados.
- Use grupos gerenciados de instâncias (MIGs) para garantir a recriação automática de VMs com falha.
- Distribua o tráfego de maneira uniforme entre os recursos disponíveis implementando o balanceamento de carga.
- Use configurações de alta disponibilidade para bancos de dados como o Cloud SQL.
- Melhore a disponibilidade de dados usando discos permanentes regionais com replicação síncrona.
Para mais informações, consulte Criar uma infraestrutura confiável para suas cargas de trabalho no Google Cloud.
Entender e gerenciar a disponibilidade agregada
A disponibilidade geral ou agregada de um sistema é afetada pela disponibilidade de cada nível ou componente dele. O número de níveis em uma pilha de aplicativos tem uma relação inversa com a disponibilidade agregada da pilha. Considere as seguintes recomendações para gerenciar a disponibilidade agregada:
Calcule a disponibilidade agregada de uma pilha de vários níveis usando a fórmula disponibilidade_nível1 × disponibilidade_nível2 × disponibilidade_nívelN.
O diagrama a seguir mostra o cálculo da disponibilidade agregada para um sistema de várias camadas que consiste em quatro serviços:
No diagrama anterior, o serviço em cada nível oferece 99,9% de disponibilidade, mas a disponibilidade agregada do sistema é menor, de 99,6% (0,999 × 0,999 × 0,999 × 0,999). Em geral, a disponibilidade agregada de uma pilha de vários níveis é menor que a disponibilidade do nível que oferece a menor disponibilidade.
Sempre que possível, escolha paralelização em vez de encadeamento. Com serviços paralelizados, a disponibilidade de ponta a ponta é maior do que a disponibilidade de cada serviço individual.
O diagrama a seguir mostra dois serviços, A e B, implantados usando as abordagens de encadeamento e paralelização:
Nos exemplos anteriores, os dois serviços têm um SLA de 99%, o que resulta na seguinte disponibilidade agregada, dependendo da abordagem de implementação:
- Serviços encadeados geram uma disponibilidade agregada de apenas 98% (0,99 × 0,99).
- Serviços paralelizados geram uma disponibilidade agregada maior, 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 paralelos agregados é 1 − (1 − A) × (1 − B).
Escolha serviços Google Cloud com SLAs de tempo de atividade que podem ajudar a atender ao nível necessário de tempo de atividade geral para sua pilha de aplicativos.
Ao projetar sua arquitetura, considere as vantagens e desvantagens entre disponibilidade, complexidade operacional, latência e custo. Aumentar o número de noves de disponibilidade geralmente custa mais, mas ajuda você a atender aos requisitos regulamentares.
Por exemplo, uma disponibilidade de 99,9% (três noves) significa um possível tempo de inatividade de 86 segundos em um dia de 24 horas. Por outro lado, 99% (dois noves) significa um tempo de inatividade de 864 segundos no mesmo período, que é 10 vezes maior 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. Realizar essa avaliação ajuda você a entender as implicações das suas decisões de design na arquitetura e no orçamento.
Implementar uma estratégia de DR robusta
Crie planos bem definidos para diferentes cenários de desastre, incluindo interrupções zonais e regionais. Com uma estratégia de recuperação de desastres (DR) bem definida, é possível se recuperar de uma interrupção e retomar as operações normais com o mínimo de impacto.
DR e alta disponibilidade (HA) são conceitos diferentes. Com implantações na nuvem, em geral, a recuperação de DR se aplica a implantações multirregionais, e a alta disponibilidade se aplica a implantações regionais. Esses arquétipos de implantação oferecem suporte a diferentes mecanismos de replicação.
- HA: muitos serviços gerenciados oferecem replicação síncrona entre zonas em uma única região por padrão. Esses serviços oferecem um objetivo de tempo de recuperação (RTO) e um objetivo de ponto de recuperação (RPO) de zero ou quase zero. Com esse suporte, é possível criar uma topologia de implantação ativo-ativo sem SPOF.
- DR: para cargas de trabalho implantadas em duas ou mais regiões, se você não usar serviços multirregionais ou globais, defina uma estratégia de replicação. A estratégia de replicação normalmente é assíncrona. Avalie com cuidado como essa replicação afeta o RTO e o RPO de aplicativos críticos. Identifique as operações manuais ou semiautomáticas necessárias para o failover.
Para instituições financeiras, a escolha da região de failover pode ser limitada por regulamentações sobre soberania e residência de dados. Se você precisar de uma topologia ativo-ativo em duas regiões, recomendamos escolher serviços multirregionais gerenciados, como o Spanner e o Cloud Storage, principalmente quando a replicação de dados é essencial.
Considere as seguintes recomendações:
- Use serviços de armazenamento gerenciados e multirregionais para dados.
- Crie snapshots de dados em discos permanentes e armazene-os em locais multirregionais.
- Ao usar recursos regionais ou por zona, configure a replicação de dados para outras regiões.
- Teste o plano regularmente para validar a eficácia dele.
- Conheça o RTO e o RPO e a correlação deles com a tolerância a impactos estipulada pelas regulamentações financeiras na sua jurisdição.
Para mais informações, consulte Como arquitetar a recuperação de desastres para interrupções de infraestrutura em nuvem.
Aproveitar serviços gerenciados
Sempre que possível, use serviços gerenciados para aproveitar os recursos integrados de backups, alta disponibilidade e escalonabilidade. Considere as seguintes recomendações para usar serviços gerenciados:
- Use serviços gerenciados em Google Cloud. Eles oferecem alta disponibilidade com suporte de SLAs. Eles também oferecem mecanismos de backup e recursos de resiliência integrados.
- Para gerenciamento de dados, considere serviços como Cloud SQL, Cloud Storage e Spanner.
- Para hospedagem de computação e aplicativos, considere os grupos de instâncias gerenciadas (MIGs) do Compute Engine e os clusters do Google Kubernetes Engine (GKE). Os MIGs regionais e os clusters regionais do GKE são resilientes a interrupções de zona.
- Para melhorar a resiliência contra interrupções regionais, use serviços multirregionais gerenciados.
- Identifique a necessidade de planos de saída para serviços com características exclusivas e defina os planos necessários. Reguladores financeiros como a FCA, a PRA e a EBA exigem que as empresas tenham estratégias e planos de contingência para recuperação de dados e continuidade operacional se a relação com um provedor de nuvem terminar. As empresas precisam avaliar a viabilidade de saída antes de firmar contratos de nuvem e manter a capacidade de mudar de provedor sem interrupção operacional.
- Verifique se os serviços escolhidos permitem exportar dados para um formato aberto, como CSV, Parquet e Avro. Verifique se os serviços são baseados em tecnologias abertas, como o suporte do GKE para o formato da Open Container Initiative (OCI) ou Cloud Composer criado no Apache Airflow.
Automatizar os processos de provisionamento e recuperação da infraestrutura
Automation ajuda a minimizar erros humanos e reduzir o tempo e os recursos necessários para responder a incidentes. O uso da automaçã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 provisionamento e a recuperação de recursos:
- Minimize os erros humanos usando ferramentas de infraestrutura como código (IaC), como o Terraform.
- Reduza a intervenção manual automatizando processos de failover. As respostas automáticas também podem ajudar a reduzir o impacto das falhas. Por exemplo, é possível usar o Eventarc ou Workflows para acionar automaticamente ações corretivas em resposta a problemas observados nos registros de auditoria.
- Aumente a capacidade dos seus recursos de nuvem durante o failover usando o escalonamento automático.
- Aplique automaticamente políticas e proteções para requisitos regulamentares em toda a topologia da nuvem durante a implantação do serviço ao adotar a engenharia de plataforma.