Logo Zéphyrnet

Nexthink s'adapte à des milliards d'événements par jour avec Amazon MSK | Services Web Amazon

Date :

Le streaming de données en temps réel et le traitement des événements présentent des défis en matière d'évolutivité et de gestion. AWS propose une large sélection de services gérés services de streaming de données en temps réel pour exécuter sans effort ces charges de travail à n’importe quelle échelle.

Dans cet article, Nexthink explique comment Amazon Managed Streaming pour Apache Kafka (Amazon MSK) leur a permis d'atteindre une échelle massive dans le traitement des événements. Confronté à une hypercroissance commerciale, Nexthink a migré vers AWS pour surmonter les limites d'évolutivité des solutions sur site. Avec Amazon MSK, Nexthink traite désormais de manière transparente des milliards d'événements par jour, atteignant plus de 5 Go par seconde de débit agrégé.

Dans les sections suivantes, Nexthink présente son produit et le besoin d'évolutivité. Ils soulignent ensuite les défis de leur ancienne application sur site et présentent leur transition vers une architecture de logiciel en tant que service (SaaS) centrée sur le cloud et optimisée par Amazon MSK. Enfin, Nexthink détaille les avantages obtenus en adoptant Amazon MSK.

La nécessité d'évoluer de Nextink

Nexthink est le leader de l'expérience employé numérique (DeX). L'entreprise façonne l'avenir du travail en fournissant aux responsables informatiques et aux cadres dirigeants un aperçu des expériences technologiques quotidiennes des employés au niveau des appareils et des applications. Cela permet à l’informatique d’évoluer d’une résolution réactive de problèmes à une optimisation proactive.

La Plateforme Nextink Infinity combine l'analyse, la surveillance, l'automatisation et bien plus encore pour gérer l'expérience numérique des employés. En collectant les événements relatifs aux appareils et aux applications, en les traitant en temps réel et en les stockant, notre plateforme analyse les données pour résoudre les problèmes et améliorer l'expérience de plus de 15 millions d'employés sur cinq continents.

En seulement 3 ans, l'activité de Nexthink a été multipliée par dix et, avec l'introduction de davantage de données en temps réel, notre application a dû passer du traitement de 200 Mo par seconde à 5 Go par seconde et à des milliards d'événements par jour. Pour permettre cette croissance, nous avons modernisé notre application d'un monolithe sur site à locataire unique vers une solution SaaS évolutive basée sur le cloud et optimisée par Amazon MSK.

Les sections suivantes détaillent notre parcours de modernisation, y compris les défis auxquels nous avons été confrontés et les avantages que nous avons réalisés grâce à notre nouvelle architecture basée sur le cloud et basée sur AWS.

La solution sur site et ses enjeux

Explorons d'abord notre précédente solution sur site, Nexthink V6, avant d'examiner comment Amazon MSK a relevé ses défis. Le schéma suivant illustre son architecture.

Nextthink v6

La V6 était composée de deux applications Java et C++ monolithiques à locataire unique, étroitement couplées. Le portail était une application Java backend pour frontend, et le moteur principal était une application de base de données interne C++ en mémoire qui gérait également les connexions des appareils, l'ingestion de données, l'agrégation et les requêtes. En regroupant toutes ces fonctions, le moteur est devenu difficile à gérer et à améliorer.

Le V6 manquait également d’évolutivité. Prenant initialement en charge 10,000 300,000 appareils, certains nouveaux locataires disposaient de plus de 6 XNUMX appareils. Nous avons réagi en déployant plusieurs moteurs VXNUMX par locataire, augmentant ainsi la complexité et les coûts, entravant l'expérience utilisateur et retardant la mise sur le marché. Cela a également conduit à des cycles de validation de principe et d'intégration plus longs, ce qui a nui à l'entreprise.

