Le CDN Fastly s’enrhume : de nombreux sites inaccessibles, un correctif se déploie

Le CDN Fastly s’enrhume : de nombreux sites inaccessibles, un correctif se déploie

Fastly -> Slowly

Avatar de l'auteur
Sébastien Gavois

Publié dans

Internet

08/06/2021 2 minutes
33

Le CDN Fastly s’enrhume : de nombreux sites inaccessibles, un correctif se déploie

Twitch, Reddit, le Guardian, The New York Times, Le Monde, certains sites d’Amazon… de nombreux services sont inaccessibles depuis peu avant 12h. En cause, le CDN Fastly qui rencontre des soucis. Ce dernier ne rentre pas dans les détails, précisant simplement que ses équipes travaillent à sa résolution.

Comme nous avons déjà eu l’occasion de l’expliquer en détail, les tuyaux d’Internet fonctionnent avec un mélange de différents services : fournisseurs d’accès (les fameux FAI) et de contenu (les services), transitaires point d’échange, hébergeur, réseaux de diffusion de contenu (CDN), etc.

Certains occupent une place très importante et peuvent rapidement devenir un single point of failure (SPOF) pour certains services. Les exemples sont nombreux dans le passé, à tous les niveaux. Cette fois-ci c’est le CDN Fastly qui est en cause (un concurrent de CloudFlare et Akamai pour ne citer qu’eux). Résultat des courses, une partie du web n’est plus accessible.

Ce matin, à 11h58 heures française, Fastly explique sur sa page de statut de ses services qu’il étudie un « impact potentiel sur les performances de ses services CDN », au niveau mondial. Nul doute que les équipes de Faslty sont sur le pied de guerre pour rétablir la situation au plus vite.

Des mises à jour ont été publiées depuis pour préciser que les recherches continuent. La société vient d’annoncer que « le problème a été identifié et un correctif est en cours d'implémentation », mais elle n’a pour le moment donné aucun détail sur les causes et le délai de rétablissement.

Bref, si certains sites sont inaccessibles, il ne faut pas chercher plus loin. On peut citer Reddit, le site officiel gov.uk, des journaux comme le Guardian et le New York Times, Le Monde, Amazon au Royaume-Uni, Twitch, GitHub… bien qu’un retour à la normale semble se profiler. La liste est probablement bien longue et la question de la redondance se pose de nouveau. 

33

Écrit par Sébastien Gavois

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Commentaires (33)


Et SPOF le CDN !


C’est dommage de faire SPOF quand on joue à cache cache…


Mdr



Et +1 pour le sous-titre


Je n’y connais rien mais comment peut on avoir des SPOF dans ce genre de réseau ? Après faut avoir les détails de la panne mais bon.


En fait les services web en question ne sont pas down à proprement parler. Là c’est un prestataire chargé de mettre en cache les contenus pour (on ne rigole pas) éviter les indisponibilités qui est tombé.



Et comme ce prestataire est en frontal du visiteur, ça s’est vu.



Après, comment ce genre de chose peut arriver : il suffit d’une config foireuse poussée sur le service pour faire s’effondrer le château de cartes.



Dans la catégorie 3615 mavie : j’ai eu droit à un coup similaire dans une précédente vie où les admins sys avaient poussé une nouvelle conf DNS sur les serveurs. Sauf que le resolv.conf n’était plus lisible que par root. Résultat toutes les applis du serveur étaient en blackout.


SebGF

En fait les services web en question ne sont pas down à proprement parler. Là c’est un prestataire chargé de mettre en cache les contenus pour (on ne rigole pas) éviter les indisponibilités qui est tombé.



Et comme ce prestataire est en frontal du visiteur, ça s’est vu.



Après, comment ce genre de chose peut arriver : il suffit d’une config foireuse poussée sur le service pour faire s’effondrer le château de cartes.



Dans la catégorie 3615 mavie : j’ai eu droit à un coup similaire dans une précédente vie où les admins sys avaient poussé une nouvelle conf DNS sur les serveurs. Sauf que le resolv.conf n’était plus lisible que par root. Résultat toutes les applis du serveur étaient en blackout.


Ha ok il joue ce rôle, je pensais qu’il faisais partie de ceux qui transportes les routes comme à la dernière panne causé par des diffusions de routes BGP à tord.



Merci.


ouragand

Ha ok il joue ce rôle, je pensais qu’il faisais partie de ceux qui transportes les routes comme à la dernière panne causé par des diffusions de routes BGP à tord.



Merci.


Attention je n’ai aucune prétention à savoir la cause de l’incident de Fastly :D



Mais oui, pour résumer, le CDN est là pour fournir le contenu d’un site au plus proche du visiteur ou mettre en cache en cas d’indispo de la source.


