Comment l’équipe base de données de Figma a résisté à une montée en charge x100

• Récit des neuf mois durant lesquels l’équipe base de données de Figma a shardé horizontalement sa stack Postgres, et de la manière dont elle a rendu possible une scalabilité presque infinie

Le parcours de sharding horizontal de la stack Postgres de Figma

• La taille de la stack base de données de Figma a été multipliée par presque 100 depuis 2020 : c’est un problème positif qui reflète la croissance de l’entreprise, mais qui a aussi créé des défis techniques. En 2020, l’entreprise faisait tourner une base de données Postgres unique sur la plus grande instance physique d’AWS ; à la fin 2022, elle avait mis en place une architecture distribuée comprenant du cache, des réplicas en lecture et plusieurs bases découpées verticalement.
• Partitionnement vertical : en séparant des groupes de tables liées dans leurs propres partitions verticales, l’équipe a obtenu des gains de montée en charge progressifs et conservé suffisamment de marge pour anticiper la croissance. Par exemple, des groupes de tables liés comme les « fichiers Figma » ou les « organisations » ont été découpés dans leurs propres partitions verticales.
• Passage au sharding horizontal : l’équipe a reconnu que le partitionnement vertical seul avait ses limites. Après les premiers efforts de montée en charge centrés sur la réduction de l’utilisation CPU, elle a commencé à surveiller divers goulets d’étranglement sur une flotte devenue plus grande et plus hétérogène. Elle a quantifié les limites de scalabilité de la base de données sur plusieurs axes, du CPU et des E/S jusqu’à la taille des tables et au nombre de lignes écrites. Identifier ces limites était essentiel pour prévoir la marge disponible par shard.
• Les limites de taille des tables : certaines tables ont atteint plusieurs téraoctets et des dizaines de milliards de lignes, une taille difficile à gérer avec une base unique. À cette échelle, la fiabilité était affectée pendant les opérations vacuum de Postgres, une tâche de fond indispensable pour éviter l’arrêt dû à l’épuisement des identifiants de transaction. Les tables recevant le plus d’écritures allaient bientôt dépasser le maximum d’IOPS pris en charge par Amazon RDS. C’était un problème que le partitionnement vertical ne pouvait pas résoudre, et une solution plus ambitieuse était nécessaire pour éviter l’effondrement de la base.

Poser les bases de la montée en charge

• Minimiser l’impact pour les développeurs : l’objectif était d’absorber la majeure partie de la complexité du modèle de données relationnel afin que les développeurs applicatifs puissent se concentrer sur la création de nouvelles fonctionnalités intéressantes chez Figma, plutôt que sur le refactoring de larges pans du code.
• Scalabilité transparente : faire en sorte qu’aucun changement supplémentaire ne soit nécessaire dans la couche applicative lors des futures phases de montée en charge. Autrement dit, après le travail préparatoire initial pour rendre les tables compatibles, l’extension future devait être transparente pour les équipes produit.
• Éviter les backfills coûteux : l’équipe a écarté les solutions impliquant un backfill sur les grosses tables de Figma, ou sur toutes les tables. Compte tenu de la taille des tables et des limites de débit de Postgres, de tels backfills auraient pris plusieurs mois.
• Progresser par étapes : elle a identifié une approche pouvant être déployée progressivement afin de réduire le risque des changements majeurs en production. Cela diminuait le risque d’incident majeur et permettait à l’équipe base de données de préserver la fiabilité de Figma pendant la migration.
• Éviter les migrations à sens unique : conserver la capacité à revenir en arrière même après l’achèvement du sharding physique. Cela réduisait le risque de se retrouver bloqué dans un mauvais état en cas d’inconnues.
• Maintenir une forte cohérence des données : éviter les solutions complexes difficiles à mettre en œuvre sans interruption de service ou au prix d’une dégradation de la cohérence, comme les double-writes. L’équipe voulait une solution capable de monter en charge avec un temps d’arrêt proche de zéro.
• S’appuyer sur ses points forts : sous une forte pression de délai, l’équipe a privilégié une approche pouvant être livrée aussi progressivement que possible. Pour les tables à la croissance la plus rapide, elle a cherché à exploiter son expertise et ses technologies existantes.

