Práticas recomendadas para a seleção de regiões do Compute Engine

Este artigo descreve os critérios que você precisa avaliar ao escolher as regiões do Google Cloud que serão usadas nos recursos do Compute Engine. Essa decisão costuma ser tomada por arquitetos de nuvem ou pela equipe de gerenciamento de engenharia. Este documento, que tem ênfase principalmente na latência do processo de seleção, se destina aos aplicativos acessados por consumidores, como aplicativos ou jogos para dispositivos móveis ou para a Web, mas muitos dos conceitos podem ser aplicados a outros casos de uso.

O Google oferece várias regiões em todo o mundo para implantação dos recursos do Compute Engine. Vários fatores desempenham um papel na escolha das regiões:

  • Restrições específicas da região
  • Latência do usuário por região
  • Requisitos de latência do app
  • Quantidade de controle sobre latência
  • Equilíbrio entre baixa latência e simplicidade

Terminologia

região
Uma área geográfica independente em que seus recursos são executados. Cada região é composta normalmente por pelo menos três zonas.
zona
Uma área de implantação de recursos do Google Cloud em uma região. Colocar recursos em diferentes zonas de uma região reduz o risco de interrupção da infraestrutura que afeta todos os recursos simultaneamente.
Recursos do Compute Engine
Recursos do Compute Engine, como as instâncias de máquina virtual, são implantados em uma zona dentro de uma região. Outros produtos, como o Google Kubernetes Engine e o Dataflow, usam recursos do Compute Engine e, portanto, podem ser implantados nas mesmas regiões ou zona.
tempo de retorno (RTT)
O tempo necessário para enviar um pacote IP e receber a confirmação.

Quando escolher as regiões do Compute Engine

No início da fase de arquitetura de um aplicativo, decida quantas e quais regiões do Compute Engine serão usadas. Sua escolha pode afetar o aplicativo, por exemplo:

  • A arquitetura do aplicativo pode mudar se você sincronizar alguns dados entre as cópias, porque os mesmos usuários podem se conectar por regiões diferentes, em momentos diferentes.
  • O preço depende da região.
  • A movimentação de um aplicativo e os dados dele entre regiões é complicada e dispendiosa, por isso, evite fazê-la quando o aplicativo estiver ativo.

Fatores que precisam ser avaliados ao selecionar regiões

É comum as pessoas implantarem na região em que estão localizadas, sem considerar se essa é a melhor experiência do usuário. Imagine que você está na Europa, com uma base global de usuários e queira implantar em uma única região. A maioria das pessoas pensaria na implantação em uma região da Europa, mas a melhor escolha para hospedar esse aplicativo é uma das regiões dos EUA, por serem os mais conectados a outras regiões.

Diversos fatores afetam a escolha do local em que você decide implantar o aplicativo.

Latência

O principal fator a ser avaliado é a experiência de latência que o usuário tem. No entanto, este é um problema complexo porque a latência do usuário é afetada por diversos aspectos, como mecanismos de armazenamento em cache e de balanceamento de carga.

Em casos de uso corporativo, a latência para sistemas locais ou para um determinado subconjunto de usuários ou parceiros é mais crítica. Por exemplo, escolher a região mais próxima dos desenvolvedores ou dos serviços de banco de dados locais interconectados com o Google Cloud pode ser o fator decisivo.

Preço

Os custos dos recursos do Google Cloud variam por região. Os seguintes recursos estão disponíveis para estimativa de preço:

Se você decidir pela implantação em várias regiões, esteja ciente de que há cobranças de transferência de dados para dados sincronizados entre regiões.

Colocation com outros serviços do Google Cloud

Posicione seus recursos do Compute Engine junto com outros serviços do Google Cloud sempre que possível. A maioria dos serviços sensíveis à latência estão disponíveis em todas as regiões, mas alguns estão disponíveis somente em locais específicos.

Disponibilidade do tipo de máquina

Nem todas as plataformas de CPU e tipos de máquinas estão disponíveis em todas as regiões. A disponibilidade de plataformas de CPU ou tipos de instâncias específicas depende tanto da região quanto da zona. Se você quiser implantar recursos usando determinados tipos de máquina, saiba mais sobre a disponibilidade zonal desses recursos.

Cotas de recursos

