Le Cloud Computing sans conteneurs

Cloudflare dispose d'une plate-forme de cloud computing appeléeWorkers. Contrairement à toutes les autres plates-formes de cloud computing que je connais, elle n'utilise pas de conteneurs ou de machines virtuelles. Nous y voyons l'avenir de Serverless et du cloud computing en général, et je vais tenter de vous en convaincre.

Un problème s’est posé à nous il y a deux ans. Nous ne pouvions offrir qu'un nombre limité de fonctions et d'options développées en interne, nous avions donc besoin de permettre à nos clients de développer leurs propres solutions. Nous avons cherché un moyen de permettre aux utilisateurs d'écrire du code sur nos serveurs répartis dans le monde entier (nous avions un peu plus d'une centaine de centres de données à l'époque, contre 155 aujourd'hui). Notre système avait besoin de pouvoir exécuter en toute sécurité du code non approuvé, avec un faible surdébit. Nous traitions des millions et des millions de demandes par seconde, il fallait également que le système fonctionne très rapidement.

Lua que nous avions utilisé auparavant ne pouvait pas fonctionner dans une sandbox ; les clients ne pouvaient pas écrire leur propre code sans nous. Les technologies traditionnelles de virtualisation et de conteneur comme Kubernetes auraient été particulièrement coûteuses pour toutes les personnes concernées. L'exploitation de milliers de pods Kubernetes en un seul endroit nécessiterait beaucoup de ressources, mais ce serait encore pire de le faire dans 155 endroits. Il serait plus facile de les mettre à l’échelle qu'en l'absence d'un système de gestion, mais ce serait loin d'être chose aisée pour autant.

Nous avons finalement opté pour une technologie développée par l'équipe Google Chrome pour faire fonctionner le moteur Javascript V8 dans ce navigateur  : Isolates.

Isolates désigne des contextes légers qui regroupent des variables avec le code autorisé à les faire muter. Plus important encore, un seul processus peut exécuter des centaines ou des milliers d'Isolates, en passant facilement de l'un à l'autre. Ils permettent d'exécuter du code non approuvé de plusieurs clients différents au sein d'un seul système d'exploitation. Ils sont conçus pour démarrer très rapidement (plusieurs ont dû démarrer dans votre navigateur rien que pour que vous puissiez charger cette page), et pour ne pas permettre à un Isolate d'accéder à la mémoire d'un autre.

Nous payons le coût d'un runtime Javascript une seule fois, et pouvons ensuite exécuter des scripts pour ainsi dire illimités et quasiment sans frais individuels. Un Isolate donné peut démarrer environ cent fois plus vite qu'un processus Node ne peut démarrer sur mon ordinateur. Plus important encore, ils consomment beaucoup moins de mémoire que ce processus.

Ils sont dotés d'une ergonomie parfaite qui vous permet d'écrire du code sans vous soucier de son fonctionnement ou de sa mise à l’échelle. Simultanément, ils n'utilisent pas de machine virtuelle ou de conteneur, ce qui signifie que vous interagissez plus étroitement avec le hardware qu'avec toute autre forme de cloud computing de ma connaissance. Je crois qu'il est possible avec ce modèle de parvenir à faire tourner du code sur un système dépourvu de système d'exploitation, mais dans un environnement exclusivement Serverless.

Sans vouloir faire la promotion de Workers, je tiens à vous montrer un graphique qui montre bien la différence, pour vous montrer pourquoi je crois que ce changement de paradigme n'est pas anecdotique et constitue un véritable changement de cap :

Ces données reflètent les demandes réelles (y compris la latence du réseau) provenant d'un centre de données à proximité de l'endroit où toutes les fonctions ont été déployées, ce qui représente une charge de travail importante pour le processeur. Source

Tout le monde ne comprend pas parfaitement comment fonctionne une plate-forme traditionnelle Serverless comme Lambda. Elle enclenche un processus conteneurisé pour votre code. Elle n'exécute pas votre code dans un environnement plus léger que celui de Node sur vos propres ordinateurs. Par contre, elle permet de mettre automatiquement à l’échelle ces processus (un peu maladroitement). Cette mise à l'échelle automatique génère des démarrages à froid.

