Nouveaux outils pour la sécurité de la production : déploiements graduels, Stack Traces, contrôle du volume de requêtes et nouveaux SDK

L'édition 2024 de la Developer Week est consacrée à la préparation à la production. Le lundi 1er avril, nous avons annoncé que D1, Queues, Hyperdrive et Workers Analytics Engine sont désormais prêts pour le déploiement en production et accessibles en disponibilité générale. Le mardi 2 avril, nous avons effectué une annonce identique au sujet de notre plateforme d'inférence Workers AI. Et nous n'avons pas encore fini !

Cependant, l'état de préparation à la production ne dépend pas uniquement de l'ampleur et la fiabilité des services avec lesquels vous développez des solutions. Vous devez également disposer d'outils permettant d'apporter des modifications de manière sûre et fiable. Vous dépendez non seulement des outils que fournit Cloudflare, mais également de la capacité de contrôler et d'adapter précisément le comportement de Cloudflare aux besoins de votre application.

Aujourd'hui, nous annonçons cinq mises à jour conçues pour mettre davantage de puissance entre vos mains (les déploiements graduels, les traces d'appels mappées à la source dans Tail Workers, une nouvelle API de contrôle du volume de requêtes, de nouveaux SDK pour API et des mises à jour de Durable Objects), chacune développée en gardant à l'esprit les services de production essentiels à l'activité. Nous développons nous-mêmes nos produits avec Workers (notamment Access, R2, KV Waiting Room, Vectorize, Queues Stream et bien d'autres), et nous dépendons nous-mêmes de chacune de ces nouvelles fonctionnalités pour nous assurer que nos services sont prêts pour la production – et nous sommes aujourd'hui ravis de les proposer à tous les utilisateurs.

Le déploiement d'une instance Workers est presque instantané ; en quelques secondes seulement, votre modification est en ligne partout.

Lorsque votre solution est prête pour un déploiement en production, chaque modification apportée comporte un risque plus important, tant en termes de volume que d'attentes. Vous devez respecter votre contrat de niveau de service (SLA) avec garantie de disponibilité de 99,99 %, ou vous avez un ambitieux objectif de niveau de service (SLO) de latence de P90. L'échec d'un déploiement traitant 100 % du trafic pendant 45 secondes peut entraîner des millions de requêtes infructueuses. Si elle est déployée en une seule fois, une modification subtile du code peut provoquer l'envoi d'un véritable déluge de tentatives à un backend déjà saturé. Ce sont les types de risques que nous prenons en compte et que nous atténuons nous-mêmes pour nos services développés sur Workers.

L'approche pour limiter ces risques consiste à déployer les changements graduellement – ce que l'on appelle communément des déploiements progressifs :

1. La version actuelle de votre application s'exécute en production.

2. Vous déployez la nouvelle version de votre application en production, mais vous n'acheminez qu'un petit pourcentage du trafic vers cette nouvelle version et vous attendez qu'elle « absorbe » la production, en surveillant les régressions et les bugs. Si un incident se produit, vous pouvez le détecter précocement, avec un faible pourcentage (par exemple, 1 %) du trafic, et vous pouvez rapidement effectuer une restauration.

3. Vous augmentez ensuite progressivement le pourcentage de trafic, jusqu'à ce que la nouvelle version reçoive 100 % du trafic ; à ce stade, son déploiement est alors finalisé.

Aujourd'hui, nous proposons une méthode exceptionnelle pour déployer progressivement les modifications de code sur Workers et Durable Objects via l'API Cloudflare, l'interface de ligne de commande Wrangler ou le tableau de bord de Workers. Les déploiements graduels entrent en phase de bêta ouverte ; vous pouvez utiliser les déploiements graduels avec n'importe quel compte Cloudflare ayant souscrit à l'offre gratuite Workers, et vous pourrez très prochainement commencer à utiliser les déploiements graduels avec des comptes Cloudflare ayant souscrit l'offre payante de Workers et l'offre Enterprise. Une bannière sera affichée sur le tableau de bord Workers lorsque votre compte y aura accès.

Si vous exécutez simultanément deux versions de votre instance Workers ou votre instance Durable Objects dans votre environnement de production, vous souhaitez certainement pouvoir filtrer vos indicateurs, vos exceptions et journaux par version. Ceci peut vous aider à identifier rapidement les problèmes de production, lorsque la nouvelle version n'est déployée que pour un petit pourcentage du trafic, ou à comparer les indicateurs de performance, lorsque le trafic est réparti à parts égales. Nous avons également ajouté l'observabilité au niveau de la version à l'échelle de notre plateforme :

• Vous pouvez filtrer les analyses de données par version depuis le tableau de bord Workers et via l'API GraphQL Analytics.

• Les événements Workers Trace Events et Tail Workers incluent l'identifiant de version de votre instance Workers, ainsi que des champs facultatifs de message de version et d'identifiant de version.

• Lorsque vous utilisez wrangler tail pour afficher les journaux en direct, vous pouvez afficher les journaux pour une version spécifique.

• Vous pouvez accéder à l'identifiant, au message et à la balise de version depuis le code de votre instance Workers, en configurant la liaison des métadonnées de version.

Vous pouvez également souhaiter vous assurer que chaque client ou utilisateur ne voit qu'une version cohérente de votre instance Workers. Nous avons ajouté l'affinité de version, afin d'assurer que les requêtes associées à un identifiant particulier (telles que l'utilisateur, la session ou tout autre identifiant unique) soient toujours traitées par une version cohérente de votre instance Workers. L'affinité de session, lorsqu'elle est utilisée avec le moteur d'ensembles de règles, vous offre un contrôle total sur le mécanisme et l'identifiant utilisés pour garantir la « persistance ».

