2 Faire passer le stockage des boîtes aux lettres de quelques milliers à des millions d’utilisateurs tient moins à l’achat de baies plus grosses qu’à la suppression des choix de conception qui empêchent une plateforme de grandir. Les plateformes de messagerie des opérateurs télécoms, fournisseurs d’accès à Internet et hébergeurs croissent dans deux directions à la fois : plus d’utilisateurs, et plus de données par utilisateur à mesure que les quotas augmentent et que les pièces jointes grossissent. Les plateformes qui montent en charge sans heurts partagent quelques traits : les utilisateurs peuvent passer librement d’un serveur à l’autre, les serveurs de messagerie conservent peu d’état permanent, le cache absorbe l’essentiel du trafic en lecture et le stockage s’étend par ajout de nœuds plutôt que par remplacement de systèmes. Cet article explique comment dimensionner le stockage des boîtes aux lettres, quels modèles d’architecture permettent à une plateforme d’atteindre des millions d’utilisateurs et quelles pratiques d’exploitation la gardent maîtrisable. Pour la conception d’ensemble, consultez notre guide sur l’architecture de stockage de la messagerie. Partir d’un modèle de dimensionnement Un modèle utile sépare la capacité de l’activité, car elles évoluent différemment. Données d’entrée de capacité Nombre de boîtes aux lettres, y compris les comptes inactifs qui contiennent encore des données. Taille moyenne d’une boîte, qui varie généralement beaucoup entre comptes grand public gratuits, comptes payants et boîtes professionnelles. Croissance annuelle par boîte, déterminée par le volume de messages entrants et les habitudes de suppression des utilisateurs. Politique de quotas, qui plafonne la croissance de certains utilisateurs mais pas de tous. Surcoût de protection lié au codage à effacement ou à la réplication, plus les copies sur un second site. Conservation des messages supprimés, si ceux-ci sont gardés pendant une période de récupération. Un exemple illustratif : 5 millions de boîtes de 2 Go en moyenne représentent 10 Po de données logiques avant compression ou protection. Si la taille moyenne des boîtes augmente de 15 % par an, la plateforme ajoute 1,5 Po de données logiques la première année. Les chiffres réels varient beaucoup : construisez le modèle à partir de vos propres statistiques de comptes. La méthode générale est décrite dans la planification de la capacité de stockage (en anglais). Données d’entrée d’activité Utilisateurs actifs simultanés en pointe, souvent une petite fraction du total des comptes. Messages délivrés par seconde en pointe. Opérations IMAP par session utilisateur, comme les synchronisations de dossiers, les changements d’indicateurs et les récupérations de messages. Taille moyenne et médiane des messages, car beaucoup de messages sont petits. Taux de suppression et d’expunge. L’activité détermine le nombre de serveurs de messagerie, la taille des caches et le débit de requêtes que le stockage doit soutenir. Une plateforme peut disposer de largement assez de capacité et pourtant peiner si le stockage ne suit pas les petites requêtes en pointe. Supprimer les îlots Le premier obstacle à la montée en charge est généralement le rattachement des utilisateurs à un stockage précis. Si chaque serveur de messagerie ou volume NAS héberge un ensemble fixe d’utilisateurs, chaque étape de croissance impose de placer soigneusement les nouveaux utilisateurs, et chaque rééquilibrage impose de copier des boîtes aux lettres. Les plateformes qui montent bien en charge découplent les utilisateurs du stockage : Une couche proxy ou director oriente chaque utilisateur vers un serveur de messagerie selon un mappage cohérent, généralement un hachage du nom d’utilisateur. Les serveurs de messagerie sont interchangeables et peuvent servir n’importe quel utilisateur, car les données résident sur un stockage partagé. Le stockage forme un seul pool logique, et non un ensemble de volumes séparés. Grâce à cette séparation, ajouter des serveurs de messagerie ajoute de la puissance de traitement, et ajouter des nœuds de stockage ajoute de la capacité, indépendamment l’un de l’autre. Rendre les serveurs de messagerie quasiment sans état Lorsque les serveurs de messagerie ne conservent que des données en cache, la panne d’un serveur devient un incident mineur : ses utilisateurs sont redirigés vers un autre serveur, qui récupère leurs données depuis le stockage. Les architectures de messagerie fondées sur le stockage objet poussent cette logique le plus loin, avec des messages et des lots d’index stockés sous forme d’objets et des disques locaux utilisés uniquement pour les caches. Sur les plateformes fondées sur des fichiers, l’équivalent est un NAS partagé sans aucune donnée sur les disques locaux, mais le verrouillage NFS et les limites de métadonnées deviennent la contrainte suivante à mesure que le nombre d’utilisateurs augmente. Laisser le cache faire le gros du travail La plupart des lectures portent sur les messages récents et les index des utilisateurs actifs. Les caches locaux des serveurs de messagerie absorbent l’essentiel de cette charge : Les caches d’index conservent l’état des dossiers des utilisateurs actifs sur SSD local. Les caches de messages conservent les messages lus récemment en mémoire ou sur SSD. L’affinité utilisateur au niveau de la couche proxy maintient chaque utilisateur sur le même serveur pour que les caches restent chauds. Avec un bon cache, le stockage voit surtout les nouvelles livraisons, les défauts de cache et les envois périodiques d’index, une charge bien plus prévisible que le trafic client brut. Choisir un stockage qui évolue horizontalement À l’échelle de millions d’utilisateurs, le stockage doit gérer des milliards d’objets ou de fichiers, des débits élevés de petites requêtes et une croissance continue de la capacité. Les options sont, dans les grandes lignes : Le NAS scale-up, performant jusqu’à ce que les limites de métadonnées ou de contrôleur soient atteintes, ce qui impose alors une nouvelle baie et une migration. Les systèmes de fichiers scale-out, qui ajoutent des nœuds mais conservent la charge liée aux métadonnées et au verrouillage du système de fichiers. Le stockage objet, qui fait évoluer capacité et traitement des requêtes par ajout de nœuds, sans verrouillage de système de fichiers partagé, et protège les données par codage à effacement. Pour les grandes plateformes de messagerie, le stockage objet est devenu une cible courante, car les messages sont immuables une fois délivrés et se représentent naturellement sous forme d’objets. Prévoir de petits objets et des débits de requêtes élevés La messagerie est une charge de petits objets. Beaucoup de messages pèsent quelques kilo-octets, les lots d’index sont de taille modeste et les suppressions sont permanentes. Lors de l’évaluation d’un stockage, testez : Les débits soutenus de petits PUT et GET avec des tailles d’objets réalistes. Les percentiles de latence, et pas seulement les moyennes, car les valeurs aberrantes lentes dégradent l’expérience utilisateur. Le débit des suppressions et la rapidité de récupération de la capacité. Le comportement lors des pannes de disques et de nœuds, y compris l’impact des reconstructions sur la latence. L’article du blog scality.com sur les performances des requêtes S3 (en anglais) présente les facteurs qui comptent, et celui sur les reconstructions dans le stockage objet (en anglais) explique ce qui se passe lors des pannes matérielles. Monter en charge sur plusieurs sites Les grands fournisseurs exploitent généralement la messagerie sur au moins deux centres de données. Les modèles courants sont : Actif-passif, avec des utilisateurs servis depuis un site et des données répliquées vers un autre pour la reprise après sinistre. Actif-actif par utilisateur, où chaque utilisateur est rattaché à un site et peut basculer vers l’autre. Stockage étendu, où une seule plateforme de stockage objet couvre plusieurs sites, de sorte que les serveurs de messagerie de l’un ou l’autre site peuvent lire les données de n’importe quel utilisateur. Le choix dépend de la latence entre sites, des objectifs de reprise et du coût. Quel que soit le modèle, testez la bascule de site avec de vrais utilisateurs. Maîtriser la croissance par des politiques La croissance du stockage n’est pas qu’une question technique. Parmi les politiques qui la gardent maîtrisable : Des quotas par type de compte, avec des options de passage clair vers les offres payantes. Le nettoyage des comptes inactifs, en supprimant les boîtes non consultées depuis longtemps après avoir prévenu les utilisateurs, conformément aux conditions d’utilisation et au droit de la protection des données. Des limites de conservation des messages supprimés, pour que les périodes de récupération ne deviennent pas un stockage illimité. La compression des messages stockés, qui réduit la capacité pour un coût CPU modeste. Les règles de protection des données comme le RGPD exigent aussi que les données personnelles ne soient pas conservées plus longtemps que nécessaire, ce qui justifie le nettoyage des comptes fermés et abandonnés. Exploiter à grande échelle Les pratiques d’exploitation font la différence entre une plateforme qui grandit sans heurts et une plateforme qui passe d’une crise à l’autre : Superviser chaque couche : routage proxy, charge des serveurs de messagerie, taux de succès des caches et latence du stockage. Automatiser les déplacements d’utilisateurs et le remplacement des serveurs. Ajouter de la capacité par petites étapes, bien avant d’atteindre les seuils. Renouveler le matériel sur place, en remplaçant les anciens nœuds de stockage pendant que le service tourne. Tester la sauvegarde et la restauration, aussi bien pour les restaurations d’un seul utilisateur que pour les incidents plus importants. Check-list : monter en charge le stockage des boîtes aux lettres Construire un modèle de dimensionnement qui sépare capacité et activité. Découpler les utilisateurs du stockage grâce à une couche proxy et à un stockage partagé. Garder les serveurs de messagerie quasiment sans état, en réservant les disques locaux aux caches. Dimensionner les caches pour les utilisateurs actifs en pointe et imposer l’affinité utilisateur. Choisir un stockage qui évolue horizontalement en capacité et en débit de requêtes. Tester les performances sur petits objets, les percentiles de latence et le débit des suppressions. Concevoir l’accès multisite et tester la bascule. Appliquer des politiques de quotas, de nettoyage et de conservation. Automatiser l’exploitation et ajouter de la capacité par petits incréments. En résumé Pour faire monter en charge le stockage des boîtes aux lettres jusqu’à des millions d’utilisateurs, supprimez les îlots qui lient les utilisateurs à des serveurs précis, gardez des serveurs de messagerie légers, laissez le cache absorber le trafic en lecture et placez les données durables sur un stockage qui s’étend par ajout de nœuds. Associez cette architecture à des politiques de croissance et à une exploitation rigoureuse, et la plateforme pourra continuer à grandir sans les migrations lourdes et périodiques qui ont marqué de nombreuses plateformes de messagerie. Si votre plateforme repose aujourd’hui sur du NAS, consultez la migration du stockage de messagerie du NAS vers le stockage objet. Questions fréquentes De combien de stockage un million de boîtes aux lettres ont-elles besoin ? Cela dépend de la taille moyenne des boîtes, de leur croissance et du surcoût de protection. Avec 2 Go par boîte à titre illustratif, un million de boîtes représente environ 2 Po de données logiques avant compression et protection. Qu’est-ce qui limite la montée en charge du stockage de messagerie sur NAS ? En général, les performances des métadonnées avec des milliards de petits fichiers, le verrouillage NFS, les limites des contrôleurs ainsi que le coût et les perturbations des mises à niveau de baies. Pourquoi rendre les serveurs de messagerie sans état ? Pour que n’importe quel serveur puisse servir n’importe quel utilisateur et qu’un serveur en panne puisse être remplacé sans récupération de données, ce qui simplifie la montée en charge et la bascule. Quelle est l’importance du cache pour les plateformes de messagerie ? Elle est très grande. Les caches locaux d’index et de messages absorbent l’essentiel du trafic en lecture, rendent la charge du stockage plus prévisible et maintiennent la réactivité d’IMAP. Le stockage objet convient-il à la messagerie ? Oui. Les messages sont immuables une fois délivrés et se représentent naturellement sous forme d’objets, et le stockage objet évolue jusqu’à des milliards d’objets avec une protection par codage à effacement. Pour aller plus loin Architecture de stockage de la messagerie Archivage ou sauvegarde des e-mails Migrer la messagerie du NAS vers le stockage objet Planification de la capacité de stockage (en anglais)
