Práticas recomendadas para a seleção da região do Compute Engine

Neste artigo, descrevemos os critérios que você precisa levar em conta ao escolher as regiões do Google Cloud Platform (GCP) que serão usadas para os recursos do Compute Engine, uma decisão que normalmente é tomada por arquitetos de nuvem ou 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 aplicativo
  • 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. Os locais nas regiões tendem a apresentar latências de rede de retorno inferior a 1 ms no 95º percentil.

zona

Uma área de implantação de recursos do GCP em determinada região. As zonas são projetadas para serem independentes entre si: os planos de alimentação, refrigeração, rede e controle são isolados de outras zonas. Eventos de falha única normalmente afetam apenas uma única zona.

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 Cloud Dataflow, usam recursos do Compute Engine e, portanto, podem ser implantados nas mesmas regiões ou zonas.

tempo de retorno (RTT, na sigla em inglês)

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.
  • O processo de mover um aplicativo e os dados entre regiões é complicado e dispendioso, por isso, evite fazê-lo 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 serviços de banco de dados locais interconectados com o GCP pode ser o fator decisivo.

Preço

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

Se você decidir implantar em várias regiões, esteja ciente de que há cobranças de saída de rede para dados sincronizados entre regiões.

Colocation com outros serviços do GCP

Coloque seus recursos do Compute Engine com outros serviços do GCP 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.

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, se um usuário estiver conectado à Internet usando um computador desktop com fibra, a latência típica para alcançar o ISP é de 1 a 10 ms. Por outro lado, as latências típicas em uma rede celular 3G 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 borda e de front-end do Google

Dependendo do modelo de implantação, a latência para o ponto de extremidade de rede do Google também é importante. É aqui que os produtos de balanceamento de carga global encerram as sessões TCP e SSL e o Cloud Content Delivery Network fornece resultados 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 extremidade. A região do Compute Engine é onde as solicitações de processamento de recursos do GCP 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

A imagem a seguir ilustra 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 e back-end distribuídos em uma região única

O diagrama a seguir mostra um modelo de implantação em que há distribuição do front-end e back-end em uma região única. Este 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

No entanto, a latência do usuário diminui em implantações de back-end de região única se a solicitação do usuário médio não exigir nenhuma ou poucas solicitações de dados para o back-end central, até que o aplicativo apresente resultado. Por exemplo, a implantação de uma camada de cache inteligente no front-end ou manipulação e gravação de dados de maneira assíncrona.

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 Cloud 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 significativa porque é difícil manter os dados sincronizados globalmente, de maneira consistente. O gerenciamento é facilitado se o banco de dados for gravado somente em uma região por gravações assíncronas e as outras regiões hospedarem réplicas somente de leitura do banco de dados.

A replicação de vários mestres nas regiões é difícil, 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 aplicativos paralelos, todos compostos por um front-end e backend e os usuários são direcionados para o aplicativo correto. Apenas uma pequena fração de dados é compartilhada entre os sites.

Latência de aplicativos 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 desses métodos são recursos do GCP e outros exigem a alteração do seu aplicativo.

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 GCP, enquanto o nível Premium oferece menor latência ao enviar o tráfego por meio da rede privada de fibra 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 aplicativo 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 Cloud Memorystore para Redis é um armazenamento de dados na memória totalmente gerenciado, que pode ser usado.

Otimizar seu cliente do aplicativo 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 uma linha de base dos requisitos de latência, examine a base de usuários para decidir o melhor posicionamento dos recursos do GCP. 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 disponibilização do aplicativo ou para medir a latência para a rede local que pode estar interconectada ao projeto do GCP usando o Cloud VPN ou o Cloud Interconnect – Dedicado.

Estimar a latência para novas cargas de trabalho

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

A luz viaja em torno de 200.000 km/s (124.000 milhas) em fibra, mas estima-se em 1 ms a latência de ida e volta para cada 100 km percorridos. Dado que os cabos de fibra 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 fibras podem seguir um caminho ainda menos ideal. A latência incluída por meio de equipamentos ativos nas redes ISP é geralmente insignificante ao observar 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 ativo 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 um grupo representativo 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 GCP. É possível conseguir algumas medições em sites de terceiros, como o GCP ping.
  • Registros de acesso: se você tiver um aplicativo ativo hospedado fora do GCP, use os dados dos registros de acesso para conseguir uma seção aproximada dos 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 seus usuários, crie scripts para testar a acessibilidade e as latências de várias regiões do GCP. Se o firewall bloquear as sondagens, tente randomizar o último octeto de IP para conseguir uma resposta de outro dispositivo com latência similar ao seu aplicativo.
  • Informações de latência do GCP: se você tiver um aplicativo ativo no GCP, 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 em potencial 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 aplicativo. Para a maioria dos aplicativos destinados a dispositivos móveis e outros aplicativos críticos de não latência, uma implantação de única região, com entrega de conteúdos armazenáveis do Cloud CDN e encerramento SSL na extremidade pode ser a melhor opção.
  3. Fundamentado no modelo de implantação, escolha regiões com base na distribuição geográfica da base de usuários e em suas dimensões de latência:

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

      • se precisar de 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 seus 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 de seus usuários com base na sua distribuição geográfica e no requisito de latência do aplicativo. Dependendo do aplicativo, otimize para uma latência mediana específica ou certifique-se de que 95 a 99% dos usuários sejam atendidos com uma latência de segmentação específica. Os usuários em determinados locais geográficos frequentemente têm uma maior tolerância à 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.

Ao selecionar regiões do Compute Engine, a latência é um dos maiores fatores a ser levado em conta. 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

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…