CAS CLIENT · INFRASTRUCTURE
Stabiliser une infrastructure sans simplement ajouter de la puissance
Un site éditorial à fort trafic rencontrait des problèmes de stabilité sur une infrastructure regroupant WordPress, PHP et la base de données sur une même machine.
PLATEFORMS est intervenu pour comprendre les causes, repenser l'architecture et reprendre son exploitation dans la durée.
- SECTEUR
- Média · Site éditorial
- CONTEXTE
- WordPress à fort trafic
- INTERVENTION
- Infrastructure · Supervision · Exploitation
- ACCOMPAGNEMENT
- Exploitation dans la durée
Un front public découplé du back-office
Le front public, développé en Next.js par BearStudio et hébergé chez Clever Cloud, est découplé du WordPress utilisé par les équipes éditoriales. PLATEFORMS prend en charge l'infrastructure du back-office, les bases de données, la supervision et son exploitation.
- BearStudio
- Développement du front public en Next.js
- Clever Cloud
- Hébergement du front public
- PLATEFORMS
- Infrastructure WordPress et données, supervision, exploitation
Repenser la répartition des fonctions
- WordPress + PHP + base de données
Sur une même grosse machine
- Ressources partagées
- Saturation difficile à isoler
- Faible visibilité
- WordPress / PHP
- MariaDB master / slave
- Monitoring
Des fonctions cloisonnées
- Ressources adaptées
- Meilleure visibilité
Comprendre avant de reconstruire
Les rédacteurs étaient particulièrement pénalisés par l’instabilité : plusieurs d’entre eux ne pouvaient plus travailler correctement en même temps. Le client avait accès à son serveur, mais manquait de visibilité, d’analyse et d’accompagnement.
Le travail a commencé par une réunion entre le client, BearStudio et PLATEFORMS. Nous avons analysé l’infrastructure, étudié les problèmes et les usages, puis réalisé un rapport d’étonnement. L’architecture proposée à la suite de cette analyse a été discutée et validée avec le client et BearStudio.
L'objectif n'était pas de remplacer systématiquement ce qui existait ni d'ajouter de la puissance pour masquer les problèmes. L'analyse a conduit à une nouvelle organisation permettant de mieux isoler les fonctions et d'attribuer les ressources là où elles étaient réellement nécessaires.
Cloisonner pour mieux maîtriser
Sur la machine initiale, WordPress, PHP et la base de données partageaient les mêmes ressources. Avec le trafic et la configuration, ces briques pouvaient se pénaliser mutuellement.
La nouvelle architecture réserve des ressources à PHP et WordPress. La couche de données repose sur MariaDB en master / slave pour mieux répartir les usages entre lecture et écriture. Le monitoring dispose également d’une brique dédiée.
CPU et mémoire sont adaptés aux besoins réels. Ce cloisonnement permet de mieux isoler les problèmes et de disposer de métriques et de logs exploitables.
L'objectif n'était pas de multiplier les serveurs. Il était d'éviter qu'un problème local puisse aussi facilement affecter l'ensemble de la plateforme.
Migrer sans interrompre les lecteurs
L’ancienne et la nouvelle infrastructure ont pu cohabiter. Une migration à blanc a permis de préparer la bascule réelle.
Lors de cette migration, le front public Next.js est resté disponible pour les lecteurs grâce à son découplage et à son mécanisme de cache. L’indisponibilité a essentiellement concerné les rédacteurs : environ deux heures ont été nécessaires pour migrer les données et basculer la plateforme.
Cette migration s’est déroulée sans incident particulier.
Passer de la réaction à l’anticipation
Métriques, logs, alertes et supervision exploitable donnent désormais de la visibilité sur le fonctionnement de la plateforme. Le client dispose lui aussi d’un accès au monitoring : la supervision n’est pas une boîte noire réservée à PLATEFORMS.
Le suivi de l’espace disque a déjà permis d’identifier des consommations liées à WordPress ou aux sauvegardes avant qu’un système de fichiers plein ne provoque un incident.
Voir ce qui se passe permet d'intervenir avant que l'utilisateur ne découvre le problème.
Une stabilité retrouvée dans les conditions actuelles
Depuis la migration, l’infrastructure est stable dans ses conditions actuelles d’exploitation.
- Les phénomènes de saturation rencontrés auparavant ne sont plus constatés dans les conditions actuelles d’exploitation.
- Plusieurs rédacteurs peuvent à nouveau travailler simultanément dans WordPress.
- Le monitoring alerte PLATEFORMS lorsqu’un problème apparaît.
- Certains problèmes ont déjà pu être anticipés grâce à la supervision.
Maintenir, sécuriser et faire évoluer
PLATEFORMS continue à prendre en charge l’hyperviseur, les machines virtuelles, les bases de données, les mises à jour nécessaires et les sauvegardes. La supervision, l’analyse des logs et des incidents et les évolutions font partie de cette exploitation dans la durée.
Le besoin a changé de nature : il s’agit désormais de maintenir, sécuriser et faire évoluer une plateforme qui fonctionne, après les problèmes récurrents de stabilité.
Le client dispose d’un interlocuteur accessible, connaissant son environnement et capable d’échanger avec lui lorsqu’un besoin apparaît. L’accompagnement dépasse ainsi une relation principalement limitée au suivi de tickets.
Une infrastructure fiable ne repose pas uniquement sur des machines. Elle repose aussi sur la capacité à comprendre ce qui s'y passe et à agir quand c'est nécessaire.
Ce qui a changé au quotidien
Avant
- WordPress, PHP et la base de données concentrés sur une grosse machine
- Saturations et instabilités
- Plusieurs rédacteurs pouvaient difficilement travailler simultanément
- Peu de visibilité exploitable sur les problèmes
- Intervention essentiellement après apparition du problème
- Accompagnement principalement au travers de tickets
Aujourd’hui
- Fonctions cloisonnées et ressources adaptées à chaque brique
- Plus de saturation constatée dans les conditions actuelles
- Les rédacteurs peuvent à nouveau travailler en parallèle
- Métriques, logs et alertes disponibles
- Supervision permettant également d’anticiper certains incidents
- Échanges directs avec un partenaire qui connaît l’environnement