Sacalabilité

Discussion originale ici : https://discuter.spip.net/t/scalabilite-horizontale-jouable/199149/1

Témoignage de b_b :

Voici ce qu’on arrive à faire chez Infini, hébergeur associatif brestois, chez qui je suis bénévole dans l’équipe tech.

Voir la présentation de notre infra pour le contexte Hébergement - Infini. On peut y lire qu’un site configuré pour tourner en PHP 8.4 est « posé » au minimum sur deux vms web afin d’assurer « le mode HA ».

Cache partagé, y compris i) sessions et ii) squelettes (Redis/Valkey?)

On branche le cache des SPIP sur notre cluster memcached avec le plugin memoization. Concernant les sessions, on configure PHP sur session_handler & save_path pour qu’elles soient sotckées dans le cluster memcached.

Stockage fichier externalisé

Tu penses à déporter uniquement le répertoire IMG, c’est bien ça ? Un montage réseau avec NFS ferait bien le job (même si PHP n’aime vraiment pas le NFS).

Gestion du cron par « génie » plutôt qu’externalisation sur un broker / système de queue tiers (RabbitMQ, SQS…)

Le cron de SPIP peut-être appelé depuis un cron system à l’aide de spip-cli, ça permet de ne pas être dépendant du déclenchement « classique » généré par les visites du site public.

Backup bdd via fichier local

Tu peux préciser le besoin ? Si l’objectif est de récupérer la base via un unique fichier, SQLITE répond au besoin, mais perso je ne recommande pas son usage, je préfère notre bon vieux cluster mariadb.

Scalabilité horizontale avec SPIP, notes et retours d’expérience

Ces notes font suite aux différents échanges menés sur discuter.spip.net autour de la scalabilité horizontale de SPIP.

L’objectif n’est pas de proposer une architecture unique ni de transformer SPIP en framework « cloud native », mais plutôt de recenser les points techniques identifiés lors des retours d’expérience et des expérimentations autour des architectures multi-instances.

Sujet global

Le principal sujet soulevé dans les échanges concerne la capacité de SPIP à fonctionner sur plusieurs instances simultanément derrière un répartiteur de charge.

SPIP n’a historiquement pas été conçu pour ce type d’architecture.

Plusieurs éléments reposent fortement sur le système de fichiers local :

• sessions ;
• cache ;
• répertoire IMG/ ;
• logs ;
• certains traitements temporaires ;
• certains plugins.

Pour autant, plusieurs retours montrent qu’il est déjà possible d’aller relativement loin avec des adaptations ciblées.

Logs

SPIP écrit historiquement ses logs dans tmp/log/ via spip_log().

Dans des environnements conteneurisés modernes (Docker, Kubernetes, etc.), les logs sont généralement récupérés via stdout et stderr.

Le plugin logs_stderr a été développé dans ce contexte afin de rediriger les appels à spip_log() vers stderr.

Objectifs :

• éviter une dépendance forte au disque local ;
• faciliter la centralisation des logs ;
• améliorer l’intégration avec les outils d’observabilité ;
• simplifier l’exploitation.

Cela ne règle évidemment pas tous les sujets liés à la scalabilité, mais constitue une première brique intéressante.

Sessions

Le sujet des sessions revient régulièrement dans les retours d’expérience.

Historiquement, les sessions SPIP sont stockées dans tmp/sessions/.

Dans une architecture multi-instances, cela peut provoquer des pertes de session lorsqu’une personne change d’instance derrière un load balancer.

Pistes évoquées

Répertoire partagé

Partage du répertoire des sessions entre plusieurs instances :

• NFS ;
• volume partagé ;
• stockage réseau.

Cette approche semble avoir déjà été utilisée historiquement sur certains projets SPIP.

Configuration PHP

Utilisation des mécanismes natifs de PHP.

Exemple :

session.save_handler = files
session.save_path = /repertoire/partage

Ou avec Redis :

