Este artigo descreve os critérios a ter em conta ao escolher as Google Cloud regiões a usar para os seus recursos do Compute Engine, uma decisão que é normalmente tomada por arquitetos da nuvem ou pela gestão de engenharia. Este documento foca-se principalmente no aspeto da latência do processo de seleção e destina-se a apps acedidas por consumidores, como apps ou jogos para dispositivos móveis ou Web, mas muitos dos conceitos podem aplicar-se a outros exemplos de utilização.
A Google oferece várias regiões em todo o mundo para implementar os seus recursos do Compute Engine. Vários fatores desempenham um papel na escolha das suas regiões:
- Restrições específicas da região
- Latência do utilizador por região
- Requisitos de latência da sua app
- Quantidade de controlo sobre a latência
- Equilíbrio entre a baixa latência e a simplicidade
Terminologia
- região
- Uma área geográfica independente onde executa os seus recursos. Cada região consiste em zonas, normalmente, pelo menos, três zonas.
- zona
- Uma área de implementação para Google Cloud recursos numa região. Colocar recursos em zonas diferentes numa região reduz o risco de uma interrupção da infraestrutura que afete todos os recursos em simultâneo.
- Recursos do Compute Engine
- Os recursos no Compute Engine, como as instâncias de máquinas virtuais, são implementados numa zona de uma região. Outros produtos, como o Google Kubernetes Engine e o Dataflow, usam recursos do Compute Engine e, por isso, podem ser implementados nas mesmas regiões ou zona.
- tempo de ida e volta (RTT)
- O tempo que demora a enviar um pacote IP e a receber a confirmação.
Quando escolher as regiões do Compute Engine
No início da fase de arquitetura de uma app, decida quantas e que regiões do Compute Engine usar. A sua escolha pode afetar a sua app, por exemplo:
- A arquitetura da sua app pode mudar se sincronizar alguns dados entre cópias, porque os mesmos utilizadores podem estabelecer ligação através de diferentes regiões em momentos diferentes.
- O preço difere consoante a região.
- O processo de mover uma app e os respetivos dados entre regiões é complexo e, por vezes, dispendioso, pelo que deve ser evitado assim que a app estiver em direto.
Fatores a considerar ao selecionar regiões
É comum as pessoas fazerem a implementação numa região onde se encontram, mas não consideram se esta é a melhor experiência do utilizador. Suponhamos que está localizado na Europa com uma base de utilizadores global e quer implementar numa única região. A maioria das pessoas consideraria a implementação numa região da Europa, mas normalmente é a melhor escolha ter esta app alojada numa das regiões dos EUA, porque os EUA são o país mais ligado a outras regiões.
Vários fatores afetam o local onde decide implementar a sua app.
Latência
O principal fator a considerar é a latência que o utilizador experimenta. No entanto, este é um problema complexo, porque a latência do utilizador é afetada por vários aspetos, como os mecanismos de colocação em cache e de equilíbrio de carga.
Nos exemplos de utilização empresarial, a latência para sistemas no local ou a latência para um determinado subconjunto de utilizadores ou parceiros é mais crítica. Por exemplo, escolher a região mais próxima dos seus programadores ou dos serviços de base de dados no local interligados com oGoogle Cloud pode ser o fator decisivo.
Preços
Google Cloud Os custos dos recursos diferem consoante a região. Os seguintes recursos estão disponíveis para estimar o preço:
Se decidir implementar em várias regiões, tenha em atenção que existem custos de transferência de dados para os dados sincronizados entre regiões.
Colocação conjunta com outros Google Cloud serviços
Localize os seus recursos do Compute Engine com outros serviços, sempre que possível. Google CloudEmbora a maioria dos serviços sensíveis à latência esteja disponível em todas as regiões, alguns serviços só estão disponíveis em localizações específicas.
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 específicas ou tipos de instâncias específicos difere por região e até mesmo por zona. Se quiser implementar recursos com determinados tipos de máquinas, saiba mais sobre a disponibilidade zonal destes recursos.
Quotas de recursos
A sua capacidade de implementar recursos do Compute Engine é limitada pelas quotas de recursos regionais. Por isso, certifique-se de que pede quota suficiente para as regiões nas quais planeia implementar. Se estiver a planear uma implementação especialmente grande, colabore com a equipa de vendas atempadamente para discutir as suas escolhas de seleção de regiões e garantir que tem capacidade de quota suficiente.
Percentagem de energia sem carbono
Para alimentar cada Google Cloud região, a Google usa eletricidade da rede onde a região está localizada. Esta eletricidade gera mais ou menos emissões de carbono, dependendo do tipo de centrais elétricas que geram eletricidade para essa rede e quando a Google a consome. Recentemente, a Google estabeleceu o objetivo de, até 2030, ter eletricidade sem carbono a alimentar as suas aplicações na hora e no local de que precisa, 24 horas por dia, em todas as Google Cloud regiões.
Até esse objetivo ser alcançado, cada Google Cloud região vai ser abastecida por uma combinação de fontes de energia com e sem carbono a cada hora. Denominamos esta métrica de percentagem de energia sem carbono (CFE%) e publicamos a CFE% para Google Cloud regiões. Para novas aplicações no Google Cloud, pode usar esta tabela para começar a incorporar o impacto de carbono nas suas decisões de arquitetura. Escolher uma região com uma percentagem de EFC mais elevada significa que, em média, a sua aplicação vai ser alimentada com energia sem carbono durante uma percentagem mais elevada das horas em que é executada, o que reduz as emissões brutas de carbono dessa aplicação.
Avalie os requisitos de latência
A latência é frequentemente a principal consideração para a seleção da região, uma vez que a latência elevada do utilizador pode resultar numa experiência do utilizador inferior. Pode afetar alguns aspetos da latência, mas alguns estão fora do seu controlo.
Quando otimizam em função da latência, muitos arquitetos de sistemas consideram apenas a latência da rede ou a distância entre o ISP do utilizador e a instância da máquina virtual. No entanto, este é apenas um dos muitos fatores que afetam a latência do utilizador, como pode ver no diagrama seguinte.
Como arquiteto de apps, pode otimizar a seleção de regiões e a latência das apps, mas não tem controlo sobre a latência e o último quilómetro dos utilizadores até aos Pontos de Presença (POP) da rede periférica da Google mais próximos.
A seleção da região só pode afetar a latência da região do Compute Engine e não a totalidade da latência. Consoante o exemplo de utilização, isto pode ser apenas uma pequena parte da latência geral. Por exemplo, se os seus utilizadores estiverem a usar principalmente redes móveis, pode não ser útil tentar otimizar as suas regiões, uma vez que isto afeta pouco a latência total do utilizador.
Latência do último quilómetro
A latência deste segmento difere consoante a tecnologia usada para aceder à Internet. Por exemplo, a latência típica para alcançar um ISP é de 1 a 10 ms em redes modernas. Por outro lado, as latências típicas numa rede móvel 3G são de 100 a 500 ms. O intervalo de latência para fornecedores de DSL e cabo é de aproximadamente 10 a 60 ms.
Latência do POP de extremidade e front-end da Google
Consoante o modelo de implementação, a latência até ao limite da rede da Google também é importante. É aqui que os produtos de balanceamento de carga global terminam as sessões TCP e SSL e a partir das quais a RFC do Google Cloud fornece resultados em cache. Com base no conteúdo publicado, muitas viagens de ida e volta podem já terminar aqui, porque apenas parte dos dados tem de ser obtida durante todo o processo. Esta latência pode ser significativamente superior se usar o nível de serviço de rede padrão.
Latência da região do Compute Engine
O pedido do utilizador entra na rede da Google no POP de limite. A região do Compute Engine é onde os Google Cloud recursos que processam pedidos estão localizados. Este segmento é a latência entre o POP de limite e a região do Compute Engine, e está totalmente dentro da rede global da Google.
Latência da app
Esta é a latência da app a responder a pedidos, incluindo o tempo de que a app precisa para processar o pedido.
As diferentes apps têm requisitos de latência diferentes. Dependendo da aplicação, os utilizadores são mais tolerantes com os problemas de latência. As apps que interagem de forma assíncrona ou as apps para dispositivos móveis com um limite de latência elevado (100 milissegundos ou mais) podem ser implementadas numa única região sem degradar a experiência do utilizador. No entanto, para apps como jogos em tempo real, alguns milissegundos de latência podem ter um efeito maior na experiência do utilizador. Implemente estes tipos de apps em várias regiões próximas dos utilizadores.
Padrões de implementação global
Esta secção explica como vários modelos de implementação afetam os fatores de latência.
Implementação de região única
A imagem seguinte ilustra uma implementação de região única.
Mesmo que a sua app sirva uma base de utilizadores global, em muitos casos, uma única região continua a ser a melhor escolha. As vantagens da latência mais baixa podem não compensar a complexidade adicional da implementação multirregional. Mesmo com uma implementação de região única, ainda pode usar otimizações, como o Cloud CDN e o balanceamento de carga global, para reduzir a latência do utilizador. Pode optar por usar uma segunda região por motivos de cópia de segurança e recuperação de desastres, mas isto não afeta o caminho de publicação da app e, por isso, não afeta a latência do utilizador.
Front-end distribuído em várias regiões e back-end numa única região
O diagrama seguinte mostra um modelo de implementação em que distribui o front-end por várias regiões, mas limita o back-end a uma única região. Este modelo oferece-lhe a vantagem de uma latência mais baixa para os servidores de front-end sem ter de sincronizar dados em várias regiões.
Este modelo de implementação oferece uma baixa latência do utilizador em cenários em que o pedido médio do utilizador não envolve pedidos de dados ou envolve apenas alguns pedidos de dados ao back-end central antes de a app poder produzir um resultado. Um exemplo é uma app que implementa uma camada de colocação em cache inteligente no frontend ou que processa as gravações de dados de forma assíncrona. Uma app que faz muitos pedidos que requerem uma viagem completa ao back-end pode não beneficiar deste modelo.
Front-end e back-end distribuídos em várias regiões
Um modelo de implementação em que distribui o front-end e o back-end em várias regiões permite-lhe minimizar a latência do utilizador, uma vez que a app pode responder totalmente a qualquer pedido localmente. No entanto, este modelo tem uma complexidade acrescida, uma vez que todos os dados têm de ser armazenados e acessíveis localmente. Para responder a todos os pedidos dos utilizadores, os dados têm de ser totalmente replicados em todas as regiões.
O Spanner, a oferta de base de dados gerida globalmente consistente, tem uma opção multirregional de três continentes, onde, além das réplicas de leitura/escrita nos EUA, existem duas réplicas de leitura na Europa e na Ásia. Esta opção oferece acesso de leitura de baixa latência aos dados para calcular instâncias situadas nos EUA, na Europa ou na Ásia. Se o seu serviço estiver a segmentar os EUA, também existe uma opção multirregional com replicação nos EUA.
Se decidir executar o seu próprio serviço de base de dados no Compute Engine, tem de replicar os dados manualmente. Esta replicação é uma tarefa significativa, uma vez que é difícil manter os dados sincronizados de forma consistente a nível global. É mais fácil gerir se a base de dados for escrita apenas numa região através de escritas assíncronas e as outras regiões alojarem réplicas só de leitura da base de dados.
A replicação de bases de dados entre regiões é difícil e recomendamos que colabore com um parceiro forte com experiência nesta área, como a Datastax para a replicação do Cassandra.
Várias apps paralelas
Consoante a natureza da sua app, com uma variação da abordagem anterior, pode preservar a baixa latência do utilizador e reduzir a necessidade de replicação constante de dados. Conforme ilustrado na imagem seguinte, existem várias apps paralelas, todas compostas por um front-end e um back-end, e os utilizadores são direcionados para a app correta. Apenas uma pequena fração dos dados é partilhada entre os sites.
Por exemplo, quando gere uma empresa de retalho, pode publicar anúncios para utilizadores em diferentes regiões através de domínios de países diferentes e executar sites paralelos em todas essas regiões, sincronizando apenas os dados dos produtos e dos utilizadores quando necessário. Os sites locais mantêm a disponibilidade de stock local e os utilizadores ligam-se a um site alojado localmente selecionando um domínio de país. Quando um utilizador visita um domínio de um país diferente, é redirecionado para o domínio correto.
Outro exemplo é nos jogos em tempo real. Pode ter apenas um serviço de lobby global onde os utilizadores escolhem uma sala de jogos ou um mundo perto da respetiva localização e essas salas ou mundos não partilham dados entre si.
Um terceiro exemplo é oferecer software como serviço (SaaS) em diferentes regiões, onde a localização dos dados é selecionada no momento da criação da conta, com base na localização do utilizador ou na respetiva escolha. Depois de iniciar sessão, o utilizador é redirecionado para um subdomínio específico da localização e usa o serviço regionalmente.
Otimize a latência entre utilizadores e regiões
Independentemente do modelo de implementação, pode combinar métodos de otimização para reduzir a latência visível para o utilizador final. Alguns destes métodos sãoGoogle Cloud funcionalidades, enquanto outros requerem que altere a sua app.
Use a rede de nível Premium
A Google oferece níveis de serviço de rede premium (predefinição) e padrão. O tráfego de nível padrão é fornecido através de ISPs de trânsito de Google Cloud regiões, enquanto o nível premium oferece uma latência mais baixa através do fornecimento do tráfego através da rede privada global da Google. A rede de nível Premium reduz a latência do utilizador e deve ser usada para todas as partes da app no caminho de publicação. A rede de nível Premium também é necessária para usar os produtos de balanceamento de carga global da Google.
Use o Cloud Load Balancing e o Cloud CDN
O Cloud Load Balancing, como o balanceamento de carga de HTTP(S), TCP e proxy SSL, permite-lhe redirecionar automaticamente os utilizadores para a região mais próxima onde existem back-ends com capacidade disponível.
Mesmo que a sua app esteja apenas numa única região, a utilização do Cloud Load Balancing continua a proporcionar uma latência mais baixa para o utilizador, porque as sessões TCP e SSL são terminadas no limite da rede. Termine facilmente o tráfego de utilizadores com HTTP/2 e Quick UDP Internet Connections (QUIC). Também pode integrar o Cloud CDN com o balanceamento de carga HTTP(S) para fornecer recursos estáticos diretamente a partir do limite da rede, o que reduz ainda mais a latência do utilizador.
Coloque em cache localmente
Quando as localizações de front-end são diferentes das localizações de back-end, certifique-se de que coloca em cache as respostas dos serviços de back-end sempre que possível. Quando o front-end e o back-end estão na mesma região, a latência da app é reduzida porque as consultas demoradas também são reduzidas. O Memorystore for Redis é um armazenamento de dados na memória totalmente gerido que pode usar.
Otimize o cliente da app ou o frontend Web
Pode usar técnicas no lado do cliente, quer seja uma app para dispositivos móveis ou o frontend da Web, para otimizar a latência do utilizador. Por exemplo, pré-carregue alguns recursos ou coloque dados em cache na app.
Também pode otimizar a forma como a sua app obtém informações reduzindo o número de pedidos e obtendo informações em paralelo, sempre que possível.
Meça a latência do utilizador
Depois de estabelecer uma base de referência dos seus requisitos de latência, analise a sua base de utilizadores para decidir o melhor posicionamento dos seus Google Cloud recursos. Consoante se trata de uma app nova ou existente, existem diferentes estratégias a usar.
Use as seguintes estratégias para medir a latência dos parceiros aos quais acede durante a publicação de apps ou para medir a latência da sua rede no local que pode estar interligada ao seu projeto através da Cloud VPN ou do Dedicated Interconnect. Google Cloud
Estime a latência para novas cargas de trabalho
Se não tiver uma app existente com uma base de utilizadores semelhante à da nova app, estime a latência de várias Google Cloud regiões com base na distribuição aproximada da localização da sua base de utilizadores esperada.
Estime 1 ms de latência de ida e volta para cada 100 km percorridos. Uma vez que as redes não seguem um caminho ideal da origem ao destino, normalmente, pode deduzir que a distância real é cerca de 1,5 a 2 vezes a distância medida num mapa. Claro que, em algumas regiões menos densamente povoadas, as redes podem seguir um caminho ainda menos ideal. Normalmente, a latência adicionada através de equipamento ativo nas redes de ISP é insignificante quando se consideram distâncias entre regiões.
Estes números podem ajudar a estimar a latência para os nós dos POPs de limite e da CDN da Google Cloud, bem como as regiões do Compute Engine em todo o mundo, conforme indicado no mapa de rede.
Meça a latência para utilizadores existentes
Se já tiver uma app com uma base de utilizadores semelhante, existem várias ferramentas que pode usar para estimar melhor as latências.
- Utilizadores representativos: se tiver utilizadores ou parceiros que representem uma amostra representativa das suas distribuições geográficas e que estejam dispostos a trabalhar consigo, ou funcionários nesses países, peça-lhes que meçam a latência para várias Google Cloud regiões. Os Websites de terceiros, como o Google Cloud ping, podem ajudar a obter algumas medições.
- Registos de acesso: se tiver uma app ativa alojada fora do Google Cloud, use dados dos registos de acesso para obter uma análise transversal aproximada dos utilizadores. Os seus registos podem fornecer informações sobre o país ou a cidade, o que também lhe permite estimar as latências.
- Endereço IP: se tiver acesso aos endereços IP dos seus utilizadores, crie scripts para testar a acessibilidade e as latências de várias regiões Google Cloud. Se a firewall bloquear as suas sondagens, experimente aleatorizar o último octeto do IP para receber uma resposta de outro dispositivo com uma latência semelhante à da sua app.
Informações de latência de Google Cloud: se tiver uma app existente no Google Cloud, existem várias formas de recolher informações de latência.
- Cabeçalhos de pedidos definidos pelo utilizador**: ative cabeçalhos para informações do país, da sub-região e da cidade dos clientes, bem como o RTT estimado entre o equilibrador de carga e o cliente.
- Métricas do Cloud Monitoring para o balanceamento de carga HTTP(S): Incluem o RTT do front-end e as latências do back-end.
- Registos de fluxo da VPC: Recebe o RTT de TCP entre ambas as extremidades de uma ligação como parte das métricas fornecidas.
Conetividade global
Ao estimar a latência, tenha em atenção a topologia da rede global da Google.
- POPs: onde o tráfego de utilizadores entra na rede.
- Nós da RFC: onde o tráfego é colocado em cache.
- Regiões: onde os seus recursos podem estar localizados.
- Conetividade: entre os POPs e as regiões.
Encontre uma lista de localizações onde a Google interliga com outros ISPs no PeeringDB.
Certifique-se de que tem em consideração a topologia inter-regional quando decidir em que regiões fazer a implementação. Por exemplo, se quiser implementar uma app com uma base de utilizadores global numa única região, é normalmente melhor alojar esta app numa das regiões dos EUA, uma vez que os EUA estão ligados à maioria das outras regiões. Embora exista conetividade direta entre muitos continentes, existem casos em que esta não existe, por exemplo, entre a Europa e a Ásia. Por isso, o tráfego entre a Europa e a Ásia flui através dos EUA.
Se a sua app estiver alojada em várias regiões e precisar de sincronizar dados, tenha em atenção a latência entre essas regiões. Embora esta latência possa mudar ao longo do tempo, normalmente é estável. Meça a latência por si mesmo ao apresentar instâncias de teste em todas as regiões potenciais ou use Websites de terceiros para ter uma ideia das latências atuais entre regiões.
Combine tudo
Agora que considerou os requisitos de latência, os potenciais modelos de implementação e a distribuição geográfica da sua base de utilizadores, compreende como estes fatores afetam a latência em determinadas regiões. É altura de decidir em que regiões quer lançar a sua app.
Embora não exista uma forma correta de ponderar os diferentes fatores, a seguinte metodologia passo a passo pode ajudar a decidir:
- Verifique se existem fatores não relacionados com a latência que impedem a implementação em regiões específicas, como o preço ou a colocação conjunta. Remova-os da sua lista de regiões.
- Escolha um modelo de implementação com base nos requisitos de latência e na arquitetura geral da app. Para a maioria das apps para dispositivos móveis e outras apps não críticas para a latência, uma implementação de região única com a entrega de conteúdo memorizável em cache e a terminação SSL na extremidade do Cloud CDN pode ser a escolha ideal.
Com base no seu modelo de implementação, escolha regiões com base na distribuição geográfica da sua base de utilizadores e nas suas medições de latência:
Para uma implementação de região única:
- Se precisar de acesso de baixa latência às instalações da sua empresa, implemente na região mais próxima desta localização.
- Se os seus utilizadores forem principalmente de um país ou uma região, implemente numa região mais próxima dos seus utilizadores representativos.
- Para uma base de utilizadores global, implemente numa região nos EUA.
Para uma implementação multirregional:
- Escolha regiões próximas dos seus utilizadores com base na respetiva distribuição geográfica e no requisito de latência da app. Consoante a sua app, otimize para uma latência mediana específica ou certifique-se de que 95 a 99% dos utilizadores recebem conteúdo com uma latência alvo específica. Os utilizadores em determinadas localizações geográficas têm frequentemente uma maior tolerância à latência devido às suas limitações de infraestrutura.
Se a latência do utilizador for semelhante em várias regiões, o preço pode ser o fator decisivo.
Quando selecionar regiões do Compute Engine, a latência é um dos fatores mais importantes a ter em conta. Avalie e meça os requisitos de latência para oferecer uma experiência do utilizador de qualidade e repita o processo se a distribuição geográfica da sua base de utilizadores mudar.
O que se segue?
- Reveja as regiões e as zonas do Compute Engine.
- Saiba como otimizar a latência da aplicação com o equilíbrio de carga.
- Leia o guia Google Cloud para profissionais de centros de dados.
- Veja a série de vídeos Atlas de desempenho na nuvem.
- Para uma vista mais completa sobre como otimizar a latência do utilizador, consulte o site High-performance browser networking.
- Explore arquiteturas de referência, diagramas e práticas recomendadas sobre o Google Cloud. Consulte o nosso Centro de arquitetura na nuvem.