Métricas personalizadas de balanceadores de carga de aplicaciones

En esta página se describe cómo usar métricas personalizadas con los balanceadores de carga de aplicaciones. Las métricas personalizadas le permiten configurar el comportamiento de distribución del tráfico de su balanceador de carga en función de métricas específicas de los requisitos de su aplicación o infraestructura, en lugar de las métricas estándar de uso o basadas en la tasa de Google Cloud. Definir métricas personalizadas para tu balanceador de carga te ofrece la flexibilidad de dirigir las solicitudes de aplicaciones a las instancias y los endpoints de backend que sean más óptimos para tu carga de trabajo.

El balanceador de carga usa los valores de las métricas personalizadas para tomar las siguientes decisiones:

1. Selecciona el grupo de instancias de máquina virtual (VM) o el grupo de endpoints de red de backend que debe recibir el tráfico.
2. Selecciona la instancia de VM o el endpoint que debe recibir el tráfico.

Balanceo de carga con métricas personalizadas (haz clic en la imagen para ampliarla).

A continuación, se muestran algunos casos prácticos de ejemplo para las métricas personalizadas:

• Maximiza el uso de tu capacidad de computación global tomando decisiones de balanceo de carga basadas en métricas personalizadas que sean más relevantes para tu aplicación, en lugar de usar los criterios predeterminados, como la afinidad regional o la latencia de red.

  Si tus aplicaciones suelen tener latencias de procesamiento de backend del orden de segundos, puedes usar tu capacidad de computación global de forma más eficiente balanceando la carga de las solicitudes en función de métricas personalizadas en lugar de la latencia de red.

• Maximiza la eficiencia de los recursos informáticos tomando decisiones de balanceo de carga basadas en combinaciones de métricas exclusivas de tu implementación. Por ejemplo, supongamos que tus solicitudes tienen tiempos de procesamiento y requisitos de computación muy variables. En este caso, el balanceo de carga basado únicamente en la tasa de solicitudes por segundo da como resultado una distribución de carga desigual. En ese caso, puede que quieras definir una métrica personalizada que equilibre la carga en función de una combinación de la tasa de solicitudes y el uso de la CPU o la GPU para usar tu flota de computación de la forma más eficiente posible.

• Escala automáticamente los back-ends en función de las métricas personalizadas que sean más relevantes para los requisitos de tu aplicación. Por ejemplo, puedes definir una política de autoescalado para autoescalar tus instancias de backend cuando tu métrica personalizada configurada supere el 80%. Para ello, se usan métricas de autoescalado basadas en el tráfico (autoscaling.googleapis.com|gclb-capacity-fullness). Para obtener más información, consulta Autoescalado basado en el tráfico del balanceador de carga.

Balanceadores de carga y backends admitidos

Las métricas personalizadas se admiten en los siguientes balanceadores de carga de aplicaciones:

• Balanceador de carga de aplicación externo global
• Balanceador de carga de aplicación externo regional
• Balanceador de carga de aplicación interno entre regiones
• Balanceador de carga de aplicación interno regional

Las métricas personalizadas se admiten con los siguientes tipos de backend:

• Grupos de instancias administradas
• NEGs por zonas (con puntos finales GCE_VM_IP_PORT)
• NEGs de conectividad híbrida

Cómo funcionan las métricas personalizadas

Para que tu balanceador de carga pueda tomar decisiones sobre la distribución del tráfico en función de métricas personalizadas, primero debes determinar cuáles son las métricas más relevantes para tu aplicación específica. Una vez que sepas qué métricas quieres usar, configura tus back-ends para que empiecen a enviar un flujo constante de estas métricas a tu balanceador de carga. Google Cloud te permite enviar métricas como parte de la cabecera de cada respuesta HTTP que envían los back-ends a tu balanceador de carga. Estas métricas se encapsulan en un encabezado de respuesta HTTP personalizado y deben seguir el estándar Open Request Cost Aggregation (ORCA).

Las métricas se pueden configurar en dos niveles:

• A nivel de servicio de backend, para influir en la selección del backend (MIG o NEG)
• A nivel de backend, para influir en la selección de instancias de VM o de endpoints

En las siguientes secciones se describe cómo funcionan las métricas personalizadas.

Determinar qué métricas personalizadas influyen en las decisiones de balanceo de carga

Determinar qué métricas personalizadas influyen en las decisiones de balanceo de carga es muy subjetivo y depende de las necesidades de tus aplicaciones. Por ejemplo, si las aplicaciones tienen latencias de procesamiento de backend del orden de segundos, puede que le interese balancear la carga de las solicitudes en función de otras métricas personalizadas en lugar de las latencias de red estándar.

