Divide el tráfico

Puedes usar la división del tráfico para especificar una distribución porcentual del tráfico en 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 implementas características.

La división del tráfico se aplica a las URL que no se orientan específicamente 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:

  • [MY_PROJECT].appspot.com: distribuye el tráfico a las versiones del servicio default.
  • [MY_SERVICE].[MY_PROJECT].appspot.com: distribuye el tráfico a las versiones del servicio [MY_SERVICE].

Para obtener más información sobre cómo alcanzar una versión con solicitudes, 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é con cualquier aplicación de App Engine, especialmente, 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 de Control de caché y de Vencimiento. 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 correctamente.

    Si quieres información adicional sobre el almacenamiento en caché en general, consulta Campos de encabezado en el HTTP/1.1 RFC y Documentos almacenados en caché en el Manual de seguridad del navegador.

  • 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 tu aplicación configure el encabezado de Variar: cookie para que la singularidad de un recurso se calcule mediante la combinación de las cookies y la URL de la solicitud. Sin embargo, este enfoque aumenta la carga de los servidores de caché. Hay 1,000 valores posibles de GOOGAPPUID y, por lo tanto, 1,000 entradas posibles para cada URL en tu aplicación. Según la carga en los servidores proxy entre los usuarios y la aplicación, esto puede disminuir la tasa de aciertos de caché. Además, ten en cuenta que, durante las 24 horas posteriores a la incorporación de un lote nuevo de usuarios a una versión, es posible que sigan viendo recursos 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 utiliza 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 consumidas por la aplicación.

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 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 con direcciones IP y División con cookies.

Console

Para dividir el tráfico en GCP Console, ve a la página de Versiones:

Ir a la página de 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 utilizar para dividir el tráfico.
    • El porcentaje de tráfico que debe recibir cada versión.

gcloud

Después de instalar el SDK de Google Cloud, ejecuta el siguiente comando para dividir el tráfico en 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, 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 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 a tu aplicación mediante cookies, esta busca en el encabezado de solicitud HTTP una cookie con el nombre GOOGAPPUID, que contenga 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, en primer lugar, 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 de cookies tiene las siguientes limitaciones:

  • Si desarrollas una aplicación para dispositivos móviles o si ejecutas un cliente de computadora de escritorio, es necesario administrar las cookies GOOGAPPUID. Por ejemplo, cuando se usa un encabezado de respuesta de Set-Cookie, debes almacenar la cookie y también incluirla 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. En todas las solicitudes de usuario que se envían desde la infraestructura de nube de Google, se debe reenviar la cookie del usuario con cada solicitud. Por ejemplo, debes reenviar la cookie del usuario en las solicitudes enviadas de la aplicación a otra aplicación o a sí misma. 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 hacia una sola versión.

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...

Entorno flexible de App Engine para documentos de Java