Métricas personalizadas para balanceadores de carga de aplicativos

Esta página descreve como usar métricas personalizadas com os balanceadores de carga de aplicativo. Com as métricas personalizadas, você pode configurar o comportamento de distribuição de tráfego do balanceador de carga com base em métricas específicas dos requisitos de infraestrutura ou do aplicativo, em vez de utilizar as métricas de utilização padrão ou baseadas na taxa do Google Cloud. A definição de métricas personalizadas para o balanceador de carga oferece a flexibilidade de encaminhar solicitações de aplicativos para as instâncias e os endpoints de back-end mais adequados à sua carga de trabalho.

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

  1. Selecione qual grupo de instâncias de VM de back-end ou grupo de endpoints de rede deve receber tráfego
  2. Selecionar qual instância de VM ou endpoint vai receber tráfego
Balanceamento de carga com métricas personalizadas.
Balanceamento de carga com métricas personalizadas (clique para ampliar).

Confira alguns exemplos de casos de uso para métricas personalizadas:

  • Maximize o uso da sua capacidade de computação global tomando decisões de balanceamento de carga com base em métricas personalizadas mais relevantes para seu aplicativo, em vez dos critérios padrão, como afinidade regional ou latência de rede.

    Caso seus aplicativos tenham latências de processamento de back-end na ordem de segundos, use sua capacidade de computação global de maneira mais eficiente com solicitações de balanceamento de carga com base em métricas personalizadas, em vez de latência de rede.

  • Maximize a eficiência do processamento tomando decisões de balanceamento de carga com base em combinações de métricas exclusivas da sua implantação. Por exemplo, considere um cenário em que suas solicitações têm tempos de processamento e requisitos de computação altamente variáveis. Nesse cenário, o balanceamento de carga baseado apenas na taxa de solicitações por segundo resultaria em uma distribuição de carga desigual. Nesse caso, você pode definir uma métrica personalizada que equilibra a carga com base na taxa de solicitações e na utilização da CPU ou GPU para usar a frota de computação de maneira mais eficiente.

  • Escalonamento automático de back-ends com base em métricas personalizadas mais relevantes para os requisitos do seu aplicativo. Por exemplo, é possível definir uma política de escalonamento automático para escalonar automaticamente as instâncias do back-end quando a métrica personalizada configurada exceder 80%. Isso é feito usando métricas de escalonamento automático baseadas em tráfego (autoscaling.googleapis.com|gclb-capacity-fullness). Para mais informações, consulte Escalonamento automático baseado no tráfego do balanceador de carga.

Balanceadores de carga e back-ends compatíveis

As métricas personalizadas são compatíveis com os seguintes balanceadores de carga de aplicativo:

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

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

  • Grupos de instâncias gerenciadas
  • NEGs zonais (com endpoints GCE_VM_IP_PORT)
  • NEGs de conectividade híbrida

Como as métricas personalizadas funcionam

Para permitir que o balanceador de carga tome decisões de distribuição de tráfego com base em métricas personalizadas, primeiro é preciso determinar quais são as métricas mais relevantes para sua aplicação específica. Quando você souber quais métricas quer usar, configure os back-ends para começar a informar um fluxo constante dessas métricas para o balanceador de carga.O Google Cloud permite informar métricas como parte do cabeçalho de cada resposta HTTP enviada dos back-ends para o balanceador de carga. Essas métricas são encapsuladas em um cabeçalho de resposta HTTP personalizado e precisam seguir o padrão Open Request Cost Aggregation (ORCA).

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

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

As seções a seguir descrevem como as métricas personalizadas funcionam.

Determinar quais métricas personalizadas devem influenciar as decisões de balanceamento de carga

Determinar quais métricas personalizadas devem influenciar as decisões de balanceamento de carga é altamente subjetivo e baseado nas necessidades dos seus aplicativos. Por exemplo, se os aplicativos tiverem latências de processamento de back-end na ordem de segundos, talvez seja melhor balancear as solicitações com base em outras métricas personalizadas, em vez de latências de rede padrão.

Depois de determinar quais métricas você quer usar, também é necessário determinar o limite máximo de utilização de cada uma delas. Por exemplo, se você quiser usar a utilização de memória como métrica, também precisará determinar o limite máximo de utilização de memória para cada back-end.

Por exemplo, se você configurar uma métrica chamada example-custom-metric, com o limite de utilização máxima definido como 0,8, o balanceador de carga vai ajustar dinamicamente a distribuição de tráfego entre os back-ends para manter a métrica example-custom-metric informada pelo back-end abaixo de 0,8, sempre que possível.

