Descripción general de la administración avanzada del tráfico

Traffic Director proporciona funciones de administración avanzada del tráfico que te brindan un control detallado sobre cómo se maneja el tráfico. Traffic Director admite los siguientes casos de uso:

  • Enrutamiento detallado de las solicitudes a uno o más servicios
  • Acciones basadas en solicitudes y respuestas, como redireccionamientos y transformaciones de encabezados
  • Distribución de tráfico más precisa entre los backends de un servicio para mejorar el balanceo de cargas

Estas funciones de administración avanzada del tráfico te permiten cumplir tus objetivos de disponibilidad y rendimiento. Uno de los beneficios de usar Traffic Director para estos casos de uso es que puedes actualizar la forma en que se administra el tráfico sin tener que modificar el código de la aplicación.

Ejemplos de casos de uso

La administración avanzada del tráfico abarca muchos casos de uso. En esta sección, se proporcionan algunos ejemplos de alto nivel.

Puedes encontrar más ejemplos, incluido el código de muestra, en las guías Configura la administración avanzada del tráfico y Configura servicios de gRPC sin proxy basados en VM con la administración avanzada del tráfico.

Enrutamiento detallado del tráfico para la personalización

Puedes enrutar el tráfico a un servicio según los parámetros de la solicitud. Por ejemplo, puedes usar esto para proporcionar una experiencia más personalizada a los usuarios de Android. En el siguiente diagrama, Traffic Director configura la malla de servicios para enviar solicitudes con el encabezado user-agent:Android al servicio de Android y no al servicio genérico.

Enrutamiento basado en el encabezado de usuario-agente establecido en Android (haz clic para ampliar)
Enrutamiento basado en el encabezado user-agent establecido en Android (haz clic para ampliar)

División del tráfico basada en el peso para implementaciones más seguras

Implementar una versión nueva de un servicio de producción existente puede ser arriesgado. Incluso después de que se pasen las pruebas en un entorno de pruebas, no recomendamos enrutar todos los usuarios a la versión nueva de inmediato.

Traffic Director te permite definir divisiones de tráfico basadas en el peso para distribuir el tráfico entre varios servicios. Por ejemplo, puedes enviar el 1% del tráfico a la versión nueva del servicio, supervisar que todo funcione y, luego, aumentar de forma gradual la proporción del tráfico que se dirige al servicio nuevo.

División de tráfico basada en el peso de Traffic Director (haz clic para ampliar)
División del tráfico basada en el peso de Traffic Director (haz clic para ampliar)

Duplicación del tráfico para la depuración

Cuando depuras un problema, puede ser útil enviar copias del tráfico de producción a un servicio de depuración. Traffic Director te permite configurar políticas de duplicación de solicitudes para que estas se envíen a un servicio, y las copias de esas solicitudes se envíen a otro servicio.

Duplicación del tráfico de Traffic Director (haz clic para ampliar)
Duplicación del tráfico de Traffic Director (haz clic para ampliar)

Balanceo de cargas más preciso para el rendimiento

Según las características de la aplicación, es posible que puedas mejorar el rendimiento y la disponibilidad si ajustas con precisión la forma en que se distribuye el tráfico entre los backends de un servicio. Con Traffic Director, puedes aplicar algoritmos de balanceo de cargas avanzados para que el tráfico se distribuya según tus necesidades.

En el siguiente diagrama, a diferencia de los diagramas anteriores, se muestra un servicio de backend de destino (servicio de producción [Production Service]) y los backends para ese servicio de backend (máquina virtual 1 [Virtual Machine 1], máquina virtual 2 [Virtual Machine 2], máquina virtual 3 [Virtual Machine 3]). Con la administración avanzada del tráfico, puedes configurar cómo se selecciona un servicio de backend de destino y cómo se distribuye el tráfico entre los backends para ese servicio de destino.

Balanceo de cargas de Traffic Director (haz clic para ampliar)
Balanceo de cargas de Traffic Director (haz clic para ampliar)

Cómo funciona la administración avanzada del tráfico

La administración avanzada del tráfico se configura mediante el mapa de reglas de enrutamiento y los recursos de los servicios de backend que usas cuando configuras Traffic Director. En cambio, Traffic Director configura los proxies de Envoy y las aplicaciones de gRPC sin proxy para aplicar las políticas de administración avanzada del tráfico que configuraste.

