Cloud Native : ce que cela signifie dans le monde des données


Avant Rockset, j’ai passé huit ans chez Facebook à développer leur infrastructure de données volumineuses et leur infrastructure de données en ligne. Tous les logiciels que nous avons écrits ont été déployés dans les centres de données privés de Facebook, donc ce n’est que lorsque j’ai commencé à construire sur le cloud public que j’ai pleinement apprécié son véritable potentiel.

Facebook est peut-être la définition même d’une entreprise à l’échelle du Web, mais l’obtention de matériel nécessitait toujours d’énormes délais et une planification de capacité étendue. Le cloud public, en revanche, fournit du matériel grâce à la simplicité du provisionnement basé sur l’API. Il offre, à toutes fins utiles, un calcul et un stockage infinis, demandés à la demande et abandonnés lorsqu’ils ne sont plus nécessaires.

Une épiphanie sur l’élasticité du cloud

J’en suis venu à une réalisation simple sur la puissance de l’économie du cloud. Dans le cloud, le prix d’utilisation d’1 CPU pendant 100 minutes est le même que celui d’utilisation de 100 CPU pendant 1 minute. Si une tâche de traitement de données qui prend 100 minutes sur un seul processeur pouvait être reconfigurée pour s’exécuter en parallèle sur 100 processeurs en 1 minute, le prix de calcul de cette tâche resterait le même, mais l’accélération serait énorme !

L’évolution vers le cloud

Les évolutions récentes de l’état de l’art du traitement des données ont chacune cherché à exploiter les tendances matérielles dominantes. Hadoop et RocksDB sont deux exemples sur lesquels j’ai eu le privilège de travailler personnellement. La chute du prix de Disques SATA au début des années 2000 a été un facteur majeur de la popularité de Hadoop, car c’était le seul logiciel capable de bricoler des pétaoctets de ces disques pour fournir un système de stockage à grande échelle. De même, RocksDB s’est épanoui parce qu’il a tiré parti du sweet spot prix-performances de SSD stockage. Aujourd’hui, la plate-forme matérielle est à nouveau en pleine mutation, de nombreuses applications passant au cloud. Cette tendance vers le cloud annoncera à nouveau une nouvelle génération de solutions logicielles.



La prochaine version du logiciel de traitement de données exploitera la nature fluide du matériel dans le cloud. Les charges de travail de données saisiront et libéreront les ressources de calcul, de mémoire et de stockage, selon les besoins et au moment voulu, pour répondre aux exigences de performances et de coût. Mais les logiciels de traitement de données doivent être repensés et réécrits pour que cela devienne une réalité.

Comment créer pour le cloud

Les plates-formes de données cloud natives doivent évoluer de manière dynamique pour utiliser les ressources cloud disponibles. Cela signifie qu’une demande de données doit être parallélisée et que le matériel nécessaire à son exécution doit être acquis instantanément. Une fois les tâches nécessaires planifiées et les résultats renvoyés, la plate-forme doit rapidement se débarrasser des ressources matérielles utilisées pour cette demande.

Le simple fait de traiter en parallèle ne rend pas un système compatible avec le cloud. Hadoop était un système de traitement parallèle, mais son objectif était d’optimiser le débit des données traitées dans un ensemble fixe de ressources pré-acquises. De même, de nombreux autres systèmes pré-cloud, dont MongoDB et Elasticsearch, ont été conçus pour un monde dans lequel le matériel sous-jacent, sur lequel ils s’exécutent, était fixe.

Cependant, l’industrie a récemment fait des percées dans la conception de plates-formes de données pour le cloud. Qubole a transformé Hadoop pour qu’il soit compatible avec le cloud, tandis qu’Amazon Aurora et Snowflake ont créé des bases de données relationnelles optimisées pour le cloud. Voici quelques modèles architecturaux courants dans le traitement de données cloud natif :

Utilisation du stockage partagé plutôt que du stockage sans partage

La vague précédente de frameworks de traitement de données distribués a été conçue pour une infrastructure non cloud et utilisait des architectures sans partage. Dr Stonebraker écrit sur les avantages des architectures sans partage depuis 1986 (Le cas de Shared Nothing) et l’avènement de HDFS en 2005 ont fait des architectures sans partage une réalité généralisée. À peu près au même moment, d’autres logiciels distribués, tels que Cassandra, HBase et MongoDB, qui utilisaient un stockage sans partage, sont apparus sur le marché. Le stockage était généralement JBOD, attaché localement à des machines individuelles, ce qui se traduisait par un calcul et un stockage étroitement couplés.

Mais à l’ère du cloud, les magasins d’objets sont devenus le stockage dominant. Les services cloud tels qu’Amazon S3 fournissent un stockage partagé accessible simultanément à partir de plusieurs nœuds à l’aide d’API bien définies. Le stockage partagé nous permet de découpler le calcul et le stockage et de faire évoluer chacun indépendamment. Cette capacité se traduit par des systèmes cloud natifs qui sont des ordres de grandeur plus efficaces. Dr Dewittqui a enseigné mes cours de base de données à l’Université du Wisconsin-Madison, a postulé dans son prise de position 2017 que le stockage partagé est de nouveau à la mode !