Há dois tipos de métricas personalizadas:

  • Métricas reservadas. Há cinco nomes de métricas reservados. Esses nomes sã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

  • Métricas nomeadas: são métricas exclusivas do seu app que você especifica usando o campo ORCA named_metrics no seguinte formato:

    orca.named_metrics.METRIC_NAME

    Todas as métricas personalizadas definidas pelo usuário são especificadas usando este mapa named_metrics no formato de pares de nome e valor.

Métricas obrigatórias

Para permitir que o balanceador de carga use métricas personalizadas para a seleção de grupo de instâncias de VM de back-end ou de grupo de endpoints de rede, especifique pelo menos uma das métricas de utilização da lista a seguir no relatório de carga do ORCA enviado ao balanceador de carga:

  • orca.cpu_utilization ou
  • orca.application_utilization ou
  • orca.mem_utilization ou
  • orca.named_metrics, que é um mapa de métricas definidas pelo usuário na forma de pares de nome e valor.

Além disso, para permitir que o balanceador de carga use métricas personalizadas para influenciar ainda mais a seleção da instância de VM de back-end ou do endpoint, é necessário fornecer todas as métricas a seguir no relatório de carga ORCA enviado ao balanceador de carga. O balanceador de carga usa pesos calculados com base nessas métricas informadas para atribuir a carga a back-ends individuais.

  • orca.rps_fractional (solicitações por segundo),
  • orca.eps (erros por segundo) e
  • uma métrica de uso com a seguinte ordem de precedência:
    • orca.application_utilization
    • orca.cpu_utilization
    • métricas definidas pelo usuário no mapa orca.named_metrics

Observações adicionais:

  • Há um limite de duas métricas personalizadas por back-end. No entanto, é possível realizar testes dryRun com um máximo de três métricas personalizadas.

    Se duas métricas forem fornecidas, o balanceador de carga vai tratá-las de forma independente. Por exemplo, se você definir duas dimensões: custom-metric-util1 e custom-metric-util2, o balanceador de carga vai tratá-las de forma independente. Se um back-end estiver em execução com um alto nível de utilização em termos de custom-metric-util1, o balanceador de carga evita enviar tráfego para esse back-end. Geralmente, o balanceador de carga tenta manter todos os back-ends em execução com aproximadamente a mesma capacidade. A plenitude é calculada como currentUtilization / maxUtilization. Nesse caso, o balanceador de carga usa o maior dos dois valores de plenitude informados pelas duas métricas para tomar decisões de balanceamento de carga.

  • Há um limite de duas métricas personalizadas por serviço de back-end. No entanto, é possível realizar testes dryRun com um máximo de três métricas personalizadas. Esse limite não inclui as métricas orca.eps e orca.rps_fractional necessárias. Esse limite também é independente das métricas configuradas no nível do back-end.

  • As métricas reservadas e nomeadas podem ser usadas juntas. Por exemplo, orca.cpu_utilization = 0.5 e uma métrica personalizada, como orca.named_metrics.queue_depth_util = 0.2, podem ser fornecidas em um único relatório de carga.

  • Os nomes de métricas personalizadas não podem conter informações regulamentadas, sensíveis, identificáveis ou outras informações confidenciais que qualquer pessoa externa à sua organização não possa acessar.

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

  • JSON

    Exemplo de codificação JSON de um relatório 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 binário

    Para o código compatível com Protocol Buffers, este é 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 do gRPC exige que as métricas sejam fornecidas usando metadados finais com a chave endpoint-load-metrics-bin.

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

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

Por exemplo, se você escolher orca.cpu_utilization como uma métrica personalizada para um back-end, esse back-end precisa informar a utilização atual da CPU ao balanceador de carga em cada pacote enviado. Para instruções, consulte a seção Informar métricas ao balanceador de carga nesta página.

Configuração do balanceador de carga para oferecer suporte a métricas personalizadas

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

Como as métricas personalizadas funcionam com os balanceadores de carga de aplicativo.
Como as métricas personalizadas funcionam com os balanceadores de carga de aplicativo (clique para ampliar).

  • Modo de balanceamento CUSTOM_METRICS. Cada um dos back-ends em um serviço de back-end precisa ser configurado para usar o modo de balanceamento CUSTOM_METRICS. Quando um back-end é configurado com o modo de balanceamento CUSTOM_METRICS, o balanceador de carga direciona o tráfego para os back-ends de acordo com o limite máximo de utilização configurado para cada métrica personalizada.

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

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

  • Política de localidade do balanceamento de carga WEIGHTED_ROUND_ROBIN. A política de localidade de balanceamento de carga do serviço de back-end precisa ser definida como WEIGHTED_ROUND_ROBIN. Com essa configuração, o balanceador de carga também usa as métricas personalizadas para selecionar a instância ou o endpoint ideal no back-end para atender à solicitação.

Configurar métricas personalizadas

