Geografia e regiões

Os produtos do Google Cloud são fornecidos a partir de domínios de falha regionais específicos e têm o suporte total dos Contratos de nível de serviço para garantir a criação da arquitetura do aplicativo dentro da estrutura de Google Cloud.

Os serviços de infraestrutura do Google Cloud estão disponíveis em locais na América do Norte, na América do Sul, na Europa, na Ásia, no Oriente Médio e na Austrália. Esses locais estão divididos em regiões e zonas. É possível escolher a localização dos seus aplicativos para atender aos seus requisitos de latência, disponibilidade e durabilidade.

Faça um teste

Se você começou a usar o Google Cloud agora, crie uma conta para avaliar o desempenho dos nossos produtos em situações reais. Clientes novos também recebem US$ 300 em créditos para executar, testar e implantar cargas de trabalho.

Comece a usar gratuitamente

Regiões e zonas

Regiões são áreas geográficas independentes que consistem em zonas. Zonas e regiões são abstrações lógicas de recursos físicos subjacentes fornecidos em um ou mais data centers físicos. Esses data centers podem pertencer ao Google e estar listados na página de locais do Google Cloud ou ser alugados por provedores de data centers de terceiros. Veja também a lista completa de locais de data centers para o Google Cloud, consulte nosso certificado ISO/IEC 27001. Independentemente de o data center ser próprio ou alocado, o Google Cloud seleciona data centers e projeta sua infraestrutura para fornecer um nível uniforme de desempenho, segurança e confiabilidade

Uma zona é uma área de implantação de recursos do Google Cloud em uma região. As zonas devem ser consideradas um domínio de falha único dentro de uma região. Para implantar aplicativos tolerantes a falhas com alta disponibilidade e ajudar a proteger contra falhas inesperadas, implante seus aplicativos em várias zonas em uma região.

Para se proteger contra a perda de uma região inteira devido a um desastre natural, tenha um plano de recuperação de desastres e saiba como acessar seu aplicativo no caso improvável de perder sua região principal. Consulte considerações sobre a implantação do aplicativo para mais informações.

Para mais informações sobre os recursos específicos disponíveis em cada opção de local, consulte os Locais do Cloud.

Os serviços e recursos do Google Cloud podem ser zonais, regionais ou gerenciados pelo Google em várias regiões. Para mais informações sobre o significado dessas opções para seus dados, consulte Gerenciamento geográfico de dados.

O Google Cloud pretende oferecer no mínimo três zonas de disponibilidade (zonas fisicamente e logicamente diferentes) em cada região de uso geral.

Recursos por zona

Os recursos por zona funcionam apenas em uma zona. Falhas zonais podem afetar alguns ou todos os recursos da zona. Um exemplo de recurso zonal é uma instância de máquina virtual (VM) do Compute Engine que reside em uma zona específica.

Recursos regionais

Recursos regionais são recursos implantados de forma redundante em várias zonas de uma região, como aplicativos do App Engine ou grupos gerenciados de instâncias regionais. Isso proporciona a eles mais disponibilidade em relação aos recursos de zona.

Recursos multirregionais

Vários serviços do Google Cloud são gerenciados pelo Google para serem redundantes e distribuídos entre várias regiões. Esses serviços otimizam a disponibilidade, o desempenho e a eficiência do recurso. Como resultado, eles exigem um equilíbrio entre a latência ou o modelo de consistência. Essas contrapartidas são documentadas com base em um produto específico.

Os seguintes serviços têm um ou mais locais multirregionais, além de locais regionais:

Artifact Registry
Bigtable
Proteção de dados confidenciais
API Cloud Healthcare
Cloud KMS
Container Registry
Spanner
Cloud Storage
Database Migration Service
Datastore
Firestore

Esses serviços multirregionais são projetados para funcionar após a perda de uma única região.

Para mais informações, consulte Produtos disponíveis por local e a documentação de cada produto.

Serviços globais

O Google Cloud foi projetado para operar globalmente do zero e realiza manutenção e upgrades contínuos 24 horas por dia, 7 dias por semana e 365 dias por ano, sem que você precise entrar em contato. Nosso backbone global oferece flexibilidade maciça para balanceamento de carga e reduz a latência do usuário final por ter interconexões próximas a ele. Nosso plano de gerenciamento de nuvem global simplifica o gerenciamento de desenvolvimentos multirregionais.

