Se você usa métricas do Pub/Sub como um sinal para fazer o escalonamento automático do 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 uso da CPU do cliente. Esse indicador pode indicar se as tarefas do cliente estão processando trabalho e se o escalonamento vertical pode permitir que elas 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 sinais 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 base na utilização da CPU, consulte Escalonamento baseado na utilização da CPU.
O escalonamento automático horizontal de pods (HPA) do Google Kubernetes Engine é compatível com o escalonamento automático com base no uso de recursos, como CPU e memória, métricas personalizadas do Kubernetes e métricas externas, como as do Monitoring para o Pub/Sub. Ele também é compatível com vários indicadores.
Para mais informações, consulte Escalonamento automático horizontal de pods.
Use a versão regional das métricas em vez das 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 uma única região. A versão global dessas métricas exige o cálculo do backlog em todas as regiões conhecidas por ter mensagens, o que significa que a indisponibilidade em uma única região resulta em uma lacuna de dados. Já 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 vai informar valores para as outras regiões.
Evite usar métricas de capacidade de transmissão do lado do assinante para escalonar automaticamente os assinantes
Evite usar métricas de capacidade de transmissão do lado do assinante, como
subscription/ack_message_count, para escalonar automaticamente os clientes assinantes. Em vez disso, use métricas que refletem diretamente o backlog de mensagens aguardando processamento, como subscription/num_unacked_messages ou subscription/oldest_unacked_message_age, mencionadas anteriormente.
Problemas ao usar métricas de capacidade de processamento do lado 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 à redução dos clientes. Por exemplo, isso pode acontecer se houver uma queda temporária no tráfego ou um problema com um dos seus inscritos.
Se os clientes reduzir escala vertical a zero ou quase zero, todo o tráfego de inscrição em andamento poderá ser interrompido, e os assinantes talvez não consigam 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 nas métricas quando elas ocorrem
Não suponha que a ausência de métricas significa que não há mensagens para processar. Por exemplo, se, em resposta a métricas ausentes, você reduzir escala vertical as tarefas de processamento para zero, as mensagens já na fila de espera ou 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 que você esteja 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 foram projetados para manter a contagem atual de réplicas quando as métricas não estão disponíveis. Isso oferece uma rede de segurança se nenhuma métrica estiver disponível.
Você também pode implementar mecanismos de controle de fluxo do Pub/Sub para evitar que as tarefas sejam sobrecarregadas se forem reduzidas involuntariamente devido a métricas ausentes.