COOG 1.6 - Nouvelle Architecture

Si la version 1.6 de Coog a apporté de très nombreuses nouvelles fonctionnalités métier et d’améliorations ergonomiques, comme nous avons eu l’occasion de le détailler lors de l’annonce, elle a aussi permis de faire progresser la solution dans un domaine moins visible : celui de la technologie.

Pour parvenir à cet objectif, Coopengo a monté en 2015 une équipe technique dédiée (hors projets d’implémentation) dont l’objectif est de propulser Coog à la pointe de ce qu’offre la technologie.

Ainsi, l’architecture de Coog, primordiale pour la pérennité de la solution et la facilité de ses déploiements, a bénéficié d’une révolution à l’occasion de la version 1.6. Certains changements sont détaillés plus bas pour donner de la visibilité sur notre ambition.

architecture coog

Par ailleurs, Coopengo a avancé sur le packaging et l’outillage de la solution pour industrialiser les processus de maintenance et mieux accueillir les nouveaux contributeurs. Ces aspects seront couverts par des articles à venir.

Multi-worker

Situation

La mise en production à grande échelle de Coog chez nos clients a pu montrer dans des cas précis certaines limites de la scalabilité verticale avec Python. Même en mettant à disposition toutes les ressources matérielles nécessaires,
l’architecture mono-processus reste un frein pour déployer à très grande échelle.

La solution souvent évoquée est l’utilisation d’un dispatcher WSGI (permet de multiplier les workers). Néanmoins, cette solution reste peu utilisée et nécessite du développement sur les couches basses.

Solution

Pour répondre à ce besoin qui commençait à être pressant, Coog a choisi d’utiliser Nginx. Cette solution a non seulement répondu au besoin, mais de plus elle a permis de rajouter Nginx dans notre stack offrant ainsi beaucoup de possibilités pour nos déploiements.

Les raisons

  • Nginx est le serveur applicatif par excellence sur le marché aujourd’hui
  • Son fonctionnement asynchrone limite au maximun l’overhead
  • Il assure très bien les rôles de reverse-proxy et load-balancer demandés par nos client
  • Il permet de profiter d’autres fonctionnalités (règles de sécurité, gestion du SSL, logging puissant, etc.)

Cache transverse

Situation

Le mode multi-worker nous a mené à relever un autre challenge : la gestion du cache. Les nœuds (serveur) ont deux types de cache :

  • Cache transactionnel : exclusif à une transaction (appel serveur) et lui permet de garder les objets qu’elle manipule en mémoire (le niveau d’isolation au niveau de la base de données le permet bien)
  • Cache transverse : partagé par toutes les transactions (prévu pour les objets qui changent rarement comme les vues, les tables de tarification en assurance, etc.). Toutes les transactions peuvent alimenter et périmer ce cache. Ces actions se font dans des “Sections critiques”

Avec un pool de processus concurrents, le mode de gestion du cache devient obsolète :

  • Le mécanisme d’invalidation du cache ne fonctionne plus : si worker-1 modifie un objet, il invalide son cache local mais aucun moyen de prévenir worker-2
  • Avec la multiplication des workers, on se retrouve avec de la mémoire redondante (les mêmes objets en cache autant de fois que les workers)

Solution

Les deux solutions possibles étaient :

  1. Un mécanisme de synchronisation via la base de données pour propager l’invalidation
  2. Utiliser une serveur de cache (hors mémoire)

Même si la première solution avait l’air plus naturelle au vu du framework utilisé, Coopengo a opté pour la seconde option. Celle-ci permet en effet, non seulement de résoudre la problématique de la synchronisation des caches mais aussi :

  • D’éviter la redondance en mémoire
  • D’éviter les sections critiques pour les accès au cache
  • De profiter d’un système dédié et efficace pour ce rôle

Pour la technologie, Redis était le choix naturel. Pour ce qui est de l’implémentation :

  • Le nouveau cache utilise la même interface que le cache natif de Tryton (modification très locale)
  • Les objets de Tryton étant facilement sérialisable, l’interface avec le cache était simple et l’utilisation de msgpack était un pari gagnant sur tous les aspects (mémoire, CPU)

Ce chantier a été sensible à mener. Maintenant que les déploiements en production de Coog chez différents client l’ont approuvé et étant donné le gain en performance constaté, Redis devient le cache par défaut de Coog (mono et multi-workers, applicatif et batch)

Conclusion

Ces nouveautés prouvent la maturité atteinte par Coog afin de pouvoir répondre aux besoins de ses clients. Cela donne aussi de l’assurance et de la sérénité à Coopengo pour étendre encore plus sa couverture métier et maintenir son niveau de performance sur des déploiements à forte sollicitation.

Références