Streaming qui change la donne : Apache Pulsar présente l'autoscaling

Apache Pulsar s'est toujours considéré comme natif du cloud. C'est juste là sur la page d'accueil :

"Apache® Pulsar™ est une plate-forme open source de messagerie et de streaming distribuée conçue pour le cloud"

Pulsar incarne certainement de nombreux principes natifs du cloud, y compris la séparation du calcul du stockage où le courtier Pulsar gère le service des messages et Apache BookKeeper gère leur stockage, et l'idée de composants sans état qui peuvent être augmentés et réduits à volonté comme le courtier Pulsar.

Cependant, il n'a jamais vraiment tenu la promesse ultime du cloud : l'autoscaling. Du moins, pas avant aujourd'hui.

Je suis ravi de vous présenter Kubernetes Autoscaling pour Apache Pulsar, ou KAAP. KAAP est un opérateur Kubernetes disponible sur OperatorHub. Il comprend toutes les subtilités que vous attendez d'un opérateur Kubernetes. Une fois que vous avez installé l'opérateur dans votre cluster Kubernetes, vous pouvez obtenir un cluster Pulsar entièrement fonctionnel en appliquant une seule définition de ressource personnalisée (CRD) comme ceci :

 apiVersion: kaap.oss.datastax.com/v1alpha1 kind: PulsarCluster metadata: name: pulsar spec: global: name: pulsar image: 'apachepulsar/pulsar:3.0.0'

Pulsar a plusieurs composants : ZooKeeper, BookKeeper, courtiers et mandataires. L'opérateur s'occupe de les configurer tous avec le PulsarCluster CRD. Étant donné que l'opérateur travaille au niveau du cluster, vous n'avez pas à vous soucier de la façon dont les composants fonctionnent ensemble. L'opérateur s'en charge pour vous.

Mises à niveau automatiques par étapes

