Nous avons récemment publié un article explorer quel type d'infrastructure est nécessaire pour exécuter les fonctions de pointe. Pour cette pièce, nous avons parlé à plusieurs experts de l'industrie dans des conversations de grande envergure. Bien que nous n'ayons pas pu utiliser toutes les conversations de l'article, nous voulions les partager intégralement afin que vous puissiez obtenir tous les éléments intéressants que nous ne pouvions pas inclure. Vous trouverez ci-dessous la conversation de Ryan avec Malte Ubl, CTO chez Vercel. 

Cette conversation a été modifiée pour plus de clarté et de contenu. 

---

Ryan Donovan: Pour la structure réelle du serveur physique derrière fonctions de bord, avez-vous des serveurs que vous possédez ou avez-vous un partenaire derrière cela ?

Malte Ubl : Pour les fonctions de périphérie réelles en production, elles s'exécutent sur l'infrastructure de travail de Cloudflare. Cependant, il est très différent du produit que vous pouvez acheter chez Cloudflare. Le produit de travail de Cloudflare est ce qui met fin au trafic.

Il assume ce rôle principal en tant que proxy inverse. La façon dont nous les utilisons est comme un backend, n'est-ce pas ? Parce que nous terminons le trafic dans notre propre infrastructure. Nous les utilisons donc de manière très similaire à une fonction sans serveur implémentant une route - nous obtenons la route, nous déterminons, d'accord, nous devons la router vers cette fonction, puis lui demander d'effectuer cette requête. 

Il est important de noter que c'est quelque chose que nous appelons l'infrastructure définie par le cadre. Les fonctions Edge ne sont pas primitives comme Lambda ou les workers que vous programmez directement, n'est-ce pas ? Où vous faites un fichier terraform et vous dites comme, je veux le Lambda, et c'est le fichier que je compile, que je télécharge là, bla, bla. Ce n'est pas comme ça. Au lieu de cela, dans votre cadre, vous utilisez simplement la manière idiomatique de créer vos pages ou vos routes API. Cela n'a pas vraiment d'importance, car vous utilisez le langage de votre framework.

Nous allons prendre cela et dire, d'accord, nous transformons ce qui a fonctionné sur votre machine locale et l'enveloppons de telle sorte que lorsque nous déployons sur l'infrastructure que nous utilisons, il se comporte exactement de la même manière. Cela fait que nos fonctions de bord produisent cette notion plus abstraite parce que vous ne l'utilisez pas si concrètement. Next.js a un moyen d'activer les fonctions de périphérie. Droite? Et vous n'avez jamais à penser à Vercel à ce moment-là. C'est juste que ça marche. 

DR : À propos des restaurations de données… cela nécessite-t-il beaucoup de réplication sur ces serveurs ou existe-t-il un emplacement central ?

MU: C'est une bonne question. La façon dont notre système fonctionne est que, par défaut, nous maintenons l'activité dans certains délais généreux - vous ne voudriez pas revenir à quelque chose il y a six mois, n'est-ce pas ? Avec un peu de chance. Parce que tout ce que nous faisons est sans serveur dans cette notion abstraite, car il n'y a pas cette infrastructure physique, donc cela ne s'applique pas réellement aux fonctions de périphérie. Mais avec notre produit sans serveur plus traditionnel, basé sur AWS Lambda, nous archiverons votre fonction si elle n'a pas été appelée pendant deux semaines.

Mais quand contre toute attente, nous recevrons une autre demande, nous la désarchiverons à la volée afin qu'elle se comporte de manière absolument transparente. C'est juste un peu plus lent. Encore une fois, dans la pratique, cela ne se produit jamais du côté de la production. Un actif statique est en quelque sorte plus intéressant, car il y en a beaucoup et ceux-ci sont accélérés grâce aux caches d'extraction. Si vous revenez à quelque chose d'ancien, cela pourrait être temporairement un peu plus lent.

Mais dans le cas d'une restauration instantanée, ce n'est en fait pas le cas car il est en fait beaucoup plus probable que vous reveniez à quelque chose qui avait peut-être du trafic il y a 30 minutes. Probablement, il fait encore très chaud.