En un alto nivel, puedes seguir los siguientes pasos:

  1. Configura el mapa de reglas de enrutamiento para que realice las siguientes acciones, según las características de la solicitud saliente:

    1. Seleccionar el servicio de backend al que se enrutan las solicitudes

    2. Realizar acciones adicionales (opcional)

  2. Configura el servicio (servicio de backend) a fin de controlar cómo se distribuye el tráfico en los backends y extremos después de seleccionar un servicio de destino.

Acciones y enrutamiento del tráfico

En Traffic Director, el mapa de reglas de enrutamiento hace referencia a la combinación de la regla de reenvío, el proxy de destino y los recursos del mapa de URL. Todas las funciones de administración avanzada del tráfico relacionadas con el enrutamiento y las acciones se configuran mediante el mapa de URL.

Puedes configurar las siguientes funciones de administración avanzada del tráfico en tu mapa de reglas de enrutamiento.

Control de solicitudes

Cuando un cliente envía una solicitud, esta se controla de la siguiente manera:

  1. La solicitud coincide con un mapa de reglas de enrutamiento específico. Esta coincidencia se realiza de la siguiente manera:
    1. Mediante el uso de Envoy:
      1. El puerto y la dirección IP de destino de la solicitud se comparan con el puerto y la dirección IP de las reglas de reenvío en todos los mapas de reglas de enrutamiento. Solo se consideran los mapas de reglas de enrutamiento con reglas de reenvío que tengan el esquema de balanceo de cargas INTERNAL_SELF_MANAGED.
      2. La regla de reenvío que coincide con la solicitud hace referencia a un proxy HTTP o gRPC de destino, que hace referencia a un mapa de URL. Este mapa de URL contiene información que se usa para el enrutamiento y las acciones.
    2. Mediante el uso de gRPC sin proxy:
      1. Se ignora la dirección IP de la solicitud, ya que solo puedes usar la dirección IP 0.0.0.0 cuando creas una regla de reenvío que hace referencia a un proxy de gRPC de destino. Solo se consideran los mapas de reglas de enrutamiento con reglas de reenvío que tengan el esquema de balanceo de cargas INTERNAL_SELF_MANAGED.
      2. El puerto en el URI de destino (por ejemplo, xds:///foo.myservice:8080) se compara con el puerto de las reglas de reenvío con el esquema de balanceo de cargas INTERNAL_SELF_MANAGED. La dirección IP de una regla de reenvío no se usa.
      3. La regla de reenvío que coincide con la solicitud hace referencia a un proxy de gRPC de destino, que hace referencia a un mapa de URL. Este mapa de URL contiene información que se usa para el enrutamiento y las acciones.
  2. Cuando se determina el mapa de URL adecuado, se evalúa el mapa de URL para determinar el servicio de backend de destino y, de forma opcional, aplicar acciones.
  3. Una vez que se selecciona el servicio de backend de destino, el tráfico se distribuye entre los backends o extremos de ese servicio, según la configuración del recurso del servicio de backend.

El segundo paso se describe en la siguiente sección, Enrutamiento simple basado en el host y la ruta de acceso. El tercer paso se analiza en Enrutamiento y acciones avanzados.

Enrutamiento simple basado en el host y la ruta de acceso

Traffic Director admite un esquema de enrutamiento simplificado y un esquema más avanzado. Los esquemas de enrutamiento más avanzados, incluidas las acciones, se describen en la siguiente sección, Enrutamiento y acciones avanzados. En el esquema simple, debes especificar un host y, de forma opcional, una ruta de acceso. El host y la ruta de acceso de la solicitud se evalúan para determinar el servicio al que se debe enrutar una solicitud.

  • El host de la solicitud es la parte del nombre de dominio de una URL. Por ejemplo, la parte del host de la URL http://example.com/video/ es example.com.
  • La ruta de acceso de la solicitud es la parte de la URL que sigue al nombre de host. Por ejemplo, /video en http://example.com/video.
Configura el enrutamiento simple basado en el host y la ruta de acceso

El enrutamiento simple basado en el host y la ruta de acceso se configura en el mapa de reglas de enrutamiento, que consta de los siguientes elementos:

  • Una regla de reenvío global
  • Un proxy HTTP de destino o un proxy de gRPC de destino
  • Un mapa de URL

La mayor parte de la configuración se realiza en el mapa de URL. Después de crear el mapa de reglas de enrutamiento inicial, por lo general, solo necesitas modificar la parte del mapa de URL del mapa de reglas de enrutamiento. En este diagrama, las reglas de ruta de acceso tienen acciones similares al siguiente diagrama.

Enrutamiento basado en recursos de host y ruta de acceso (haz clic para ampliar)
Enrutamiento basado en recursos de host y ruta de acceso (haz clic para ampliar)

La regla más simple es una regla predeterminada, en la que solo especificas una regla de host comodín (*) y un comparador de rutas de acceso con un servicio predeterminado. Una vez que creaste la regla predeterminada, puedes agregar reglas adicionales que especifiquen diferentes hosts y rutas de acceso. Las solicitudes salientes se evalúan según estas reglas de la siguiente manera.

Si el host de una solicitud (por ejemplo, example.com) coincide con una regla de host, sucede lo siguiente:

  1. Se evalúa el comparador de rutas de acceso.
  2. Cada comparador de rutas de acceso contiene una o más reglas de ruta de acceso que se evalúan en función de la ruta de acceso de la solicitud.
  3. Si se encuentra una coincidencia, la solicitud se enruta al servicio especificado en la regla de ruta de acceso.
  4. Cada comparador de rutas de acceso contiene un servicio predeterminado al que se enrutan las solicitudes si coincide la regla de host, pero no una regla de ruta de acceso.

Si la solicitud no coincide con ninguna de las reglas de host que especificaste, se enruta al servicio especificado en la regla predeterminada.

Para obtener más información sobre los campos del recurso del mapa de URL y cómo funcionan, consulta la página de la API de REST de urlMaps.

Enrutamiento y acciones avanzados

Puedes configurar reglas avanzadas para enrutar solicitudes y realizar acciones si deseas hacer más que enrutar una solicitud basada en el host y la regla de acceso de una solicitud.

Enrutamiento avanzado (haz clic para ampliar)
Enrutamiento avanzado (haz clic para ampliar)

En un nivel alto, el enrutamiento y las acciones avanzados funcionan de la siguiente manera:

  1. Al igual que con el enrutamiento simple, el host de la solicitud se compara con las reglas de host que configuras en el mapa de URL. Si el host de una solicitud coincide con una regla de host, se evalúa el comparador de rutas de acceso de la regla de host.
  2. El comparador de rutas de acceso contiene una o más reglas de enrutamiento que se evalúan según la solicitud.
    1. Estas reglas de enrutamiento se evalúan en orden de prioridad. Para ello, se hacen coincidir los atributos de la solicitud (host, ruta de acceso, encabezado y parámetros de consulta) de acuerdo con condiciones de coincidencia específicas, por ejemplo, coincidencia de prefijo.
  3. Una vez que se selecciona una regla de enrutamiento, es posible que se apliquen acciones. La acción predeterminada es enrutar la solicitud a un solo servicio de destino, pero también puedes configurar otras acciones.
Enrutamiento avanzado

El enrutamiento avanzado es similar al enrutamiento simple descrito antes, con la excepción de que puedes especificar la prioridad de la regla y las condiciones de coincidencia adicionales, como se describe a continuación.

Con el enrutamiento avanzado, debes especificar una sola prioridad para cada regla. Esta prioridad determina el orden en el que se evalúan las reglas de enrutamiento; los valores con una prioridad más baja prevalecen sobre los de mayor prioridad. Cuando una solicitud coincide con una regla, esta se aplica y otras se ignoran.

El enrutamiento avanzado también admite condiciones de coincidencia adicionales. Por ejemplo, puedes especificar que una regla coincida con el encabezado de una solicitud si el nombre de ese encabezado coincide de manera exacta o parcial, por ejemplo, según el prefijo o sufijo. Puede coincidir según la evaluación del nombre del encabezado en función de una expresión regular o de acuerdo con otros criterios, como verificar la presencia de un encabezado.

Si combinas el host, la ruta de acceso, el encabezado, los parámetros de consulta con prioridades y las condiciones de coincidencia, puedes crear reglas muy expresivas que se adapten a tus requisitos exactos de administración del tráfico.

Hosts HTTP en comparación con hosts de gRPC

Si escribes una aplicación basada en HTTP, el host es la parte del nombre de dominio de la URL a la que llama la aplicación. Por ejemplo, la parte del host de la URL http://example.com/video/ es example.com.

Si escribes una aplicación basada en gRPC, el host es el nombre que un cliente usa en el URI del canal para conectarse a un servicio específico. Por ejemplo, la parte del host del URI del canal xds:///example.com es example.com.

Rutas de acceso de HTTP en comparación con rutas de acceso de gRPC

Si escribes una aplicación basada en HTTP, la ruta de acceso es la parte de la URL que sigue al nombre de host, por ejemplo, /video en http://example.com/video.

Si escribes una aplicación basada en gRPC, la ruta de acceso se encuentra en el encabezado :path de la solicitud HTTP/2 y se ve como /SERVICE_NAME/METHOD_NAME/. Por ejemplo, si llamas al método Download en el servicio de gRPC de Example, el contenido del encabezado :path se vería como /Example/Download.

Otros encabezados de gRPC (metadatos)

gRPC admite el envío de metadatos entre el cliente de gRPC y el servidor de gRPC para proporcionar información adicional sobre una llamada RPC. Estos metadatos tienen un formato de pares clave-valor que se transfieren como encabezados en la solicitud HTTP/2.

Acciones

Traffic Director te permite especificar acciones que realizan los proxies de Envoy o las aplicaciones de gRPC sin proxy cuando controlan una solicitud. Las siguientes acciones se pueden configurar mediante Traffic Director.

Acción (nombre del campo de la API) Descripción
Redireccionamientos (urlRedirect) Muestra un código de respuesta 3xx configurable. También establece el encabezado de respuesta Location con el URI apropiado, lo que reemplaza el host y la ruta de acceso como se especifica en la acción de redireccionamiento.
Reescritura de URL (urlRewrite) Vuelve a escribir la parte del nombre de host de la URL, la parte de la ruta de la URL o ambas, antes de enviar una solicitud al servicio de backend seleccionado.
Transformaciones del encabezado (headerAction) Agrega o quita encabezados de la solicitud antes de enviar una solicitud al servicio de backend. También puede agregar o quitar los encabezados de respuesta después de recibir una respuesta del servicio de backend.
Duplicación de tráfico (requestMirrorPolicy) Además de reenviar la solicitud al servicio de backend seleccionado, envía una solicitud idéntica al servicio de backend duplicado y configurado en una base de enviar y olvidar. El balanceador de cargas no espera una respuesta del backend al que envía la solicitud duplicada.

La duplicación es útil para probar una versión nueva de un servicio de backend. También puedes usarla para depurar errores de producción en una versión de depuración de tu servicio de backend, en lugar de hacerlo en la versión de producción.
División de tráfico basada en el peso (weightedBackendServices) Permite que el tráfico de una regla coincidente se distribuya a varios servicios de backend, proporcional a un peso definido por el usuario asignado al servicio de backend individual.

Esta función es útil para configurar implementaciones publicadas en etapa de pruebas o pruebas A/B. Por ejemplo, la acción de enrutamiento se podría configurar, de manera que el 99% del tráfico se envíe a un servicio que ejecuta una versión estable de una aplicación, mientras que el 1% del tráfico se envíe a un servicio independiente que ejecuta una versión más reciente de esa aplicación.
Reintentos (retryPolicy) Configuran las condiciones en las que el balanceador de cargas reintenta enviar solicitudes fallidas, cuánto espera el balanceador de cargas antes de volver a intentarlo y la cantidad máxima de reintentos permitidos.
Tiempo de espera (timeout) Especifica el tiempo de espera para la ruta seleccionada. El tiempo de espera se calcula desde el momento en que la solicitud se procesa por completo hasta el momento en que la respuesta se procesa por completo. El tiempo de espera incluye todos los reintentos.
Inserción de fallas (faultInjectionPolicy) Presenta errores cuando se entregan solicitudes para simular fallas, incluida la latencia alta, la sobrecarga del servicio, las fallas del servicio y la partición de la red. Esta característica es útil para probar la resiliencia de un servicio ante fallas simuladas.
Políticas de seguridad (corsPolicy) Las políticas de uso compartido de recursos entre dominios (CORS) controlan la configuración para aplicar las solicitudes de CORS.

Para obtener información adicional sobre las acciones y cómo funcionan, consulta la referencia de la API de mapas de URL.

En cada regla de enrutamiento, puedes especificar una de las siguientes acciones de enrutamiento (denominadas “Acciones principales” en Google Cloud Console):

  • Enrutar el tráfico a un solo servicio (service)
  • Dividir el tráfico entre varios servicios (weightedBackendServices)
  • Redireccionar las URL (urlRedirect)

Además, puedes combinar cualquiera de las acciones de enrutamiento mencionadas antes con una o más de las siguientes acciones de enrutamiento (denominadas “Acciones de complementos” en Google Cloud Console):

  • Manipular los encabezados de respuesta o solicitud (headerAction)
  • Duplicar el tráfico (requestMirrorPolicy)
  • Reescribir la ruta de acceso/host de URL (urlRewrite)
  • Reintentar con las solicitudes que fallaron (retryPolicy)
  • Configurar el tiempo de espera (timeout)
  • Ingresar errores en un porcentaje del tráfico (faultInjectionPolicy)
  • Agregar política de CORS (corsPolicy)

Debido a que las acciones están asociadas con reglas de enrutamiento específicas, el proxy de Envoy o la aplicación de gRPC sin proxy puede aplicar diferentes acciones en función de la solicitud que controla.

Distribuye el tráfico entre los backends de un servicio

Como se explica en Control de solicitudes, cuando un cliente controla una solicitud saliente, primero selecciona un servicio de destino. Una vez que selecciona un servicio de destino, necesita determinar qué backend o extremo debe recibir la solicitud.

Distribución del tráfico entre backends (haz clic para ampliar)
Distribución del tráfico entre backends (haz clic para ampliar)

En el diagrama anterior, se simplificó la Regla (Rule). Por lo general, se trata de una regla de host, un comparador de rutas de acceso y una o más reglas de enrutamiento o ruta de acceso. El servicio de destino es el servicio (de backend) ([Backend] Service). En realidad, Backend 1, … y Backend n reciben y controlan la solicitud. Estos backends pueden ser, por ejemplo, máquinas virtuales de Compute Engine que alojan el código de la aplicación del servidor.

De forma predeterminada, el cliente que controla la solicitud enviará solicitudes al backend en buen estado más cercano y que tenga capacidad. Para evitar la sobrecarga de un backend específico, balancea las cargas posteriores en otros backends del servicio de destino mediante el algoritmo de balanceo de cargas round robin. Sin embargo, en algunos casos, recomendamos un control más detallado sobre este comportamiento.

Balanceo de cargas, afinidad de sesión y protección de backends

Puedes establecer las siguientes políticas de distribución de tráfico en cada servicio.

Política (nombre del campo de la API) Descripción
Modo de balanceo de cargas (balancingMode) Controla cómo se selecciona un grupo de extremos de red o un grupo de instancias administrado una vez que se selecciona un servicio de destino. Puedes configurar el modo de balanceo para distribuir la carga en función de las conexiones simultáneas, el porcentaje de solicitudes, etcétera.
Política de balanceo de cargas (localityLbPolicy) Establece el algoritmo de balanceo de cargas que se usa para distribuir el tráfico entre backends dentro de un grupo de extremos de red o un grupo de instancias administrado. Puedes elegir entre una variedad de algoritmos diferentes (como round robin, solicitud mínima, etc.) para optimizar el rendimiento.
Afinidad de sesión (sessionAffinity) La afinidad de sesión hace su mejor esfuerzo para enviar solicitudes de un cliente en particular al mismo backend, siempre que el backend esté en buen estado y tenga capacidad. Traffic Director admite cuatro opciones de afinidad de sesión diferentes: dirección IP de cliente, basada en cookies HTTP, basada en encabezado HTTP y afinidad de cookie generada (que la genera Traffic Director).
Hash coherente (consistentHash) Se puede usar para proporcionar afinidad de sesión reducida basada en encabezados HTTP, cookies y otras propiedades.
Disyuntores (circuitBreakers) Establece los límites superiores en el volumen de conexiones y solicitudes por conexión a un servicio de backend.
Detección de valores atípicos (outlierDetection) Especifica los criterios para (1) quitar extremos o backends en mal estado de los grupos de instancias administrados o los grupos de extremos de red, y (2) agregar un backend o un extremo cuando se considere que está en buen estado para volver a recibir tráfico. La verificación de estado asociada a un servicio determina si un backend o un extremo está en buen estado.

Para obtener información adicional sobre las diferentes opciones de distribución de tráfico y cómo funcionan, consulta la referencia de la API de los servicios de backend.

Configuración de filtros

Una de las responsabilidades principales de Traffic Director es generar la configuración y enviarla a varios clientes de Traffic Director, por ejemplo, proxies de Envoy o aplicaciones de gRPC. Traffic Director controla tu malla de servicios mediante el envío de la configuración a sus clientes, que les indica qué deben hacer. Traffic Director es el plano de control.

Cuando creas o actualizas una configuración en Traffic Director, Traffic Director traduce esta configuración a un lenguaje que los clientes puedan comprender. De forma predeterminada, Traffic Director comparte esta configuración con todos sus clientes. En algunos casos, recomendamos personalizar qué clientes de Traffic Director reciben una configuración específica, en otras palabras, filtrar la configuración para clientes específicos.

Aunque esta es una funcionalidad avanzada, en los siguientes ejemplos, se muestra cuándo podría ser útil la configuración de filtros:

  • Tu organización usa el modelo de herramientas de redes de VPC compartida, y varios equipos usan Traffic Director en diferentes proyectos de servicio. Si deseas aislar la configuración de otros proyectos de servicio, puedes filtrarla para que los clientes específicos de Traffic Director reciban solo un subconjunto de la configuración.
  • Tienes una gran cantidad de reglas de enrutamiento y servicios configurados en Traffic Director y deseas evitar el envío de una gran cantidad de configuración a cada cliente de Traffic Director. Ten en cuenta que un cliente que necesita evaluar una solicitud saliente mediante una configuración grande y compleja puede tener un menor rendimiento que un cliente que solo necesita evaluar una solicitud con una configuración optimizada.

El filtrado de configuración se basa en el concepto de filtros de metadatos:

  1. Cuando se conecta un cliente de Traffic Director, presenta información del archivo de arranque a Traffic Director.
  2. Esta información incluye el contenido de los campos de metadatos, en forma de pares clave-valor, que especificas en el archivo de arranque cuando implementas los proxies de Envoy o las aplicaciones de gRPC.
  3. Puedes agregar filtros de metadatos a la regla de reenvío o a las reglas de enrutamiento que configures en el mapa de reglas de enrutamiento.
  4. Cuando agregas filtros de metadatos a estos recursos, Traffic Director solo comparte la configuración con los clientes que presentan metadatos que coinciden con las condiciones del filtro de metadatos.

Puedes aplicar filtros de metadatos en la regla de reenvío. En este caso, el mapa de reglas de enrutamiento y los servicios asociados solo se comparten con clientes de Traffic Director que presentan metadatos coincidentes.

Como alternativa, puedes aplicar filtros de metadatos en reglas de enrutamiento específicas. En este caso, Traffic Director solo comparte la regla de enrutamiento específica y los servicios asociados con clientes de Traffic Director que presentan metadatos coincidentes. Para obtener información sobre cómo configurar filtros de metadatos, consulta Establece el filtrado de configuración según la coincidencia de MetadataFilter.

Limitaciones

  • Algunas funciones descritas en este documento no se pueden configurar para servicios de gRPC sin proxy con Traffic Director. Para obtener información sobre las funciones compatibles, consulta Administración de enrutamiento y tráfico, Balanceo de cargas y otras tablas en Funciones de Traffic Director.

  • Para obtener información sobre las limitaciones adicionales que se aplican a las aplicaciones de gRPC sin proxy con Traffic Director, consulta la sección Limitaciones en la guía de descripción general.

Próximos pasos