Ayant exploité un service de cloud de production pour Pulsar plus longtemps que quiconque que je connaisse (d'abord à Kesque et maintenant avec DataStax Astra Streaming), je sais de première main combien de temps il faut pour effectuer une mise à niveau appropriée d'un cluster Pulsar. Bien que vous puissiez simplement mettre à niveau YOLO tous les composants à la fois, la méthode recommandée et la plus sûre consiste à mettre à niveau chaque composant un par un, en vous assurant que chaque composant a été mis à niveau avec succès avant de passer au suivant.

C'est le processus que nous suivons lors de la mise à niveau des clusters Pulsar dans notre service Astra Streaming car la disponibilité de notre service client est primordiale, mais cela prend beaucoup de temps pour notre équipe d'ingénierie de production. En fait, c'est la demande numéro un qu'ils ont : pouvez-vous rendre les mises à niveau plus intelligentes et plus automatiques ? Eh bien, avec KAAP, c'est exactement ce que nous avons fait.

Avec un seul changement de ligne dans le PulsarCluster CRD, vous pouvez déclencher une mise à niveau par étapes de votre cluster Pulsar. L'opérateur KAAP orchestrera une mise à niveau minutieuse et échelonnée de votre cluster. Bien sûr, vous devez surveiller les métriques lors de la mise à niveau, mais vous pouvez laisser l'opérateur KAAP conduire (pas de sommeil au volant).

Mise à l'échelle automatique open source

Les mises à niveau automatiques par étapes sont agréables, mais ce n'est pas ce qui me passionne le plus avec KAAP. Le concept de ressources élastiques est une promesse clé du cloud. C'est pourquoi de nombreux services AWS ont "élastique" dans leur nom. J'ai (en fait ChatGPT ) fait une recherche rapide et il y en a au moins 10.

Le cloud vous permet d'acquérir et de libérer des ressources à la demande, vous pouvez donc utiliser des techniques de mise à l'échelle automatique pour faire correspondre le nombre de ressources que votre application utilise à la charge qui y est associée. Au fur et à mesure que la charge augmente, vous pouvez automatiquement ajouter plus de ressources. Au fur et à mesure que la charge diminue, vous pouvez libérer des ressources. Étant donné que les fournisseurs de cloud facturent l'utilisation des ressources, l'autoscaling peut vous aider à tirer le meilleur parti de vos dépenses liées au cloud.

Je suis sûr que nous pouvons tous penser à des exemples de services cloud qui comportent une mise à l'échelle automatique dans les coulisses. La plupart de ces services AWS "élastiques" fonctionnent ainsi. Cependant, la mise en œuvre de l'autoscaling est propriétaire, verrouillée dans le référentiel privé d'un fournisseur. Parfois, ils parleront de la façon dont ils ont mis en œuvre l'autoscaling, comme dans ce papier sur AWS DynamoDB, ou ceci article de blog sur la façon dont Confluent Cloud rend Kafka élastique. Mais personne, à ma connaissance, n'a rendu son implémentation d'autoscaling open source, librement disponible pour tous les utilisateurs sous une licence véritablement open source. C'est exactement ce que nous faisons avec KAAP.

KAAP ajoute des capacités de mise à l'échelle automatique sophistiquées à votre Pulsar (ou Lune Streaming , notre distribution Pulsar) sous licence Apache 2.0. Vous pouvez le vérifier dans notre Référentiel GitHub . Si vous l'aimez, n'oubliez pas de lui donner une étoile.

Pulsar + mise à l'échelle automatique : une combinaison parfaite

KAAP vous permet d'ajouter l'autoscaling à Pulsar lors de l'exécution dans Kubernetes. Il ne s'agit pas d'un simple Horizontal Pod Autoscaler (HPA) ajouté à un déploiement de courtier Pulsar, mais d'un autoscaler sophistiqué qui fonctionne avec les composants cloud natifs existants de Pulsar pour fournir un système de streaming et de messagerie vraiment élastique. À mon avis, c'est une combinaison qui ne peut pas être battue.

Mise à l'échelle du courtier sans état

Examinons les deux principales dimensions d'autoscaling de KAAP. Tout d'abord, nous examinerons les courtiers Pulsar. Comme vous le savez peut-être, les courtiers Pulsar sont sans état, ce qui signifie que vous pouvez les augmenter et les réduire facilement, selon vos besoins. Mais ce que vous ne savez peut-être pas, c'est que Pulsar dispose d'un mécanisme d'équilibrage de charge de courtier intégré qui surveille en permanence le processeur, la mémoire et la bande passante réseau sur chaque courtier. En utilisant ces informations et l'un des algorithmes d'équilibrage de charge configurables, Pulsar déplacera les sujets d'un courtier à l'autre pour éviter qu'un courtier ne soit surchargé.

Une solution d'autoscaling naïve consisterait à configurer un Kubernetes Horizontal Pod Autoscaler (HPA) sur les courtiers et lorsque certaines métriques comme le CPU deviennent élevées, mettez à l'échelle un autre pod de courtier. Mais cela n'est peut-être pas nécessaire car l'équilibreur de charge du courtier Pulsar pourrait décider de déplacer les sujets pour égaliser la charge en même temps. Vous avez maintenant mis à l'échelle un pod de courtier qui n'est pas nécessaire car l'équilibreur de charge Pulsar a équilibré les choses. Alors maintenant, le HPA décide de réduire le nouveau module de courtier, ce qui entraîne le déplacement de tous les nouveaux sujets qui y ont été créés vers un courtier existant. Comme vous pouvez l'imaginer, l'équilibreur de charge Pulsar et un HPA peuvent créer un fouillis de courtiers qui montent et descendent et des sujets déplacés d'un courtier à l'autre.

KAAP évite ce problème en s'intégrant directement à l'équilibreur de charge Pulsar. KAAP fait évoluer les courtiers lorsque les métriques à l'échelle du cluster de l'équilibreur de charge Pulsar suggèrent que le cluster approche de la capacité, et non lorsqu'un seul pod de courtier est occupé. Et il ne réduit un courtier que si l'utilisation de l'ensemble du cluster tombe en dessous d'un seuil configuré. L'opérateur KAAP travaille avec l'équilibreur de charge du courtier Pulsar, et non contre lui.

Augmenter et réduire le stockage : remarquable !

La mise à l'échelle de la couche de calcul (ou de service) de Pulsar est excellente, mais ce n'est pas suffisant pour une véritable implémentation de mise à l'échelle automatique. Bien sûr, le nombre de messages (ou d'événements) à traiter peut varier dans le temps, mais qu'en est-il du nombre de messages à stocker ? Nous avons probablement tous dû faire face à un arriéré de messages en raison d'une défaillance d'un système en aval. Au fur et à mesure que la panne se prolonge, le stockage disponible sur le système de streaming commence à s'épuiser.