Explorer les options possibles

• Examen des options de bases de données à sharding horizontal : il existe plusieurs solutions populaires, open source ou managées, pour les bases de données à sharding horizontal compatibles avec Postgres ou MySQL. CockroachDB, TiDB, Spanner et Vitess ont été évalués dans ce cadre. Cependant, migrer vers l’une de ces bases alternatives aurait exigé une migration de données complexe afin de garantir cohérence et fiabilité entre deux systèmes de stockage distincts.
• Exploiter l’expertise existante : au cours des dernières années, l’équipe avait développé une expertise importante pour exploiter RDS Postgres de manière stable et efficace. Pendant la migration, il aurait fallu reconstruire cette expertise métier depuis zéro. Vu le rythme de croissance extrêmement agressif, il ne restait que quelques mois.
• Exclusion de l’option NoSQL : une autre solution de scalabilité souvent choisie quand une entreprise grandit est la base de données NoSQL. Mais Figma disposait déjà d’un modèle de données relationnel très complexe, construit sur son architecture Postgres actuelle, et les API NoSQL n’offraient pas cette diversité. L’équipe voulait que les ingénieurs puissent se concentrer sur la livraison de grandes fonctionnalités et la création de nouveaux produits, plutôt que de réécrire presque toutes les applications backend ; NoSQL n’était donc pas une solution viable.
• Envisager une solution de sharding horizontal sur l’infrastructure RDS Postgres existante : pour une petite équipe, réimplémenter en interne une base relationnelle générale à sharding horizontal n’avait pas de sens. Cela l’aurait mise en concurrence avec les outils développés par de vastes communautés open source ou par des fournisseurs spécialisés en bases de données. En revanche, comme le sharding horizontal serait adapté à l’architecture spécifique de Figma, un jeu de fonctionnalités beaucoup plus réduit pouvait suffire. Par exemple, l’équipe a décidé de ne pas prendre en charge les transactions inter-shards garantissant l’atomicité, car elle disposait d’un moyen de gérer les échecs de transactions entre shards. Elle a choisi une stratégie de colocation minimisant les changements nécessaires dans la couche applicative. Cela lui a permis de prendre en charge un sous-ensemble de Postgres compatible avec l’essentiel de la logique produit. De plus, il était facile de maintenir une rétrocompatibilité entre Postgres shardé et non shardé. En cas d’inconnues, il restait possible de revenir facilement à Postgres non shardé.

La voie vers le sharding horizontal

