En 2010, YouTube était dans une situation difficile. La plateforme se développait rapidement et son infrastructure ne parvenait pas à suivre le rythme. Injecter plus de CPU et de mémoire n’a pas aidé ; Il n'arrêtait pas de s'affaisser au niveau des coutures. C'est à ce moment-là que deux ingénieurs YouTube, Sugu Sougoumarane et Mike Soloman, ont décidé de prendre du recul et d'examiner le problème sous un angle différent : "Quand nous nous sommes assis et avons écrit une grande feuille de calcul de tous les problèmes et solutions, et quand nous avons examiné "Il était évident que nous devions créer quelque chose qui se situe entre l'application et la couche MySQL et modérer toutes ces requêtes", a déclaré Sugu lors d'une réunion avec LaComparacion Pro en marge de la Percona Live Conference Europe 2019 à Amsterdam. La solution au problème est venue sous la forme de Vitess, qui facilite essentiellement la mise à l'échelle et la gestion de grands groupes de bases de données MySQL. Sugu nous raconte que le projet a beaucoup évolué depuis sa création sur YouTube. À l'époque, Vitess était principalement confronté à des problèmes d'évolutivité : "Mais au fil du temps, dès que ce proxy a été implémenté, les utilisateurs ont commencé à demander de plus en plus de fonctionnalités. Et nous avons grandi de manière organique jusqu'à ce que nous en soyons aujourd'hui."
Routage transparent
Sugu dit que ses utilisateurs préfèrent Vitess au clustering en raison de la flexibilité qu'il offre : « Le clustering MySQL pose des problèmes d'extension. Ainsi, lorsque vous souhaitez évoluer, vous souhaitez que les parties s'emboîtent de manière plus lâche. Mais si vous utilisez le clustering (MySQL »), cela n'est pas le cas. "Je n'ai pas cette flexibilité pour déplacer les choses plus facilement. Je pense donc que c'est pourquoi les utilisateurs préfèrent Vitess." Une exigence essentielle pour faire évoluer une base de données est de gérer la façon dont une base de données est divisée ou partagée dans le langage DBA. L'une des raisons de la popularité de Vitess est son système de fragmentation efficace. VTGate, l'un des deux principaux proxys de Vitess, initialement conçu comme un consolidateur de connexions, devient un élément important de la solution : « Lorsque nous avons créé Vitess pour la première fois, nous avions besoin que l'application soit parfaitement consciente. Par conséquent, l'application devait dire « Je Je veux envoyer cette requête, je veux l'envoyer à ce fragment. " Ce qui signifiait que si vous décidiez d'utiliser Vitess, vous deviez réécrire votre application pour effectuer des appels prenant en charge le fragment et Vitess gère le cluster pour vous. " Cela a changé en 2013, lorsque VTGate a pu acheminer les requêtes standard vers le bon fragment : "Cela signifiait que l'application n'avait plus besoin de connaître les fragments... n'importe quel autre pilote de base de données peut désormais utiliser Vitess. Sugu nous dit que le fournisseur de commerce électronique indien , Flipkart, propriété de Walmart, a été le premier à prendre note de cette fonctionnalité et à créer un pilote JDBC pour Vitess, ce qui leur a ensuite permis de porter facilement leur application. dans Vitess Cette fonctionnalité, qui, selon Sugu, était relativement simple à mettre en œuvre, a modifié les perspectives du projet.
Solution cloud native
Vitess est une solution cloud native. Sceptiques, nous avons demandé à Sugu s'il ne s'agissait pas simplement de se conformer à des mots à la mode. Il explique que la nature cloud-ready de Vitess peut être attribuée au gestionnaire de cluster de Google appelé Borg. Vitess a été initialement conçu pour fonctionner dans les centres de données de YouTube. Jusqu'en 2013, où Google décide de les déplacer en interne chez Google : « Le logiciel Borg de Google est une bête car c'est un environnement hostile pour les systèmes de stockage. Il fallait vraiment faire tourner Vitess dans cet environnement où Borg viderait, à sa guise, sa capsule et effacerait ses données, lui permettant de survivre dans cet environnement. » Cela signifiait que les développeurs devaient créer des fonctions de résistance dans Vitess pour garantir que les pods seraient ressuscités après la stagnation de Borg : « Et pour la plupart, ce sont les mêmes règles que Kubernetes. Dans Kubernetes, si un pod tombe en panne, ses données sont perdues. Nous étions donc presque prêts pour Kubernetes, avant la naissance de Kubernetes. "De plus, ils ont également dû apporter des modifications subtiles au code Vitess car le cycle de vie du cloud Les déploiements sont très différents de leur cycle de vie sur bare metal : « Sur bare metal, on peut avoir un master pendant six mois. Chez Google, une semaine serait un miracle, car Google réorganisait constamment les pods, ce qui finirait par le faire tomber. " Un autre aspect de cette reprogrammation a permis de préparer Vitess à l'environnement cloud en constante évolution : " Lorsque (le planificateur de Google) est reprogrammé, il affiche parfois autre chose dans la même direction. Par exemple, il est possible de reprogrammer un fragment et de le programmer dans un autre. Vous ne le saurez même pas car le schéma est correct, vous soumettez une demande et il vous enverra des réponses. Nous avons donc dû renforcer notre protection contre ces choses.