Plongée dans l’Architecture de SAS Viya 4 : Une Révolution Cloud-Native

SAS Viya 4 représente la dernière génération de la plateforme analytique SAS, entièrement repensée pour le cloud. Contrairement à ses prédécesseurs, Viya 4 adopte une architecture "cloud-native", basée sur des conteneurs et orchestrée par Kubernetes. Cette transformation fondamentale offre une portabilité, une scalabilité et une résilience accrues, mais nécessite une bonne compréhension de ses composants pour en tirer le meilleur parti.

Cet article explore les briques essentielles de l'architecture SAS Viya 4, en s'appuyant sur les informations techniques fournies, pour vous donner une vision claire de son fonctionnement interne.

Le Socle : Kubernetes

Le changement le plus significatif de Viya 4 est son exécution intégrale au sein d'un environnement Kubernetes. Tous les composants de Viya sont livrés sous forme d'images de conteneurs et déployés comme des "pods" (groupes de conteneurs) gérés par Kubernetes.

Cette approche offre plusieurs avantages majeurs :

Portabilité Multi-Cloud : Viya 4 peut être déployé sur divers services Kubernetes managés (comme Azure Kubernetes Service (AKS) Amazon Elastic Kubernetes Service (EKS) , Google Kubernetes Engine (GKE)) ou sur une infrastructure Kubernetes sur site.

Scalabilité : Kubernetes permet de monter ou descendre en charge les différents services de Viya de manière dynamique (bien que certaines limitations existent pour certains composants comme ODFE dans les versions initiales).

Résilience : Kubernetes gère le cycle de vie des pods, redémarrant automatiquement les conteneurs en cas d'échec et gérant la haute disponibilité pour les composants critiques.

Déploiement et Mises à Jour Facilités : L'approche Infrastructure as Code (IaC) et la livraison continue (CI/CD) sont grandement facilitées.

Référence Kubernetes :Documentation officielle Kubernetes

Les Piliers de l'Architecture Viya 4 L'architecture de Viya 4 peut être décomposée en plusieurs grandes catégories de composants :

1. Moteurs Analytiques (Analytic Engines) [

Ce sont les cerveaux de la plateforme, responsables de l'exécution des calculs et des analyses.

• SAS Cloud Analytic Services (CAS) : Le moteur principal, conçu pour l'analyse haute performance en mémoire. CAS peut fonctionner en mode :
  • SMP (Symmetric Multi-Processing) : Sur un seul nœud (pod), où le contrôleur fait aussi office de worker.
  • MPP (Massively Parallel Processing) : Distribué sur plusieurs nœuds (pods) pour traiter de très gros volumes de données, avec un contrôleur (et un contrôleur de secours optionnel) et plusieurs workers.
  • Intégration Kubernetes : CAS est géré via un "Operator" Kubernetes spécifique et une "Custom Resource Definition" (CRD) CASDeployment . Des volumes persistants (PVC) sont utilisés pour le permstore (permissions) et les données (casdatalib, cache disque) .
  • Personal CAS : Une instance CAS SMP temporaire, mono-utilisateur, pouvant être lancée au sein du pod d'un Compute Server pour des travaux locaux (désactivée par défaut) .
  • Référence CAS : SAS Cloud Analytic Services Documentation
• SAS Compute Server : L'environnement d'exécution traditionnel du langage SAS (SAS Programming Runtime Environment - SPRE) . Il exécute le code SAS soumis via des clients comme SAS Studio. Il est lancé à la demande par le Launcher Service ].
• SAS Event Stream Processing (ESP) : Moteur d'analyse de flux de données en temps réel (si licencié).
• SAS Micro Analytic Service (MAS) : Exécute de petites pièces de code SAS (souvent des modèles) de manière très performante, typiquement via des API REST (si licencié) .

2. Composants d'Exécution de Programmation (Programming Run-Time Components)

Ces services gèrent le cycle de vie et l'accès aux environnements d'exécution SAS.

• SAS Launcher Service : Ce service central interagit avec l'API Kubernetes pour démarrer des pods à la demande pour les Compute Servers, les SAS/CONNECT Servers et les Batch Servers, en se basant sur des PodTemplates et des Launcher Contexts ].
• SAS Compute Service : Fournit les points d'accès API REST pour que les clients (comme SAS Studio) puissent demander, gérer et interagir avec les sessions Compute Server].
• SAS/CONNECT Spawner & Server : Permet les connexions SAS/CONNECT. Fonctionnement distinct selon le client :
  • Launching (Client interne au K8s) : Le Spawner demande au Launcher Service de démarrer un nouveau pod sas-launcher-long-guid contenant un SAS/CONNECT Server dédié. Le client se connecte ensuite directement à l'IP interne de ce pod . Scalabilité horizontale .
  • Spawning (Client externe au K8s) : Le Spawner démarre un processus SAS/CONNECT Server au sein de son propre pod. Le client se connecte via le service externe du Spawner (LoadBalancer ou NodePort), et la connexion est héritée par le processus serveur . Scalabilité verticale.
  • Contrôle : Le comportement peut être influencé par les options -SERVICELAUNCH/-NOLOCALLAUNCH du spawner ou la variable d'environnement TCPNOIPADDR côté serveur/client
  • Référence SAS/CONNECT : SAS/CONNECT for SAS Viya
• SAS Batch Service & Server : Permet de soumettre des travaux SAS ou des commandes système en mode batch, typiquement via l'interface en ligne de commande (CLI) sas-viya. Le Batch Service reçoit la demande et utilise le Launcher Service pour démarrer un pod sas-launcher-long-guid exécutant un Batch Server (sasgrid process).

