Nous avons résolu le problème de l'erreur 429 lors de la grande promotion grâce au gateway Kubernetes et avons également économisé 30 % des coûts d'hébergement des serveurs.

Le mois dernier, pendant la période de promotions Black Friday, notre équipe a failli échouer :13 % des demandes d'analyse des adresses des utilisateurs sont rejetées directement avec le code d'erreur 429.Après une demi-journée de recherche en interne, on a découvert que les règles de limitation de trafic appliquées séparément à chaque micro-service étaient trop strictes. Le trafic du module de consultation logistique avait triplé, et les ressources libérées ne pouvaient pas être utilisées pour d'autres services.

Avant, nous pensions toujours que le gateway Kubernetes était un composant complexe réservé aux grandes entreprises. Ce n’est qu’après avoir rencontré des problèmes que nous avons été contraints de l’utiliser. Tout cela a pris moins d’une semaine, et les résultats ont été bien meilleurs que nous l’espérions.

Qu'est-ce qu'un gateway Kubernetes, après tout ?

En d'autres termes, c'est l'entrée unique pour tout le trafic de votre cluster Kubernetes. Toutes les demandes externes arrivent d'abord ici, puis sont redirigées vers les services backend correspondants. La version open-source que nous utilisons peut gérer jusqu'à 12 000 demandes par seconde avec un seul instance, donc les petites équipes n'ont pas à se soucier des goulets d'étranglement de performance.

Les 3 avantages réels que nous avons obtenus

Le premier point le plus évident : les règles de limitation de trafic n’ont plus besoin d’être configurées individuellement pour chaque service. Auparavant, lors de grandes promotions, nous devions modifier les seuils de limitation de trafic pour sept ou huit microservices, et si nous en manquions un, cela provoquait des problèmes. Maintenant, la limitation de trafic dynamique est gérée directement au niveau du gateway, permettant aux ressources serveur libres de se réorienter automatiquement vers les modules ayant un plus grand trafic. Lors de la grande promotion de Noël, le nombre d’erreurs 429 a été réduit à zéro.

Le deuxième avantage est la réduction des coûts. Auparavant, pour faire face aux pics de charge, nous avions ajouté 2 serveurs de redondance pour chacun des 3 services essentiels, ce qui entraînait un taux d’utilisation des ressources de seulement 20 % la plupart du temps. Maintenant, le gateway effectue automatiquement le répartissement du trafic, nous avons donc pu réduire le nombre de serveurs de 6, et les calculs montrent que les coûts cloud ont diminué de 30 % chaque mois.

Le troisième avantage est que nous n'avons plus besoin de faire modifier en permanence le code backend concernant les logiques générales telles que la gestion des domaines cross-domain et les authentifications. Auparavant, chaque nouveau service nécessitait que le code de vérification JWT soit réécrit pour chaque nouveau service lancé. Maintenant, il suffit d'ajuster une règle au niveau du gateway, et cela nous permet de gagner au moins une demi-journée par semaine pour développer du code d'affaires.

Ne vous fiez pas seulement aux avantages ; nous avons bien connu ces deux problèmes.

Le premier problème est que la configuration par défaut du temps d'attente est très défavorable. Dès le premier jour de lancement, nous avons constaté que 5 % des demandes d'analyse d'adresses tombaient dans le temps d'attente. Après une longue recherche, nous avons découvert que le temps d'attente par défaut du gateway était de 30 secondes, alors que notre service d'analyse d'adresses nécessitait en réalité jusqu'à 40 secondes pour s'exécuter. Une fois que nous avons modifié les règles, le problème a immédiatement disparu. Avant de lancer le service, il est essentiel de vérifier individuellement les seuils de temps d'attente pour chacune de vos interfaces métiers.

Le deuxième piège est de ne pas essayer d'intégrer toutes les fonctionnalités dès le début. Au début, nous voulions activer en même temps les fonctionnalités de journalisation, de limitation de la charge, de WAF (Web Application Firewall) et de déploiement en mode gris, mais une erreur dans la configuration a provoqué une interruption de l'accès à tout le cluster pendant 20 minutes. Par la suite, nous avons commencé par activer uniquement la routage et la limitation de la charge, et après trois jours d'exploitation stable, nous avons progressivement ajouté les autres fonctionnalités sans rencontrer de problèmes.

Faut-il vraiment l'utiliser ? Nos critères de décision sont très simples.

Cas d'utilisation appropriés :

• Vous avez plus de 5 microservices, et chaque fois que vous modifiez les configurations générales, vous devez ajuster plusieurs endroits.
• Nous rencontrons fréquemment des pics de trafic, et il est difficile de répartir les ressources de manière flexible entre les différents services.
• L'équipe du backend est composée de moins de 5 personnes, et nous ne voulons pas perdre notre temps à réécrire constamment de la logique générale.

Situations où il ne faut pas se donner de mal :

• Vous n’avez que deux microservices, et le trafic est stable tout au long de l’année. Actuellement, l’utilisation de NGINX pour la redirection ne pose aucun problème.
• Personne dans l’équipe ne comprend les bases de Kubernetes ; ne vous forcez pas à adopter de nouvelles technologies juste pour suivre la tendance.

Deux conseils concrets pour les petites équipes qui commencent pour la première fois

Il n’est pas nécessaire de se soucier du choix des solutions : pour les petites équipes, il suffit d’utiliser des API ouverts tels que APISIX ou Kong. Les documents d’accompagnement sont complets, et en cas de problème, il est généralement possible de trouver une solution en faisant une recherche. Il n’est pas nécessaire d’acheter la version commerciale, car les fonctionnalités de la version gratuite sont amplement suffisantes.

Avant de mettre le service en ligne, dirigez d’abord 10 % du trafic pendant 24 heures pour vérifier s’il y a des problèmes de timeout ou d’interception erronée des demandes. Si tout est ok, alors transférez tout le trafic. Ne transférez pas tout le trafic d’un coup.

Pour terminer, je vais répondre à une question fréquente : personne n'avait spécifiquement étudié les gateways auparavant pour nos trois backends. Nous avons mis deux jours à les mettre en place en nous référant aux documents officiels, et ce n'est vraiment pas aussi compliqué que vous le pensez.