Se usar métricas do Pub/Sub como um sinal para ajustar automaticamente a escala do seu pipeline, seguem-se algumas recomendações.
Use mais do que um sinal para ajustar automaticamente a escala do seu pipeline
Não use apenas métricas do Pub/Sub para ajustar automaticamente a escala do pipeline. Pode levar a cenários em que tem um único ponto de falha para as suas decisões de ajuste automático de escala. Em alternativa, use uma combinação de sinais para acionar o ajuste de escala automático. Um exemplo de um sinal adicional é o nível de utilização da CPU do cliente. Este sinal pode indicar se as tarefas do cliente estão a processar trabalho e se o aumento da escala pode permitir que as tarefas do cliente processem mais trabalho. Seguem-se alguns exemplos de sinais de outros produtos na nuvem que pode usar para o seu pipeline:
O Compute Engine suporta a criação de uma escala automática com base em sinais como a utilização da CPU e as métricas de monitorização. O Compute Engine também suporta várias métricas e vários sinais para uma melhor fiabilidade.
Para mais informações sobre a escalabilidade com as métricas de monitorização, consulte o artigo Escale com base nas métricas de monitorização. Para mais informações sobre o escalamento com base na utilização da CPU, consulte o artigo Escale com base na utilização da CPU.
A escala automática horizontal de pods (HPA) do Google Kubernetes Engine suporta a escala automática com base na utilização de recursos, como a utilização da CPU e da memória, métricas personalizadas do Kubernetes e métricas externas, como as métricas de monitorização do Pub/Sub. Também suporta vários sinais.
Para mais informações, consulte o artigo Escala automática horizontal de pods.
Use a versão regional das métricas em vez das versões globais
O Pub/Sub oferece duas versões de cada métrica normalmente usada com o ajuste de escala automático. Certifique-se de que usa as versões com o sufixo by_region:
Não use as versões globais destas métricas se quiser que o dimensionamento automático seja resiliente a interrupções de uma única região. A versão global destas métricas requer o cálculo da acumulação em todas as regiões que se sabe terem mensagens, o que significa que a indisponibilidade numa única região resulta numa lacuna de dados. Por outro lado, as versões by_region das métricas calculam e comunicam
o backlog por região. Se não for possível calcular o atraso para uma única região, a métrica continua a comunicar valores para as outras regiões.
Evite usar métricas de débito do lado do subscritor para ajustar automaticamente a escala dos subscritores
Evite usar métricas de débito do lado do subscritor, como
subscription/ack_message_count, para ajustar automaticamente a escala dos clientes subscritores. Em alternativa, considere usar métricas que reflitam diretamente a acumulação de mensagens à espera de processamento, como as mencionadas anteriormente subscription/num_unacked_messages ou subscription/oldest_unacked_message_age.
Problemas com a utilização de métricas de débito do lado do subscritor para a escala automática
A utilização destas métricas pode causar problemas, uma vez que representam a quantidade de tráfego entre o Pub/Sub e os subscritores. A escalabilidade com base nesta métrica pode criar um ciclo autorreferencial em que uma diminuição nas mensagens entregues ou confirmadas leva à redução da escala dos clientes. Por exemplo, isto pode ocorrer se houver uma diminuição temporária no tráfego ou se houver um problema com um dos seus subscritores.
Se os seus clientes forem reduzidos para zero ou quase zero, todo o tráfego de subscrição em curso pode parar e os subscritores podem não conseguir processar mensagens, mesmo que cheguem novas mensagens. Isto pode resultar num atraso significativo na ingestão e levar a um estado irrecuperável para os clientes subscritores.
Lidar com lacunas de métricas quando ocorrem
Não pressuponha que a ausência de métricas significa que não existem mensagens a processar. Por exemplo, se, em resposta a métricas em falta, reduzir as tarefas de processamento a zero, as mensagens já na fila de espera ou que são publicadas durante este período podem não ser consumidas. Isto aumenta a latência ponto a ponto. Para minimizar a latência, defina uma contagem mínima de tarefas superior a zero para estar sempre preparado para processar mensagens publicadas, mesmo que as métricas recentes do Pub/Sub indiquem uma fila vazia.
Os escaladores automáticos do Compute Engine e os HPAs do Google Kubernetes Engine foram concebidos para manter a contagem de réplicas atual quando as métricas não estão disponíveis. Isto oferece uma rede de segurança se não estiverem disponíveis métricas.
Também pode implementar mecanismos de controlo de fluxo do Pub/Sub para ajudar a evitar que as tarefas fiquem sobrecarregadas se forem reduzidas involuntariamente devido a métricas em falta.