A capacidade de implantar recursos do Compute Engine é limitada pelas cotas de recursos regionais, portanto, solicite uma cota suficiente para as regiões em que você planeja implantar. Se estiver planejando uma implantação especialmente ampla, trabalhe primeiro com a equipe de vendas para discutir as opções de seleção de região e garantir que você tenha capacidade de cota suficiente.

Porcentagem de energia sem emissão de carbono

Para fornecer energia a cada região do Google Cloud, o Google usa eletricidade da grade em que a região está localizada. Essa eletricidade gera mais ou menos emissões de carbono, dependendo do tipo de usina que gera eletricidade para essa grade e quando o Google a consome. O Google estabeleceu recentemente a meta de que, até 2030, teremos eletricidade sem carbono nos aplicativos no tempo e no lugar que os aplicativos forem necessários, 24 horas por dia em todas as regiões do Google Cloud.

Até que essa meta seja alcançada, cada região do Google Cloud será abastecida por uma combinação de fontes de energia baseadas em carbono e sem carbono a cada hora. Chamamos essa métrica de porção de energia sem carbono (CFE) e publicamos uma porcentagem de CFE para as regiões do Google Cloud. Para novos aplicativos no Google Cloud, você pode usar essa tabela para começar a incorporar o impacto do carbono nas decisões de arquitetura. Escolher uma região com uma porcentagem maior de CFE significa que, em média, o aplicativo será abastecido com energia livre de carbono em uma porcentagem maior das horas que ele é executado, reduzindo a emissão bruta de carbono desse aplicativo.

Avaliar os requisitos de latência

A latência costuma ser a principal consideração para a seleção de região, porque a alta latência do usuário pode proporcionar uma experiência inferior. É possível interferir em alguns aspectos da latência, mas alguns estão fora do seu controle.

Ao otimizar a latência, muitos arquitetos de sistema se importam apenas com a latência de rede ou a distância entre o ISP do usuário final e a máquina virtual. No entanto, esse é apenas um dos muitos fatores que afetam a latência do usuário, como pode ser visto no diagrama a seguir:

Avaliar a latência na seleção de região do Compute Engine

Os arquiteto de aplicativos podem otimizar a seleção de região e a latência do aplicativo, mas não têm controle sobre a latência e última milha do usuário para o Ponto de Presença (POP) de extremidade do Google mais próximo.

A seleção de região afeta apenas a latência para a região do Compute Engine e não a totalidade da latência. Dependendo do caso de uso, isso poderá ser uma parte muito pequena da latência geral. Por exemplo, se os usuários estiverem usando principalmente redes celulares, talvez não seja relevante tentar otimizar suas regiões, uma vez que isso dificilmente afeta a latência total do usuário.

Latência de última milha

A latência desse segmento varia dependendo da tecnologia usada para acessar a internet. Por exemplo, a latência típica para alcançar um ISP nas redes modernas é de 1 a 10 ms. Por outro lado, as latências em uma rede celular 3G normalmente são de 100 a 500 ms. O intervalo de latência para DSL e provedores de cabo é de aproximadamente 10 a 60 ms.

Latência de POP de front-end e borda do Google

Dependendo do modelo de implantação, a latência para a borda de rede do Google também é importante. É aqui que os produtos de balanceamento de carga global encerram as sessões de TCP e SSL. E, a partir delas, o Cloud CDN fornece os resultados armazenados em cache. Com base no conteúdo disponibilizado, muitas idas e vindas terminam aqui, porque apenas parte dos dados precisa ser recuperada ao longo de todo o processo. Essa latência pode ser significativamente maior se você usar o nível de serviço de rede padrão.

Latência de região do Compute Engine

A solicitação do usuário entra na rede do Google no POP de borda. A região do Compute Engine é onde as solicitações de processamento de recursos do Google Cloud estão localizadas. Esse segmento é a latência entre o POP de extremidade e a região do Compute Engine e fica totalmente na rede global do Google.

Latência do aplicativo

Essa é a latência do aplicativo que responde às solicitações, incluindo o tempo necessário para o aplicativo processar a solicitação.

Dispositivos diferentes têm diferentes requisitos de latência. Dependendo do aplicativo, os usuários são mais tolerantes quanto aos problemas de latência. Aplicativos que interagem de maneira assíncrona ou aplicativos para dispositivos móveis com um limite alto de latência (100 milissegundos ou mais), podem ser implantados em uma única região sem prejudicar a experiência do usuário. No entanto, em aplicativos como jogos em tempo real, alguns milissegundos de latência podem ter maior influência na experiência do usuário. Implante esses tipos de aplicativos em várias regiões próximas aos usuários.