Les déploiements graduels entrent dans la phase de bêta ouverte. Tandis que nous progressons vers la disponibilité générale, nous nous employons à déployer les fonctionnalités suivantes :

• Remplacements de version. Invoquez une version spécifique de votre instance Workers afin de réaliser des tests avant de l'utiliser pour servir du trafic de production. Cela vous permettra d'effectuer des déploiements bleu/vert.

• Cloudflare Pages. Laissez le système CI/CD de Cloudflare Pages faire évoluer automatiquement les déploiements à votre place.

• Restaurations automatiques. Revenez automatiquement en arrière lorsque le taux d'erreurs augmente pour une nouvelle version de votre instance Workers.

Nous sommes impatients d'entendre vos commentaires ! Utilisez ce formulaire de commentaires pour nous faire part de vos réflexions ou contactez-nous sur notre Discord pour développeurs, sur le canal #workers-gradual-deployments-beta.

L'état de préparation à la production exige d'assurer le suivi des erreurs et des exceptions, avec l'objectif de les réduire à zéro. Lorsqu'une erreur se produit, la première chose que vous souhaitez généralement examiner est la trace d'appels de l'erreur – c'est-à-dire les fonctions spécifiques qui ont été appelées, dans quel ordre, depuis quelle ligne et quel fichier, et avec quels arguments.

La plupart du code JavaScript (pas uniquement exécuté sur Workers, mais sur toutes les plateformes) est d'abord groupé, souvent compilé de source à source (ou « transpilé »), puis minifié avant d'être déployé en production. Cette opération se déroule en tâche de fond, afin de créer des bundles plus petits, permettant d'optimiser les performances et de convertir le code Typescript en code JavaScript, si nécessaire.

Si vous avez déjà vu une exception renvoyer une trace d'appels telle que /src/index.js:1:342, cela signifie que l'erreur s'est produite au 342e caractère du code minifié de votre fonction... ce qui n'est évidemment pas très utile pour le débogage.

Les cartes des sources permettent de résoudre ce problème : elles renvoient le code compilé et minifié au code original que vous avez écrit. Les cartes des sources sont combinées avec la trace d'appels renvoyée par le runtime JavaScript, afin de présenter une trace de pile lisible par l'humain. Par exemple, la trace d'appels suivante montre que l'instance Workers a reçu une valeur null inattendue à la ligne 30 du fichier down.ts. Il s'agit d'un point de départ utile pour le débogage, et vous pouvez approfondir l'examen de la trace d'appels afin de comprendre les fonctions qui ont été appelées, et dont la définition a entraîné la valeur null.

Voici comment elle fonctionne :

Unexpected input value: null
  at parseBytes (src/down.ts:30:8)
  at down_default (src/down.ts:10:19)
  at Object.fetch (src/index.ts:11:12)

1. Si vous définissez upload_source_maps = true dans le fichier wrangler.toml, Wrangler génère et transfère automatiquement tout fichier de carte des sources lorsque vous exécutez wrangler deploy ou wrangler versions upload.

