Infrastructure de Services Cloud FaaS sur nœuds IoT

Dans cette section, nous présentons les approches ayant des objectifs similaires: faire du calcul distribué sur des environnements très limités, même si les capacités ne sont pas toujours aussi restreintes dans toutes les approches.

Si nous regardons les approches classiques de cloud computing, basés sur ferme de serveurs et non sur IoT, nous pouvons trouver des systèmes tels que PyWren [3] proposant une architecture de stateless-cloud cloud élastique et passant à l’échelle. Leur plate-forme a pour objectif premier une prise en main facile, d’avoir un temps d’exécution réduit, un planificateur de tâches rapide, l’équilibrage de charge et la possibilité d’ajouter des dépendances au run-time. Ils ont également implémenté la ré-exécution symétrique des tâches pour renforcer la tolérance aux pannes du système et plusieurs optimisations sur le parallélisme du code. Aucun aspect de consommation énergétique n’y est toutefois abordé.

Dans l’article Middleware Implementation in Cloud-MANET Mobility Model for Internet of Smart Devices [1], nous pouvons voir une intégration du Cloud et du réseau MANET. Cette approche utilise le réseau ad-hoc MANET pour connecter des appareils intelligents entre eux puis implémente une couche android middleware afin d’offrir un service de cloud computing aux utilisateurs. Cependant, les capacités des appareils utilisés, même étant un environnement constraint, sont importantes (CPU et GPU complexes), et l’optimisation finale porte uniquement sur l’amélioration de distance de couverture de bord de réseau et le débit de celui-ci.

Sur un autre périmètre, celui des réseaux véhiculaires, nous pouvons trouver d’autres approches, comme VANET-cloud: a generic cloud computing model for vehicular Ad Hoc networks [2], qui implémentent du cloud computing sur réseaux véhiculaires afin de réduire le délai, et l’énergie consommée, augmenter l’efficacité, l’évolutivité, la fiabilité et la sécurité du cloud computing pour les systèmes de transport intelligents (STI). Ce système intègre de nouvelles ressources embarquées déjà présentes sur les véhicules pour étendre l’environnement cloud traditionnel. La fiabilité envisagée reste toutefois sur la communication inter-véhiculaire et non sur d’autres types de pannes.

cuCloud [5] propose un système partageant notre logique: créer un réseau ad-hoc opportuniste avec nos propres appareils, PC dans leur cas, pour améliorer les capacités de calcul. Original, basé sur une participation volontaire de machines aux ressources sous-utilisées, cuCloud se concentre uniquement sur le passage à l’échelle et les performances, sans prise en compte de l’énergie. Ce système est de plus basé sur la réplication des machines virtuelles et non sur l’exécution de fonctions légères comme nous le proposons.

Dans cette section, nous commencerons par décrire les messages et canaux ainsi que les grands traits de l’architecture de notre modèle. Dans la deuxième partie, nous présenterons la stratégie de consensus mise en œuvre et finalement, nous présenterons les techniques de partitionnement des graphes implantées dans l’architecture.

Matériel et banc de test: Pour les tests, nous avons utilisé un Macbook Pro 15 comme client et Dispatcher, et 7 cartes ESP-32 comme Workers. Nous avons testé avec un banc de test public numpy ¹¹1github.com/serge-sans-paille/numpy-benchmarks/tree/master/benchmarks de calcul numérique, adapté pour notre infrastructure. Ces fonctions ont été exécutées en ajoutant une série d’annotations pour les rendre compréhensibles pour le parser du client.

Métriques: Dans les tests, nous avons pris en considération nos trois principaux facteurs de notre modèle: la tolérance aux pannes, la performances et la consommation d’énergie. Pour la consommation d’énergie, nous avons utilisé un modèle décrit dans [8], incluant le courant moyen en mode actif, le courant moyen en mode veille et le duty-cycle. Nous avons inferé la consommation des ESP-32 [4] dans notre cas, avec seulement besoin du WIFI et des modules de carte de base, par $I_{active}=0,260A$ et $I_{sleep}=2,5*10^{-6}A$ alors que l’ESP-32 est en mode hibernation.

Nous avons testé pour chaque fonction du benchmark numpy trois configurations (1%, 10% et sans duty-cyle) et en augmentant la complexité des calculs. Sur la figure 4, nous observons que le rapport entre le temps d’exécution du Macbook Pro et celui des différents configurations diminue avec l’exécution durée de la tâche convergeant vers environ 1,2 fois le temps d’exécution sans duty-cycle, 1,5 fois pour 10 % duty-cycle et 1,8 fois pour 1 % duty-cycle. Cependant, si nous observons la consommation énergétique, nous remarquons qu’il n’y a presque pas de différence entre le 10% et le 1% duty-cycle dans les tâches supérieures à 2 secondes. Le ratio performance/énergie présente donc le meilleur compromis pour 10% duty-cycle. Par ailleurs, sur la figure 5, nous pouvons remarquer que sur les tâches longues, nous retrouvons un comportement similaire pour toutes les fonctions testées, qui nous permet de trouver des seuils de convergence pour nos configurations. Cela montre que notre plate-forme se comporte essentiellement de la même manière pour toutes les fonctions du benchmark.

Enfin, si nous regardons l’influence du duty cycle sur la tolérance aux pannes, nous pouvons voir qu’il n’a aucune influence. Cependant, si nous nous intéressons à la taille des clusters, nous voyons que cela impacte directement la tolérance aux pannes du système, le rendant plus forte sur les clusters plus gros. En observant la figure de droite, le meilleur compromis panne/performance se retrouve avec 5 nœuds par cluster.

Après les tests, nous pouvons conclure que PyCloudIoT maximise le compromis cherché pour une configuration de cluster à 5 nœuds avec un duty-cycle de 10%. Nous constatons une convergence stable pour les tâches moyennes / longues (de 5 à 60s) d’environ 1,4 fois plus longue que celle exécutée sur le Macbook Pro tout en diminuant presque totalement la consommation d’énergie (98%). Comme travaux futurs, nous testerons et comparerons différents algorithmes de consensus, ainsi qu’optimisations de partitionnement de graphes. Ensuite, nous nous concentrerons sur la réalisation d’un analyseur syntaxique apprenant qui décidera des tâches à décharger en fonction des exécutions précédentes.