Comparaison de l'allocation des ressources pour les membres de Replica Set vs les Nœuds Shardés

MongoDB offre des solutions robustes pour la persistance des données, la haute disponibilité et la scalabilité. Deux architectures principales facilitent ces objectifs : les Replica Sets et les Clusters Shardés. Bien que les deux soient fondamentaux pour les déploiements MongoDB en production, leurs stratégies d'allocation de ressources sous-jacentes diffèrent significativement, impactant directement la conception de l'infrastructure et les coûts.

Cet article explore une comparaison détaillée des exigences matérielles — spécifiquement CPU, RAM et stockage — pour divers composants MongoDB. Nous examinerons les besoins des nœuds primaire, secondaire et arbitre au sein d'un replica set, contrastés avec les exigences distinctes des routeurs de requête mongos, des serveurs de configuration et des membres de shard individuels dans un cluster shardé. Comprendre ces différences est crucial pour prendre des décisions éclairées concernant la configuration de l'infrastructure, garantissant des performances optimales, une scalabilité et une efficacité des coûts pour votre déploiement MongoDB.

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 Replica Set et un Sharded Cluster.

Replica Sets : Haute Disponibilité et Redondance des Données

Un replica set MongoDB est un groupe d'instances mongod qui maintiennent le même ensemble de données. Ceci assure la haute disponibilité et la redondance des données. Un replica set se compose typiquement de :

• Nœud Primaire : Le seul nœud qui reçoit toutes les opérations d'écriture. Il enregistre tous les changements dans son journal des opérations (oplog). Il ne peut y avoir qu'un seul primaire dans un replica set à un instant donné.
• Nœuds Secondaires : Répliquent l'oplog du primaire et appliquent ces changements à leurs propres ensembles de données, assurant 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 un minimum de ressources et sont utilisés pour fournir un nombre impair de membres votants dans un replica set afin de prévenir les scénarios d'égalité lors des élections.

Sharded Clusters : Scalabilité 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 très grands ensembles de données et des opérations à haut débit qu'un seul replica set ne peut 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 quelles plages de données résident sur quels shards (la 'shard map'). Les serveurs de configuration sont déployés sous forme de replica set (Config Server Replica Set - CSRS) pour la haute disponibilité.
• Shards : Chaque shard est lui-même un replica set qui détient un sous-ensemble des données du cluster. Les données sont distribuées sur ces shards en fonction d'une clé de shard.

Allocation des Ressources pour les Membres de Replica Set

Les exigences en ressources pour les membres de replica set varient significativement 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 replica set, 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 à forte intensité d'écriture, les pipelines d'agrégation complexes, les opérations d'indexation et la gestion de nombreuses connexions concurrentes exigent une puissance CPU significative. 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 contenir les données et les index fréquemment accédés en mémoire afin de minimiser les E/S disque. Une recommandation courante est d'allouer suffisamment de RAM pour contenir votre jeu de travail (les données et index activement utilisés par vos applications) plus un certain tampon.
• Stockage : IOPS et débit élevés. Toutes les opérations d'écriture atteignent 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 sa croissance, plus l'espace 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 lecture. Si les secondaires gèrent une partie importante des lectures, leurs exigences en CPU peuvent approcher celles du primaire. S'ils sont principalement dédiés à la réplication et au basculement (failover), l'utilisation du CPU sera plus faible, mais toujours importante pour appliquer efficacement les entrées d'oplog.
• RAM : Critique. Semblables au primaire, les secondaires maintiennent un cache WiredTiger et ont besoin de suffisamment de RAM pour contenir le jeu de travail afin d'appliquer efficacement les entrées d'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 cohérentes lors du basculement.
• Stockage : IOPS et débit élevés. Les secondaires doivent suivre les écritures du primaire en appliquant les entrées d'oplog. Cela exige également des performances 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 cohérentes lorsqu'un secondaire devient primaire.

Nœud Arbitre

Les arbitres sont des nœuds légers servant uniquement à 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 calcul minimal lié aux protocoles d'élection.
• RAM : Très Faible. Ne nécessite que la mémoire suffisante pour la surcharge de base du processus mongod et l'état de l'élection.
• Stockage : Très Faible. Ne stocke que la configuration minimale et les fichiers journaux, pas de fichiers de données.

Attention : N'exécutez jamais d'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 prévenir 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, menant à une stratégie d'allocation de ressources plus distribuée et complexe.

Mongos (Routeurs de Requêtes)

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

