Rechercher

Real Time Applications : Les 12 questions clés que vous devez savoir répondre

Durant votre carrière de développeur ou architecte, vous serez surement confrontez à des problématiques d’applications en temps réel où la latence, le temps de réponse et le taux de traitement sont les premiers défis auxquels vous faites face.


#1 : Que comprenez-vous par les termes Application en Temps Réel (ATR), latence et taux de traitement?


Application en temps réel (ou ATR) est une application dans laquelle la donnée est consommée «tel quelle» dans un laps de temps spécifié. Ces délais sont définis en tant que SLA (Service Level Agreement). Par exemple, dans une solution de traitement des données IoT (Internet Of Things), vous avez un flux en temps réel entre les objets connectés et l’application.

Les systèmes en temps réel peuvent être divisés :

1) temps réel strict et 2) temps réel souple. En temps réel strict, lorsqu'une action est effectuée au mauvais moment n'aura probablement aucun impact négatif. En d'autres termes, vous devez absolument respecter toutes les échéances. Il n'est pas acceptable de dire que 90% du temps, nous atteignons le temps de réponse de 100 ms. Seuls certains systèmes ont cette exigence -> applications médicales (par exemple, stimulateur cardiaque), systèmes de défense, systèmes nucléaires, avionique, etc.

En temps réel souple, si une action est effectuée trop tôt ou trop tard, elle aura toujours un effet positif, mais si elle avait été exécutée à temps, elle aurait eu une plus grande valeur en termes d'amélioration de l'expérience client, de respect des contrats de niveau de service, etc. Le système en temps réel souple peut être une application de e-commerce avec un temps de latence élevé ou une latence faible mais sans temps de réponse garantie. Aucune catastrophe ne se produit lorsque les temps de réponse dépassent la limite, par exemple une augmentation du temps de réponse de 5% lorsque 100K demandes sont envoyées. La plupart des systèmes entrent dans cette catégorie comme les applications financières, les télécommunications, etc.


#2 La machine virtuelle Java peut-elle être utilisée pour des applications en temps réel dans le sens où elle garantit un temps de réponse strict?


La réponse est non pour les machines virtuelles standard, mais les machines spéciales qui prennent en charge les extensions «Spécification Temps Réel pour Java (RTSJ)» peuvent être utilisées pour les applications en temps réel strict. Les machines virtuelles standard nous obtiennent un «temps réel souple» principalement en raison de la collecte automatique des objets supprimés et des pauses GC qui leur sont associées. Le RTSJ est une sous-classe de RTT (Real Time Thread) appelée NoHeapRealtimeThread (NHRT). Les instances de cette sous-classe sont protégées des pauses induites par GC. Les NHRT ne sont PAS autorisés à utiliser le heap. Les NHRT utilisent les fonctionnalités de la mémoire de périmètre prédéfini (Scoped Memory) et de la mémoire immortelle pour allouer de la mémoire sur une base plus prévisible.


#3 Préférez-vous d’utiliser les consignes de développement Java en temps réel strict ou souples en général?


On privilégie le temps réel souple, sauf si un besoin spécifique en temps réel strict est nécessaire, car le temps réel souple offre une productivité et une maintenance des applications bien meilleures.


La latence est le temps nécessaire pour exécuter une action ou produire un résultat. La latence est mesurée en unités de temps telles que secondes, millisecondes, microsecondes, nanosecondes, etc. Ce qui définit une latence «faible» dépend du contexte - une latence faible sur Internet peut être de 200 ms, alors qu'une latence faible dans une application de e-commerce basée sur FIX ou des protocoles personnalisés sur TCP / IP pourrait être de 2µs. Les systèmes de e-commerce doivent cibler 100 nanosecondes à 100 ms.


Le taux de traitement (Throughput) est le nombre de telles actions exécutées ou de résultats produits par unité de temps. Ceci est mesuré en unités de temps, comme des requêtes par seconde. Le terme «bande passante mémoire» est parfois utilisé pour spécifier le débit des systèmes de mémoire.


