Se préparer pour son premier déploiement MongoDB : Capacity Planning et Monitoring

Vous venez d'achever le développement de votre nouvelle application s'appuyant sur MongoDB et vous vous préparez maintenant à déployer en production. Il y a quelques questions sur lesquelles vous devez être en train de vous pencher, en compagnie de vos équipes d'exploitation :

• Quelles sont les bonnes pratiques en matière de déploiement ?
• Quelles sont les métriques clés à superviser pour s'assurer que l'application se conforme aux niveaux de service attendus ?
• Quand pourrez-vous savoir qu'il est nécessaire d'ajouter des shards ?
• Quels sont les outils à disposition pour les sauvegardes et les restaurations de la base ?
• Qu'en est-il de la sécurisation des accès à toutes ces données temps-réel ?

Cet article couvre les sujets du matériel à sélectionner, du scaling, de la haute disponibilité (HA) et du monitoring. Avant d'entrer dans les détails, examinons d'abord quelques-unes des questions les plus fréquentes.

Est-ce que déployer MongoDB est différent du déploiement d'un RDBMS ?

Vous vous apercevrez qu'une base de données orientée document telle que MongoDB partage avec les bases du monde relationnel beaucoup de concepts, de manipulations, de stratégies et de procédures, beaucoup de choses avec lesquelles vous êtes certainement déjà familiers. Les processus et les bonnes pratiques de supervision, d'indexation, de tuning, de sauvegarde, etc. sont applicables à MongoDB. Si vous souhaitez vous attaquer à une formation, des cours en ligne gratuits proposés par des développeurs et des DBAs sont mis à disposition par la MongoDB University.

La performance et le Capacity Planning sont deux sujets importants auxquels tout projet de développement doit s'intéresser, que ce soit pour un RDBMS ou une base NoSQL. Vous devez prévoir notamment des références en matière de volumes de données, de charge du système, de performance (débit et latence) et d'utilisation des ressources. Ces références sont censées refléter le travail que vous souhaitez que votre base réalise en production. Celles-ci devraient être réactualisées périodiquement, particulièrement lorsque le nombre d'utilisateurs, les fonctionnalités applicatives, les SLA sur la performance ou tout autre facteur changent.

Les références vous aideront autant à savoir si le système se comporte comme prévu qu'à détecter les moments où des problèmes pouvant affecter la qualité de l'expérience utilisateur, ou autres facteurs critiques, commencent à émerger.

La section suivante aborde les points clés à considérer dans le cadre d'un déploiement, notamment le matériel, le scaling et la haute disponibilité. Cette section présente aussi les éléments à monitorer pour maintenir une performance optimale du système.

Connaitre son working set

Lorsqu'il s'agit de prioriser le budget pour le hardware lors des déploiements de MongoDB, la RAM devrait être en tête de liste.

MongoDB fait un usage intensif de la RAM pour les opérations à faible latence. Dans MongoDB, tout la donnée est lue et manipulée à travers des fichiers mappés en mémoire. La lecture de données est mesurée en nanosecondes, là où elle l'est en millisecondes lorsqu'elle est lue depuis le disque. En d'autres termes, lire en mémoire est à peu près 100 000 fois plus rapide que lire sur le disque.

Le jeu de données et les index accédés le plus souvent pendant les opérations courantes correspondent à ce que l'on appelle le working set. Idéalement, celui-ci devrait pourvoir tenir en RAM. Il peut arriver que le working set représente une fraction complète de la base de données, comme par exemple dans le cas d'applications où les données les plus fréquemment accédées sont relatives à certains événements récents ou à certains produits populaires.

Des erreurs de page peuvent arriver lorsque MongoDB essaye d'accéder aux données n'ayant pas été chargées en RAM. S'il y a de la mémoire libre, alors le système d'exploitation localisera la page sur le disque et la chargera en mémoire directement. Cependant, s'il n'y a pas d'espace mémoire disponible, le système doit reporter une page se trouvant en mémoire vers le disque avant de placer la page requêtée en mémoire. Ce processus sera plus lent, en comparaison à un accès à la donnée se trouvant déjà en mémoire.

Certaines opérations peuvent par inadvertance induire la purge d'une part importante du working set de la mémoire, et donc pénaliser la performance. Par exemple, une requête effectuant un scan de tous les documents dans la base de données, dans le cas où la base est plus grande que la RAM du serveur, va provoquer un chargement en mémoire des documents et une écriture sur disque du working set. Il faut s'assurer que vos requêtes soient couvertes par les index appropriés au moment de la phase de conception afin d'en minimiser le risque. L'opération MongoDB explain peut être utilisée pour récupérer des informations sur le plan d'exécution et les index utilisés.