On appelle démarrage à froid le fait de devoir lancer une nouvelle copie de votre code sur une machine. Dans Lambda, cela équivaut à faire tourner un nouveau processus conteneurisé qui peut prendre entre 500 millisecondes et 10 secondes. Toutes les demandes que vous recevrez resteront en suspens pendant une dizaine de secondes, ce qui est pénible pour l'utilisateur. Puisqu'un serveur Lambda ne peut traiter qu'une seule requête à la fois, un nouveau serveur Lambda doit être démarré à froid chaque fois que vous recevez une requête concurrente supplémentaire. Cela signifie qu'une requête à forte latence peut se répéter indéfiniment. Si votre serveur Lada ne reçoit pas une requête assez tôt, il sera arrêté et tout recommencera. Chaque fois que vous lancez un nouveau code, tout se reproduit car chaque serveur Lambda doit être redéployé. On a à juste titre considéré cela comme l'une des raisons pour lesquelles Serverless n'est pas aussi bien qu'on le prétend.

Puisque Workers n'a pas à démarrer de processus, les Isolates se lancent en 5 millisecondes, une durée imperceptible. Les Isolates se déploient et se mettent à l'échelle tout aussi rapidement, en éliminant complètement le problème des technologies Serverless existantes.

L'une des principales caractéristiques d'un système d'exploitation est qu'il vous donne la possibilité d'exécuter plusieurs processus à la fois. Il bascule de manière transparente entre les différents processus qui souhaitent exécuter du code à tout moment. Pour ce faire, il effectue ce qu'on appelle un « changement de contexte », qui consiste à retirer toute la mémoire requise pour un processus puis à la remplacer par la mémoire requise pour le suivant.

Ce changement de contexte peut prendre jusqu'à 100 microsecondes. Si l'on multiplie cela par tous les processus Node, Python ou Go exécutés sur un serveur Lambda moyen, cela crée un gros encombrement, ce qui signifie que toute la puissance des processeurs ne peut être consacrée à l'exécution du code du client ; elle est utilisée pour basculer entre eux.

Un système basé sur Isolates permet d'exécuter tout le code avec un seul processus et utilise ses propres mécanismes pour sécuriser l'accès à la mémoire. Cela signifie qu'il n'y a pas besoin de changements de contexte coûteux en mémoire, avec une machine qui passe le plus clair de son temps à exécuter votre code.

Les runtimes Node ou Python étaient destinés à être exécutés par des individus sur leurs propres serveurs. Ils n'ont jamais été conçus pour fonctionner dans un environnement comptant plusieurs utilisateurs avec le code de milliers d'autres personnes et des exigences de mémoire élevées. Un Node Lambda de base sans code réel consomme 35 Mo de mémoire. Lorsque qu'il est possible de partager le runtime entre tous les Isolates comme nous le faisons, ce chiffre tombe à environ 3 Mo.

La mémoire représente souvent la charge la plus élevée pour l'exécution du code d'un client (encore plus élevée que celle du processeur). Lorsqu'elle est réduite, cela change complètement la situation.

V8 a été essentiellement conçu pour accueillir plusieurs utilisateurs. Il a été conçu pour exécuter le code à partir des nombreux onglets de votre navigateur dans des environnements isolés en un seul processus. Ce n'est pas le cas des Nodes et des runtimes similaires, et cela se voit dans les systèmes à utilisateurs multiples construits avec.

Exécuter le code de plusieurs clients dans le cadre d'un même processus nécessite évidemment d'accorder une attention particulière à la sécurité. Cela n'aurait été ni rentable ni efficace pour Cloudflare si nous avions nous-mêmes conçu cette couche d'isolation. Il faut une quantité astronomique d'essais, de fuzzing, d'essais de pénétration et de recherche de bugs pour bâtir un système si complet et si complexe.

Tout cela n'a été rendu possible que grâce à la nature open-source du V8, et à sa réputation de logiciel dont la sécurité a été la mieux testée au monde. Nous disposons également de quelques couches de sécurité conçues en interne, dont diverses protections contre les attaques temporelles, mais le V8 reste la véritable merveille qui rend ce modèle de calcul possible.