De plus, l’absence d’une plateforme de streaming comme Kafka créait des dépendances entre les équipes grâce à un couplage HTTP/gRPC étroit. De plus, les équipes ne pouvaient pas accéder aux événements en temps réel avant leur ingestion dans la base de données, ce qui limitait le développement de fonctionnalités. Nous manquions également de tampon de données, ce qui risquait de perdre des données en cas de panne. De telles contraintes entravent l’innovation et augmentent les risques.

En résumé, bien que le système V6 ait rempli son objectif initial, le réinventer avec des technologies centrées sur le cloud est devenu impératif pour améliorer l'évolutivité, la fiabilité et favoriser l'innovation de nos équipes d'ingénierie et de produits.

Transition vers une architecture centrée sur le cloud avec Amazon MSK

Pour atteindre nos objectifs de modernisation, après des recherches et des itérations approfondies, nous avons mis en œuvre une conception de microservices événementiels sur Service Amazon Elastic Kubernetes (Amazon EKS), en utilisant Kafka sur Amazon MSK pour le stockage et le streaming d'événements distribués.

Notre transition de la solution v6 sur site vers la plateforme centrée sur le cloud s'est déroulée en quatre itérations :

  • Phase 1 – Nous sommes passés des machines sur site aux machines virtuelles dans le cloud, réduisant ainsi les complexités opérationnelles et accélérant les cycles de preuve de concept tout en migrant de manière transparente les clients.
  • Phase 2 – Nous avons étendu l'architecture cloud en implémentant de nouvelles fonctionnalités de produit avec des microservices et Kafka autogéré sur Kubernetes. Cependant, exploiter nous-mêmes les clusters Kafka s’est avéré trop difficile, ce qui nous a conduit à la phase 3.
  • Phase 3 – Nous sommes passés de Kafka autogéré à Amazon MSK, améliorant ainsi la stabilité et réduisant les coûts opérationnels. Nous avons réalisé que la gestion de Kafka n'était pas notre compétence principale ni notre différenciateur, et que les frais généraux étaient élevés. Amazon MSK nous a permis de nous concentrer sur notre application principale, nous libérant ainsi du fardeau d'une gestion indifférenciée de Kafka.
  • Phase 4 – Enfin, nous avons éliminé tous les composants existants, achevant ainsi la transition vers une plateforme SaaS entièrement centrée sur le cloud. Ce parcours pluriannuel d’apprentissage et de transformation a duré 3 ans.

Aujourd'hui, après notre transition réussie, nous utilisons Amazon MSK pour deux fonctions clés :

  • Ingestion de données en temps réel et traitement de milliards d'événements quotidiens provenant de plus de 15 millions d'appareils dans le monde, comme l'illustre la figure suivante.

Ingestion d'architecture Nexthink

  • Activer un système piloté par les événements qui dissocie les producteurs et les consommateurs de données, comme illustré dans la figure suivante.

Nexthink Architecture pilotée par les événements

Pour améliorer encore notre évolutivité et notre résilience, nous avons adopté un architecture basée sur les cellules en utilisant la large disponibilité d'Amazon MSK dans les régions AWS. Nous exploitons actuellement plus de 10 cellules, chacune représentant un déploiement régional indépendant de notre solution SaaS. Cette approche basée sur les cellules minimise la zone d'impact en cas de problèmes, répond aux exigences de résidence des données et permet une mise à l'échelle horizontale dans les régions AWS, comme illustré dans la figure suivante.

Cellules d'architecture Nextink

Avantages d'Amazon MSK

Amazon MSK a joué un rôle essentiel dans la mise en œuvre de notre conception basée sur les événements. Dans cette section, nous décrivons les principaux avantages que nous avons tirés de son adoption.

Résilience des données améliorée

Dans notre nouvelle architecture, les données des appareils sont transmises directement aux sujets Kafka dans Amazon MSK, ce qui offre une haute disponibilité et résilience. Cela garantit que les événements peuvent être reçus et stockés en toute sécurité à tout moment. Nos services consommant ces données héritent de la même résilience d'Amazon MSK. Si nos services d'ingestion backend sont confrontés à des perturbations, aucun événement n'est perdu, car Kafka conserve tous les messages publiés. Lorsque nos services reprennent, ils continuent le traitement de manière transparente là où ils s'étaient arrêtés, grâce à la sémantique du producteur de Kafka, qui permet de traiter les messages exactement une fois, au moins une fois ou au plus une fois en fonction des besoins de l'application.

