Dividir el tráfico

ID de región

El REGION_ID es un código abreviado que Google asigna en función de la región que selecciones al crear tu aplicación. El código no corresponde a un país o provincia, aunque algunos IDs de región pueden parecerse a los códigos de país y provincia que se usan habitualmente. En las aplicaciones creadas después de febrero del 2020, REGION_ID.r se incluye en las URLs de App Engine. En las aplicaciones creadas antes de esa fecha, el ID de región es opcional en la URL.

Más información sobre los IDs de región

Puede usar la división del tráfico para especificar un porcentaje de distribución del tráfico entre dos o más versiones de un servicio. La división del tráfico te permite hacer pruebas A/B entre tus versiones y controlar el ritmo de lanzamiento de las funciones.

El reparto del tráfico se aplica a las URLs que no se dirigen explícitamente a una versión. Por ejemplo, las siguientes URLs dividen el tráfico porque se dirigen a todas las versiones disponibles del servicio especificado:

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

Para obtener información sobre cómo llegan las solicitudes a una versión, consulta Cómo se dirigen las solicitudes.

Antes de empezar

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

Evitar problemas de almacenamiento en caché

Antes de activar la división del tráfico, debes tener en cuenta los posibles problemas de almacenamiento en caché. Los problemas de almacenamiento en caché pueden darse en cualquier aplicación de App Engine, sobre todo al desplegar una nueva versión. La división del tráfico suele hacer que los problemas de almacenamiento en caché sutiles sean más evidentes.

