Le 18 novembre, Cloudflare a subi un incident qui a touché des milliers de clients, dont des clients utilisant notre service. Notre service proxy est hébergé sur AWS dans une architecture à très haute disponibilité, qui n'a pas été affectée (même par la récente panne AWS). Nous avons également conçu notre système pour résister aux défaillances centralisées et pour limiter l'impact sur les clients en cas de panne.
L'incident a duré environ 5h 34m, du début de la panne jusqu'à la résolution complète (nous avons observé un rétablissement dès 3 heures après le début de l'incident). Vous pouvez consulter notre chronologie de l'incident ici.
Nous souhaitons partager quelques observations intéressantes faites pendant la panne, ainsi que mettre en lumière certains aspects de notre architecture qui ont permis de limiter l'impact sur nos clients.
Observations internes + comment nous avons limité l'impact sur les clients
Notre proxy et notre pipeline de traitement interne étant hébergés sur AWS, aucune de nos opérations critiques n'a été affectée. En revanche, notre tableau de bord est hébergé sur Cloudflare, et a donc été touché comme la plupart des sites web sur internet. Parce que nous utilisons Cloudflare pour l'hébergement (Cloudflare Workers/Pages/etc) et pas uniquement pour le proxying, il ne nous était pas possible de simplement rediriger le DNS pour contourner la panne. De plus, de nombreux services en amont dépendent de Cloudflare d'une manière ou d'une autre. Lorsqu'on cherche une solution peu coûteuse pour distribuer des ressources via un CDN, on se tourne naturellement vers Cloudflare.
Pannes en amont
De notre côté, nous avons pu observer la panne depuis nos serveurs en amont. Nous avons constaté un nombre élevé d'erreurs 5XX provenant de serveurs affectés par la panne Cloudflare sur notre proxy. Nous avons également reçu des alertes à ce sujet, et on peut noter que le moment de la hausse des erreurs correspond presque exactement au début de la panne Cloudflare, à 11h48 UTC.
Notre proxy transitant par les load balancers AWS, et retournant la même réponse HTTP que les sources de scripts en amont, nous disposons de toutes les métriques lorsque des pannes de ce type surviennent. C'est l'un des avantages d'avoir le trafic routé via notre système : nous détectons immédiatement ce type de panne et pouvons en informer nos clients.
Comment nous avons continué à servir les scripts pendant la panne
Nous mettons en cache les requêtes vers des scripts identiques lorsque la politique de cache (Cache-Control) le permet. Ainsi, dans ce cas, les scripts hébergés sur Cloudflare restaient accessibles et le demeuraient jusqu'à l'invalidation du cache. C'est l'un des avantages du proxy cside.
Voici une capture d'écran de notre tableau de bord Grafana interne affichant les métriques de scripts pendant la période de la panne.
Pendant la panne : le taux de cache hit était de 70,8 %, ce qui signifie que de nombreux scripts ont continué à être servis alors qu'ils auraient pu être inaccessibles.
Référence habituelle : ce pourcentage est proche de notre normale. Par exemple, le 17 novembre, le taux moyen de cache hit était de 74 %, ce qui signifie que nous servions notre volume habituel de scripts mis en cache.
Le nombre total de requêtes a toutefois diminué.**
cside est conçu pour faire face aux pannes généralisées
Ce type de panne généralisée est inévitable en raison de la nature centralisée des fournisseurs cloud, mais nous faisons de notre mieux pour en limiter l'impact grâce à des déploiements multi-régions de notre proxy et à une architecture « Fail Open » qui garantit que les requêtes continuent de passer même en cas de défaillance totale.
Il est également important de souligner que nos services edge sont conçus pour fonctionner en mode « isolé » si notre pipeline centralisé tombe en panne. Cela signifie que même si nous ne pouvons plus communiquer avec ce système, notre proxy reste opérationnel et peut continuer à recevoir et à retourner des requêtes de scripts. Par conception, la défaillance d'un système centralisé ne peut donc pas mettre hors service l'ensemble de nos nœuds edge.
Vous pouvez lire une présentation détaillée de la façon dont notre architecture empêche les sites de tomber en panne ici.
Le billet de blog Cloudflare disponible ici entre également dans les détails, et mérite d'être lu.
Note à propos de la gestion des erreurs :
- La cause de la panne Cloudflare était liée à un mode de défaillance particulier des programmes Rust utilisant des appels à la fonction
.unwrap(), ce qui a provoqué les erreurs 500 que nous avons observées. Nous n'utilisons pas du tout cette fonction dans notre codebase de proxy, qui est également écrit en Rust.
cside est une équipe d'ingénieurs web distribués chevronnés. Parmi eux : des contributeurs principaux à des navigateurs comme Servo, d'anciens ingénieurs Cloudflare, et des contributeurs open source de la première heure à Tailwind et Bootstrap. Nous nous soucions du web ; nous traitons notre infrastructure et notre architecture comme une œuvre d'art. Nous saluons des entreprises comme Cloudflare pour la transparence avec laquelle elles partagent les détails de leurs incidents, et nous avons appris de ces retours tout au long de nos carrières pour éviter qu'ils ne se reproduisent autant que possible.