Une autre information qui va vous être utile est inclue avec la commande ServerStatus. Il s'agit du working set document, qui fournit une estimation de la taille du working set de l'instance MongoDB. Les équipes d'exploitation peuvent suivre le nombre de pages accédées pour l'instance sur une période donnée et le temps écoulé entre le plus vieux et le plus récent document du working set. En traçant ces métriques, il est possible de détecter quand le working set approche les limites actuelles de la RAM et faire en sorte, de façon proactive, que le système tienne la charge.

Le service MongoDB Management Service et mongostat aident à monitorer l'utilisation de la mémoire. Ceux-ci sont abordés plus en détail ci-dessous.

Le stockage et les I/O disques

Avec MongoDB, il n'est pas nécessaire d'avoir recours à un stockage partagé, comme par exemple des zones de stockage réseau. MongoDB peut utiliser des stockages attachés locaux aussi bien que des Solid State Drives (SSDs).

La plupart des patterns d'accès au disque de MongoDB ne sont pas séquentiels et, par conséquence, les utilisateurs peuvent bénéficier de gains de performance substantiels en utilisant des SSD. SATA SSD et PCI donnent de bons résultats, à des prix intéressants. Les drives mécaniques SATA basiques donnent des résultats comparables à ceux des drives mécaniques plus chers, à cause de la façon non séquentielle d'accéder aux données adoptée par MongoDB. Plutôt que de dépenser pour des drives mécaniques, le budget devrait être utilisé pour de la RAM ou du SSD.

Alors que les fichiers de données vont profiter des SSD, les fichiers de journalisation, eux, seront de bons candidats pour des disques conventionnels rapides, car ceux-ci présentent des caractéristiques d'écriture séquentielle.

La plupart des déploiements MongoDB devraient être faits sur du RAID-10. RAID-5 et RAID-6 n'offrent pas assez de performance. RAID-0 offre de bonnes performances en écriture mais une performance limitée en lecture, ainsi qu'une tolérance de panne insuffisante. Les replica sets de MongoDB, abordés plus bas, permettent de déployer en assurant une meilleure disponibilité des données. Le recours aux working sets, tout comme le recours à RAID ou à d'autres facteurs, devrait être envisagé pour honorer le SLA de disponibilité souhaité.

Si votre système MongoDB devrait être conçu de façon à ce que le working set puisse tenir en mémoire, les I/O disques doivent eux aussi être vus comme des aspects clés de la performance. MongoDB effectue des flushs réguliers des écritures sur le disque et soumet les modifications au journal, de sorte que, sous des conditions de forte charge, le système disque sous-jacent peut être saturé. La commande iostat peut être utilisée pour mettre en évidence une forte sollicitation du disque et des files d'attente excessives pour l'écriture.

La sélection des CPU, de la vitesse ou des cœurs ?

Habituellement, la performance de MongoDB n'est pas limitée par le CPU. Puisque MongoDB est rarement soumis à des charges pouvant avoir des effets sur les cœurs disponibles, souvent nombreux, il est préférable d'opter pour des serveurs avec des vitesses d'horloge élevées plutôt que de nombreux cœurs avec des vitesses d'horloge moindres.

Comme dans tout système, la mesure de l'utilisation CPU est importante. Si on observe une forte utilisation, mais toutefois l'absence d'autres problèmes tels que des disques saturés ou des fautes de pages, il peut y avoir un problème quelque part dans le système. Par exemple, un job MapReduce en boucle infinie ou une requête triant et filtrant un nombre important de documents dans le working set et non couverte par les index, peuvent induire des pics de CPU sans toutefois provoquer de problème au niveau du disque ou des fautes de pages. Des outils de supervision du CPU sont abordés ci-dessous.

Augmenter la capacité de votre base de données : quand, comment ?

MongoDB permet de réaliser un scale-out des bases de données grâce à la technique que l'on appelle sharding. Le sharding distribue les données à travers de multiples partitions physiques appelées shards. Le sharding permet de lever la problématique des limites matérielles auxquelles on est confronté avec un serveur seul, telles que les goulots d'étranglement au niveau de la RAM ou des I/O disques, sans ajouter de complexité au niveau de l'application.

L'auto-sharding de MongoDB

Il est beaucoup plus facile d'implémenter le sharding avant que les ressources du système aient atteint leurs limites. Pour cette raison, le Capacity Planning et un monitoring proactif sont des éléments clés de la réussite pour le scaling de l'application.

Les utilisateurs devraient considérer le déploiement d'un cluster MongoDB avec Sharding dans les situations suivantes :