Le site du SAMU et celui des pompiers de mon département sont accessibles :francais:



Cumbalero a dit:


Le site du SAMU et celui des pompiers de mon département sont accessibles :francais:




:bravo:


La véritable question est : est-ce que ces CDN sont vraiment indispensables à Internet ?


Dans l’absolu non, mais si on veut s’assurer que les diverses ressources d’un site soient au plus près de l’utilisateur (et ainsi diminuer la durée de chargement dudit site) ou économiser en bande-passante, utiliser un CDN est incontournable.


BlackEco

Dans l’absolu non, mais si on veut s’assurer que les diverses ressources d’un site soient au plus près de l’utilisateur (et ainsi diminuer la durée de chargement dudit site) ou économiser en bande-passante, utiliser un CDN est incontournable.


Mouais, ça concerne surtout les gros sites Web commerciaux. La plupart des sites Web n’utilisent pas de CDN et s’en sortent très bien.


En complément des réponses déjà apportées, le CDN avec son cache notamment pour les ressources statiques (images, feuilles de styles, javascripts…) permet de fortement diminuer la charge sur l’infrastructure du site. Par exemple sur un site e-commerce, le CDN en frontal capte plus ou moins la moitié du trafic et ne l’envoie pas aux serveurs du site e-commerce. Si le CDN n’était pas là, le site e-commerce devrait largement augmenter son infrastructure.



Et comme ça a été également dit, en plus cela permet de distribuer le trafic au plus proche du client grâce aux nombreux point de présence (PoP) sur toute la surface du globe.



Autant le cache peut “facilement” s’implémenter que les points de présences nécisstent un très gros investissement.


Très bon choix d’image pour illustrer l’article.



SunneX a dit:


La véritable question est : est-ce que ces CDN sont vraiment indispensables à Internet ?




Ça dépend de ton audience, tant que tu ne vise pas une cible internationale (voir même plutôt intercontinentale) dans la l’absolu ça reste très dispensable sauf problématique particulière (live stream).


Comme notre site des impôts français qui utilise le CDN d’Omicron Media, une entreprise basée dans notre bonne vieille région de la Floride, pour répondre à son audience intercontinentale :francais:


ThomChroma

Comme notre site des impôts français qui utilise le CDN d’Omicron Media, une entreprise basée dans notre bonne vieille région de la Floride, pour répondre à son audience intercontinentale :francais:


Ça me parait pas si déconnant pour les impôts d’avoir un CDN pour les parties informative.
Il ne faut pas oublié que la France ce n’est pas que la métropole et la Corse, c’est aussi la France d’outre-mer https://fr.wikipedia.org/wiki/France_d%27outre-mer .


Altair31

Ça me parait pas si déconnant pour les impôts d’avoir un CDN pour les parties informative.
Il ne faut pas oublié que la France ce n’est pas que la métropole et la Corse, c’est aussi la France d’outre-mer https://fr.wikipedia.org/wiki/France_d%27outre-mer .


Exact, soit 4% de la population. C’est peu pour justifier un CDN (c’est quand même surtout pour alléger la charge lors des pics). Quant à la connectivité j’espère que les FAI présents ont déjà travaillé le peering. Quoi qu’il en soit, je préférerais un CDN français/européen qu’un basé en Floride pour ce genre de sites… Espionnage, RGPD toussa !


ThomChroma

Exact, soit 4% de la population. C’est peu pour justifier un CDN (c’est quand même surtout pour alléger la charge lors des pics). Quant à la connectivité j’espère que les FAI présents ont déjà travaillé le peering. Quoi qu’il en soit, je préférerais un CDN français/européen qu’un basé en Floride pour ce genre de sites… Espionnage, RGPD toussa !


Pour être au plus près des Antilles, la Floride on a du mal à faire mieux.



Par ailleurs, les impôts ne concernent pas que ceux qui résident sur le territoire national.


Cumbalero

Pour être au plus près des Antilles, la Floride on a du mal à faire mieux.



Par ailleurs, les impôts ne concernent pas que ceux qui résident sur le territoire national.


Parce qu’un CDN français comme OVH ne peut pas être aussi présent en Amérique du Nord, c’est un CDN limité à un seul pays, bien sûr :roll:



Je parle de la Floride évidemment pour l’aspect administratif et la souveraineté numérique…



Et après avoir parlé des outre-mers on passe aux expatriés qui représentent une audience encore plus faible. Prochaine étape : un CDN en Floride c’est mieux pour Thomas Pesquet !


Comme je l’ai dit précédemment, un CDN sert également à réduire sa bande passante (et donc réduire la puissance de ses serveurs et ses coûts) grâce à la mise en cache de ses pages ou ressources.



