Kong Gateway en production : clinique des pannes (Course #kong-clinic)
For ingénieurs plateforme, SRE, responsables des opérations API.
À la fin, vous saurez
À l'issue de cette formation, vous saurez exploiter la limitation de débit de Kong Gateway sur des comportements mesurés — matrice de décision des stratégies, rayon d'impact éprouvé sous partition et audit de l'ordre des plugins — afin qu'une panne du magasin de compteurs produise un multiplicateur connu plutôt qu'illimité.
Cas fil rouge
Vantry Payments place ses API d'autorisation de paiement et d'enrôlement marchand derrière Kong Gateway en mode hybride, sur 6 nœuds de data plane répartis sur 2 régions, avec un contrat de 600 req/min par marchand. Pendant un incident Redis de 4 minutes, les marchands ont soutenu environ 6× leur débit contractuel sans un seul 429, et c'est l'autorisateur en aval qui a délesté. Le risque exige désormais que le comportement du limiteur en perte de magasin de compteurs soit un chiffre mesuré dans le runbook, et non une capture d'écran de configuration.
Programme chaque ligne est quelque chose que vous faites
4 modules · 12 sujets · dans l'ordre du cours
-
Module 1
Le limiteur cède en position ouverte
Objectif. Mesurer ce que Rate Limiting Advanced applique quand un nœud perd son magasin de compteurs partagé, et relever le multiplicateur pour votre topologie.
- Reproduire le repli documenté : à la perte de Redis, le plugin retombe en limitation locale sur chaque nœud
- Calculer le plafond effectif pour un data plane de 6 nœuds — une limite de 600 req/min devient jusqu'à 3 600 req/min pendant la panne
- Instrumenter le repli pour que la bascule soit alertable en 60 secondes au lieu d'être découverte via les réclamations marchands
-
Module 2
Quelle stratégie est seulement permise
Objectif. Choisir une stratégie de comptage au regard des contraintes de mode de déploiement, et non des seules préférences de précision.
- Écarter la stratégie cluster là où elle n'est pas supportée : le mode hybride et les déploiements Konnect l'excluent tous deux
- Arbitrer précision et coût : un sync_rate de 0,1 représente 10 synchronisations de compteurs par seconde, et les fréquences très élevées en mode cluster sont déconseillées
- Tenir compte du comportement en réduction d'échelle, où la probabilité de faux négatifs augmente à mesure que le cluster rétrécit
-
Module 3
L'ordre change à votre insu
Objectif. Auditer la chaîne d'exécution des plugins et détecter les changements de priorité qui réordonnent silencieusement les policies entre versions.
- Reconstituer l'ordre d'exécution réel de la chaîne de policies plutôt que l'ordre d'écriture de la configuration
- Suivre la conséquence d'un changement de priorité : Service Protection est passé de 915 à 901 et s'exécute désormais après les autres plugins de limitation
- Figer l'ordre attendu dans un test qui échoue à la montée de version, couvrant tous les plugins des 2 routes les plus chargées
-
Module 4
Le prouver sous partition
Objectif. Exécuter l'exercice de partition de bout en bout et produire l'entrée de runbook avec des chiffres mesurés.
- Couper le magasin de compteurs 4 minutes sous une charge réaliste et relever les requêtes admises face aux 600 req/min contractuels
- Recueillir les preuves qu'exige une revue post-incident : débit admis, nombre de nœuds, début du repli et durée de reprise
- Rédiger l'entrée de runbook comme un comportement mesuré et daté, le support des stratégies comme les priorités de plugins évoluant entre versions
Références & documentation officielle chaque affirmation ci-dessus a une source
Module 1
- RFC 6585 — Additional HTTP Status CodesSpécification
- Gateway rate limitingDoc MuleSoft
- Rate Limiting Advanced pluginDoc MuleSoft
Module 2
Module 3
- Kong plugin execution and priorityDoc MuleSoft
- Plugin entityDoc MuleSoft
Module 4
- Kong Gateway monitoringDoc MuleSoft