Si usas métricas de Pub/Sub como un indicador para ajustar automáticamente la escala de tu canalización, aquí tienes algunas recomendaciones.
Usa más de un indicador para ajustar automáticamente la escala de tu canalización
No uses solo las métricas de Pub/Sub para ajustar automáticamente la escala de tu canalización. Esto podría generar situaciones en las que tengas un solo punto de falla para tus decisiones de ajuste automático. En su lugar, usa una combinación de indicadores para activar el ajuste de escala automático. Un ejemplo de un indicador adicional es el nivel de uso de la CPU del cliente. Este indicador puede señalar si las tareas del cliente están procesando trabajo y si el aumento de la escala puede permitir que las tareas del cliente procesen más trabajo. Estos son algunos ejemplos de indicadores de otros productos de Cloud que puedes usar para tu canalización:
Compute Engine admite el ajuste de escala automático basado en indicadores como el uso de CPU y las métricas de Monitoring. Compute Engine también admite varias métricas y varios indicadores para una mayor confiabilidad.
Para obtener más información sobre el ajuste de escala con las métricas de Monitoring, consulta Ajusta la escala en función de las métricas de Monitoring. Para obtener más información sobre el ajuste de escala con el uso de CPU, consulta Ajusta la escala según el uso de CPU.
El ajuste de escala automático horizontal de Pods (HPA) de Google Kubernetes Engine admite el ajuste de escala automático basado en el uso de recursos, como el uso de CPU y memoria, las métricas personalizadas de Kubernetes y las métricas externas, como las métricas de Monitoring para Pub/Sub. También admite varios indicadores.
Para obtener más información, consulta Ajuste de escala automático horizontal de Pods.
Usa la versión regional de las métricas en lugar de las versiones globales
Pub/Sub ofrece dos versiones de cada métrica que se suele usar con el ajuste de escala automático. Asegúrate de usar las versiones con el sufijo by_region:
No uses las versiones globales de estas métricas si deseas que tu ajuste de escala automático sea resistente a las interrupciones de una sola región. La versión global de estas métricas requiere el cálculo del backlog en todas las regiones en las que se sabe que hay mensajes, lo que significa que la falta de disponibilidad en una sola región genera una brecha de datos. Por el contrario, las versiones by_region de las métricas calculan y registran el trabajo pendiente por región. Si no se puede calcular el backlog para una sola región, la métrica seguirá registrando valores para las demás regiones.
Evita usar métricas de capacidad de procesamiento del suscriptor para ajustar la escala automáticamente de los suscriptores
Evita usar métricas de rendimiento del cliente suscriptor, como subscription/ack_message_count, para ajustar la escala automáticamente de los clientes suscriptores. En su lugar, considera usar métricas que reflejen directamente la acumulación de mensajes que esperan ser procesados, como las métricas subscription/num_unacked_messages o subscription/oldest_unacked_message_age mencionadas anteriormente.
Problemas con el uso de métricas de capacidad de procesamiento del cliente para el ajuste de escala automático
El uso de estas métricas puede causar problemas porque representan la cantidad de tráfico entre Pub/Sub y los suscriptores. El ajuste de escala basado en esa métrica puede crear un bucle autorreferencial en el que una disminución en los mensajes entregados o confirmados genera una reducción en la escala de los clientes. Por ejemplo, esto puede ocurrir si hay una disminución temporal en el tráfico o si hay un problema con uno de tus suscriptores.
Si tus clientes se reducen a cero o cerca de cero, se puede detener todo el tráfico de suscripciones en curso, y es posible que los suscriptores no puedan procesar mensajes, incluso si llegan mensajes nuevos. Esto puede generar un retraso significativo en la transferencia y provocar un estado irrecuperable para los clientes suscriptores.
Cómo abordar las brechas en las métricas cuando se producen
No supongas que la ausencia de métricas significa que no hay mensajes para procesar. Por ejemplo, si, en respuesta a la falta de métricas, reduces las tareas de procesamiento a cero, es posible que no se consuman los mensajes que ya están en la lista de tareas pendientes o que se publiquen durante este tiempo. Esto aumenta la latencia de extremo a extremo. Para minimizar la latencia, establece un recuento mínimo de tareas superior a cero para que siempre estés preparado para controlar los mensajes publicados, incluso si las métricas recientes de Pub/Sub indican una cola vacía.
Tanto los escaladores automáticos de Compute Engine como los HPA de Google Kubernetes Engine están diseñados para mantener el recuento de réplicas actual cuando las métricas no están disponibles. Esto proporciona una red de seguridad si no hay métricas disponibles.
También puedes implementar mecanismos de control de flujo de Pub/Sub para evitar que las tareas se sobrecarguen si se reducen de forma involuntaria debido a la falta de métricas.