Métricas personalizadas para balanceadores de carga de aplicativos

Nesta página, descrevemos como usar métricas personalizadas com os balanceadores de carga de aplicativo. Com as métricas personalizadas, é possível 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 métricas padrão de utilização ou com base em taxa do Google Cloud. Ao definir métricas personalizadas para seu balanceador de carga, você tem a flexibilidade de rotear solicitações de aplicativos para as instâncias e endpoints de back-end mais adequados à sua carga de trabalho.

No GKE, também é possível usar métricas personalizadas do serviço ou aplicativo em execução. Para mais detalhes, consulte Expor métricas personalizadas.

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

  1. Selecione qual grupo de instâncias de máquina virtual (VM) de back-end ou grupo de endpoints de rede vai receber o tráfego.
  2. Selecione qual instância de VM ou endpoint vai receber o 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 de critérios padrão, como afinidade regional ou latência de rede.

    Se os aplicativos tiverem latências de processamento de back-end na ordem de segundos, use a capacidade de computação global de forma mais eficiente balanceando as solicitações com base em métricas personalizadas em vez de latência de rede.

  • Maximize a eficiência de computação 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 resulta em uma distribuição desigual da carga. Nesse caso, talvez seja interessante definir uma métrica personalizada que equilibre a carga com base em uma combinação da taxa de solicitações e da utilização da CPU ou GPU para usar a frota de computação da maneira mais eficiente.

  • Faça o escalonamento automático dos 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 de back-end quando a métrica personalizada configurada exceder 80%. Isso é feito usando métricas de escalonamento automático baseado 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 determine quais são as métricas mais relevantes para seu aplicativo específico. Quando você sabe quais métricas quer usar, configure os back-ends para começar a informar um fluxo constante dessas métricas ao balanceador de carga.O Google Cloud permite informar métricas como parte do cabeçalho de cada resposta HTTP enviada dos back-ends ao 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 serviço de back-end, para influenciar a seleção de back-end (MIG ou NEG)
  • No nível do back-end, para influenciar a seleção de instâncias de VM ou endpoints

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

Determine quais métricas personalizadas influenciam as decisões de balanceamento de carga

Determinar quais métricas personalizadas influenciam 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 fazer o balanceamento de carga das solicitações com base em outras métricas personalizadas em vez de latências de rede padrão.

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

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

Há dois tipos de métricas personalizadas que você pode usar:

  • Métricas reservadas. Há cinco nomes de métricas reservados, que 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 ultrapassa o orçamento.

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

    orca.named_metrics.METRIC_NAME

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

    As métricas nomeadas definidas para o modo de balanceamento CUSTOM_METRICS precisam incluir valores no intervalo 0 - 100. As métricas nomeadas definidas para a política de localidade de balanceamento de carga WEIGHTED_ROUND_ROBIN nã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 de grupo de instâncias de VM de back-end ou grupo de endpoints de rede, especifique uma ou mais das seguintes métricas de utilização no relatório de carga do ORCA enviado ao balanceador de carga. orca.named_metrics é um mapa de métricas definidas pelo usuário na forma de pares 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 e influencie ainda mais a seleção da instância ou do endpoint da VM de back-end, forneça todas as métricas a seguir no relatório de carga do ORCA enviado ao balanceador de carga. O balanceador de carga usa ponderações calculadas com base nessas métricas informadas para atribuir carga a back-ends individuais.

  • orca.rps_fractional (solicitações 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 usuário no mapa orca.named_metrics

Limitações e requisitos

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

    Se duas métricas forem fornecidas, o balanceador de carga as tratará 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 backend estiver sendo executado em um nível de utilização alto em termos de custom-metric-util1, o balanceador de carga vai evitar enviar tráfego para esse backend. Em geral, 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 integridade 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 no máximo três métricas personalizadas. Esse limite não inclui as métricas obrigatórias orca.eps e orca.rps_fractional. 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 não podem ser acessadas por pessoas de fora da sua organização.

Codificações disponíveis para especificação de métrica personalizada

  • 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 código compatível com Protocol Buffers, esse é um protobuf OrcaLoadReport binário serializado codificado em base64 em endpoint-load-metrics-bin ou endpoint-load-metrics: BIN.

  • HTTP nativo

    Pares de chave-valor separados por vírgula 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 exige que as métricas sejam fornecidas usando metadados de rastreamento com a chave endpoint-load-metrics-bin.

Configuração de back-end para gerar relatórios de 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 do ORCA e informe os valores em cada cabeçalho de resposta HTTP enviado ao balanceador de carga.

Por exemplo, se você escolheu orca.cpu_utilization como uma métrica personalizada para um back-end, ele precisa informar a utilização atual da CPU ao balanceador de carga em cada resposta enviada a ele. 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 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 seus 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 para 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 WATERFALL_BY_REGION padrão tenta manter todos os back-ends em execução com a mesma capacidade.

  • WEIGHTED_ROUND_ROBIN política de localidade do balanceamento de carga. 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

Para permitir que os balanceadores de carga de aplicativo usem métricas personalizadas, faça o seguinte:

  1. Determine as métricas personalizadas que você quer usar.
  2. Configure os back-ends para gerar relatórios de métricas personalizadas ao balanceador de carga. É necessário estabelecer um fluxo de dados que possa ser enviado ao balanceador de carga para ser usado no balanceamento. Essas métricas precisam ser compiladas e codificadas em um relatório de carga do 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 personalizada informados pelos back-ends.

Determinar as métricas personalizadas

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

Antes de configurar o balanceador de carga, revise os tipos de métricas personalizadas disponíveis (reservadas e nomeadas) e os requisitos para seleção de métricas, que são descritos na seção Como as métricas personalizadas funcionam nesta página.

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.

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

Esta seção mostra como compilar as métricas personalizadas em um relatório de carga do ORCA e 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 seguinte formato.

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

Independente do formato de codificação usado, remova o prefixo orca. do nome da métrica ao criar o relatório de carga.

Confira um snippet de código que mostra 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. Este exemplo codifica os valores de customUtilA e customUtilB apenas para simplificar. O balanceador de carga recebe os valores das métricas que você determinou que influenciam 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 de 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 zonal. No entanto, é possível usar as mesmas flags --custom-metrics demonstradas aqui para atualizar qualquer back-end existente usando o comando gcloud compute backend-services update.

  1. É possível definir o modo de balanceamento de um back-end como CUSTOM_METRICS ao adicionar o back-end ao serviço de back-end. Use a flag --custom-metrics para especificar sua métrica personalizada e o limite a ser usado nas 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_SERVICE_NAME: o nome do serviço de back-end
    • NEG_NAME: o nome do NEG zonal ou híbrido
    • NEG_ZONE: a zona em que o NEG foi criado
    • REGION: para balanceadores de carga regionais, a região em que o balanceador de carga foi criado
    • BACKEND_METRIC_NAME: os nomes de métrica personalizada usados aqui precisam corresponder aos nomes de métrica personalizada 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 buscar 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 comando a seguir 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'

    Outra opção é 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 endpoints, 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 já 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 no 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