• Limitation de RAM : la taille du working set actif du système s'approche de la capacité RAM disponible dans le système.
• Limitation des I/O disques : le système doit honorer beaucoup d'écritures et le système d'exploitation ne peut pas écrire assez vite pour répondre à la demande ; et/ou la bande passante des I/O limite la vitesse à laquelle les écritures peuvent être flushées vers le disque.
• Limitation du stockage : le jeu de données s'approche ou va au-delà de la capacité de stockage d'un nœud du système.

Un des objectifs du sharding est de distribuer uniformément les données à travers de multiples serveurs. Si l'utilisation des ressources des serveurs n'est pas à peu près égale, cela peut poser problème pour le déploiement. Par exemple, une clef de sharding mal choisie peut provoquer une distribution inégale des données. Dans ce cas, un grand nombre, si ce n'est toutes les requêtes seront dirigées vers un seul mongod.

De plus, MongoDB peut essayer de redistribuer les documents pour arriver à une meilleure balance entre les serveurs. Même si cette redistribution peut amener à une meilleure répartition des documents, cela représente un travail significatif qui peut empêcher d'atteindre les SLA de performance désirés.

En exécutant db.currentOp(), vous pourrez obtenir une vue du travail réalisé par le cluster, y compris le travail pour effectuer la balance des documents au sein des shards.

Afin d'assurer une distribution uniforme à travers les shards d'un cluster, il est essentiel de sélectionner une clef de sharding adéquate. La documentation MongoDB contient un tutorial pour sélectionner de bonnes clefs de sharding.

La haute disponibilité avec les Replica Sets MongoDB

MongoDB utilise ses mécanismes de réplication natifs pour maintenir de multiples copies des données à travers les replica sets. Les replica sets aident à éviter les coupures de service en détectant les échecs (de serveurs, réseau, OS ou base de données) et en initiant automatiquement un failover. Il est recommandé que tous les déploiements MongoDB soient configurés avec la réplication active.

L'auto-réparation avec les replica sets de MongoDB

Les opérations qui modifient une base sur le nœud primaire sont répliquées sur les secondaires avec un log appelé oplog. Un oplog contient un ensemble ordonné d'opérations idempotentes rejouées sur les secondaires. La taille de l'oplog est configurable ; par défaut elle est fixée à 5% de l'espace disque disponible.

Comme l'illustre l'image ci-dessous, les replicas peuvent être localisés de façon à apporter une tolérance aux défaillances au niveau du serveur, du rack, du datacenter et aux partitionnement réseau.

Le délai de réplication est une des opérations normales à superviser. Il correspond au temps pris pour la réplication d'une opération d'écriture sur le primaire vers un secondaire. Une partie du délai est normale mais, lorsque le retard de réplication grandit, des dysfonctionnements peuvent apparaitre. Les causes classiques de retard de réplication comprennent la latence réseau ou des problèmes de connectivité et des latences disques, comme lorsque le débit des secondaires est inférieur à celui du primaire.

Le statut de réplication, dont le retard de réplication, peut être obtenu avec la commande replSetGetStatus.

Un mot au sujet des logs

En tant que partie intégrante de tout déploiement, les logs de l'application et de la base de données devraient être surveillés pour détecter les erreurs ou autres informations concernant le système. Il est important de corréler les logs de votre application et ceux de la base de données afin de déterminer laquelle des activités de l'application est au bout du compte responsable des dysfonctionnements dans le système. Par exemple, un pic des écritures issues des utilisateurs peut entrainer une hausse des volumes d'écritures vers MongoDB, qui peuvent à leur tour surcharger le système de stockage sous-jacent. Sans la mise en corrélation des logs de l'application et de la base de données, il faudra certainement plus de temps que nécessaire pour établir que c'est l'application qui est responsable de l'augmentation des écritures, et pas quelque autre processus exécuté au sein de MongoDB.

Les outils de monitoring de MongoDB

MongoDB propose plusieurs outils de monitoring vous permettant de gérer de façon proactive les opérations et la performance de vos systèmes.

Le service MongoDB Management Service (MMS)

MongoDB Management Service (MMS) propose un service cloud de monitoring et de backup, pour aider les utilisateurs à optimiser leurs clusters, à dépanner les problèmes de performance et à minorer les risques opérationnels. Le backup MMS sera abordé dans un prochain article.

Le monitoring MMS propose des graphiques, des tableaux de bord personnalisés ainsi que des alertes personnalisées. MMS requiert très peu de setup et de configuration. Les utilisateurs installent un agent local sur toutes les instances mongod. Celui-ci suit des centaines de métriques de santé clés sur l'utilisation de la base de données, dont :

• Les Op Counters : nombre d'opérations exécutées par seconde
• La mémoire : la quantité de mémoire utilisée par MongoDB
• Le Lock Percent : le pourcentage de temps passé sur les verrous en écriture
• Le Background Flush : le temps moyen de flush disque
• Les connexions : le nombre de connexions à MongoDB ouvertes
• Les Queues : le nombre d'opérations en attente d'exécution
• Fautes de pages (Page Fault) : le nombre de fautes de pages du disque
• Réplication : la taille de l'oplog (pour le primaire) et le délai de réplication (sur les secondaires)
• Journal : le volume de données écrit sur le journal