Exemple : Hadoop

Le système de fichiers distribués Hadoop (HDFS) et Map-Reduce concernent le taux de traitement (throughput) .Par exemple, traiter un fichier de 100 Go sur un cluster de 20 nœuds en 2 minutes ou un fichier de 1 To sur un cluster de 100 nœuds en 2 minutes pour obtenir le taux requis. HDFS offre une bonne scalabilité et utilise une infrastructure moins chère. Vous pouvez commencer avec 20 nœuds, puis horizontalement à plus de 100 nœuds, car un taux plus élevé est nécessaire pour analyser des téraoctets de données.

C'est souvent un compromis entre la latence (temps de traitement d'un enregistrement) et le taux (nombre d'enregistrements traités / seconde), pour le Stream Processing des outils comme par exemple Apache Storm ou Apache Flink sont optimisés pour avoir une bonne latence, pour le Batch Processing des outils comme par exemple Apache Spark sont optimisés pour avoir un bon taux de traitement. La latence doit être aussi faible que possible, tandis que le taux doit être aussi élevé que possible. Il est difficile d’atteindre les deux en même temps, mais nous devons nous efforcer de trouver un bon équilibre pour respecter les niveaux de service SLAs (Service Level Agreements).

Dans les systèmes Big Data certaines données ont une valeur très importante peu de temps après leur apparition et cette importance diminue très rapidement avec le temps. Le Stream Processing cible de tels scénarios et peut fournir des analyses de données plus rapidement, souvent en quelques millisecondes à quelques secondes.


Exemple: Stream Processing

Le Stream Processing s’adapte naturellement aux données chronologiques et à la détection de patterns dans le temps. Par exemple, détection des fraudes en filtrant les enregistrements suspects, les alertes / alarmes système, les données du capteur IoT, les sessions Web des utilisateurs, etc. Si vous essayez de détecter la longueur d'une session Web dans un stream sans fin, il est très difficile de le faire avec le Batch Processing car il se peut qu’une session se divise en deux batches. Le streaming gère des flux de données interminables de manière naturelle. Mais si le traitement nécessite plusieurs passages complets à travers un périmètre de données intégral ou un accès aléatoire, il est difficile d’utiliser le streaming.


#4 Comment effectuez-vous le Stream Processing dans les langages qui possèdent une JVM tels que Java, Scala, etc.?


Vous pouvez créer votre propre application avec un middleware orienté message (MOM) tel que Websphere MQ, ActiveMQ, Rabbit MQ, Kafka, etc., dans lequel vous écrivez du code pour recevoir des événements provenant des topics du broker (tels que les flux d’événements), calculer les résultats, puis publier les résultats sur le broker. Sinon, vous pouvez utiliser de préférence un framework de Stream Processing tel qu'Apache Storm, Apache Flink, Streaming Apache Spark, etc. pour gagner du temps. Le framework fera le gros du travail en collectant les données, en les transmettant à chaque processeur, en s'assurant qu'elles s'exécutent dans le bon ordre, en collectant les résultats, en partageant la charge entre plusieurs nœuds si la charge est élevée et en gérant les échecs par de nouvelles tentatives.


#5 Quelle est la différence entre les termes latence et temps de réponse? "


La latence est le temps écoulé entre le moment où une demande a été envoyée au serveur et le moment où le premier octet de la réponse a été reçu.


Le temps de réponse est le temps écoulé entre le moment où une demande a été envoyée au serveur et le moment où la réponse a été entièrement reçue. Dans une application Web, le navigateur doit charger les contenu de la page tels que l’arborescence DOM, les images, les CSS et les scripts JavaScript.


Ainsi, le temps de réponse sera toujours > = latence. En d'autres termes :


Temps de réponse = la latence + temps de traitement (ex : temps de chargement du navigateur)


Une latence faible est la somme de nombreux facteurs. Les deux plus importants sont: 1. La latence du réseau qui correspond au temps pris par le réseau pour envoyer / recevoir un message / un événement et 2. La latence de traitement qui est le temps pris par votre application pour traiter un message / événement.

Si vous construisez un moteur de «mapping d’ordre de transaction» en Java, la «latence du réseau» est le temps pris en micro-secondes, par exemple, pour recevoir une demande de mapping d’ordre au moteur à partir d’une application cliente, plus le temps nécessaire à cette application pour recevoir le premier octet du message de réponse du moteur. La «latence de traitement» est le temps écoulé en micro ou millisecondes pour que le moteur fasse le mapping de transaction et génère la réponse à renvoyer à l'application cliente.


#6 Une latence de plus de 20 ms est-elle considérée comme rapide ou lente dans une application HFT (High Frequency Trading)? ”


Tout ce qui dépasse 20 ms sera considéré comme lent. Les transactions HFT sont effectuées à l'aide d'algorithmes permettant d'acheter, de vendre et de mapper des transactions. Ce sont des applications à très faible latence qui étaient autrefois écrites en «C» et qui sont de nos jours de plus en plus écrites en Java.


#7 Quel taux de traitement viserez-vous dans les applications HFT (High Frequency Trading)? ”


50K à 200K commandes ou transactions par seconde. Vous aurez plusieurs serveurs pour traiter les demandes. L'architecture doit être évolutive pour répondre aux demandes croissantes.


#8 Quelle latence allez-vous cibler pour vos applications?


Cela dépend du contexte de l'application. Par exemple,

Une application Web standard ciblera une latence de 200 ms à 800 ms mais une application Web plus complexe ciblera une latence de 500 ms à 1 000 ms.


Exemple Système EFTPOS (Electronic funds transfer at point of sale)





Exemple Système de e-commerce




#9 Comment allez-vous améliorer la latence d'un site Web plus complexe?

#9.1 Traiter les demandes de manière asynchrone en les soumettant à une file d'attente et en obtenant les résultats ultérieurement via un pull client ou un push serveur.

# 9.2 Réduire la complexité de la page en vue d’une meilleure expérience utilisateur. Cela signifie également un contenu plus léger transféré entre le client et le serveur pour une meilleure latence du réseau.

#9.3 Produire moins de garbage collection en violant les concepts d'OO en privilégiant les types de données primitifs et en appliquant le pattern Flyweight pour améliorer la réutilisation.

# 9.4 Profiler l'application avec des outils tels que VisualVM pour identifier et améliorer les goulots d'étranglement en termes de CPU, d'utilisation de la mémoire, de pauses de Garbage Collection, etc.


#10 Que comprenez-vous par les termes systèmes temps réel, système faible latence et scalabilité d’un système ?


Les systèmes en temps réel et les systèmes de faible latence sont des sujets distincts, bien que souvent liés. Dans un système en temps réel, il faut être plus prévisible que rapide. Les systèmes à faible temps de latence doivent être rapides pour respecter les SLA (Service Level Acceptances) en moins d'une milliseconde (par exemple, une micro-seconde).

La scalabilité signifie la capacité du système à répondre aux demandes croissantes en ajoutant plus de processeurs, de mémoire, de nœuds, de serveurs, etc.


#11 Quelles sont les considérations à prendre en compte lors de l'écriture d'applications Java à faible temps de latence?


#11 .1 Traitement parallèle via :

a) Multi-Threading

