Métricas personalizadas para balanceadores de carga de aplicações

Esta página descreve como usar métricas personalizadas com os seus equilibradores de carga de aplicações. As métricas personalizadas permitem-lhe configurar o comportamento de distribuição de tráfego do seu equilibrador de carga com base em métricas específicas dos requisitos da sua aplicação ou infraestrutura, em vez das métricas de utilização padrão ou baseadas em taxas. Google CloudA definição de métricas personalizadas para o seu equilibrador de carga dá-lhe a flexibilidade de encaminhar pedidos de aplicações para as instâncias e os pontos finais de back-end mais adequados para a sua carga de trabalho.

Para o GKE, também pode usar métricas personalizadas provenientes do serviço ou da aplicação que está a executar. Para ver detalhes, consulte o artigo Exponha métricas personalizadas.

O balanceador de carga usa os valores das métricas personalizadas para tomar as seguintes decisões:

  1. Selecione o grupo de instâncias de máquinas virtuais (VMs) ou o grupo de pontos finais de rede de back-end que vai receber tráfego.
  2. Selecione a instância de VM ou o ponto final que vai receber tráfego.
Equilíbrio de carga com métricas personalizadas.
Equilíbrio de carga com métricas personalizadas (clique para aumentar).

Seguem-se alguns exemplos de utilização de métricas personalizadas:

  • Maximize a utilização da sua capacidade de computação global tomando decisões de equilíbrio de carga com base em métricas personalizadas mais relevantes para a sua aplicação, em vez dos critérios predefinidos, como a afinidade regional ou a latência da rede.

    Caso as suas aplicações tenham frequentemente latências de processamento de back-end na ordem dos segundos, pode usar a sua capacidade de computação global de forma mais eficiente equilibrando os pedidos de carga com base em métricas personalizadas, em vez da latência da rede.

  • Maximize a eficiência de computação tomando decisões de equilíbrio de carga com base em combinações de métricas exclusivas da sua implementação. Por exemplo, considere um cenário em que os seus pedidos têm tempos de processamento e requisitos de computação altamente variáveis. Neste cenário, o equilíbrio de carga baseado apenas na taxa de pedidos por segundo resulta numa distribuição de carga desigual. Nesse caso, é recomendável definir uma métrica personalizada que equilibre a carga com base numa combinação da taxa de pedidos e da utilização da CPU ou da GPU para usar a sua frota de computação da forma mais eficiente.

  • Crie uma escala automática de back-ends com base em métricas personalizadas mais relevantes para os requisitos da sua aplicação. Por exemplo, pode definir uma política de escalabilidade automática para escalar automaticamente as instâncias de back-end quando a métrica personalizada configurada exceder 80%. Isto é conseguido através da utilização de métricas de escala automática baseadas no tráfego (autoscaling.googleapis.com|gclb-capacity-fullness). Para mais informações, consulte o artigo Escala automática baseada no tráfego do equilibrador de carga.

Balanceadores de carga e back-ends suportados

As métricas personalizadas são suportadas para os seguintes equilibradores de carga de aplicações:

  • Balanceador de carga de aplicações externo global
  • Balanceador de carga de aplicações externo regional
  • Balanceador de carga de aplicações interno entre regiões
  • Balanceador de carga de aplicações interno regional

As métricas personalizadas são suportadas com os seguintes tipos de back-end:

  • Grupos de instâncias geridas
  • NEGs zonais (com GCE_VM_IP_PORT pontos finais)
  • NEGs de conetividade híbrida

Como funcionam as métricas personalizadas

Para permitir que o equilibrador de carga tome decisões de distribuição de tráfego com base em métricas personalizadas, tem de determinar primeiro quais são as métricas mais relevantes para a sua aplicação específica. Quando souber que métricas quer usar, configure os seus back-ends para começarem a comunicar um fluxo constante destas métricas ao equilibrador de carga. Google Cloud permite-lhe comunicar métricas como parte do cabeçalho de cada resposta HTTP enviada dos back-ends para o equilibrador de carga. Estas métricas estão encapsuladas num cabeçalho de resposta HTTP personalizado e têm de seguir a norma de agregação de custos de pedidos abertos (ORCA).

As métricas podem ser configuradas em dois níveis:

  • Ao nível do serviço de back-end, para influenciar a seleção de back-end (MIG ou NEG)
  • Ao nível do back-end, para influenciar a seleção de instâncias de VM ou pontos finais

As secções seguintes descrevem como funcionam as métricas personalizadas.

Determine que métricas personalizadas influenciam as decisões de equilíbrio de carga

