Si vous utilisez des métriques Pub/Sub comme signal pour l'autoscaling de votre pipeline, voici quelques recommandations.
Utiliser plusieurs signaux pour l'autoscaling de votre pipeline
N'utilisez pas que les métriques Pub/Sub pour effectuer l'autoscaling de votre pipeline. Cela peut conduire à des scénarios dans lesquels vous disposez d'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 du client traitent le travail et si le scaling à la hausse peut permettre aux tâches du client de gérer plus de travail. Voici quelques exemples de signaux provenant d'autres produits Cloud que vous pouvez utiliser pour votre pipeline:
Compute Engine (GCE) est compatible avec l'autoscaling basé sur des signaux tels que l'utilisation du processeur et les métriques Monitoring. Compute Engine accepte également plusieurs métriques et signaux pour une meilleure fiabilité.
Pour en savoir plus sur le scaling avec les métriques Monitoring, consultez la page 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 Scaling basé sur l'utilisation du processeur.
L'autoscaling horizontal des pods (AHP) de Google Kubernetes Engine (GKE) est compatible avec l'autoscaling basé sur l'utilisation des ressources, telles que l'utilisation du processeur et de la mémoire, les métriques Kubernetes personnalisées et les métriques externes telles que les métriques de surveillance pour Pub/Sub. Il accepte également plusieurs signaux.
Pour en savoir plus, consultez la section Autoscaling horizontal des pods.
Comment 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 aucun message à traiter. Par exemple, si vous réduisez à zéro les tâches de traitement en réponse à des métriques manquantes, les messages déjà en attente ou publiés au cours de cette période ne sont pas consommés. Cela augmente la latence de bout en bout. Pour minimiser 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 conserver le nombre d'instances répliquées actuel lorsque les métriques ne sont pas disponibles. Cela constitue un filet de sécurité si aucune métrique n'est disponible.
Vous pouvez également mettre en œuvre des mécanismes de contrôle de flux Pub/Sub pour éviter que les tâches ne soient surchargées si elles sont involontairement réduites à l'échelle en raison de métriques manquantes.