On va rester à vitesse, parce que vélocité reste soit synonyme de vitesse, soit une vitesse et une direction (et rares sont les architectes qui revendiquent une solution qui ne va pas de l'avant).

La notion de "temps réel" est toute relative. Dans les systèmes industriels, comme l'avionique, avoir une information en moins de 50 ms est du temps réel. Pour mettre à jour le CA d'une entreprise en "temps réel", une mise à jour toutes les 30 secondes est tout à fait envisageable. Imaginons la durée de l'article que le "temps réel" soit "vite au sens de l'utilisateur". Le besoin se manifeste souvent comme étant le besoin d'avoir les données les plus fraîches possibles pour un traitement donné, donc notamment la minimisation du temps entre l'arrivée de la donnée dans le SI et sa mise à disposition dans une application.

Accélérer la mise à disposition

Si vous avez déjà utilisé une solution qui se base sur map-reduce, vous savez que rien que le temps de lancement de la JVM prend un temps incompatible avec un quelconque espoir de "temps réel". L'idée est donc d'utiliser des index, du "stockage" en mémoire, et bien sûr, les caches.

Les lambda architectures

Au delà de cette structuration différente, on a deux patterns architecturaux, les lambda et kappa architectures.

Le principe des lambda architectures est expliqué ci dessus. Prenons un exemple: tous les jours, à la fin de la journée, les ventes de tous les magasins d'une chaîne de commerce sont intégrées dans une grande base de données. Au début, cette mise à jour quotidienne marchait fort bien. Puis le besoin a changé pour avoir un suivi du temps réel des ventes. Dans ce cas là, l'idée est simple: on continue à intégrer les ventes par batch, on utilise en parallèle une solution de "temps réel" qui stocke (par exemple en mémoire) les nouvelles ventes. Quand l'utilisateur demande le CA sur une période donnée, l'algorithme est de prendre les données sur le support stable pour les jours passés, et sur la source de données "temps réel" pour ce qui n'est pas stocké dans le support long terme. Évidemment, il faut mettre à jour le support long terme avec les données "temps réel". Un batch doit tourner régulièrement pour vider le stockage court terme et le stocker dans le support long terme.

Streams

Oui, mais alors, tout ça, c'est magnifique, mais pour le "temps réel", si on pouvait s'affranchir de la partie batch, on irait encore plus vite. L'idée la plus simple (en théorie) pour aller encore plus vite est de tout traiter en temps réel et en mémoire. On utilise donc des solutions comme Kafka et on gère de manière incrémentale les données :

  • le service utilisateur pointe sur la dernière version des données
  • chaque mise à jour implique l'exécution d'un job qui va traiter les données, et créer une version des données plus récente. L'ancien job est éteint, et l'ancienne version des données est supprimée.
  • Le tout avec des techniques ou technologies qui minimisent la latence (notamment disque)

Conclusion

En fonction du besoin de "temps réel" de votre client, vous avez trois familles d'options:

  • cache et index pour accélérer les traitements
  • utiliser une architecture lambda, complexe techniquement
  • et si vous trouvez que la mise à jour de deux parties de batch à chaque demande client est trop lourde, pensez au streaming. Vous trouverez de quoi avec kafpa et spark (streaming)
 

Comments are closed.

Set your Twitter account name in your settings to use the TwitterBar Section.