• CPU : Modéré à Élevé. L'utilisation du CPU évolue avec le nombre de connexions clientes, la complexité des requêtes acheminées (par exemple, les jointures, les agrégations que mongos doit combiner) et le débit global des requêtes. Il est possible d'ajouter davantage d'instances mongos 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 (shard map) et les tampons d'agrégation temporaires. Moins critique que les nœuds porteurs de données, mais une RAM suffisante empêche le swapping et assure des temps de réponse rapides.
• Stockage : Très Faible. Seuls les journaux sont stockés. Des SSD locaux sont généralement plus que suffisants.

Astuce : Pour des performances optimales, déployez les instances mongos à proximité 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 sous forme de replica set (CSRS).

• CPU : Modéré. L'utilisation du CPU peut augmenter brusquement lors des migrations de blocs (chunk migrations), du rééquilibrage des shards ou des mises à jour fréquentes des métadonnées. Bien que pas aussi élevé qu'un primaire porteur de données, une performance constante est vitale.
• 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 blocs et de bases de données. Une RAM insuffisante peut dégrader gravement les performances et la stabilité du cluster.
• Stockage : IOPS et Capacité Modérées. Bien que la taille des métadonnées soit généralement inférieure aux données utilisateur, les mises à jour de la shard map et d'autres informations d'état du cluster peuvent être fréquentes, nécessitant de bonnes performances E/S. La capacité doit pouvoir accueillir les métadonnées croissantes et l'oplog.

Attention : La performance 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 de Shard (Replica Sets Porteurs de Données)

Chaque shard est un replica set autonome, stockant une sous-partie des données totales du cluster. Par conséquent, les exigences en ressources pour les nœuds primaire, secondaire et arbitre au sein de chaque shard sont similaires en nature à un replica set autonome, mais mises à l'échelle pour 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 exigences 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 au jeu de travail des données qu'il stocke. Ceci est crucial pour les performances au sein de son segment de données.
• Stockage : IOPS et Débit Élevés pour le primaire et les secondaires. Similaire à un replica set autonome, un stockage rapide est requis 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 replica set de shard individuel ait des exigences similaires à un replica set autonome, le cluster shardé global distribue les données et la charge de travail totales sur plusieurs replica sets de ce type. Cela signifie que la somme des ressources sur tous les shards sera significativement supérieure à celle d'un seul replica set mis à l'échelle verticalement.

Comparaison de l'Allocation des Ressources : Replica Set vs Sharded Cluster

Considérations Pratiques et Bonnes Pratiques

• Analyse de la Charge de Travail : Comprenez parfaitement les modèles 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 pour la planification des ressources.
• La Surveillance est Essentielle : Mettez en œuvre 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 retard oplog, les temps de requête). Cela aide à identifier les goulots d'étranglement et permet une mise à l'échelle proactive.
• Performance Réseau : Pour les clusters shardés, la latence et la bande passante réseau entre mongos, les serveurs de configuration et les shards sont critiques. La communication inter-shard et les opérations d'équilibrage de données peuvent être fortement impactées par une mauvaise performance réseau.
• Ressources Dédiées : Chaque processus mongod, qu'il soit primaire, secondaire ou membre de shard, doit s'exécuter sur du matériel dédié ou une machine virtuelle dédiée. Évitez la colocalisation avec des serveurs d'application ou d'autres instances de base de données pour prévenir la contention des ressources.
• Cloud vs. Sur Site (On-Premise) : Les fournisseurs de cloud offrent la flexibilité de mettre à l'échelle les ressources facilement. 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 gourmandes en stockage.
• Tests et Étalonnage (Benchmarking) : Testez toujours l'infrastructure planifiée avec des charges de travail réalistes avant de passer en production. Cela permet de valider vos hypothèses d'allocation de ressources.

Conclusion

Le choix entre un replica set et un cluster shardé, et par conséquent l'allocation des ressources, dépend entièrement de l'échelle, des exigences de performance et du budget de votre application. Les replica sets offrent haute disponibilité et redondance des données, adaptés à de nombreuses applications, avec une allocation de ressources axée sur la garantie que le primaire et les secondaires peuvent gérer la charge de travail de l'ensemble des données.

Le sharding, bien qu'introduisant une complexité opérationnelle significative et des coûts d'infrastructure plus élevés, offre une scalabilité horizontale inégalée pour les ensembles de données massifs et un débit extrême. Il nécessite une approche plus nuancée de l'allocation des ressources, reconnaissant que chaque composant (mongos, serveurs de configuration et replica sets de shard individuels) joue un rôle distinct avec des exigences matérielles uniques. Une planification minutieuse, une surveillance continue et des tests approfondis sont indispensables pour les deux stratégies de déploiement afin d'assurer un environnement MongoDB robuste et performant.