Determinar que métricas personalizadas influenciam as decisões de equilíbrio de carga é altamente subjetivo e baseia-se nas necessidades das suas aplicações. Por exemplo, se as suas aplicações tiverem latências de processamento de back-end na ordem dos segundos, é recomendável equilibrar a carga dos pedidos com base noutras métricas personalizadas, em vez das latências de rede padrão.

Depois de determinar as métricas que quer usar, também tem de determinar o limite máximo de utilização para cada métrica. Por exemplo, se quiser usar a utilização de memória como uma métrica, também tem de determinar o limite máximo de utilização de memória para cada back-end.

Por exemplo, se configurar uma métrica denominada example-custom-metric, com o respetivo limite de utilização máximo definido como 0,8, o balanceador de carga ajusta dinamicamente a distribuição de tráfego entre os back-ends para manter a métrica example-custom-metric comunicada pelo back-end inferior a 0,8, tanto quanto possível.

Existem dois tipos de métricas personalizadas que pode usar:

  • Métricas reservadas. Existem cinco nomes de métricas reservados. Estes nomes estão reservados porque correspondem a campos predefinidos de nível superior na API ORCA.

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

    As métricas mem_utilization, cpu_utilization e application_utilization esperam valores no intervalo de 0.0 - 1.00, mas podem exceder 1.00 em cenários em que a utilização de recursos excede o orçamento.

  • Métricas com nome. Estas são métricas exclusivas da sua aplicação que especifica através do campo ORCA named_metrics no seguinte formato:

    orca.named_metrics.METRIC_NAME

    Todas as métricas personalizadas definidas pelo utilizador são especificadas através deste named_metrics mapa no formato de pares de nome e valor.

    As métricas com nome definidas para o modo de equilíbrio CUSTOM_METRICS têm de incluir valores no intervalo 0 - 100. As métricas com nome definidas para a política de localidade de equilíbrio de carga WEIGHTED_ROUND_ROBINnão têm um intervalo esperado.

Métricas obrigatórias

Para permitir que o balanceador de carga use métricas personalizadas para a seleção do grupo de instâncias de VM ou do grupo de pontos finais de rede de back-end, tem de especificar uma ou mais das seguintes métricas de utilização no relatório de carga da ORCA enviado para o balanceador de carga. orca.named_metrics é um mapa de métricas definidas pelo utilizador no formato de pares de nome/valor.

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

Além disso, para permitir que o balanceador de carga use métricas personalizadas para influenciar ainda mais a seleção da instância ou do ponto final da VM de back-end, tem de fornecer todas as seguintes métricas no relatório de carga da ORCA enviado para o balanceador de carga. O balanceador de carga usa ponderações calculadas a partir destas métricas comunicadas para atribuir carga a back-ends individuais.

  • orca.rps_fractional (pedidos por segundo)
  • orca.eps (erros por segundo)
  • Uma métrica de utilização com a seguinte ordem de precedência:
    1. orca.application_utilization
    2. orca.cpu_utilization
    3. Métricas definidas pelo utilizador no orca.named_metrics mapa

Limites e requisitos

  • Existe um limite de duas métricas personalizadas por back-end. No entanto, pode fazer testes dryRuncom um máximo de três métricas personalizadas.

    Se forem fornecidas duas métricas, o balanceador de carga trata-as de forma independente. Por exemplo, se definir duas dimensões: custom-metric-util1 e custom-metric-util2, o balanceador de carga trata-as de forma independente. Se um back-end estiver a ser executado a um nível de utilização elevado em termos de custom-metric-util1, o balanceador de carga evita enviar tráfego para este back-end. Geralmente, o balanceador de carga tenta manter todos os back-ends em execução com aproximadamente a mesma capacidade. A ocupação é calculada da seguinte forma: currentUtilization / maxUtilization. Neste caso, o equilibrador de carga usa o valor de preenchimento mais elevado comunicado pelas duas métricas para tomar decisões de equilíbrio de carga.

  • Existe um limite de duas métricas personalizadas por serviço de back-end. No entanto, pode fazer dryRun testes com um máximo de três métricas personalizadas. Este limite não inclui as métricas orca.eps e orca.rps_fractional obrigatórias. Este limite também é independente das métricas configuradas ao nível do back-end.

  • As métricas reservadas e as métricas com nome podem ser usadas em conjunto. Por exemplo, pode fornecer orca.cpu_utilization = 0.5 e uma métrica personalizada, como orca.named_metrics.queue_depth_util = 0.2, num único relatório de carregamento.

  • Os nomes das métricas personalizadas não podem conter informações regulamentadas, sensíveis, identificáveis nem outras informações confidenciais que não devem ser vistas por pessoas externas à sua organização.

