Instagram possède l'une des plus grandes bases de données Apache Cassandra au monde. Le projet a commencé à utiliser Cassandra en 2012 pour remplacer Redis et soutenir la mise en œuvre de fonctionnalités d'application telles qu'un système de reconnaissance des fraudes, Tape et Direct. Au début, les clusters Cassandra fonctionnaient dans AWS, mais les ingénieurs les ont ensuite migrés vers l'infrastructure Facebook avec tous les autres systèmes Instagram. Cassandra a très bien performé en termes de fiabilité et de tolérance aux pannes. Dans le même temps, les mesures de latence lors de la lecture des données pourraient clairement être améliorées.
L'année dernière, l'équipe d'assistance Instagram de Cassandra a commencé à travailler sur un projet visant à réduire considérablement la latence dans la lecture des données à Cassandra, que les ingénieurs ont appelé Rocksandra. Dans cet article, l'auteur explique ce qui a poussé l'équipe à mettre en œuvre ce projet, les difficultés qui ont dû être surmontées et les mesures de performances que les ingénieurs utilisent à la fois dans les environnements cloud internes et externes.
Motifs de transition
Instagram utilise activement et largement Apache Cassandra comme service de stockage de valeurs-clés. La plupart des demandes Instagram se produisent en ligne, par conséquent, pour fournir une expérience utilisateur fiable et agréable à des centaines de millions d'utilisateurs Instagram, les SLA sont très exigeants sur les performances du système.
Instagram adhère à une cote de fiabilité de cinq à neuf. Cela signifie que le nombre de pannes à un moment donné ne peut pas dépasser 0,001%. Afin d'améliorer les performances, les ingénieurs surveillent activement la bande passante et les latences des différents clusters Cassandra et s'assurent que 99% de toutes les demandes s'inscrivent dans un certain indicateur (délai P99).
Ci-dessous est un graphique montrant le délai côté client d'un pour l'un des clusters de combat Cassandra. Le bleu indique la vitesse de lecture moyenne (5 ms) et l'orange indique la vitesse de lecture à 99%, allant de 25 à 60 ms. Ses modifications dépendent fortement du trafic client.
L'étude a révélé que les brusques rafales de retard sont en grande partie dues au travail du ramasse-miettes JVM. Les ingénieurs ont introduit une métrique appelée «pourcentage d'arrêts du CM» pour mesurer le pourcentage de temps consacré à «arrêter le monde» par le serveur Cassandra, et s'est accompagnée d'un refus des demandes des clients. Voici le tableau ci-dessus montrant le temps (en pourcentage) qui est allé aux arrêts SM en utilisant l'exemple de l'un des serveurs de combat Cassandra. L'indicateur variait de 1,25% en période de moindre trafic à 2,5% en période de pointe.
Le graphique montre que cette instance de serveur Cassandra pourrait passer 2,5% de son temps à collecter des ordures au lieu de traiter les demandes des clients. Les opérations préventives du collecteur ont évidemment eu un impact significatif sur le retard P99, et il est donc devenu clair que si nous pouvions réduire le taux d'arrêt CM, les ingénieurs pourraient réduire considérablement le taux de retard P99.
Solution
Apache Cassandra est une base de données distribuée basée sur Java avec son propre moteur de stockage de données basé sur des arbres LSM. Les ingénieurs ont constaté que des composants de moteur tels qu'une table mémoire, un outil de compression, des chemins de lecture / écriture et certains autres créaient de nombreux objets dans la mémoire dynamique Java, ce qui obligeait la JVM à effectuer de nombreuses opérations supplémentaires. Pour réduire l'impact des mécanismes de stockage sur le travail du ramasse-miettes, l'équipe de support a envisagé différentes approches et a finalement décidé de développer un moteur C ++ et de remplacer celui existant par celui-ci.
Les ingénieurs ne voulaient pas tout faire à partir de zéro et ont donc décidé de prendre RocksDB comme base.
RocksDB est une base de données intégrée open source hautes performances pour le stockage de valeurs-clés. Il est écrit en C ++, et son API possède des liaisons de langage officiel pour C ++, C et Java. RocksDB est optimisé pour des performances élevées, en particulier sur les disques rapides tels que les SSD. Il est largement utilisé dans l'industrie comme moteur de stockage pour MySQL, mongoDB et d'autres bases de données populaires.
Des difficultés
Lors de la mise en œuvre du nouveau moteur de stockage sur RocksDB, les ingénieurs ont dû faire face à trois tâches difficiles et les ont résolues.
La première difficulté était que Cassandra n'avait toujours pas d'architecture permettant de connecter des processeurs de données tiers. Cela signifie que le travail du moteur existant est assez étroitement interconnecté avec d'autres composants de la base de données. Pour trouver un équilibre entre le refactoring à grande échelle et les itérations rapides, les ingénieurs ont défini l'API du nouveau moteur, y compris les interfaces de lecture, d'écriture et de flux les plus courantes. Ainsi, l'équipe d'assistance a pu mettre en œuvre de nouveaux mécanismes de traitement des données pour l'API et les insérer dans les chemins d'exécution de code appropriés à l'intérieur de Cassandra.
La deuxième difficulté était que Cassandra supportait les types de données structurées et les schémas de table, tandis que RocksDB ne fournissait que des interfaces clé-valeur. Les ingénieurs ont soigneusement défini des algorithmes de codage et de décodage pour prendre en charge le modèle de données Cassandra au sein des structures de données RocksDB et ont assuré la continuité de la sémantique des requêtes similaires entre les deux bases de données.
La troisième difficulté était liée à un composant aussi important pour tout composant de base de données distribuée que le travail avec les flux de données. Chaque fois qu'un nœud est ajouté ou supprimé d'un cluster Cassandra, il doit répartir correctement les données entre les différents nœuds pour équilibrer la charge au sein du cluster. Les implémentations existantes de ces mécanismes étaient basées sur l'obtention de données détaillées à partir du moteur de base de données existant. Par conséquent, les ingénieurs ont dû les séparer les uns des autres, créer une couche d'abstraction et implémenter une nouvelle option pour le traitement des flux à l'aide de l'API RocksDB. Pour obtenir un débit élevé de flux, l'équipe de support distribue maintenant d'abord les données dans des fichiers sst temporaires, puis utilise l'API spéciale RocksDB pour «avaler» les fichiers, ce qui leur permet d'être chargés simultanément dans l'instance RocksDB.
Indicateurs de performance
Après près d'un an de développement et de tests, les ingénieurs ont achevé la première version de l'implémentation et l'ont «déployée» avec succès sur plusieurs clusters Instagram Instagram Cassandra. Sur l'un des clusters de combat, le délai P99 est passé de 60 ms à 20 ms. Les observations ont également montré que les arrêts SM dans ce cluster sont passés de 2,5% à 0,3%, soit près de 10 fois!
Les ingénieurs souhaitaient également vérifier si Rocksandra pouvait bien fonctionner dans un environnement de cloud public. L'équipe de support a configuré un cluster Cassandra dans AWS à l'aide de trois instances i3.8 xlarge EC2, chacune avec un processeur 32 cœurs, 244 Go de RAM et un raid zéro de quatre lecteurs flash NVMe.
Pour les tests comparatifs, nous avons utilisé
NDBench et le schéma de table par défaut pour le framework.
TABLE emp ( emp_uname text PRIMARY KEY, emp_dept text, emp_first text, emp_last text )
Les ingénieurs ont préchargé 250 millions de 6 lignes de 6 Ko chacune (environ 500 Go de données sont stockées sur chaque serveur). Ensuite, configurez 128 lecteurs et écrivains dans NDBench.
L'équipe de support a testé diverses charges et mesuré les latences moyennes de lecture et d'écriture / P99 / P999. Les graphiques ci-dessous montrent que Rocksandra a montré des latences de lecture et d'écriture nettement plus faibles et plus stables.
Les ingénieurs ont également vérifié la charge en mode lecture sans écriture et ont constaté qu'avec le même délai de lecture P99 (2 ms), Rocksandra est capable de multiplier par 10 la vitesse de lecture des informations (300 K / s pour Rocksandra contre 30 K / s pour C * 3.0).
Plans futurs
L'équipe d'assistance Instagram a ouvert le code et le
cadre Rocksandra pour évaluer les performances . Vous pouvez les télécharger depuis Github et essayer dans votre propre environnement. Assurez-vous de nous dire ce qui en est arrivé!
Dans une prochaine étape, l'équipe travaille activement à l'ajout d'une prise en charge plus large des fonctionnalités C *, telles que les index secondaires, les correctifs, etc. De plus, les ingénieurs développent l'
architecture du moteur de base de données plug-in en C * afin de transférer ces développements à la communauté Apache Cassandra.