b) E / S non bloquantes (NIO) (ex. MINA, Netty, Grizzly, etc.)

c) Systèmes Distribués (ex. Apache Kafka, Apache Spark, etc.) avec des architectures Share-Nothing. L'architecture Share-Nothing permet aux applications de fonctionner en parallèle sur plus de 100 nœuds avec leur processeur, mémoire, E / S, etc. dédiés.


#11.2 API de Streaming telles que Apache Spark Streaming , Apache Storm, StAX (Streaming API for XML) permettant de traiter des données en temps réel ou quasi réel.


#11.3 Ecriture de programmes qui permettent un accès concurrentiel aux ressources avec des fonctionnalités multi-threading Java telles que des Executors, Futures, des Completable Futures, des fork / join, des structures de données avec accès concurrentiel (ConcurentHashMap) etc...


#11.4 Comprendre le modèle de mémoire Java et optimiser la mémoire et le Garbage Collection Java.


#11.5 Utilisation de patterns basés sur les événements non bloquants. Par exemple, utilisez des frameworks tels qu’Apache MINA, Netty, Grizzly et Akka.


MINA & Netty sont des frameworks de niveau inférieur à Akka et sont basées sur NIO (New Java IO). NIO est un modèle non bloquant, basé sur les événements.


Akka est un framework de niveau supérieur par rapport à MINA & Netty pour la création d'applications basées sur les événements, scalables et tolérantes aux pannes. Akka est écrit en Scala, avec des librairies fournies pour Scala et Java. Akka utilise le modèle Actor pour masquer tout le code lié aux threads et vous fournit des interfaces très simples et utiles pour implémenter facilement un système scalable et tolérant aux pannes.