DR : Et juste, juste pour être clair que les fonctions sont sans serveur, non ? Aucun état stocké sur eux, n'est-ce pas ?

MU: Ils sont sans serveur, vous ne gérez rien de leur cycle de vie. Je pense que ce qui est vraiment intéressant, c'est la façon dont notre produit de fonction de périphérie est tarifé par rapport à une fonction sans serveur traditionnelle et comment ils se comportent au fil du temps.

Mais l'une des décisions qui prévaut dans l'espace sans serveur est que vous ne faites pas réellement de concurrence sur la fonction individuelle - honnêtement, je pense que c'est un peu bizarre. Surtout que les gens utilisent beaucoup node.js sur notre plate-forme, où l'idée fondatrice était que vous pouviez gérer plusieurs requêtes simultanément sur le même noyau, n'est-ce pas ? Sur la pile sans serveur traditionnelle, cela ne se produit pas. Ce n'est pas particulièrement efficace si votre charge de travail est liée aux E/S. 

La plupart des sites Web qui effectuent un rendu en temps réel, le modèle sera, vous avez une charge de travail liée au processeur, qui rend la page, mais vous attendez également le backend. Presque toujours. Il y aura toujours une demande backend et cela prendra un certain temps et pendant ce temps, le processeur pourrait faire d'autres travaux. Sur le produit des fonctions de pointe, c'est absolument le cas.

Je pense que ce qui est très unique dans notre produit, même par rapport aux travailleurs sur lesquels il est basé, c'est que notre tarification est entièrement basée sur le CPU net. Cela signifie que vous ne payez que lorsque le processeur est occupé. C'est entièrement gratuit en attendant le backend.

C'est très intéressant si votre backend est lent. C'est une priorité pour moi à cause de toutes les API d'IA, qui sont incroyablement lentes. Les cas d'utilisation très courants sont que vous appelez une API, vous n'exécutez presque aucun calcul. Peut-être que vous faites du munging sur le JSON, non ? Mais ce n'est presque rien, on parle de deux millisecondes. C'est le CPU net. Mais OpenAI met 40 secondes à répondre. Donc, sur ce modèle de tarification, vous payez pour deux millisecondes, et c'est en fait incroyablement attractif.

C'est possible grâce à un emballage très serré. Le modèle de tarification traditionnel sans serveur est basé sur des gigaoctets-heures - ils paient essentiellement pour la RAM. La façon dont tout ce produit est conçu est que vous ne pouvez pas vous permettre d'en avoir plusieurs qui n'utilisent pas de RAM incrémentielle. C'est pourquoi cela fonctionne pour nous deux. Cela permet essentiellement la révolution de l'IA parce que vous ne pouvez pas vous permettre de l'exécuter sur des serveurs sans serveur traditionnels, car ils deviennent tous viraux comme des fous, vous ne pouvez pas non plus vraiment vous permettre de les exécuter sur des serveurs.

C'est donc un très bon moment pour ça. 

DR : En parlant de cela, avez-vous une infrastructure ou CloudFlare a-t-il une infrastructure sur ces travailleurs de périphérie qui prend en charge le traitement AI/ML ? Une sorte de GPU, de TPU sur le backend ?

MU: Pas du côté de la fonction de périphérie, mais ce cas d'utilisation est essentiellement le cas d'utilisation lié aux E/S, pour lequel ils sont idéaux, où vous externalisez le modèle et l'inférence ailleurs et vous appelez simplement cela.

Nous investissons dans le côté sans serveur des charges de travail liées au processeur. Parce qu'ils sont bons à ça de toute façon. Vous avez juste besoin de flexibilité. 

Par exemple : les limitations sur le type de code qu'ils peuvent exécuter. C'est principalement JavaScript et Wasm qui vous amènent assez loin. Mais vous ne pouvez pas exécuter langchain. Vous ne pouvez pas faire de véritable inférence. Vous ne pouvez pas non plus exécuter Python, que nous prenons en charge dans notre produit principal sans serveur.

Ce qui est vraiment populaire, c'est dans la même application. Construire une application Next.js ou Remix pour votre front-end. Mais implémenter les routes API, qui seraient traditionnellement également écrites en JavaScript et Python. Les gens aiment faire cela parce qu'ils ont accès à des bibliothèques spécialisées qui ne sont tout simplement pas disponibles dans le système JavaScript. 

