Premiers pas avec Serverless WebAssembly

Maintenant que WebAssembly est pris en charge par tous les principaux navigateurs et plus de 85% des utilisateurs dans le monde entier JavaScript n'est plus la seule langue du navigateur en ville. Si vous ne l'avez pas encore entendu, WebAssembly est un nouveau langage de bas niveau qui s'exécute dans le navigateur. C’est également une cible de compilation, ce qui signifie que vous pouvez compiler des programmes existants écrits dans des langages tels que C, C ++ et Rust dans WebAssembly et les exécuter dans le navigateur. Jusqu'à présent, WebAssembly a été utilisé pour porter toutes sortes d'applications sur le Web, y compris les applications de bureau les outils de ligne de commande les jeux et les données. outils scientifiques .

Note: Pour une étude de cas approfondie de la façon dont WebAssembly peut être utilisé dans le navigateur pour accélérer les applications Web, consultez mon article précédent . [19659007] WebAssembly en dehors du Web?

Bien que la plupart des applications WebAssembly actuelles soient centrées sur le navigateur, WebAssembly n’était pas conçu à l’origine pour le Web, mais vraiment pour tout environnement en mode bac à sable. En fait, il y a récemment eu beaucoup d'intérêt à explorer la manière dont WebAssembly pourrait être utile en dehors du navigateur, en tant qu'approche générale pour l'exécution de binaires sur tout système d'exploitation ou architecture d'ordinateur, tant qu'il existe un environnement d'exécution WebAssembly qui soutient ce système. Dans cet article, nous verrons comment WebAssembly peut être exécuté en dehors du navigateur, de manière sans serveur / Fonction en tant que service (FaaS).

WebAssembly pour applications sans serveur

En un mot, fonctions sans serveur sont un modèle informatique dans lequel vous confiez votre code à un fournisseur de cloud, et les laissez exécuter et gérer la mise à l'échelle de ce code pour vous. Par exemple, vous pouvez demander que votre fonction sans serveur soit exécutée chaque fois que vous appelez un point de terminaison d'API ou que des événements, tels que le téléchargement d'un fichier dans votre compartiment Cloud, en dépendent. Le terme «sans serveur» peut sembler abusif, car les serveurs sont clairement impliqués, mais il est sans serveur, de notre point de vue, car nous n'avons pas à nous soucier de la gestion, du déploiement ou de la mise à l'échelle de ces serveurs. [19659011] Bien que ces fonctions soient généralement écrites dans des langages tels que Python et JavaScript (Node.js), vous pouvez choisir d'utiliser WebAssembly à la place:

1. Faster Initialization Times
   Les fournisseurs sans serveur prenant en charge WebAssembly (y compris Cloudflare et Rapidement signalent qu'ils peuvent lancer des fonctions au moins un ordre de grandeur plus rapide que la plupart des fournisseurs de cloud, avec d'autres langues. Pour ce faire, ils exécutent des dizaines de milliers de modules WebAssembly dans le même système. processus, ce qui est possible car la nature en bac à sable de WebAssembly constitue un moyen plus efficace d’obtenir l’isolation pour laquelle les conteneurs sont traditionnellement utilisés.
2. Pas de réécriture nécessaire [19659013] L'un des principaux attraits de WebAssembly dans le navigateur est la possibilité de porter du code existant sur le Web sans avoir à tout réécrire en JavaScript. Cet avantage est toujours valable dans le cas d'utilisation sans serveur, car les fournisseurs de cloud limitent les langues dans lesquelles vous pouvez écrire vos fonctions sans serveur. Ils prennent généralement en charge Python, Node.js et peut-être quelques autres, mais certainement pas les langages C, C ++ et Rust. . En prenant en charge WebAssembly, les fournisseurs sans serveur peuvent prendre en charge indirectement beaucoup plus de langues.
3. Plus léger
   Lors de l’exécution de WebAssembly dans le navigateur, nous comptons sur l’ordinateur de l’utilisateur final pour effectuer nos calculs. Si ces calculs sont trop intensifs, nos utilisateurs ne seront pas contents lorsque leur fan d’ordinateur s’agitera. L'exécution de WebAssembly en dehors du navigateur nous confère les avantages de WebAssembly en termes de rapidité et de portabilité, tout en maintenant la légèreté de notre application. De plus, puisque nous utilisons notre code WebAssembly dans un environnement plus prévisible, nous pouvons potentiellement effectuer des calculs plus intensifs.

Un exemple concret

Dans mon article précédent ici dans Smashing Magazine Nous avons expliqué comment nous avions accéléré une application Web en remplaçant les calculs JavaScript lents par du code C compilé dans WebAssembly. L'application Web en question était fastq.bio un outil qui permettait de visualiser la qualité des données de séquençage de l'ADN.

Comme exemple concret, réécrivons fastq.bio en tant qu'application qui utilise WebAssembly sans serveur. d’exécuter WebAssembly dans le navigateur. Pour cet article, nous allons utiliser Cloudflare Workers un fournisseur sans serveur prenant en charge WebAssembly et basé sur le moteur de navigateur V8. Fastly, un autre fournisseur de cloud, travaille sur une offre similaire, mais sur la base de son Lucet .

Commençons par écrire du code Rust pour analyser la qualité des données de séquençage d’ADN. Pour plus de commodité, nous pouvons utiliser la bibliothèque bioinformatique Rust-Bio pour traiter l'analyse des données d'entrée et la bibliothèque wasm-bindgen pour nous aider à compiler notre code Rust pour WebAssembly. Voici un extrait du code qui lit les données de séquençage de l'ADN et génère un JSON avec un résumé des mesures de qualité:

 // Importer les packages
caisse externe wasm_bindgen;
utilisez bio :: seq_analysis :: gc;
utilisez bio :: io :: fastq;
...

// Cette balise "wasm_bindgen" nous permet de noter les fonctions
// nous voulons exposer dans notre module WebAssembly
# [wasm_bindgen]
pub fn fastq_metrics (seq: String) -> Chaîne
{
    ...

    // boucle en boucle dans le fichier
    let reader = fastq :: Reader :: new (seq.as_bytes ());
    pour résultat dans reader.records () {
        let record = result.unwrap ();
        let sequence = record.seq ();

        // Calculer des statistiques simples sur chaque enregistrement
        n_reads + = 1.0;
        let read_length = sequence.len ();
        let read_gc = gc :: gc_content (sequence);

        // Nous voulons dessiner des histogrammes de ces valeurs
        // donc nous stockons leurs valeurs pour un tracé ultérieur
        hist_gc.push (read_gc * 100.0);
        hist_len.push (read_length);

        ...
    }

    // retourne les statistiques sous forme de blob JSON
    json! ({
        "n": n_reads,
        "hist": {
            "gc": hist_gc,
            "len": hist_len
        },
        ...
    }). to_string ()
} 

Nous avons ensuite utilisé l’outil de ligne de commande de Cloudflare wrangler pour effectuer la lourde tâche de compilation vers WebAssembly et de déploiement vers le cloud. Une fois cela fait, nous recevons un point de terminaison API qui utilise les données de séquençage en entrée et renvoie un JSON avec des métriques de qualité des données. Nous pouvons maintenant intégrer cette API dans notre application.

Voici un fichier GIF de l'application en action:

Image agrandie )