Même si vous avez de bonnes compétences en écriture des programmes simultanés en Java, privilégiez un framework comme Akka, car l’écriture de programmes simultanés complexes n’est pas une tâche aisée car vous devez vous occuper des threads, verrous, conditions de concurrence et débogage. L'écriture de programmes simultanés sans framework peut être sujette aux erreurs et peut conduire à un code difficile à lire, à tester et à maintenir.


#11.6 Si vous travaillez dans les systèmes BigData, jetez un coup d’œil sur Apache Spark, qui est basé sur Scala & Akka Toolkit. Voici un exemple d’un maître Spark « Driver Application » qui créé et planifie des tâches pour être exécutées sur les «exécuteurs Spark». Ici, seuls deux exécuteurs sont mis en œuvre, mais les clusters typiques auront plus de 100 nœuds et exécuteurs.



Les exécuteurs sont des processus au niveau du nœud en charge d’exécuter des tâches individuelles dans un job Spark donné. Les exécuteurs Spark sont lancés au début d'une application Spark et s'exécutent généralement pendant toute la durée de vie d'une application. Une fois les tâches exécutées, ils envoient les résultats au «Driver Application». Les exécuteurs mettent en cache les RDD en les stockant en mémoire.


#12 Qu'est-ce que le Actor Model dans Akka, également appelé Reactor Design Pattern?


Le Actor Model est un pattern de conception permettant d'écrire du code pour exécuter des tâches en parallèle offrant ainsi une meilleurs scalabilité pour les systèmes distribués. Il s’agit d’un modèle axé sur les événements (c’est-à-dire la transmission de messages) qui consiste à envoyer et à recevoir des événements entre les acteurs.



Au lieu d'appeler directement un objet, vous construisez un message et l'envoyez à un objet de destination appelé acteur.

Chaque thread est un acteur avec un travail spécifique à faire. Le moteur d'acteur stocke le message dans une file d'attente.

Lorsqu'un thread devient disponible, le moteur d'acteur exécutant l'acteur transmet ce message à son objet acteur de destination.

Lorsque l'acteur a terminé sa tâche, il renvoie un message à l'objet d'origine, qui est également considéré comme un acteur.

Vous pouvez orchestrer quels messages sont transmis à quels acteurs dans quelles conditions.



Le module akka-camel permet aux «acteurs non typés» de recevoir et d'envoyer des messages via une grande variété de protocoles tels que HTTP, SOAP, TCP, FTP, SMTP ou JMS et des API telles que java et Scala.

0 vue

#Suivez-Nous

+213560764957

©2020 by DIGITAL GROWING.