Os serviços de infraestrutura do Google Cloud são executados em locais ao redor do mundo. Os locais são divididos em domínios de falha chamados regiões e zonas, que são os elementos básicos para criar uma infraestrutura confiável para as cargas de trabalho na nuvem.
Um domínio de falha é um recurso ou um grupo que pode falhar de maneira independente de outros recursos Uma VM independente do Compute Engine é um exemplo de um recurso que é um domínio de falha. Uma região ou zona do Google Cloud é um exemplo de domínio de falha que consiste em um grupo de recursos. Quando um aplicativo é distribuído de maneira redundante em domínios de falha, ele pode atingir um nível de disponibilidade agregado maior do que aquele fornecido por cada domínio de falha.
Esta parte do Guia de confiabilidade da infraestrutura do Google Cloud descreve os elementos básicos da confiabilidade no Google Cloud e como eles afetam a disponibilidade dos recursos da nuvem.
Regiões e zonas
As regiões do Google Cloud são locais geográficos independentes. Cada região do Google Cloud contém várias zonas. É improvável que uma falha em uma zona afete a infraestrutura nas outras. Um backbone de rede global oferece conectividade de alta largura de banda e baixa latência em todas as zonas e regiões do Google Cloud.
Disponibilidade da plataforma
A infraestrutura do Google Cloud foi projetada para tolerar e se recuperar de falhas. O Google investe continuamente em abordagens inovadoras para manter e melhorar a confiabilidade do Google Cloud. Os seguintes recursos da infraestrutura do Google Cloud ajudam a fornecer uma plataforma confiável para suas cargas de trabalho na nuvem:
- Regiões geograficamente separadas para reduzir os efeitos de desastres naturais e falhas temporárias em serviços globais.
- Redundância de hardware e replicação para evitar pontos únicos de falha.
- Migração em tempo real de recursos durante eventos de manutenção. Por exemplo, durante a manutenção planejada da infraestrutura, as VMs do Compute Engine podem ser movidas para outro host na mesma zona usando migração em tempo real.
- Uma base de infraestrutura com segurança incorporada ao design da infraestrutura física e do software em que o Google Cloud é executado, além de controles de segurança operacional para proteger seus dados e cargas de trabalho. Para mais informações, consulte a Visão geral do design de segurança da infraestrutura do Google.
- Uma rede de backbone de alto desempenho que usa uma abordagem avançada de rede definida por software (SDN, na sigla em inglês) para gerenciamento de rede, com serviços de armazenamento em cache de borda para oferecer um desempenho consistente e escalonável.
- Monitoramento e relatórios contínuos. É possível visualizar o status dos serviços do Google Cloud em todos os locais usando o Painel do Google Cloud Service Health.
- Eventos anuais de teste de recuperação de desastres (DiRT, na sigla em inglês) da empresa para garantir que os serviços do Google Cloud e as operações comerciais internas continuem sendo executados durante um desastre.
A infraestrutura do Google Cloud foi projetada para dar suporte aos seguintes níveis de disponibilidade para a maioria das cargas de trabalho do cliente:
| Local de implantação | Porcentagem de disponibilidade (tempo de atividade) | Inatividade máxima estimada |
|---|---|---|
| Única zona | 3 noves: 99,9% | 43,2 minutos em um mês de 30 dias |
| Várias zonas em uma região | 4 noves: 99,99% | 4,3 minutos em um mês de 30 dias |
| Várias regiões | 5 noves: 99,999% | 26 segundos em um mês de 30 dias |
As porcentagens de disponibilidade na tabela anterior são metas. Os contratos de nível de serviço (SLAs) de serviços específicos do Google Cloud podem ser diferentes dessas metas de disponibilidade. Por exemplo, o SLA de tempo de atividade de uma instância do Bigtable depende do número de clusters, da distribuição deles entre locais e a política de roteamento configurada.
O SLA de tempo de atividade mínimo para uma instância do Bigtable com clusters em três ou mais regiões será de 99,999% se a política de roteamento de vários clusters estiver configurada. No entanto, se a política de roteamento de cluster único estiver configurada, o SLA de tempo de atividade mínimo será de 99,9%, independentemente do número de clusters e da distribuição deles.
Os diagramas nesta seção mostram instâncias do Bigtable com tamanhos de cluster variados e as diferenças subsequentes nos SLAs de tempo de atividade.
Cluster único
O diagrama a seguir mostra uma instância do Bigtable de cluster único, com um SLA de tempo de atividade mínimo de 99,9%:
Vários clusters
O diagrama a seguir mostra uma instância de vários clusters do Bigtable em várias zonas dentro de uma única região, com roteamento de vários clusters (SLA de tempo de atividade mínimo: 99,99%):
Vários clusters
O diagrama a seguir mostra uma instância de Bigtable de vários clusters em três regiões, com roteamento de vários clusters (SLA de tempo de atividade mínimo: 99,999%):
Disponibilidade de infraestrutura agregada
Para executar seus aplicativos no Google Cloud, você usa recursos de infraestrutura, como VMs e bancos de dados. Juntos, esses recursos de infraestrutura constituem a pilha de infraestrutura do aplicativo.
O diagrama a seguir mostra o exemplo de uma pilha de infraestrutura no Google Cloud e o SLA de disponibilidade para cada recurso na pilha:
Este exemplo de pilha de infraestrutura inclui os seguintes recursos do Google Cloud:
- Um balanceador de carga de aplicativo externo regional recebe e responde às solicitações do usuário.
- Um grupo gerenciado de instâncias (MIG, na sigla em inglês) regional é o back-end do balanceador de carga de aplicativo externo regional. 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 aplicativos.
- Um segundo MIG regional é o back-end do balanceador de carga interno. Esse MIG tem duas VMs do Compute Engine em zonas diferentes. Cada VM hospeda uma instância de um servidor de aplicativos.
- Uma instância do Cloud SQL 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.
A disponibilidade agregada esperada de uma pilha de infraestrutura, como o exemplo anterior, depende dos seguintes fatores:
SLAs do Google Cloud
Os SLAs de tempo de atividade dos serviços do Google Cloud usados na pilha de infraestrutura influenciam a disponibilidade mínima agregada que pode ser esperada da pilha.
As tabelas a seguir apresentam uma comparação dos SLAs de tempo de atividade de alguns serviços:
| Serviços do Compute | SLA de tempo de atividade mensal | Inatividade máxima estimada em um mês de 30 dias |
|---|---|---|
| VM do Compute Engine | 99,9% | 43,2 minutos |
| Pods do Autopilot do GKE em várias zonas | 99,9% | 43,2 minutos |
| Serviço do Cloud Run | 99,95% | 21,6 minutos |
| Serviços de banco de dados | SLA de tempo de atividade mensal | Inatividade máxima estimada em um mês de 30 dias |
|---|---|---|
| Instância do Cloud SQL para PostgreSQL (edição Enterprise) | 99,95% | 21,6 minutos |
| Instância do AlloyDB para PostgreSQL | 99,99% | 4,3 minutos |
| Instância multirregional do Spanner | 99,999% | 26 segundos |
Para ver os SLAs de outros serviços do Google Cloud, consulte Contratos de nível de serviço do Google Cloud.
Conforme mostrado nas tabelas anteriores, os serviços do Google Cloud escolhidos para cada nível da pilha de infraestrutura afetam diretamente o tempo de atividade geral da pilha de infraestrutura. Para aumentar a disponibilidade esperada de uma carga de trabalho implantada em um recurso do Google Cloud, é possível provisionar instâncias redundantes do recurso, conforme descrito na próxima seção.
Redundância de recursos
Redundância de recursos significa provisionar duas ou mais instâncias idênticas de um recurso e implantar a mesma carga de trabalho em todos os recursos do grupo. Por exemplo, para hospedar o nível da Web de um aplicativo, é possível provisionar um MIG que contém várias VMs idênticas do Compute Engine.
Se você distribuir um grupo de recursos de forma redundante em vários domínios de falha (por exemplo, duas zonas do Google Cloud), a disponibilidade do recurso esperada desse grupo será maior do que o SLA de tempo de atividade de cada recurso no grupo. Essa maior disponibilidade ocorre porque a probabilidade de todos os recursos no grupo falharem ao mesmo tempo é menor do que a probabilidade de os recursos em um único domínio de falha apresentarem uma falha coordenada.
Por exemplo, se o SLA de disponibilidade de um recurso for de 99,9%, a probabilidade de esse recurso falhar será de 0,001 (1 menos o SLA). Se você distribuir uma carga de trabalho entre duas instâncias desse recurso provisionadas em domínios de falha separados, a probabilidade de ambos os recursos falharem ao mesmo tempo será de 0,000001 (ou seja, 0,001 x 0,001). Essa probabilidade de falha é uma disponibilidade teórica de 99,9999% para o grupo de dois recursos. No entanto, a disponibilidade real esperada é limitada à disponibilidade de destino do local de implantação: 99,9% se os recursos estiverem em uma única zona do Google Cloud, 99,99% para uma implantação em várias zonas e 99,999% se os recursos redundantes forem distribuídos em várias regiões.
Profundidade da pilha
A profundidade de uma pilha de infraestrutura é o número de níveis (ou camadas) distintos na pilha. Cada nível em uma pilha de infraestrutura contém recursos que fornecem uma função distinta para o aplicativo. Por exemplo, o nível do meio em uma pilha de três níveis pode usar VMs do Compute Engine ou um cluster do GKE para hospedar servidores de aplicativos. Cada nível em uma pilha de infraestrutura normalmente tem uma interdependência rígida com os níveis adjacentes. Isso significa que, se algum nível da pilha estiver indisponível, toda a pilha ficará indisponível.
É possível calcular a disponibilidade agregada esperada de uma pilha de infraestrutura de nível N usando a seguinte fórmula:
Por exemplo, se cada nível em uma pilha de três níveis for projetado para fornecer 99,9% de disponibilidade, a disponibilidade agregada da pilha será de aproximadamente 99,7% (0,999 x 0,999 x 0,999). Isso significa que a disponibilidade agregada de uma pilha de vários níveis é menor que a disponibilidade do nível que fornece a menor disponibilidade.
À medida que o número de níveis interdependentes em uma pilha aumenta, a disponibilidade agregada da pilha diminui, conforme mostrado na tabela a seguir. Cada exemplo de pilha na tabela tem um número diferente de níveis. Para facilitar a comparação, considera-se que cada nível fornece 99,9% de disponibilidade.
| Nível | Pilha A | Pilha B | Pilha C |
|---|---|---|---|
| Front-end | 99,9% | 99,9% | 99,9% |
| Nível do aplicativo | 99,9% | 99,9% | 99,9% |
| Nível intermediário | – | 99,9% | 99,9% |
| Nível dos dados | – | – | 99,9% |
| Disponibilidade agregada da pilha | 99,8% | 99,7% | 99,6% |
| Inatividade máxima estimada da pilha em um mês de 30 dias | 86 minutos | 130 minutos | 173 minutos |
Resumo das considerações para desenvolvimento
Ao desenvolver seus aplicativos, considere a disponibilidade agregada da pilha de infraestrutura do Google Cloud.
- A disponibilidade de cada recurso do Google Cloud na sua pilha de infraestrutura influencia a disponibilidade agregada da pilha. Ao escolher os serviços do Google Cloud para criar sua pilha de infraestrutura, considere o SLA de disponibilidade dos serviços.
- Para melhorar a disponibilidade da função (por exemplo, computação ou banco de dados) fornecida por um recurso, é possível provisionar instâncias redundantes do recurso. Ao desenvolver uma arquitetura com recursos redundantes, além dos benefícios de disponibilidade, também é preciso considerar os possíveis efeitos na complexidade operacional, latência e no custo.
- O número de níveis em uma pilha de infraestrutura (ou seja, a profundidade da pilha) tem uma relação inversa com a disponibilidade agregada da pilha. Considere essa relação ao desenvolver ou modificar sua pilha.
Para ver exemplos de cálculos de disponibilidade agregada, consulte as seguintes seções:
- Exemplo de cálculo: implantação em uma única zona
- Exemplo de cálculo: implantação em várias zonas
- Exemplo de cálculo: implantação multirregional com balanceamento de carga regional
- Exemplo de cálculo: implantação multirregional com balanceamento de carga global
Escopos de local
O escopo do local de um recurso do Google Cloud determina até que ponto uma falha de infraestrutura pode afetar o recurso. A maioria dos recursos provisionados no Google Cloud tem um dos seguintes escopos de localização: zonal, regional, multirregional ou global.
O escopo de localização de alguns tipos de recursos é fixo. Ou seja, não é possível escolher ou alterar o escopo. Por exemplo, as redes de nuvem privada virtual (VPC) são recursos globais, e as máquinas virtuais (VMs) do Compute Engine são recursos zonais. Para determinados recursos, é possível escolher o escopo do local enquanto provisiona o recurso. Por exemplo, ao criar um cluster do Google Kubernetes Engine (GKE), é possível criar um cluster regional ou zonal do GKE.
As seções a seguir descrevem os escopos de local em mais detalhes.
Recursos zonais
Os recursos zonais são implantados em uma única zona em uma região do Google Cloud. Veja a seguir exemplos de recursos zonais. Esta não é uma lista completa.
- VMs do Compute Engine
- Grupos de instâncias gerenciadas por zona (MIGs)
- Discos permanentes por zona
- Clusters do GKE de zona única
- Instâncias básicas e zonais do Filestore
- Jobs do Dataflow
- Instâncias do Cloud SQL
- Clusters do Dataproc no Compute Engine
Uma falha em uma zona pode afetar os recursos zonais provisionados nessa zona. As zonas são projetadas para minimizar o risco de falhas correlacionadas com outras zonas na região. Uma falha em uma zona geralmente não afeta os recursos nas outras zonas da região. Além disso, uma falha em uma zona não faz com que toda a infraestrutura dela esteja indisponível. A zona apenas define o limite esperado para o efeito de uma falha.
Para proteger aplicativos que usam recursos zonais contra incidentes zonais, é possível distribuir ou replicar os recursos em várias zonas ou regiões. Para mais informações, consulte Criar uma infraestrutura confiável para suas cargas de trabalho no Google Cloud.
Recursos regionais
Os recursos regionais são implantados de maneira redundante em várias zonas de uma região. Veja a seguir exemplos de recursos regionais. Esta não é uma lista completa.
- MIGs regionais
- Buckets regionais do Cloud Storage
- Discos permanentes regionais
- Clusters regionais do GKE com a configuração padrão (várias zonas)
- sub-redes VPC
- Balanceadores de carga de aplicativo externos regionais
- Instâncias regionais do Spanner
- Instâncias do Filestore Enterprise
- Serviços do Cloud Run
Os recursos regionais são resilientes a incidentes em uma zona específica. Uma falha temporária na região pode afetar alguns ou todos os recursos regionais provisionados nessa região. Essas falhas temporárias podem ser causadas por desastres naturais ou falhas de infraestrutura em grande escala.
Recursos multirregionais
Os recursos multirregionais são distribuídos entre regiões específicas. Veja a seguir exemplos de recursos multirregionais. Esta não é uma lista completa.
- Buckets do Cloud Storage birregionais e multirregionais
- Instâncias multirregionais do Spanner
- Instâncias do Bigtable em vários clusters (multirregional)
- Keyrings multirregionais no Cloud Key Management Service
Para ver uma lista completa dos serviços do Google disponíveis em configurações multirregionais, consulte Produtos disponíveis por local.
Os recursos multirregionais são resilientes a incidentes em regiões e zonas específicas. Uma falha temporária na infraestrutura que ocorre em várias regiões pode afetar a disponibilidade de alguns ou de todos os recursos multirregionais provisionados nas regiões afetadas.
Recursos globais
Os recursos globais estão disponíveis em todos os locais do Google Cloud. Veja a seguir exemplos de recursos globais. Esta não é uma lista completa.
projetos e pagam por eles. Para orientações e práticas recomendadas sobre como organizar seus recursos do Google Cloud em pastas e projetos, consulte Decidir uma hierarquia de recursos para sua zona de destino do Google Cloud.
Redes VPC, incluindo rotas associadas e regras de firewall
Zonas do Cloud DNS
Balanceadores de carga de aplicativos externos globais
Keyrings globais no Cloud Key Management Service
Tópicos do Pub/Sub
Secrets no Secret Manager
Para uma lista completa dos serviços do Google disponíveis globalmente, consulte Produtos globais.
Os recursos globais são resilientes a incidentes zonais e regionais. Esses recursos não dependem de infraestrutura em uma região específica. O Google Cloud tem sistemas e processos que ajudam a minimizar o risco de falhas temporárias na infraestrutura global. O Google também monitora continuamente a infraestrutura e resolve rapidamente falhas globais.
Veja na tabela a seguir um resumo da resiliência relativa de recursos zonais, regionais, multirregionais e globais aos problemas de aplicativos e infraestrutura. Também descreve o esforço necessário para configurar esses recursos e recomendações para reduzir os efeitos das interrupções.
| Escopo do recurso | Resiliência | Recomendações para reduzir os efeitos de falhas na infraestrutura |
|---|---|---|
| Zonal | Baixa | Implantar os recursos de maneira redundante em várias zonas ou regiões. |
| Regional | Média | Implantar os recursos de maneira redundante em várias regiões. |
| Multirregional ou global | Altos | Gerencie as mudanças com cuidado e use substitutos de defesa detalhadas sempre que possível. Para mais informações, consulte Recomendações para gerenciar o risco de interrupções de recursos globais. |
Recomendações para gerenciar o risco de falhas temporárias de recursos globais
Para aproveitar a resiliência dos recursos globais às falhas temporárias de zona e região, use determinados recursos globais na sua arquitetura. O Google recomenda as seguintes abordagens para gerenciar o risco de interrupções de recursos globais:
Gerenciamento cuidadoso das mudanças nos recursos globais
Os recursos globais são resilientes a falhas físicas. A configuração desses recursos tem escopo global. Assim, definir e configurar um único recurso global é mais fácil do que operar vários recursos regionais. No entanto, um erro crítico na configuração de um recurso global pode torná-lo um ponto único de falha (SPOF, na sigla em inglês). Por exemplo, é possível usar um balanceador de carga global como front-end para um aplicativo distribuído geograficamente. Um balanceador de carga global geralmente é uma boa opção para esse aplicativo. No entanto, um erro na configuração do balanceador de carga pode torná-lo indisponível em todas as geografias. Para evitar esse risco, é necessário gerenciar cuidadosamente as alterações de configuração nos recursos globais. Para mais informações, consulte Controlar alterações nos recursos globais.
Uso de recursos regionais como substitutos da defesa
Para aplicativos que têm requisitos de disponibilidade excepcionalmente altos, substitutos de defesa detalhados regionais podem ajudar a minimizar o efeito de interrupções de recursos globais. Considere o exemplo de um aplicativo distribuído geograficamente que tem um balanceador de carga global como front-end. Implante o balanceador de carga regional para garantir que o aplicativo permaneça acessível mesmo que o balanceador de carga global seja afetado por uma falha global. É possível configurar os clientes para preferir o balanceador de carga global, mas ocorrerá uma fala no balanceador de carga regional mais próximo se o balanceador de carga global não estiver disponível.
Exemplo de arquitetura com recursos zonais, regionais e globais
A topologia da nuvem pode incluir uma combinação de recursos zonais, regionais e globais, conforme mostrado no diagrama a seguir. O diagrama a seguir mostra um exemplo de arquitetura para um aplicativo de vários níveis implantado no Google Cloud.
Conforme mostrado no diagrama anterior, um balanceador de carga HTTP/S externo global recebe solicitações de clientes. O balanceador de carga distribui as solicitações para o back-end, que é um MIG regional que tem duas VMs do Compute Engine. O aplicativo em execução nas VMs grava dados e lê em um banco de dados do Cloud SQL. O banco de dados está configurado para alta disponibilidade. As instâncias primária e de espera do banco de dados são provisionadas em zonas separadas, e o banco de dados primário é replicado de forma síncrona no banco de dados em espera. Além disso, o banco de dados é armazenado em backup automaticamente em um bucket multirregional no Cloud Storage.
Veja na tabela a seguir um resumo dos recursos do Google Cloud na arquitetura anterior e a resiliência de cada recurso em caso de falhas temporárias em zonas e regiões:
| Recurso | Resiliência a falhas temporárias |
|---|---|
| Rede VPC | Redes VPC são recursos globais, inclusive as respectivas rotas associadas e regras de firewall. Elas são resilientes a falhas temporárias em zonas e regiões. |
| Sub-redes | As sub-redes VPC são recursos regionais. Elas são resilientes a falhas de zona. |
| Balanceador de carga HTTP/S externo global | Os balanceadores de carga HTTP/S externos globais são resilientes a falhas de zona e região. |
| MIG regional | Os MIGs regionais são resilientes a falhas temporárias de zonas. |
| VMs do Compute Engine | As VMs do Compute Engine são recursos zonais. Se ocorrer uma falha temporária na zona, as VMs individuais do Compute Engine poderão ser afetadas. No entanto, o aplicativo pode continuar a veicular solicitações porque o back-end do balanceador de carga é um MIG regional, e não VMs independentes. |
| Instâncias do Cloud SQL | A implantação do Cloud SQL nesta arquitetura está configurada
para alta disponibilidade. Ou seja, a implantação inclui um par de instâncias de banco de dados primário em espera. O banco de dados primário é replicado de maneira síncrona
para o banco de dados de espera usando discos permanentes regionais.
|
| Bucket do Cloud Storage multirregional | Os dados armazenados em buckets multirregionais do Cloud Storage são resilientes a falhas temporárias em apenas uma região. |
| Discos permanentes | Os discos permanentes podem ser zonais ou regionais. Os discos permanentes regionais são resilientes a interrupções de zona. Para se preparar para a recuperação de interrupções da região, programe snapshots de discos permanentes e armazene-os em um bucket multirregional do Cloud Storage. |