Codificações disponíveis para a especificação de métricas personalizadas

  • JSON

    Exemplo de codificação JSON de um relatório de carregamento:

    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}}.

  • Binary Protobuf

    Para código compatível com buffers de protocolo, trata-se de um protobuf OrcaLoadReport codificado em base64 serializado binário em endpoint-load-metrics-bin ou em endpoint-load-metrics: BIN.

  • HTTP nativo

    Pares de chave-valor separados por vírgulas em endpoint-load-metrics. Esta é uma representação de texto simplificada do 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

    A especificação gRPC requer que as métricas sejam fornecidas através de metadados finais com a chave endpoint-load-metrics-bin.

Configuração de back-end para comunicar métricas personalizadas

Depois de determinar as métricas que quer que o balanceador de carga use, configure os seus back-ends para compilar as métricas personalizadas necessárias num relatório de carga ORCA e comunicar os respetivos valores em cada cabeçalho de resposta HTTP enviado para o balanceador de carga.

Por exemplo, se escolheu orca.cpu_utilization como uma métrica personalizada para um back-end, esse back-end tem de comunicar a utilização atual da CPU ao equilibrador de carga em cada resposta enviada ao equilibrador de carga. Para ver instruções, consulte a secção Comunique métricas ao equilibrador de carga nesta página.

Configuração do balanceador de carga para suportar métricas personalizadas

Para permitir que o balanceador de carga use os valores das métricas personalizadas comunicados pelos back-ends para tomar decisões de distribuição de tráfego, tem de definir o modo de balanceamento de cada back-end como CUSTOM_METRICS e definir a política de localidade do balanceamento de carga do serviço de back-end como WEIGHTED_ROUND_ROBIN.

Como funcionam as métricas personalizadas com os equilibradores de carga de aplicações.
Como funcionam as métricas personalizadas com os equilibradores de carga de aplicações (clique para aumentar).

  • CUSTOM_METRICS modo de equilíbrio. Cada um dos seus back-ends num serviço de back-end tem de ser configurado para usar o modo de equilíbrio de carga CUSTOM_METRICS. Quando um back-end está configurado com o modo de equilíbrio de carga CUSTOM_METRICS, o equilibrador de carga direciona o tráfego para os back-ends de acordo com o limite de utilização máximo configurado para cada métrica personalizada.

    Cada back-end pode especificar um conjunto diferente de métricas para comunicar. Se forem configuradas várias métricas personalizadas por back-end, o balanceador de carga tenta distribuir o tráfego de forma que todas as métricas permaneçam abaixo dos limites de utilização máximos configurados.

    O tráfego é balanceado de carga entre os back-ends com base no algoritmo de balanceamento de carga que escolher. Por exemplo, o algoritmo predefinido WATERFALL_BY_REGION tenta manter todos os back-ends em execução com a mesma capacidade.

  • WEIGHTED_ROUND_ROBIN política de localidade de balanceamento de carga. A política de localidade de equilíbrio de carga do serviço de back-end tem de estar definida como WEIGHTED_ROUND_ROBIN. Com esta configuração, o balanceador de carga também usa as métricas personalizadas para selecionar a instância ou o ponto final ideal no back-end para publicar o pedido.

Configure métricas personalizadas

Para permitir que os equilibradores de carga de aplicações usem métricas personalizadas, faça o seguinte:

  1. Determine as métricas personalizadas que quer usar.
  2. Configure os back-ends para comunicar métricas personalizadas ao equilibrador de carga. Tem de estabelecer uma stream de dados que possa ser enviada para o balanceador de carga para ser usada para o balanceamento de carga. Estas métricas têm de ser compiladas e codificadas num relatório de carregamento da ORCA e, em seguida, comunicadas ao equilibrador de carga através de cabeçalhos de resposta HTTP.
  3. Configure o balanceador de carga para usar os valores de métricas personalizadas comunicados pelos servidores de back-end.

Determine as métricas personalizadas

Este passo é altamente subjetivo com base nas necessidades das suas aplicações. Depois de determinar as métricas que quer usar, também tem de determinar o limite máximo de utilização para cada métrica. Por exemplo, se quiser usar a utilização de memória como uma métrica, também tem de determinar o limite máximo de utilização de memória para cada back-end.

Antes de avançar para a configuração do balanceador de carga, certifique-se de que reviu os tipos de métricas personalizadas disponíveis (reservadas e com nome) e os requisitos para a seleção de métricas, que são descritos na secção Como funcionam as métricas personalizadas nesta página.

Configure os back-ends para comunicarem métricas ao balanceador de carga

