Analyse post-incident de l’incident Kagi de la semaine dernière

Résolution du problème d’instabilité du service Kagi.com

• En cours d’investigation - Un problème est survenu après un déploiement et l’équipe travaille à sa résolution. (12 janvier, 16:45 UTC)
• Surveillance - L’équipe a annulé un changement de configuration soupçonné d’être à l’origine du problème et surveille en continu le retour à la normale du service. (12 janvier, 18:30 UTC)
• Mise à jour - Afin de rétablir complètement la stabilité, le trafic sera brièvement interrompu et les utilisateurs seront redirigés vers cette page. Des détails supplémentaires seront fournis à mesure que la situation évolue pendant la restauration contrôlée de la charge sur le service. (12 janvier, 20:26 UTC)
• Surveillance - Le trafic a été rétabli et l’équipe continue de surveiller le retour complet à la normale du service. (12 janvier, 21:14 UTC)
• Résolu - Tous les services fonctionnent normalement. L’équipe remercie les utilisateurs d’avoir patienté pendant la résolution du problème.

Analyse post-incident

• Zac, responsable technique chez Kagi, a partagé une analyse post-incident détaillée de l’interruption de service de la semaine dernière.
• En réponse à cet incident, l’ingénieur senior Seth et l’ingénieur DevOps Luan ont travaillé ensemble.
• Des acteurs ont abusé du service et exploité des goulots d’étranglement de l’infrastructure ; des mesures d’atténuation immédiates ont été prises et des améliorations sont en cours dans plusieurs domaines du code et de la communication.

Déroulement de l’incident

• Le 12 janvier vers 17 h 30, un problème d’infrastructure a été détecté via la surveillance interne et les signalements des utilisateurs.
• La nature du problème provoquait des chargements lents ou des expirations de page pour des utilisateurs dans différentes régions.
• La résolution a pris un temps considérable, et l’équipe a expliqué le contexte, l’évolution de la situation et le plan à venir.

Processus de résolution technique

• Au départ, le problème est survenu par coïncidence au moment d’une augmentation des ressources RAM sur une VM.
• La surveillance signalait une latence élevée et un problème de pool de connexions à la base de données dans l’application.
• Le pool de connexions était arrivé à saturation, ce qui signifiait que le nombre total de connexions dépassait la limite maximale configurée.
• Pendant l’évaluation de l’état interne de la base de données et des performances des requêtes, quelques instances ont été remplacées pour tester l’effet sur la réduction de la congestion.
• Comme le remplacement d’une partie des instances semblait aider, le trafic utilisateur a été temporairement suspendu afin de réinitialiser complètement tous les pools de connexions en une seule fois.
• L’examen de l’état de la base de données a clairement montré que la cause racine était une forte contention sur les lignes de la table des utilisateurs.
• Cette contention a fortement augmenté la latence d’écriture, créant une contre-pression sur le pool de connexions de l’application, jusqu’à épuiser toutes les connexions disponibles.
• Jusqu’à présent, Kagi utilisait la base de données mono-cœur la moins chère disponible sur GCP, ce qui comportait le risque de rendre facilement la base de données inopérante.
• En identifiant les acteurs malveillants, l’équipe a découvert des comptes créés dans les 24 heures ainsi qu’un compte utilisateur unique ayant effectué plus de 60 000 recherches en peu de temps.
• La fonction de recherche a été retirée à ce compte, et un hotfix a été publié pour désactiver l’écriture spécifique à l’origine du problème.
• À minuit, le problème était entièrement résolu, et l’équipe a continué de surveiller de près tout signe de retour de ces acteurs.

Mesures à venir

• Kagi indique avoir beaucoup appris de cet incident et avoir déjà lancé des plans immédiats pour renforcer davantage le système et améliorer le processus de communication en cas d’incident.
• L’entreprise reconnaît d’abord que les mises à jour de la page de statut n’ont pas été assez rapides.
• Elle prévoit de migrer vers une plateforme de page de statut permettant d’exposer plus facilement la surveillance interne automatisée aux utilisateurs, afin qu’ils puissent voir en temps réel l’état de santé de la plateforme.
• L’équipe atténue directement les requêtes problématiques et mène des tests de charge pour déterminer si d’autres failles similaires existent.
• Une surveillance supplémentaire sera mise en place pour pointer plus rapidement vers le bon emplacement dans l’infrastructure et éviter de perdre du temps à suivre de faux signaux comme ce fut le cas cette fois.
• Les systèmes de détection de ce type d’abus sont également en cours de renforcement, et comme ils ont un impact direct non seulement sur les performances mais aussi sur les coûts, il est nécessaire de mettre en place des limitations automatisées pour les faire respecter.
• Les nouvelles limitations étaient déjà en vigueur au moment de cette publication, et leur impact sera surveillé tout en continuant à les ajuster si nécessaire.
• Kagi demande à toute personne pensant avoir été bloquée à tort dans son accès au service de contacter [e-mail].

L’avis de GN⁺

