Divide el tráfico

ID de región

REGION_ID es un código abreviado que Google asigna en función de la región que eliges cuando creas la app. El código no corresponde a un país ni a una provincia, aunque algunos ID de región puedan parecer similares a los códigos de país y provincia que se suelen usar. En el caso de las apps creadas después de febrero de 2020, REGION_ID.r se incluye en las URL de App Engine. En el caso de las apps existentes creadas antes de esta fecha, el ID de región es opcional en la URL.

Obtén más información acerca de los ID de región.

Puedes usar la división del tráfico para especificar una distribución porcentual del tráfico entre dos o más de las versiones dentro de un servicio. La división del tráfico te permite realizar pruebas A/B entre las versiones y controlar el ritmo cuando lanzas funciones.

La división del tráfico se aplica a las URL que no se orientan especialmente a una versión. Por ejemplo, las siguientes URL dividen el tráfico porque se orientan a todas las versiones disponibles dentro del servicio especificado:

  • https://PROJECT_ID.REGION_ID.r.appspot.com: Distribuye tráfico a versiones del servicio default.
  • https://SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com: Distribuye tráfico a versiones del servicio [SERVICE_ID].

Para obtener más información sobre cómo las solicitudes llegan a una versión, consulta Cómo se enrutan las solicitudes.

Antes de comenzar

Antes de poder configurar el tráfico a una versión, asegúrate de que tu cuenta de usuario incluya los privilegios obligatorios.

Evita problemas de almacenamiento en caché

Antes de activar la división del tráfico, te recomendamos tener en cuenta los posibles problemas de almacenamiento en caché. Puede haber problemas de almacenamiento en caché en cualquier app de App Engine, en especial cuando se implementa una versión nueva. A menudo, con la división del tráfico, los problemas sutiles de almacenamiento en caché son más evidentes.

Por ejemplo, supongamos que estás dividiendo el tráfico entre dos versiones, A y B, y algún recurso externo que puede almacenarse en caché cambió de una versión a otra, por ejemplo, un archivo CSS. Ahora supongamos que un cliente hace una solicitud y la respuesta contiene una referencia externa al archivo almacenado en caché. La memoria caché HTTP local recuperará el archivo si está almacenado en la caché, independientemente de la versión del archivo que esté almacenada en caché y la versión de la aplicación que envió la respuesta. El recurso almacenado en caché podría ser incompatible con los datos que se enviaron en la respuesta.

Para evitar problemas de almacenamiento en caché, realiza lo siguiente:

  • Para los recursos dinámicos, configura los encabezados Cache-Control y Expires. Estos encabezados les indican a los proxies que el recurso es dinámico. Se recomienda configurar ambos encabezados, ya que no todos los servidores proxy admiten el encabezado HTTP/1.1 Cache-Control de forma adecuada.

    Si deseas obtener información adicional sobre el almacenamiento en caché en general, consulta Campos de encabezado en el RFC HTTP/1.1 y la Descripción general del almacenamiento en caché HTTP en Fundamentos de la Web.

  • Para los recursos estáticos que pueden almacenarse en caché y que varían de una versión a otra, cambia la URL del recurso según la versión. Si los recursos estáticos se entregan desde URL diferentes, ambas versiones pueden coexistir sin problema en servidores proxy y memorias caché de navegador.

También puedes hacer que la app configure el encabezado Vary: Cookie para que la singularidad de un recurso se calcule a través de la combinación de las cookies y la URL de la solicitud. Sin embargo, este enfoque aumenta la carga de los servidores en caché. Hay 1,000 valores posibles de GOOGAPPUID y, por lo tanto, 1,000 entradas posibles para cada URL en tu app. Según la carga en los proxies entre los usuarios y la app, esto puede disminuir la frecuencia con la que tu app entrega un resultado almacenado en caché. Además, durante las 24 horas posteriores a la incorporación de un lote nuevo de usuarios a una versión, esos usuarios aún podrían ver recursos almacenados en caché. Sin embargo, usar Vary: Cookie puede facilitar el cambio de nombre de los recursos estáticos que cambian entre versiones.

La técnica Vary: Cookie no funciona en todas las circunstancias. En general, si la aplicación usa cookies para otros fines, debes considerar cómo esto afecta la carga de los servidores proxy. Si codeninja tenía su propia cookie con 100 valores posibles, el espacio de todas las entradas de caché posibles se convierte en un número muy grande (100 * 1,000 = 100,000). En el peor de los casos, existe una cookie única para cada usuario. Dos ejemplos comunes de esto son Google Analytics (__utma) y SiteCatalyst (s_vi). En estos casos, cada usuario obtiene una copia única que degrada en gran medida el rendimiento de la caché y también puede aumentar las horas de instancia facturables que consume la app.

Divide el tráfico entre varias versiones

Cuando hayas especificado dos o más versiones para la división, debes elegir si quieres dividir el tráfico con una dirección IP del remitente o una cookie HTTP. Es más fácil configurar una división con direcciones IP, pero una división con cookies es más precisa. Para obtener más información, consulta División por dirección IP y División por cookies.