• L’introduction du sharding horizontal : le sharding horizontal consiste à découper une table unique ou un groupe de tables afin de répartir les données sur plusieurs instances physiques de base de données. Grâce à ce processus, les tables shardées horizontalement dans la couche applicative peuvent prendre en charge n’importe quel nombre de shards dans la couche physique. Il est toujours possible d’étendre davantage en exécutant simplement une séparation physique des shards, une opération effectuée de façon transparente en arrière-plan, avec un minimum d’interruption et sans changement au niveau applicatif. Cette capacité a permis à Figma de prendre de l’avance sur les goulets d’étranglement restants en matière de scalabilité base de données et d’éliminer l’un de ses derniers grands défis de montée en charge. Si le partitionnement vertical permettait d’accélérer à la vitesse de l’autoroute, le sharding horizontal supprimait la limitation de vitesse pour permettre de voler.
• La complexité du sharding horizontal : le sharding horizontal est d’un ordre de grandeur plus complexe que les précédents efforts de montée en charge. Lorsque les tables sont réparties sur plusieurs bases physiques, de nombreuses propriétés de fiabilité et de cohérence habituellement acquises dans une base SQL ACID sont perdues. Par exemple, certaines requêtes SQL peuvent devenir inefficaces ou impossibles à prendre en charge, et le code applicatif doit être mis à jour pour fournir suffisamment d’informations afin de router les requêtes aussi efficacement que possible vers le bon shard. Les changements de schéma doivent être coordonnés pour garder tous les shards synchronisés, et les clés étrangères ainsi que les index globalement uniques ne peuvent plus être imposés par Postgres. Les transactions se retrouvent réparties sur plusieurs shards, si bien qu’il n’est plus possible de les faire respecter par Postgres. Désormais, certaines écritures peuvent réussir sur certaines bases alors que d’autres échouent. Il faut donc veiller à ce que la logique produit soit robuste face à ces « échecs de commit partiel » (imaginez par exemple qu’une équipe soit déplacée entre deux organisations et que seule la moitié des données disparaisse).
• Un effort pluriannuel vers le sharding horizontal : l’équipe savait que parvenir à un sharding horizontal complet serait un effort de plusieurs années. Il fallait fournir de la valeur progressivement tout en réduisant autant que possible le risque du projet. Le premier objectif était de sharder en production, aussi vite que possible, des tables relativement simples mais à très fort trafic. Cela permettrait non seulement de prouver la viabilité du sharding horizontal, mais aussi d’augmenter la marge disponible sur les bases les plus chargées. Ensuite, l’équipe pourrait développer des fonctionnalités supplémentaires tout en shardant des groupes de tables plus complexes. Même l’ensemble de fonctionnalités le plus simple représentait encore un travail considérable. Du début à la fin, il a fallu à l’équipe environ neuf mois pour sharder la première table.

Notre approche unique

• Colocations (colos) : fragmentation horizontale de groupes de tables liées en colocations partageant la même clé de sharding et la même disposition de sharding physique (affectueusement appelées « colos »). Cela fournit aux développeurs une abstraction conviviale pour interagir avec des tables fragmentées horizontalement.
• Sharding logique : séparation des concepts de « sharding logique » au niveau de la couche applicative et de « sharding physique » au niveau de Postgres. Des vues sont utilisées pour déployer d’abord un sharding logique, plus sûr et moins coûteux, avant d’exécuter des bascules physiques distribuées plus risquées.
• Moteur de requêtes DBProxy : création du service DBProxy, qui intercepte les requêtes SQL générées dans la couche applicative et les route dynamiquement vers différentes bases de données Postgres. DBProxy inclut un moteur de requêtes capable d’analyser et d’exécuter des requêtes complexes dans un environnement de sharding horizontal. DBProxy a permis d’implémenter des fonctionnalités comme l’équilibrage dynamique de charge et le hedging des requêtes.
• Préparation applicative fantôme : ajout d’un framework de « préparation applicative fantôme » capable de prédire comment le trafic de production réel se comporterait avec différentes clés de sharding potentielles. Cela donne aux équipes produit une vision claire des besoins de refactorisation ou de suppression de logique applicative pour préparer l’application au sharding horizontal.
• Réplication logique complète : pas besoin d’implémenter une « réplication logique filtrée » qui ne copierait qu’un sous-ensemble des données vers chaque shard. À la place, l’ensemble complet des données est copié, puis les lectures/écritures ne sont autorisées que sur le sous-ensemble appartenant au shard concerné.

Mise en œuvre du sharding