Padrões globais de implantação

Nesta seção, explicamos como os vários modelos de implantação afetam os fatores de latência.

Implantação de região única

Na imagem a seguir, você verá uma implantação de região única.

Latência de implantação única de front-end

Mesmo que seu aplicativo disponibilize uma base global de usuários, há muitos casos em que uma região única ainda é a melhor escolha. Os benefícios de baixa latência podem não compensar o aumento de complexidade da implantação em várias regiões. Mesmo com a implantação de uma região única, é possível usar otimizações como o Cloud CDN e o balanceamento de carga global, para reduzir a latência do usuário. É possível escolher uma segunda região para fins de backup e recuperação de desastres, mas isso não afeta o caminho de disponibilização do aplicativo e, portanto, não afetará a latência do usuário.

Front-end distribuído em várias regiões e back-end em uma região

O diagrama a seguir mostra um modelo de implantação em que há uma distribuição do front-end em várias regiões, mas o back-end se limita a uma única região. Esse modelo permite que você se beneficie da menor latência para os servidores de front-end, sem precisar sincronizar dados em várias regiões.

Latência de implantação distribuída de front-end

Esse modelo de implantação fornece baixa latência de usuário em cenários em que a solicitação do usuário médio não inclui solicitações de dados ou inclui apenas algumas para o back-end central antes que o app produza um resultado. Um exemplo seria um app que implanta uma camada de armazenamento em cache inteligente no front-end ou que processa gravações de dados de forma assíncrona. Um app que faz muitas solicitações que exigem um retorno completo para o back-end provavelmente não se beneficiará desse modelo.

Front-end e back-end distribuídos em várias regiões

Um modelo de implantação que distribui o front-end e o back-end em várias regiões permite minimizar a latência do usuário, porque o aplicativo atende totalmente qualquer solicitação no local. No entanto, esse modelo é mais complexo porque todos os dados precisam ser armazenados e acessados localmente. Para responder a todas as solicitações de usuários, os dados precisam ser totalmente replicados em todas as regiões.

Latência de várias implantações distribuídas

O Spanner, que é a oferta de banco de dados gerenciado globalmente de maneira consistente, oferece uma opção multirregional de três continentes, em que, além das réplicas de leitura e gravação nos EUA, há duas réplicas de leitura localizadas na Europa e na Ásia. Nessa opção é fornecido acesso de leitura de baixa latência aos dados, para instâncias de computação situadas nos EUA, Europa ou Ásia. Se o serviço estiver segmentando os EUA, há também uma opção multirregional com replicação nos EUA.

Se decidir executar seu próprio serviço de banco de dados no Compute Engine, você mesmo replicará os dados. Essa replicação é uma tarefa importante porque é difícil manter os dados sincronizados globalmente de maneira consistente. É mais fácil gerenciar quando o banco de dados é gravado somente em uma região por gravações assíncronas e as outras regiões hospedam réplicas somente leitura do banco de dados.

É difícil replicar várias bancos de dados em diversas regiões e recomendamos o engajamento de um parceiro forte com experiência nessa área, como o Datastax para replicação do Cassandra.

Vários aplicativos paralelos

Dependendo da natureza do seu aplicativo, com uma variação da abordagem anterior, é possível preservar a baixa latência do usuário e simultaneamente reduzir a necessidade de replicação constante de dados. Conforme ilustrado na imagem a seguir, há vários apps paralelos, todos compostos por um front-end e back-end, e os usuários são direcionados para o app correto. Apenas uma pequena fração de dados é compartilhada entre os sites.

Latência de apps paralelos

Por exemplo, ao administrar uma empresa de varejo, é preciso atender usuários em diferentes regiões por meio de domínios em países variados e executar sites paralelos em todas essas regiões, sincronizando dados de produtos e usuários somente quando necessário. Os sites locais mantêm a disponibilidade de estoque local e os usuários se conectam a um site hospedado localmente selecionando um domínio de país. Quando um usuário visita um domínio de país diferente, é redirecionado para o domínio correto.

Outro exemplo é nos jogos em tempo real. Talvez você tenha apenas um serviço de lobby global em que os usuários escolhem uma sala ou mundo de jogos perto da respectiva localidade, e essas salas ou mundos não compartilham dados entre si.

