SAS Viya 4 et Redis : Le duo choc pour une plateforme moderne
Dans cet article, je vais explorer, une fois encore - je sais je radote un peu - l'architecture de la plateforme SAS Viya 4 et comment elle fonctionne avec Redis et essaye de montrer comment cette combinaison aide la plateforme à être réactive et solide, même quand plein de services tournent en même temps. Spoiler alert : Redis joue un rôle clé dans cette performance.
SAS Viya 4 : Le Passage à une Architecture Cloud-Native
Vous le savez, si vous êtes arrivé sur cet article, que les versions de SAS Viya 4 (depuis la 2020.1) représentent un changement important par rapport aux architectures plus anciennes, souvent monolithiques. SAS Viya 4 adopte une approche cloud-native, en s'appuyant principalement sur Kubernetes pour gérer les conteneurs. Ce changement majeur amène plusieurs nouveautés :
Pilotage Natif par Kubernetes
La plateforme est faite pour tourner entièrement dans un environnement Kubernetes. Elle profite donc de ses fonctions natives comme l'élasticité (adapter les ressources automatiquement selon la charge), la haute disponibilité (si un composant tombe, un autre prend le relais) et l'équilibrage de charge. Ça rend le déploiement et la gestion plus faciles et la plateforme plus souple.
Architecture en Microservices
Au lieu d'un gros bloc, SAS Viya 4 est divisée en plein de petits services indépendants et spécialisés (les microservices). Chaque microservice s'occupe d'une tâche précise (comme l'authentification, la gestion des données, etc.). Au lieu d'un gros bloc, SAS Viya 4 est divisée en plein de petits services indépendants et spécialisés (les microservices). Chaque microservice s'occupe d'une tâche précise (comme l'authentification, la gestion des données, etc.).
Le bon fonctionnement de la myriade de microservices et composants de SAS Viya repose sur une infrastructure de support robuste, elle-même composée de services stateful critiques.
SAS Configuration Server (basé sur Consul)
Ce service, utilisant l'outil open-source Consul, joue un rôle vital dans la découverte de services (permettant aux microservices de se localiser mutuellement) et la gestion centralisée de la configuration. Il est typiquement déployé en mode haute disponibilité (HA) avec plusieurs réplicas (généralement 3 ou 5) pour assurer la tolérance aux pannes, et chaque réplica nécessite un volume persistant pour stocker son état.
SAS Infrastructure Data Server (basé sur PostgreSQL)
Il s'agit du système de gestion de base de données relationnelle utilisé par la plateforme pour stocker une grande variété d'informations persistantes, notamment le contenu créé par les utilisateurs (rapports, modèles, flux, etc.), les métadonnées de la plateforme, les informations d'audit, et les configurations de services.
SAS Message Broker (basé sur RabbitMQ)
Ce composant fournit un système de messagerie asynchrone utilisé par divers services Viya pour communiquer entre eux de manière découplée. Il est essentiel pour les workflows impliquant des notifications, des tâches en arrière-plan ou des architectures événementielles. Comme Consul, il est déployé en mode HA avec plusieurs réplicas et nécessite un stockage persistant.
SAS Redis Server (basé sur Redis)
Comme mentionné précédemment et détaillé plus loin, ce service fournit la capacité de cache distribué utilisée par les microservices Viya.
La stabilité et la performance globales de la plateforme SAS Viya ne dépendent pas uniquement des moteurs de calcul comme CAS ou Compute. Elles sont intrinsèquement liées au bon fonctionnement et à la performance de cette infrastructure de support sous-jacente. Consul, PostgreSQL, RabbitMQ et Redis forment un socle interdépendant sur lequel s'appuient les microservices pour la configuration, la persistance des métadonnées et du contenu, la communication asynchrone et le caching. Un goulot d'étranglement, une mauvaise configuration ou une instabilité dans l'un de ces composants stateful peut avoir des répercussions significatives sur de nombreux aspects de la plateforme Viya. Par exemple, une base de données PostgreSQL lente affectera le chargement des contenus dans les applications web, tandis qu'un service Redis indisponible pourrait dégrader la performance ou la fonctionnalité des microservices qui l'utilisent pour le cache d'état.
Redis : Une Base de Données en Mémoire Très Performante
Redis (REmote DIctionary Server) est une base de données NoSQL open-source, très connue pour ses bonnes performances et ses temps de réponse très courts. Ce qui le rend spécial, c'est qu'il stocke les données principalement en mémoire vive (RAM). En gardant les données en RAM au lieu du disque dur (comme les bases de données classiques), Redis permet des accès très rapides, qui se comptent souvent en millisecondes.
Même si on le voit souvent comme un simple stockage clé-valeur, Redis gère en fait plein de types de structures de données, ce qui le rend très polyvalent:
- Des textes (Strings) : Pour stocker du texte, des chiffres, ou des données binaires.
- Des Listes (Lists) : Des collections ordonnées.
- Des Ensembles (Sets) : Des collections d'éléments uniques, sans ordre précis.
- Des Tables de Hachage (Hashes) : Pour stocker des objets avec des champs et des valeurs.
- Des Ensembles Triés (Sorted Sets) : Des ensembles avec un score pour chaque membre, pour les trier facilement.
- D'autres types plus avancés : Streams (pour des logs d'événements), Données Géographiques, HyperLogLogs, Bitmaps, JSON, et d'autres...
Ce mélange de rapidité et de flexibilité fait de Redis un super choix technique pour mettre en place des systèmes de cache partagé (distribué).
Le Rôle Clé du Cache dans une Architecture Microservices
Dans une architecture répartie comme SAS Viya 4, où plusieurs copies (instances) d'un même microservice peuvent tourner en même temps, devoir demander sans arrêt à la base de données principale (souvent PostgreSQL dans Viya pour le stockage des donnée) pour chercher les mêmes infos ou des états partagés peut vite devenir un point de blocage (goulot d'étranglement, comme indiqué un peu plus haut). Chaque demande à la base de données ajoute du délai et la charge plus.
Un cache partagé, fait avec Redis, fonctionne comme une couche de stockage au milieu, partagée et très rapide. Il permet aux différentes copies des microservices de :
- Garder temporairement les résultats de calculs longs ou de demandes fréquentes.
- Partager des infos (comme les sessions utilisateur).
- Accéder presque tout de suite à ces données gardées en cache.
Utiliser Redis comme cache partagé dans SAS Viya diminue beaucoup la charge sur la base principale et améliore vraiment la vitesse et les performances générales de la plateforme, surtout quand il y a beaucoup d'activité
Pour Finir et la Suite
Maintenant qu'on a posé les bases sur l'architecture cloud-native de SAS Viya 4 et présenté Redis comme une solution de stockage en mémoire rapide et importante pour le cache, j'irai plus loin dans un prochain article. Je regarderai plus en détail comment SAS a spécifiquement intégré Redis dans sa plateforme, son rôle exact, et comment ça marche concrètement dans l'environnement Kubernetes.
