Black Friday: comment une expérience risquée nous a sauvés la journée
Vendredi dernier, l’état d’urgence était déclaré chez Digitec Galaxus AG. Le plus gros souci: est-ce que les serveurs tiendront le coup face à l’afflux? Enes Poyaz, Software Engineer, était en première ligne. Il parle du jour où tous les ingénieurs ont misé sur le même cheval.
17 secondes. C’est le temps qu’il a fallu pour que digitec.ch soit pour la première fois hors ligne lors du fameux Black Friday. La raison: trop de demandes d’utilisateurs. Les serveurs de notre entreprise ont capitulé après 17 secondes sous le poids des demandes. Trop de clients voulaient profiter des offres spéciales lors de la journée de soldes internationale.
«En fait, nous pensions que les serveurs tiendraient plus longtemps», dit Enes Poyraz, Junior Software Engineer.
L’ingénieur parle d’une journée où lui et son équipe ont forcé une entreprise à improductive et où les ingénieurs ont sauvé vos offres dans un acte de désespoir.
Enes est là à la seconde où les serveurs fléchissent pour la première fois. Car, chaque année, une équipe d’ingénieurs – toutes sont nommées d’après des James Bond – est toujours en stand-by pour le Black Friday. Dans les nouveaux bureaux de la Förrlibuckstrasse, à la maison en home office ou quelque part sur les ordinateurs portables avec l’Internet mobile. Ils attendent que les serveurs fléchissent.
Cependant, à minuit, ils arrivent à leurs limites. Les ingénieurs d’habitude si fiers doivent encaisser un coup dur. Les hommes et les femmes qui trouvent déjà un arrêt de quelques petites secondes trop long ont seulement réussi à rendre les serveurs opérationnels après deux bonnes heures. Mais la boutique en ligne n’était pas stable. Le site était souvent hors ligne, mais pas longtemps. Seul un flux en direct du Digital Marketing est actif.
«Certes, cela est pénible pour les clients, mais du côté des ingénieurs, c’est un comportement attendu», dit Enes. Il hausse les épaules. Bien sûr, c’est désagréable et les ingénieurs essaient de minimiser ces périodes. Mais quand une nation va à l’assaut d’un site Internet, cela peut se produire.
La seconde vague
Le calme revient. Après 2 heures, les Suisses ont chassé les bonnes affaires et dorment. Plus tard, au cours de la journée, j’ai appris qu’à la succursale de Zurich, une personne était entièrement consacrée aux abonnements. Car vendredi dernier, les clients profitaient de 50 % de rabais sur leur smartphone s’ils concluaient un contrat. Les abonnements peuvent aussi être obtenus en ligne.
Mais Enes n’en savait rien. Peu avant 3 heures de matin, il rentre chez lui et dort quelques heures d’un sommeil agité. À côté de lui, son téléphone portable en mode «son»: à tout moment, il pourrait recevoir un appel et devrait se rendre au bureau à cause des serveurs qui sont en panne. Mais l’appel ne vient pas. Enes dort. Les autres ingénieurs font pareil, tout comme Raphael Renaud, Teamleader Software Engineering qui est de service de piquet. Le téléphone de Raphael a sonné à 5 heures du matin. Un appel de Wohlen avec pour question: pourquoi y a-t-il aussi peu de commandes dans le système? Le centre logistique de Wohlen est aussi en état d’urgence pour le Black Friday et fonctionne à plein régime avec un effectif de personnel maximal.
Vers 9 heures, il est de nouveau au travail et se décrit comme ayant assez dormi. Les serveurs tiennent le coup. De justesse.
«La charge a continuellement augmenté au cours de la journée», dit Enes, «et nous avons compris que si cela continue comme ça, nous ne tiendrons pas la journée.»
C’est hors de question. Comme il y a plus d’ingénieurs dans le bureau que l’équipe de piquet de la nuit dernière, ils peuvent se répartir. Une équipe se focalise sur les systèmes internes. Tout ce qui peut être éteint est éteint. Un e-mail du Chief Information Officer Oliver Herren informe les employés digitec vers 9 h 36 pour dire que le système de pointage des heures de travail ainsi que certaines fonctions en arrière-plan de la boutique seront éteints pour économiser les ressources des serveurs. Tout ce que nous pouvons héberger localement et éteindre est éteint.
Dans les bureaux du siège principal de Zurich, les employés sont étonnés. Nous sommes une boutique en ligne. Notre site Internet est notre capital, celui qui paie nos factures et vous apporte vos nouveaux appareils. Nous sommes inquiets. Surtout, car la rédaction peut, plus ou moins, cesser ses activités. Tout le Magazine est bannis de la page principale. Les images sur lesquelles vous cliquez prennent trop de ressources.
Mais rien n’y fait: à midi, le serveur retombe une nouvelle fois en panne. Pas aussi gravement que la nuit dernière, le site s’affiche et disparaît toutes les quelques secondes, mais tout de même trop instable pour une bonne expérience d’achat sur le site.
Les ingénieurs oublient la pause de midi et donnent leur maximum pour remettre le site en ligne.
Une expérience sauve la journée
Alors qu’Oliver et une équipe d’ingénieurs composé de tous les départements de l’Engineering ont mis des services hors ligne, Enes et deux autres ingénieurs étaient occupés à faire un plan de bataille. Que faire quand mettre les services internes hors ligne ne suffit pas?
Les trois ingénieurs ont reçu la mission de trouver une solution quand toutes les autres solutions échouent.
«Plus anticonformiste est impossible», dit Enes. Il est tout de même fier d’appartenir à l’équipe qui a sauvé la journée. L’homme d’ordinaire plutôt calme parle cette fois un peu plus fort.
La solution s’appelle Redis, un système en cache que les ingénieurs observent du coin de l’œil. Enes fait partie de ceux qui ont testé des applications sur ce dernier. Un cache n’est rien d’autre qu’une mémoire de données qui sauvegarde les demandes les plus faites et les traite donc plus rapidement. Un exemple: si vous et des milliers d’autres personnes souhaitez accéder à la page Black Mobile, la banque de donnée derrière le site Web ne doit plus être consultée à chaque fois. Le cache a déjà sauvegardé une version de la page et vous l’affiche. Ainsi, les ressources peuvent être utilisées pour d’autres processus d’achat.
«Bien sûr, nous avons une solution de mise en cache qui fonctionne parfaitement en temps normal», dit Enes. Mais chaque fois qu’un serveur tombe en panne, les caches doivent être recalculées. Encore pire: chacun de nos serveurs calcule le cache localement. C’est-à-dire que chaque fois qu’un serveur est en panne, le cache doit être recalculé localement sur la machine du serveur; ce qui consomme des ressources dont les clients ont besoin. Plus personne dans l’entreprise ne pense aux lecteurs du Magazine. Les départements du marketing ont depuis longtemps jeté l’éponge, le management de produit se demande si leurs stocks suffiront, les employés des succursales sont confrontés à de longues files d’attente et les ingénieurs font face à une horde d’acheteurs et ne pensent pas à abandonner.
«Je n’ai jamais vraiment testé Redis», dit-il, «mais j’ai passé deux jours à faire quelques tests». Ça ne sera jamais assez pour confier la plus grande boutique en ligne de Suisse au système. Quand Enes regarde ses notes prises il y a deux semaines, il sourit.
Il a certainement quelques domaines d’applications chez nous
Les ingénieurs décident de mettre en ligne Redis sans l’avoir testé sur un système de démo. Une action risquée. Avant qu’une entreprise intègre un logiciel dans un système en direct, il est testé de fond en comble par différents postes internes et souvent aussi externes. En effet, ce n’est pas parce qu’un logiciel est décrit comme exactement ce dont votre système a besoin par le marketing du fabricant que le logiciel apporte la valeur ajoutée promise. Parfois, tout empire avec son utilisation.
On demande à Enes: «Tu penses que ça va le faire?»
L’ingénieur acquiesce.
Redis prend en charge
À partir de ce point, tout se passe très vite. Comme, d’après les informations d’Enes, Redis est «super rapide et facile à utiliser», le serveur est prêt en 20 minutes. Là où l’ancien système en cache digitec fonctionnait localement sur chaque serveur, Redis fonctionne de manière centrale sur un serveur et calcule aussi les demandes sur les autres serveurs. En d’autres termes, chaque serveur écrit dans le cache Redis, ce qui rend la solution plus évolutive et réduit la charge des serveurs de lecture.
«Mais pour ne pas se lancer dans une mission totalement périlleuse #yolo, nous avons encore installé un SwitchBit», précise Enes. De plus, une petite équipe de l’IT Operations a dû se porter volontaire pour toujours surveiller les serveurs pour que la boutique ne soit pas complètement HS. IT Ops a déjà passé toute la journée à surveiller la performance des serveurs. D’après Enes, ce sont eux qui ont couvert son équipe pour faire l’expérience avec Redis.
Le problème arrive avec le go-live que se passe de la manière la plus désordonnée possible. Enes veut lancer Redis sur un Managed Server de Microsoft pour que les charges de deviennent pas trop grandes en interne.
«Malheureusement, Redis fonctionne sur le port 6380, fermé chez nous», dit-il. En urgence, il demande l’ouverture du port, qui n’est malheureusement par possible: il est justement bloqué par le serveur Microsoft. Mais Enes a appris une chose: il a toujours un second plan prêt à l’emploi.
«En parallèle, j’ai essayé de faire marcher Redis sur le cloud Google», ajoute-t-il. Mais ça aussi s’avère plus difficile que prévu. Avec l’aide de Michal Nebes, Senior Software Engineer, il arrive à créer un cluster Redis.
Vers 16 heures, c’est du sérieux. Un petit review de code. D’après Boško Stupar, Senior Software Engineer, le code fonctionne et il mesure de round trop des données, c’est-à-dire le temps dont les données ont besoin pour être envoyées au serveur et pour revenir à l’ordinateur de l’utilisateur.
- Normal: de 50 à 500 millisecondes. Trop lent
- Redis, système de test local: de 8 à 9 millisecondes
- Redis, productif: de 16 à 19 millisecondes
Redis est mis en ligne. Les ventes du soir sont placées entre les mains d’un système non testé avec une sécurité minimale.
Quelques secondes de panique.
Redis lis les demandes et constitue un cache.
La charge pesant sur les serveurs diminue sensiblement. La boutique en ligne se stabilise.
Les ingénieurs respirent.
Plus tard, sur Facebook, Boško Stupar écrit:
Black Friday survit. C’était une journée incroyable dans ma carrière! Tellement stressante, tellement dure et tellement gratifiante. Pour les nerds: nous avons mis en place un caching two stage avec farm Redis centralisée. Opération à cœur ouvert sans anesthésie. PS Je déteste Black Friday.
Après le coucher de soleil, les ingénieurs se retrouvent autour d’une bière au cinquième étage à la Pfingstweidstrasse, avec toujours un œil sur la boutique en ligne. Une fête de folie ne ressemble pas vraiment à ça, mais ils de détendent.
Vers 18h55, Enes lève le statut d’urgence via WhatsApp:
Les serveurs fonctionnent normalement, sous une charge normale. Pendant ce temps, les gens attendent dans la succursale, souscrivent des abonnements pour smartphone et viennent récupérer des commandes. Adrian Maier, Store Manager, se trouve à l’entrée de la succursale de Zurich et informe sur le temps d’attente. Vingt minutes, quarante minutes. Il est fatigué, tout comme l’équipe derrière les caisses.
Les ingénieurs ont à moitié fini leur journée, mais les employés des succursales sont les derniers devant tenir le coup. Aux caisses, la journée se termine à 20 heures. Plus d’abonnements, plus de livraisons, plus de questions.
Quo vadis, Redis?
Le système Redis reste en ligne durant le week-end jusqu’à lundi soir pour pouvoir participer au Cyber Monday. Les ingénieurs sont fiers, la boutique en ligne sera stable lundi. Mais, dans un premier temps, Redis a fait son travail et le cluster sera à nouveau retiré du réseau.
«Une fois que tout est dit et fait, on parle tout de même d’un système encore peu testé», ajoute Enes.
Les ingénieurs ont une longue liste de questions qu’ils doivent traiter avant de pouvoir ajouter définitivement Redis au réseau avec bonne conscience. Parmi ces dernières, de nombreuses questions qui ressemblent à ça: «pourquoi est-ce que Redis fait $ding?»
Maintenant que la situation s’est à nouveau calmée, les ingénieurs peuvent se consacrer à ces questions. Car Black Friday leur a au moins montré une chose: Redis a du potentiel. Ne pas l’utiliser serait dommage.
Journaliste. Auteur. Hackers. Je suis un conteur d'histoires à la recherche de limites, de secrets et de tabous. Je documente le monde noir sur blanc. Non pas parce que je peux, mais parce que je ne peux pas m'en empêcher.