Dividir el tráfico

Puedes usar la división de 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 implementas características.

La división del tráfico se aplica a URL que no están orientadas específicamente a ninguna 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 más información sobre cómo las solicitudes alcanzan 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.

Evitar problemas de almacenamiento en caché

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

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. Ahora, supongamos que 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 está almacenado en la caché, independientemente de la versión del archivo que esté almacenada y la versión de la aplicación que haya enviado 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 recursos dinámicos, configura los encabezados de Control de caché y Vencimiento. Estos encabezados informan a los proxies que el recurso es dinámico. Es mejor configurar ambos encabezados, pues no todos los servidores proxy admiten el encabezado HTTP/1.1 Cache-Control correctamente.

    Para obtener más información sobre el almacenamiento en caché en general, consulta la sección sobre campos de encabezado en la RFC de HTTP/1.1 y la sección sobre almacenamiento de documentos en caché en el Manual de seguridad del navegador.

  • Para recursos estáticos almacenables en caché que varían entre versiones, cambia la URL del recurso entre versiones. 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 aplicación configure el encabezado Vary: Cookie para que la singularidad de un recurso se calcule combinando las cookies con 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 para cada URL de 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 después de agregar un lote nuevo de usuarios a una versión, es probable que sigan viendo recursos en caché durante las 24 horas siguientes. Sin embargo, el uso de 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 tiene su propia cookie de 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 son Google Analytics (__utma) y SiteCatalyst (s_vi). En estos casos, cada usuario obtiene una copia única, lo que degrada severamente el rendimiento de la memoria caché y también puede aumentar las horas de instancia facturables consumidas por la aplicación.

Cómo dividir 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 la 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 por direcciones IP y División por 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 hacia las que deseas 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 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 detalles y opciones adicionales, consulta la referencia gcloud app services set-traffic.

API

Si necesitas migrar el tráfico de manera programática, puedes usar la API de Administrador. Para obtener más detalles, visita Migrar y dividir el tráfico.

Dividir el tráfico por dirección IP

Si decides dividir el tráfico en la aplicación por dirección IP, 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 por dirección IP tiene algunas limitaciones importantes:

  • Las direcciones IP son razonablemente fijas, pero no son 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, también cambiará la dirección IP de un usuario conectado con una laptop que sale de su casa para ir a trabajar desde un café. En consecuencia, el usuario puede tener una experiencia irregular con la aplicación cuando su dirección IP cambie.
  • Debido a que las direcciones IP se asignan a las versiones de manera independiente, la división del tráfico resultante será un tanto diferente de lo que especificas. Sin embargo, cuanto más tráfico reciba la aplicación, más se acercará la división real a tu objetivo. Por ejemplo, si solicitas que se entregue el 5% del tráfico a una versión alternativa, el porcentaje inicial de tráfico que se le envía 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 aplicaciones, debes usar la división por cookies. Las solicitudes que se envían entre aplicaciones 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 única dirección IP, lo que significa que todas esas solicitudes se enrutan hacia la misma versión. Como resultado, las solicitudes internas no respetan estrictamente los porcentajes que configuraste para las divisiones de tráfico basadas en IP. Por ejemplo, si estableces que una versión recibirá 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 ser mucho mayor que el 1%, porque siempre se enrutan todas las solicitudes internas a la versión asignada. Las solicitudes enviadas a tu aplicación 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 eliges dividir el tráfico hacia tu aplicación según las cookies, la aplicación busca en el encabezado de solicitud HTTP una cookie llamada GOOGAPPUID, que contiene un valor entre 0 y 999:

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

Si la respuesta no contiene la cookie GOOGAPPUID, la aplicación primero 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 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 siguientes limitaciones:

  • Si estás escribiendo una aplicación para dispositivos móviles o ejecutando un cliente de computadora de escritorio, deben administrarse las cookies GOOGAPPUID. Por ejemplo, cuando se usa un encabezado de respuesta de Set-Cookie, debes almacenar la cookie y luego incluirla con cada solicitud posterior. En las aplicaciones basadas en el navegador, las cookies ya se administran de esta manera automáticamente.

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

Inhabilitar la división del tráfico

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

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

Enviar comentarios sobre...

Entorno estándar de App Engine para Go