Una vez que haya determinado qué métricas quiere usar, también debe determinar el umbral de utilización máximo de cada métrica. Por ejemplo, si quieres usar la utilización de memoria como métrica, también debes determinar el umbral máximo de utilización de memoria de cada backend.

Por ejemplo, si configura una métrica llamada example-custom-metric con un umbral de uso máximo del 0, 8, el balanceador de carga ajustará dinámicamente la distribución del tráfico entre los backends para que la métrica example-custom-metric que informa el backend sea inferior a 0, 8 en la medida de lo posible.

Hay dos tipos de métricas personalizadas que puedes usar:

• Métricas reservadas. Hay cinco nombres de métricas reservados. Estos nombres están reservados porque corresponden a campos predefinidos de nivel superior en la API ORCA.

  • orca.cpu_utilization
  • orca.mem_utilization
  • orca.application_utilization
  • orca.eps
  • orca.rps_fractional

  Las métricas mem_utilization, cpu_utilization y application_utilization esperan valores en el intervalo de 0.0 - 1.00, pero pueden superar 1.00 en situaciones en las que la utilización de recursos supera el presupuesto.

• Métricas con nombre: Se trata de métricas exclusivas de tu aplicación que especificas mediante el campo ORCA named_metrics con el siguiente formato:

  orca.named_metrics.METRIC_NAME
  

  Todas las métricas personalizadas definidas por el usuario se especifican mediante este mapa named_metrics en formato de pares nombre-valor.

  Las métricas con nombre definidas para el modo de balanceo CUSTOM_METRICS deben incluir valores en el intervalo 0 - 100. Las métricas con nombre definidas para la política de localidad de balanceo de carga WEIGHTED_ROUND_ROBIN no tienen ningún intervalo esperado.

Métricas obligatorias

Para que tu balanceador de carga pueda usar métricas personalizadas para seleccionar un grupo de instancias de VM de backend o un grupo de endpoints de red, debes especificar una o varias de las siguientes métricas de utilización en el informe de carga de ORCA que se envía al balanceador de carga. orca.named_metrics es un mapa de métricas definidas por el usuario en forma de pares de nombre y valor.

• orca.cpu_utilization
• orca.application_utilization
• orca.mem_utilization
• orca.named_metrics

Además, para que el balanceador de carga pueda usar métricas personalizadas para influir aún más en la selección de la instancia de VM o el endpoint de backend, debe proporcionar todas las métricas siguientes en el informe de carga de ORCA que se envía al balanceador de carga. El balanceador de carga usa las ponderaciones calculadas a partir de estas métricas para asignar carga a los backends.

• orca.rps_fractional (solicitudes por segundo)
• orca.eps (errores por segundo)
• una métrica de utilización con el siguiente orden de prioridad:
  1. orca.application_utilization
  2. orca.cpu_utilization
  3. las métricas definidas por el usuario en el mapa orca.named_metrics

Notas adicionales:

• Hay un límite de dos métricas personalizadas por backend. Sin embargo, puedes realizar dryRun pruebas con un máximo de tres métricas personalizadas.

  Si se proporcionan dos métricas, el balanceador de carga las trata de forma independiente. Por ejemplo, si define dos dimensiones: custom-metric-util1 y custom-metric-util2, el balanceador de carga las tratará de forma independiente. Si un backend tiene un nivel de uso alto en términos de custom-metric-util1, el balanceador de carga evita enviar tráfico a ese backend. Por lo general, el balanceador de carga intenta mantener todos los back-ends en funcionamiento con aproximadamente el mismo nivel de ocupación. La plenitud se calcula como currentUtilization / maxUtilization. En este caso, el balanceador de carga usa el valor de plenitud más alto de los dos valores que informan las métricas para tomar decisiones sobre el balanceo de carga.

• Hay un límite de dos métricas personalizadas por servicio de backend. Sin embargo, puedes hacer dryRunpruebas con un máximo de tres métricas personalizadas. Este límite no incluye las métricas obligatorias orca.eps y orca.rps_fractional. Este límite también es independiente de las métricas configuradas en el nivel de backend.

• Las métricas reservadas y las métricas con nombre se pueden usar juntas. Por ejemplo, se pueden proporcionar tanto orca.cpu_utilization = 0.5 como una métrica personalizada, como orca.named_metrics.queue_depth_util = 0.2, en un solo informe de carga.

• Los nombres de las métricas personalizadas no deben contener información regulada, sensible, identificable ni otra información confidencial que no deba ver ninguna persona ajena a tu organización.