2. Lorsque votre instance Workers lance une exception non détectée, nous récupérons la carte de sources et nous l'utilisons pour mapper la trace d'appels de l'exception avec les lignes du code source original de votre instance Workers.

3. Vous pouvez ensuite visualiser cette trace de pile désobfusquée dans les journaux en temps réel ou dans Tail Workers.

À partir d'aujourd'hui, la version bêta ouverte vous permet de transférer des cartes des sources vers Cloudflare lorsque vous déployez votre instance Workers. Pour faire vos premiers pas, vous pouvez commencer par lire la documentation, et à partir du 15 avril, le runtime Workers commencera à utiliser les cartes des sources pour désobfusquer les traces d'appels. Lorsque les traces d'appels mappées à la source seront disponibles, nous afficherons une notification sur le tableau de bord de Cloudflare et nous publierons un message sur le compte X Cloudflare Developers.

Une API n'est prête pour la production que si elle dispose d'une fonctionnalité offrant un contrôle du volume de requêtes raisonnable. Au fur et à mesure que vous développez votre solution, la complexité et la diversité des contrôles que vous devez appliquer pour équilibrer les besoins de clients spécifiques, protéger l'intégrité de votre service ou appliquer et ajuster les limites dans des scénarios spécifiques augmentent également. L'API de Cloudflare est confrontée à ce défi : chacun de nos dizaines de produits, comportant chacun de nombreux points de terminaison d'API, peut avoir besoin d'appliquer différents contrôles du volume de requêtes.

Depuis 2017, vous pouvez configurer les règles de contrôle du volume de requêtes sur Cloudflare. Jusqu'à aujourd'hui, toutefois, la seule façon de contrôler cette fonctionnalité était depuis le tableau de bord Cloudflare ou via l'API Cloudflare. Il n'était pas possible de définir un comportement au niveau du runtime ou, dans une instance Workers, d'écrire du code qui interagit directement avec le contrôle du volume de requêtes. Vous pouviez uniquement choisir d'appliquer ou non le contrôle du volume à une requête avant qu'elle n'atteigne votre instance Workers.

Aujourd'hui, nous inaugurons une nouvelle API, en version bêta ouverte, qui vous permet d'accéder directement au contrôle du volume de requêtes depuis votre instance Workers. Elle est ultra-rapide, conçue sur la base de memcached, et très simple à ajouter à votre instance Workers. Par exemple, la configuration suivante définit un contrôle du volume de requêtes de 100 requêtes sur une période de 60 secondes :

Ensuite, dans votre instance Workers, vous pouvez appeler la méthode de contrôle du volume de requêtes pour la liaison RATE_LIMITER, en fournissant une clé de votre choix. Compte tenu de la configuration ci-dessus, ce code renverra un code d'état de réponse HTTP 429 si plus de 100 requêtes vers un chemin spécifique sont transmises dans un délai de 60 secondes :

[[unsafe.bindings]]
name = "RATE_LIMITER"
type = "ratelimit"
namespace_id = "1001" # An identifier unique to your Cloudflare account

# Limit: the number of tokens allowed within a given period, in a single Cloudflare location
# Period: the duration of the period, in seconds. Must be either 60 or 10
simple = { limit = 100, period = 60 } 

Maintenant que Workers peut se connecter directement à un magasin de données comme memcached, que pouvons-nous fournir d'autre ? Des compteurs ? Des verrous ? Un cache en mémoire ? Le contrôle du volume de requêtes est la première des nombreuses primitives que nous envisageons de fournir dans Workers, afin de répondre aux questions que nous recevons, depuis des années, sur l'emplacement où devrait résider un état partagé temporaire couvrant plusieurs isolats Workers. Si aujourd'hui, vous comptez intégrer l'état à la portée globale de votre instance Workers, nous développons actuellement de meilleures primitives, conçues pour des scénarios d'utilisation spécifiques.

export default {
  async fetch(request, env) {
    const { pathname } = new URL(request.url)

    const { success } = await env.RATE_LIMITER.limit({ key: pathname })
    if (!success) {
      return new Response(`429 Failure – rate limit exceeded for ${pathname}`, { status: 429 })
    }

    return new Response(`Success!`)
  }
}

L'API de contrôle du volume de requêtes dans Workers est en version bêta ouverte, et vous pouvez commencer en consultant la documentation.