C'est un scénario où Pulsar et sa dépendance à BookKeeper brillent. Pour ajouter de la capacité de stockage à un cluster Pulsar, il suffit d'ajouter un nouveau nœud BookKeeper, affectueusement appelé « bookie ». Parce que le stockage BookKeeper est basé sur des segments de sujets et non sur des sujets entiers, le nouveau bookmaker est immédiatement disponible pour soulager la pression sur le stockage, avec tout rééquilibrage pénible des sujets ou toute autre intervention opérationnelle.

KAAP peut, bien sûr, gérer ce cas pour vous. Il surveille en permanence l'utilisation du disque des nœuds de bookmaker, et si le stockage disponible devient faible, il augmentera un nouveau nœud de bookmaker. Ce n'est pas si remarquable (du moins pour Pulsar). Il est assez simple d'ajouter un nouveau réplica dans Kubernetes, même s'il est avec état et soutenu par des volumes persistants. Mais qu'en est-il lorsque la panne est terminée et que l'arriéré est éliminé ? Êtes-vous maintenant coincé avec un nœud de bookmaker supplémentaire consommant des ressources dont vous n'avez plus vraiment besoin ?

Pas avec KAAP, tu ne l'es pas. Une fois que le stockage BookKeeper tombe en dessous d'un seuil configuré, l'opérateur KAAP orchestrera soigneusement la suppression du nœud de bookmaker inutile. Il le fait de manière très sûre, en s'assurant qu'aucun message n'est perdu et que le facteur de réplication requis est maintenu à tout moment. Par exemple, si vous avez configuré Pulsar pour conserver trois copies de chaque message (le quorum d'écriture et d'accusé de réception est égal à trois), KAAP interagit avec le BookKeeper pour copier les messages du bookmaker qui est réduit vers d'autres bookmakers afin de s'assurer qu'il y a au moins trois copies du message disponibles. Une fois que cela a été terminé avec succès, il procédera à la suppression du bookmaker inutile.

Avec KAAP, vous obtenez une mise à l'échelle automatique du stockage dans votre cluster Pulsar à la fois vers le haut et vers le bas afin que vous puissiez optimiser l'utilisation du stockage dans votre cluster et ne pas rester bloqué avec une capacité inactive après un incident de production malheureux. Je ne sais pas pour vous, mais je pense que c'est assez remarquable.

Outils de reconnaissance de zone et de migration

KAAP peut effectuer des mises à niveau par étapes et une mise à l'échelle intelligente de votre cluster Pulsar. Mais il y a plus. Pour exploiter un cluster hautement disponible dans un fournisseur de cloud, il est important de prendre en compte les zones de disponibilité (AZ). Si vous ne répartissez pas vos composants, en particulier BookKeeper, sur les zones de disponibilité, vous ne pourrez pas survivre à une panne AZ et fournir plusieurs neuf de disponibilité.

Heureusement, Pulsar possède d'excellentes capacités intégrées telles que la reconnaissance du rack pour prendre en charge les déploiements à haute disponibilité. La partie délicate est que pour le configurer correctement, vous devez à la fois configurer correctement Kubernetes avec la détection de zone et également configurer Pulsar. L'opérateur KAAP vous a couvert en introduisant le concept d'ensembles de ressources, qui vous permettent de regrouper les composants et de leur donner une connaissance du rack. L'opérateur KAAP appliquera automatiquement les configurations Kubernetes et Pulsar en fonction de votre configuration déclarative des ensembles de ressources. Les ensembles de ressources sont flexibles, vous permettant de prendre en charge une variété d'options de déploiement Pulsar.

