Planification de capacité MongoDB avec exemples pratiques : guide d'implémentation étape par étape

La planification de capacité est la discipline qui consiste à prévoir et provisionner les ressources de calcul, de mémoire, de stockage et de réseau dont votre déploiement MongoDB a besoin pour atteindre vos objectifs de performance et de fiabilité avec des marges de sécurité. Bien réalisée, elle évite les urgences de dernière minute, maîtrise les coûts et trace une trajectoire claire pour le passage à l'échelle. Ce guide propose une approche pratique, étape par étape, avec des exemples construits, des vérifications observables et des scénarios de récupération applicables aux serveurs autonomes, aux jeux de réplication ou aux clusters partagés.

Ce que vous apprendrez :

• Comment inventorier les versions, la topologie et les fondamentaux de la charge de travail qui comptent pour le dimensionnement.
• Comment estimer le CPU, la mémoire, le stockage et les E/S avec des marges de sécurité.
• Comment reconnaître les signaux de passage à l'échelle et choisir entre montée en puissance verticale, réplication et partitionnement.
• Comment vérifier les résultats avec des métriques observables et des commandes simples.
• Comment gérer les modes de défaillance courants et revenir en arrière en toute sécurité.
• Une liste de contrôle concise pour garder les opérations sur les rails.

Public visé : développeurs, consultants DevOps et équipes techniques de startups qui conçoivent ou font évoluer des services s'appuyant sur MongoDB, y compris les API Node.js et Express.

Prérequis : familiarité de base avec les collections et les index MongoDB, accès shell aux hôtes de base de données, et capacité à exécuter mongosh et les outils système de base sur ces hôtes.

Inventaire des versions et de l'environnement

Avant d'estimer, documentez ce que vous possédez. Cela évite de dimensionner sur des suppositions et rend les comparaisons reproductibles.

Prérequis :

• Accès shell aux hôtes de base de données.
• mongosh disponible.
• Permissions pour exécuter des commandes de diagnostic en lecture seule.

Étapes d'inventaire (à exécuter depuis un hôte d'administration de confiance ou un bastion) :

1. Enregistrer les versions du serveur MongoDB et du shell :

   mongosh --eval "db.version()"
   mongod --version

1. Identifier la topologie :

• Jeu de réplication :

     mongosh --eval "rs.status().members.map(m => ({name: m.name, stateStr: m.stateStr}))"

• Aperçu du cluster partagé (depuis mongos) :

     mongosh --eval "sh.status()"

1. Collecter les marqueurs d'échelle de la charge de travail (exemples de commandes construits) :

• Statistiques de stockage au niveau base de données :

     mongosh --eval "db.stats({scale:1024})"

• Statistiques par collection (remplacez par votre collection) :

     mongosh --eval "db.getSiblingDB('app').getCollection('orders').stats({scale:1024})"

• Détails des index pour les collections chaudes :

     mongosh --eval "db.getSiblingDB('app').getCollection('orders').stats({indexDetails: true})"

• Instantané des métriques serveur :

     mongosh --eval "db.serverStatus()"

1. Vérifier la santé de la réplication (jeux de réplication) :

   mongosh --eval "rs.printSlaveReplicationInfo()"

1. Taille et marge de l'oplog (primaire) :

   mongosh --eval "db.getSiblingDB('local').getCollection('oplog.rs').stats({scale:1024})"