Le code complet est disponible sous GitHub (open-source).

Tout est dans le contexte

Pour mettre en place l'approche sans serveur WebAssembly Dans le contexte, considérons quatre manières principales de créer des applications Web de traitement de données (des applications Web permettant d’analyser les données fournies par l’utilisateur):

Comme indiqué ci-dessus, le traitement des données peut être effectué à plusieurs endroits:

1. Côté serveur
   Il s'agit de l'approche adoptée par la plupart des applications Web, où les appels d'API sont effectués. dans le traitement frontal du traitement des données sur le serveur principal
2. JavaScript côté client
   Dans cette approche, le code de traitement des données est écrit en JavaScript et s'exécute dans le navigateur. L'inconvénient est que votre performance va en prendre un coup, et si votre code d'origine n'était pas en JavaScript, vous devrez le réécrire à partir de zéro!
3. WebAssembly côté client
   Ceci implique la compilation de code d'analyse de données dans WebAssembly. et l'exécuter dans le navigateur. Si le code d'analyse a été écrit dans des langages tels que C, C ++ ou Rust (comme c'est souvent le cas dans mon domaine de la génomique), cela évite d'avoir à réécrire des algorithmes complexes en JavaScript. Il offre également la possibilité d'accélérer notre application (par exemple, comme indiqué dans un article précédent ).
4. Serverless WebAssembly
   Il s'agit d'exécuter WebAssembly compilé sur le cloud, en utilisant un modèle de type FaaS. (par exemple cet article)

Alors pourquoi choisiriez-vous l’approche sans serveur plutôt que les autres? D'une part, comparé à la première approche, il présente les avantages liés à l'utilisation de WebAssembly, notamment la possibilité de porter du code existant sans avoir à le réécrire en JavaScript. Comparé à la troisième approche, WebAssembly sans serveur signifie également que notre application est plus légère, car nous n’utilisons pas les ressources de l’utilisateur pour effectuer les calculs. En particulier, si les calculs sont assez compliqués ou si les données sont déjà dans le cloud, cette approche est plus logique.

Par contre, l'application doit maintenant établir des connexions réseau, de sorte que l'application sera probablement Ralentissez. De plus, en fonction de l'ampleur du calcul et de la possibilité de le décomposer en éléments d'analyse plus petits, cette approche peut ne pas être appropriée en raison des limitations imposées par les fournisseurs de cloud en mode sans serveur sur l'utilisation de l'exécution, de la CPU et de la RAM.

Conclusion

Comme nous l'avons vu, il est maintenant possible d'exécuter du code WebAssembly sans serveur et de tirer parti des avantages de WebAssembly (portabilité et vitesse) et de ceux des architectures fonctionnelles en tant que service (mise à l'échelle automatique et personnalisée). prix d'utilisation). Certains types d'applications, comme l'analyse de données et le traitement d'images, pour n'en citer que quelques-uns, peuvent grandement bénéficier d'une telle approche. Bien que l'exécution ait souffert des allers-retours supplémentaires vers le réseau, cette approche nous permet de traiter plus de données à la fois et de ne pas épuiser les ressources des utilisateurs.

(rb, dm, yk, il)