Por ejemplo, supongamos que estás dividiendo el tráfico entre dos versiones, A y B, y que algún recurso externo que se puede almacenar en caché ha cambiado entre las versiones (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 caché HTTP local recuperará el archivo si está en la caché, independientemente de la versión del archivo que esté almacenada en caché y de la versión de la aplicación que haya enviado la respuesta. El recurso almacenado en caché podría no ser compatible con los datos que se enviaron en la respuesta.

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

  • En el caso de los recursos dinámicos, defina los encabezados Cache-Control y Expires. Estos encabezados indican a los proxies que el recurso es dinámico. Lo mejor es definir ambos encabezados, ya que no todos los servidores proxy admiten correctamente el encabezado Cache-Control de HTTP/1.1.

    Si quieres obtener más información sobre el almacenamiento en caché en general, consulta los campos de encabezado de la RFC de HTTP/1.1 y la descripción general del almacenamiento en caché HTTP de Web Fundamentals.

  • En el caso de los recursos estáticos almacenables en caché que varían entre versiones, cambia la URL del recurso entre versiones. Si los recursos estáticos se sirven desde URLs diferentes, ambas versiones pueden coexistir sin problemas en los servidores proxy y en las cachés de los navegadores.

También puedes hacer que tu aplicación defina 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 1000 valores posibles de GOOGAPPUID y, por lo tanto, 1000 entradas posibles para cada URL de tu aplicación. En función de la carga de los proxies entre tus usuarios y tu aplicación, esto puede reducir la frecuencia con la que tu aplicación ofrece un resultado almacenado en caché. Además, durante las 24 horas posteriores a la adición de un nuevo lote de usuarios a una versión, es posible que esos usuarios sigan viendo 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. Por lo general, si tu aplicación usa cookies para otros fines, debes tener en cuenta cómo afecta esto a 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 sería un número muy grande (100 * 1000 = 100.000). En el peor de los casos, hay una cookie única para cada usuario. Dos ejemplos habituales son Google Analytics (__utma) y SiteCatalyst (s_vi). En estos casos, cada usuario obtiene una copia única, lo que reduce considerablemente el rendimiento de la caché y también puede aumentar las horas de instancia facturables que consume tu aplicación.

Dividir el tráfico entre varias versiones

Cuando haya especificado dos o más versiones para la división, deberá elegir si quiere dividir el tráfico mediante una dirección IP del remitente 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 de direcciones IP y División de cookies.

Consola

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

Ve a la página Versiones.

  1. Selecciona una o varias versiones a las que quieras dirigir el tráfico.
  2. Haga clic en Dividir tráfico y, a continuación, especifique lo siguiente:
    • El método que quieras usar para dividir el tráfico.
    • El porcentaje de tráfico que debe recibir cada versión.

gcloud

Después de instalar la CLI 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 información y opciones, consulta la referencia de gcloud app services set-traffic.

API

Para migrar el tráfico de forma programática, puedes usar la API Admin. Consulta el artículo Migrar y dividir el tráfico para obtener más información.

División de direcciones IP

Si decides dividir el tráfico de tu aplicación por dirección IP del remitente, cuando la aplicación recibe una solicitud, cifra la dirección IP en un valor entre 0 y 999 y usa ese número para enrutar la solicitud.

La división de direcciones IP tiene algunas limitaciones importantes:

  • Las direcciones IP de los remitentes son razonablemente persistentes, pero no permanentes. Los usuarios que se conecten desde teléfonos móviles pueden tener una dirección IP cambiante a lo largo de una misma sesión. Del mismo modo, un usuario que se desplace de su casa a una cafetería para trabajar con un portátil también cambiará de dirección IP. Por lo tanto, es posible que el usuario tenga una experiencia incoherente con tu aplicación a medida que cambie su dirección IP.
  • Como las direcciones IP se asignan de forma independiente a las versiones, la división del tráfico resultante será algo diferente de la que especifiques. Sin embargo, a medida que tu aplicación reciba más tráfico, la división real se acercará más al objetivo. Por ejemplo, si pide que se envíe el 5% del tráfico a una versión alternativa, el porcentaje inicial de tráfico a la versión podría estar entre el 3 y el 7 %, pero, con el tiempo, se acercará al 5 % objetivo.
  • Si necesitas enviar solicitudes internas entre aplicaciones, debes usar la división de cookies. Las solicitudes que se envían entre aplicaciones que se ejecutan en la infraestructura de nube de Google proceden de un número reducido de direcciones IP que probablemente se hayan asignado a la misma versión. Por lo tanto, todas las solicitudes internas pueden comportarse de forma similar a las solicitudes enviadas desde una única dirección IP, lo que significa que todas esas solicitudes se dirigen a la misma versión. Por lo tanto, las solicitudes internas no respetan los porcentajes que hayas definido para tus divisiones de tráfico basadas en IP. Por ejemplo, si asignas a una versión el 1% de todo el tráfico de tu aplicación y las direcciones de la infraestructura de Google Cloud se asignan a esa versión por casualidad, el resultado real podría superar con creces el 1 %, ya que todas las solicitudes internas siempre se dirigen a la versión asignada. Las solicitudes enviadas a tu aplicación desde fuera de la infraestructura de nube de Google funcionarán correctamente, ya que proceden 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 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 no existe ninguna cookie de este tipo, la solicitud se enruta de forma aleatoria.

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

Al usar cookies para dividir el tráfico, es más fácil asignar usuarios a versiones con precisión. La precisión del enrutamiento del tráfico puede alcanzar un 0,1% del reparto objetivo. Sin embargo, la división de cookies tiene las siguientes limitaciones:

  • Si estás escribiendo una aplicación móvil o ejecutando un cliente de escritorio, este debe gestionar las cookies GOOGAPPUID. Por ejemplo, cuando se usa un encabezado de respuesta Set-Cookie, debe almacenar la cookie e incluirla en cada solicitud posterior. Las aplicaciones basadas en navegador ya gestionan las cookies de esta forma automáticamente.

  • Dividir las solicitudes internas requiere un trabajo adicional. Todas las solicitudes de los 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 a otra aplicación o a sí misma. Ten en cuenta que no se recomienda enviar solicitudes internas si no proceden de un usuario.

Inhabilitar la división del tráfico

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