Une plateforme sans serveur offre une élasticité extrême, mais impose des défis majeurs à l'infrastructure. Alibaba Cloud propose une solution combinant Container Service for Kubernetes (ACK) à d'autres services cloud pour optimiser l'accès aux données avec Elastic Container Instance. Cette rubrique décrit les défis liés à l'accès aux données dans le cloud computing sans serveur et la solution permettant de les surmonter.
Défis de l'accès aux données dans le cloud computing sans serveur
Une plateforme sans serveur permet de mettre à l'échelle rapidement les ressources ou les charges de travail des applications. Quelques secondes après le démarrage, l'application est prête à l'emploi. Les ressources de calcul s'ajustent en quelques secondes, voire en millisecondes. L'infrastructure doit donc relever des défis importants. Le stockage constitue la ressource d'infrastructure la plus sollicitée. Si le débit d'E/S du système de stockage ne suit pas la cadence de mise à l'échelle des instances, le système ne peut pas respecter les exigences de mise à l'échelle en quelques secondes. Par exemple, le système peut mettre à l'échelle les instances de conteneurs en deux secondes, mais le téléchargement des données depuis le système de stockage prend des dizaines de secondes, voire plusieurs minutes.
La conteneurisation sans serveur impose les exigences suivantes aux systèmes de stockage traditionnels :
Accès hautement concurrentiel : les ressources de calcul traitent uniquement les données, stockées dans le système de stockage. La surcharge liée à l'accès aux données augmente donc dans les scénarios de forte concurrence. Cela affecte la stabilité du système et accroît l'utilisation de la bande passante.
Faible latence réseau : l'architecture découplant le calcul du stockage augmente la latence d'accès aux données métier.
Débit d'E/S élastique : la bande passante de stockage traditionnelle augmente avec la capacité de stockage. Un grand nombre d'accès simultanés par les conteneurs peut déclencher une limitation de débit et entraîner un conflit entre les ressources de calcul élastiques et la bande passante de stockage.
Solution d'optimisation de l'accès aux données
Pour mieux prendre en charge le cloud computing sans serveur, l'équipe ACK collabore avec les équipes des logiciels de base et du système d'exploitation, d'Elastic Container Instance et de Data Lake afin de proposer une solution d'optimisation de l'accès aux données basée sur Elastic Container Instance. Cette solution respecte les règles suivantes :
Conformité aux normes existantes pour garantir une expérience utilisateur cohérente. Par exemple, Sidecar et Device Plugin dans Kubernetes servent de normes pour exposer les API et les interfaces utilisateur.
Prise en charge du contrôle des privilèges Linux à grain fin.
Synchronisation des mises à jour du noyau et des mises à jour sous-jacentes issues de Kubernetes open source. La conception reste cohérente avec Kubernetes open source.
L'architecture utilisée par Fluid dans le cloud computing sans serveur se compose du plan de données et du plan de contrôle.
Plan de données : les conteneurs FUSE correspondant à différents environnements d'exécution composent le plan de données. Déployés conjointement avec les applications en tant que conteneurs sidecar, ils gèrent l'accès aux données lié aux applications.
-
Plan de contrôle : le plan de contrôle comprend l'injecteur, le contrôleur d'environnement d'exécution de cache et le contrôleur d'application.
Injecteur : il transforme les informations relatives à l'accès aux données et à l'implémentation de l'environnement d'exécution en informations lisibles par Sidecar, puis injecte ces informations dans les applications. Il contrôle également l'ordre de lancement des conteneurs d'une charge de travail. Celle-ci peut être un pod ou une charge de travail d'IA big data, telle qu'un Spark Job, un TensorFlow Job ou un MPI Job.
Contrôleur d'environnement d'exécution de cache : il gère l'élasticité des caches de données en fonction du débit du FUSE Sidecar, ainsi que les permissions d'accès aux données.
Contrôleur d'application : il termine les conteneurs FUSE d'un pod lorsque les conteneurs d'un batch Job, d'un TensorFlow Job ou d'un Spark Job au sein du même pod sont terminés.