L'état de préparation à la production implique d'évoluer de l'approche consistant à effectuer des modifications en cliquant sur des boutons dans un tableau de bord vers une approche programmatique, en utilisant un service « d'infrastructure en tant que code » tel que Terraform ou Pulumi ou en transmettant directement des requêtes d'API, soit par vos propres moyens, soit par l'intermédiaire d'un SDK.

L'API de Cloudflare est colossale et reçoit continuellement de nouvelles fonctionnalités ; en moyenne, nous mettons à jour nos schémas d'API entre 20 et 30 fois par jour. Jusqu'à présent toutefois, nos SDK d'API ont fait l'objet d'un développement et d'une maintenance manuels, et nous ressentions donc un besoin urgent d'automatiser cette approche.

C'est ce que nous avons fait, et nous annonçons aujourd'hui de nouveaux SDK pour l'API Cloudflare dans trois langages (Typescript, Python et Go) ; d'autres langages seront pris en charge prochainement.

Chaque SDK est généré automatiquement avec l'API Stainless, sur la base des schémas OpenAPI qui définissent la structure et les fonctionnalités de chacun de nos points de terminaison d'API. Cela signifie que lorsque nous ajoutons une nouvelle fonctionnalité à l'API Cloudflare, pour n'importe quel produit Cloudflare, ces SDK d'API sont automatiquement régénérés et de nouvelles versions sont publiées, garantissant qu'elles sont correctes et à jour.

Vous pouvez installer les SDK en exécutant l'une des commandes suivantes :

Si vous utilisez Terraform ou Pulumi, dans l'envers du décor, le fournisseur Terraform de Cloudflare utilise actuellement le SDK Go existant, non automatisé. Lorsque vous exécutez terraform apply, le fournisseur Terraform de Cloudflare détermine quelles requêtes d'API doivent être transmises et dans quel ordre, puis les exécute à l'aide du SDK Go.

// Typescript
npm install cloudflare

// Python
pip install cloudflare

// Go
go get -u github.com/cloudflare/cloudflare-go/v2

Le nouveau SDK Go généré automatiquement ouvre la voie à une prise en charge plus complète de Terraform pour tous les produits Cloudflare, fournissant ainsi un ensemble de base d'outils dont vous pouvez avoir l'assurance qu'ils sont à la fois corrects et à jour des dernières modifications de l'API. Nous nous dirigeons vers un avenir où chaque fois qu'une équipe produit de Cloudflare crée une nouvelle fonctionnalité exposée via l'API Cloudflare, elle est automatiquement prise en charge par les SDK. Attendez-vous à de nouvelles mises à jour tout au long de l'année 2024.

Nous développons un grand nombre de nos produits, parmi lesquels Waiting Room, R2 et Queues, ainsi que des plateformes telles PartyKit, avec Durable Objects. Durable Objects est désormais déployé dans le monde entier, avec une nouvelle prise en charge pour la région Océanie ; vous pouvez considérer la solution comme un ensemble de singletons d'instances Workers pouvant fournir un point de coordination unique et un état persistant. Ces éléments sont parfaits pour les applications qui nécessitent une coordination en temps réel des utilisateurs, à l'image des chats interactifs ou de l'édition collaborative. Croyez-en la parole d'Atlassian :

Parmi les nouvelles fonctionnalités que nous proposons figurent les tableaux blancs de Confluence, qui offrent un moyen libre de capturer le travail non structuré (par exemple, un brainstorming ou une planification précoce) avant qu'il ne soit documenté de manière plus formelle par les équipes. L'équipe a envisagé de nombreuses options pour la collaboration en temps réel, et a finalement décidé d'utiliser la solution Durable Objects de Cloudflare. Durable Objects s'est avéré être fantastiquement bien adapté à cet espace problématique, en proposant une combinaison unique de fonctionnalités qui nous a permis de simplifier considérablement notre infrastructure et d'évoluer facilement vers un grand nombre d'utilisateurs. – Atlassian

Nous n'avions auparavant pas exposé les tendances analytiques associées dans le tableau de bord, ce qui rendait difficile la compréhension des modèles d'utilisation et des taux d'erreur dans un espace de noms Durable Objects, à moins d'utiliser directement l'API GraphQL Analytics. Le tableau de bord Durable Objects a maintenant été remanié, vous permettant d'approfondir les indicateurs autant que vous le souhaitez.

Dès le premier jour, Durable Objects a pris en charge les protocoles WebSocket, permettant à de nombreux clients de se connecter directement à une instance Durable Objects pour l'envoi et la réception de messages.

