Comment Pinterest a pu passer à 11 millions d’utilisateurs avec 6 ingénieurs

Le parcours de montée en charge de Pinterest

Le processus de montée en charge de Pinterest se divise en quatre étapes :

1. L’ère de la découverte de soi : une petite équipe d’ingénieurs gérait la création rapide de prototypes et des exigences produit en constante évolution.
2. L’ère de l’expérimentation : la forte hausse du nombre d’utilisateurs a imposé une montée en charge rapide, mais a aussi conduit à un système complexe et fragile.
3. L’ère de la maturité : l’architecture a été simplifiée en utilisant des technologies matures et capables de monter en charge, comme MySQL, Memcache et Redis.
4. L’ère de la régression : une fois la bonne architecture en place, l’entreprise a poursuivi sa croissance grâce à une montée en charge horizontale.

Technologies clés

Pinterest a donné la priorité à des technologies axées sur la fiabilité, la simplicité de compréhension et la capacité à monter en charge :

• MySQL : une base de données relationnelle stable et facile à maintenir.
• Memcache : met en cache en mémoire les données fréquemment consultées afin de décharger les lectures de la base de données.
• Redis : un magasin de données flexible capable de gérer diverses structures de données.
• Solr : une plateforme de recherche rapidement exploitable.

Montée en charge de la base de données : clustering vs sharding

Pinterest a étudié deux approches pour distribuer sa base de données :

Clustering

• Lorsque les données arrivent, le système détermine le nœud optimal puis réplique les données sur plusieurs nœuds.
• Cette approche offre des avantages comme la montée en charge automatique, la facilité de configuration et la garantie de disponibilité des données, mais présente aussi des inconvénients tels que la complexité, le manque de maturité et la difficulté des mises à niveau.

Sharding

• Les données sont divisées en petits morceaux, chacun étant placé sur un serveur indépendant.
• Cette approche apporte une architecture simple, une montée en charge indépendante et une propriété des données clairement définie, mais elle ne permet pas les jointures ni les transactions au niveau de la base de données et accroît la complexité applicative.

Pinterest a choisi le sharding en raison d’expériences négatives avec le clustering.

Transition vers une architecture en sharding

Pinterest est passé progressivement au sharding pendant une période de gel fonctionnel :

1. Suppression des jointures : toutes les jointures MySQL ont été supprimées, avec recours à la dénormalisation des données et au cache.
2. Sharding basé sur les ID : le sharding a été mis en place sur la base d’ID 64 bits afin de simplifier le routage des données.

Inconvénients du sharding et solutions

• Scripts de migration : le transfert des données vers l’infrastructure de sharding demandait beaucoup de temps.
• Logique applicative : l’absence de jointures et de transactions au niveau de la base de données obligeait à maintenir la cohérence des données dans l’application.
• Modification du schéma : les changements de schéma devaient être planifiés et appliqués sur tous les shards.
• Génération de rapports : il fallait agréger plusieurs shards pour produire des rapports.

Enseignements

Principaux enseignements tirés du parcours de montée en charge de Pinterest :

• La simplicité compte : choisir des technologies faciles à comprendre aide à résoudre les problèmes et à réduire les risques.
• Priorité à la montée en charge : dans un contexte de croissance rapide, il faut privilégier la capacité à monter en charge, même au prix de certaines fonctionnalités de base de données.
• Concevoir pour la montée en charge horizontale : choisir une architecture qui permet d’ajouter des ressources à mesure que la base d’utilisateurs grandit.