Si usas las métricas de Pub/Sub como señal para escalar automáticamente tu canalización, aquí tienes algunas recomendaciones.
Usar más de una señal para autoescalar tu flujo de procesamiento
No utilices solo métricas de Pub/Sub para autoescalar tu canalización. Esto puede dar lugar a situaciones en las que tengas un único punto de fallo para tus decisiones de escalado automático. En su lugar, usa una combinación de señales para activar el escalado automático. Un ejemplo de señal adicional es el nivel de utilización de la CPU del cliente. Esta señal puede indicar si las tareas del cliente están gestionando el trabajo y si el escalado puede permitir que las tareas del cliente gestionen más trabajo. A continuación, se muestran algunos ejemplos de señales de otros productos de Cloud que puedes usar en tu flujo de procesamiento:
Compute Engine admite el autoescalado basado en señales como el uso de CPU y las métricas de Monitoring. Compute Engine también admite varias métricas y señales para mejorar la fiabilidad.
Para obtener más información sobre el escalado con métricas de Monitoring, consulta Escalar según las métricas de Monitoring. Para obtener más información sobre el escalado según el uso de la CPU, consulta Escalar según el uso de la CPU.
El autoescalado horizontal de pods (HPA) de Google Kubernetes Engine admite el autoescalado basado en el uso de recursos, como el uso de CPU y memoria, métricas personalizadas de Kubernetes y métricas externas, como las métricas de Monitoring de Pub/Sub. También admite varias señales.
Para obtener más información, consulta Autoescalado horizontal de pods.
Usar 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 escalado automático. Asegúrate de usar las versiones con el sufijo by_region:
No uses las versiones globales de estas métricas si quieres 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 que se sabe que tienen mensajes, lo que significa que la falta de disponibilidad en una sola región provoca un vacío de datos. Por el contrario, las versiones by_region de las métricas calculan y registran la acumulación de trabajo por región. Si no se puede calcular el trabajo pendiente de una región, la métrica seguirá registrando valores de las demás regiones.
No utilices métricas de rendimiento del lado del suscriptor para escalar automáticamente los suscriptores
No utilices métricas de rendimiento del lado del suscriptor, como subscription/ack_message_count, para escalar automáticamente los clientes suscriptores. En su lugar, te recomendamos que uses métricas que reflejen directamente el trabajo pendiente de mensajes que están esperando a procesarse, como subscription/num_unacked_messages o subscription/oldest_unacked_message_age, que ya hemos mencionado.
Problemas al usar métricas de rendimiento del lado del suscriptor para el autoescalado
El uso de estas métricas puede causar problemas, ya que representan la cantidad de tráfico entre Pub/Sub y los suscriptores. El escalado basado en esta métrica puede crear un bucle autorreferencial en el que una disminución de los mensajes entregados o confirmados provoca una reducción de los clientes. Por ejemplo, esto puede ocurrir si hay un descenso temporal del tráfico o si hay un problema con uno de tus suscriptores.
Si tus clientes reducen su actividad a cero o casi cero, todo el tráfico de suscripción en curso puede detenerse y es posible que los suscriptores no puedan procesar mensajes, aunque lleguen mensajes nuevos. Esto puede provocar un retraso significativo en la ingesta y llevar a un estado irrecuperable para tus clientes suscriptores.
Gestionar las lagunas de métricas cuando se produzcan
No supongas que la ausencia de métricas significa que no hay mensajes que 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 pendientes o que se publiquen durante ese tiempo. Esto aumenta la latencia de extremo a extremo. Para minimizar la latencia, define un número mínimo de tareas superior a cero para que siempre estés preparado para gestionar los mensajes publicados, aunque las métricas recientes de Pub/Sub indiquen que la cola está vacía.
Tanto los escaladores automáticos de Compute Engine como los HPA de Google Kubernetes Engine se han diseñado para mantener el número de réplicas actual cuando las métricas no están disponibles. De esta forma, se 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 que faltan métricas.