Le serveur est mort.. Vive le serveur!

Pour résumer, un service qui a des serveurs un peu partout dans le monde, bien connectés, et qui sert d’intermédiaire entre les visiteurs du site et les serveurs, en gardant en mémoire les fichiers souvent demandés pour qu’ils chargent plus vite (vu qu’ils vont charger directement depuis la mémoire du noeud CDN le plus proche de chez toi). Et de nos jours ils font bien plus de choses, comme du routage intelligent, du redimensionnement / optimisation d’images et vidéos, protection contre les attaques…

En gros, ils ont plein de racks comme ça (plein de SSDs, de RAM et de réseau 100 Gbps) :
image

Un peu partout dans le monde :

Parmi les plus gros : Akamai (le gros historique), Cloudflare, Fastly

Vu que tout le trafic du site passe par là généralement, ça fait un gros point central qui peut tout casser. Normalement si il y a des problèmes c’est localisé dans le pays / datacenter impacté, mais là Fastly ce matin a eu un bug qui a fait planter tous les serveurs, partout, quasi tous en même temps. Woops.

4 « J'aime »

Sur ce coup là, on a chatté : on utilise Cloudflare.

Je suis tout de même très surpris de voir Amazon utiliser Fastly…

1 « J'aime »

Amazon ont pas tant de centres serveurs que ca, Akamai et Fastly eux en ont vraiment partout (par exemple on a un cache de ces deux là à la reunion, enfin Akamai sur qu’il l’ont installé Fastly était en discussion il y a quelques années), donc assez logique que Amazon s’appuient sur ce type d’infras…

AWS a pas mal de pops « edge » ou Cloudfront (leur CDN) et lambda at Edge sont déployés, sans être des régions AWS : Fonctionnalités clés d'un réseau de diffusion de contenu | Performance, Sécurité | Amazon CloudFront

Après Cloudfront c’est pas terrible terrible comme CDN quand tu as des besoins un peu complexe / une typologie de trafic hors norme, je peux totalement comprendre que Amazon utilise un « vrai cdn » pour leurs images ecommerce :slightly_smiling_face:

1 « J'aime »

Une architecture quelque peu contre-nature quand on repense à la conception d’origine du web…

image

30 « J'aime »

Je me suis fait la mm réflexion !

1 « J'aime »

J’en ai conclu (sans tricher) que CDN est l’acronyme de Content Diffusion Network.

J’ai bon ?

Et pour le néophyte que je suis : du peu que je lis ici les installations me semblent bien peu robuste en terme de redondance pour éviter ce genre de « blocages ».

Quelqu’un pourrait-il m’expliquer en quoi ce que je viens d’écrire est une belle connerie d’ignare parce que quand même, les experts ne sont pas des cons et ont les moyens de leurs ambitions sécuritaires !

1 « J'aime »

Ce genre de système a toujours de la redondance, que ce soit en termes de matériels doublés, rocade de fibre etc etc… Au niveau logiciel c’est bien plus compliqué, tu as un soft qui fait le job (qui peut fonctionner en cluster) mais ça reste un seul et unique soft(par exemple sur ton pc tu peux pas faire tourner 2 OS simultanément pour te prémunir de la défaillance d’un des deux).

Le problème est ici logiciel, un bug est survenu et ce bug a été propagé à l’intégralité du matos. Donc tu as beau être redondé ben tout est touché :confused:

2 « J'aime »

Ok, merci.

Et qu’y a-t-il alors comme moyens de se préserver d’une telle propagation d’un bug ? (je suis de nature curieuse)

Il n’y a malheureusement pas vraiment de moyen. Tu as grosso modo 2 types de bugs :

  • Ceux qui arrivent directement suite à une montée de version software par exemple. C’est instantané, tu as la panne en direct au moment de l’upgrade.
  • Ceux qui arrivent en décalés et qui peuvent être provoqués suite à un upgrade ( par exemple bug de remplissage du buffer mémoire qui provoque un crash, ça n’arrive pas directement mais un temps après), ou alors la correction de code, etc etc…

Dans le premier cas, tu peux toujours faire un test de montée de version dans un environnement bac à sable pour voir comment ça se comporte et valider le bon fonctionnement.

Dans le second cas, la meilleure chose pour se prémunir c’est une supervision très renforcée de tout ce qui est déroulement de process, consommation anormale de ressources avec seuil d’alertes et actions correctrices automatisées (ou pas).

Dans le deuxième cas, la supervision n’empêchera pas l’incident. Cela permet de conditionner le degré de réactivité permettant de l’isoler avant de rendre tout le truc inopérant et surtout de trouver d’où vient le problème.

4 « J'aime »

Merci ! Je te paierai avec l’argent que @Jemparing me doit. :grin:

1 « J'aime »

Quooowhaaaat ?!? :joy::joy:

1 « J'aime »

presque : content delivery network, mais en français, ça donne bien un réseau de diffusion de contenu.
De ce que j’en ai retenu, n’étant pas dans le réseau, c’est que tu deportais certains types de contenus (à l’origine surtout des images avec akamai) sur des serveurs dédiés et répliqués à divers endroits dans le monde, ce qui permettait à l’utilisateur d’y avoir accès plus rapidement, sans avoir à suivre une multitude de nœuds dans les méandres d’internet

1 « J'aime »

Et tu oublies les délais liés aux vitesses ridicules de la lumière….

Malheureusement il faudra faire avec :slightly_smiling_face:

A la base, comme dans beaucoup de domaines, il y a du bon sens.

Malheureusement ce ce qui est le plus souvent mis de côté a l’heure actuelle…
Cf. les échanges sur le CDO dans le fil sur Clash of Cultures…

Généralement tu fais ce qu’on appelle des « rolling updates » : tu déploies le nouveau logiciel sur 1 serveur, puis 10, puis 50, puis 100, puis partout. Avec N minutes/heures entre chaque pour vérifier qu’il n’y a pas d’effets indésirables.

Là Fastly a déployé une nouvelle version il y a 2 semaines, sans rien voir de spécial. Mais un client a créé une configuration spécifique hier, qui a révélé un bug jusque là inconnu (malgré tous les tests manuels et automatiques) et a tout fait planter.
Fastly se fait fort de déployer la nouvelle configuration en moins de quelques secondes partout, ce qui en tant que client est bien pratique (Akamai par exemple c’était en 6 heures à l’époque…). Mais il y a ce risque que ça trigger un bug :frowning: Sachant que les configurations sont compilées et testées avant le déploiement, mais probablement pas le truc précis qui faisait planter sur le coup.

Ils ont fait un post avec le timing pour les curieux : Summary of June 8 outage

(et ya plus de détails pour les clients mais c’est sous NDA)

5 « J'aime »

C’est le bordel chez OVH encore.

Selon le patron c’est une erreur humaine…
Selon un contact que j’ai chez eux, c’est un hack avant leur entrée en bourse…

Affaire à suivre !

1 « J'aime »

Tant que ce n’est pas un barbeuk qui part en c…