Pendant des années, Microsoft Graph a répondu à des milliards de requêtes par jour en tant que l’une des principales API REST des services Microsoft. Le service est devenu une infrastructure clé pour les applications de Microsoft, les solutions métier et les solutions commerciales tierces.
Tout élément d’infrastructure critique s’accompagne de responsabilités rigoureuses : maintenance, support et sécurisation. Et parfois, cette infrastructure doit être « mise à niveau » vers les normes les plus récentes, ce qui améliore la valeur fournie à ses utilisateurs grâce à une meilleure sécurité, une meilleure interopérabilité et de meilleures performances.
Sur le plan de la sécurité, l’équipe de service a déployé la prise en charge de TLS1.2/1.3, ainsi que désactivé la prise en charge de TLS1.0/1.1. Sur le front de l’interopérabilité, IPv6 a été activé pour Microsoft Graph il y a quelques mois. Les deux mises à niveau ont également permis de réduire la latence.
De même, HTTP/2 (h2) permet de réduire la latence, l’utilisation de la bande passante (protocole binaire, compression des en-têtes…) et permet un meilleur parallélisme des requêtes multiples par rapport à HTTP/1.1.
Cet article raconte l’histoire du déploiement h2 pour Microsoft Graph, une histoire de planification et de collaboration minutieuses.
Début
À l’époque où j’étais MVP Microsoft, je plaidais déjà auprès de l’équipe produit, alors plus petite, pour obtenir un support h2. En fait, je crois que le fait de m’exprimer à ce sujet est l’une des raisons pour lesquelles je fais partie de l’équipe maintenant : « arrête de te plaindre de cela et viens nous aider à la place ». Bien sûr, h2 avait toujours une priorité inférieure par rapport à l’ajout de fonctionnalités supplémentaires.
Avance rapide jusqu’en février 2022, je travaille maintenant dans l’équipe de l’expérience des développeurs (SDK, outils, etc.) et l’équipe de service est occupée à mettre à niveau Microsoft Graph de dotnet « classique » à core. Lors du déploiement de cette nouvelle version, les clients ont commencé à se plaindre de problèmes avec d’anciennes versions du SDK Java. Cela semblait étrange car les mises à niveau internes ne devraient pas avoir d’impact sur la surface de l’API elle-même.
Il s’avère que :
- h2 est activé par défaut avec asp.net core. (désactivé en classique)
- h2 normalise les en-têtes en lower-kebab-case. (par opposition à Upper-Kebab-Case avec HTTP/1.1)
- ces anciennes versions du SDK Java utilisaient des comparaisons sensibles à la casse pour piloter leur logique.
Planification
Après cette première expérience avec h2, l’équipe de service a configuré une plate-forme de validation avec h2 activé afin que nous puissions tester tous les SDK pour h2 et corriger les SDK problématiques.
C’était d’autant plus préoccupant que nous n’avions aucun moyen de mesurer correctement le problème : les requêtes/réponses n’échouaient pas, si une défaillance se produisait, elle se situait sur l’infrastructure des clients.
L’équipe de service a ensuite communiqué un changement de protocole à venir et a donné aux clients plus d’un an pour se préparer à ce changement. Les clients pouvaient soit :
- Désactiver h2 via le code ou la configuration. (moins désiré)
- Vérifier qu’ils utilisaient les versions « testées pour h2 » des SDK.
- Vérifier leur code où il lit les en-têtes.
Livraison
Nous avions initialement prévu de commencer à déployer h2 en septembre 2023, mais nous avons dû le reporter à février 2024 en raison de la vulnérabilité Rapid Reset découverte dans certaines implémentations de serveur h2.
Après le déploiement progressif de h2, l’équipe de service a remarqué que certaines instances de service montaient en charge tandis que d’autres restaient inactives. Cela était dû au fait que l’affinité de partition au niveau du répartiteur de charge ne tenait pas compte du nombre maximal de flux parallèles par connexion, ce qui a été rapidement corrigé.
H2 est enfin entièrement déployé et la seule chose que vous auriez dû remarquer, c’est que « les choses semblent un peu plus rapides ». Ces mises à niveau de protocole (h2, IPv6, TLS1.2+) permettent à notre infrastructure de fonctionner comme sur des roulettes.
Nous envisageons déjà de déployer HTTP3 qui devrait permettre une latence encore plus faible grâce à sa nouvelle couche QUIC !
J’espère que ce genre d’article sur les coulisses vous a intéressé, dites-moi ce que vous en avez pensé dans les commentaires !