Comparaison de l'allocation des ressources pour les membres d'un jeu de réplicas par rapport aux nœuds de sharding

La planification des ressources MongoDB change radicalement lorsque l'on passe d'un jeu de réplicas à un cluster shardé. Deux architectures principales facilitent ces objectifs : les jeux de réplicas et les clusters shardés. Bien que les deux soient fondamentaux pour les déploiements MongoDB de niveau production, leurs stratégies d'allocation des ressources sous-jacentes diffèrent considérablement, impactant directement la conception de l'infrastructure et les coûts.

Un jeu de réplicas concentre l'ensemble des données et la majeure partie de la pression d'écriture sur un seul primaire. Un cluster shardé répartit les données sur plusieurs jeux de réplicas de shards, mais ajoute des routeurs mongos et des serveurs de configuration qui nécessitent également de la capacité et une surveillance.

Comprendre les stratégies de déploiement MongoDB

Avant de plonger dans l'allocation des ressources, récapitulons brièvement les rôles de chaque composant dans un jeu de réplicas et un cluster shardé.

Jeux de réplicas : Haute disponibilité et redondance des données

Un jeu de réplicas MongoDB est un groupe d'instances mongod qui maintiennent le même ensemble de données. Cela offre une haute disponibilité et une redondance des données. Un jeu de réplicas se compose généralement de :

Nœud primaire : Le seul nœud qui reçoit toutes les opérations d'écriture. Il enregistre toutes les modifications dans son journal des opérations (oplog). Il ne peut y avoir qu'un seul primaire dans un jeu de réplicas à un moment donné.
Nœuds secondaires : Répliquent l'oplog du primaire et appliquent ces modifications à leurs propres ensembles de données, assurant ainsi la cohérence des données. Les nœuds secondaires peuvent servir des opérations de lecture, selon les paramètres de préférence de lecture, et peuvent être élus comme primaire si le primaire actuel devient indisponible.
Nœud arbitre : Participe aux élections pour déterminer le primaire mais ne stocke pas de données. Les arbitres consomment des ressources minimales et peuvent être utilisés pour ajouter un vote lorsque vous ne pouvez pas déployer un autre membre porteur de données. Ils n'empêchent pas tous les problèmes d'élection et doivent être utilisés avec parcimonie.

Clusters shardés : Évolutivité horizontale

Le sharding est la méthode de MongoDB pour distribuer les données sur plusieurs machines. Cela permet une mise à l'échelle horizontale pour gérer de grands ensembles de données et des opérations à haut débit qu'un seul jeu de réplicas ne peut pas gérer. Un cluster shardé comprend plusieurs composants clés :

Mongos (routeurs de requêtes) : Agissent comme une interface entre les applications clientes et le cluster shardé. Ils acheminent les requêtes vers les shards appropriés, agrègent les résultats et gèrent les connexions.
Serveurs de configuration (CSRS) : Stockent les métadonnées du cluster, y compris les plages de données qui résident sur chaque shard (la 'carte des shards'). Les serveurs de configuration sont déployés en tant que jeu de réplicas (Config Server Replica Set - CSRS) pour une haute disponibilité.
Shards : Chaque shard est lui-même un jeu de réplicas qui contient un sous-ensemble des données du cluster. Les données sont réparties entre ces shards en fonction d'une clé de shard.

Allocation des ressources pour les membres d'un jeu de réplicas

Les besoins en ressources des membres d'un jeu de réplicas varient considérablement en fonction de leur rôle et de la charge de travail globale.

Nœud primaire

Le nœud primaire est le membre le plus critique et le plus gourmand en ressources d'un jeu de réplicas, car il gère toutes les opérations d'écriture et généralement la plupart des opérations de lecture.