• Importance du choix de la clé de shard : dans le sharding horizontal, l’une des décisions les plus importantes est le choix de la clé de shard. Le sharding horizontal ajoute plusieurs contraintes au modèle de données autour de cette clé. Par exemple, la plupart des requêtes doivent inclure la clé de shard afin d’être routées vers le bon shard. Certaines contraintes de base de données, comme les clés étrangères, ne fonctionnent que si la clé étrangère est aussi la clé de sharding. La clé de shard doit répartir uniformément les données sur tous les shards afin d’éviter les hotspots susceptibles de créer des problèmes de fiabilité ou de nuire à la montée en charge.
• Approche adaptée au modèle de données de Figma : Figma fonctionne dans le navigateur, et de nombreux utilisateurs peuvent collaborer simultanément sur le même fichier Figma. Cela repose sur un modèle de données relationnel relativement complexe qui capture les métadonnées de fichiers, les métadonnées d’organisation, les commentaires, les versions de fichiers, etc. Comme il n’existait pas de candidat unique satisfaisant dans le modèle de données existant, l’équipe a envisagé d’utiliser la même clé de sharding pour toutes les tables, mais cela aurait nécessité de créer des clés composites pour ajouter une clé de sharding unifiée, d’ajouter des colonnes à tous les schémas de table, d’exécuter un backfill coûteux pour les remplir, puis de refactoriser en profondeur la logique produit. À la place, Figma a adapté son approche à son modèle de données spécifique en sélectionnant un petit nombre de clés de sharding, comme UserID, FileID et OrgID. Presque toutes les tables de Figma peuvent être shardées à l’aide de l’une de ces clés.
• Introduction des colocations (colos) : introduction du concept de colocation afin de fournir une abstraction conviviale aux développeurs produit. Les tables au sein d’une colo prennent en charge les jointures inter-tables et les transactions complètes tant qu’elles sont limitées à une seule clé de sharding. La majeure partie du code applicatif interagissait déjà avec la base de données de cette manière, ce qui a réduit au minimum le travail nécessaire côté développeurs pour adapter les tables au sharding horizontal.
• Garantir l’uniformité de la distribution des données : une fois les clés de sharding choisies, il fallait garantir une distribution uniforme des données sur l’ensemble des bases de données backend. Malheureusement, beaucoup des clés choisies utilisaient des identifiants auto-incrémentés ou des ID préfixés par un horodatage Snowflake. Cela aurait créé d’importants hotspots, avec la majorité des données concentrées dans un seul shard. L’équipe a exploré une migration vers des identifiants plus aléatoires, mais cela aurait exigé une migration de données coûteuse et longue. Elle a donc décidé d’utiliser le hash de la clé de sharding pour le routage. En choisissant une fonction de hachage suffisamment aléatoire, il est possible de garantir une distribution homogène des données. Un inconvénient est que les range scans sur la clé de shard deviennent moins efficaces, car des clés consécutives sont hachées vers différents shards de base de données. Cependant, ce motif de requête étant rare dans leur base de code, ce compromis a été jugé acceptable.

La solution « logique »

• Réduction du risque lors du déploiement du sharding horizontal : afin de réduire le risque du déploiement du sharding horizontal, l’équipe a voulu dissocier le processus physique de division des shards du travail de préparation des tables dans la couche applicative. Pour cela, elle a séparé le « sharding logique » du « sharding physique ». Cela permettait de séparer les deux volets de la migration, de les implémenter indépendamment et d’en réduire le risque. Le sharding logique apportait de la confiance dans la stack de serving grâce à un déploiement progressif à faible risque, piloté par pourcentage. En cas de bug, revenir en arrière sur le sharding logique se résumait à un simple changement de configuration. Revenir sur le travail de sharding physique était possible, mais nécessitait une coordination plus complexe pour garantir la cohérence des données.
• Comportement après le sharding logique : une fois une table shardée logiquement, toutes les opérations de lecture et d’écriture se comportent déjà comme si elle était shardée horizontalement. En termes de fiabilité, de latence et de cohérence, le système se comporte comme s’il était horizontalement shardé, même si les données résident encore physiquement sur un seul hôte de base de données. Une fois la certitude acquise que le sharding logique fonctionnait comme prévu, l’équipe procédait alors au sharding physique. Cela consistait à copier les données depuis une base unique, à les répartir sur plusieurs backends, puis à rerouter le trafic de lecture et d’écriture via les nouvelles bases de données.

Un moteur de requêtes capable d’agir

