Este documento na Google Cloud perspectiva de serviços financeiros (FS, na sigla em inglês) do Well-Architected Framework oferece uma visão geral dos princípios e recomendações para projetar, implantar, e operar cargas de trabalho confiáveis de FS em Google Cloud. O documento explica como integrar práticas avançadas de confiabilidade e observabilidade aos seus projetos arquitetônicos. As recomendações neste documento estão alinhadas ao pilar de confiabilidade do Well-Architected Framework.
Para instituições financeiras, uma infraestrutura confiável e resiliente é uma necessidade comercial e um imperativo regulatório. Para garantir que as cargas de trabalho de FS em Google Cloud sejam confiáveis, é necessário entender e mitigar possíveis pontos de falha , implantar recursos de maneira 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 FS a atenderem a requisitos regulatórios rigorosos. Ela também ajuda a evitar danos intoleráveis aos clientes.
Os principais blocos de construção de confiabilidade em Google Cloud são regiões, zonas e os vários escopos de localização de 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 FS operam sob mandatos de confiabilidade rigorosos de agências regulatórias, como o Federal Reserve System nos EUA, a Autoridade Bancária Europeia na UE e a Autoridade de Regulamentação Prudencial no Reino Unido. Globalmente, 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 essenciais. Isso exige uma abordagem harmonizada para gerenciar riscos tecnológicos e dependências de terceiros.
Os requisitos regulatórios na maioria das jurisdições têm os seguintes temas comuns:
- Cibersegurança 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 operações essenciais durante interrupções e se recuperar de maneira eficaz.
- Proteção da estabilidade financeira: garantia da solidez e estabilidade do sistema financeiro mais amplo.
As recomendações de confiabilidade neste documento são mapeadas para os seguintes princípios básicos:
- Priorizar implantações multizonais e multirregionais
- Eliminar pontos únicos de falha (SPOFs, na sigla em inglês)
- Entender e gerenciar a disponibilidade agregada
- Implementar uma estratégia de DR robusta
- Aproveitar os serviços gerenciados
- Automatizar os processos de provisionamento e recuperação de infraestrutura
Priorizar implantações multizonais e multirregionais
Para aplicativos de serviços financeiros essenciais, recomendamos o uso de uma topologia multirregional distribuída em pelo menos duas regiões e em três zonas em cada região. Essa abordagem é importante para a resiliência contra interrupções de zonas e regiões. Os regulamentos geralmente prescrevem 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 interrupções de zonas e regiões:
- Prefira recursos que tenham um escopo de localização mais amplo. Sempre que possível, use recursos regionais em vez de zonais e recursos 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 provisionamento excessivo 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 HA do Cloud SQL oferece uma topologia quase ativa-ativa, com réplicas de leitura em todas as zonas. Ele oferece um objetivo do ponto de recuperação (RPO) entre regiões que é próximo de 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. Um balanceador de carga global é outra opção que você pode considerar, dependendo dos seus requisitos e da criticidade. 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 locais diferentes e use recursos redundantes para evitar que qualquer ponto único de falha (SPOF) afete toda a pilha de aplicativos.
Considere as seguintes recomendações para evitar SPOFs:
- Evite implantar apenas um único servidor de aplicativos ou banco de dados.
- Garanta a recriação automática de VMs com falha usando grupos de instâncias gerenciadas (MIGs).
- Distribua o tráfego de maneira uniforme entre os recursos disponíveis implementando o balanceamento de carga.
- Use configurações de HA 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 em Google Cloud.
Entender e gerenciar a disponibilidade agregada
Esteja ciente de que a disponibilidade geral ou agregada de um sistema é afetada pela disponibilidade de cada camada ou componente do sistema. O número de camadas 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árias camadas usando a fórmula disponibilidade_camada1 × disponibilidade_camada2 × disponibilidade_camadaN.
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 camada 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árias camadas é menor que a disponibilidade da camada 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 que a disponibilidade de cada serviço individual.
O diagrama a seguir mostra dois serviços, A e B, que são 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 maneira 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 possam ajudar a atender ao nível necessário de tempo de atividade geral da sua pilha de aplicativos.
Ao projetar sua arquitetura, considere as compensações entre disponibilidade, complexidade operacional, latência e custo. Aumentar o número de noves de disponibilidade geralmente custa mais, mas isso ajuda você a atender aos requisitos regulatórios.
Por exemplo, a disponibilidade de 99,9% (três noves) significa um possível tempo de inatividade de 86 segundos em um dia de 24 horas. Em contraste, 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 essenciais, 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 dessa avaliação ajuda a avaliar as implicações das 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 desastres, incluindo interrupções zonais e regionais. Uma estratégia de recuperação de desastres (DR) bem definida permite que você se recupere de uma interrupção e retome as operações normais com impacto mínimo.
DR e alta disponibilidade (HA) são conceitos diferentes. Com implantações na nuvem, em geral, a DR se aplica a implantações multirregionais e a HA se aplica a implantações regionais. Esses arquétipos de implantação oferecem suporte a mecanismos de replicação diferentes.
- HA: muitos serviços gerenciados oferecem replicação síncrona entre zonas em uma única região por padrão. Esses serviços oferecem suporte a um objetivo do tempo de recuperação (RTO) e um objetivo do ponto de recuperação (RPO) zero ou quase zero. Esse suporte permite criar uma topologia de implantação ativa-ativa que não tenha nenhum SPOF.
- DR: para cargas de trabalho implantadas em duas ou mais regiões, se você não usar serviços multirregionais ou globais, será necessário definir uma estratégia de replicação. A estratégia de replicação é normalmente assíncrona. Avalie cuidadosamente como essa replicação afeta o RTO e o RPO de aplicativos essenciais. Identifique as operações manuais ou semiautomatizadas necessárias para o failover.
Para instituições financeiras, a escolha da região de failover pode ser limitada por regulamentações sobre soberania de dados e residência de dados. Se você precisar de uma topologia ativa-ativa em duas regiões, recomendamos que escolha serviços multirregionais gerenciados, como o Spanner e o Cloud Storage, especialmente quando a replicação de dados é essencial.
Considere as seguintes recomendações:
- Use serviços de armazenamento multirregionais gerenciados para dados.
- Crie snapshots de dados em discos permanentes e armazene-os em locais multirregionais.
- Ao usar recursos regionais ou zonais, configure a replicação de dados para outras regiões.
- Valide se os planos de DR são eficazes testando o plano regularmente.
- Esteja ciente do RTO e do RPO e da correlação deles com a tolerância ao impacto estipulada pelas regulamentações financeiras na sua jurisdição.
Para mais informações, consulte Como arquitetar a recuperação de desastres para interrupções da infraestrutura em nuvem.
Aproveitar os serviços gerenciados
Sempre que possível, use serviços gerenciados para aproveitar os recursos integrados de backups, HA e escalonabilidade. Considere as seguintes recomendações para usar serviços gerenciados:
- Use serviços gerenciados em Google Cloud. Eles oferecem HA com suporte de SLAs. Eles também oferecem mecanismos de backup integrados e recursos de resiliência.
- Para gerenciamento de dados, considere serviços como Cloud SQL, Cloud Storage, e Spanner,
- Para computação e hospedagem de aplicativos, considere grupos de instâncias gerenciadas (MIGs) do Compute Engine e clusters do Google Kubernetes Engine (GKE). Os MIGs regionais e os clusters regionais do GKE são resilientes a interrupções de zonas.
- Para melhorar a resiliência contra interrupções de região, use serviços multirregionais gerenciados.
- Identifique a necessidade de planos de saída para serviços que tenham características exclusivas 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 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 oferecem suporte à exportação de 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 Serviço gerenciado para Apache Airflow criado no Apache Airflow.
Automatizar os processos de provisionamento e recuperação de infraestrutura
Automation ajuda a minimizar erros humanos e a 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 erros humanos usando ferramentas de infraestrutura como código (IaC), como o Terraform.
- Reduza a intervenção manual automatizando os processos de failover. Respostas automatizadas também podem ajudar a reduzir o impacto de falhas. Por exemplo, é possível usar o Eventarc ou fluxos de trabalho para acionar automaticamente ações corretivas em resposta a problemas observados nos registros de auditoria.
- Aumente a capacidade dos recursos de nuvem durante o failover usando o escalonamento automático.
- Aplique automaticamente políticas e proteções para requisitos regulatórios em toda a topologia de nuvem durante a implantação do serviço adotando a engenharia de plataforma.