Dividir tráfego

ID da região

O REGION_ID é um código abreviado que a Google atribui com base na região que seleciona quando cria a sua app. O código não corresponde a um país ou uma província, embora alguns IDs de regiões possam parecer semelhantes aos códigos de países e províncias usados frequentemente. Para apps criadas após fevereiro de 2020, REGION_ID.r está incluído nos URLs do App Engine. Para apps existentes criadas antes desta data, o ID da região é opcional no URL.

Saiba mais acerca dos IDs de regiões.

Pode usar a divisão de tráfego para especificar uma distribuição percentual do tráfego em duas ou mais versões num serviço. A divisão do tráfego permite-lhe realizar testes A/B entre as suas versões e oferece controlo sobre o ritmo de implementação de funcionalidades.

A divisão de tráfego é aplicada a URLs que não segmentam explicitamente uma versão. Por exemplo, os seguintes URLs dividem o tráfego porque segmentam todas as versões disponíveis no serviço especificado:

  • https://PROJECT_ID.REGION_ID.r.appspot.com - Distribui tráfego para versões do serviço default.
  • https://SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com - Distribui o tráfego para versões do serviço [SERVICE_ID].

Para obter informações sobre como os pedidos chegam a uma versão, consulte o artigo Como os pedidos são encaminhados.

Antes de começar

Antes de poder configurar o tráfego para uma versão, certifique-se de que a sua conta de utilizador tem os privilégios necessários.

Evitar problemas de colocação em cache

Antes de ativar a divisão de tráfego, recomendamos que tenha em conta potenciais problemas de colocação em cache. Os problemas de colocação em cache podem existir para qualquer app do App Engine, especialmente quando implementa uma nova versão. A divisão do tráfego torna frequentemente mais evidentes os problemas de colocação em cache subtis.

Por exemplo, suponha que está a dividir o tráfego entre duas versões, A e B, e que um recurso memorizável em cache externo foi alterado entre as versões, por exemplo, um ficheiro CSS. Agora, suponha que um cliente faz um pedido e a resposta contém uma referência externa ao ficheiro em cache. A cache HTTP local vai obter o ficheiro se estiver na cache, independentemente da versão do ficheiro que está em cache e da versão da aplicação que enviou a resposta. O recurso em cache pode ser incompatível com os dados que foram enviados na resposta.

Para evitar problemas de cache:

  • Para recursos dinâmicos, defina os cabeçalhos Cache-Control e Expires. Estes cabeçalhos indicam aos proxies que o recurso é dinâmico. É melhor definir ambos os cabeçalhos, uma vez que nem todos os servidores proxy suportam corretamente o cabeçalho Cache-Control HTTP/1.1.

    Se quiser mais informações sobre o armazenamento em cache em geral, consulte os campos de cabeçalho na RFC HTTP/1.1 e a vista geral do armazenamento em cache HTTP nos fundamentos da Web.

  • Para recursos estáticos memorizáveis em cache que variam entre versões, altere o URL do recurso entre versões. Se os recursos estáticos forem publicados a partir de URLs diferentes, ambas as versões podem coexistir sem problemas nos servidores proxy e nas caches do navegador.

Também pode fazer com que a sua app defina o cabeçalho Vary: Cookie para que a exclusividade de um recurso seja calculada combinando os cookies e o URL do pedido. No entanto, esta abordagem aumenta a carga nos servidores de cache. Existem 1000 valores possíveis de GOOGAPPUID e, por conseguinte, 1000 entradas possíveis para cada URL da sua app. Consoante a carga nos proxies entre os seus utilizadores e a sua app, isto pode diminuir a frequência com que a sua app publica um resultado em cache. Além disso, durante as 24 horas após adicionar um novo lote de utilizadores a uma versão, esses utilizadores podem continuar a ver recursos em cache. No entanto, a utilização de Vary: Cookie pode facilitar a mudança do nome dos recursos estáticos que estão a mudar entre versões.

A técnica Vary: Cookie não funciona em todas as circunstâncias. Em geral, se a sua app estiver a usar cookies para outros fins, tem de considerar como isto afeta a carga nos servidores proxy. Se codeninja tivesse o seu próprio cookie com 100 valores possíveis, o espaço de todas as entradas de cache possíveis torna-se um número muito grande (100 * 1000 = 100 000). No pior caso, existe um cookie único para cada utilizador. Dois exemplos comuns disto são o Google Analytics (__utma) e o SiteCatalyst (s_vi). Nestes casos, cada utilizador recebe uma cópia única, o que degrada gravemente o desempenho da cache e também pode aumentar as horas de instância faturáveis consumidas pela sua app.

Dividir o tráfego em várias versões

Quando especifica duas ou mais versões para a divisão, tem de escolher se quer dividir o tráfego através de um endereço IP do remetente ou de um cookie HTTP. É mais fácil configurar uma divisão de endereços IP, mas uma divisão de cookies é mais precisa. Para mais informações, consulte os artigos Divisão de endereços IP e Divisão de cookies.

Consola

Para dividir o tráfego na Google Cloud consola, aceda à página Versões:

Aceda a Versões

  1. Selecione uma ou mais versões para as quais quer dividir o tráfego.
  2. Clique em Dividir tráfego e, de seguida, especifique:
    • O método que quer usar para dividir o tráfego.
    • A percentagem de tráfego que cada versão deve receber.

gcloud