Cependant, il arrive que l'application client ouvre une connexion WebSocket, puis cesse de faire que ce soit. Pensez à cet onglet que vous avez laissé ouvert dans votre navigateur pendant les cinq dernières heures, sans y revenir ; s'il utilise les protocoles WebSocket pour envoyer et recevoir des messages, il dispose en réalité d'une connexion TCP de longue durée qui n'est utilisée pour rien. Si cette connexion est établie à une instance Durable Objects, cette dernière doit continuer à fonctionner en attendant qu'un événement se produise, en consommant de la mémoire et en vous coûtant de l'argent.

C'est pour résoudre ce problème que nous avons initialement lancé WebSocket Hibernation. Aujourd'hui, nous annonçons que cette fonctionnalité a quitté la phase bêta, et qu'elle est désormais proposée en disponibilité générale. Avec WebSocket Hibernation, vous définissez une réponse automatique à utiliser pendant l'hibernation et vous sérialisez l'état afin qu'il survive à l'hibernation. Cela fournit à Cloudflare les données entrantes dont nous avons besoin pour maintenir les connexions WebSocket ouvertes depuis les clients, tout en « mettant en hibernation » l'instance Durable Objects, afin qu'elle ne fonctionne pas activement et que le temps d'inactivité ne vous soit pas facturé. Le résultat est que votre état est toujours disponible en mémoire lorsque vous en avez réellement besoin, mais qu'il n'est pas conservé inutilement lorsque ce n'est pas le cas. Tant que votre instance Durable Objects est en hibernation, même si des clients actifs sont toujours connectés par le biais d'une instance de protocole WebSocket, cette durée ne vous sera pas facturée.

En outre, les développeurs nous ont fait part de leurs commentaires concernant les coûts des messages WebSocket entrants transmis à Durable Objects, qui privilégie les messages plus petits et plus fréquents pour les communications en temps réel. À partir d'aujourd'hui, les messages WebSocket entrants seront facturés à l'équivalent de 1/20e d'une requête (au lieu d'un message équivalent à une requête, comme c'était le cas jusqu'à présent). Voici un exemple de tarification :

.tg {border-collapse:collapse;border-color:#ccc;border-spacing:0;} .tg td{background-color:#fff;border-color:#ccc;border-style:solid;border-width:1px;color:#333; font-family:Arial, sans-serif;font-size:14px;overflow:hidden;padding:10px 5px;word-break:normal;} .tg th{background-color:#f0f0f0;border-color:#ccc;border-style:solid;border-width:1px;color:#333; font-family:Arial, sans-serif;font-size:14px;font-weight:normal;overflow:hidden;padding:10px 5px;word-break:normal;} .tg .tg-0lax{text-align:left;vertical-align:top} .tg .tg-4kyp{color:#0E101A;text-align:left;vertical-align:top} .tg .tg-bhdc{color:#0E101A;font-weight:bold;text-align:left;vertical-align:top}

Requêtes de connexion WebSocket

Messages WebSocket entrants

Requêtes facturées

Facturation des requêtes

Avant

10K

432M

432 010 000

$64.65

Après

10K

432M

21 610 000

$3.09

Jusqu'à présent, l'état de préparation à la production sur la nouvelle génération de plateformes cloud exigeait de ralentir la vitesse de livraison. Cela nécessitait d'assembler de nombreux outils déconnectés ou de mettre à l'arrêt des équipes entières afin d'intervenir sur les plateformes internes, et d'adapter vos propres couches de productivité à des plateformes dont la complexité était problématique.

La plateforme pour développeurs de Cloudflare est désormais mature et prête pour la production. Nous nous engageons à proposer une plateforme intégrée, sur laquelle les produits opèrent ensemble de manière intuitive et où il n'existe pas 10 façons différentes de faire une même chose, sans nécessiter une matrice de compatibilité pour aider les utilisateurs à comprendre les services qui fonctionnent ensemble. Chacune de ces mises à jour illustre cette démarche, en intégrant de nouvelles fonctionnalités aux différents produits et composants de la plateforme de Cloudflare.

À cette fin, nous voulons que vous nous disiez non seulement ce que vous voulez voir ensuite, mais également les aspects que nous pourrions encore simplifier, ou encore de quelle manière nos produits pourraient mieux fonctionner ensemble. Dites-nous ce que nous pourrions faire de plus ; le Discord pour développeurs de Cloudflare est toujours ouvert.