Como dividir o tráfego

ID da região

O REGION_ID é um código abreviado que o Google atribui com base na região que você selecionou ao criar o aplicativo. O código não corresponde a um país ou estado, ainda que alguns IDs de região sejam semelhantes aos códigos de país e estado geralmente usados. Para apps criados após fevereiro de 2020, o REGION_ID.r está incluído nos URLs do App Engine. Para apps existentes criados antes dessa data, o ID da região é opcional no URL.

Saiba mais sobre IDs de região.

OK

Divida o tráfego para distribuir um percentual dele entre duas ou mais versões de um serviço. Assim, você realiza testes A/B entre as versões e tem controle sobre o ritmo do lançamento de recursos.

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

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

Para informações sobre como as solicitações alcançam uma versão, consulte Como as solicitações são encaminhadas.

Antes de começar

Antes de configurar o tráfego para uma versão, verifique se a conta de usuário inclui os privilégios obrigatórios.

Como evitar problemas de armazenamento em cache

Antes de ativar a divisão de tráfego, você precisa se preparar para possíveis problemas de cache. Eles ocorrem em qualquer aplicativo do App Engine, principalmente na implantação de uma nova versão. Muitas vezes, a divisão de tráfego deixa pequenos problemas de cache mais evidentes.

Por exemplo, suponha que você divida o tráfego entre duas versões, A e B, e algum recurso externo armazenável em cache tenha sido alterado entre elas. Por exemplo, um arquivo CSS. Agora, suponha que um cliente faça uma solicitação, e a resposta contenha uma referência externa ao arquivo em cache. O cache HTTP local recupera o arquivo se ele estiver no cache, seja qual for a versão do arquivo armazenada e a versão do aplicativo 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:

• Nos recursos dinâmicos, defina os cabeçalhos Cache-Control e Expires. Eles informam aos proxies que o recurso é dinâmico. É melhor configurar ambos os cabeçalhos, já que nem todos os servidores proxy aceita corretamente o cabeçalho Cache-Control HTTP/1.1.

  Para mais informações sobre o armazenamento em cache, consulte os documentos sobre campos de cabeçalhos na RFC do HTTP/1.1 e visão geral do armazenamento em cache HTTP nos Fundamentos da Web (links em inglês).

• Nos recursos estáticos armazenáveis em cache que variam entre as versões, altere o URL do recurso entre elas. Se os recursos estáticos são disponibilizados usando diferentes URLs, ambas as versões podem coexistir em servidores proxy e caches de navegador.

Também é possível definir o cabeçalho Vary: Cookie no aplicativo para que a singularidade de um recurso seja computada ao combinar os cookies e o URL da solicitação. No entanto, essa abordagem aumenta a carga sobre os servidores de cache. Há 1.000 valores possíveis para GOOGAPPUID e, portanto, 1.000 entradas possíveis para cada URL do app. Dependendo da carga nos proxies entre os usuários e o app, isso pode diminuir a frequência de exibição de um resultado armazenado em cache. Além disso, nas primeiras 24 horas após adicionar um novo lote de usuários a uma versão, eles ainda poderão ver recursos em cache. No entanto, usar Vary: Cookie ajuda a renomear recursos estáticos que mudam entre as versões.

A técnica do Vary: Cookie não funciona em todas as circunstâncias. Em geral, se o app usa cookies para outras finalidades, você precisa pensar em como isso afeta a carga nos servidores proxy. Se codeninja tiver o próprio cookie com 100 valores possíveis, o espaço de todas as entradas de cache possíveis será um número muito grande (100 * 1.000 = 100.000). No pior dos casos, há um único cookie para todos os usuários. Dois exemplos comuns disso são o Google Analytics (__utma) e o SiteCatalyst (s_vi). Nesses casos, cada usuário recebe uma cópia exclusiva, o que afeta negativamente o desempenho do cache e também pode aumentar as horas de instância faturáveis consumidas pelo app.

Como dividir o tráfego em várias versões

Depois de especificar duas ou mais versões para a divisão, você precisa escolher se usará um endereço IP do remetente ou um cookie HTTP no processo. É mais fácil configurar uma divisão com endereços IP, mas o método com cookies é mais preciso. Para saber mais informações, veja Como dividir por endereços IP e Como dividir por cookies.

Console

Para dividir o tráfego no console do Google Cloud, acesse a página "Versões":

