Divide el tráfico

Puedes utilizar la división del tráfico para especificar un porcentaje de distribución de tráfico entre dos o más versiones de un mismo servicio. La división del tráfico te permite realizar pruebas A/B entre tus versiones y controlar el ritmo cuando se implementan funciones.

La división del tráfico se aplica a las URL que no se orienten de manera explícita a una versión. Por ejemplo, las URL que aparecen a continuación, 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 información sobre cómo llegan las solicitudes a una versión, consulta Cómo se enrutan las solicitudes.

Antes de comenzar

Antes de configurar el tráfico hacia una versión, asegúrate de que tu Cuenta de usuario incluya los privilegios necesarios.

Evita problemas de almacenamiento en caché

Antes de activar la división del tráfico, te recomendamos tener en cuenta los problemas posibles de almacenamiento en caché. Puede haber problemas de almacenamiento en caché para cualquier aplicación de App Engine, en especial cuando se implementa una versión nueva. La división del tráfico suele hacer que los problemas sutiles de almacenamiento en caché sean más evidentes.

Por ejemplo, supongamos que tienes que dividir el tráfico entre dos versiones, A y B, y que algún recurso externo almacenable en caché cambió entre las versiones, por ejemplo, un archivo CSS. Luego un cliente realiza una solicitud y la respuesta contiene una referencia externa al archivo almacenado en caché. La memoria caché HTTP local recuperará el archivo si se encuentra allí, sin importar qué versión del archivo está almacenada en caché y qué versión de la aplicación envió la respuesta. El recurso almacenado en caché podría no ser compatible con los datos enviados en la respuesta.

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

  • Para recursos dinámicos, configura los encabezados Cache-Control y Expires. Estos encabezados informan a los proxies que el recurso es dinámico. Es mejor establecer ambos encabezados, ya que no todos los servidores proxy admiten el encabezado de HTTP/1.1 Cache-Control de forma correcta.

    Si deseas información adicional sobre el almacenamiento en caché en general, consulta Campos de encabezado en el HTTP/1.1 RFC y Almacenamiento de documentos en caché en el manual de seguridad del navegador.

  • Para los recursos estáticos almacenables en caché que varían entre versiones, cambia la URL del recurso entre cada versión. Si los recursos estáticos se entregan desde URL diferentes, ambas versiones pueden coexistir sin inconvenientes en servidores proxy y cachés de navegador.

También puedes hacer que tu app configure el encabezado Vary: 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 para GOOGAPPUID y, por lo tanto, 1,000 entradas posibles en cada URL de la app. Según la carga de los proxies entre los usuarios y tu app, esto puede disminuir la tasa de aciertos de caché. Además, ten en cuenta que durante 24 horas después de agregar un lote nuevo de usuarios a una versión, es posible que sigan viendo recursos en caché. Sin embargo, el uso de Vary: Cookie puede simplificar 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 tu app utiliza cookies para otros fines, debes considerar cómo esto afecta la carga de los servidores proxy. Si codeninja tuviera su cookie propia con 100 valores posibles, el espacio de todas las entradas de caché posibles se convertiría en un número muy grande (100 * 1,000 = 100,000). En el peor de los casos, habrá una cookie única para cada usuario. Dos ejemplos comunes son Google Analytics (__utma) y SiteCatalyst (s_vi). En estos casos, cada usuario obtiene una copia única, lo que degrada de manera severa el rendimiento de la memoria caché y también puede aumentar las horas de instancias facturables que la app consume.

Divide el tráfico entre varias versiones

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

Console

Para dividir el tráfico en GCP Console, 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 el tráfico y, luego, especifica la siguiente información:
    • 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 el SDK de Google Cloud, ejecuta el comando a continuación 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 más información y opciones adicionales, consulta la referencia gcloud app services set-traffic.

API

Si deseas migrar el tráfico de manera programática, puedes usar la API de Administrador. Consulta Migra y divide el tráfico para obtener más información.

Divide el tráfico por dirección IP

Si decides dividir el tráfico en tu aplicación por dirección IP, ten en cuenta que cuando la aplicación recibe una solicitud, genera un hash de la dirección IP con un valor entre 0 y 999 y utiliza ese número para enrutar la solicitud.

La división del tráfico por dirección IP tiene algunas limitaciones importantes:

  • Por lo general, las direcciones IP son fijas, pero no permanentes. La dirección IP de los usuarios que se conectan desde teléfonos celulares puede cambiar en una sola sesión. Del mismo modo, las direcciones IP también cambiarán si un usuario se traslada con una laptop de su casa a una cafetería para trabajar. En consecuencia, el usuario puede tener una experiencia irregular con tu app a medida que su dirección IP cambie.
  • Dado que las direcciones IP se asignan a las versiones de manera independiente, la división del tráfico resultante será un poco diferente de lo que especifiques. Sin embargo, la división real se acercará más a tu objetivo a medida que tu aplicación reciba más tráfico. Por ejemplo, si solicitas que se entregue el 5% del tráfico a una versión alternativa, el porcentaje inicial del tráfico que se envía a la versión podría ser de entre un 3% y un 7%, pero se acercará cada vez más al objetivo del 5%.
  • Si necesitas enviar solicitudes internas entre apps, debes usar la división por cookies. Las solicitudes que se envían entre aplicaciones y que se ejecutan en la infraestructura de nube de Google se originan desde un número reducido de direcciones IP, las cuales probablemente se asignen a la misma versión. Por lo tanto, todas las solicitudes internas pueden comportarse de manera similar a las solicitudes enviadas desde una dirección IP única, lo que significa que todas esas solicitudes se dirigen hacia la misma versión. Como resultado, las solicitudes internas no respetan estrictamente los porcentajes que estableces 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 app y las direcciones de la infraestructura de nube de Google se asignaron por coincidencia a esa versión, el resultado real podría superar por mucho el 1% porque todas las solicitudes internas siempre se enrutan hacia la versión asignada. Las solicitudes enviadas a tu app desde fuera de la infraestructura de nube de Google funcionarán según lo esperado, ya que se originan a partir de una distribución variada de direcciones IP.

Si decides dividir el tráfico de tu aplicación por cookies, la aplicación buscará en el encabezado de solicitud HTTP una cookie denominada GOOGAPPUID, que contiene un valor de entre 0 y 999:

  • Si la cookie existe, se utiliza el valor 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 app agregará la cookie GOOGAPPUID con un valor aleatorio de entre 0 y 999 antes de enviarla.

El uso de cookies para dividir el tráfico facilita la asignación precisa de usuarios a las versiones. La precisión del enrutamiento del tráfico puede llegar a tener tan solo una diferencia del 0.1% con respecto a la división deseada. Sin embargo, la división por cookies tiene las limitaciones a continuación:

  • Si desarrollas una app para dispositivos móviles o ejecutas un cliente de computadora de escritorio, la aplicación debe administrar las cookies GOOGAPPUID. Por ejemplo, cuando se usa un encabezado de respuesta Set-Cookie, debes almacenar la cookie y, luego, incluirla con cada solicitud posterior. En las apps basadas en el navegador, las cookies se administran de esta manera automática.

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

Inhabilita la división del tráfico

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

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

Enviar comentarios sobre...

Documentación del entorno estándar de App Engine para Node.js