• Refonte de la stack backend pour prendre en charge le sharding horizontal : au départ, les services applicatifs communiquaient directement avec PGBouncer, la couche de pooling de connexions. Mais le sharding horizontal exigeait une analyse, une planification et une exécution des requêtes bien plus complexes. Pour y répondre, l’équipe a construit DBProxy, un nouveau service en Golang. DBProxy se situe entre la couche applicative et PGBouncer. Il contient la logique d’équilibrage de charge, d’observabilité améliorée, de prise en charge des transactions, de gestion de la topologie des bases de données, ainsi qu’un moteur de requêtes léger.
• Composants clés du moteur de requêtes :
  • Analyseur de requêtes : lit le SQL envoyé par l’application et le transforme en arbre syntaxique abstrait (AST).
  • Planificateur logique : analyse l’AST et extrait du plan de requête le type de requête (insert, update, etc.) ainsi que l’ID de shard logique.
  • Planificateur physique : mappe la requête entre l’ID de shard logique et la base de données physique. Il réécrit la requête afin qu’elle soit exécutée sur le shard physique approprié.
• Approche « scatter-gather » : cela fonctionne comme un jeu de cache-cache à l’échelle de la base de données : on envoie la requête à tous les shards (dispersion), puis on récupère les réponses de chacun (collecte). C’est amusant, mais si on en abuse avec des requêtes complexes, la base de données peut devenir lente comme un escargot.
• Implémentation des requêtes dans un monde shardé horizontalement : les requêtes mono-shard sont filtrées par une seule clé de shard. Le moteur de requêtes n’a alors qu’à extraire cette clé et router la requête vers la base de données physique appropriée. Il « délègue » à Postgres la complexité de l’exécution. En revanche, si la requête ne contient pas la clé de sharding, le moteur doit effectuer un « scatter-gather » plus complexe. Dans ce cas, il faut diffuser la requête vers tous les shards (phase de dispersion), puis agréger les résultats (phase de collecte).
• Simplification de la compatibilité SQL : si le service DBProxy avait pris en charge une compatibilité SQL complète, il aurait fortement ressemblé au moteur de requêtes de Postgres. L’équipe a voulu simplifier l’API afin de minimiser la complexité de DBProxy et de réduire le travail des développeurs applicatifs, qui auraient sinon dû réécrire les requêtes non prises en charge. Pour déterminer le bon sous-ensemble, elle a construit un framework de « shadow planning » permettant de définir des schémas de sharding potentiels pour les tables et d’exécuter l’étape de planification logique au-dessus du trafic de production en temps réel. Les requêtes et les plans associés pouvaient être journalisés dans la base de données Snowflake pour être analysés hors ligne. À partir de ces données, l’équipe a choisi un langage de requête couvrant les 90 % de requêtes les plus courantes tout en évitant la complexité du pire cas dans le moteur de requêtes. Par exemple, tous les range scans et les requêtes ponctuelles sont autorisés, mais les jointures ne le sont qu’entre deux tables d’une même colo et uniquement lorsqu’elles portent sur la clé de sharding.

Perspectives d’avenir

