Le 25 mars, PagerDuty a subi une dégradation intermittente de son service pendant trois heures, affectant nos clients de diverses manières. Durant cette dégradation, PagerDuty n'a pas pu accepter 2,5 % des tentatives d'envoi d'événements à nos points de terminaison d'intégration et 11 % des notifications ont subi un retard de livraison : au lieu d'arriver dans les cinq minutes suivant l'événement déclencheur, elles ont été envoyées jusqu'à vingt-cinq minutes après.

Nous prenons la fiabilité très au sérieux. Une panne d'une telle ampleur et son impact sur nos clients sont inacceptables. Nous nous excusons auprès de tous les clients concernés et mettons tout en œuvre pour que les causes sous-jacentes ne se PagerDuty plus.

Ce qui s'est passé?

Une grande partie du pipeline de notifications PagerDuty repose sur Cassandra, une base de données NoSQL distribuée. Nous utilisons Cassandra pour ses excellentes caractéristiques de durabilité et de disponibilité, et cette solution est extrêmement performante. À mesure que nous avons migré une partie croissante du pipeline de notifications vers Cassandra, la charge de travail appliquée à notre cluster Cassandra a augmenté, incluant à la fois une charge stable et diverses tâches planifiées par lots en rafales.

Le 25 mars, le cluster Cassandra a subi une charge de travail supérieure à la normale provenant de plusieurs services back-end distincts, tout en restant dans les limites de sa capacité. Cependant, certaines tâches planifiées ont ensuite appliqué des charges de travail importantes et en rafales au cluster Cassandra, ce qui a placé plusieurs nœuds du cluster Cassandra en état de surcharge. Les nœuds Cassandra surchargés ont réagi en annulant plusieurs requêtes en file d'attente, entraînant des échecs de traitement pour les clients internes.

Les échecs de requêtes ne sont pas inattendus : nombre de nos clients internes disposent d'une logique de relance après échec pour surmonter les défaillances temporaires. Cependant, ces relances se sont avérées contre-productives face à la surcharge de Cassandra : de nombreuses requêtes annulées ont été immédiatement relancées, prolongeant ainsi la période de surcharge plus longtemps que nécessaire, le nombre de relances diminuant progressivement.

En résumé, d'importantes fluctuations de la charge de travail de Cassandra ont dépassé la capacité de traitement du cluster, ce qui a entraîné des pannes. De plus, la logique de relance client a ralenti considérablement la dissipation de la charge de travail, prolongeant ainsi la période d'interruption de service.

Ce que nous faisons à ce sujet

Même avec une surveillance et des alertes performantes, les charges de travail sporadiques sont dangereuses : le temps que leur impact soit mesuré, les dégâts peuvent déjà être causés. L'objectif est plutôt une charge de travail globale peu variable. Dans cette optique, nous avons rééquilibré nos tâches planifiées afin de les répartir temporellement et de minimiser leur chevauchement. De plus, nous aplanissons l'intensité de nos tâches planifiées afin que chacune d'elles ait une charge beaucoup plus constante et prévisible, même si elle s'étend sur une période plus longue.

De plus, bien que nos ensembles de données soient déjà logiquement séparés, l'utilisation d'un seul cluster Cassandra partagé pour l'ensemble du pipeline de notifications reste problématique. Outre la difficulté de modéliser et de prédire avec précision la charge de travail combinée de plusieurs systèmes, une surcharge peut impacter plusieurs systèmes. Pour réduire cet effet d'entraînement, nous allons isoler les systèmes associés afin d'utiliser des clusters Cassandra distincts, éliminant ainsi toute interférence entre les systèmes via Cassandra.

Nos politiques de détection des pannes et de nouvelle tentative doivent également être rééquilibrées, afin qu'elles prennent mieux en compte les scénarios de surcharge et permettent le recul et la dissipation de la charge.

Enfin, nous devons étendre notre régime de tests de défaillance pour inclure des scénarios de surcharge, à la fois dans nos sessions Failure Friday et au-delà.

Nous prenons au sérieux chaque panne affectant nos clients et mettrons en œuvre les mesures ci-dessus (et bien d'autres) pour améliorer la fiabilité de PagerDuty . Pour toute question ou commentaire, n'hésitez pas à nous contacter.