DR : Donc, revenons au proxy initial, comment faites-vous pour que cet appel de pare-feu soit si rapide dans le monde entier ? Y a-t-il un serveur quelque part qui attend l'appel ?

MU: Je pense que la bonne réponse est de nombreuses couches de mise en cache, n'est-ce pas ? Et beaucoup de Redis. Il ne s'agit certainement pas d'un serveur, mais de plusieurs serveurs. Il y a trois couches principales impliquées.

L'un fait la terminaison TLS et est la couche IP du pare-feu. C'est un peu un pare-feu de couche HTTP, mais il regarde principalement le trafic de manière agnostique et essaie de filtrer les mauvaises choses sans payer le prix de savoir vraiment ce qui se passe. C'est la première couche. Absolument optimisé pour le service HTTP à haut débit.

Descendre d'une couche est la couche qui a la plus grande empreinte. Celui-ci comprend qui sont les clients, quels sont leurs déploiements, etc. Cela est motivé par une mise en cache substantielle. Nous avons quelque chose que nous appelons notre pipeline push mondial. Lorsque les choses changent, il les pousse dans tous les centres de données afin que les hits d'origine réels - où vous revenez jusqu'à une base de données centrale - utilisent le chemin de service à chaud du trafic utilisateur, en particulier pour les sites qui ont une forme quelconque de non-trivial circulation. Vous pouvez toujours produire un cas où vous faites une demande par jour. 

Ensuite, la dernière couche est notre service d'évocation de fonction de périphérie. C'est toujours quelque chose qui fonctionne dans notre infrastructure. Ce service a plusieurs rôles, mais il agit principalement comme un équilibreur de charge. Une chose dont nous sommes vraiment satisfaits, c'est que lorsque vous utilisez le produit CloudFlare directement dans ce rôle traditionnel, cela peut être très agréable sur votre machine. Parce qu'il prend votre connexion H2 et continue d'affecter le même travailleur. C'est très rapide. 

Parce que nous avons le luxe d'avoir une couche devant, nous imitons essentiellement le même comportement où nous équilibrons la charge que nous-mêmes et disons, d'accord, nous avons ici un travailleur qui peut prendre un peu plus de trafic, puis multiplexer une autre demande sur le même connexion.

Vous ne savez pas ce que vous savez sur HTTP, mais il s'agit essentiellement de HTTP `Keep-Alive`. Il utilise la même connexion pour communiquer avec le back-end CloudFlare.

DR : Donc, gardez simplement cette connexion avec un seul travailleur et ne passez pas par le même chemin de pare-feu. 

MU: Exactement. Nous avons comme ce service d'invocation qui n'est pas seulement une machine, un centre de données, n'est-ce pas ? Mais c'est beaucoup moins que ce dont vous auriez besoin de travailleurs. Parce que tout d'abord, ils sont multi-locataires. Et aussi c'est un service très simple au final, qui ne fait que du proxy HTTP haute performance.

DR : Vous avez dit que c'était bon pour les charges de travail liées aux E/S. Pour quels types d'applications ce type de fonction de périphérie est-il vraiment utile ?

MU: Eh bien, je veux dire, ils n'ont pas besoin d'être liés aux E/S - je pense que les E/S lourdes sont en fait le bon mot, car vous pouvez utiliser le processeur. Ce n'est pas vraiment de cela qu'il s'agit. Ils font des E/S et vous attendez un backend, n'est-ce pas ? Si vous ne faites que du CPU, ce n'est pas nécessairement la bonne plate-forme.

Nous ne voyons pas vraiment cela lourdement. Je mentionnais le cas d'utilisation de l'IA comme le genre de cas extrême où il est particulièrement précieux. Mais pour la page Web dynamique typique, nous prenons en charge d'autres modes de rendu, comme génération incrémentale de sites statiques, qui diffuse la page statique petit à petit. Il y a une mise à jour asynchrone en arrière-plan avant que je ne diffuse un élément dynamique en direct. C'est effectivement toujours une opération lourde d'E/S. 