• Encapsulation des shards logiques : l’équipe devait décider comment encapsuler les shards logiques. Elle a exploré le partitionnement des données via des bases de données Postgres distinctes ou des schémas Postgres. Malheureusement, cela exigeait des modifications physiques des données lors du sharding logique, avec une complexité comparable à celle d’un split de shard physique.
• Représentation des shards via des vues Postgres : à la place, l’équipe a choisi de représenter les shards sous forme de vues Postgres. Plusieurs vues peuvent être créées pour chaque table, chacune correspondant à un sous-ensemble de données d’un shard donné. Cela prend la forme suivante : CREATE VIEW table_shard1 AS SELECT * FROM table WHERE hash(shard_key) >= min_shard_range AND hash(shard_key) < max_shard_range). Toutes les opérations de lecture et d’écriture passent par ces vues.
• Création de vues shardées au-dessus d’une base physique existante non shardée : cela permettait de sharder logiquement avant d’exécuter une opération risquée de resharding physique. Chaque vue était accessible via son propre service de connection pooling shardé. Le pooler pointait toujours vers l’instance physique non shardée, tout en donnant l’apparence d’un système shardé. Grâce à des feature flags dans le moteur de requêtes, le déploiement des lectures et écritures shardées a pu être progressif, avec réduction du risque, et un rollback possible à tout moment en quelques secondes en redirigeant le trafic vers les tables principales. Au moment du premier reshard, l’équipe avait déjà confiance dans la sécurité de la topologie shardée.
• Risques liés à la dépendance aux vues : les vues ajoutent un surcoût de performance et peuvent, dans certains cas, modifier en profondeur la manière dont le query planner de Postgres optimise les requêtes. Pour valider cette approche, l’équipe a collecté un corpus de requêtes de production assainies et exécuté des tests de charge avec et sans vues. Elle a constaté que, dans la plupart des cas, les vues n’ajoutaient qu’un surcoût minimal, inférieur à 10 % même dans le pire des cas. Elle a aussi mis en place un framework de shadow reads envoyant tout le trafic de lecture en temps réel à travers les vues, afin de comparer les performances et l’exactitude des requêtes avec et sans vues. Les résultats ont confirmé que les vues constituaient une solution viable avec un impact minimal sur les performances.

Résolution des problèmes de topologie

• Compréhension de la topologie par DBProxy pour le routage des requêtes : DBProxy devait comprendre la topologie des tables et des bases physiques. La séparation entre les concepts de sharding logique et physique imposait une manière de représenter ces abstractions dans la topologie.
• Mappage des tables et des clés de shard : il fallait pouvoir mapper la table users à la clé de shard user_id, ainsi qu’associer un ID de shard logique (123) à la base logique et physique appropriée.
• Partitionnement vertical et dépendance à des fichiers de configuration codés en dur : pour le partitionnement vertical, l’équipe s’appuyait sur un simple fichier de configuration codé en dur qui associait les tables à leur partition. Le passage au sharding horizontal a nécessité un système plus complexe.
• Changements dynamiques de topologie et nécessité pour DBProxy de mettre rapidement à jour son état : lors des splits de shards, la topologie change dynamiquement, ce qui imposait à DBProxy d’actualiser rapidement son état pour éviter de router des requêtes vers la mauvaise base.
• Rétrocompatibilité des changements de topologie : tous les changements de topologie devaient rester rétrocompatibles, sans modification sur le chemin critique du site.
• Construction d’une topologie de base de données encapsulant les métadonnées complexes du sharding horizontal : l’équipe a construit une topologie de base de données encapsulant cette métadonnée complexe et fournissant des mises à jour en temps réel en moins d’une seconde.
• Simplification de l’administration via la séparation entre topologies logique et physique : cela a permis de conserver en environnement non productif la même topologie logique qu’en production, tout en réduisant le nombre de bases physiques, ce qui diminue les coûts et la complexité.
• Application d’invariants dans la topologie via une bibliothèque dédiée : une bibliothèque de topologie appliquait des invariants, par exemple l’obligation pour chaque ID de shard d’être mappé à exactement une base physique, afin de garantir la justesse du système pendant la mise en place du sharding horizontal.

Opérations de sharding physique

• Dernière étape une fois la table prête au sharding : il fallait effectuer le basculement physique d’une base non shardée vers une base shardée. Une grande partie de la logique utilisée pour le sharding horizontal a pu être réemployée, mais avec quelques différences notables, notamment le passage d’une base 1:1 à une base 1:N.
• Nécessité de renforcer la robustesse du processus de basculement : le processus devait être rendu plus résilient face à de nouveaux modes de défaillance, dans lesquels l’opération de sharding pouvait ne réussir que sur une partie de la base.
• La plupart des risques déjà traités pendant le partitionnement vertical : comme beaucoup de risques avaient déjà été réduits pendant le partitionnement vertical, l’équipe a pu avancer vers sa première opération de sharding physique bien plus rapidement qu’elle n’aurait pu le faire autrement.

