- Identification du problème
- Des ralentissements intermittents de la réponse se produisaient sur le serveur d’authentification d’Airbridge.
- Comme l’authentification/l’autorisation est effectuée avant les requêtes API, la latence du serveur d’authentification affecte directement la stabilité de l’ensemble du service.
- Les résultats de la supervision montraient une augmentation progressive des alertes de latence de réponse supérieure à 1 seconde → lancement de l’analyse des causes et des travaux d’optimisation.
- Analyse des causes
- (1) DB Query excessives : lors du processus de vérification des autorisations, un trop grand nombre de DB Query étaient exécutées à chaque requête, ce qui épuisait rapidement le DB Connection Pool → latence de réponse.
- (2) Saturation du HikariCP Connection Pool : lors de l’exécution excessive de DB Query, le pool HikariCP arrivait à saturation → constat d’une attente des threads de plus de 30 secondes.
- (3) Faible efficacité du cache : TTL défini trop court à 30 secondes + logique de cache inefficace → forte probabilité de réexécution de DB Query.
- Stratégie d’amélioration
- (1) Amélioration de la structure de vérification des autorisations et de cache
- Introduction d’un accès groupé à la base de données avec
findAllBy~ → DB Query réduites de 134 à 4 (-97 %).
- Mise en place d’un cache
mutableMap basé sur la mémoire de l’application.
- Application du principe de responsabilité unique (SRP) → séparation des méthodes et définition d’une stratégie de cache par sous-logique.
- (2) Introduction d’une architecture de cache à 2 couches
- Mise en place d’une structure mixte Local Cache (Caffeine, L1) + Remote Cache (Redis, L2).
- Amélioration de l’efficacité opérationnelle grâce à une segmentation des stratégies de cache en L1-Only, L2-Only et Hybrid.
- Analyse de l’utilisation mémoire du cache → estimation de 500 000 clés Redis, besoin mémoire d’environ 190 MB, avec une marge de sécurité.
- (3) Invalidation du cache basée sur Redis Pub/Sub
- Sortie d’un fonctionnement dépendant du TTL grâce à une synchronisation en temps réel du cache lors de la modification des informations d’autorisation.
- Lors d’une modification sur un serveur, invalidation synchronisée du Local Cache de tous les serveurs via un canal Redis.
- (4) Ajustement du pool de connexions HikariCP
maximum-pool-size étendu de 10 à 30.- Optimisation d’options détaillées comme Connection Timeout, Idle Timeout et Max Lifetime → réduction de la contention DB I/O.
- Tests de performance et résultats : maintien de performances stables même sous un trafic massif.
- Effets de l’amélioration en environnement de production
- Après le déploiement, disparition des alertes de latence de réponse et stabilisation du temps de réponse global.
- Forte amélioration de la fiabilité du service et de la stabilité opérationnelle.
- Optimisation supplémentaire : JVM Warm-Up
- Découverte d’un problème de latence des réponses initiales causé par le retard de compilation JIT juste après le déploiement.
- Introduction d’un Warm-Up Runner :
- Exécution préalable de requêtes factices au démarrage de l’application.
- Lors du remplacement d’un Pod K8s, traitement du trafic après fin du JIT → temps de réponse initial réduit de 1.07s à 94ms.
- Conclusion et effets
- Résolution du problème de latence de réponse + mise en place d’une architecture capable d’absorber une hausse soudaine du trafic.
- Amélioration de la stabilité et de la fiabilité globales des services Airbridge.
- Hausse de l’utilisation du serveur d’authentification, ce qui améliore la productivité du développement des services métiers.
2 commentaires
Avec l’arrêt récent du service de deep links de Google, on dirait que le nombre d’entreprises utilisant ce service a augmenté.
J’espère un service stable !
Oh… notre entreprise a récemment signé ici elle aussi, et vous travaillez d’arrache-pied pour améliorer les performances, on dirait !!!