Cloudflare migre son blog principal sur EmDash et Cloudflare Workers

Une architecture serverless taillée pour la haute disponibilité

La nouvelle version du blog de Cloudflare s'appuie sur le CMS (Content Management System, ou système de gestion de contenu) EmDash, couplé au framework web Astro. L'ensemble s'exécute directement sur les Cloudflare Workers (un environnement d'exécution d'API et de scripts sans serveur basé sur V8). L'accès aux données est assuré par Hyperdrive (un service d'accélération et de pooling de connexions de bases de données) relié à une base de données PlanetScale.

Pour garantir des temps de réponse stables malgré un trafic moyen de 75 requêtes par seconde (RPS) pouvant grimper au-delà de 5 000 RPS, une stratégie de mise en cache à plusieurs niveaux a été déployée. Elle combine le Workers Cache et Workers KV (une base de données clé-valeur distribuée à très faible latence). Cette configuration permet de servir 99,5 % des fichiers statiques et 70 % des requêtes globales directement depuis le cache, réduisant la charge sur la base de données.

Qualification sous charge critique avec k6

En amont de la bascule en production, les équipes ont évalué la résistance de l'architecture avec k6 (un outil open-source de test de charge). L'objectif était de valider le comportement du système face à un scénario de type burst (montée brutale du trafic) poussé à 7 000 RPS.

import { randomPageVisit } from "../random-page-visit.ts";

export const options = {
  scenarios: {
    burst: {
      executor: "constant-arrival-rate",
      rate: 7000,
      timeUnit: "1s",
      duration: "1m",
      preAllocatedVUs: 4000,
      maxVUs: 10000,
    },
  },
  thresholds: {
    http_req_failed: ["rate<0.01"],
    "http_req_duration{status:200}": ["p(95)<500", "p(99)<1000"],
  },
};

export default randomPageVisit;

Les métriques exigées imposaient un taux d'erreur 5xx inférieur à 0,01 % et une latence P95 (le temps maximal de réponse pour 95 % des requêtes) sous la barre des 500 ms.

Une bascule sans coupure grâce aux Service Bindings

Afin d'éviter toute interruption de service, un Worker proxy a été positionné en amont pour aiguiller le trafic entre l'ancienne infrastructure et le nouveau blog via des cookies de versioning. En cas d'erreur 500 sur le nouveau système, le proxy basculait automatiquement sur l'ancienne version.

Pour réduire la latence, le proxy communique avec le Worker du blog via l'option NEW_BLOG en utilisant des Service Bindings (un mécanisme permettant à deux Workers de communiquer directement en mémoire sur le réseau interne, sans passer par la résolution DNS, le protocole TLS ou des appels HTTP publics). Le basculement a démarré à 1 % du trafic, avant de progresser à 5 %, 15 %, puis 100 % en fin de journée.

Refonte visuelle et performances observées

Cette migration a également servi de support à une refonte d'interface basée sur le système de design interne Kumo. Le site intègre désormais un mode sombre automatique aligné sur les préférences du système d'exploitation, une table des matières dynamique et une ergonomie revue pour les formulaires.

En production, le système a permis de supprimer les pics de latence observés sur l'ancienne plateforme, maintenant un profil de réponse plat jusqu'à des charges mesurées à 850 RPS.