Où en est aujourd’hui le parcours vers le sharding horizontal

• Investissement pluriannuel dans le sharding horizontal : après avoir reconnu la nécessité d’un investissement de plusieurs années dans le sharding horizontal pour la scalabilité future de Figma, l’équipe a lancé sa première table shardée horizontalement en septembre 2023.
• Exécution réussie du failover : le failover a été réalisé avec succès, avec seulement 10 secondes de disponibilité partielle temporaire sur la base primaire et aucun impact sur la disponibilité des réplicas. Après le sharding, aucune régression n’a été observée en latence ou en disponibilité.
• Gestion de shards complexes : l’équipe a commencé par un shard relativement simple sur la base affichant le plus haut taux d’écriture. Cette année, elle prévoit de sharder des bases de plus en plus complexes, comprenant des dizaines de tables et des milliers de points d’appel dans le code.
• Nécessité d’un sharding horizontal pour toutes les tables de Figma : afin d’éliminer la dernière limite de montée en charge et d’atteindre une véritable résilience. Un monde entièrement shardé horizontalement apporte divers bénéfices, comme une meilleure fiabilité, une réduction des coûts et une plus grande vélocité pour les développeurs.
• Problèmes restant à résoudre :
  • prise en charge des mises à jour de schémas shardés horizontalement
  • génération d’ID globalement uniques pour les clés primaires shardées horizontalement
  • transactions inter-shards atomiques pour les cas d’usage critiques métier
  • index distribués globalement uniques (actuellement pris en charge uniquement pour les index incluant la clé de shard)
  • augmentation de la vélocité des développeurs avec des modèles ORM compatibles nativement avec le sharding horizontal
  • opérations de resharding entièrement automatisées, permettant d’exécuter un split de shard par simple clic
• Réévaluation de l’approche existante de sharding horizontal sur RDS : ce parcours a commencé il y a 18 mois sous une forte pression de calendrier. Avec les progrès continus et la maturation des stores NewSQL, l’équipe dispose désormais d’une marge suffisante pour réévaluer les compromis entre la poursuite de la voie actuelle et une bascule vers une solution open source ou managée.
• Progrès enthousiasmants dans le parcours vers le sharding horizontal : de nombreux défis restent encore à résoudre. L’équipe prévoit de publier d’autres analyses approfondies sur différentes composantes de sa stack de sharding horizontal. Les personnes intéressées par ce type de projet sont invitées à la contacter. Des recrutements sont en cours.

L’avis de GN⁺

• L’équipe base de données de Figma a cherché à dépasser les limites de scalabilité de sa base via le sharding horizontal, une étape importante pour soutenir la croissance et les performances d’un outil de collaboration cloud.
• Le sharding horizontal introduit de nouveaux défis en gestion des données et en optimisation des requêtes, qui exigent de nouvelles connaissances et compétences de la part des administrateurs de bases de données et des développeurs.
• Le sharding horizontal améliore fortement la scalabilité des bases de données, mais nécessite aussi de nouvelles solutions pour le traitement des requêtes complexes et le maintien de la cohérence des données.
• Parmi les projets open source offrant des fonctionnalités similaires, on peut citer CitusDB, qui permet de faire monter Postgres en charge horizontalement.
• Lors de l’adoption du sharding horizontal, il faut prendre en compte la complexité du modèle de données, les performances des requêtes, la flexibilité du système et les aspects de maintenance, ce qui revient à trouver un équilibre entre scalabilité de la base de données et facilité d’exploitation.

[GN⁺]

Avis Hacker News

• Tables volumineuses et limite d’IOPS de RDS

  • Il est mentionné que la plus grande table atteint plusieurs To et dépassera bientôt le maximum d’IOPS pris en charge par RDS.
  • RDS pour PostgreSQL atteint au maximum 256 000 IOPS sur un volume de 64 To.
  • En configuration multi-AZ, cela représente un coût de 70 k$ par mois.

