Comment Studo utilise Scalingo pour faire du FaaS ?

Vous connaissez le FaaS ? Mais est-ce que vous saviez que vous pouvez faire du FaaS sur Scalingo ?

L'équipe tech de Studo utilise le Platform as a Service Scalingo depuis plusieurs années pour héberger ses projets web. Dans cet article, nous verrons comment ils combinent plusieurs fonctionnalités de Scalingo pour faire du « Function as a Service » ou FaaS.

Mais tout d'abord nous allons vous présenter Studo.

Qui est Studo ?

Studo est une application qui permet aux étudiants Européens de gérer leurs études en ligne en Allemagne, Autriche et ailleurs. Dans son marché initial en Autriche, elle compte actuellement plus de 150 000 utilisateurs actifs par mois, ce qui est impressionnant si l'on considère qu'il y a environ 300 000 étudiants en Autriche.

Ce qui veut dire que 1 étudiant autrichien sur 2 utilise Studo !

Comme ils se développent en Allemagne, où le nombre d'étudiants est 10 fois plus grand, ils s'attendent à une forte augmentation de l'activité.

Si vous êtes intéressés par les technologies qu'ils utilisent : le backend utilise Kotlin et la base de données est MongoDB.

PaaS, FaaS, quésaco ?

Scalingo est un Platform as a Service, ou PaaS en abrégé. Un PaaS est un environnement managé dans le cloud qui permet de déployer et d'héberger des projets web sans avoir à installer ou maintenir de serveurs, sans avoir besoin de connaissances en administration système.

En sous-main, un PaaS reçoit le code source envoyé par les développeurs pour le packager dans des conteneurs. Par défaut ces containers sont tout le temps allumés : qu'il soit 2h du matin ou 15h de l'après-midi, les containers sont présents et immédiatement prêt à recevoir les requêtes des internautes.

Tous les frameworks web habituellement utilisés par les développeurs fonctionnent sur un PaaS comme par exemple Ruby on Rails, Django, Node.js ou Symfony.

Dans le Function as a Service (FaaS) le code applicatif est réparti dans plusieurs "fonctions", des sortes de mini-programmes qui réagissent à des événements. Il est alors possible de chaîner plusieurs fonctions pour réaliser un travail complexe.

Le FaaS est un changement de paradigme complet dans la façon de programmer des applications web.

Chaque fonction est séparée des autres par un mécanisme d'isolation. Contrairement au PaaS, les fonctions ne vivent que durant leur temps d'exécution. Dès que l'événement est traité par la fonction, elle s'arrête. La plupart des plateformes proposant du FaaS imposent un traitement dans un délai maximal de quelques secondes.

Deux types de traitement informatique

Pour nous aider à comprendre comment Scalingo peut être utilisé pour faire du FaaS il est important de définir les 2 grands types de traitement qu'une application web peut être amenée à effectuer.

Traiter des requêtes web

Le premier traitement le plus évident est qu'une application web doit réagir aux requêtes HTTP envoyées par les navigateurs des internautes ou des machines qui utilisent les projets web d'API.

Réagir à des événements

Lorsqu'un événement apparait, on exécute un certain morceau de code. C'est le cas lorsqu'on met en place du traitement asynchrone : au lieu d'exécuter un traitement tout de suite, on empile la description du traitement dans une file d'attente tandis qu'un autre processus vient dépiler cette file d'attente et exécute les traitements conformément à leur description.

Autant le PaaS que le FaaS permettent de traiter des requêtes web, c'est l'essence même de la programmation web. Comme vous l'aurez compris c'est le fait de réagir à des événements qui est le terrain privilégié du FaaS et ce n'est traditionnellement pas le cas pour le PaaS. Sauf chez Scalingo ! Nous allons voir pourquoi avec un cas concret.

Étude de cas

Nous avons pu parler récemment avec Zoltan Sasvari, le lead développeur backend de Studo. Il est également responsable de l'administration du système de l'application Studo. Et il travaille également sur une autre application. Entre le développement et la mise à l'échelle pour servir plusieurs centaines de milliers d'utilisateurs actifs, cela représente beaucoup de travail et n'est possible que parce que Studo est hébergé chez Scalingo qui facilite la vie des développeurs puisqu'ils n'ont plus de serveurs à gérer ou à effectuer de tâches d'administration système.

