Si vous utilisez les métriques Pub/Sub comme signal pour l'autoscaling de votre voici quelques recommandations.
Utiliser plusieurs signaux pour effectuer l'autoscaling de votre pipeline
N'utilisez pas uniquement les métriques Pub/Sub pour effectuer l'autoscaling de votre pipeline. Il peut conduire à des scénarios dans lesquels vous disposez d'un point de défaillance unique pour votre des décisions d'autoscaling. Utilisez plutôt une combinaison de signaux pour déclencher l'autoscaling. Un exemple de signal supplémentaire est le CPU du client et le niveau d'utilisation. Ce signal peut indiquer si les tâches du client sont 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) prend en charge l'autoscaling basé sur des signaux tels que Utilisation du processeur et métriques Monitoring. 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 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 (HPA, 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, telles que 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.
Comment combler les lacunes au niveau des métriques lorsqu'elles 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 effectuez un scaling à la baisse en réponse à des métriques manquantes les tâches de traitement à zéro, les messages déjà en attente ou publiés pendant cette période peuvent ne pas être utilisé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 de sont toujours prêts à 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 un filet de sécurité sont disponibles.
Vous pouvez également implémenter Mécanismes de contrôle de flux Pub/Sub pour éviter que les tâches ne soient submergées si elles sont involontairement réduit en raison de métriques manquantes.