On a donc des usages légitimes à un CDN au delà de servir des utilisateurs dans plusieurs pays.


BlackEco

Comme je l’ai dit précédemment, un CDN sert également à réduire sa bande passante (et donc réduire la puissance de ses serveurs et ses coûts) grâce à la mise en cache de ses pages ou ressources.



On a donc des usages légitimes à un CDN au delà de servir des utilisateurs dans plusieurs pays.


La question à se poser, est : Pourquoi le CDN n’est alors pas capable de repointer sur un autre cache d’une autre région en cas de défaillance ? Et ce même si cela augmente la latence.



Ici nous tombons dans le cas d’une mauvaise redondance encore, mais de la part du prestataire qui délivre le CDN non ?


th3squal

La question à se poser, est : Pourquoi le CDN n’est alors pas capable de repointer sur un autre cache d’une autre région en cas de défaillance ? Et ce même si cela augmente la latence.



Ici nous tombons dans le cas d’une mauvaise redondance encore, mais de la part du prestataire qui délivre le CDN non ?


Normalement tu devrais pouvoir basculer sur une autre région, mais je crains que l’incident que rencontre Fastly touche toute son infrastructure. Ce genre d’incident est rarissime mais forcément très médiatisé quand ça arrive.


BlackEco

Normalement tu devrais pouvoir basculer sur une autre région, mais je crains que l’incident que rencontre Fastly touche toute son infrastructure. Ce genre d’incident est rarissime mais forcément très médiatisé quand ça arrive.


Il va falloir que Fastly (ou autres) revoient leurs copies :mdr2:



BlackEco a dit:


Comme je l’ai dit précédemment, un CDN sert également à réduire sa bande passante (et donc réduire la puissance de ses serveurs et ses coûts) grâce à la mise en cache de ses pages ou ressources.




Réduction des coûts de BP c’est discutable, certes certains CDN sont gratuit mais en contre partit tu leur cède une partie de données et celle de tes utilisateurs.
Pour les usages type cache mutualisé, c’est une pratique obsolète du fait que moins efficace que HTTP/2 et qui en fait ne fonctionne même plus du tout sur la majorité des navigateurs du au sandboxing (un site B n’accède pas a une ressource X mis en cache par un site A, elle est retéléchargé).


Un seul être vous manque, et tout est dépeuplé. :D
On attend toujours la réaction du ministre “C’est grave et inacceptable” , il doit convoquer et gronder le responsable de Fastfly.


Apparemment c’était bien une config foireuse à en croire leur très vague communication sur le sujet.



L’indignation du jour a déjà été trouvée.


Paradoxalement, les plus gros sites Web sont devenus les moins disponibles.
Un CDN, c’est bien, mais un CDN redondé c’est mieux… et d’un seul coup les rapports bénéfice/risque & bénéfice/coût ont une autre allure.



Les circuits de secours sont toujours vus comme superfétatoires lorsqu’il s’agit de justifier leur coût, et ça couine quand finalement ils auraient bien été nécessaires.
Cas d’école d’une mauvaise gestion de risques : les œufs dans le même panier pour limiter les coûts d’une décision prise sans vue d’ensemble.



Berbe a dit:


Paradoxalement, les plus gros sites Web sont devenus les moins disponibles. Un CDN, c’est bien, mais un CDN redondé c’est mieux… et d’un seul coup les rapports bénéfice/risque & bénéfice/coût ont une autre allure.



Les circuits de secours sont toujours vus comme superfétatoires lorsqu’il s’agit de justifier leur coût, et ça couine quand finalement ils auraient bien été nécessaires. Cas d’école d’une mauvaise gestion de risques : les œufs dans le même panier pour limiter les coûts d’une décision prise sans vue d’ensemble.




Je te trouve bien catégorique. Ces sites n’ont jamais affirmé nulle part garantir un uptime. Les contrats entre grosses boîtes (puisque tu parles spécifiquement des “plus gros sites web”) et gros fournisseurs impliquent en général des SLAs et assurances complémentaires pour couvrir les pertes d’exploitation, c’est aussi une façon de gérer le risque. En l’absence d’accès à l’administratif des entreprises touchées, rien ne permet d’affirmer que ce downtime ne fait pas partie de leur modèle de risque acceptable.
J’ai l’impression que tu confonds “gérer les risques” et “assurer une disponibilité totale”. Mais ça n’a rien à voir. Tant que la durée de dowtime coûte moins cher que ce qu’il aurait fallu pour l’éviter et reste dans une fourchette anticipée, le risque est géré correctement.


À ne pas parler du même sujet, ça risque de finir en “dialogue de sourds” !
Je parle de risque d’indisponibilité, tu parles de risque financier.



