Nous sommes le lundi 12 juillet, il est 20h05 et comme pas mal de Français, je regarde à la télévision l’allocution du Président sur les nouvelles mesures pour la vaccination. Côté Doctolib la journée a été calme, et nous n’avons pas eu d’informations particulières. Ces dernières semaines nous avons pu souffler un peu, après avoir absorbé la vague de vaccination. Mais ce soir, dans 8 minutes, ce sera plutôt un Tsunami.
En temps normal, lorsque Stanislas Niox-Chateau, notre CEO passe à la télé, les équipes techniques sont informées. Il y a toujours une petite équipe d’astreinte pour réagir en cas d’anomalie sur le site Doctolib.
J’avais pris cette capture d’écran de notre tableau NewRelic le 28 avril 2021. Stan est passé au journal de vingt heures. Et comme vous le voyez, cela se transforme souvent en un afflux de trafic sur le site de Doctolib.
Lorsque nous sommes au courant, il suffit alors simplement de démarrer plus de serveurs, et c’est tout. Nous retournons à nos occupations devant le 20h, bonne soirée.
Pour les personnes qui ne sont pas très techniques, il faut comprendre que l’architecture de Doctolib est élastique. Elle est capable de réagir automatiquement à des pics de charge. Pour cela, le système démarre ou arrête automatiquement des cohortes de serveurs. Nous savons par exemple que la nuit et les week-ends sont moins chargés. Durant ces périodes, le site fonctionne avec moins de serveurs. Le Lundi matin est traditionnellement le moment le plus chargé. Le site fonctionne alors avec 4 fois plus de serveurs pendant quelques heures.
Il faut compter quelques minutes pour passer de 200 à 2500 serveurs par exemple, de quoi absorber sans soucis plusieurs millions de visiteurs. Mais c’est parfois trop lent à réagir, et c’est pour cette raison que nous essayons d’anticiper les pics de trafic.
Ce soir du 12 juillet c’est plutôt calme et sincèrement, nous n’attendions rien de particulier. A 20h13 je reçois un SMS d’alerte, comme toutes les personnes qui se sont inscrites pour participer à la gestion des crises. L’une de mes missions est de participer à la cellule de crise et d’aider autant que possible les équipes. Dès que quelque chose d’anormal se produit, vous recevez un SMS. Quelques collègues sont en congés et je décide de prendre l’ordinateur afin d’aller rejoindre une salle de crise virtuelle où nous passons en vidéo-conférence, sur Google Meet. Nous sommes 4 ou 5, chacun arrive sans stress.
Simone Veronese et Florian Philippon sont 2 des ingénieurs responsables du bon fonctionnement du site Doctolib. En arrivant je suis dans les premiers et je vais faire le Scribe durant les 2h40 de la crise.
L’organisation est simple : le Responsable Incident est chargé de coordonner les équipes, de prendre les décisions. Le Responsable de la communication de son côté sera chargé d’informer les équipes de Doctolib qui ne sont pas techniques. C’est cette personne qui rendra compte des chiffres, de la situation et de la gravité de ce qui se passe. Les personnes présentes peuvent participer, auquel cas il faut réagir vite et dans le calme. Mais vous pouvez aussi être spectateur, pour apprendre et observer. Ce soir-là, je me retrouve à faire le Scribe. Ma mission est d’écrire sur un document partagé toutes les discussions et les décisions. Je suis là pour écouter et pour marquer les prises de décisions, ce qui sera utile ensuite pour rédiger un Post-Mortem interne.
Nous voilà parti pour 2h40 que je vous propose de suivre…
Les premières lignes du journal de cette crise #1192 démarrent à 20h17. Florian déclare qu’il va forcer à monter rapidement le nombre de serveurs, sans attendre que l’auto-scaler s’en charge. Nous utilisons des outils d’observation comme NewRelic et Datadog pour nous rendre compte de la situation. Et pour comprendre, nous voyons que le trafic est en très forte augmentation sur la partie Vaccination du site de Doctolib. Nous passons d’environ 500 000 visiteurs à 2.1 millions en 15 minutes.
Sur le même type de graphique que celui présenté en début d’article, nous sommes à un volume 3 fois plus important que lors du passage au journal télévisé de notre PDG.
La majorité des visites se font à partir de téléphone mobile. On imagine chaque personne devant sa télévision, à la recherche d’un créneau de vaccination. Sans réaction de notre part, le volume de visiteur risque de saturer le site.
La courbe bleu ci-dessus montre le nombre de transactions ce soir là. Nous sommes montés à 10 millions de transaction par minute plusieurs fois.
La ligne en pointillés vert affiche le lundi 5 juillet, 7 jours avant, ce qui permet de voir que « quelque chose » se passe. Le système est capable de détecter les anomalies et c’est lui qui a envoyé des alertes vers 20h à l’équipe SRE. Florian a ensuite déclenché une crise, ce qui lui permet de mobiliser immédiatement une équipe pour l’aider. D’où le SMS que je reçois à 20h13.
Sur ce deuxième graphique, un lundi normal c’est 1.89 millions de transactions par minute. Le lundi 12 juillet, nous avons observé des pics à 10.3 millions de transactions, ce qui est 5 fois plus que la semaine précédente à la même heure.
Ce soir-là, l’équipe SRE avec Simone et Florian va appliquer d’abord les procédures que nous avons déjà utilisées, en particulier pour les centres de vaccination en Allemagne. Ce n’est pas la première fois que nous avons des pics de trafic.
En premier lieu donc, ils démarrent automatiquement des dizaines de serveurs. Notre application monolithique (Ruby on Rails) est très robuste et elle scale en quelques minutes. Cela permet d’accueillir le trafic et de conserver un site rapide à répondre.
Après quelques minutes, nous constatons que les mesures fonctionnent mais que cela ne sera pas suffisant si les visiteurs continuent à arriver sur le site. Imaginez un supermarché : vous venez d’ouvrir les portes et les clients se ruent. Vous vous assurez que chacun trouve les articles dans le magasin. Maintenant les personnes passent aux caisses et il y a à nouveau de la contention. C’est exactement le souci que nous allons avoir dans quelques minutes, sur les bases de données en écriture. A cet instant, nous n’avions pas pensé à activer un système de cache sur les Rendez-vous. Cela aurait soulagé les bases en lecture, mais dans le feu de l’action, nous étions sur d’autres sujets à traiter. Cela n’aura pas beaucoup d’impact plus tard, à part la facture d’hébergement de la soirée…
Après avoir augmenté le nombre de serveurs, nous observons que la base de données demande de plus en plus de ressources. Chez Doctolib, c’est une base relationnelle, c’est du postgreSQL. Sauf que Doctolib n’est pas un client « classique ». Nous utilisons un système de bases de données répliquées dans le cloud. Notre fournisseur AWS propose la technologie Aurora, qui permet de copier des milliers de fois les données, et de partager ainsi les cohortes de visiteurs sur un cluster de serveurs. Nous passons de 6 instances à 14 instances Aurora de type db.r5.24xlarge. Chaque instance représente 48 cores, 96 vCPU et dispose de 768Gb de mémoire vive. Pour gérer correctement le trafic en écriture de prises de rendez-vous, nous utilisons un writer Aurora et nous répliquons sur 14 readers Aurora. Au passage : toutes les données sont chiffrées de bout en bout au repos et en transit. Il y a un double chiffrement, qui assure que seul le patient et le praticien peuvent partager leurs informations. C’est une obligation pour l’hébergement des données de santé.
Nous aurions pu utiliser un petit peu moins de machines, en activant un cache sur les disponibilités des rendez-vous. Par exemple 30 secondes par centre. Mais je vous l’ai dit : on a oublié car la procédure n’était pas correctement documentée ce soir-là.
Du coup, chaque utilisateur du site bénéficie du top de la réservation des créneaux de vaccination car nous servons de la disponibilité en temps réel…
David Gageot notre responsable architecture se chargera un peu plus tard de configurer un cache, en relisant le journal de la crise justement.
Le site sert donc de la dispo de créneaux de vaccination en temps réel. Pour bien comprendre ce point : Doctolib est un système qui vous permet de choisir votre créneau horaire pour la vaccination. C’est un énorme avantage pour vous. Mais c’est très compliqué à architecturer correctement. Nous aurions pu écrire un système qui vous dit « bon, rendez-vous lundi à partir de 8h30, vous faites la queue et vous passez quand il y a de la place« . Mais ce n’est pas notre produit et le service offert aux personnes entraîne une petite complexité d’architecture. Ce choix des 2 créneaux nécessite la pré-réservation d’un créneau quelques instants, le temps de trouver le 2ème créneau de vaccination.
Il est 20h20. Trop de personnes sont sur le site, il faut fortement réduire le nombre de nouveaux arrivants. L’équipe décide d’activer la salle d’attente sur notre CDN, avant même d’arriver sur le site de Doctolib. Ce système d’attente est utilisé par exemple pour la vente de billets pour les jeux Olympiques ou le mondial de foot. Nous l’avons installé pour l’Allemagne quelques semaines avant, afin de gérer les pics d’affluence sur les centres de vaccination. Ce soir il sera utilisé pour réguler le nombre de visiteurs sur le site.
Nous n’avons aucune idée du bon réglage, car ce qui se passe est unique. Un premier seuil est placé à 20h22 à 800 000 utilisateurs concurrents sur le site. Cela ne donnera un effet que 6 minutes plus tard. Nous comprenons que les gens actuellement sur le site passent plus de temps qu’un visiteur lambda pour de la vaccination. Côté base de données, les volumes d’écriture s’envolent. Nous comprenons que les visiteurs sont en train d’inscrire des membres de leur famille, qui ne sont pas sur la plateforme. Nous apprendrons le lendemain que la grande majorité des rendez-vous de cette soirée étaient pour des personnes de moins de 30 ans. Ceci explique cela.
Chérie, est-ce que Camille est inscrite sur ta carte vitale ou sur la mienne ?
un utilisateur anonyme sur Doctolib le 12 juillet 2021
Pendant ce temps là, nous voyons que la situation ne se calme pas. Vers 20h26 le nombre de rendez-vous confirmés dépasse le plafond du 26 juin dernier, qui était notre dernière référence. Les équipes décident de réduire encore le nombre de visiteurs à l’entrée à 400 000. C’est peu, mais il faut que les utilisateurs sur le site puissent terminer leur recherche sans lenteur. La salle d’attente monte à quelques centaines de milliers de sessions, c’est énorme. Le site fonctionne parfaitement, aucune lenteur, c’est ce que les équipes cherchent à faire afin que les visiteurs ne restent pas trop longtemps.
En relisant les notes, je vois que Simone nous dit : on est en train de passer de 8 000 à 26 000 transactions par seconde car les personnes terminent leurs réservations. On monte encore d’autres systèmes de répartition de la charge en amont des bases de données.
Philippe Vimard notre CTO passe la tête dans la salle de crise afin de voir comment les équipes travaillent. Il relève alors 18 000 réservations par minute à 20h35, nous sommes à 75% de la charge des bases en écriture, donc il reste de la marge. Il donne carte blanche et recommande de laisser le maximum de serveurs en fonctionnement, en anticipation de la soirée.
A 20h36 nous pensons que le plus gros est fait, et nous suggérons de passer en medium crisis. Cela permet de libérer du monde, et nous sommes alors confiants que la situation va se tasser, le système marche bien et les courbes se stabilisent.
Vers 20h53 nous avons un système qui sature et qui ne retourne plus les erreurs, ce qui est inquiétant. Après enquête le lendemain, il s’avère que notre partenaire pensait avoir subi une attaque, et il a mitigé le trafic quelques instants. Rien ne se passe comme prévu et le trafic reste très soutenu pendant une longue demie heure. Nous restons en high crisis, c’est assez unique chez Doctolib.
Le trafic ensuite semble se calmer brusquement quelques minutes. Comme le calme après la tempête. L’une des personnes nous signale que c’est la fin du discours du Président et que la publicité a démarré. Et nous on sait qu’après la pub, les gens vont revenir. On vous connaît !
C’est l’œil du cyclone et nous sommes en plein dedans !
Et en effet : dès la fin de la coupure pub nous voyons un pic de trafic, accompagné de réservations quelques minutes plus tard. Simoné marque un pic à 30 000 requêtes par seconde à 21h07. Il y a encore beaucoup (beaucoup) de monde.
Vers 21h25 c’est Eric, de l’équipe sécurité qui passe nous voir. Il nous informe que le site a eu une petite attaque d’une IP Française, délibérée, dans le but de faire tomber le site. Dans ce type de situation, l’équipe sécurité mitige l’attaque et aucun incident ne viendra perturber le reste de la soirée. Sachez simplement que c’est relativement fréquent, parfois volontaire, parfois non.
Durant les 2 heures qui suivent, l’équipe reste présente et mobilisée pour ajuster la salle d’attente, surveiller l’activité et ajuster les nombreux réglages dont nous disposons. Sauf que le trafic ne faiblira pas avant 23h30. Nous anticipons un mardi « sportif » et l’équipe SRE laisse tourner beaucoup de serveurs et les bases de données répliquées. Cela représente un coût financier vraiment important, mais c’est en prévision de la journée de mardi, qui sera l’une des journées les plus actives sur le site Doctolib.
21h50 c’est Nicolas de Nayer, notre VP of Engineering, qui a vu les actualités, et qui vient proposer son aide. Les équipes techniques ont fait leur travail et la soirée s’est plutôt bien passée. Nous voyons que la nuit va être délicate pour les plateformes d’envoi des SMS. Cela prendra plusieurs heures pour envoyer les millions de SMS. Nicolas, Léo et David vont prendre le relai ensuite jusqu’à 1h du matin, afin d’ajuster et d’anticiper le mardi. Nous ne voulons pas de salles d’attente sur le site classique de Doctolib, uniquement sur la vaccination. Tout sera préparé ce soir là, afin que le mardi se passe bien. Et il s’est bien passé pour l’ensemble des utilisateurs de Doctolib le mardi suivant. Les chiffres déjà publiés par Doctolib : 926 000 rendez-vous le lundi soir en 2h30 et ensuite 1.4 millions sur la journée du mardi. C’est énorme.
Finalement, nous étions 14 personnes et tout a été piloté par Florian et Simone, 2 de nos ingénieurs SRE. L’ambiance était un peu tendue car nous sentions qu’il se passait quelque chose. Il n’y a aucun grand chef pour décider à ta place. Tu cliques sur deploy, et tu attends. Nos chefs étaient présents. Ils sont passés pour aider et pour s’assurer que tout allait bien.
C’est les équipes qui gèrent et qui ont toute l’autonomie pour assurer le service. Il y a plus de 300 personnes côté « Tech & Product » chez Doctolib, sur les 1900 employés de la société. Ce soir-là, c’était vraiment passionnant à vivre. Je vous souhaite de participer et d’être l’un des acteurs de ce type d’événement. C’est possible, il suffit de nous contacter pour rejoindre les équipes. J’ai rejoint Doctolib en mars 2021. Et me voilà à suivre et à observer le travail des équipes, à être l’un des petits acteurs de cette soirée. C’est ça qui fait que notre travail est unique, passionnant et que nous en sommes aussi tous très fiers.
Rejoignez Doctolib, on recrute
Consultez la liste de l’ensemble des postes ouverts chez Doctolib
Doctolib Tech a des bureaux à Levallois, à Nantes, à Niort, à Berlin et à Milan. La société est aussi ouvert au 100% remote, selon les postes.
Translation to English
This article has been translated and published on the Doctolib Tech Blog
26 likes
Merci, c’était très intéressant !
Mais dans les 48h précédents l’annonce il y avait des rumeurs dans les médias et réseaux sociaux d’instauration d’un pass sanitaire, vous n’étiez pas un minimum aux aguets par rapport à l’annonce de ce soir ?
Et vous n’avez jamais de communication préalable du gouvernement, ne serait-ce que quelques heures avant ? Ca permettrait d’anticiper d’autant mieux ces montées en charge.
J’en profite pour poser une autre question, concernant le système de cache : lors de l’ouverture de la vaccination à tous sous condition de créneaux dans les 24h (à partir du 12 mai, de mémoire), il m’a fallut une semaine pour enfin avoir un rdv, malgré mes recherches plusieurs fois par jour, et ce même en utilisant un bot de reservation doctolib (https://addons.mozilla.org/fr/firefox/addon/vaccin-click/) qui n’a jamais réussi à reserver jusqu’au bout non plus. Tout ça à cause du système de cache du site, qui créait un décalage fatal entre les dispos affichés et les dispos réelles.
Avec le recul, aurait-il était capable de faire mieux dans cette situation ?
Sacré boulot d’équipe, bravo a l’organisation de la boîte, sur le pont au bon moment, et tout a été géré sans crises mode « Cata ». Chapeau bas messieurs.
Le manque de communication préalable du gov.fr est une(mauvaise) habitude prise il y a déjà quelques années… Pas de politique ici, juste une commentaire d’ordre organisaationnel.
Réponses à Robin Lionel : non, nous n’avons aucunes communications avant, ce qui justement ce soir là a rendu la soirée « exceptionnelle ». Concernant le cache, c’est un système nécessaire pour soulager la pression et qui a fonctionné avec des millions de rendez-vous. Comme je le dis dans l’article, le site Doctolib a enregistré 1.4 millions de RDV uniquement sur la journée du mardi 13 juillet 2021. Depuis le début de la campagne, 61 millions de rendez-vous ont été pris sur Doctolib.fr (source : @Doctolib Twitter https://twitter.com/doctolib/status/1426166245628551168)
Et le RGPD, tout le monde s’en fout joyeusement avec tous les sous-traitants techniques qu’il y a
@Tubbydev +1
Merci pour ce retour très intéressant !
Par contre je n’ai pas bien compris comment vous arriviez à 1344 db en écriture. A part que ca semble lie au nombre d’instances et cpu (14×96 cpu). Ça veut dire 1 db par cpu ?? Je ne connais pas la techno Aurora mais à priori leur doc parle de replicas ( en lecture donc ) . Y a t-il du multi-master, du sharding automatique ou que vous gérez applicativement ?
2500 serveurs pour 30K RPS ? Donc 12 RPS par serveur ? C\’est quoi comme type d\’instance AWS ? Si les chiffres sont bons, vous avez vrai problème de perf, et ça doit vous coûter extrêmement cher dans ce genre de moment. On dirait que vos instances RoR sont complètement synchrones sur l\’I/O ; si tel est le cas, passer asynchrone vous permettrait de diviser vos coûts par quelque chose comme 100. À dispo si je peux vous filer un coup de main.
Et vous avez pensé à passer le site en php7 pour gérer le flux en écriture?
Super boulot les gars, bravo. Ça doit faire du bien de savoir toutes ses connaissances vraiment utiles, pour toute la société.
Je vous claque la bise.
Merci beaucoup pour ce retour d’expériences ! Je serais curieux de savoir votre méthodologie / organisation lors de tests de montées en charges (fréquence, volumétrie, architecture dédiée, outillage, équipe dédiée) qui vous a sans doute permis d’avoir une telle résilience.