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 tus versiones y controlar el ritmo cuando se implementan funciones.

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 de [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 tenga los privilegios necesarios.

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é 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, supón que divides el tráfico entre dos versiones, A y B, y algún recurso externo que puede almacenarse en caché cambió entre versiones, como un archivo CSS. Ahora supón 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 caché, independientemente de la versión del archivo almacenada en la caché y la versión de la aplicación que envió la respuesta. El recurso almacenado en la caché podría ser incompatible con los datos enviados en la respuesta.

Para evitar problemas de almacenamiento en caché:

  • Para los recursos dinámicos, configura los encabezados Control de caché y Vencimiento. Estos encabezados les indican a los proxies que el recurso es dinámico. Es mejor 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 Almacena documentos en caché en el Manual de seguridad del navegador.

  • Para los recursos estáticos que se pueden almacenar en caché y que varían entre versiones, cambia la URL del recurso entre versiones. Si los recursos estáticos se entregan desde diferentes URL, ambas versiones pueden coexistir 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 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 de tu aplicación. La tasa de aciertos de caché puede disminuir en función de la carga en los proxies entre tus usuarios y tu aplicación. 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 almacenados en caché. Sin embargo, usar 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 aplicación usa cookies para otros fines, debes considerar cómo esto afecta la carga de los servidores proxy. Si codeninja tuviera 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 tu aplicación.

Divide el tráfico entre varias versiones

Cuando hayas especificado dos o más versiones para dividir el tráfico, debes elegir si quieres hacerlo mediante una dirección IP o una cookie HTTP. Es más fácil configurar una división de direcciones IP, pero una división de 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 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:
    • 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

Si quieres migrar el tráfico de manera programática, puedes usar la API de Administrador. Para obtener más detalles, consulta Migra y divide el tráfico.

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 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, también cambiará la dirección IP de un usuario conectado con una laptop que sale de casa para ir a trabajar desde un café. En consecuencia, el usuario puede tener una experiencia irregular con tu aplicación cuando cambia su dirección IP.
  • 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, la división real se acercará más a tu objetivo a medida que tu aplicación reciba más trafico. Por ejemplo, si solicitas que el 5% del tráfico se entregue a una versión alternativa, el porcentaje inicial de tráfico que se le envía podría ser entre un 3% y un 7%, pero se acercará cada vez más a tu objetivo del 5%.
  • Si necesitas enviar solicitudes internas entre aplicaciones, debes usar la división de cookies. Las solicitudes que se envían entre apps 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 igual que las solicitudes enviadas desde una sola dirección IP, lo que significa que todas las solicitudes se enrutan hacia la misma versión. En consecuencia, las solicitudes internas no respetan de forma estricta los porcentajes que estableces para tus 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 las direcciones de la infraestructura de nube de Google se asignaron coincidentemente 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 aplicación desde fuera de la infraestructura de nube de Google funcionarán según lo previsto, ya que se originan en una distribución variada de direcciones IP.

Si optas por dividir el tráfico hacia tu aplicación mediante cookies, la aplicación busca en el Encabezado de solicitud de HTTP una cookie con el nombre 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, 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 a la división objetivo en un 0.1%. No obstante, dividir por cookies tiene las siguientes limitaciones:

  • Si desarrollas una aplicación para dispositivos móviles o si ejecutas un cliente en la 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 en forma automática.

  • Dividir solicitudes internas requiere trabajo adicional. 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 aplicación o hacia ella 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.