CPU : Élevé. Les charges de travail intensives en écriture, les pipelines d'agrégation complexes, les opérations d'indexation et la gestion de nombreuses connexions simultanées exigent une puissance CPU importante. Si votre application met fréquemment à jour des documents ou effectue des requêtes intensives, le CPU du primaire peut rapidement devenir un goulot d'étranglement.
RAM : Critique. Le moteur de stockage WiredTiger de MongoDB dépend fortement de la RAM pour son cache. Le primaire a besoin de suffisamment de RAM pour conserver les données et les index fréquemment consultés en mémoire afin de minimiser les E/S disque. Une recommandation courante est d'allouer suffisamment de RAM pour contenir votre ensemble de travail (les données et les index activement utilisés par vos applications) plus une certaine marge.
Stockage : IOPS et débit élevés. Toutes les opérations d'écriture touchent le disque du primaire, y compris la journalisation. Un stockage rapide (SSD/NVMe) avec des IOPS (opérations d'entrée/sortie par seconde) élevés est essentiel pour éviter que la latence d'écriture ne devienne un goulot d'étranglement. La capacité doit être suffisante pour l'ensemble des données et leur croissance, plus l'espace pour l'oplog.

Nœuds secondaires

Les nœuds secondaires répliquent les données du primaire et peuvent servir des requêtes de lecture, déchargeant ainsi le primaire. Leurs besoins en ressources sont souvent similaires à ceux du primaire, surtout s'ils gèrent des lectures.

CPU : Modéré à élevé. L'utilisation du CPU dépend du taux de réplication et de la charge de travail en lecture. Si les secondaires gèrent une part importante des lectures, leurs besoins en CPU peuvent se rapprocher de ceux du primaire. S'ils sont principalement destinés à la réplication et au basculement, l'utilisation du CPU sera plus faible mais reste importante pour appliquer efficacement les entrées de l'oplog.
RAM : Critique. Comme le primaire, les secondaires maintiennent un cache WiredTiger et ont besoin de suffisamment de RAM pour contenir l'ensemble de travail afin d'appliquer efficacement les entrées de l'oplog et de servir les lectures sans E/S disque excessives. Le cache d'un secondaire devrait idéalement refléter celui du primaire pour des performances constantes lors d'un basculement.
Stockage : IOPS et débit élevés. Les secondaires doivent suivre le rythme des écritures du primaire en appliquant les entrées de l'oplog. Cela exige également des performances d'E/S élevées. La capacité doit être identique à celle du primaire, car ils stockent une copie complète des données.

Astuce : Assurez-vous que les nœuds secondaires sont provisionnés de manière similaire au primaire. Cela garantit un basculement fluide et des performances constantes lorsqu'un secondaire devient primaire.

Nœud arbitre

Les arbitres sont des nœuds légers uniquement destinés à participer aux élections. Ils ne stockent pas de données et ne servent pas d'opérations de lecture/écriture.

CPU : Très faible. Les arbitres effectuent un minimum de calculs liés aux protocoles d'élection.
RAM : Très faible. Nécessite seulement suffisamment de mémoire pour les frais généraux de base du processus mongod et l'état de l'élection.
Stockage : Très faible. Stocke uniquement des fichiers de configuration et des journaux minimes, pas de fichiers de données.

Avertissement : N'exécutez jamais une application ou d'autres processus de base de données sur un nœud arbitre. Il doit s'agir d'une instance dédiée et minimale pour garantir sa disponibilité pour les élections et éviter la contention des ressources.

Allocation des ressources pour les composants de sharding

Les clusters shardés introduisent des composants supplémentaires, chacun avec des profils de ressources uniques, conduisant à une stratégie d'allocation des ressources plus distribuée et complexe.

Mongos (routeurs de requêtes)

Les instances mongos sont des processus de routage sans état. Elles ne stockent pas de données mais coordonnent les opérations entre les shards.