Cette dernière manière de penser est tout le nœud du problème : tant qu’il n’y a pas de risque financier, briser la disponibilité n’est pas un problème… et on s’est donc retrouvés avec un grand nombre de grosse plateformes indisponibles.
Pour ceux que ça ne choque pas, c’est qu’ils participent à ce second logiciel.



Une n-ème preuve, s’il en fallait, que :




  • l’utilisateur n’est pas roi, l’argent si (souvenez-vous en quand vous entendrez des discours qui semblent sous-entendre que l’utilisateur est le cœur des priorités)

  • les grosses structures ne sont pas des modèles


Berbe

À ne pas parler du même sujet, ça risque de finir en “dialogue de sourds” !
Je parle de risque d’indisponibilité, tu parles de risque financier.



Cette dernière manière de penser est tout le nœud du problème : tant qu’il n’y a pas de risque financier, briser la disponibilité n’est pas un problème… et on s’est donc retrouvés avec un grand nombre de grosse plateformes indisponibles.
Pour ceux que ça ne choque pas, c’est qu’ils participent à ce second logiciel.



Une n-ème preuve, s’il en fallait, que :




  • l’utilisateur n’est pas roi, l’argent si (souvenez-vous en quand vous entendrez des discours qui semblent sous-entendre que l’utilisateur est le cœur des priorités)

  • les grosses structures ne sont pas des modèles


Évidemment je parle de risque financier, parce qu’on parle de plateformes commerciales.



Elles ont été indisponibles 1h, ce qui est largement dans les marges de tolérances. Améliorer la disponibilité, ce n’est pas une opération linéaire en termes de coûts, c’est une exponentielle, les derniers pouillèmes de pourcent à eux seuls sont plus chers que quasiment l’ensemble de la couverture précédente.



Je travaille dans une très grosse boîte et j’opère un grand nombre de sites e-commerce. Nous avons un contrat avec un seul CDN, et un prestataire cloud pour l’infra. Évidemment tout est backupé dans plusieurs data centers (et tous les sites ne tournent pas dans le même) et nous avons une procédure, testée, qui nous permet de tout remonter si ça plante.
Mais ce remontage se fait forcément “à froid”, on a donc un incompressible de 1 à quelques heures pour retrouver une activité dans le cas où un datacenter aurait sauté.
Le seul moyen pour battre ce gap de dispo, ce serait de pouvoir remonter “à chaud”, et donc d’avoir un full miroir toujours up, dimensionné pour encaisser le pic de transition de tout le traffic si nécessaire. Ça reviendrait à augmenter nos coûts d’infra d’un bon 50%, juste pour gagner 1h ou 2 dans le rare cas où on aurait un datacenter qui chute. (c’est arrivé une fois en 7 ans)
Pour des sites de vente en ligne.



J’ai vraiment besoin d’expliquer en quoi ce serait absurde de mettre une telle débauche de moyens (ça cuberait en millions d’euros) pour un gain de dispo aussi ridicule ? (1h de dispo gagnée sur 7 ans…)



Un bon modèle de risque est un modèle qui reste réaliste par rapport à la criticité des services considérés. Est-ce flouer mes utilisateurs de m’autoriser la possibilité d’un downtime ? Je ne pense pas.



Évidemment, si j’opérais l’infra du réseau électrique, des services hospitaliers ou des numéros d’urgence (hem…), le modèle de risque serait entièrement différent.



A mon sens la position que tu sembles défendre comme quoi tout service quel que soit sa nature devrait à ses utilisateurs une dispo 100% à tout prix n’a pas de sens, ce serait juste un gaspillage de ressources monstrueux.
Pour une plateforme commerciale non-essentielle, il est tout à fait normal d’intégrer le risque de dispo dans le cadre financier.
Pour un service essentiel, la disponibilité devrait primer, mais ici ce n’est pas le contexte.



TomGun a dit:


Parce qu’un CDN français comme OVH ne peut pas être aussi présent en Amérique du Nord, c’est un CDN limité à un seul pays, bien sûr :roll:




OVH a-t-il répondu à l’appel d’offre?




Je parle de la Floride évidemment pour l’aspect administratif et la souveraineté numérique…




Et moi je parle de géographie. Et la législation est la même pour OVH et les autres.




Et après avoir parlé des outre-mers on passe aux expatriés qui représentent une audience encore plus faible. Prochaine étape : un CDN en Floride c’est mieux pour Thomas Pesquet !




Qui a dit que je me restreignais aux expats? Qui a dit d’ailleurs que je me restreignais aux Français? Qui a dit qu’on ne se référait qu’aux particuliers ?