Amazon MSK nous permet d'adapter la durée de conservation des données à nos besoins spécifiques, allant de quelques secondes à une durée illimitée. Cette flexibilité garantit une disponibilité ininterrompue des données à notre application, ce qui n'était pas possible avec notre architecture précédente. De plus, pour sauvegarder l'intégrité des données en cas d'erreurs de traitement ou de corruption, Kafka nous a permis de mettre en place un mécanisme de relecture des données, garantissant la cohérence et la fiabilité des données.

Mise à l'échelle organisationnelle

En adoptant une architecture basée sur les événements avec Amazon MSK, nous avons décomposé notre application monolithique en microservices sans état et faiblement couplés communiquant de manière asynchrone via des sujets Kafka. Cette approche a permis à notre organisation d'ingénierie de passer rapidement de seulement 4 à 5 équipes en 2019 à plus de 40 équipes et environ 350 ingénieurs aujourd'hui.

Le couplage lâche entre les éditeurs d'événements et les abonnés a permis aux équipes de se concentrer sur des domaines distincts, tels que l'ingestion de données, les services d'identification et les lacs de données. Les équipes pourraient développer des solutions indépendamment dans leurs domaines, en communiquant via des sujets Kafka sans couplage étroit. Cette architecture a accéléré le développement de fonctionnalités en minimisant le risque que de nouvelles fonctionnalités impactent celles existantes. Les équipes pourraient consommer efficacement les événements publiés par d’autres, offrant ainsi de nouvelles fonctionnalités plus rapidement tout en réduisant les dépendances entre les équipes.

La figure suivante illustre le flux de travail transparent d'ajout de nouveaux domaines à notre système.

Ajouter des domaines

De plus, la conception basée sur les événements a permis aux équipes de créer des services sans état qui pouvaient évoluer automatiquement de manière transparente en fonction des métriques MSK telles que les messages par seconde. Cette évolutivité basée sur les événements a éliminé le besoin d'une planification approfondie des capacités et d'efforts de mise à l'échelle manuelle, libérant ainsi du temps de développement.

En utilisant une architecture de microservices basée sur les événements sur Amazon MSK, nous avons atteint une agilité organisationnelle, une évolutivité améliorée et une innovation accélérée tout en minimisant les frais opérationnels.

Mise à l’échelle transparente de l’infrastructure

L'activité de Nexthink a décuplé en 3 ans et de nombreuses nouvelles fonctionnalités ont été ajoutées au produit, entraînant une augmentation substantielle du trafic de 200 Mo par seconde à 5 Go par seconde. Cette croissance exponentielle des données a été rendue possible par la robuste évolutivité d'Amazon MSK. Atteindre une telle échelle avec une solution sur site aurait été difficile et coûteux, voire irréalisable.

Tenter d’autogérer Kafka imposait des frais opérationnels inutiles sans apporter de valeur commerciale. Le faire fonctionner avec seulement 5 % du trafic actuel était déjà complexe et nécessitait deux ingénieurs. Aux volumes actuels, nous estimons avoir besoin de 6 à 10 employés dédiés, ce qui augmentera les coûts et détournera les ressources des priorités essentielles.

Capacités en temps réel

En canalisant toutes nos données via Amazon MSK, nous avons permis le traitement des événements en temps réel. Cela a débloqué des fonctionnalités telles que des alertes en temps réel, des déclencheurs basés sur des événements et des webhooks qui étaient auparavant inaccessibles. À ce titre, Amazon MSK a joué un rôle déterminant en facilitant notre architecture basée sur les événements et en favorisant des innovations percutantes.

Accès sécurisé aux données