Parce que pourquoi est-ce que je fais ça ? Avez-vous un excellent exemple de réponse avec quelque chose de aléatoire ? Mais ce n'est pas vraiment ce que vous voulez. Droite? Vous voulez parler à une base de données, vous voulez parler à votre passerelle API. Quelque chose comme ça, c'est ce que tu veux faire. Donc, vous allez toujours attendre que cela revienne, car vous déchargez le traitement sur un autre système, même si c'est très rapide.

C'est toute la charge de travail sur le Web : donnez-moi votre panier, affichez la page de détail du produit, affichez la recommandation d'un article de blog en fonction de l'utilisateur. Toutes ces choses que les gens font sur Vercel relèvent toutes de cette charge de travail.

Ceux qui sont vraiment liés au processeur sont vraiment une exception. Je ne dirais pas que c'est du jamais vu, mais le modèle de fonction de périphérie est bon par défaut car la charge de travail Web dynamique typique s'intègre très bien dans ce modèle.

DR : La façon dont nous avons obtenu cette interview était que vous vous lancez dans le jeu des bases de données avec des bases de données sans serveur ?

MU: Oui, absolument.

DR : Comment cela s'intègre-t-il dans les fonctions de pointe ?

MU: Nous proposons en fait trois bases de données différentes, plus une qui n'est pas vraiment une base de données, mais ce que nous appelons notre cache de données.

Ils sont tous liés. Le KV (valeur clé) que nous avons lancé est un produit KV répliqué à l'échelle mondiale. Pour que cela s'intègre directement dans les fonctions de bord. 

Notre produit Postgres que nous avons lancé n'est vraiment pas sans serveur. Mais vous choisissez une région, c'est là que se trouve la base de données. Nous soutenons la lecture à partir du bord, mais vous devez être prudent, n'est-ce pas ? Si vous faites des chutes d'eau, vous devrez passer par une longue connexion à latence élevée pour le faire. C'est donc quelque chose dont les gens doivent être conscients, mais d'un autre côté, les gens veulent juste une base de données Postgres même si ce n'est peut-être pas la chose parfaite. 

Il y a deux façons de l'atténuer. Si vous effectuez une charge de travail importante sur une telle base de données, le cache de données que nous livrons est parfait pour cela. Cela vient avec les compromis de la mise en cache, comme ça, vous devez invalider des choses.

Mais c'est l'essentiel pour lequel nous passons du temps à le rendre vraiment, vraiment sympa. L'autre chose que nous prenons en charge est que les utilisateurs peuvent choisir d'appeler les fonctions de périphérie dans une région. C'est un peu bizarre, mais fondamentalement, ils sont toujours déployés à l'échelle mondiale, mais ensuite via notre proxy et notre infrastructure internes.

Vous pouvez dire, invoquez-le à côté de ma base de données. C'est pour le cas où vous voulez avoir ce système régional. Il peut s'agir d'une base de données, de votre backend dans le centre de données de votre entreprise sur site. À cause de cela, nous devons prendre en charge cela, ce qui ne vous donne évidemment plus la faible latence globale. Mais une fois que vous parlez deux fois à votre base de données, c'est toujours moins cher du point de vue de la latence.

C'est pourquoi nous avons décidé d'expédier cette fonctionnalité. C'est super utile pour ce cas. Vous bénéficiez toujours des avantages du modèle de tarification et des performances de démarrage à froid, etc.

Mots clés: travailleurs du cloud, fonctions de bord, gestion des infrastructures, suivant.js

• Contenu propulsé par le référencement et distribution de relations publiques. Soyez amplifié aujourd'hui.
• PlatoData.Network Ai générative verticale. Autonomisez-vous. Accéder ici.
• PlatoAiStream. Intelligence Web3. Connaissance Amplifiée. Accéder ici.
• PlatonESG. Automobile / VE, Carbone, Technologie propre, Énergie, Environnement, Solaire, La gestion des déchets. Accéder ici.
• Décalages de bloc. Modernisation de la propriété des compensations environnementales. Accéder ici.
• La source: https://stackoverflow.blog/2023/08/07/speeding-up-the-i-o-heavy-app-qa-with-malte-ubl-of-vercel/