Codificaciones disponibles para la especificación de métricas personalizadas

• JSON

  Ejemplo de codificación JSON de un informe de carga:

  endpoint-load-metrics-json: JSON {"cpu_utilization": 0.3, "mem_utilization": 0.8, "rps_fractional": 10.0, "eps": 1, "named_metrics": {"custom-metric-util": 0.4}}.
  

• Protobuf binario

  En el caso del código compatible con Protocol Buffers, se trata de un protobuf de OrcaLoadReport serializado en formato binario y codificado en base64 en endpoint-load-metrics-bin o en endpoint-load-metrics: BIN.

• HTTP nativo

  Pares clave-valor separados por comas en endpoint-load-metrics. Esta es una representación de texto combinada de OrcaLoadReport:

  endpoint-load-metrics: TEXT cpu_utilization=0.3, mem_utilization=0.8, rps_fractional=10.0, eps=1, named_metrics.custom_metric_util=0.4
  

• gRPC

  La especificación de gRPC requiere que las métricas se proporcionen mediante metadatos finales con la clave endpoint-load-metrics-bin.

Configuración del backend para registrar métricas personalizadas

Una vez que haya determinado las métricas que quiere que use el balanceador de carga, configure sus backends para que compilen las métricas personalizadas necesarias en un informe de carga de ORCA y comuniquen sus valores en cada encabezado de respuesta HTTP enviado al balanceador de carga.

Por ejemplo, si ha elegido orca.cpu_utilization como métrica personalizada para un backend, ese backend debe informar al balanceador de carga de la utilización actual de la CPU en cada respuesta que le envíe. Para obtener instrucciones, consulta la sección Enviar métricas al balanceador de carga de esta página.

Configuración del balanceador de carga para admitir métricas personalizadas

Para que el balanceador de carga pueda usar los valores de las métricas personalizadas que comunican los back-ends para tomar decisiones sobre la distribución del tráfico, debe definir el modo de balanceo de cada back-end en CUSTOM_METRICS y la política de localidad del balanceo de carga del servicio de back-end en WEIGHTED_ROUND_ROBIN.

Cómo funcionan las métricas personalizadas con los balanceadores de carga de aplicaciones (haz clic en la imagen para ampliarla).

• CUSTOM_METRICSmodo de balanceo. Cada uno de los backends de un servicio de backend debe configurarse para usar el modo de balanceo CUSTOM_METRICS. Cuando un backend se configura con el modo de balanceo CUSTOM_METRICS, el balanceador de carga dirige el tráfico a los backends según el umbral de utilización máximo configurado para cada métrica personalizada.

  Cada backend puede especificar un conjunto de métricas diferente para generar informes. Si se configuran varias métricas personalizadas por backend, el balanceador de carga intenta distribuir el tráfico de forma que todas las métricas permanezcan por debajo de los límites de utilización máximos configurados.

  El tráfico se balancea entre los backends en función del algoritmo de balanceo de carga que elijas. Por ejemplo, el algoritmo WATERFALL_BY_REGION predeterminado intenta mantener todos los backends en funcionamiento con la misma capacidad.

• WEIGHTED_ROUND_ROBIN política de localidad de balanceo de carga. La política de localidad de balanceo de carga del servicio de backend debe ser WEIGHTED_ROUND_ROBIN. Con esta configuración, el balanceador de carga también usa las métricas personalizadas para seleccionar la instancia o el endpoint óptimos del backend para atender la solicitud.

Configurar métricas personalizadas

Para que tus balanceadores de carga de aplicaciones puedan usar métricas personalizadas, haz lo siguiente:

1. Determina las métricas personalizadas que quieras usar.
2. Configura los back-ends para que envíen métricas personalizadas al balanceador de carga. Debes establecer un flujo de datos que se pueda enviar al balanceador de carga para usarlo en el balanceo de carga. Estas métricas deben compilarse y codificarse en un informe de carga de ORCA y, a continuación, enviarse al balanceador de carga mediante encabezados de respuesta HTTP.
3. Configure el balanceador de carga para que use los valores de métricas personalizadas que comunican los back-ends.

Determinar las métricas personalizadas

Este paso es muy subjetivo y depende de las necesidades de tus aplicaciones. Una vez que haya determinado qué métricas quiere usar, también debe determinar el umbral de utilización máximo de cada métrica. Por ejemplo, si quieres usar la utilización de memoria como métrica, también debes determinar el umbral máximo de utilización de memoria de cada backend.

