Une solution sans serveur sans code / bas code pour le traitement de flux

Le traitement par flux est un mécanisme permettant de traiter une très grande quantité de données en temps réel. Par exemple, imaginez une compagnie d'assurance automobile qui souhaite facturer à son client la distance parcourue quotidiennement, vous devrez traiter de nombreuses données de localisation à partir d'une énorme flotte de véhicules.

Ou imaginez un pays qui souhaite mettre en place un Système de diagnostic COVID-19 basé sur les symptômes signalés en temps réel.

Ce type de traitement est devenu standardisé et très accessible grâce à des piles technologiques comme Kafka ainsi qu'à des offres sans serveur de fournisseurs de cloud.

Par exemple, Amazon Kinesis est un service de streaming de données en temps réel évolutif et durable. Pour plus d'informations, voir Amazon Kinesis Data Streams .

Corticon.js est un moteur de règles sans code / low-code et cloud natif qui permet aux utilisateurs professionnels de créer des services de décision pouvant être déployés sans serveur. les fonctions. En savoir plus sur Corticon.js ici .

Dans ce blog, nous verrons comment la combinaison de ces deux technologies vous offre de grands avantages. Nous utiliserons, à titre d'exemple, un service de décision qui traite les dossiers des patients de soins de santé pour déterminer à la fois la probabilité qu'une personne ait le COVID-19 ainsi que le niveau de risque du patient et, sur la base de ces résultats, notifier, en temps réel, un fournisseur de soins de santé. [19659007] Pourquoi utiliseriez-vous ces deux technologies?

Il y a plusieurs raisons, entre autres:

1. Le débit des données entrantes est élevé et variable. Il y aura des rafales lorsque de nombreux dossiers de patients arriveront et à d'autres moments, le taux ralentira. Le flux Kinesis se chargera de recevoir les enregistrements et de les rendre disponibles pour le traitement des décisions. Si beaucoup de données arrivent et que le backend ne peut pas les traiter immédiatement, le flux stockera les enregistrements automatiquement pour vous.
2. Le traitement des données est découplé de l'écriture des données dans le flux (également appelée ingestion de données).
3. ] Plus important encore, vous voulez permettre aux spécialistes d’entreprise de créer et de maintenir les règles sur la façon de traiter les dossiers de santé, car le projet doit être prêt «hier» et votre backlog est déjà plus que complet.

   En utilisant une règle basée service de décision sans serveur sans code comme Corticon.js, vous gagnez en productivité car le processeur des enregistrements (le consommateur de flux dans le jargon Kinesis) est créé directement par le spécialiste métier.

4. Et surtout, vous gagnerez en agilité car le même utilisateur professionnel pourra ajuster les règles très rapidement au fur et à mesure que l'entreprise évoluera sans les allers-retours coûteux et chronophages qui sont typiques entre les utilisateurs professionnels et les programmeurs.

   Vous êtes en eeing vos précieuses ressources de programmation pour vous concentrer sur la sécurité et l'évolutivité de la solution.

5. Mais cela ne s'arrête pas là, vous gagnez encore plus d'agilité car l'utilisateur métier n'a pas besoin d'être formé à aucune des technologies cloud . Vous pouvez donc démarrer plus rapidement et sans frais supplémentaires. Nous verrons dans l'une des sections suivantes comment cela fonctionne.

À qui s'adresse ce blog?

Ce blog est destiné aux architectes et aux concepteurs d'applications cloud car il montre un modèle qui peut être utilisé pour améliorer l'actuel ou le futur architecture et conception du cloud. Il est également utile pour les intégrateurs de tels systèmes car nous comprendrons comment un service de décision sans code peut être intégré dans le traitement de flux.

Dans les sections suivantes, nous verrons à quel point il est simple de créer un flux de données et configurer un service de décision sans serveur à partir des règles.

Création du flux Kinesis

Il s'agit d'une tâche assez simple à partir de la console AWS.

Vous sélectionnez Kinesis dans la liste des services et cliquez sur le bouton Créer

Vous obtiendrez le formulaire suivant:

Ceci est où vous entrez un nom et un nombre de fragments que vous souhaitez configurer. Nous n'entrerons pas dans les détails des fragments ici, mais c'est essentiellement là que vous configurerez le débit maximal possible. Le nombre de fragments peut être ajusté après l'étape de création lorsque votre modèle de trafic change. Pour commencer, configurez simplement une partition.

Traitement des données du côté du consommateur

Un spécialiste de la santé a rédigé un ensemble de règles. Le premier ensemble calcule la probabilité que le patient ait COVID-19 sur la base des connaissances actuelles tandis que le second ensemble détermine si le patient a besoin d'une attention médicale immédiate en fonction de la probabilité, de l'âge et d'autres critères.

Ceci est illustré par le flux de règles Corticon.js suivant.

Et voici la feuille de règles ComputeDiagnosis:

Remarquez comment le spécialiste de la santé travaille simplement dans un tableur comme une interface pour:

1. Évaluer diverses conditions (panneau supérieur)
2. Agir en fonction de ces conditions (panneau du milieu)

Travailler avec une interface de feuille de calcul permet à la plupart des utilisateurs professionnels d'exprimer des règles simples à très complexes sans avoir à écrire une seule ligne de code.

De plus, vous remarquerez dans le troisième panneau (en bas), un ensemble d'énoncés de règles documentant l'entreprise