• Résultats du sharding et coût

  • Au final, on part sur l’hypothèse d’un sharding en 5 fragments, chaque shard prenant en charge environ 50 000 IOPS et 12 To de données.
  • En configuration multi-AZ, cela représente un coût de 100 k$ par mois.

• Temps et coût du sharding

  • Il a fallu 9 mois pour sharder la première table.
  • Comme des modifications de l’application étaient aussi nécessaires, le calcul donne 9 mois * 20 jours ouvrés/mois * (3 ingénieurs DB + 2 ingénieurs applicatifs) = 900 jours-homme.
  • En supposant un salaire moyen de 100 k$ pour un ingénieur, le coût total s’élève à environ 400 k$.

• Comparaison des coûts avec YugabyteDB

  • YugabyteDB, un NewSQL compatible PostgreSQL, est estimé à 15 k$ par mois pour égaler les meilleures performances de RDS.
  • Figma a dépensé environ 25 fois plus (400 k$/15 k$) pour implémenter un sharding horizontal en interne et utilise toujours RDS, pour un coût d’environ 6 fois plus élevé (100 k$/15 k$).

• Proposition de séparation des bases de données par client

  • Il est suggéré qu’il pourrait être plus simple de placer chaque client dans une base de données (logique) distincte.
  • Comme il n’y a pas besoin de transactions entre différents clients, ils semblent résoudre un problème plus difficile que nécessaire.
  • On ne sait pas si les bases de données (logiques) de PostgreSQL passeront bien à l’échelle, mais en principe ce n’est pas impossible.

• Construire une version PG similaire à Vitess pour MySQL

  • La réécriture des requêtes est jugée intéressante.
  • Placer une couche entre la base de données et l’application permettrait aussi divers ACL (listes de contrôle d’accès).

• Réflexion autour de FoundationDB

  • Certains s’interrogent sur la raison pour laquelle FoundationDB n’a pas été essayé.
  • Il y avait des problèmes avec le vacuuming (garbage collection) de PostgreSQL.
  • Dans les versions précédentes, le vacuuming nécessitait deux fois plus d’espace, mais cela a peut-être changé dans les versions récentes.

• Une approche qui traite le sharding comme du bricolage

  • Il vaudrait mieux s’appuyer sur les API de l’OS plutôt que de gérer soi-même le buffering/caching I/O bas niveau.
  • Il reste l’impression qu’il manque encore des techniques et des infrastructures comparables pour le sharding de bases de données.

• Interrogation sur l’absence de l’extension Citus

  • Citus, une extension Postgres déjà mature, n’est pas mentionnée dans l’article.
  • Ils ne connaissent peut-être pas Citus, ou l’ont ignorée pour une raison particulière.

• Possibilité d’utiliser Aurora Limitless

  • Question sur la possibilité d’utiliser Amazon Aurora Limitless.

• Compréhension des bases de données NoSQL

  • NoSQL convient aux backends qui doivent accueillir des données non structurées sans nécessiter de modèle relationnel complexe.
  • Postgres le prend en charge via le type de données jsonb, mais comme ils ont déjà un bon modèle de données, ils n’ont pas vraiment besoin de l’utiliser souvent.

• Maturité du sharding et intérêt des solutions NewSQL

  • Question sur l’intérêt d’envisager une solution NewSQL pour l’auto-sharding et le support multi-région, maintenant que le sharding a mûri.
  • Apprendre à exploiter une base de données NewSQL représente aussi un coût supplémentaire.

• La technologie Spanner de Google et l’évaluation de Figma

  • Chez Google, Spanner est perçu comme une technologie quasi magique qui permet un sharding horizontal infini et les transactions, au point que presque tous les projets migrent vers Spanner.
  • Certains se demandent comment Figma a évalué Cloud Spanner et s’ils ont effectivement renoncé au support réel des transactions avec leur schéma Postgres horizontal, même temporairement.