Antes de configurar el balanceador de carga, consulte los tipos de métricas personalizadas que tiene a su disposición (reservadas y con nombre) y los requisitos para seleccionar métricas, que se describen en la sección Cómo funcionan las métricas personalizadas de esta página.

Configurar backends para que envíen métricas al balanceador de carga

Las métricas personalizadas se envían a los balanceadores de carga como parte de cada respuesta HTTP de los back-ends de tu aplicación mediante el estándar ORCA. En esta sección se explica cómo compilar las métricas personalizadas en un informe de carga de ORCA y cómo registrar estas métricas en cada encabezado de respuesta HTTP enviado al balanceador de carga.

Por ejemplo, si usas la codificación de texto HTTP, el encabezado debe informar de las métricas en el siguiente formato.

endpoint-load-metrics: TEXT BACKEND_METRIC_NAME_1=BACKEND_METRIC_VALUE_1,BACKEND_METRIC_NAME_2=BACKEND_METRIC_VALUE_2

Independientemente del formato de codificación que se utilice, asegúrese de quitar el prefijo orca. del nombre de la métrica al generar el informe de carga.

Aquí tienes un fragmento de código que muestra cómo añadir dos métricas personalizadas (customUtilA y customUtilB) a tus encabezados HTTP. En este fragmento de código se muestran tanto la codificación de texto HTTP nativa como la codificación en base64. Ten en cuenta que en este ejemplo se han codificado los valores de customUtilA y customUtilB solo para simplificar. El balanceador de carga recibe los valores de las métricas que has determinado que influyen en el balanceo de carga.

...
type OrcaReportType int

const (
        OrcaText OrcaReportType = iota
        OrcaBin
)

type HttpHeader struct {
        key   string
        value string
}

const (
        customUtilA = 0.2
        customUtilB = 0.4
)

func GetBinOrcaReport() HttpHeader {
        report := &pb.OrcaLoadReport{
                NamedMetrics: map[string]float64{"customUtilA": customUtilA, "customUtilB": customUtilB}}
        out, err := proto.Marshal(report)
        if err != nil {
                log.Fatalf("failed to serialize the ORCA proto: %v", err)
        }
        return HttpHeader{"endpoint-load-metrics-bin", base64.StdEncoding.EncodeToString(out)}
}

func GetHttpOrcaReport() HttpHeader {
        return HttpHeader{
                "endpoint-load-metrics",
                fmt.Sprintf("TEXT named_metrics.customUtilA=%.2f,named_metrics.customUtilB=%.2f",
                        customUtilA, customUtilB)}
}

func GetOrcaReport(t OrcaReportType) HttpHeader {
        switch t {
        case OrcaText:
                return GetHttpOrcaReport()
        case OrcaBin:
                return GetBinOrcaReport()
        default:
                return HttpHeader{"", ""}
        }
}
...

Configurar el balanceador de carga para que use métricas personalizadas

Para que el balanceador de carga use estas métricas personalizadas al seleccionar un backend, debe definir el modo de balanceo de cada backend como CUSTOM_METRICS. Además, si quieres que las métricas personalizadas también influyan en la selección de endpoints, define la política de localidad de balanceo de carga como WEIGHTED_ROUND_ROBIN.

En los pasos que se describen en esta sección se presupone que ya ha implementado un balanceador de carga con backends de NEG por zonas. Sin embargo, puedes usar las mismas marcas --custom-metrics que se muestran aquí para actualizar cualquier backend con el comando gcloud compute backend-services update.