Ces métriques sont reportées de façon sécurisée vers MMS où elles sont traitées, agrégées, où elles donnent lieu à des alertes. Ces données peuvent également être visualisées depuis un navigateur et permettent aux utilisateurs de déterminer facilement la santé de leurs clusters.

Monitoring du Hardware

Munin node est un logiciel open-source pour le monitoring hardware et la création de rapports à partir de métriques comme l'utilisation du disque ou de la RAM. MMS peut collecter ces données depuis Munin node et les proposer avec les autres données disponibles dans le tabeau de bord MMS. Puisque chaque application et chaque déploiement sont uniques, les utilisateurs sont censés créer leurs alertes pour détecter les conditions d'utilisation particulières du disque, les changements majeurs au niveau de l'activité réseau et les augmentations des tailles moyennes et des temps moyens des requêtes.

Le Profiler de la base de données

MongoDB propose des fonctionnalités de profiling avec l'outil Database Profiler. Celui-ci génère des logs d'informations à faible granularité portant sur les opérations effectuées sur la base de données. Le profiler peut être activé de façon à tracer des informations sur tous les évènements ou seulement ceux dont la durée dépasse un certain seuil configurable. La donnée de profiling est stockée dans une collection, dont la taille est plafonnée, et dans laquelle il est facile de rechercher les évènements significatifs : il est souvent plus facile de requêter cette collection plutôt que d'essayer de parser les fichiers de logs.

Autres outils de monitoring

Il existe différents outils de monitoring pouvant donner des éléments de vision additionnels sur votre système MongoDB :

• mongotop est un utilitaire embarqué avec MongoDB qui trace et donne un rapport des activités en cours sur un cluster MongoDB.
• mongostat est un autre utilitaire embarqué avec MongoDB qui fournit un aperçu exhaustif de toutes les opérations, dont le nombre d'updates, d'inserts, de fautes de pages, de défauts d'index (index misses) et de nombreuses autres mesures importantes de la santé du système.
• Des utilitaires Linux tels que iostat, vmstat, netstat et sat peuvent donner des informations de valeur également.
• Pour ceux se trouvant en environnement Windows, le Performance Monitor (snap-in de la console Microsoft Management Console) est utile pour mesurer différentes statistiques.

Pour plus d'information sur les outils de monitoring et sur les choses à monitorer, vous pouvez vous référer à la page Monitoring Database Systems, sur la documentation MongoDB.

Configurer MongoDB

Les utilisateurs ont la possibilité de stocker leurs options de configuration dans le fichier de configuration de mongod. Ceci permet aux administrateurs système d'implémenter des ensembles de configuration consistantes sur tout le cluster. Les fichiers de configuration supportent toutes les options de la ligne de commande pour mongod. Les installations et les montées de version peuvent être automatisées grâce à des outils populaires comme Chef et Puppet. La communauté propose et maintient des scripts pour ces outils.

Une configuration MongoDB classique ressemble à ceci :

• fork = true
• bind_ip = 127.0.0.1
• port = 27017
• quiet = true
• dbpath = /srv/mongodb
• logpath = /var/log/mongodb/mongod.log
• logappend = true
• journal = true

La documentation vous permettra d'en apprendre plus sur les options de configuration de MongoDB.

Les toutes dernières suggestions sur les configurations spécifiques par système d'exploitation, file systems, devices de stockage et autres sujets liés au système sont sur la page des notes de production, dans la documentation MongoDB.

Conclusion

Dans cet article, nous avons mis en lumière le fait que beaucoup de concepts, d'opérations et de processus pour le déploiement de base de données relationnelles peuvent être appliqués directement à MongoDB, tout comme le choix du matériel, les bonnes pratiques de déploiement et le monitoring. Plus de détails sur ces sujets sont disponibles dans le guide MongoDB Operations Guide (ouvre un .pdf).

Au sujet de l'auteur

Mat Keep (@matkeep) fait partie de l'équipe marketing produit de MongoDB. Il est en charge de construire la vision, le positionnement, le contenu des produits et les services MongoDB. Ceci comprend l'analyse des tendances du marché et des attentes des clients. Avant MongoDB, Mat était directeur produit chez Oracle Corp., en charge de MySQL dans les domaines du web, des télécoms, du cloud et big data. Ceci fait suite à une série de postes dans les ventes, le développement business ou en tant qu'analyste programmeur, chez des éditeurs de logiciels et pour des entreprises "utilisateurs finaux".