Apache Pulsar démontre un rapport prix-performances cloud-natif de premier ordre – –

Nous assistons à un nombre croissant de projets d’entreprise où les données sont produites, consommées, analysées et traitées en temps réel. De cette façon, la technologie prend conscience de ce qui se passe à l’intérieur et autour d’elle, prenant elle-même des décisions pragmatiques et tactiques. Nous voyons cela se jouer dans les transports, la téléphonie, les soins de santé, la sécurité et l’application de la loi, la finance, la fabrication et dans la plupart des secteurs de chaque industrie.

Avant cette évolution, les ramifications analytiques inhérentes aux données étaient dérivées longtemps après que l’événement qui a produit ou créé les données soit passé. Nous pouvons désormais utiliser la technologie pour capturer, analyser et prendre des mesures en fonction de ce qui se passe sur le moment.

Cette catégorie de données est connue sous plusieurs noms : streaming, messagerie, flux en direct, temps réel et événementiel. Dans l’espace technologique de mise en file d’attente de données et de messages en continu, un certain nombre de technologies populaires sont utilisées, notamment Apache Kafka et Apache Pulsar ™.

En janvier, DataStax, connu pour son support commercial, ses logiciels et sa base de données en tant que service cloud pour Apache Cassandra™, a lancé une nouvelle ligne d’activité pour le streaming de données appelée Luna Streaming. DataStax Luna Streaming est un service d’abonnement basé sur Apache Pulsar open-source. En avril, DataStax a lancé une version bêta privée pour diffuser Pulsar en tant que service ciblant les ingénieurs de données, les ingénieurs logiciels et les architectes d’entreprise.

Nous avons récemment effectué un test de performances comparant les clusters Luna Streaming (Pulsar) et Kafka avec Kubernetes. Nous voulions voir si les avantages architecturaux inhérents à Pulsar (stockage hiérarchisé, calcul et stockage découplés, multilocation) permettaient une architecture efficace qui offre des avantages tangibles en termes de performances dans des scénarios réels.

Lire aussi  Dota 2 Invitational Tickets remboursés, 5 jours avant le début de l'événement

Nous avons déployé un cluster Kubernetes sur des instances Amazon Web Services EC2 et utilisé le faisceau de test OpenMessaging Benchmark (OMB) pour mener notre évaluation. Nous avons travaillé avec le fork Confluent de l’OpenMessaging Benchmark sur GitHub. Nous avons également utilisé les mêmes types d’instances de configuration matérielle pour les courtiers Kafka et pour co-localiser les courtiers Pulsar et les nœuds Bookkeeper afin de tirer parti des deux grands disques SSD NVMe rapides (2,5 To) connectés localement.

Pour Kafka, nous avons réparti le stockage de volume persistant sur les deux disques. Pour Pulsar, nous avons créé des volumes persistants et utilisé à la fois les disques locaux pour le grand livre Bookkeeper et l’autre pour les plages. Pour le journal Bookkeeper, nous avons provisionné un volume AWS Elastic Block Storage (EBS) de 100 Go gp3 avec 4 000 IOPS et un débit de 1 000 Mo/s. À part tirer parti de cette configuration de stockage pour les deux plates-formes, nous n’avons effectué aucun autre réglage spécifique de l’une ou l’autre plate-forme et avons préféré utiliser leurs configurations « prêtes à l’emploi » car elles ont été déployées via leurs images Docker et graphiques Helm respectifs. .

Nos tests de performances ont révélé que Luna Streaming avait un débit moyen plus élevé dans toutes les charges de travail de test OMB que nous avons effectuées. En termes d’équivalence de nœud de courtier, nous avons trouvé :

3 nœuds Luna Streaming @ 5 nœuds Kafka

6 nœuds Luna Streaming @ 8 nœuds Kafka

9 nœuds Luna Streaming @ 14 nœuds Kafka

Nous avons supposé une croissance linéaire simple des besoins en données de streaming d’une entreprise sur une période de trois ans : un « petit » cluster (3x Luna Streaming ou 5x Kafka) l’année 1, un « moyen » l’année 2 (6x Luna Streaming ou 8x Kafka) , et un “grand” (9x Luna Streaming ou 14x Kafka) au cours de l’année 3. En utilisant les équivalences de nœuds trouvées dans nos tests ci-dessus, cela entraînerait une économie de 33% sur les coûts d’infrastructure en utilisant Luna Streaming au lieu de Kafka.

Lire aussi  Des yeux Lego fabriquant des briques à partir de bouteilles en plastique recyclées

Dans ce scénario axé sur les charges de travail en « période de pointe », nous avons constaté une économie d’environ 50 %, selon le pourcentage de temps pendant lequel les périodes de pointe durent.

Pour notre troisième scénario de coût, nous nous sommes concentrés sur des projets qui peuvent avoir une complexité importante mais des exigences de débit brut limitées, résultant en un environnement organisationnel qui impose un grand nombre de sujets et de partitions pour gérer le large éventail de besoins dans l’ensemble de l’entreprise. Dans ce cas, nous avons constaté des économies d’infrastructure de 75 % en utilisant Luna Streaming sur Kafka.

Vous pouvez télécharger le rapport, avec une description complète des tests et des implications des résultats, ici.

.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Recent News

Editor's Pick