session.save_handler = redis
session.save_path = "tcp://redis:6379"

Dans ce cas, le stockage des sessions est géré directement par PHP.

Sticky sessions

Autre possibilité : conserver une même personne sur la même instance.

Cette approche simplifie fortement la problématique des sessions, mais limite une partie des bénéfices d’une architecture réellement distribuée.

Sujet éventuel côté plugins

Plusieurs échanges ont évoqué l’idée d’un plugin générique permettant :

• de diagnostiquer le mode actuel de stockage des sessions ;
• de documenter les configurations compatibles multi-instances ;
• éventuellement de piloter certains handlers PHP.

L’idée serait davantage de fournir une couche de compatibilité ou de diagnostic qu’un remplacement complet du fonctionnement historique.

Cache

Le cache SPIP repose historiquement sur des fichiers stockés localement dans tmp/cache/.

Le principal sujet n’est pas uniquement le stockage du cache, mais également sa cohérence entre plusieurs instances.

Pistes évoquées

Cache local sur chaque instance

Chaque instance conserve son propre cache local.

Approche simple et probablement suffisante dans de nombreux cas.

Sujet principal : propagation des invalidations.

Invalidation distribuée

Plusieurs mécanismes ont été évoqués :

• appels HTTP ;
• Redis pub/sub ;
• file de messages ;
• purge centralisée.

Cache externalisé

Redis ou Memcached ont également été évoqués.

Cependant, le fonctionnement historique du cache SPIP reste fortement orienté fichiers.

Répertoire IMG/

Le stockage des documents reste l’un des principaux points structurants.

Par défaut, les fichiers sont stockés localement dans IMG/.

Pistes évoquées

Répertoire partagé

Partage de IMG/ entre toutes les instances.

Approche pragmatique et probablement la plus simple à mettre en œuvre.

Stockage objet

Autre piste évoquée :

• S3 ;
• MinIO ;
• Swift ;
• stockage objet compatible.

Cette approche nécessiterait davantage d’adaptations sur :

• les uploads ;
• les URLs ;
• certains traitements sur les documents.

Tâches planifiées

Sujet également évoqué dans plusieurs retours.

Dans une architecture multi-instances, plusieurs serveurs peuvent exécuter les mêmes tâches simultanément.

Pistes évoquées :

• une instance dédiée aux tâches CRON ;
• verrouillage distribué ;
• pilotage externe.

Plugins

Plusieurs échanges rappellent que certains plugins peuvent poser problème dans des architectures distribuées.

Exemples possibles :

• écritures locales dans tmp/ ;
• génération de fichiers temporaires ;
• caches spécifiques ;
• hypothèse implicite d’instance unique.

Piste évoquée : documenter progressivement les compatibilités.

Architecture hybride

Plusieurs retours convergent vers une approche pragmatique :

• frontal public distribué ;
• espace privé plus centralisé ;
• stockage partagé ;
• supervision renforcée.

Dans de nombreux cas, cela semble constituer un bon compromis entre :

• simplicité d’exploitation ;
• résilience ;
• compatibilité avec le fonctionnement historique de SPIP.

Sujet observabilité

Sujet revenu plusieurs fois dans les échanges.

Besoin de mieux suivre :

• logs ;
• erreurs ;
• performances ;
• cache ;
• tâches planifiées ;
• charge base de données.

Le sujet dépasse largement SPIP lui-même et rejoint les problématiques classiques d’exploitation moderne.

Pistes futures

Plusieurs sujets pourraient être approfondis :

• documentation des bonnes pratiques multi-instances ;
• abstraction du stockage des sessions ;
• amélioration de l’observabilité ;
• propagation distribuée des invalidations ;
• stockage objet des documents ;
• diagnostic des dépendances locales.

L’approche qui ressort le plus des différents échanges reste une approche progressive et pragmatique, basée sur des adaptations ciblées plutôt qu’une refonte complète du fonctionnement historique de SPIP.