Esta secção do guia de Google Cloud arquétipos de implementação descreve o arquétipo de implementação regional.
Numa arquitetura de nuvem que usa o arquétipo de implementação regional, as instâncias da aplicação são executadas em duas ou mais zonas numa única Google Cloud região. Todas as instâncias da aplicação usam um repositório partilhado e gerido centralmente de ficheiros de configuração. Os dados da aplicação são replicados de forma síncrona em todas as zonas na arquitetura.
O diagrama seguinte mostra a topologia da nuvem para uma aplicação de alta disponibilidade que é executada de forma independente em três zonas numa única região:Google Cloud
O diagrama anterior mostra uma aplicação com componentes de front-end e back-end que são executados de forma independente em três zonas numa Google Cloud região. Um balanceador de carga externo encaminha os pedidos dos utilizadores para um dos front-ends. Um balanceador de carga interno encaminha o tráfego dos front-ends para os back-ends. A aplicação usa uma base de dados replicada nas zonas. Se ocorrer uma indisponibilidade de uma zona, a base de dados muda para uma réplica noutra zona.
A topologia no diagrama anterior é robusta contra falhas de zonas, mas não contra falhas de regiões. Para poder recuperar de interrupções de regiões, tem de ter implementado uma réplica passiva da aplicação numa segunda região (de alternativa), conforme mostrado no diagrama seguinte:
Quando ocorre uma indisponibilidade na região principal, tem de promover a base de dados na região de failover e permitir que as políticas de encaminhamento de DNS encaminhem o tráfego para o balanceador de carga na região de failover.
Para otimizar o custo da infraestrutura de comutação por falha, pode operar a região de comutação por falha com uma capacidade inferior implementando menos recursos.
Exemplos de utilização
As secções seguintes fornecem exemplos de casos de utilização para os quais o arquétipo de implementação regional é uma escolha adequada.
Aplicação altamente disponível com utilizadores numa área geográfica
Recomendamos o arquétipo de implementação regional para aplicações que precisam de robustez contra falhas de zonas, mas que podem tolerar algum tempo de inatividade causado por falhas de regiões. Se qualquer parte da pilha de aplicações falhar, a aplicação continua a ser executada se existir, pelo menos, um componente funcional com capacidade adequada em todos os níveis. Se ocorrer uma indisponibilidade de uma zona, a pilha de aplicações continua a ser executada nas outras zonas.
Latência baixa para utilizadores da aplicação
Se os utilizadores de uma aplicação estiverem numa área geográfica, como um único país, o arquétipo de implementação regional pode ajudar a melhorar o desempenho da aplicação percebido pelos utilizadores. Pode otimizar a latência da rede para pedidos de utilizadores implementando a aplicação na região mais próxima dos seus utilizadores. Google Cloud
Rede de baixa latência entre componentes da aplicação
Uma arquitetura de região única pode ser adequada para aplicações como a computação em lote que precisam de ligações de rede de baixa latência e elevada largura de banda entre os nós de computação. Todos os recursos estão numa única Google Cloud região, pelo que o tráfego de rede entre recursos permanece na região. A latência da rede entre recursos é baixa e não incorre em custos de transferência de dados entre regiões. Os custos de rede intrarregionais continuam a aplicar-se.
Conformidade com os requisitos de residência e soberania dos dados
O arquétipo de implementação regional pode ajudar a cumprir os requisitos regulamentares de residência dos dados e soberania operacional. Por exemplo, um país na Europa pode exigir que todos os dados dos utilizadores sejam armazenados e acedidos em centros de dados localizados fisicamente no país. Para ajudar a cumprir este requisito, pode implementar a aplicação numa Google Cloud região na Europa.
Considerações de design
Quando cria uma arquitetura baseada no arquétipo de implementação regional, considere os seguintes fatores de design.
Período de descanso durante indisponibilidades de regiões
Quando ocorre uma indisponibilidade regional, a aplicação fica inativa. Pode reduzir o tempo de inatividade causado por falhas de funcionamento da região mantendo uma réplica passiva (de alternativa) do conjunto de infraestrutura noutra região Google Cloud . Se ocorrer uma indisponibilidade na região principal, pode ativar a pilha na região de alternativa e usar políticas de encaminhamento de DNS para encaminhar o tráfego para o equilibrador de carga na região de alternativa.
Custo dos recursos redundantes
Normalmente, uma arquitetura de várias zonas tem mais recursos na nuvem do que uma implementação de zona única. Considere o custo destes recursos na nuvem quando criar a sua arquitetura. Para aplicações que precisam de robustez contra interrupções de zonas, a vantagem de disponibilidade de uma arquitetura de várias zonas pode justificar o custo mais elevado.
Arquitetura de referência
Para uma arquitetura de referência que pode usar para criar uma implementação regional em VMs do Compute Engine, consulte o artigo Implementação regional no Compute Engine.