As métricas personalizadas são comunicadas aos balanceadores de carga como parte de cada resposta HTTP dos backends da sua aplicação através da norma ORCA.

Quando usa o Google Kubernetes Engine, também tem a opção de usar métricas personalizadas para balanceadores de carga.

Esta secção mostra como compilar as métricas personalizadas num relatório de carregamento do ORCA e comunicar estas métricas em cada cabeçalho de resposta HTTP enviado para o equilibrador de carga.

Por exemplo, se estiver a usar a codificação de texto HTTP, o cabeçalho tem de comunicar as métricas no seguinte formato.

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

Independentemente do formato de codificação usado, certifique-se de que remove o prefixo orca. do nome da métrica quando criar o relatório de carregamento.

Segue-se um fragmento de código que mostra como anexar duas métricas personalizadas (customUtilA e customUtilB) aos seus cabeçalhos HTTP. Este fragmento do código mostra a codificação de texto HTTP nativa e a codificação base64. Tenha em atenção que este exemplo codifica os valores de customUtilA e customUtilB apenas para simplificar. O equilibrador de carga recebe os valores das métricas que determinou que vão influenciar o equilíbrio 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{"", ""}
        }
}
...

Configure o equilibrador de carga para usar métricas personalizadas

Para que o equilibrador de carga use estas métricas personalizadas ao selecionar um back-end, tem de definir o modo de equilíbrio para cada back-end como CUSTOM_METRICS. Além disso, se quiser que as métricas personalizadas também influenciem a seleção de pontos finais, defina a política de localidade de equilíbrio de carga como WEIGHTED_ROUND_ROBIN.

Os passos descritos nesta secção pressupõem que já implementou um equilibrador de carga com back-ends NEG zonais. No entanto, pode usar as mesmas flags --custom-metrics demonstradas aqui para atualizar qualquer back-end existente usando o comando gcloud compute backend-services update.

  1. Pode definir o modo de balanceamento de um back-end como CUSTOM_METRICS quando adiciona o back-end ao serviço de back-end. Use a flag --custom-metrics para especificar a sua métrica personalizada e o limite a usar para decisões de equilíbrio 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'

    Substitua o seguinte:

    • BACKEND_SERVICE_NAME: o nome do serviço de back-end
    • NEG_NAME: o nome do NEG zonal ou híbrido
    • NEG_ZONE: a zona onde o NEG foi criado
    • REGION: para balanceadores de carga regionais, a região onde o balanceador de carga foi criado
    • BACKEND_METRIC_NAME: os nomes das métricas personalizadas usados aqui têm de corresponder aos nomes das métricas personalizadas comunicados pelo relatório ORCA do back-end
    • MAX_UTILIZATION_FOR_METRIC: a utilização máxima que os algoritmos de equilíbrio de carga têm de segmentar para cada métrica

    Por exemplo, se os seus back-ends estiverem a comunicar duas métricas personalizadas, customUtilA e customUtilB (conforme demonstrado na secção Configure back-ends to report metrics to the load balancer), use o seguinte comando para configurar o seu equilibrador de carga para usar 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'

    Em alternativa, pode fornecer uma lista de métricas personalizadas num ficheiro JSON estruturado:

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

    Em seguida, anexe o ficheiro de métricas no formato JSON ao back-end da seguinte forma:

    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'

    Se quiser testar se as métricas estão a ser comunicadas sem afetar realmente o equilibrador de carga, pode definir a flag dryRun como true ao configurar a métrica da seguinte forma:

    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'

    Quando uma métrica está configurada com dryRun definido como true, a métrica é comunicada à monitorização, mas não é realmente usada pelo balanceador de carga.

    Para reverter esta situação, atualize o serviço de back-end com a flag 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'

    Se todas as suas métricas personalizadas estiverem configuradas com dryRun definido como true, definir o modo de balanceamento como CUSTOM_METRICS ou a política de localidade de balanceamento de carga como WEIGHTED_ROUND_ROBIN não tem efeito no balanceador de carga.

  2. Para configurar o balanceador de carga para usar as métricas personalizadas para influenciar a seleção de pontos finais, defina a política de localidade de balanceamento de carga do serviço de back-end como WEIGHTED_ROUND_ROBIN.

    Por exemplo, se tiver um serviço de back-end já configurado com os back-ends adequados, configure a política de localidade de equilíbrio de carga da seguinte forma:

    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

    Conforme demonstrado anteriormente para as métricas ao nível do back-end, também pode fornecer uma lista de métricas personalizadas num ficheiro JSON estruturado ao nível do serviço de back-end. Use o campo --custom-metrics-file para anexar o ficheiro de métricas ao serviço de back-end.

O que se segue?