3. Serveurs d'Infrastructure (Stateful Services)

Ces services maintiennent un état et nécessitent généralement un stockage persistant. Ils sont cruciaux pour le fonctionnement de la plateforme.

• SAS Configuration Server (Basé sur HashiCorp Consul) : Registre central pour la configuration des services, la découverte de services et les informations d'état. Les microservices l'utilisent au démarrage. Déployé comme un StatefulSet (généralement 3 instances pour la HA) avec des volumes persistants (PVC) . sas-config-reconciler assure la synchronisation avec Kubernetes .
  • Référence Consul : HashiCorp Consul
• SAS Infrastructure Data Server (Basé sur PostgreSQL) : Stocke les métadonnées et le contenu de Viya (rapports, règles d'autorisation, favoris, etc.)
• SAS Message Broker (Basé sur RabbitMQ) : Gère la communication asynchrone et les événements entre les microservices (accusés de réception, persistance des messages, redondance). Une couche d'abstraction (sas-arke) permet potentiellement de changer de technologie de messaging à l'avenir . Déployé comme un StatefulSet (généralement 3 instances pour la HA) avec des PVCs
  • Référence RabbitMQ : RabbitMQ Documentation
• SAS Cache Locator / SAS Cache Server (Basé sur Apache Geode) : Fournit un système de cache distribué en mémoire pour améliorer les performances des microservices . Fonctionne sur un modèle client/serveur avec découverte via les Locators . Déployé comme des StatefulSet (généralement 2 instances chacun pour la HA) avec des PVCs . Le cache est en mémoire et non persistant aux redémarrages serveur.
  • Référence Apache Geode : Apache Geode Documentation

4. Services de Support et Microservices (Supporting Services & Viya Services)

Un ensemble de microservices fournissant diverses fonctionnalités (authentification, gestion des métadonnées, API diverses, etc.) et des services supportant l'opération de la plateforme.

• Open Distro for Elasticsearch (ODFE) / OpenSearch : Moteur de recherche et d'indexation distribué basé sur Elasticsearch/Lucene. Utilisé initialement par SAS Information Catalog pour indexer les métadonnées des actifs de données. SAS utilise ODFE (une distribution open-source sponsorisée par AWS, maintenant évoluée en OpenSearch) pour éviter les problèmes de licence d'Elasticsearch . Déployé via un Operator SAS spécifique et une CRD OpenDistroCluster . Les nœuds ODFE sont des pods stateful nécessitant un stockage persistant rapide (disques locaux recommandés, pas NFS) . La haute disponibilité requiert un cluster d'au moins 3 nœuds.
  • Référence OpenSearch (successeur d'ODFE) : OpenSearch Documentation
• Ingress Controller (souvent Nginx) : Gère l'accès externe (HTTP/S) aux applications web et services Viya.
• Monitoring & Logging : Outils pour observer la santé et les logs de la plateforme (souvent basés sur Prometheus, Grafana, Fluent Bit/Elasticsearch - regroupés dans le framework ops4viya)

5. Clients et Interfaces Visuelles (Clients & Visual Interfaces)

Les points d'entrée pour les utilisateurs.

• SAS Studio : Interface web principale pour la programmation SAS, le flux de données, et plus encore. Évolution de SAS Studio Enterprise Edition, avec des éditions spécifiques (Analyst, Engineer) remplaçant les anciens clients lourds (Enterprise Guide, Data Integration Studio) . Optimisation : l'interface se charge rapidement pendant que le Compute Server démarre en arrière-plan
  • Référence SAS Studio : SAS Studio Documentation
• SAS Visual Analytics / SAS Visual Statistics / etc. : Applications web dédiées à l'exploration de données, la modélisation, etc.
• SAS for Microsoft 365 : Add-in web pour Microsoft Excel (desktop ou web) permettant d'intégrer des rapports SAS Visual Analytics dans les classeurs Excel.
  • Référence SAS for Microsoft 365 : SAS for Microsoft 365 Documentation
• Absence de Clients Lourds : Viya 4 n'a pas de clients desktop traditionnels. Les connexions depuis d'anciens clients comme Enterprise Guide ne sont pas directement possibles.

Intégration Cloud Avancée

Au-delà de Kubernetes, Viya 4 peut s'intégrer plus profondément avec les services cloud natifs :

• Utilisation de bases de données managées (Azure DB for PostgreSQL, AWS RDS, Google Cloud SQL) pour le SAS Infrastructure Data Server .
• Intégration avec les services de monitoring natifs (Azure Monitor, AWS CloudWatch, Google Monitoring).
• Utilisation de services de Load Balancing et DNS du fournisseur cloud .
• Potentiellement, remplacement de Consul ou RabbitMQ par des services équivalents managés
• Gestion des identités via Azure Active Directory / AWS IAM / Google Cloud IAM .
• Stockage des secrets et certificats dans des coffres-forts managés (Azure Key Vault)

Conclusion

SAS Viya 4 marque une étape majeure dans l'évolution de la plateforme SAS. Son architecture cloud-native basée sur Kubernetes et les conteneurs offre une flexibilité, une scalabilité et une résilience sans précédent. Comprendre ses composants clés - des moteurs analytiques comme CAS et Compute, aux services d'infrastructure stateful comme PostgreSQL et Consul, en passant par les mécanismes de lancement comme le Launcher Service et l'intégration Kubernetes - est essentiel pour déployer, administrer et exploiter efficacement cette puissante plateforme analytique dans l'ère du cloud.