Google a écrit à propos de leurs défis dans la mise à l’échelle de Google Meet en raison de l’utilisation accrue depuis la pandémie COVID-19 a conduit plus de personnes à l’utiliser. L’équipe SRE de Google a utilisé son cadre de gestion des incidents existant avec des modifications pour relever le défi de l’augmentation du trafic qui a commencé plus tôt cette année.

L’équipe SRE a reçu des signaux d’alerte précoce en capacité régionale pour Google Meet vers le 17 février, mais il n’y a pas encore eu de panne ni d’impact sur les utilisateurs. Le but était d’éviter les pannes et évoluer en fonction des demandes de croissance encore inconnues. La stratégie de réponse de l’équipe consistait à utiliser leur cadre de gestion des incidents, même si cela ne correspondait pas aux paramètres d’un incident «traditionnel». Ils ont mis en place rôles spécifiques comme un commandant d’incident, un chef des communications et un chef des opérations en Amérique du Nord et en Europe. L’équipe a mis en place des «workstreams» pour rationaliser le travail. Chaque flux de travail traitait d’un aspect spécifique – Capacité, dépendances (par exemple, services d’authentification dont dépend Meet), goulots d’étranglement, boutons de commande et déploiements de production avec de nouveaux paramètres de réglage. Ils ont ajouté une «veille» à chaque personne en réponse à un incident pour éviter la surcharge et l’épuisement professionnel.

Samantha Schaevitz, Ingénieur responsable de la fiabilité des sites chez Google, était l’un des commandants des incidents. Elle écrit que son rôle consistait à «collecter des informations sur l’état des problèmes tactiques persistants, qui travaillait sur quoi et sur les contextes qui affectaient notre réponse (par exemple, les réponses COVID-19 des gouvernements), puis à envoyer du travail à des personnes capables de Aidez-moi ». L’objectif technique de l’équipe était de «maintenir la capacité de service Meet disponible au niveau régional avant la demande des utilisateurs».

L’équipe a pu doubler la capacité de service de Meet, et les décisions de capacité de provisionnement ont dû passer de l’utilisation des tendances historiques à un nouveau modèle de prévision de l’utilisation. La deuxième phase s’est concentrée sur le travail vers une croissance 50x. Un accent constant sur l’automatisation des processus, y compris les nouveaux, a aidé l’équipe à réduire les opérations manuelles et à déployer les changements plus rapidement. Chaque déploiement est passé via un déploiement Canary.

Une observation intéressante au cours de cet exercice était que l’affectation de plus de ressources (CPU et RAM) aux processus était plus efficace que les mêmes ressources réparties entre les processus. Cela était dû au fait que la surcharge inévitable de chaque processus (surveillance, contrôles de santé, initialisation) pouvait être minimisée avec un nombre moindre de processus. Au moment où l’équipe a clôturé cet «incident», Meet comptait près de 100 millions de participants quotidiens.

D’autres plates-formes de conférence ont connu une croissance similaire au cours de la même période. Le Webex de Cisco, par exemple, a vu 3 fois son volume normal globalement, avec des augmentations plus élevées dans des régions spécifiques. Il comptait « plus de 500 millions de participants à la réunion et a enregistré plus de 25 milliards de minutes de réunion en avril ». Ils se sont davantage concentrés sur les fonctionnalités d’analyse et de sécurité dans le cadre de la gestion de la charge accrue. De même, Zoom a vu un Augmentation de 50% en réunion quotidienne des participants en avril. Zoom a 17 centres de données à l’échelle mondiale, et utilise également AWS, Oracle Cloud et Azure. Ils ajoutée «5000 – 6000 serveurs» sur AWS chaque nuit pour gérer la demande croissante.

Microsoft Teams – qui avait 200 millions de participants aux réunions quotidiennes en avril – fonctionne entièrement sur Azure. À l’instar de ce qui s’est passé chez Google, l’équipe de Microsoft Teams s’est rendu compte « que nos modèles de prévision précédents devenaient rapidement obsolètes » avec l’augmentation du trafic. Selon leur article de blog, ils ont utilisé des techniques de modélisation prédictive et ont accéléré les décisions en matière de ressources sans aller trop loin. Parmi les autres mesures prises, citons le déploiement de services critiques dans plus de régions, l’optimisation du code, un meilleur routage du trafic réseau et une compression des données plus agressive. Ils ont également apporté quelques modifications à leurs processus internes de gestion des incidents afin d’éviter l’épuisement professionnel.