Siga as etapas abaixo para permitir que os balanceadores de carga de aplicativo tomem decisões de balanceamento de carga com base em métricas personalizadas:

  1. Determine as métricas personalizadas que você quer usar.
  2. Configure os back-ends para informar métricas personalizadas ao balanceador de carga. Você precisa estabelecer um fluxo de dados que possa ser enviado ao balanceador de carga para ser usado nas decisões de balanceamento de carga. Essas métricas precisam ser compiladas e codificadas em um relatório de carga ORCA e, em seguida, informadas ao balanceador de carga usando cabeçalhos de resposta HTTP.
  3. Configure o balanceador de carga para usar os valores de métrica personalizados informados pelos back-ends.

Determinar as métricas personalizadas

Essa etapa é altamente subjetiva e depende das necessidades dos seus próprios aplicativos. Depois de determinar quais métricas você quer usar, também é necessário determinar o limite máximo de utilização de cada uma delas. Por exemplo, se você quiser usar a utilização de memória como métrica, também precisará determinar o limite máximo de utilização de memória para cada back-end.

Antes de continuar a configurar o balanceador de carga, revise os tipos de métricas personalizadas disponíveis (reservadas e nomeadas) e os requisitos para a seleção de métricas na seção Como as métricas personalizadas funcionam.

Configurar back-ends para informar métricas ao balanceador de carga

As métricas personalizadas são informadas aos balanceadores de carga como parte de cada resposta HTTP dos back-ends do aplicativo usando o padrão ORCA. Esta seção mostra como compilação das métricas personalizadas em um relatório de carga ORCA e como informar essas métricas em cada cabeçalho de resposta HTTP enviado ao balanceador de carga.

Por exemplo, se você estiver usando a codificação de texto HTTP, o cabeçalho precisará informar as métricas no formato a seguir.

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, remova o prefixo orca. do nome da métrica ao criar o relatório de carga.

Este é um snippet de código que demonstra como anexar duas métricas personalizadas (customUtilA e customUtilB) aos cabeçalhos HTTP. Este snippet de código mostra a codificação de texto HTTP nativa e a codificação base64. Observe que este exemplo codifica os valores de customUtilA e customUtilB apenas para simplificar. O balanceador de carga precisa receber os valores das métricas que você determinou para influenciar o balanceamento 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 o balanceador de carga para usar métricas personalizadas

Para que o balanceador de carga use essas métricas personalizadas ao selecionar um back-end, defina o modo de balanceamento para cada back-end como CUSTOM_METRICS. Além disso, se você quiser que as métricas personalizadas também influenciem a seleção de endpoints, defina a política de localidade de balanceamento de carga como WEIGHTED_ROUND_ROBIN.

As etapas descritas nesta seção pressupõem que você já implantou um balanceador de carga com back-ends de NEG zonais. No entanto, é possível usar as mesmas sinais --custom-metrics mostradas aqui para atualizar qualquer back-end usando o comando gcloud compute backend-services update.

  1. É possível definir o modo de balanceamento de um back-end como CUSTOM_METRICS ao adicioná-lo ao serviço de back-end. Use a flag --custom-metrics para especificar a métrica personalizada e o limite a ser usado para decisões de balanceamento 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:

    • BACKEND_METRIC_NAME: os nomes das métricas personalizadas usados aqui precisam corresponder aos nomes das métricas personalizadas que estão sendo informados pelo relatório ORCA do back-end.
    • MAX_UTILIZATION_FOR_METRIC: a utilização máxima que os algoritmos de balanceamento de carga devem atingir para cada métrica.

    Por exemplo, se os back-ends estiverem informando duas métricas personalizadas, customUtilA e customUtilB (conforme demonstrado na seção Configurar back-ends para informar métricas ao balanceador de carga), use o seguinte comando para configurar o balanceador de carga para usar essas 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'

    Como alternativa, você pode fornecer uma lista de métricas personalizadas em um arquivo 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 arquivo de métricas no formato JSON ao back-end da seguinte maneira:

    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 você quiser testar se as métricas estão sendo informadas sem afetar o balanceador de carga, defina a flag dryRun como true ao configurar a métrica da seguinte maneira:

    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 é configurada com dryRun definido como true, ela é informada ao Monitoring, mas não é usada pelo balanceador de carga.

    Para reverter isso, 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 terá efeito no balanceador de carga.

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

    Por exemplo, se você tiver um serviço de back-end que já esteja configurado com os back-ends adequados, configure a política de localidade de balanceamento de carga da seguinte maneira:

    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 demonstrado anteriormente para as métricas do nível do back-end, você também pode fornecer uma lista de métricas personalizadas em um arquivo JSON estruturado no nível do serviço de back-end. Use o campo --custom-metrics-file para anexar o arquivo de métricas ao serviço de back-end.

A seguir