Acessar a página "Versões"

1. Selecione uma ou mais versões em que você quer dividir o tráfego.
2. Clique em Dividir tráfego e especifique os seguintes elementos:
   • O método que você quer usar para dividir o tráfego.
   • O percentual de tráfego que cada versão receberá.

gcloud

Depois de instalar a Google Cloud CLI, 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 mais detalhes e opções, consulte a referência de gcloud app services set-traffic.

API

Para migrar o tráfego de maneira programática, use a API Admin. Para saber mais, consulte Como migrar e dividir o tráfego.

Como dividir por endereços IP

Ao escolher esse método, o aplicativo gera o hash do endereço IP do remetente com um valor entre 0 e 999 quando recebe uma solicitação. Depois, ele usa esse número para encaminhá-la.

A divisão por endereço IP tem algumas limitações importantes:

• Os endereços IP do remetente são razoavelmente fixos, mas não são permanentes. O endereço IP dos usuários que se conectam usando celulares pode mudar ao longo de uma única sessão. Isso também acontece com um usuário que leva seu laptop a diferentes lugares para trabalhar. Como resultado, os usuários podem ter uma experiência inconsistente no app, já que o endereço IP muda.
• Como os endereços IP são atribuídos às versões de maneira independente, a divisão de tráfego resultante é um pouco diferente do que você especifica. No entanto, a divisão fica mais similar ao seu objetivo conforme o aplicativo recebe mais tráfego. Por exemplo, se você solicitar que 5% do tráfego seja enviado a uma versão alternativa, a porcentagem inicial estará entre 3% e 7%. Com o tempo, ela ficará mais próxima dos 5% pretendidos.
• Se for preciso enviar solicitações internas entre os aplicativos, use a divisão por cookies. As solicitações enviadas entre aplicativos em execução na infraestrutura em nuvem do Google vêm de um pequeno número de endereços IP. É provável que todos os endereços sejam atribuídos à mesma versão. Portanto, todas as solicitações internas podem funcionar da mesma maneira que aquelas enviadas de um único endereço IP. Isso significa que todas essas solicitações são encaminhadas para a mesma versão. Como resultado, as solicitações internas não respeitam exatamente os percentuais definidos para as divisões de tráfego baseadas em IP. Por exemplo, se você definir que uma versão receba 1% de todo o tráfego do seu app e os endereços de infraestrutura em nuvem do Google tiverem sido atribuídos a ela, o resultado real poderá exceder muito o 1%. Isso acontece porque todas as solicitações internas são sempre encaminhadas para a versão atribuída. As solicitações enviadas ao app de fora da infraestrutura em nuvem do Google funcionam conforme o esperado, já que elas vêm de uma distribuição variada de endereços IP.

Como dividir por cookies

Se o tráfego do aplicativo for dividido por cookies, o aplicativo procurará no cabeçalho de solicitação HTTP um cookie denominado GOOGAPPUID, que contém um valor entre 0 e 999:

• Se o cookie existir, o valor será usado para rotear a solicitação.
• Caso contrário, a solicitação será roteada aleatoriamente.

Se a resposta não tiver o cookie GOOGAPPUID, o app primeiro adicionará um valor aleatório entre 0 e 999 a GOOGAPPUID antes do envio.

Usar cookies para dividir o tráfego facilita a atribuição correta de usuários às versões. A precisão do roteamento de tráfego pode chegar a 0,1% da divisão pretendida. No entanto, a divisão por cookies tem as limitações a seguir:

• Ao escrever um app para dispositivos móveis ou executar um cliente de área de trabalho, é preciso gerenciar os cookies GOOGAPPUID. Por exemplo, quando um cabeçalho de resposta Set-Cookie é usado, é preciso armazenar o cookie e incluí-lo em cada solicitação posterior. Os apps baseados em navegadores já gerenciam os cookies dessa maneira automaticamente.

• Dividir as solicitações internas requer trabalho extra. Todas as solicitações de usuários enviadas pela infraestrutura em nuvem do Google exigem que você encaminhe o cookie com cada uma delas. Por exemplo, é preciso encaminhar o cookie do usuário nas solicitações enviadas do seu app para outro aplicativo ou para ele mesmo. Não é recomendado enviar solicitações internas quando elas não são feitas por um usuário.

Como desativar a divisão do tráfego

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