Il ne s'agit pas ici d'un référendum sur la facturation AWS, mais il est intéressant d'en parler rapidement car les aspects économiques sont intéressants. Les serveurs Lambda sont facturés en fonction de leur durée de fonctionnement. Cette facturation est arrondie à la centaine de millisecondes supérieure, ce qui signifie que les clients paient en moyenne 50 millisecondes de trop à chaque exécution. Pire encore, ils vous facturent tout le temps d'utilisation du serveur Lambda, même si celui-ci ne fait qu'attendre qu'une requête externe soit traitée. Comme les requêtes externes peuvent prendre des centaines ou des milliers de ms, vous risquez de finir par payer des montants astronomiques.

Les Isolates ont une si faible empreinte sur la mémoire que nous pouvons au moins nous permettre de ne vous facturer que lorsque votre code est en cours d'exécution.

Dans notre cas, grâce à la réduction des frais généraux, Workers est environ 3 fois moins cher par cycle d'horloge. Un serveur Workers offrant 50 millisecondes de puissance de calcul coûte 0,50 $ par million de requêtes, l'équivalent Lambda est de 1,84 $ par million de requêtes. Je pense que le fait de diviser les coûts par 3 est un élément de motivation assez persuasif pour convaincre les entreprises de passer à des fournisseurs basés sur Isolates.

Amazon propose un produit appelé Lambda@Edge déployé dans son centre de traitement des données CDN. Malheureusement, cela coûte trois fois plus cher qu'un serveur Lambda traditionnel, et sa mise en service prend 30 minutes au départ. Il ne prend pas non plus en charge les requêtes arbitraires, limitant son utilité à des usages de type CDN.

À l'inverse, comme je l'ai déjà dit, avec Isolates, nous sommes en mesure de déployer chaque fichier source dans 155 centres de traitement de données à un prix plus avantageux que celui pratiqué par Amazon pour un seul. Il se peut même qu'il soit moins coûteux d'utiliser 155 Isolates qu'un seul conteneur, ou peut-être qu'Amazon impose-t-elle des tarifs bien supérieurs à ses coûts ? Je ne sais pas comment Amazon calcule ses coûts, mais je peux vous dire que les nôtres nous paraissent tout à fait corrects.

Il est évident depuis longtemps que pour avoir un système vraiment fiable, il doit être déployé à plusieurs endroits dans le monde. Un serveur Lambda opère dans une seule zone de disponibilité, dans une seule région, dans un seul centre de données.

Aucune technologie n'est parfaite et chaque transition comporte son lot d'inconvénients. Un système basé sur Isolate ne peut pas exécuter du code compilé arbitrairement. L'isolation au niveau du processus permet à votre serveur Lambda de faire tourner n'importe quelle source binaire dont il peut avoir besoin. Dans un univers Isolate, vous devez soit écrire votre code en Javascript (nous utilisons beaucoup TypeScript), soit un langage qui cible WebAssembly comme Go ou Rust.

Si vous ne réussissez pas à recompiler vos processus, vous ne pouvez pas les exécuter dans un Isolate. Cela pourrait signifier que l'application Serverless à base Isolate sera réservée aux projets les plus récents et les plus modernes dans un avenir immédiat. Cela peut également signifier que seuls les éléments les plus sensibles à la latence des anciennes applications seront initialement déplacés dans un Isolate. La communauté trouvera peut-être aussi de nouvelles et de meilleures façons de transposer les applications existantes dans WebAssembly, ce qui pourra faire disparaître ce problème.

J'aimerais beaucoup que vous essayiez Workers et que vous racontiez votre expérience à nous et à la communauté. Il nous reste encore beaucoup de choses à développer, et vos commentaires pourraient nous être utiles.

Nous avons aussi besoin d'ingénieurs et de chefs de produits qui estiment la chose intéressante et qui ont envie de lui faire prendre de nouvelles directions. N'hésitez pas à nous contacter si vous habitez à San Francisco, Austin ou Londres.

Vous souhaitez déployer un serveur Cloudflare Worker sans configurer un domaine sur Cloudflare ? Nous facilitons la création d'applications sans serveur avec des sous-domaines personnalisés sur workers.dev. Si vous êtes déjà client(e) de Cloudflare, vous pouvez ajouter Workers à votre site internet actuel en cliquanti ci..

Réserver un sous-domaine