En passant à notre nouvelle architecture, nous avons atteint nos objectifs en matière de sécurité et d’intégrité des données. Avec les ACL Kafka, nous avons appliqué des contrôles d'accès stricts, permettant aux consommateurs et aux producteurs d'interagir uniquement avec les sujets autorisés. Nous avons basé ces contrôles d'accès aux données granulaires sur des critères tels que le type de données, le domaine et l'équipe.

Pour faire évoluer en toute sécurité la gestion décentralisée des sujets, nous avons introduit des Définitions de ressources personnalisées (CRD) Kubernetes. Ces CRD ont permis aux équipes de gérer indépendamment leurs propres sujets, paramètres et ACL sans compromettre la sécurité.

Chiffrement Amazon MSK s'est assuré que les données restaient cryptées au repos et en transit. Nous avons également introduit une option Bring Your Own Key (BYOK), permettant le chiffrement au niveau de l'application avec les clés client pour tous les sujets mono-locataires et multi-locataires.

Observabilité améliorée

Amazon MSK nous a donné une grande visibilité sur nos flux de données. Le prêt à l'emploi Amazon Cloud Watch métrique Voyons la quantité et les types de données circulant à travers chaque sujet et cluster. Cela nous a aidé à quantifier l'utilisation des fonctionnalités de nos produits en suivant les volumes de données au niveau du sujet. Les métriques opérationnelles d'Amazon MSK ont permis une surveillance et un dimensionnement sans effort des clusters et des courtiers. Dans l'ensemble, la riche observabilité d'Amazon MSK a facilité les décisions basées sur les données concernant l'architecture et les fonctionnalités du produit.

Conclusion

Le parcours de Nexthink d'un monolithe sur site à un SaaS cloud a été rationalisé grâce à Amazon MSK, un service Kafka entièrement géré. Amazon MSK nous a permis d'évoluer de manière transparente tout en bénéficiant d'une fiabilité et d'une sécurité de niveau entreprise. En confiant la gestion de Kafka à AWS, nous pourrions rester concentrés sur notre cœur de métier et innover plus rapidement.

À l'avenir, nous prévoyons d'améliorer encore les performances, les coûts et l'évolutivité en adoptant les fonctionnalités Amazon MSK telles que stockage hiérarchisé ainsi que Types d'instances EC2 basées sur AWS Graviton.

Nous travaillons également en étroite collaboration avec l'équipe Amazon MSK pour préparer les fonctionnalités de service à venir. L'adoption rapide de nouvelles capacités nous aidera à rester à la pointe de l'innovation tout en continuant à développer notre activité.

Pour en savoir plus sur la façon dont Nexthink utilise AWS pour servir sa clientèle mondiale, explorez le Étude de cas Nexthink sur AWS. De plus, découvrez d'autres témoignages de clients avec Amazon MSK en visitant le Catégorie de blog Amazon MSK.


À propos des auteurs

Moe HaïdarMoe Haïdar est ingénieur principal et responsable des projets spéciaux au bureau CTO de Nexthink. Il est impliqué chez AWS depuis 2018 et est un contributeur clé à la transformation cloud de la plateforme Nexthink vers AWS. Il se concentre sur l'incubation et l'architecture de produits et de technologies, mais il aime également réaliser des activités pratiques pour maintenir ses connaissances technologiques pointues et à jour. Il contribue toujours largement à la base de code et aime s'attaquer à des problèmes complexes.
Simone PomataSimone Pomata est architecte de solutions senior chez AWS. Il travaille avec enthousiasme dans l’industrie technologique depuis plus de 10 ans. Chez AWS, il aide les clients à réussir chaque jour dans la création de nouvelles technologies.
Magdalena GargasMagdalena Gargas est un architecte de solutions passionné par la technologie et par la résolution des défis des clients. Chez AWS, elle travaille principalement avec des éditeurs de logiciels, les aidant à innover dans le cloud. Elle participe à des événements de l'industrie, partageant ses idées et contribuant à l'avancement du domaine de la conteneurisation.

spot_img

Dernières informations

spot_img