Si vous utilisez des métriques Pub/Sub comme signal pour autoscaler votre pipeline, voici quelques recommandations.
Utiliser plusieurs signaux pour autoscaler votre pipeline
N'utilisez pas uniquement les métriques Pub/Sub pour autoscaler votre pipeline. Cela peut entraîner 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. Par exemple, le niveau d'utilisation du processeur du client est un signal supplémentaire. Ce signal peut indiquer si les tâches du client gèrent le travail et si la mise à l'échelle peut permettre aux tâches du 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 est compatible avec l'autoscaling basé sur des signaux tels que l'utilisation du processeur et les métriques Monitoring. Compute Engine est également compatible avec plusieurs métriques et signaux pour une fiabilité accrue.
Pour en savoir plus sur le scaling avec les métriques Monitoring, consultez Effectuer un scaling basé sur les métriques Monitoring. Pour en savoir plus sur le scaling basé sur l'utilisation du processeur, consultez Effectuer un scaling basé sur l'utilisation du processeur.
L'autoscaling horizontal des pods (AHP, Horizontal Pod Autoscaling) de Google Kubernetes Engine est compatible avec l'autoscaling basé sur l'utilisation des ressources (processeur et mémoire, par exemple), les métriques Kubernetes personnalisées et les métriques externes (métriques Monitoring pour Pub/Sub, par exemple). Il est également compatible avec plusieurs signaux.
Pour en savoir plus, consultez Autoscaling horizontal des pods.
Utilisez la version régionale des métriques plutôt que la version globale.
Pub/Sub propose deux versions de chaque métrique généralement utilisée avec l'autoscaling. Assurez-vous d'utiliser les versions avec le suffixe by_region :
N'utilisez pas les versions globales de ces métriques si vous souhaitez que votre autoscaling soit résilient aux pannes dans une seule région. La version mondiale de ces métriques nécessite de calculer le backlog dans toutes les régions connues pour avoir des messages, ce qui signifie qu'une indisponibilité dans une seule région entraîne un manque de données. En revanche, les versions by_region des métriques calculent et indiquent l'encours par région. Si le backlog ne peut pas être calculé pour une seule région, la métrique indique quand même des valeurs pour les autres régions.
Évitez d'utiliser les métriques de débit côté abonné pour l'autoscaling des abonnés
Évitez d'utiliser des métriques de débit côté abonné telles que subscription/ack_message_count pour effectuer l'autoscaling des clients abonnés. Utilisez plutôt des métriques qui reflètent directement le backlog de messages en attente de traitement, comme subscription/num_unacked_messages ou subscription/oldest_unacked_message_age mentionnés précédemment.
Problèmes liés à l'utilisation des métriques de débit côté abonné pour l'autoscaling
L'utilisation de ces métriques peut poser problème, car elles représentent la quantité de trafic entre Pub/Sub et les abonnés. La mise à l'échelle basée sur une telle métrique peut créer une boucle autoréférentielle dans laquelle une diminution des messages distribués ou reconnus entraîne une réduction du nombre de clients. Par exemple, cela peut se produire en cas de baisse temporaire du trafic ou de problème avec l'un de vos abonnés.
Si vos clients sont réduits à zéro ou presque, tout le trafic d'abonnement en cours peut s'arrêter, et les abonnés peuvent ne pas être en mesure de traiter les messages, même si de nouveaux messages arrivent. Cela peut entraîner un décalage important au niveau de l'ingestion et un état irrécupérable pour vos clients abonnés.
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 les tâches de traitement à zéro en réponse à des métriques manquantes, il est possible que les messages déjà en attente ou publiés pendant cette période ne soient 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 à traiter les messages publiés, même si les métriques Pub/Sub récentes indiquent une file d'attente vide.
Les autoscalers Compute Engine et les HPA Google Kubernetes Engine sont conçus pour maintenir le nombre actuel de répliques lorsque les métriques ne sont pas disponibles. Cela permet de disposer d'une solution de secours 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 surchargées si elles sont involontairement réduites en raison de métriques manquantes.