Architecture désagrégée

Un système cloud natif est conçu de telle sorte qu’il n’utilise que la quantité de matériel réellement nécessaire pour la charge de travail qu’il dessert. Le cloud nous offre la possibilité d’utiliser le stockage, le calcul et le réseau indépendamment les uns des autres. Nous ne pouvons en bénéficier que si nous concevons notre service pour utiliser plus (ou moins) d’une ressource matérielle sans modifier sa consommation de toute autre ressource matérielle.


image (2)

Entrez dans les microservices. Un service logiciel peut être composé d’un ensemble de microservices, chaque microservice étant limité à un seul type de ressource. Il s’agit d’une architecture désagrégée. Si plus de calcul est nécessaire, ajoutez plus de processeurs au microservice de calcul. Si davantage de stockage est nécessaire, augmentez la capacité de stockage du microservice de stockage. Référez-vous à ceci HotCloud ’18 article du professeur Remzi, Andrea et notre propre Venkat pour une articulation plus approfondie des principes de conception cloud-native.

Planification native du cloud pour gérer à la fois l’offre et la demande

Pour gérer l’ajout et la suppression de ressources matérielles vers et depuis les microservices, nous avons besoin d’un nouveau type de planificateur de ressources. Les planificateurs de tâches traditionnels ne gèrent généralement que la demande, c’est-à-dire qu’ils planifient les demandes de tâches parmi les ressources matérielles disponibles. En revanche, un ordonnanceur cloud natif peut gérer à la fois l’offre et la demande. En fonction de la charge de travail et des politiques configurées, un planificateur natif du cloud peut demander le provisionnement de nouvelles ressources matérielles et planifier simultanément de nouvelles demandes de tâches sur le matériel provisionné.

Les planificateurs de logiciels de gestion de données traditionnels ne sont pas conçus pour se débarrasser du matériel. Mais dans le cloud, il est impératif qu’un planificateur se débarrasse du matériel lorsqu’il n’est pas utilisé. Plus un système peut supprimer rapidement le matériel excédentaire, meilleures sont ses caractéristiques prix-performances.

Séparation de la durabilité et de la performance

Le maintien de plusieurs répliques de données utilisateur pour assurer la durabilité en cas de défaillance du nœud était une stratégie courante avec les systèmes pré-cloud, tels que Hadoop, MongoDB et Elasticsearch. L’inconvénient de cette approche était qu’elle coûtait la capacité du serveur. Le fait d’avoir deux ou trois répliques a effectivement doublé ou triplé les besoins en matériel. Une meilleure approche pour une plate-forme de données cloud native consiste à utiliser un magasin d’objets cloud pour assurer la durabilité, sans avoir besoin de répliques.

Les répliques ont un rôle à jouer dans l’amélioration des performances du système, mais à l’ère du cloud, nous ne pouvons mettre les répliques en ligne qu’en cas de besoin. S’il n’y a pas de demande pour une donnée particulière, elle peut résider uniquement dans le stockage d’objets cloud. À mesure que les demandes de données augmentent, une ou plusieurs répliques peuvent être créées pour les servir. En utilisant un stockage d’objets cloud moins cher pour la durabilité et en ne faisant tourner le calcul et le stockage rapide pour les répliques que lorsque cela est nécessaire pour les performances, les plates-formes de données cloud natives peuvent offrir un meilleur rapport qualité-prix.

Capacité à tirer parti de la hiérarchie de stockage

Le cloud nous permet non seulement de faire évoluer le stockage de manière indépendante en cas de besoin, mais il ouvre également de nombreuses autres options de stockage partagé, telles que les disques SSD distants, les disques rotatifs distants, les magasins d’objets et le stockage à froid à long terme. Ces niveaux de stockage offrent chacun des caractéristiques de coût-latence différentes, de sorte que nous pouvons placer les données sur différents niveaux de stockage en fonction de la fréquence d’accès.

Les plates-formes de données natives du cloud sont généralement conçues pour tirer parti de la hiérarchie de stockage facilement disponible dans le cloud. En revanche, l’exploitation de la hiérarchie de stockage n’a jamais été un objectif de conception pour de nombreux systèmes existants, car il était difficile de mettre en œuvre plusieurs niveaux de stockage physique dans le monde pré-cloud. Il fallait assembler du matériel de plusieurs fournisseurs pour mettre en place un système de stockage hiérarchique. C’était fastidieux et chronophage, et seuls les utilisateurs très sophistiqués pouvaient se le permettre.

Plats à emporter

Une pile logicielle uniquement cloud possède des propriétés qui n’ont jamais été prises en compte pour les systèmes traditionnels. La désagrégation est la clé. La gestion fluide des ressources, où l’offre de matériel peut suivre de près la courbe de la demande, deviendra la norme, même pour les systèmes avec état. Des algorithmes parallèles embarrassants doivent être utilisés à chaque occasion jusqu’à ce que les systèmes soient liés aux ressources matérielles. Sinon, il s’agit d’une limitation de votre logiciel. Vous n’obtenez pas ces avantages en déployant des logiciels traditionnels sur des nœuds cloud ; vous devez construire pour le cloud à partir de zéro.