• Kagi a subi un problème de latence d’écriture causé par une contention sur les lignes de la table des utilisateurs, ce qui a créé une contre-pression sur le pool de connexions de l’application et provoqué l’interruption du service.
• Ce problème était la conséquence du risque lié à l’utilisation par Kagi de la base de données mono-cœur la moins chère sur GCP.
• À travers cet incident, l’équipe Kagi montre sa volonté d’améliorer la stabilité et la transparence du service en prenant des mesures pour renforcer le système, améliorer la communication avec les utilisateurs et mettre en place des limitations automatisées pour prévenir les abus. Ces efforts reflètent la volonté de Kagi de fournir un service plus fiable à ses utilisateurs.

[GN⁺]

Avis sur Hacker News

• Avis sur l’incident survenu en même temps qu’une mise à niveau de l’infrastructure

  • Le fait que l’incident se soit produit au moment même où une mise à niveau de l’infrastructure était effectuée via l’ajout de RAM à la VM était, d’après eux, une pure coïncidence.
  • Il est mentionné que ce type de « coïncidence » arrive souvent et pousse à douter de sa propre perception pendant la résolution d’un problème.
  • Il est averti qu’en situation de panique pendant le dépannage, on peut appliquer un hotfix qui casse autre chose, ce qui peut devenir une cruelle loi de Murphy pour les administrateurs système et les développeurs.

• Expérience d’un utilisateur avec la page de statut de Kagi

  • Un utilisateur dit avoir été déstabilisé parce que la page de statut de Kagi indiquait que tout fonctionnait normalement.
  • Il compare avec d’autres services sur lesquels il s’était appuyé par le passé, qui mettaient immédiatement à jour leur page de statut, ce qui permettait de savoir que le problème ne venait pas de son appareil.
  • Il précise qu’il compte continuer à utiliser Kagi, mais espère, comme mentionné dans la post-mortem, que le code de la page de statut sera déplacé vers un autre service/une autre plateforme.

• Commentaire partageant une expérience personnelle

  • Quelqu’un partage avoir personnellement vécu plusieurs fois le même type d’interruption de service et avoir tenté de résoudre des problèmes liés à l’état de santé du pool de connexions à la base de données.
  • Il souligne que les indicateurs habituels de saturation de la base de données (CPU%, IOPS, etc.) ne changent pas beaucoup pendant ce type de panne et que la contention sur les verrous peut plutôt être la cause du problème.
  • Comme recommandation pour le SGBDR utilisé par Kagi, il suggère de tracer des graphiques sur la latence globale des E/S, le temps d’acquisition des verrous et le temps d’exécution des requêtes.

• Commentaire sur l’expérience des startups

  • Il est mentionné que toutes les startups finissent par rencontrer ce genre de problème à un moment donné.
  • Elles n’ont peut-être pas suffisamment de temps ou de ressources pour mettre en place les capacités nécessaires pour l’éviter, ou n’ont peut-être tout simplement pas imaginé qu’un problème précis puisse survenir.
  • La transparence et l’apprentissage sont importants, mais parfois la compensation l’est aussi, et il est suggéré que Kagi envisage d’offrir des crédits de recherche pour la période pendant laquelle le service était indisponible.

• Commentaire sur l’observabilité des systèmes internes

  • Il est souligné que le problème aurait dû être détecté plus rapidement, et que les bons tableaux de bord Datadog et les bonnes requêtes Splunk auraient dû permettre d’identifier bien plus vite ce qui se passait.
  • Il est conseillé d’investir dans une meilleure supervision et d’en faire une expérience d’apprentissage.

• Avis d’un utilisateur payant sur la fiabilité de Kagi

  • Un utilisateur payant ayant subi l’indisponibilité de Kagi dit avoir réalisé qu’il tenait la fiabilité de Google pour acquise.
  • Il mentionne que perdre l’accès à un moteur de recherche peut être un vrai handicap, et partage qu’il adore Kagi mais que subir cette panne a été désagréable.
  • Il espère que cette expérience permettra à Kagi de devenir un service plus robuste et plus fiable.

• Commentaire sur le scraper à l’origine de l’interruption de service

  • En apprenant qu’un scraper exécuté par un utilisateur a provoqué une interruption de service de 7 heures, quelqu’un se demande pourquoi la question « que se passe-t-il si beaucoup de recherches arrivent en même temps ? » n’a pas été posée pendant les tests.

• Commentaire sur l’expérience d’utilisation de Kagi et la post-mortem

  • Après avoir utilisé Kagi pendant quelques semaines, quelqu’un raconte qu’il ne savait pas quoi faire lorsque le service n’a pas chargé immédiatement la semaine dernière.
  • Il dit avoir déjà oublié l’incident avant même la publication de la post-mortem, et remercie l’équipe pour un produit auquel on n’a pas besoin de penser quand on effectue une recherche.

• Commentaire sur la base de données monocœur utilisée sur GCP

  • Le fait que Kagi ait utilisé jusqu’ici la base de données monocœur la moins chère disponible sur GCP est accueilli positivement.
  • Il est suggéré d’envisager quelque chose comme PolyScale, capable d’absorber une forte hausse de la charge en lecture et d’améliorer davantage les performances.

• Commentaire sur le scraping automatisé

  • Il est mentionné qu’après le blocage d’un compte, l’utilisateur qui a pris contact a affirmé avoir utilisé ce compte pour scraper automatiquement les résultats.
  • Il est recommandé de mettre en place des limites de QPS (requêtes par seconde) sur toutes les requêtes RPC / API / HTTP entrantes, en particulier celles qui sont publiques.