Il est difficile d'être pertinent sur l'architecture d'un système à l'avance. Réussir le scaling d'un système tient plus dans l'utilisation intelligente des métriques et l'introspection, dans la capacité à créer des processus de build et de provisioning et dans le fait de savoir appliquer des changements radicaux avec aise. Ces points sont quelques-unes des clés de la réussite de Dropbox en matière de scaling, présentées récemment par Rajiv Eranki lors de la conférence RAMP 2013 à Budapest.
De la même façon que dans son billet de blog de 2012, Eranki décrit ses expériences en tant que responsable de l'ingénierie serveur ayant accompagné le scaling de Dropbox de 2000 utilisateurs à près de 40 millions. Lorsque Dropbox avait embauché Eranki, sorti d'école, leur architecture consistait en un unique serveur (physique) de base de données sous MySQL et un seul front-end. Commencer à petite échelle a ses bons côtés, d'après Eranki. La simplicité de l'architecture a facilité l'exécution de requêtes sur l'ensemble des utilisateurs, les backups, le débogage et a montré "une incroyable flexibilité et une grande agilité" aux premiers jours du développement du produit.
Garder les choses simples est une leçon clé pour Eranki. Les idées et les techniques intelligentes peuvent être séduisantes. Mais la leçon tirée de l'expérience de Dropbox est qu'il est plus facile de procéder à un scaling horizontal en achetant plus de matériel au moment approprié et de partitionner les bases de données au besoin. "Chaque fois que nous avons essayé d'être malins pour ce qui est de l'architecture, nous avons échoué", s'amuse Eranki. Les espoirs d'utiliser des structures de données intelligentes comme des Bloom Filters pour gérer les tables de hash distribuées n'ont jamais tenu face à un simple sharding de base de données. Les tentatives d'utiliser des schémas de sharding distribués plus intelligents pour leur base MySQL se sont avérées être plus complexes qu'une architecture pragmatique maître-esclave. La coordination des transactions est un autre domaine où la simplicité est encore sortie victorieuse. Le commit à deux phases introduit une fragilité et des problèmes de performance dans le système. À la place, ils ont opté pour un design où l'ordre de commit est coordonné de façon à ce que les erreurs soient prises en charge de façon contrôlée et puissent être corrigées plus tard par des transactions de compensation.
"Garder la trace des choses" est un autre thème majeur du discours de Rajiv Eranki. Dropbox a écrit ses propres métriques applicatives spécifiques et créé une API de logging simple, afin qu'il soit facile aux développeurs de l'utiliser partout dans leur code. La récupération des métriques a été automatisée, puis ils ont construit des tableaux de bord pour aider à la surveillance de la santé du système. "La plupart des graphes sont inutiles", fait remarquer Eranki, c'est pourquoi il est préférable de construire des tableaux de bord autour de besoins spécifiques, de niveau applicatif. Créez des alertes pour les métriques qui ne sont pas constamment surveillées mais pour lesquelles vous voulez être averti lorsqu'elles sortent de certaines limites prédéfinies. "Surveillez les plus gros utilisateurs", conseille Eranki. Mettre en place un monitoring des utilisateurs "qui ont le plus de dossiers partagés, qui prennent le plus de bande passante, qui font le plus de requêtes" fournit une vision intéressante sur le comportement des utilisateurs et révèle souvent des cas d'abus ou plus simplement des bugs dans le système.
Le logging va de pair avec le monitoring. Les nouvelles fonctionnalités de Dropbox partent en production avec un niveau de logs "ultra-verbeux", dit Eranki et généralement ils le regrettent quand, plus tard, ces points de logs sont supprimés. "Avoir beaucoup de sorties est la bonne façon de faire". Eranki recommande que les logs soient gardés pour référence, pour plus tard, par exemple pour aider à débugger une "race condition" compliquée qui arrive de temps en temps.
Eranki décrit les étapes suivies par Dropbox qui, en appliquant les leçons apprises de Netflix dans leur façon de faire face au chaos, a appris à "atténuer la loi de Murphy". Les vraies défaillances étant difficiles à reproduire en environnement de test, ils ont à dessein fait échouer les hôtes en production. "Vous savez que les machines vont tomber, donc faites que cela arrive à 2h de l'après-midi lorsque vous êtes au bureau, plutôt qu'à 5h du matin.", dit Eranki. Ceci amène à une autre leçon clé, qui est de devenir à l'aise avec les changements majeurs. Appliquer des changements de schéma ou basculer d'une base de données maître à un clone sont des changements majeurs qui, si vous les maitrisez et faites que cela devienne une routine, apporte de hauts niveaux de flexibilité dans tout ce qui est modifications système ou récupérations après échec.
Eranki conclut sa présentation sur le sujet du scaling des ressources humaines. Il note combien les personnes connaissant le système au complet ont de la valeur et regrette que ce constat n'ait pas été fait plus tôt. Le problème est qu'il faut plusieurs mois à une nouvelle personne pour être tout à fait opérationnelle. Mais les personnes d'expérience réduisent le coût des corrections techniques et aident à éviter l'accumulation de dette technique induite par les corrections "à la va-vite".