Ces instructions de règle seront générées lors de l'exécution et sont généralement utilisées à des fins d'audit ou de traçage. Dans notre exemple, nous les utilisons également comme contenu lorsque nous générons la notification au prestataire de soins.

Ces règles peuvent devenir assez compliquées et seraient difficiles à programmer correctement et rapidement si elles devaient être codées dans un langage de programmation normal. Il est plus simple, plus fiable et plus rapide de laisser le spécialiste de la santé créer les règles, les maintenir et les tester. Cela permet une bonne division du travail, l'intégrateur peut se concentrer sur la sécurisation de la solution et sa mise à l'échelle sans avoir à se soucier de l'implémentation et du test des règles elles-mêmes.

Nous sommes maintenant prêts à déployer les règles en tant que fonction AWS Serverless Lambda en un seul clic, comme indiqué ci-dessous:

Comme vous pouvez le constater, le même service de décision peut être regroupé pour un déploiement dans Azure ou Google cloud en tant que fonctions sans serveur . Et ici, vous voyez un avantage supplémentaire à utiliser Corticon.js: les auteurs de règles n'ont pas besoin de savoir quoi que ce soit sur les technologies cloud et d'être formés sur celles-ci, ils écrivent les règles indépendamment de l'endroit où ces règles s'exécuteront.

Ainsi vous gagner encore plus de productivité. Vous pouvez vous référer à ce blog https://www.progress.com/blogs/no-code-decision-services-for-serverless-mobile-and-browser-apps pour plus d'informations et notamment pour voir comment les services de décision peuvent également être exécutés d irectement dans l'interface (navigateur ou application mobile) pour fournir une interface utilisateur plus réactive.

Vous créez la fonction AWS Lambda et téléchargez le fichier zip généré comme indiqué dans l'écran ci-dessous.

Vous disposez maintenant d'un service de décision sans serveur prêt à évoluer et à gérer une charge énorme dans le flux de données. L'étape suivante consiste à configurer la manière dont Kinesis appellera ce service de décision:

Nous cliquons sur Ajouter un déclencheur dans la console de fonctions Lambda et sélectionnons «Kinesis analytics aws streaming», et sélectionnons le nom du flux dont nous voulons consommer les données. Nous cliquons sur Enregistrer et c'est tout – notre décision est prête.

En quelques clics, nous avons créé une solution hautement évolutive pour traiter les enregistrements.

Comprendre l'évolutivité de la solution – La vitesse de traitement du service de décision Enregistrements

Le service de décision sera appelé avec un ou plusieurs enregistrements à la fois. Vous avez le contrôle sur ce processus avec les deux paramètres intéressants suivants. La «Taille du lot» et la «Fenêtre du lot».

La «Taille du lot» spécifie le nombre maximum d'enregistrements que nous voulons traiter à la fois. Par exemple, dans l'écran ci-dessous, je spécifie 50. Lorsqu'un grand nombre de données est produit à la fois, mon service de décision ne sera pas appelé pour chaque enregistrement mais dès que 50 enregistrements se seront accumulés dans le fragment.

Maintenant, lorsque peu d'enregistrements sont poussés dans le flux, nous ne voulons peut-être pas attendre d'atteindre le seuil de 50 enregistrements. C’est là que la «fenêtre de lots» entre en jeu. Essentiellement, je peux spécifier, comme dans l'exemple ci-dessous, que lorsque 10 secondes se sont écoulées et que moins de 50 enregistrements ont été reçus, appelez de toute façon le service de décision avec le lot actuel d'enregistrements.

Il y a un cas supplémentaire à examiner . Disons que les producteurs mettent 50 enregistrements dans le flux en 100 ms, mais mon service de décision prend 280 ms pour les traiter. Les enregistrements de données s'accumuleront plus rapidement que la fonction de traitement ne peut gérer.

Cela peut ne pas être un problème dans tous les cas, vous pouvez être d'accord pour que le flux accumule les données et que la fonction rattrape quand il y a moins de trafic.

Mais si vous voulez traiter tous les enregistrements en temps réel , vous avez deux options ici:

1. Augmentez la mémoire allouée à la fonction lambda car vous obtiendrez un temps d'exécution plus rapide (environ deux fois plus rapide lorsque vous multipliez la taille de la mémoire par 2). Ainsi, dans notre cas, nous pourrions augmenter la taille de la mémoire de 128 à 512 et exécuter en moyenne le service de décision en 70 ms (280/4).
2. Il existe également un «paramètres avancés» dans l'interface utilisateur du déclencheur Kinesis appelé «Concurrent lots par partition. » Cela nous permet de contrôler le nombre de services de décision pouvant s'exécuter en parallèle. Encore une fois, dans notre cas, nous pourrions le régler sur 3.

Ajustement de la fonction Serverless

Comme nous venons de le voir, Kinesis appellera le service de décision avec un nombre variable d'enregistrements. Pour améliorer les performances du service en cours d'exécution, nous regrouperons tous les enregistrements que nous recevons sous une seule charge utile. Pour ce faire, utilisez le code JavaScript comme indiqué ci-dessous:

Conclusion

Comme vous pouvez le voir, dans quelques minutes, comme un intégrateur ou un architecte d'application, vous pouvez créer un flux en temps réel et vous connecter à un ensemble de services de décision prêts à traiter des enregistrements à très grande échelle. En tirant parti du moteur de règles sans code sans code de Corticon.js, vous pouvez permettre aux spécialistes métier de créer les services de décision; permettant à votre équipe de développement de se concentrer sur la sécurité et l'évolutivité de la solution.