Sync Computing vise à reprendre là où le sans serveur s'arrête

Dans notre perspectives de données pour 2022, nous avons posé la question de savoir si les nuages ​​de données – ou le cloud computing en général – deviendraient plus faciles cette année. Notre question portait sur la gamme ahurissante de services cloud. Le choix est vaste pour le client, mais trop de choix ne serait-il pas une bonne chose ?

Il y a un autre côté de l'équation: choisir votre empreinte cloud computing. Le sans serveur est censé résoudre ce problème. Vous vous abonnez au service et le fournisseur de cloud (ou de services) mettra ensuite automatiquement à l'échelle le cluster en fonction des types d'instances par défaut du service. Une startup qui vient de remporter un financement de démarrage fait valoir que le sans serveur est plus une question de commodité que d’efficacité.

Synchroniser l'informatique vient de sortir de la furtivité avec un financement de démarrage de 6,1 millions de dollars et propose désormais une solution basée sur le cloud. Accordeur automatique service qui introspectera les journaux de votre charge de travail Spark et recommandera l'empreinte optimale de l'instance. Sync Computing a choisi Spark car il est populaire et constitue donc une première cible logique.

Soyons plus précis. Il prend en compte le cloud spécifique sur lequel les charges de travail Spark ont ​​été exécutées, en tenant compte des types d'instances de calcul disponibles et des offres tarifaires pertinentes.

La question naturelle à se poser est la suivante: le calcul sans serveur ne résout-il pas déjà ce problème en permettant au fournisseur de services cloud d'exécuter la mise à l'échelle automatique? La réponse est bien entendu assez subjective. Selon le CEP et cofondateur Jeff Chou, le sans serveur concerne davantage automatisation provisionnement des nœuds et mise à l'échelle vers le haut ou vers le bas plutôt que choisir les bons nœuds Pour le boulot.

Mais il y a une autre partie de la réponse qui est objective: tous les services de cloud computing ne sont pas disponibles. sans serveur, et Spark, la cible initiale de Sync, n'est dans la plupart des cas actuellement proposé que sous forme de service provisionné. service. Il y a quelques mois, Google Cloud lancé Spark sans serveur, tandis que Microsoft a introduit pools SQL sans serveur pour Azure Synapse (qui permet les requêtes vers des tables Spark externes), et Databricks propose un aperçu public.

Nous avons déjà évoqué la question de la jonglerie entre les instances de calcul cloud. Par exemple, lors de notre dernier décompte il y a quelques années, AWS comptait cinq catégories d'instances, 16 familles d'instances et 44 types d'instances. Nous sommes sûrs que ce nombre est plus important maintenant. Il y a quelques années, AWS a lancé Optimiseur de calcul, qui utilise l'apprentissage automatique pour identifier les modèles de charge de travail et les configurations suggérées. Nous n’avons pas encore rencontré d’offres similaires pour d’autres cloud.

Il y a une histoire intéressante sur la façon dont Sync a créé Autotuner. C'était le résultat de l'application du Modèle d'Ising pour optimiser la conception des circuits sur une puce. Ising examine les changements de phase qui se produisent au sein d'un système, qui peuvent s'appliquer à tout ce qui a trait au changement d'état -- il peut s'agir de l'état thermique, du changement de phase d'un matériau ou des changements qui se produisent à différentes étapes de sa fabrication. calculs. Et c’est là qu’intervient l’optimisation de l’empreinte du calcul cloud pour un problème spécifique: dans ce cas, le calcul Spark s’exécute.

Alors que l'entreprise sort de la furtivité, ses offres sont un travail en cours. Les éléments de base d'Autotuner sont en place: un client peut soumettre des journaux de ses précédentes exécutions de calcul Spark, et l'algorithme effectuera des optimisations offrant un choix d'options: optimiser pour le coût ou optimiser pour performance; puis le client repart. À bien des égards, cela s’apparente aux optimisations de requêtes classiques pour SQL. Il prend actuellement en charge EMR et Databricks sur AWS. Un client de référence, Duolingo, a pu diviser par 4 la taille de son cluster de tâches et les coûts de travail par deux.

À l'avenir, Sync Compute a l'intention de mettre à niveau Autotuner vers une API pouvant fonctionner automatiquement; en fonction des préférences du client; cela redimensionnerait automatiquement le cluster. Et puis, il compte étendre cela à la planification et à l’orchestration des tâches. Tout comme il existe des optimisations pour les instances de calcul, il existe des optimisations pour planifier une série de tâches, enchaînant les tâches qui nécessiteraient la même empreinte de calcul.

Bien entendu, pour tout ce qui concerne les données, le calcul n’est pas la seule variable; la forme de stockage entre également en compte. Mais à ce stade, Sync Computing cible le calcul. Et pour l'instant, il cible les tâches de calcul Spark sur AWS, mais il n'y a aucune raison pour que l'approche ne puisse pas être étendue à Azure ou Google Cloud ou appliqué à d'autres moteurs de calcul, tels que ceux utilisés pour les réseaux de neurones, le deep learning ou le HPC.

C'est un début.