Serviços internos

A base e o suporte de muitos serviços do Google Cloud voltados ao cliente são um conjunto de serviços internos comprovados, como Spanner, Colossus, Borg e Chubby.

O balanceamento de carga desses serviços internos é global em várias regiões ou exclusivo de cada região em que está disponível. Quando os serviços de balanceamento de carga são de várias regiões, implantamos atualizações gradualmente por região. Dessa forma, podemos detectar e resolver problemas sem afetar o uso do serviço. Nenhum desses serviços internos é limitado a um único data center lógico ou a uma única região.

Os serviços internos globais podem ser executados ou replicados nas regiões da nuvem a seguir:

América

southamerica-west1
us-central1
us-east1
us-east4
us-west1
us-west4

Europa

europe-north1
europe-west1
europe-west4

Ásia

asia-east1
asia-southeast1

Dependências do serviço

Em geral, para serviços do Google Cloud, se uma única região falhar, somente os clientes daquela região serão afetados; os clientes com produtos multirregionais não serão afetados. O Google Cloud tem uma arquitetura significativa em vigor para impedir falhas correlacionadas entre regiões.

Todos os serviços do Google Cloud contam com as principais ferramentas internas para fornecer serviços fundamentais, como redes (dentro e fora de data centers), acesso a data centers e sistemas de autorização de identidade. Essas ferramentas são resilientes a interrupções regionais, com o objetivo de uma região não ser afetada se outras regiões ficarem indisponíveis.

O Google Cloud oferece uma orientação clara sobre como os clientes podem arquitetar seus aplicativos para o nível desejado de resiliência no nosso site público, principalmente para produtos de uso comum do Google Cloud, como Compute Engine, BigQuery, Pub/Sub e outros serviços.

Nossas principais dependências estão listadas abaixo, começando com dependências comuns a todos os serviços, com a probabilidade de que os detalhes de implementação de nível inferior estejam sujeitos a alterações.

Dependências comuns para todos os serviços

Plano de dados de identidade para autenticação e autorização
Serviços internos que fornecem geração de registros, armazenamento de metadados e gerenciamento de fluxo de trabalho
O acesso às APIs do Google Cloud depende do DNS, de balanceadores de carga distribuídos globalmente e de pontos de presença (PoPs).
A configuração dos recursos globais: por exemplo, políticas de IAM, regras de firewall globais, configurações de balanceador de carga global e tópicos do Pub/Sub são armazenadas em bancos de dados replicados.
Quando os serviços do Google Cloud fazem solicitações a endpoints controlados pelo cliente, por exemplo, o Cloud EKM busca chaves ou clientes do Pub/Sub, essas solicitações dependem da nossa infraestrutura de rede global para acessar esses clientes de endpoints controlados.

Serviços com mais dependências

Serviços do Compute Engine
- Os planos de dados da VM do Google Cloud e do Persistent Disk dependem dos serviços do Compute Engine e do Cloud Storage de nível inferior, como o Borg e o Colossus.
O Google Cloud e os serviços de armazenamento de infraestrutura como Spanner, Bigtable e Cloud Storage dependem de:
- Infraestrutura de gerenciamento de criptografia e chaves para clientes (Cloud KMS/Cloud EKM) e infraestrutura interna para chaves de propriedade do Google
- Serviços internos para fornecer geração de registros e auditoria do acesso a dados
- Serviços internos de replicação de dados, em que se espera que os dados estejam disponíveis em várias regiões
- A replicação e os backups configurados explicitamente para outras regiões dependem da rede entre regiões.
Serviços de mensagens
- O Pub/Sub depende da nossa infraestrutura de rede global para acessar endpoints controlados pelo cliente
Serviços de redes
- O balanceamento de carga global, o DNS e o failover entre regiões dependem da infraestrutura de rede física.
- Impedir ataques de DDos e similares pode depender da infraestrutura de nível inferior do Compute Engine.
Serviços gerenciados e hospedados, como GKE e Cloud SQL,
- Depende do Compute Engine e no Container Registry ou no Artifact Registry para imagens de VM.
Infraestrutura de nível inferior independente
- Nosso plano interno de controle no nível de cluster, incluindo Borg e tecidos de rede
- Armazenamento no nível do cluster, como Colossus
- Infraestrutura de gerenciamento de criptografia e chaves