Console

Para dividir el tráfico en la consola de Google Cloud, ve a la página Versiones:

Ir a la página Versiones

  1. Selecciona una o más versiones en las que desees dividir el tráfico.
  2. Haz clic en Dividir tráfico y, luego, especifica:
    • El método que deseas usar para dividir el tráfico
    • El porcentaje de tráfico que debe recibir cada versión.

gcloud

Después de instalar Google Cloud CLI, ejecuta el siguiente comando para dividir el tráfico entre varias versiones, por ejemplo:

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

Para obtener detalles y opciones adicionales, consulta la referencia de gcloud app services set-traffic .

API

Para migrar el tráfico de manera programática, puedes usar la API de Administrador. Consulta Migrar y dividir el tráfico si quieres ver información detallada.

Divide el tráfico por dirección IP

Si eliges dividir el tráfico hacia tu aplicación por dirección IP del remitente, cuando la aplicación reciba una solicitud, generará un hash de la dirección IP con un valor de entre 0 y 999, y usará ese número para enrutar la solicitud.

Dividir el tráfico por dirección IP tiene algunas limitaciones importantes:

  • Las direcciones IP del remitente son bastante fijas, pero no son permanentes. Los usuarios que se conectan desde teléfonos celulares pueden tener una dirección IP cambiante en una sola sesión. Del mismo modo, un usuario con una laptop puede ir a trabajar de su casa a un café y también cambiará entre distintas direcciones IP. En consecuencia, el usuario puede tener una experiencia incoherente con la aplicación cuando cambie la dirección IP.
  • Debido a que las direcciones IP se asignan a las versiones de manera independiente, la división del tráfico que se obtiene como resultado será algo diferente de lo que especificas. Sin embargo, a medida que la aplicación recibe más tráfico, más se acerca la división real al objetivo. Por ejemplo, si solicitas el envío del 5% del tráfico a una versión alternativa, el porcentaje inicial de tráfico hacia la versión podría estar entre el 3% y el 7%, pero en última instancia, el promedio se aproxima más al 5% objetivo.
  • Si necesitas enviar solicitudes internas entre aplicaciones, debes usar la división con cookies. Las solicitudes que se envían entre aplicaciones que se ejecutan en la infraestructura de nube de Google se originan en una pequeña cantidad de direcciones IP que, probablemente, estén asignadas a la misma versión. Por lo tanto, todas las solicitudes internas pueden comportarse de manera similar ante las solicitudes enviadas desde una única dirección IP, lo que significa que todas esas solicitudes se enrutan hacia la misma versión. En consecuencia, las solicitudes internas no coinciden con los porcentajes establecidos para las divisiones de tráfico basadas en IP. Por ejemplo, si configuras una versión para que reciba el 1% de todo el tráfico hacia tu aplicación y, casualmente, las direcciones de la infraestructura de nube de Google se asignaron a esa versión, el resultado real podría superar el 1%, porque todas las solicitudes internas siempre se enrutan a la versión asignada. Las solicitudes enviadas a la aplicación desde fuera de la infraestructura de nube de Google funcionarán según lo previsto, ya que surgen de una distribución variada de direcciones IP.

Si optas por dividir el tráfico mediante cookies, la aplicación busca en el encabezado de la solicitud HTTP una cookie llamada GOOGAPPUID, que contiene un valor entre 0 y 999:

  • Si la cookie existe, el valor se usa para enrutar la solicitud.
  • Si la cookie no existe, la solicitud se enruta de forma aleatoria.

Si la respuesta no contiene la cookie GOOGAPPUID, la aplicación agrega la cookie GOOGAPPUID con un valor aleatorio entre 0 y 999 antes de enviarla.

El uso de cookies para dividir el tráfico facilita la asignación precisa de usuarios a versiones. La precisión del enrutamiento del tráfico puede acercarse al 0.1% de la división objetivo. No obstante, la división por cookies tiene las siguientes limitaciones:

  • Si escribes una app para dispositivos móviles o ejecutas un cliente de escritorio, es necesario administrar las cookies GOOGAPPUID. Por ejemplo, cuando se usa un encabezado de respuesta Set-CookieSet-Cookie, debes almacenar la cookie y, también, incluirla junto con cada solicitud posterior. Las aplicaciones basadas en el navegador ya administran las cookies de esta manera automáticamente.

  • La división de solicitudes internas requiere trabajo adicional. Todas las solicitudes de los usuarios que se envían desde la infraestructura de la nube de Google requieren que reenvíes la cookie del usuario con cada solicitud. Por ejemplo, debes reenviar la cookie del usuario en solicitudes enviadas desde tu app a otra o a sí mismo. Ten en cuenta que no se recomienda enviar solicitudes internas si estas no provienen de un usuario.

Inhabilita la división del tráfico

Para inhabilitar la división del tráfico, migra todo el tráfico a una sola versión.