Conforme descrito em Disponibilidade da plataforma, a infraestrutura do Google Cloud foi projetada para oferecer suporte a uma disponibilidade de destino de 99,9% para uma carga de trabalho implantada em uma única zona. A disponibilidade desejada é de 99,99% para uma implantação de várias zonas e de 99,999% para uma implantação de várias regiões. Esta parte do Guia de confiabilidade da infraestrutura do Google Cloud fornece orientações de implantação, arquiteturas de exemplo e técnicas de design que podem ajudar a proteger suas cargas de trabalho contra falhas no recurso, na zona, e região.
Evite pontos únicos de falha
Os aplicativos geralmente são compostos por vários componentes interdependentes, cada um projetado para executar uma função específica. Esses componentes geralmente são agrupados em níveis com base na função que desempenham e na relação com os outros componentes. Por exemplo, um aplicativo de disponibilização de conteúdo pode ter três níveis: um nível contendo um balanceador de carga e servidores da Web, um nível de app com um cluster de servidores de aplicativos e um nível de dados para persistência. Se algum componente dessa pilha de aplicativos depender de um único recurso de infraestrutura, uma falha desse recurso poderá afetar a disponibilidade de toda a pilha. Por exemplo, se o nível do app for executado em uma única VM e a VM falhar, toda a pilha estará indisponível. Esse componente é um ponto único de falha (SPOF, na sigla em inglês).
Uma pilha de aplicativos pode ter mais de um SPOF. Considere a pilha de aplicativos de vários níveis mostrada no diagrama a seguir:
Conforme mostrado no diagrama anterior, este exemplo de arquitetura contém um único balanceador de carga, dois servidores da Web, um único servidor de aplicativos e um único banco de dados. O balanceador de carga, o servidor do app e o banco de dados neste exemplo são SPOFs. A falha de um desses componentes pode causar falhas nas solicitações do usuário para o aplicativo.
Para remover os SPOFs da pilha de aplicativos, distribua recursos entre locais e implante recursos redundantes.
Distribuir recursos e criar redundância
Dependendo dos requisitos de confiabilidade do aplicativo, é possível escolher uma das seguintes arquiteturas de implantação:
| Arquitetura | Recomendação de carga de trabalho |
|---|---|
| Multirregião | Cargas de trabalho essenciais para os negócios e em que a alta disponibilidade é essencial, como aplicativos de varejo e mídias sociais. |
| Várias zonas | Cargas de trabalho que precisam de resiliência contra falhas temporárias de zona, mas podem tolerar uma inatividade causada por interrupções de região. |
| Única zona | Cargas de trabalho que toleram inatividade ou podem ser implantadas em outro local, quando necessário, com o mínimo de esforço. |
Considerações sobre custo, latência e operações
Ao projetar uma arquitetura distribuída com recursos redundantes, além dos requisitos de disponibilidade do aplicativo, também é preciso considerar os efeitos na complexidade operacional, latência e custo.
Em uma arquitetura distribuída, você provisiona e gerencia um número maior de recursos. O volume de tráfego de rede entre locais é maior. Você também armazena e replica mais dados. Como resultado, o custo dos recursos da nuvem em uma arquitetura distribuída é maior, e a operação dessas implantações envolve mais complexidade. Para aplicativos essenciais para os negócios, a vantagem da disponibilidade de uma arquitetura distribuída pode superar o aumento de custos e a complexidade operacional.
Para aplicativos que não são essenciais para os negócios, a alta disponibilidade oferecida por uma arquitetura distribuída pode não ser essencial. Alguns aplicativos têm outros requisitos mais importantes que a disponibilidade. Por exemplo, aplicativos de computação em lote exigem conexões de rede de baixa latência e alta largura de banda entre as VMs. Uma arquitetura de zona única pode ser adequada para esses aplicativos, além de ajudar a reduzir os custos de transferência de dados.
Arquiteturas de implantação
Nesta seção, apresentamos as seguintes opções de arquitetura para criar infraestrutura para as cargas de trabalho no Google Cloud:
- Implantação de zona única
- Implantação em várias zonas
- Implantação multirregional com balanceamento de carga regional
- Implantação multirregional com balanceamento de carga global
Implantação de zona única
O diagrama a seguir mostra uma arquitetura de aplicativo de zona única com redundância em cada nível para alcançar uma maior disponibilidade das funções executadas por cada componente:
Conforme mostrado no diagrama anterior, este exemplo de arquitetura inclui os seguintes componentes:
- Um balanceador de carga HTTP/S externo regional para receber e responder a solicitações de usuários.
- Um grupo gerenciado de instâncias por zona (MIG) como back-end do balanceador de carga HTTP/S. O MIG tem duas VMs do Compute Engine. Cada VM hospeda uma instância de um servidor da Web.
- Um balanceador de carga interno para lidar com a comunicação entre o servidor da Web e as instâncias do servidor de apps.
- Um segundo MIG zonal como o back-end do balanceador de carga interno. Esse MIG contém duas VMs do Compute Engine. Cada VM hospeda uma instância de um servidor de apps.
- Uma instância de banco de dados do Cloud SQL (edição Enterprise) em que o aplicativo grava dados e lê. O banco de dados é replicado manualmente para uma segunda instância de banco de dados do Cloud SQL na mesma zona.
Disponibilidade agregada: implantação de zona única
A tabela a seguir mostra a disponibilidade de cada nível no diagrama anterior de arquitetura de zona única:
| Recurso | SLA |
|---|---|
| Balanceador de carga externo | 99,99% |
| Nível da Web: VMs do Compute Engine em uma única zona | 99,9% |
| Balanceador de carga interno | 99,99% |
| Nível do aplicativo: VMs do Compute Engine em uma única zona | 99,9% |
| Instância do Cloud SQL (edição Enterprise) | 99,95% |
Os recursos de infraestrutura do Google Cloud listados na tabela anterior fornecem a seguinte disponibilidade agregada e inatividade mensal máxima estimada:
- Disponibilidade agregada: 0,9999 x 0,999 x 0,9999 x 0,999 x 0,9995 = 99,73%
- Inatividade mensal máxima estimada: aproximadamente 1 hora e 57 minutos
Esse cálculo considera apenas os recursos de infraestrutura mostrados no diagrama de arquitetura anterior. Para avaliar a disponibilidade de um aplicativo no Google Cloud, considere também outros fatores, como estes:
- O desenvolvimento interno do aplicativo
- Os processos e as ferramentas do DevOps usados para criar, implantar e manter o aplicativo, as dependências dele e a infraestrutura do Google Cloud
Para mais informações, consulte Fatores que afetam a confiabilidade do aplicativo.
Efeitos das falhas temporárias e orientação para recuperação
Em uma arquitetura de implantação de zona única, se algum componente falhar, o aplicativo poderá processar solicitações se cada nível contiver pelo menos um componente funcional com capacidade adequada. Por exemplo, se uma instância do servidor da Web falhar, o balanceador de carga encaminhará as solicitações do usuário para as outras instâncias do servidor. Se uma VM que hospeda um servidor da Web ou uma instância do servidor de apps falhar, o MIG vai garantir que uma nova VM seja criada automaticamente. Se o banco de dados falhar, você precisará ativar manualmente o segundo banco de dados e atualizar as instâncias do servidor do app para se conectar ao banco de dados.
Uma falha temporária de zona ou região afeta as VMs do Compute Engine e as instâncias de banco de dados do Cloud SQL em uma implantação de zona única. Uma falha temporária de zona não afeta o balanceador de carga nessa arquitetura porque é um recurso regional. No entanto, o balanceador de carga não pode distribuir o tráfego porque não há back-ends disponíveis. Se ocorrer uma falha temporária na zona, você precisará aguardar o Google resolver a interrupção e verificar se o aplicativo funciona conforme o esperado.
Na próxima seção, descrevemos uma abordagem de arquitetura que pode ser usada para distribuir recursos em várias zonas, o que ajuda a melhorar a resiliência do aplicativo em caso de falhas temporárias.
Implantação em várias zonas
Em uma implantação de zona única, se ocorrer uma interrupção de zona, o aplicativo não poderá atender a solicitações até que o problema seja resolvido. Para ajudar a melhorar a resiliência do aplicativo contra falhas temporárias de zona, é possível provisionar várias instâncias de recursos zonais (como VMs do Compute Engine) em duas ou mais zonas. Para serviços que oferecem suporte a recursos com escopo regional, como buckets do Cloud Storage, é possível implantar recursos regionais.
O diagrama a seguir mostra uma arquitetura de zona cruzada altamente disponível, com os componentes em cada nível da pilha de aplicativos distribuídos em duas zonas:
Conforme mostrado no diagrama anterior, este exemplo de arquitetura inclui os seguintes componentes:
- Um balanceador de carga HTTP/S externo regional recebe e responde às solicitações do usuário.
- Um MIG regional é o back-end do balanceador de carga HTTP/S. O MIG contém duas VMs do Compute Engine em zonas diferentes. Cada VM hospeda uma instância de um servidor da Web.
- Um balanceador de carga interno processa a comunicação entre o servidor da Web e as instâncias do servidor de apps.
- Um segundo MIG regional é o back-end do balanceador de carga TCP. Esse MIG tem duas VMs do Compute Engine em zonas diferentes. Cada VM hospeda uma instância de um servidor de apps.
- Uma instância do Cloud SQL (edição Enterprise) configurada para alta disponibilidade é o banco de dados do aplicativo. A instância principal do banco de dados é replicada de maneira síncrona em uma instância de banco de dados em espera.
Disponibilidade agregada: implantação em várias zonas
A tabela a seguir mostra a disponibilidade de cada nível no diagrama anterior de arquitetura de duas zonas:
| Recurso | SLA |
|---|---|
| Balanceador de carga externo | 99,99% |
| Nível da Web: VMs do Compute Engine em zonas separadas | 99,99% |
| Balanceador de carga interno | 99,99% |
| Nível do aplicativo: VMs do Compute Engine em zonas separadas | 99,99% |
| Instância do Cloud SQL (edição Enterprise) | 99,95% |
Os recursos de infraestrutura do Google Cloud listados na tabela anterior fornecem a seguinte disponibilidade agregada e inatividade mensal máxima estimada:
- Disponibilidade agregada: 0,9999 x 0,9999 x 0,9999 x 0,9999 x 0,9995 = 99,91%
- Inatividade mensal máxima estimada: aproximadamente 39 minutos
Esse cálculo considera apenas os recursos de infraestrutura mostrados no diagrama de arquitetura anterior. Para avaliar a disponibilidade de um aplicativo no Google Cloud, considere também outros fatores, como estes:
- O desenvolvimento interno do aplicativo
- Os processos e as ferramentas do DevOps usados para criar, implantar e manter o aplicativo, as dependências dele e a infraestrutura do Google Cloud
Para mais informações, consulte Fatores que afetam a confiabilidade do aplicativo.
Efeitos das falhas temporárias e orientação para recuperação
Em uma implantação de duas zonas, se algum componente falhar, o aplicativo poderá processar solicitações se houver pelo menos um componente funcional com capacidade adequada em cada nível. Por exemplo, se uma instância do servidor da Web falhar, o balanceador de carga encaminhará as solicitações do usuário para a instância do servidor da Web na outra zona. Se uma VM que hospeda um servidor da Web ou uma instância do servidor de apps falhar, o MIG vai garantir que uma nova VM seja criada automaticamente. Se o banco de dados principal do Cloud SQL falhar, ele fará o failover automaticamente para a instância do banco de dados em espera.
O diagrama a seguir mostra a mesma arquitetura do diagrama anterior e os efeitos de uma falha temporária de zona na disponibilidade do aplicativo:
Conforme mostrado no diagrama anterior, se uma interrupção ocorrer em uma das zonas, o balanceador de carga nessa arquitetura não será afetado, porque é um recurso regional. Uma falha temporária de zona pode afetar as VMs individuais do Compute Engine e uma das instâncias de banco de dados do Cloud SQL. No entanto, o aplicativo permanece disponível e responsivo, porque as VMs estão em MIGs regionais e o banco de dados do Cloud SQL está configurado para alta disponibilidade. Os MIGs garantem que novas VMs sejam criadas automaticamente para manter o número mínimo configurado de VMs. Se a instância principal do banco de dados do Cloud SQL for afetada por uma falha temporária, o Cloud SQL fará o failover automaticamente para a instância de espera na outra zona. Depois que o Google resolver a falha temporária, verifique se o aplicativo é executado conforme o esperado em todas as zonas em que está implantado.
Se as duas zonas nesta arquitetura tiverem uma falha temporária, significa que o aplicativo não está disponível. O balanceador de carga continua disponível, a menos que ocorra uma falha temporária na região. No entanto, o balanceador de carga não pode distribuir o tráfego porque não há back-ends disponíveis. Se ocorrer uma falha temporária em várias zonas ou região, aguarde o Google resolver a falha e verifique se o aplicativo funciona conforme o esperado.
As próximas seções apresentam opções de arquitetura para proteger seu aplicativo contra falhas temporárias em várias zonas e na região.
Implantação multirregional com balanceamento de carga regional
Em uma implantação de zona única ou de várias zonas, se ocorrer uma falha temporária na região, o aplicativo não poderá exibir solicitações até que o problema seja resolvido. Para proteger seu aplicativo contra falhas temporárias na região, é possível distribuir os recursos do Google Cloud em duas ou mais regiões.
O diagrama a seguir mostra uma arquitetura entre regiões altamente disponível, com os componentes em cada nível da pilha de aplicativos distribuídos em várias regiões:
Conforme mostrado no diagrama anterior, este exemplo de arquitetura inclui os seguintes componentes:
- Uma zona pública do Cloud DNS com uma política de roteamento que direciona o tráfego para duas regiões do Google Cloud.
- Um balanceador de carga HTTP/S externo regional em cada região para receber e responder às solicitações do usuário.
- O back-end de cada balanceador de carga HTTP/S regional é um MIG regional. Cada MIG contém duas VMs do Compute Engine em zonas diferentes. Cada uma dessas VMs hospeda uma instância de um servidor da Web.
- Um balanceador de carga interno em cada região processa a comunicação entre as instâncias do servidor da Web e as instâncias do servidor de aplicativos.
- Um segundo par de MIGs regionais é o back-end dos balanceadores de carga internos. Cada um desses MIGs contém duas VMs do Compute Engine em zonas diferentes. Cada VM hospeda uma instância de um servidor de apps.
- O aplicativo grava dados e lê em uma instância multirregional do Spanner. A configuração multirregional usada nessa
arquitetura (
eur5) inclui quatro réplicas de leitura e gravação. As réplicas de leitura/gravação são provisionadas igualmente em duas regiões e em zonas separadas. A configuração multirregional do Spanner também inclui uma réplica de testemunha em uma terceira região.
Disponibilidade agregada: implantação multirregional com balanceamento de carga regional
Na implantação multirregional mostrada no diagrama anterior, os balanceadores de carga e as VMs são provisionados de maneira redundante em duas regiões. A zona de DNS é um recurso global, e a instância do Cloud Spanner é um recurso multirregional.
Para calcular a disponibilidade agregada da infraestrutura do Google Cloud mostrada nessa arquitetura, primeiro é necessário calcular a disponibilidade agregada dos recursos em cada região e, em seguida, considerar os recursos que abrangem várias regiões. Use o seguinte processo:
- Calcule a disponibilidade agregada dos recursos de infraestrutura por região, desconsiderando os recursos de DNS e banco de dados:
Recurso e SLA SLA Balanceador de carga externo 99,99% Nível da Web: VMs do Compute Engine em zonas separadas 99,99% Balanceador de carga interno 99,99% Nível do aplicativo: VMs do Compute Engine em zonas separadas 99,99% Disponibilidade agregada por região: 0,9999 x 0,9999 x 0,9999 x 0,9999 = 99,96%
Calcule a disponibilidade agregada dos recursos de infraestrutura, considerando a redundância birregional dos balanceadores de carga e das VMs do Compute Engine.
A disponibilidade teórica é de 1-(1-0,9996)(1-0,9996) = 99,999984%. No entanto, a disponibilidade real que você espera é limitada à disponibilidade de destino para implantações multirregionais, que é de 99,999%.
Calcule a disponibilidade agregada de todos os recursos de infraestrutura, considerando os recursos do Cloud DNS e do Spanner:
- Disponibilidade agregada: 0,99999 x 1 x 0,99999 = 99,998%
- Inatividade mensal máxima estimada: aproximadamente 52 segundos
Esse cálculo considera apenas os recursos de infraestrutura mostrados no diagrama de arquitetura anterior. Para avaliar a disponibilidade de um aplicativo no Google Cloud, considere também outros fatores, como estes:
- O desenvolvimento interno do aplicativo
- Os processos e as ferramentas do DevOps usados para criar, implantar e manter o aplicativo, as dependências dele e a infraestrutura do Google Cloud
Para mais informações, consulte Fatores que afetam a confiabilidade do aplicativo.
Efeitos das falhas temporárias e orientação para recuperação
Se algum componente nesta implantação multirregional falhar, mas houver pelo menos um componente funcional com capacidade adequada em cada nível, o aplicativo continuará funcionando. Por exemplo, se uma instância do servidor da Web falhar, o balanceador de carga HTTP/S externo regional encaminhará as solicitações dos usuários para outras instâncias de servidor da Web na região. Da mesma forma, se uma das instâncias do servidor de apps falhar, os balanceadores de carga internos vão enviar solicitações para as outras instâncias do servidor. Se alguma das VMs falhar, os MIGs garantem que novas VMs sejam criadas automaticamente para manter o número mínimo configurado de VMs.
Uma falha temporária em uma única zona não afeta os balanceadores de carga, porque são recursos regionais e resilientes a interrupções de zona. Uma falha temporária de zona pode afetar VMs individuais do Compute Engine. No entanto, as instâncias do servidor da Web e do servidor de apps permanecem disponíveis porque as VMs fazem parte dos MIGs regionais. Os MIGs garantem que novas VMs sejam criadas automaticamente para manter o número mínimo configurado de VMs. A instância do Spanner nessa arquitetura usa uma configuração multirregional, que é resiliente a interrupções de zona.
Para informações sobre como funciona a replicação multirregional no Spanner, consulte Configurações regionais e multirregionais e Desmistificar as configurações do Cloud Spanner multirregional.
No diagrama a seguir, veja a mesma arquitetura multirregional que o diagrama anterior e os efeitos de uma falha temporária regional na disponibilidade do aplicativo:
Como mostrado no diagrama anterior, mesmo que uma interrupção ocorra nas duas zonas em qualquer região, o aplicativo permanece disponível, porque uma pilha de aplicativos independente é implantada em cada região. A zona de DNS direciona as solicitações do usuário para a região que não é afetada pela falha temporária. A instância multirregional do Spanner é resiliente a interrupções da região. Depois que o Google resolver a falha, verifique se o aplicativo é executado conforme o esperado na região em que ela ocorreu.
Se alguma das duas regiões desta arquitetura tiver interrupções, o aplicativo não estará disponível. Aguarde o Google resolver as interrupções. Em seguida, verifique se o aplicativo é executado conforme o esperado em todas as regiões em que ele está implantado.
Para implantações multirregionais, em vez de usar balanceadores de carga regionais, considere o uso de um balanceador de carga global. A próxima seção apresenta uma arquitetura de implantação multirregional que usa um balanceador de carga global e descreve os benefícios e riscos dessa abordagem.
Implantação multirregional com balanceamento de carga global
No diagrama a seguir, mostramos uma implantação multirregional alternativa que usa um balanceador de carga global em vez de balanceadores de carga regionais:
Conforme mostrado no diagrama anterior, essa arquitetura usa um balanceador de carga HTTP/S externo global (com o Cloud CDN ativado) para receber e responder a solicitações do usuário. Cada regra de encaminhamento do balanceador de carga usa um único endereço IP externo. Não é preciso configurar um registro DNS separado para cada região. Os back-ends do balanceador de carga HTTP/S externo global são dois MIGs regionais. O balanceador de carga encaminha solicitações para a região mais próxima dos usuários.
Todos os outros componentes nessa arquitetura são idênticos à mostrada na implantação multirregional com balanceamento de carga regional.
Benefícios e riscos do balanceamento de carga global para implantações multirregionais
Para balancear a carga do tráfego externo em um aplicativo distribuído em várias regiões, use um balanceador de carga global ou vários balanceadores regionais.
Veja a seguir os benefícios de uma arquitetura que usa um balanceador de carga global:
- Você só precisa gerenciar um balanceador de carga.
- Os balanceadores de carga globais usam um único endereço IP anycast para fornecer balanceamento de carga em todas as regiões do Google Cloud.
- Os balanceadores de carga globais são resilientes a interrupções de região e oferecem failover automático entre regiões.
- Os balanceadores de carga globais oferecem suporte aos seguintes recursos, que podem ajudar a melhorar
a confiabilidade das implantações:
- Armazenamento em cache de borda usando o Cloud CDN
- Capacidade de usar buckets do Cloud Storage altamente duráveis como back-ends
- Políticas de segurança do Google Cloud Armor
Veja a seguir os riscos de uma arquitetura que usa um balanceador de carga global:
- Uma alteração de configuração incorreta no balanceador de carga global pode tornar o aplicativo indisponível para os usuários. Por exemplo, ao atualizar o front-end do balanceador de carga global, se você excluir acidentalmente uma regra de encaminhamento, o balanceador de carga deixará de receber solicitações de usuários. O efeito desse risco é menor no caso de uma arquitetura multirregional que usa balanceadores de carga regionais, porque mesmo que o balanceador de carga regional em uma das regiões seja afetado por um erro de configuração, os balanceadores de carga nas outras regiões continuam funcionando.
- Uma falha temporária na infraestrutura que afeta recursos globais pode tornar o balanceador de carga global indisponível.
Para reduzir esses riscos, gerencie as alterações no balanceador de carga global com cuidado e considere usar substitutos de defesa completos sempre que possível. Para mais informações, consulte Recomendações para gerenciar o risco de interrupções de recursos globais.
Disponibilidade agregada: implantação multirregional com balanceamento de carga global
Na implantação multirregional mostrada no diagrama anterior, as VMs e os balanceadores de carga internos são distribuídos de maneira redundante em duas regiões. O balanceador de carga externo é um recurso global, e a instância do Spanner é um recurso multirregional.
Para calcular a disponibilidade agregada dessa implantação, primeiro calculamos a disponibilidade agregada dos recursos em cada região e, em seguida, consideramos os recursos que abrangem várias regiões.
- Calcule a disponibilidade agregada dos recursos de infraestrutura por região, desconsiderando o balanceador de carga externo e o banco de dados:
Recurso SLA Nível da Web: VMs do Compute Engine em zonas separadas 99,99% Balanceador de carga interno 99,99% Nível da Web: VMs do Compute Engine em zonas separadas 99,99% Disponibilidade agregada por região: 0,9999 x 0,9999 x 0,9999 = 99,97%
Calcule a disponibilidade agregada dos recursos de infraestrutura, considerando a redundância birregional do balanceador de carga interno e as VMs do Compute Engine.
A disponibilidade teórica é de 1-(1-0,9997)(1-0,9997) = 99,999991%. No entanto, a disponibilidade real que você espera é limitada à disponibilidade de destino para implantações multirregionais, que é de 99,999%.
Calcule a disponibilidade agregada de todos os recursos de infraestrutura, considerando o balanceador de carga global e os recursos do Spanner:
- Disponibilidade agregada: 0,99999 x 0,9999 x 0,99999 = 99,988%
- Inatividade mensal máxima estimada: aproximadamente 5 minutos e 11 segundos
Esse cálculo considera apenas os recursos de infraestrutura mostrados no diagrama de arquitetura anterior. Para avaliar a disponibilidade de um aplicativo no Google Cloud, considere também outros fatores, como estes:
- O desenvolvimento interno do aplicativo
- Os processos e as ferramentas do DevOps usados para criar, implantar e manter o aplicativo, as dependências dele e a infraestrutura do Google Cloud
Para mais informações, consulte Fatores que afetam a confiabilidade do aplicativo.
Efeitos das falhas temporárias e orientação para recuperação
Se algum componente dessa arquitetura falhar, o aplicativo continuará funcionando se houver pelo menos um componente funcional com capacidade adequada em cada nível. Por exemplo, se uma instância do servidor da Web falhar, o balanceador de carga HTTP/S externo global encaminhará as solicitações do usuário para as outras instâncias do servidor. Se uma instância do servidor de apps falhar, os balanceadores de carga internos vão enviar as solicitações para as outras instâncias do servidor de apps. Se alguma das VMs falhar, os MIGs garantem que novas VMs sejam criadas automaticamente para manter o número mínimo configurado de VMs.
Se uma interrupção ocorrer em uma das zonas de qualquer região, o balanceador de carga não será afetado. O balanceador de carga HTTP/S externo global é resiliente a interrupções de zona e região. Os balanceadores de carga internos são recursos regionais. Eles são resistentes a falhas temporárias nas zonas. Uma falha temporária de zona pode afetar VMs individuais do Compute Engine. No entanto, as instâncias do servidor da Web e do servidor de apps permanecem disponíveis porque as VMs fazem parte dos MIGs regionais. Os MIGs garantem que novas VMs sejam criadas automaticamente para manter o número mínimo configurado de VMs. A instância do Spanner nessa arquitetura usa uma configuração multirregional, que é resiliente a interrupções de zona.
No diagrama a seguir, veja a mesma arquitetura multirregional que o diagrama anterior e os efeitos de uma falha temporária regional na disponibilidade do aplicativo:
Como mostrado no diagrama anterior, mesmo que uma interrupção ocorra nas duas zonas em qualquer região, o aplicativo permanece disponível, porque uma pilha de aplicativos independente é implantada em cada região. O balanceador de carga HTTP/S externo global encaminha solicitações de usuários para o aplicativo na região que não é afetada pela interrupção. A instância multirregional do Spanner é resiliente a interrupções da região. Depois que o Google resolver a falha, verifique se o aplicativo é executado conforme o esperado na região em que ela ocorreu.
Para informações sobre como funciona a replicação multirregional no Spanner, consulte Configurações regionais e multirregionais e Desmistificar as configurações do Cloud Spanner multirregional.
Se alguma das duas regiões desta arquitetura tiver interrupções, o aplicativo não estará disponível. O balanceador de carga HTTP/S externo global está disponível, mas não pode distribuir o tráfego porque não há back-ends disponíveis. Aguarde o Google resolver as interrupções. Em seguida, verifique se o aplicativo é executado conforme o esperado em todas as regiões em que ele está implantado.
As implantações multirregionais podem ajudar a garantir alta disponibilidade para seus aplicativos de negócios mais essenciais. Para garantir a continuidade dos negócios durante eventos de falha, além de implantar o aplicativo em várias regiões, você precisa seguir determinadas etapas. Por exemplo, é necessário executar o planejamento de capacidade para garantir que a capacidade suficiente seja reservada em todas as regiões ou que os riscos associados ao escalonamento automático de emergência sejam aceitáveis. Também é necessário implementar práticas operacionais para teste de DR, gerenciamento de incidentes, verificação de status do aplicativo após incidentes e execução de retrospectivas.