Como manter e melhorar a disponibilidade e a resiliência

A engenharia de confiabilidade do site (SRE) é a organização interna do Google dedicada a trabalhar na disponibilidade, latência, desempenho e capacidade. Falhas e indisponibilidade do serviço estão relacionadas à implantação de um novo código ou a alterações no ambiente. Usando as práticas recomendadas do setor, a SRE equilibra a necessidade de lançar novos softwares e mantém o ambiente seguro, com a compreensão de que essas alterações necessárias podem causar inatividade.

Como fazer parcerias com clientes para criar serviços resilientes

Se você tiver necessidades essenciais e precisar projetar para ter resiliência e recuperação de desastres, nossas equipes SRE/CRE e PSO podem ajudar você a arquitetar seus aplicativos para conectar várias regiões e zonas e, depois, a projetar sistemas de alta disponibilidade (HA, na sigla em inglês).

Se você tiver aumentado os requisitos de disponibilidade em datas específicas, como Black Friday/Cyber Monday, o Google Cloud tem um programa para fazer parceria com você para verificar e validar seu aplicativo específico em execução no Google Cloud, além de identificar quaisquer dependências de serviço imprevistas entre o aplicativo e os serviços.

Pontos de presença (POPs, na sigla em inglês)

O Google opera uma rede global de pontos de presença de peering, o que significa que o tráfego do cliente pode viajar dentro da rede até que esteja perto do destino, fornecendo uma experiência melhor e mais segurança aos usuários. Para mais informações, consulte Locais de borda de rede.

Gerenciamento geográfico de dados

A localidade dos dados para os serviços do Google Cloud é regida pelos Termos de Serviço, incluindo Termos de Serviço específicos. O Google entende que cada cliente tem necessidades exclusivas de segurança e conformidade. A equipe de vendas do Google Cloud pode ajudar você a atender a esses requisitos.

Ao usar recursos de armazenamento regional ou por zona, é altamente recomendável replicar dados para outra região ou enviar um snapshot deles para um recurso de armazenamento multirregional para fins de recuperação de desastres.

Considerações sobre a implantação do aplicativo

Para criar serviços e aplicativos altamente disponíveis que possam suportar zonas que estejam ficando indisponíveis

Use o seguinte:

Recursos regionais, como os aplicativos do App Engine, os grupos de instâncias gerenciadas regionais e recursos multirregionais gerenciados, como Cloud Storage, Datastore, Firestore ou Spanner.
recursos por zona, como máquinas virtuais do Compute Engine, mas gerencie a própria redundância de computação e armazenamento entre zonas ou regiões diferentes.

Para criar aplicativos capazes de se recuperar de desastres que consigam suportar a perda estendida de regiões inteiras

Para dados, use uma ou mais das seguintes estratégias:

Use serviços de armazenamento gerenciados e multirregionais, como Cloud Storage, Datastore, Firestore ou Spanner.
Use recursos regionais ou zonais, mas capture dados do snapshot para um recurso multirregional, como Cloud Storage, Datastore, Firestore ou Spanner.
Use recursos por zona ou regionais, mas gerencie a própria replicação de dados para uma ou mais regiões.

Para computação, use a seguinte estratégia:

Use recursos por zona ou regionais, como Compute Engine ou App Engine, mas carregue manual ou automaticamente o aplicativo em outra região (em caso de falha regional) referenciando cópias dos dados principais, caso os dados ainda não estejam em um recurso gerenciado multirregional.

Para mais informações sobre dependências de serviço, entre em contato com o setor de vendas.

Mais soluções e tutoriais

Os seguintes tutoriais e soluções apresentam diretrizes para garantir que o aplicativo seja altamente disponível e possa suportar paralisações:

Padrões para apps escalonáveis e resilientes

Veja como usar o Google Cloud para criar arquiteturas de aplicativos escalonáveis e resilientes usando padrões e práticas que se aplicam amplamente a qualquer aplicativo da Web.

Como criar um balanceador de carga HTTPS

Configure instâncias do Compute Engine em regiões diferentes e use o balanceamento de carga HTTP para distribuir o tráfego entre as regiões a fim de aumentar a disponibilidade entre as regiões e oferecer um failover em caso de uma paralisação do serviço.