Pour gérer les tâches récurrentes, il a commencé avec un worker (processus séparé de l'application principale) très simple qui n'était qu'une boucle exécutant des tâches à intervalles réguliers.

Mais l'exécution de toutes ces tâches dans le même conteneur a commencé à créer des problèmes au fur et à mesure que Studo se développait. Certaines tâches devaient être exécutées simultanément, d'autres exigeaient beaucoup de mémoire et monopolisaient les ressources, d'autres encore étaient très légères et ne prenaient pas beaucoup de temps à exécuter.

Ces tâches ne vont pas bien ensemble et doivent être exécutées dans leurs propres conteneurs.

Les diviser en plusieurs workers aurait coûté beaucoup d'argent, car Studo aurait payé des conteneurs toujours actifs pour chaque worker.

Comme les workers s'exécutent dans des conteneurs permanents, il n'était pas rentable d'avoir un worker par tâche alors que certaines tâches ne duraient que quelques heures par mois au total.

Nous n'aurions pas pu faire 15+ workers parce que cela aurait coûté très cher.

C'est pourquoi il a décidé d'utiliser des conteneurs one-off.

C'est quoi un conteneur one-off ?

Comme nous l'avons expliqué précédemment, lorsque vous poussez du code sur Scalingo, la plateforme construit une image de conteneur et package le code avec toutes les dépendances nécessaires pour faire tourner ce code à l'intérieur du conteneur. C'est la phase de dite de BUILD.

Ensuite intervient la phase de RUN où Scalingo va allumer et faire tourner ce conteneur. Scalingo sait comment démarrer ces conteneurs en se basant sur la technologie détectée pendant la phase de BUILD.

La phase de RUN permet de démarrer le projet de façon à ce qu'il réponde aux requêtes web.

Il existe une autre manière d'utiliser l'image de conteneur construite pendant la phase de BUILD : le conteneur one-off.

Un conteneur one-off est un conteneur éphémère supplémentaire qu'on démarre en lui passant une commande. Votre code doit donc savoir interpréter la commande que vous lui passez. La commande peut être interactive ou non.

La façon la plus simple d'exécuter un conteneur one-off est de télécharger notre CLI et d'exécuter la sous-commande run. L'argument passée après le mot-clé run est la commande que l'on veut voir exécutée.

Voici quelques exemples en utilisant le CLI de Scalingo.

scalingo -a my-application run ls -l

Exécute la commande "ls -l" dans un conteneur one-off. Le conteneur one-off démarre, exécute la commande, retourne le résultat à l'utilisateur et s'éteint immédiatement.

scalingo -a my-application run rails console

Exécute la console de debug Ruby on Rails. Le conteneur one-off démarre, exécute la commande, les entrées/sorties permettent à l'utilisateur de taper des commandes dans la console et de voir le résultat. Ici le conteneur s'éteint dès que la console Rails est quittée.

Si la façon la plus simple d'invoquer un conteneur one-off est d'utiliser notre CLI, il existe également une API.

L'API des conteneurs one-off pour exécuter des fonctions

Zoltan l'a fait en déclenchant des conteneurs one-off via l'API Scalingo lorsqu'il avait besoin d'exécuter une tâche via un unique worker beaucoup plus petit qu'auparavant.

Un worker utilise l'API Scalingo pour exécuter différentes tâches dans des conteneurs one-offs.

Il utilise des conteneurs one-offs pour effectuer des tâches telles que :

• L'archivage de données. Chaque démarrage de l'application par un utilisateur est enregistré en base de données dans une collection "appStarts" et sa taille augmente donc rapidement, mais comme seule l'activité récente est nécessaire à Studo, les données plus anciennes sont archivées au cas où elles seraient nécessaires pour du debug. Zoltan utilise des conteneurs one-offs pour requêter les données, les formater (pour enlever toutes les données personnelles en lien avec le RGPD) et les envoyer à l'AWS S3.
• L'analyse de données. Cette tâche requête les données de la collection "appStarts", les agrège et enregistre le résultat dans InfluxDB pour les visualiser dans Grafana. Cela leur permet, par exemple, de trouver les problèmes de performances.
• La mise à jour des abonnements. Les utilisateurs paient soit sur l'App Store d'Apple, soit sur le Play Store de Google. L'application doit périodiquement synchroniser l'état des abonnements en appelant les API de ces app stores.

L'exécution des tâches se fait comme une fonction pour un FaaS : à l'invocation de la tâche, la plateforme démarre un conteneur avec les informations nécessaires permettant à la tâche de s'exécuter. Dès que la tâche est terminée, le conteneur s'arrête.

Que la tâche ait duré 15 secondes ou 30 minutes, Scalingo facture uniquement le temps d'exécution du conteneur, à la minute près (toute minute commencée est due).

Grâce à des conteneurs one-offs, Studo conserve tous les avantages d'un PaaS comme Scalingo tout en pouvant bénéficier des avantages normalement exclusifs du serverless comme le paiement à la consommation.

Il est extrêmement simple d'utiliser des conteneurs one-offs. Cela fonctionne très, très bien !

Conclusion

Comme on a pu le voir dans cet article il est tout à fait possible d'utiliser le PaaS Scalingo et ses API pour exécuter des fonctions temporaires en réaction à des événements.

Ceci permet aux développeurs utilisant Scalingo d'utiliser la plateforme comme un FaaS.

L'intérêt pour eux est pouvoir continuer à utiliser les mêmes technologies, les mêmes outils et les mêmes modèles mentaux que pour leurs projets web habituels.