Chiron (4/11) : journal, bascule, historisation

[Laurent Caillette]

Nous avons précédemment évoqué le remplissage du journal qui contient les données chaudes et nous allons maintenant nous pencher sur son cycle de vie. 

Pour une application qui est sensée fonctionner sans limite dans le temps, comment ne pas saturer la mémoire vive ? Il faut un événement qui provoque une remise à zéro. Un cas typique en finance de marché c'est la transition entre deux journées de travail. Cet événement sera nommé "bascule". Dans le code applicatif, pour une bascule qui a lieu chaque nuit, le mot "Daybreak" fonctionne très bien.

Au moment de la bascule, on crée un nouveau journal qu'on alimente avec des données de base, par exemple les utilisateurs et la définition des produits financiers. Ça marche tant qu'il n'y en a pas trop. Je travaille sur une application où on n'aura jamais plus de 100 utilisateurs et 1000 produits, ce qui fait à la louche `110 ko` qui se répètent plus ou moins d'un fichier à l'autre, donc un coût complètement acceptable. 

Une question intéressante, c'est ce qu'on fait de ces fichiers journal au moment de la bascule. 

=== Accumulation de fichiers journal

Une bonne raison de ne pas les jeter, c'est qu'on a une piste d'audit de toutes les transitions d'états du système. Qui a fait quoi et quand, et qui l'a défait. Au niveau légal pas possible de faire mieux. 

Un fichier journal est le candidat rêvé pour un archivage sur un support durable. On peut graver un DVD ou télécharger un fichier chiffré sur Amazon S3 avec des permissions interdisant la modification des archives. Comme dispositif de sauvegarde c'est hideusement //simple//. Un peu de publicité : le client S3 en Java offre une "fonctionnalité de chiffrement" 

https://groups.google.com/d/msg/techos/eWYMKjFjeq0/LFgewCAswlIJ

admirablement bien pensée. 

Les sauvegardes c'est bien, à condition de pouvoir les restaurer. Le format d'un fichier journal dépend de la version de l'application qui l'a écrit. Pour relire les vieux journaux, on peut ressortir la vieille version et on bricole un truc équivalent à un export vers un fichier unique. Mais le mieux c'est de garantir que chaque version sache relire les journaux de toutes les versions antérieures.

Oui ça fait autant de cas que de versions de schéma pour le fichier journal, et ça semble beaucoup plus compliqué qu'une montée de version avec un SGBDR. Mais là tout peut se coder avec le même langage, et les structures de données sont plus simples. Et avant de livrer une version c'est //vraiment// un bon test de lui faire manger tous les fichiers journaux des versions précédentes. 

=== Historisation

On a vu que chaque bascule provoque la création d'un fichier journal tout frais, avec des données de base suffisantes pour la journée qui vient. Mais dès la deuxième journée il est probable que les utilisateurs souhaitent accéder aux données froides, c'est à dire une synthèse de données produites lors des jours précédents. La solution consiste à alimenter un dispositif historique séparé à chaque bascule, et à fournir des primitives de requêtage. L'historique est techniquement assez trivial, puisqu'il suffit de garantir un accès exclusif lors d'un ajout en masse qui intervient alors que l'application n'est pas, ou peu utilisée. 

Tout cela reste cohérent avec ce qu'on racontait au début avec la distinction entre "données chaudes" et "données froides". Cette approche est formalisée sous le nom de ségrégation entre responsabilité transactionnelle et décisionnelle ("CQRS" pour "Command Query Responsibility Segregation"

https://martinfowler.com/bliki/CQRS.html

). Techniquement les données froides peuvent se retrouver dans une base documentaire indexée comme Lucene, un SGBDR avec un modèle en étoile (en tant que vertueuse trahison du modèle relationnel), ou un tas de fichiers qu'on monte en mémoire au démarrage. 

Après, si on veut enrichir la structure des données froides avec des données qui n'étaient pas initialement prévues, il suffit de les reconstruire à partir des fichiers journaux existants. 

=== Outillage

Pour faire fonctionner tout ça il faut ajouter un peu d'outillage applicatif : du code pour rejouer les fichiers journal historisés en vérifiant que ça n'explose pas, valider l'intégrité de l'historique, vérifier que lors du rejeu les fichiers journal produisent bien le même historique, et recréer un historique juste à partir des fichiers journal archivés. Dans l'architecture décrite, le code effectuant le rejeu et l'historisation est déjà écrit quelque part, donc il faut juste un peu de boulot supplémentaire pour fournir des commandes en ligne et produire des rapports, avec du bon code Java testable unitairement. Tu connais beaucoup d'applications qui ont des tests unitaires pour leur sauvegarde ?

Ce n'est pas tout. En intégrant les sauvegardes au niveau applicatif on maîtrise la concurrence d'accès et on évite un outil de plus pour faire de la sauvegarde en ligne. Ça fait sûrement un consultant en quelque chose ou une license de je sais pas quoi dont on peut se débarrasser.

Mais le plus beau avec cette possibilité d'un rejeu massif des fichiers journal, c'est que ça rentabilise l'utilisateur en lui faisant écrire des tests d'intégration. 

Et si on utilise DRBD pour la réplication, ça fait une réplication en temps réel sur une machine dont l'activité est presque nulle. Donc pour pas un rond de plus, on peut figer les données répliquées avec un instantané LVM. Comme ça on peut faire tourner tranquillement un rejeu massif lors des tests d'intégration. 

=== Que fournit Chiron ?

Chiron ne propose pas de fonctionnalité de haut niveau pour pour effectuer la bascule, pour l'instant la fonctionnalité reste cantonnée à du code applicatif.