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.
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çodefault
.-
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":
- Selecione uma ou mais versões em que você quer dividir o tráfego.
- 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 respostaSet-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.