Nesta seção do guia de arquétipos de implantação do Google Cloud, descrevemos o arquétipo de implantação regional.
Em uma arquitetura de nuvem que usa o arquétipo de implantação regional, as instâncias do aplicativo são executadas em duas ou mais zonas dentro de uma única região do Google Cloud. Todas as instâncias do aplicativo usam um repositório compartilhado e gerenciado de maneira centralizada de arquivos de configuração. Os dados do aplicativo são replicados de maneira síncrona em todas as zonas da arquitetura.
O diagrama a seguir mostra a topologia de nuvem para um aplicativo altamente disponível que é executado de maneira independente em três zonas dentro de uma única região do Google Cloud:
O diagrama anterior mostra um aplicativo com componentes de front-end e back-end executados de maneira independente em três zonas de uma região do Google Cloud. Um balanceador de carga externo encaminha as solicitações do usuário para um dos front-ends. Um balanceador de carga interno encaminha o tráfego dos front-ends para os back-ends. O aplicativo usa um banco de dados replicado nas zonas. Se ocorrer uma falha temporária na zona, o banco de dados fará o failover para uma réplica em outra zona.
A topologia no diagrama anterior é robusta contra interrupções de zona, mas não contra interrupções de região. Para se recuperar de interrupções da região, é preciso implantar uma réplica passiva do aplicativo em uma segunda região (failover), conforme mostrado no diagrama a seguir:
Quando ocorre uma interrupção na região principal, é preciso promover o banco de dados na região de failover e permitir que as políticas de roteamento de DNS encaminhem o tráfego para o balanceador de carga no failover regional.
Para otimizar o custo da infraestrutura de failover, é possível operar a região de failover com uma capacidade menor implantando menos recursos.
Casos de uso
As seções a seguir fornecem exemplos de casos de uso em que o arquétipo de implantação regional é uma escolha adequada.
Aplicativo altamente disponível com usuários em uma área geográfica
Recomendamos o arquétipo de implantação regional para aplicativos que precisam de robustez contra interrupções de zona, mas podem tolerar algum tempo de inatividade causado por interrupções na região. Se alguma parte da pilha falhar, ele continuará em execução se houver pelo menos um componente em funcionamento com capacidade adequada em cada nível. Se ocorrer uma interrupção na zona, a pilha do aplicativo continuará em execução nas outras zonas.
Baixa latência para usuários de aplicativos
Se os usuários de um aplicativo estiverem em uma área geográfica, como um único país, o arquétipo de implantação regional poderá ajudar a melhorar o desempenho percebido pelo usuário do aplicativo. É possível otimizar a latência da rede para solicitações dos usuários implantando o aplicativo na região do Google Cloud mais próxima dos usuários.
Rede de baixa latência entre componentes de aplicativos
Uma arquitetura de região única pode ser adequada para aplicativos como computação em lote que precisam de conexões de rede de baixa latência e alta largura de banda entre os nós de computação. Todos os recursos estão em uma única região do Google Cloud, de modo que o tráfego de rede entre recursos permanece na região. A latência da rede entre recursos é baixa e não há custos de transferência de dados entre regiões. Os custos de rede intrarregional ainda são aplicáveis.
Conformidade com os requisitos de soberania e residência de dados
O arquétipo de implantação regional pode ajudar você a atender aos requisitos regulamentares para residência de dados e soberania operacional. Por exemplo, um país na Europa pode exigir que todos os dados do usuário sejam armazenados e acessados em data centers localizados fisicamente dentro do país. Para ajudar a atender a esse requisito, implante o aplicativo em uma região do Google Cloud na Europa.
Considerações sobre o design
Ao criar uma arquitetura baseada no arquétipo de implantação regional, considere os fatores de design a seguir.
Inatividade durante interrupções na região
Quando ocorre uma falha temporária na região, o aplicativo fica inativo. É possível reduzir a inatividade causada por interrupções da região mantendo uma réplica passiva (failover) da pilha de infraestrutura em outra região do Google Cloud. Se ocorrer uma interrupção na região principal, ative a pilha na região de failover e use políticas de roteamento de DNS para rotear o tráfego para o balanceador de carga em a região de failover.
Custo de recursos redundantes
Uma arquitetura de várias zonas geralmente tem mais recursos de nuvem do que uma implantação de zona única. Considere o custo desses recursos de nuvem ao criar sua arquitetura. Para aplicativos que precisam de robustez contra interrupções de zona, a vantagem de disponibilidade de uma arquitetura de várias zonas pode justificar o custo mais alto.
Arquitetura de referência
Para uma arquitetura de referência que possa ser usada para projetar uma implantação regional em VMs do Compute Engine, consulte Implantação regional no Compute Engine.