CPU : Modéré à élevé. L'utilisation du CPU augmente avec le nombre de connexions client, le travail de routage des requêtes, les requêtes scatter-gather et le travail de fusion d'agrégation que mongos doit coordonner. Plus d'instances mongos peuvent être ajoutées pour gérer des charges plus élevées.
RAM : Modérée. Principalement utilisée pour la gestion des connexions, la mise en cache des métadonnées des serveurs de configuration (carte des shards) et les tampons d'agrégation temporaires. Pas aussi critique que les nœuds porteurs de données, mais une RAM suffisante empêche le swapping et garantit des temps de réponse rapides.
Stockage : Très faible. Seuls les journaux sont stockés. Les SSD locaux sont généralement plus que suffisants.

Astuce : Pour des performances optimales, déployez les instances mongos près de vos serveurs d'application afin de minimiser la latence réseau.

Serveurs de configuration (Config Server Replica Set - CSRS)

Les serveurs de configuration sont cruciaux pour le fonctionnement du cluster shardé, stockant les métadonnées sur l'état du cluster. Ils sont toujours déployés en tant que jeu de réplicas (CSRS).

CPU : Modéré. L'utilisation du CPU peut augmenter lors des migrations de chunks, du rééquilibrage des shards ou des mises à jour fréquentes des métadonnées. Bien que pas aussi élevé que celui d'un primaire porteur de données, des performances constantes sont vitales.
RAM : Modérée à élevée. Nécessite suffisamment de RAM pour conserver les métadonnées critiques du cluster en mémoire. La taille des métadonnées dépend du nombre de shards, de chunks et de bases de données. Une RAM insuffisante peut gravement dégrader les performances et la stabilité du cluster.
Stockage : IOPS et capacité modérés. Bien que la taille des métadonnées soit généralement plus petite que celle des données utilisateur, les mises à jour de la carte des shards et d'autres informations sur l'état du cluster peuvent être fréquentes, nécessitant des performances d'E/S décentes. La capacité doit s'adapter à la croissance des métadonnées et de l'oplog.

Avertissement : Les performances et la disponibilité de vos serveurs de configuration sont primordiales. Toute dégradation peut paralyser l'ensemble de votre cluster shardé. Provisionnez-les avec une infrastructure hautement fiable et performante.

Membres d'un shard (jeux de réplicas porteurs de données)

Chaque shard est un jeu de réplicas autonome, stockant un sous-ensemble des données totales du cluster. Par conséquent, les besoins en ressources pour les nœuds primaire, secondaire et arbitre au sein de chaque shard sont similaires en nature à ceux d'un jeu de réplicas autonome, mais adaptés à la portion de données qu'ils détiennent.

CPU : Élevé pour le primaire, Modéré à élevé pour les secondaires. Le primaire de chaque shard gère toutes les écritures et potentiellement les lectures pour son sous-ensemble de données. Les demandes sont proportionnelles à la charge de travail acheminée vers ce shard spécifique.
RAM : Critique pour le primaire et les secondaires. Chaque mongod de shard a besoin de suffisamment de RAM pour son cache WiredTiger, proportionnellement à l'ensemble de travail des données qu'il stocke. Ceci est crucial pour les performances dans son segment de données.
Stockage : IOPS et débit élevés pour le primaire et les secondaires. Comme pour un jeu de réplicas autonome, un stockage rapide est nécessaire pour gérer les écritures, les lectures et la réplication pour le sous-ensemble de données du shard. La capacité doit être suffisante pour la portion de données du shard et sa croissance.

Différence clé : Bien qu'un jeu de réplicas de shard individuel ait des exigences similaires à un jeu de réplicas autonome, le cluster shardé global distribue les données totales et la charge de travail sur plusieurs de ces jeux de réplicas. Cela signifie que la somme des ressources sur tous les shards sera significativement plus grande que celle d'un seul jeu de réplicas mis à l'échelle verticalement.

Comparaison de l'allocation des ressources : Jeu de réplicas vs. Cluster shardé

