Azure API Management en production : clinique des pannes (Course #azure-apim-clinic)
For ingénieurs plateforme, SRE, responsables des opérations API, architectes cloud.
À la fin, vous saurez
À l'issue de cette formation, vous saurez exploiter un parc Azure API Management sur des métriques défendables — tableau de bord de capacité par localisation, seuils d'alerte justifiés par le tier et le nombre d'unités, et contrat de réessai client — afin qu'une gateway en surcharge soit reconnue en quelques minutes au lieu d'être imputée à un backend.
Cas fil rouge
Kirren Mobility exploite ses API de réservation, de télémétrie et partenaires pour une flotte présente dans 7 villes sur un parc Azure API Management multi-régions, avec 140 API déployées face à un pic du lundi matin. Sa dernière panne a été imputée 40 minutes durant à un défaut backend, le tableau de bord de capacité paraissant sain tout du long, et l'autoscale a ajouté une unité 30 minutes après le passage du trafic qui l'avait déclenché. L'équipe plateforme doit produire un modèle d'alerte résistant au recalcul de la métrique elle-même et un contrat de réessai client documenté.
Programme chaque ligne est quelque chose que vous faites
4 modules · 12 sujets · dans l'ordre du cours
-
Module 1
Elle se dégrade, elle ne throttle pas
Objectif. Caractériser le comportement en surcharge d'une instance API Management et en déduire le contrat qu'elle impose à chaque consommateur.
- Établir le comportement documenté à saturation : l'instance ne throttle pas pour éviter la surcharge, elle présente latence accrue, connexions coupées et timeouts
- Concevoir la protection que la plateforme ne fournit pas — throttling au niveau policy et contrat de réessai avec gigue pour les 140 API
- Distinguer les deux signatures dans une chronologie d'incident, surcharge de gateway et défaillance backend se présentant presque identiquement côté client
-
Module 2
La capacité n'est pas le trafic
Objectif. Lire la métrique de capacité pour ce qu'elle mesure et éliminer les quatre erreurs de lecture courantes de vos tableaux de bord.
- Énoncer la limite clairement : les métriques de capacité ne mesurent pas directement le nombre de requêtes traitées
- Tenir compte des relevés non nuls à trafic nul, dus à des actions de plateforme, et des problèmes qui ne font jamais bouger la métrique
- Retirer les métriques structurellement nulles pour votre tier — la capacité affiche 0 sur les tiers v2, CPU et mémoire affichent 0 sur les tiers classiques
-
Module 3
Des seuils qui survivent au recalcul
Objectif. Fixer des seuils de scaling et d'alerte justifiés par le tier, le nombre d'unités et l'historique de révision de la métrique.
- Appliquer correctement les deux seuils publiés : monter en charge au-delà de 60–70 % soutenus, mais au-delà de 40 % sur une instance à une seule unité pour réserver la capacité des mises à jour de l'OS invité
- Redériver les seuils après un changement de métrique — la mise à jour de calcul de mai 2025 a relevé les valeurs rapportées sans modifier les performances réelles
- Exclure Max de l'alerting : réservé au tier Premium et documenté comme informatif, il ne fonde pas une décision de scaling
-
Module 4
Monter en charge avant d'en avoir besoin
Objectif. Concevoir les règles d'autoscale et le tableau de bord multi-régions au regard des délais et contraintes réels de la plateforme.
- Prévoir une opération de scaling d'environ 30 minutes, les règles devant anticiper le pic plutôt que d'y réagir
- Ventiler la capacité par localisation avant de l'interpréter, et tenir compte du fait que seule la localisation primaire est scalable en déploiement multi-régions
- Amortir les règles contre le flapping et écarter le dernier point à 1 minute, en utilisant des fenêtres de 30 minutes ou plus
Références & documentation officielle chaque affirmation ci-dessus a une source
Module 1
- RFC 6585 — Additional HTTP Status CodesSpécification
- Advanced request throttling with Azure API ManagementDoc MuleSoft
- Capacity of an Azure API Management instanceDoc MuleSoft
Module 2
- Azure API Management v2 tiersDoc MuleSoft
- Monitor published APIs with Azure MonitorDoc MuleSoft
Module 3
Module 4
- Autoscale an Azure API Management instanceDoc MuleSoft
- Flapping in autoscaleDoc MuleSoft