Et que se passe-t-il si vous exécutez déjà votre Pulsar à l'aide d'un graphique Helm ou peut-être simplement de la magie manifeste de Kubernetes ? KAAP dispose d'un outil de migration pour vous aider. Vous pouvez faire pointer l'outil de migration vers votre déploiement Kubernetes Pulsar existant et il générera automatiquement une configuration CRD correspondante que vous pourrez utiliser pour que l'opérateur KAAP prenne en charge l'exploitation de votre cluster pour vous.

La pile KAAP

L'opérateur KAAP possède de nombreuses fonctionnalités intéressantes, turbocompressant votre cluster Pulsar habituel en une machine de mise à l'échelle automatique bien huilée et hautement disponible. Mais en tant que personne qui exploite des clusters Pulsar de production depuis longtemps, je sais qu'il existe de nombreuses autres considérations pour créer un cluster Pulsar de production, telles que la gestion, l'authentification et la surveillance des certificats TLS.

C'est pourquoi nous avons inclus ce que nous appelons la pile KAAP avec l'opérateur. Il s'agit d'une charte parapluie Helm qui installe l'opérateur KAAP ainsi que des outils de production critiques, notamment :

• Gestionnaire de certificats
• Cape de clé
• Pile Prométhée (Grafana)
• Tableaux de bord Pulsar Grafana

Ce sont des outils indispensables lors de l'exécution de nos clusters Pulsar de production et nous ne voulions pas vous laisser au sec, nous les avons donc tous rassemblés et intégrés dans un seul package pratique.

Pourquoi utiliser KAAP ?

Vous avez donc entendu parler de toutes les fonctionnalités intéressantes de Kubernetes Autoscaling pour Apache Pulsar. Vous pouvez créer un cluster Pulsar entier avec un seul CRD. Vous pouvez mettre vos mises à niveau sur pilote automatique et laisser l'opérateur KAAP effectuer des mises à niveau sécurisées et échelonnées. Vous pouvez automatiquement augmenter et réduire les courtiers Pulsar en fonction de l'équilibreur de charge du courtier Pulsar indiquant que les courtiers sont surchargés, et vous pouvez augmenter et réduire les nœuds BookKeeper (!) En toute sécurité en fonction des besoins de stockage de vos clusters. Vous pouvez facilement configurer votre cluster pour la prise en compte de la zone de disponibilité pour une haute disponibilité. Et il inclut même un outil de migration qui vous permet de passer facilement de votre ancien déploiement basé sur Helm à un déploiement turbo basé sur un opérateur KAAP.

Donc, beaucoup de fonctionnalités intéressantes, mais quels sont les avantages de KAAP ? J'en pense plusieurs :

• Configurez et exploitez facilement des clusters Pulsar hautement disponibles exécutés dans Kubernetes, ce qui réduit les efforts pour vous et vos équipes de production
• Simplifiez considérablement la mise à l'échelle de Pulsar pour répondre à l'évolution des demandes en adaptant automatiquement les ressources du cluster pour répondre à la demande
• Réduisez le coût total de possession d'un cluster Pulsar en éliminant le provisionnement pour les pics de charge ou le surprovisionnement à la suite d'incidents de production
• Évitez la dépendance vis-à-vis d'un fournisseur en utilisant toutes les technologies open source

À mon avis, la sortie de KAAP est un moment vraiment innovant dans le domaine du streaming et de la messagerie. Aucun autre projet open source ne combine la puissance de streaming et de messagerie d'Apache Pulsar avec la promesse ultime du cloud computing : une mise à l'échelle entièrement élastique et automatique. J'ai hâte que vous l'essayiez. Rejoignez les discussions GitHub dans notre référentiel et dites-nous ce que vous en pensez !

En savoir plus

Si vous souhaitez approfondir votre connaissance technique de KAAP, consultez cet article de blog . Vous pouvez trouver la documentation complète pour KAAP ici . Et ici est le référentiel GitHub.

Par Chris Bartholomew, DataStax