Si vous utilisez des métriques Pub/Sub comme signal pour effectuer l'autoscaling de votre pipeline, voici quelques recommandations.
Utiliser plusieurs signaux pour autoscaling votre pipeline
N'utilisez pas uniquement les métriques Pub/Sub pour l'autoscaling de votre pipeline. Cela peut entraîner des scénarios où vous avez un point de défaillance unique pour vos décisions d'autoscaling. Utilisez plutôt une combinaison de signaux pour déclencher l'autoscaling. Le niveau d'utilisation du processeur du client est un exemple de signal supplémentaire. Ce signal peut indiquer si les tâches client gèrent le travail et si l'ajustement à la hausse peut permettre aux tâches client de gérer davantage de travail. Voici quelques exemples de signaux provenant d'autres produits Cloud que vous pouvez utiliser pour votre pipeline:
Compute Engine (GCE) prend en charge l'autoscaling basé sur des signaux tels que l'utilisation du processeur et les métriques de surveillance. Compute Engine accepte également plusieurs métriques et plusieurs signaux pour une meilleure fiabilité.
Pour en savoir plus sur le scaling avec les métriques Monitoring, consultez la section Effectuer un scaling basé sur les métriques Monitoring. Pour en savoir plus sur le scaling en fonction de l'utilisation du processeur, consultez la page Effectuer un scaling basé sur l'utilisation du processeur.
L'autoscaling horizontal des pods (AHP, Horizontal Pod Autoscaling) de Google Kubernetes Engine (GKE) est compatible avec l'autoscaling basé sur l'utilisation des ressources, comme l'utilisation du processeur et de la mémoire, les métriques Kubernetes personnalisées et les métriques externes, comme les métriques de surveillance pour Pub/Sub. Il est également compatible avec plusieurs signaux.
Pour en savoir plus, consultez la section Autoscaling horizontal des pods.
Gérer les écarts de métriques lorsqu'ils se produisent
Ne partez pas du principe que l'absence de métriques signifie qu'il n'y a pas de messages à traiter. Par exemple, si vous réduisez les tâches de traitement à zéro en réponse à des métriques manquantes, les messages déjà dans la file d'attente ou publiés pendant cette période risquent de ne pas être consommés. Cela augmente la latence de bout en bout. Pour réduire la latence, définissez un nombre minimal de tâches supérieur à zéro afin d'être toujours prêt à gérer les messages publiés, même si les métriques Pub/Sub récentes indiquent une file d'attente vide.
Les autoscalers GCE et les HPA GKE sont conçus pour maintenir le nombre actuel de réplicas lorsque les métriques ne sont pas disponibles. Cela constitue une sécurité si aucune métrique n'est disponible.
Vous pouvez également implémenter des mécanismes de contrôle de flux Pub/Sub pour éviter que les tâches ne soient submergées si elles sont réduites de manière involontaire en raison de métriques manquantes.