Um terceiro exemplo é oferecer o software como serviço (SaaS, na sigla em inglês) em diferentes regiões em que a localização dos dados é selecionada na criação da conta, seja com base na localização ou escolha do usuário. Após o login, o usuário é redirecionado para um subdomínio específico do local e usa o serviço regionalmente.

Otimizar a latência entre usuários e regiões

Independentemente do modelo de implantação, é possível combinar métodos de otimização para reduzir a latência visível para o usuário final. Alguns dos métodos são recursos do Google Cloud, enquanto outros exigem a alteração do seu app.

Usar a rede nível Premium

O Google oferece Network Service Tiers premium (default) e padrão. O tráfego do nível Padrão é fornecido pelos ISPs de trânsito das regiões do Google Cloud, enquanto o nível Premium oferece menor latência ao enviar o tráfego por meio da rede privada global do Google. A rede nível Premium, em que a latência do usuário é reduzida, deve ser usada para todas as partes do app no caminho de disponibilização. Essa rede também é necessária para usar os produtos de balanceamento de carga global do Google.

Usar o Cloud Load Balancing e o Cloud CDN

Use o Cloud Load Balancing, como o balanceamento de carga HTTP(S), o TCP e o balanceamento de carga proxy SSL, para redirecionar automaticamente os usuários para a região mais próxima em que estão os back-ends com capacidade disponível.

Mesmo que seu aplicativo esteja somente em uma região única, o uso do Cloud Load Balancing continua fornecendo menor latência do usuário, porque as sessões TCP e SSL são encerradas na extremidade da rede. Encerre facilmente o tráfego de usuários com HTTP/2 e conexões UDP rápidas com a Internet (QUIC, na sigla em inglês). É possível também integrar o Cloud CDN com o balanceamento de carga HTTP(S) para fornecer ativos estáticos diretamente da extremidade da rede, reduzindo ainda mais a latência do usuário.

Cache no local

Quando os locais do front-end forem diferentes dos locais do back-end, verifique se as respostas dos serviços de back-end estão sendo armazenadas sempre que possível. Quando o front-end e o back-end estão na mesma região, a latência do aplicativo diminui, porque as consultas demoradas também são reduzidas. O Memorystore para Redis é um armazenamento de dados na memória totalmente gerenciado que pode ser utilizado.

Otimizar seu cliente do app ou front-end da Web

Para otimizar a latência do usuário, é possível usar técnicas no lado do cliente, seja um aplicativo para dispositivos móveis ou o front-end da Web. Por exemplo, pré-carregue alguns recursos ou armazene os dados em cache no aplicativo.

Também é possível otimizar a maneira como seu aplicativo busca informações, reduzindo o número de solicitações e recuperando informações em paralelo, sempre que possível.

Medir a latência do usuário

Depois de estabelecer um valor de referência para os requisitos de latência, examine a base de usuários para decidir o melhor posicionamento dos recursos do Google Cloud. Dependendo de este ser um aplicativo novo ou em uso, há diferentes estratégias a serem empregadas.

Use as estratégias a seguir para medir a latência para parceiros que você acessa durante a exibição do app ou para medir a latência para a rede local que pode estar interconectada ao projeto do Google Cloud usando o Cloud VPN ou a Interconexão dedicada.

Estimar a latência para novas cargas de trabalho

Se não houver um app ativo com uma base de usuários semelhante para seu novo app, estime a latência de várias regiões do Google Cloud com base na distribuição local aproximada da sua base de usuários esperada.

Estime 1 ms de latência de ida e volta para cada 100 km percorridos. Como as redes não seguem um caminho ideal da origem ao destino, estima-se que a distância real seja de 1,5 a 2 vezes a distância medida em um mapa. Claro que em algumas regiões menos povoadas, as redes podem seguir um caminho ainda menos ideal. A latência incluída por meio de equipamentos ativos nas redes ISP é geralmente insignificante quando se observa as distâncias entre regiões.

Esses números ajudam você a estimar a latência para nós de POP de extremidade e do Cloud CDN, bem como para as regiões do Compute Engine em todo o mundo, conforme listado no mapa de rede.

Medir a latência para usuários existentes

