Se você usa métricas do Pub/Sub como um indicador para escalonar automaticamente seu pipeline, confira algumas recomendações.
Usar mais de um indicador para escalonar automaticamente seu pipeline
Não use apenas métricas do Pub/Sub para escalonar automaticamente seu pipeline. Isso pode levar a cenários em que você tem um único ponto de falha para suas decisões de escalonamento automático. Em vez disso, use uma combinação de indicadores para acionar o escalonamento automático. Um exemplo de indicador adicional é o nível de utilização da CPU do cliente. Esse indicador pode indicar se as tarefas do cliente estão processando o trabalho e se o escalonamento vertical pode permitir que as tarefas do cliente processem mais trabalho. Confira alguns exemplos de indicadores de outros produtos do Cloud que podem ser usados no seu pipeline:
O Compute Engine oferece suporte ao escalonamento automático com base em indicadores, como utilização da CPU e métricas do Monitoring. O Compute Engine também oferece suporte a várias métricas e indicadores para melhorar a confiabilidade.
Para mais informações sobre o escalonamento com métricas do Monitoring, consulte Escalonar com base nas métricas do Monitoring. Para mais informações sobre o escalonamento com utilização da CPU, consulte Escalonar com base na utilização da CPU.
O escalonamento automático horizontal de pods (HPA, na sigla em inglês) do Google Kubernetes Engine oferece suporte ao escalonamento automático com base no uso de recursos, como uso da CPU e uso da memória, métricas personalizadas do Kubernetes e métricas externas, como métricas do Monitoring para o Pub/Sub. Ele também oferece suporte a vários indicadores.
Para mais informações, consulte Escalonamento automático horizontal de pods.
Usar a versão regional das métricas em vez de versões globais
O Pub/Sub oferece duas versões de cada métrica normalmente usada com o escalonamento automático. Use as versões com o sufixo by_region:
Não use as versões globais dessas métricas se quiser que o escalonamento automático seja resiliente a interrupções de região única. A versão global dessas métricas exige o cálculo do backlog em todas as regiões conhecidas por terem mensagens, o que significa que a indisponibilidade em uma única região resulta em uma lacuna de dados. Em contraste, as versões by_region das métricas calculam e informam o backlog por região. Se o backlog não puder ser calculado para uma única região, a métrica ainda informará valores para as outras regiões.
Evitar o uso de métricas de capacidade de processamento do assinante para escalonar automaticamente os assinantes
Evite usar métricas de capacidade de processamento do assinante, como subscription/ack_message_count, para escalonar automaticamente os clientes assinantes. Em vez disso, use métricas que reflitam diretamente o backlog de mensagens aguardando processamento, como subscription/num_unacked_messages ou subscription/oldest_unacked_message_age.
Problemas com o uso de métricas de capacidade de processamento do assinante para escalonamento automático
O uso dessas métricas pode causar problemas porque elas representam a quantidade de tráfego entre o Pub/Sub e os assinantes. O escalonamento com base nessa métrica pode criar um loop autorreferencial em que uma diminuição nas mensagens entregues ou confirmadas leva ao escalonamento horizontal dos clientes. Por exemplo, isso pode ocorrer se houver uma queda temporária no tráfego ou um problema com um dos seus assinantes.
Se os clientes reduzir escala vertical para zero ou quase zero, todo o tráfego de assinatura em andamento poderá parar, e os assinantes não poderão processar mensagens, mesmo que novas mensagens cheguem. Isso pode resultar em um atraso significativo na ingestão e levar a um estado irrecuperável para os clientes assinantes.
Lidar com lacunas de métricas quando elas ocorrem
Não suponha que a ausência de métricas significa que não há mensagens a serem processadas. Por exemplo, se, em resposta a métricas ausentes, você reduzir escala vertical as tarefas de processamento a zero, as mensagens já no backlog ou que forem publicadas durante esse período poderão não ser consumidas. Isso aumenta a latência de ponta a ponta. Para minimizar a latência, defina uma contagem mínima de tarefas maior que zero para estar sempre preparado para processar mensagens publicadas, mesmo que as métricas recentes do Pub/Sub indiquem uma fila vazia.
Os escalonadores automáticos do Compute Engine e os HPAs do Google Kubernetes Engine são projetados para manter a contagem de réplicas atual quando as métricas não estão disponíveis. Isso fornece uma rede de segurança se nenhuma métrica estiver disponível.
Também é possível implementar mecanismos de controle de fluxo do Pub/Sub para ajudar a evitar que as tarefas sejam sobrecarregadas se forem reduzidas involuntariamente devido a métricas ausentes.