1. Marge au niveau OS (à exécuter sur l'hôte ; exemples construits) :

   mpstat 1 5
   nproc
   free -m
   df -h
   iostat -x 1 5

Consignez ces données dans un enregistrement daté. Pour la reproductibilité, exécutez les mêmes commandes pendant les fenêtres de charge typique et de pointe.

Chemin de configuration sécurisé

Cette section fournit un chemin pragmatique pour choisir les cibles de ressources et les tactiques de passage à l'échelle avec des marges de sécurité. Tous les exemples sont construits et utilisent des chiffres hypothétiques pour illustrer la méthode.

1. Définir les cibles de service et les bornes

• Cibles de latence : par exemple, p95 lecture < 20 ms et p95 écriture < 30 ms en pointe.
• Disponibilité : par exemple, >= 99,9 % mensuel.
• Horizon de croissance : par exemple, planifier sur 12 mois avec un tampon d'incertitude de 30 %.

2. Estimer la taille des données et la croissance (feuille de travail construite)

Données que vous rassemblez :

• Taille moyenne des documents pour les collections chaudes.
• Volume d'écriture quotidien (nouveaux documents + mises à jour avec impact sur la croissance).
• Période de rétention.
• Empreinte d'index par collection chaude.

Formule de stockage simple (construite) :

• Taille totale des données = somme(octets des documents des collections chaudes + octets des index)
• Croissance mensuelle = croissance nette quotidienne * 30
• Capacité provisionnée = (taille actuelle + croissance sur l'horizon) * facteur de sécurité (par ex., 1,3)

Exemple (hypothétique) :

• Collection orders : 5 millions de documents à 2,5 Ko en moyenne -> ~12,5 Go de données.
• Index sur {userId}, {status, createdAt} : combinés ~6 Go.
• Autres collections nettes à 8 Go de données + 4 Go d'index.
• Total actuel : ~30,5 Go.
• Croissance nette quotidienne : 150 000 documents à 2,5 Ko -> ~0,36 Go/jour de données ; index +0,18 Go/jour -> ~0,54 Go/jour.
• Croissance sur 12 mois : ~0,54 * 365 = ~197 Go.
• Capacité provisionnée : (30,5 + 197) * 1,3 = ~295 Go.
• Arrondir au palier de stockage supérieur avec marge de performance.

3. Mémoire et ensemble de travail

Visez à maintenir l'ensemble de travail chaud en RAM avec marge pour l'activité de fond et les pics.

Approximation de l'ensemble de travail (construite) :

• Documents actifs pendant l'heure de pointe + leurs index.
• Si la fraction active est 20 % des orders et 50 % des sessions :
• Orders actifs : 1 million de docs * (2,5 Ko + part d'index 1,2 Ko) ~ 3,7 Go.
• Sessions actives : 500 k docs * (1,0 Ko + index 0,6 Ko) ~ 0,8 Go.
• Autres actifs : ~1,0 Go.
• Ensemble de travail ~5,5 Go.

Cible mémoire :

• OS + surcoût MongoDB (construit) ~4-6 Go pour utilitaires et cache système de fichiers.
• RAM cible = 2x ensemble de travail + surcoût -> ~17 Go ; choisir 32 Go pour garder une forte marge et la croissance future.

4. CPU et concurrence

• Suivre les ops/sec de pointe et la complexité typique des requêtes.
• Partir sur une cible de CPU soutenu < 60 % sur les primaires, < 40 % sur les secondaires utilisés pour la lecture. Cela garde de la marge pour les élections, les compactations et les rafales.
• Si vous exécutez des agrégations CPU-intensives, envisagez de les déplacer vers les secondaires (si acceptable) ou d'ajouter des nœuds/partitions dédiés à ces charges.

5. Disque et E/S

• Choisir un stockage capable de délivrer les IOPS aléatoires en lecture/écriture et la faible latence dont votre charge a besoin.
• Budget E/S simple (construit) :
• Mesurer les ops/sec de pointe et estimer l'amplification lecture/écriture (par ex., 1-3x par opération, plus avec beaucoup d'index).
• S'assurer que les IOPS provisionnés dépassent le besoin de pointe de 30-50 %.
• Maintenir la latence d'écriture p95 bien en dessous de votre cible (par ex., < 5 ms latence dispositif pour un p95 DB confortable).

6. Dimensionnement de l'oplog (jeux de réplication)

Dimensionnez l'oplog pour qu'il conserve au moins plusieurs heures de trafic d'écriture de pointe, plus une marge pour absorber les pannes et les fenêtres de maintenance. Par exemple, si le taux d'insertion+mise à jour soutenu en pointe est de 30 Go/jour, assurez-vous que l'oplog dépasse confortablement la quantité générée pendant votre plus longue fenêtre de basculement (exemple construit : 12 heures -> > 15 Go, arrondir à 32 Go+).

7. Impacts de la stratégie d'indexation

• Chaque index additionnel augmente l'amplification d'écriture et la pression mémoire.
• Privilégier les index composés qui correspondent à vos motifs de requêtes ; éviter les index mono-champ chevauchants qui n'aident pas.
• Valider périodiquement que les index sont utilisés en échantillonnant les plans de requête.

8. Choix de passage à l'échelle et garde-fous

• Verticale d'abord : monter CPU/RAM/IOPS jusqu'à ce qu'une ressource approche 60-70 % soutenu en pointe.
• Réplication pour la disponibilité, la montée en charge de lecture et l'isolation des charges de reporting.
• Partitionnement quand un primaire unique ne suit plus l'échelle d'écriture ou de données ; choisir une clé de partition qui répartit uniformément les écritures et supporte vos requêtes les plus chaudes.
• Tester toujours la cardinalité et la monotonie de la clé de partition pour éviter les partitions chaudes.

9. Marges de sécurité communicables

• Cible de capacité = prévision + tampon d'incertitude (couramment 20-50 % selon la volatilité).
• Seuils d'alerte :
• Avertissement à 60-70 % d'utilisation soutenue ; critique à 80-90 % soutenu ou approche rapide de l'épuisement.

Tableau de synthèse du dimensionnement (exemple construit) :

Vérification et diagnostics

Après avoir dimensionné et configuré, vérifiez avec des signaux observables. Exécutez les contrôles pendant les fenêtres typiques et de pointe.

Contrôles et commandes clés (exemples construits) :

1. Latence et débit

• Capturer les métriques depuis la couche applicative et le driver (p. ex., latences p50/p95, ops/sec par route).
• Au niveau base de données, vérifier les taux d'opérations globaux :

  mongosh --eval "db.serverStatus().opcounters"

2. Mémoire et santé du cache (WiredTiger)

mongosh --eval "db.serverStatus().wiredTiger.cache"

Examiner :

• Octets actuellement dans le cache vs taille de cache configurée.
• Activité d'éviction : éviction soutenue élevée sous charge stable suggère une pression sur le cache.

3. Connexions et files d'attente

mongosh --eval "db.serverStatus().connections"

Surveiller les connexions approchant les limites configurées ou les pics importants.

4. Réplication

mongosh --eval "rs.printSlaveReplicationInfo()"

Le retard de réplication doit être proche de zéro en état stable et rester dans vos objectifs de point de récupération pendant les pointes.

5. Utilisation des index et formes de requêtes

• Échantillonner les plans d'exécution :

  mongosh --eval "db.getSiblingDB('app').orders.find({userId: 'U123', createdAt: {$gte: ISODate('2026-01-01')}}).hint({userId:1, createdAt:1}).explain('executionStats')"

• Activer le profileur (fenêtre courte en test hors pointe) pour attraper les opérations lentes :

  mongosh --eval "db.setProfilingLevel(1, 50)" # journaliser les ops > 50 ms
  # ... exécuter la charge 10-15 minutes ...
  mongosh --eval "db.system.profile.find().limit(5).pretty()"
  mongosh --eval "db.setProfilingLevel(0)"

6. Disque et système de fichiers

E/S au niveau hôte (échantillon) :

iostat -x 1 10

Surveiller les temps d'attente élevés et l'utilisation saturée pendant les pics DB.

7. Consommation de l'oplog

mongosh --eval "db.getSiblingDB('local').oplog.rs.stats({scale:1024})"

S'assurer que la fenêtre de l'oplog (intervalle temporel couvert) dépasse vos besoins opérationnels.

Signaux de passage à l'échelle et actions indicatives (construits) :

Résultats attendus si la capacité est adéquate :

• Latences p95 dans les cibles sous pointe.
• Retard de réplication proche de zéro avec pics transitoires qui se résorbent vite.
• Éviction cache non corrélée à des augmentations persistantes de latence.
• Utilisation dispositif et temps d'attente confortablement sous saturation.

Si les résultats ne sont pas atteints, ajustez un facteur à la fois et re-vérifiez pour isoler l'effet.

Modes de défaillance et récupération

Les manques de capacité surgissent souvent brutalement en pointe. Préparez des scénarios avec des actions simples et réversibles.

1. Pression mémoire et agitation du cache

Symptômes :

• Pics d'évictions cache, lectures de pages accrues, latences p95 en hausse.

Actions immédiates :

• Réduire l'ensemble de travail chaud : désactiver temporairement ou baisser les fonctionnalités à fort trafic causant des balayages larges.
• Déplacer le reporting ou les agrégations lourdes vers les secondaires (si acceptable pour vos besoins de cohérence).
• Augmenter la RAM de l'instance si possible.

Vérification :

• Métriques d'éviction stabilisées et latences en baisse.

Retour arrière :

• Si vous avez modifié des paramètres de cache et observé des régressions, restaurer les réglages précédents et retester.

2. Saturation disque et blocages d'écriture

Symptômes :

• Temps d'attente dispositif élevés, latences d'écriture en hausse, retard de réplication croissant.

Actions immédiates :

• Monter le niveau de performance de stockage ou provisionner des IOPS supplémentaires.
• Limiter les travaux en masse (rechargements, réindexations) aux fenêtres creuses.
• S'assurer que la journalisation et les choix de système de fichiers sont alignés sur les objectifs de performance.

Vérification :

• Attente dispositif en baisse ; latences d'écriture DB améliorées ; retard résorbé.

Retour arrière :

• Si un changement de stockage régresse, revenir au niveau précédent et re-planifier la migration en maintenance.

3. Saturation CPU et croissance des files

Symptômes :

• CPU > 80 % soutenu ; requêtes lentes s'accumulent ; timeouts driver.

Actions immédiates :

• Identifier les opérations lentes principales ; ajouter ou ajuster les index pour les chemins les plus chauds.
• Augmenter les vCPU ou monter en charge les lectures vers les secondaires.

Vérification :

• File réduite, CPU plus bas, p95 amélioré.

Retour arrière :

• Si un nouvel index augmente les coûts d'écriture sans bénéfice, le supprimer.

4. Retard de réplication et risque de basculement

Symptômes :

• Secondes à minutes de retard pendant les pointes ; secondaires ne suivent plus.

Actions immédiates :

• Améliorer E/S et CPU des secondaires ; décharger lecture/reporting ; agrandir l'oplog pour tamponner les pics.
• Éviter la maintenance qui ralentirait davantage les secondaires jusqu'à résorption du retard.

Vérification :

• Retard reste dans la cible pendant la pointe.

Retour arrière :

• Si un oplog plus grand cause une pression de stockage, le réduire après normalisation du trafic et extension des disques.

5. Partition chaude ou clé de partition monotone

Symptômes :

• Une partition porte une charge disproportionnée ; migrations de chunks thrashent.

Actions immédiates :

• Ajouter des fenêtres d'équilibrage ; envisager une re-partition avec une clé à cardinalité plus haute ou hachée.

Vérification :

• Répartition de charge équilibrée ; équilibrage stabilisé.

Retour arrière :

• Si un plan de re-partition dégrade les requêtes, revenir à l'ancienne clé seulement après un plan de migration testé ; sinon, ajuster les index sur la nouvelle clé.

6. Scénarios disque plein

Symptômes :

• Écritures échouent ; réplication bloquée ; journaux montrent erreurs d'espace insuffisant.

Actions immédiates :

• Libérer de l'espace (supprimer fichiers temporaires, anciens logs), étendre le volume, ou déplacer le chemin de données vers un volume plus grand.
• Réduire temporairement le trafic d'écriture si possible.

Vérification :

• Écritures reprises ; pas d'erreurs de journal ou de point de contrôle.

Retour arrière :

• Si le déplacement des chemins de données cause des problèmes, revenir au montage connu-bon avec espace suffisant pendant la maintenance.

Contrôles de récupération après tout changement :

• Latences p95 revenues dans les cibles sur périodes soutenues.
• Pas d'augmentation du taux d'erreur au niveau application ou driver.
• Réplication saine et élections sans battement.
• Sauvegardes toujours complétées dans leurs fenêtres.

Liste de contrôle opérationnelle

Utilisez cette liste pour garder la capacité alignée avec la croissance. Adaptez les intervalles à votre rythme de changement.

Hebdomadaire

• Revoir latences p95, débit et taux d'erreur depuis la couche applicative.
• Vérifier ponctuellement les plans d'exécution pour les requêtes principales.
• Vérifier que le retard de réplication reste dans la cible pendant les pointes.

Mensuel

• Rafraîchir les statistiques de taille de données et d'index pour les collections chaudes.
• Comparer croissance observée vs prévision ; mettre à jour les perspectives 3-6 mois.
• Valider les hypothèses d'ensemble de travail contre les métriques de cache.
• Confirmer espace libre stockage > 30 % et marge IOPS > 30 % sous pointe.
• Auditer le jeu d'index pour redondance ; supprimer les index inutilisés après vérification.

Trimestriel

• Test de charge d'un scénario pilote étroit et mesurable représentatif de la pointe (test construit) :
• Choisir 1-2 endpoints les plus chauds.
• Rejouer un volume de trafic réaliste avec formes de requêtes capturées.
• Valider cibles de latence et d'erreur, puis ajuster les plans de capacité.
• Réévaluer la pertinence de la clé de partition si la croissance est décalée.
• Essai à blanc de récupération et de restauration de sauvegardes.

Gestion des changements

• Appliquer un changement à la fois et mesurer.
• Garder un plan de retour arrière pour les changements de configuration, d'index et de topologie.
• Documenter décisions, seuils et résultats pour les revues futures.

Tableau d'exemple de revue de capacité (construit) :

Conclusion

La planification de capacité pour MongoDB n'est pas une estimation unique ; c'est une pratique itérative qui transforme le comportement observé de la charge de travail en plans provisionnés, testables et dotés de marges de sécurité. Commencez par un inventaire clair, dimensionnez le stockage et la mémoire autour de l'ensemble de travail, maintenez le CPU et les E/S dans des marges confortables, et choisissez l'étape de passage à l'échelle la plus simple qui préserve vos cibles. Vérifiez avec des métriques concrètes et des commandes simples, et tenez-vous prêts avec des scénarios de récupération pour les modes de défaillance courants que vous rencontrerez à l'échelle. En revisitant ces étapes à intervalles réguliers et en pilotant les changements dans des scénarios étroits et mesurables d'abord, vous réduirez la reprise de travail, maintiendrez le risque bas et conserverez une performance prévisible à mesure que vos données et votre trafic croissent.