Fonctionnalité	Jeu de réplicas (autonome)	Cluster shardé
Objectif	Haute disponibilité, Redondance des données, Mise à l'échelle modérée	Mise à l'échelle horizontale, Très grands ensembles de données, Haut débit
Nœuds totaux	Généralement 3 membres porteurs de données ; arbitres uniquement si nécessaire	3 serveurs de configuration + N jeux de réplicas de shards (généralement 3+ membres chacun) + M instances Mongos
CPU	Le primaire gère tout le CPU d'écriture. Les secondaires gèrent le CPU de lecture. Arbitre minimal.	Distribué entre `mongos`, serveurs de configuration et plusieurs primaires de shards. CPU total global plus élevé.
RAM	Le primaire et les secondaires ont besoin de RAM pour l'ensemble de l'ensemble de travail.	Chaque primaire/secondaire de shard a besoin de RAM pour son sous-ensemble de l'ensemble de travail. Les serveurs de configuration ont besoin de RAM pour les métadonnées. RAM totale globale plus élevée.
Stockage	Le primaire et les secondaires ont besoin de capacité et d'IOPS pour l'ensemble de l'ensemble de données.	Chaque primaire/secondaire de shard a besoin de capacité et d'IOPS pour son sous-ensemble de l'ensemble de données. Les serveurs de configuration ont besoin d'IOPS/capacité modérés. Stockage total global plus élevé.
Goulot d'étranglement	Nœud primaire pour les écritures ; limites de ressources d'une seule machine.	Tout composant (`mongos`, serveurs de configuration ou un shard individuel) peut devenir un goulot d'étranglement s'il est sous-provisionné.
Complexité	Relativement plus simple à configurer et à gérer.	Significativement plus complexe à planifier, déployer et gérer.
Coût	Coût d'infrastructure plus faible pour une échelle modérée.	Coût d'infrastructure plus élevé en raison du plus grand nombre d'instances et de la nature distribuée.

Considérations pratiques et meilleures pratiques

Analyse de la charge de travail : Comprenez parfaitement les modèles de lecture/écriture de votre application, les projections de croissance des données et la complexité des requêtes. C'est le facteur le plus important dans la planification des ressources.
La surveillance est essentielle : Mettez en place une surveillance complète pour tous les composants MongoDB (CPU, RAM, E/S disque, réseau, métriques de base de données comme l'utilisation du cache WiredTiger, le décalage de l'oplog, les temps de requête). Cela aide à identifier les goulots d'étranglement et permet une mise à l'échelle proactive.
Performances réseau : Pour les clusters shardés, la latence réseau et la bande passante entre mongos, les serveurs de configuration et les shards sont critiques. La communication inter-shards et les opérations d'équilibrage des données peuvent être fortement impactées par de mauvaises performances réseau.
Ressources dédiées : Chaque processus mongod, qu'il soit primaire, secondaire ou membre d'un shard, doit s'exécuter sur du matériel dédié ou une machine virtuelle dédiée. Évitez de les colocaliser avec des serveurs d'application ou d'autres instances de base de données pour éviter la contention des ressources.
Cloud vs. Sur site : Les fournisseurs de cloud offrent une flexibilité pour faire évoluer facilement les ressources. Cependant, assurez-vous que les types d'instances choisis répondent aux exigences d'IOPS et de débit, en particulier pour les opérations intensives en stockage.
Tests et benchmarking : Testez toujours votre infrastructure planifiée avec des charges de travail réalistes avant de passer en production. Cela permet de valider vos hypothèses d'allocation des ressources.

À retenir

Utilisez un jeu de réplicas lorsque votre ensemble de travail, votre taux d'écriture et votre stockage tiennent confortablement sur une seule classe de nœud porteur de données. Passez au sharding lorsque vous avez besoin d'une échelle horizontale, mais prévoyez un budget pour les pièces mobiles supplémentaires : jeux de réplicas de shards, serveurs de configuration, routeurs, capacité réseau et plus de tests opérationnels.