1. Puedes definir el modo de balanceo de un backend como CUSTOM_METRICS cuando añadas el backend al servicio de backend. Usa la marca --custom-metrics para especificar tu métrica personalizada y el umbral que se usará para tomar decisiones de balanceo de carga.

   gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
       --network-endpoint-group=NEG_NAME \
       --network-endpoint-group-zone=NEG_ZONE \
       [--global | region=REGION] \
       --balancing-mode=CUSTOM_METRICS \
       --custom-metrics='name="BACKEND_METRIC_NAME_1",maxUtilization=MAX_UTILIZATION_FOR_METRIC_1' \
       --custom-metrics='name="BACKEND_METRIC_NAME_2",maxUtilization=MAX_UTILIZATION_FOR_METRIC_2'
   

   Haz los cambios siguientes:

   • BACKEND_SERVICE_NAME: el nombre del servicio de backend
   • NEG_NAME: el nombre del NEG por zonas o híbrido
   • NEG_ZONE: la zona en la que se creó el NEG
   • REGION: en el caso de los balanceadores de carga regionales, la región en la que se creó el balanceador de carga
   • BACKEND_METRIC_NAME: los nombres de las métricas personalizadas que se usan aquí deben coincidir con los nombres de las métricas personalizadas que se registran en el informe ORCA del backend.
   • MAX_UTILIZATION_FOR_METRIC: la utilización máxima que deben alcanzar los algoritmos de balanceo de carga para cada métrica.

   Por ejemplo, si sus back-ends registran dos métricas personalizadas, customUtilA y customUtilB (como se muestra en la sección Configurar back-ends para que registren métricas en el balanceador de carga), utilice el siguiente comando para configurar el balanceador de carga de forma que use estas métricas:

   gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
       --network-endpoint-group=NEG_NAME \
       --network-endpoint-group-zone=NEG_ZONE \
       [--global | region=REGION] \
       --balancing-mode=CUSTOM_METRICS \
       --custom-metrics='name="customUtilA",maxUtilization=0.8' \
       --custom-metrics='name="customUtilB",maxUtilization=0.9'
   

   También puede proporcionar una lista de métricas personalizadas en un archivo JSON estructurado:

   {
   "name": "METRIC_NAME_1",
   "maxUtilization": MAX_UTILIZATION_FOR_METRIC_1,
   "dryRun": true
   }
   {
   "name": "METRIC_NAME_2",
   "maxUtilization": MAX_UTILIZATION_FOR_METRIC_2,
   "dryRun": false
   }

   A continuación, adjunta el archivo de métricas en formato JSON al backend de la siguiente manera:

   gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
       --network-endpoint-group=NEG_NAME \
       --network-endpoint-group-zone=NEG_ZONE \
       [--global | region=REGION] \
       --balancing-mode=CUSTOM_METRICS \
       --custom-metrics-file='BACKEND_METRIC_FILE_NAME'
   

   Si quieres comprobar si se están registrando las métricas sin afectar al balanceador de carga, puedes definir la marca dryRun en true al configurar la métrica de la siguiente manera:

   gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
       --network-endpoint-group=NEG_NAME \
       --network-endpoint-group-zone=NEG_ZONE \
       [--global | region=REGION] \
       --balancing-mode=CUSTOM_METRICS \
       --custom-metrics 'name="BACKEND_METRIC_NAME",maxUtilization=MAX_UTILIZATION_FOR_METRIC,dryRun=true'
   

   Cuando una métrica se configura con dryRun definido como true, se informa a Monitoring, pero el balanceador de carga no la usa.

   Para revertir esta acción, actualiza el servicio de backend con la marca dryRun definida como false.

   gcloud compute backend-services update-backend BACKEND_SERVICE_NAME \
       --network-endpoint-group=NEG_NAME \
       --network-endpoint-group-zone=NEG_ZONE \
       [--global | region=REGION] \
       --balancing-mode=CUSTOM_METRICS \
       --custom-metrics 'name="BACKEND_METRIC_NAME",maxUtilization=MAX_UTILIZATION_FOR_METRIC_,dryRun=false'
   

   Si todas tus métricas personalizadas están configuradas con dryRun definido como true, al definir el modo de balanceo como CUSTOM_METRICS o la política de localidad del balanceo de carga como WEIGHTED_ROUND_ROBIN no se producirá ningún cambio en el balanceador de carga.

   Nota: Para ver otras marcas compatibles con el comando gcloud compute backend-services update-backend, como --clear-custom-metrics, consulta la página de referencia de gcloud compute backend-services update-backend.

2. Para configurar el balanceador de carga de forma que use las métricas personalizadas para influir en la selección de endpoints, define la política de localidad del balanceo de carga del servicio de backend como WEIGHTED_ROUND_ROBIN.

   Por ejemplo, si tienes un servicio de backend que ya está configurado con los backends adecuados, puedes configurar la política de localidad del balanceo de carga de la siguiente manera:

   gcloud compute backend-services update BACKEND_SERVICE_NAME \
       [--global | region=REGION] \
       --custom-metrics='name=BACKEND_SERVICE_METRIC_NAME,dryRun=false' \
       --locality-lb-policy=WEIGHTED_ROUND_ROBIN
   

   Como hemos visto antes con las métricas de nivel de backend, también puedes proporcionar una lista de métricas personalizadas en un archivo JSON estructurado a nivel de servicio de backend. Usa el campo --custom-metrics-file para adjuntar el archivo de métricas al servicio backend.

Siguientes pasos

• Solucionar problemas con los balanceadores de carga de aplicaciones externos
• Solucionar problemas con los balanceadores de carga de aplicaciones internos