Caso você tenha um aplicativo atual com uma base de usuários similar, há várias ferramentas que podem ser usadas para melhor estimar as latências.

  • Usuários representantes: se você tiver usuários ou parceiros que formem uma amostra representativa de suas distribuições geográficas e que estejam dispostos a trabalhar com você ou colaboradores nesses países, peça a eles para medir a latência para várias regiões do Google Cloud. Sites de terceiros, como o Google Cloud ping, podem ajudar a conseguir algumas medições.
  • Registros de acesso: se você tiver um app ativo hospedado fora do Google Cloud, use os dados dos registros de acesso para conseguir uma amostra aproximada de usuários. Seus registros podem fornecer informações sobre o país ou a cidade, o que também permite estimar as latências.
  • Endereço IP: se você tiver acesso aos endereços IP dos usuários, crie scripts para testar a acessibilidade e as latências de várias regiões do Google Cloud. Se o firewall bloquear as sondagens, tente randomizar o último octeto de IP para receber uma resposta de outro dispositivo com latência similar ao seu aplicativo.

  • Informações de latência do Google Cloud: se você tiver um app ativo no Google Cloud, há várias maneiras de coletar informações de latência.

Conectividade global

Ao estimar a latência, mantenha a topologia da rede global do Google.

  • POPs: onde o tráfego do usuário entra na rede.
  • Nós do Cloud CDN: onde o tráfego é armazenado em cache.
  • Regiões: onde seus recursos podem ser localizados.
  • Conectividade: entre os POPs e as regiões.

Para ver uma lista de locais em que o Google interage com outros ISPs, acesse PeeringDB.

Ao decidir em que regiões implantar, verifique se você considerou a topologia inter-regional. Por exemplo, se você quiser implantar um aplicativo com uma base global de usuários em uma única região, é melhor ter o aplicativo hospedado em uma das regiões dos EUA, porque os EU são conectados à maioria das outras regiões. Há conectividade direta entre muitos continentes, mas há casos em que isso não ocorre, por exemplo, entre Europa e Ásia, passando portanto, pelos EUA.

Se o aplicativo estiver hospedado em várias regiões e for necessário sincronizar os dados, fique atento à latência entre essas regiões. A latência é geralmente estável, mas pode mudar com o tempo. Meça a própria latência adicionando instâncias de teste em todas as regiões possíveis ou use sites de terceiros para ter uma ideia das latências atuais entre as regiões.

Funcionamento em conjunto

Agora que foram avaliados os requisitos de latência, os possíveis modelos de implantação e a distribuição geográfica da sua base de usuários, você entende como esses fatores afetam a latência em determinadas regiões. É hora de decidir em que regiões lançar seu aplicativo.

Não há uma forma correta de ponderar os diferentes fatores, no entanto, a seguinte metodologia passo a passo pode ajudá-lo a decidir:

  1. Veja se há fatores relacionados à não latência que impeçam a implantação em regiões específicas, como preço ou colocation. Remova-os da lista de regiões.
  2. Escolha um modelo de implantação com base nos requisitos de latência e na arquitetura geral do app. Para a maioria dos apps destinados a dispositivos móveis e outros não críticos sem latência, uma implantação de única região com entrega de conteúdo armazenável em cache do Cloud CDN e encerramento SSL na borda pode ser a melhor opção.

  3. Com base no modelo de implantação, escolha as regiões de acordo com a distribuição geográfica da base de usuários e as dimensões de latência:

    • Para uma implantação de única região:

      • Se você precisar ter acesso de baixa latência às suas instalações corporativas, implante na região mais próxima desse local.
      • Se os usuários forem predominantemente de um país ou região, implante em uma região mais próxima dos usuários representantes.
      • Para uma base global de usuários, implante em uma região nos EUA.

    • Para uma implantação em várias regiões:

      • Escolha regiões próximas dos usuários com base na distribuição geográfica e no requisito de latência do aplicativo. Dependendo do aplicativo, otimize para uma latência mediana específica ou verifique se 95 a 99% dos usuários são atendidos com uma latência de segmentação específica. Os usuários de determinadas regiões geográficas costumam ter uma tolerância maior à latência por causa de limitações de infraestrutura.

  4. Se a latência do usuário for similar em várias regiões, o preço poderá ser o fator decisivo.

Na seleção de regiões do Compute Engine, a latência é um dos maiores fatores a serem considerados. Avalie e meça os requisitos de latência para fornecer uma experiência de usuário de qualidade e repita o processo se a distribuição geográfica da sua base de usuários for alterada.

A seguir