Depois de instalar a CLI Google Cloud, execute o seguinte comando para dividir o tráfego em várias versões, por exemplo:

gcloud app services set-traffic [MY_SERVICE] --splits [MY_VERSION1]=[VERSION1_WEIGHT],[MY_VERSION2]=[VERSION2_WEIGHT] --split-by [IP_OR_COOKIE]

Para ver detalhes e opções adicionais, consulte a referência gcloud app services set-traffic.

API

Para migrar o tráfego de forma programática, pode usar a API Admin. Consulte o artigo Migrar e dividir o tráfego para ver detalhes.

Divisão de endereços IP

Se optar por dividir o tráfego para a sua aplicação por endereço IP do remetente, quando a aplicação recebe um pedido, aplica hash ao endereço IP para um valor entre 0 e 999 e usa esse número para encaminhar o pedido.

A divisão de endereços IP tem algumas limitações significativas:

  • Os endereços IP do remetente são razoavelmente persistentes, mas não são permanentes. Os utilizadores que se ligam a partir de telemóveis podem ter um endereço IP variável ao longo de uma única sessão. Da mesma forma, um utilizador num portátil pode estar a deslocar-se de casa para um café para trabalhar e também a mudar de endereços IP. Como resultado, o utilizador pode ter uma experiência inconsistente com a sua app à medida que o respetivo endereço IP muda.
  • Uma vez que os endereços IP são atribuídos independentemente às versões, a divisão do tráfego resultante difere ligeiramente da especificada. No entanto, à medida que a sua aplicação recebe mais tráfego, a divisão real aproxima-se mais do seu alvo. Por exemplo, se pedir que 5% do tráfego seja fornecido a uma versão alternativa, a percentagem inicial de tráfego para a versão pode, na verdade, estar entre 3 e 7%, mas, eventualmente, a média aproxima-se mais dos 5% pretendidos.
  • Se precisar de enviar pedidos internos entre apps, deve usar a divisão de cookies. Os pedidos enviados entre apps executadas na infraestrutura de nuvem da Google têm origem num pequeno número de endereços IP que provavelmente estão todos atribuídos à mesma versão. Por conseguinte, todos os pedidos internos podem comportar-se de forma semelhante aos pedidos enviados a partir de um único endereço IP, o que significa que todos esses pedidos são encaminhados para a mesma versão. Como resultado, os pedidos internos não respeitam rigorosamente as percentagens que define para as divisões de tráfego baseadas em IP. Por exemplo, se definir uma versão para receber 1% de todo o tráfego para a sua app e os endereços da infraestrutura na nuvem da Google forem coincidentemente atribuídos a essa versão, o resultado real pode exceder em muito 1%, porque todos os pedidos internos são sempre encaminhados para a versão atribuída. Os pedidos enviados para a sua app a partir de fora da infraestrutura de nuvem da Google funcionam como esperado, uma vez que têm origem numa distribuição variada de endereços IP.

Se optar por dividir o tráfego para a sua aplicação por cookies, a aplicação procura no cabeçalho do pedido HTTP um cookie denominado GOOGAPPUID, que contém um valor entre 0 e 999:

  • Se o cookie existir, o valor é usado para encaminhar o pedido.
  • Se não existir nenhum cookie desse tipo, o App Engine gera um cookie com um valor aleatório oculto para encaminhar o pedido.

Se a resposta não contiver o cookie GOOGAPPUID, a app adiciona primeiro o cookie GOOGAPPUID com um valor aleatório oculto entre 0 e 999 antes de ser enviado.

A utilização de cookies para dividir o tráfego facilita a atribuição precisa de utilizadores a versões.

Por exemplo, se tiver 3 versões:

  • Versão A com 10% do tráfego
  • Versão B com 60% do tráfego
  • Versão C com 30% do tráfego

O App Engine cria 1000 fragmentos e é atribuído a cada versão um número de fragmentos correspondente à respetiva percentagem de divisão do tráfego. A partir deste exemplo, a versão A tem 100 fragmentos, a versão B tem 600 fragmentos e a versão C tem 300 fragmentos.

O App Engine usa o valor do cookie GOOGAPPUID para determinar a que fragmento um pedido é atribuído e encaminha o pedido para a versão correspondente. A precisão do encaminhamento de tráfego pode atingir quase 0,1% da divisão alvo. A divisão de cookies tem as seguintes limitações:

  • Se estiver a escrever uma app para dispositivos móveis ou a executar um cliente de computador, este tem de gerir os cookies GOOGAPPUID. Por exemplo, quando é usado um cabeçalho de resposta Set-Cookie, tem de armazenar o cookie e incluí-lo em cada pedido subsequente. As apps baseadas no navegador já gerem os cookies desta forma automaticamente.

  • A divisão de pedidos internos requer trabalho adicional. Todos os pedidos de utilizadores enviados a partir da infraestrutura de nuvem da Google requerem que encaminhe o cookie do utilizador com cada pedido. Por exemplo, tem de encaminhar o cookie do utilizador em pedidos enviados da sua app para outra app ou para si própria. Tenha em atenção que não é recomendado enviar pedidos internos se esses pedidos não tiverem origem num utilizador.

  • Não existe uma forma de determinar que versão processa um valor específico no cookie GOOGAPPUID. No entanto, a mesma versão processa pedidos com o mesmo valor no cookie GOOGAPPUID.

Desativar a divisão de tráfego

Para desativar a divisão de tráfego, migre todo o tráfego para uma única versão.