Le 25 mars, PagerDuty a subi une dégradation intermittente du service sur une période de trois heures, ce qui a affecté nos clients de diverses manières. Lors de la dégradation du service, PagerDuty n'a pas pu accepter 2,5 % des tentatives d'envoi d'événements aux points de terminaison de nos intégrations et 11,0 % des notifications ont connu 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 minutes. cinq minutes après l'événement déclencheur.

Nous prenons la fiabilité au sérieux, une panne de cette ampleur ainsi que l'impact qu'elle provoque sur nos clients sont inacceptables. Nous nous excusons auprès de tous les clients concernés et nous nous efforçons de garantir que les causes sous-jacentes n'affecteront plus jamais les clients PagerDuty .

Ce qui s'est passé?

Une grande partie du pipeline de notifications PagerDuty est construite autour de Cassandra, une banque de données NoSQL distribuée. Nous utilisons Cassandra pour ses excellentes caractéristiques de durabilité et de disponibilité, et cela fonctionne extrêmement bien pour nous. À mesure que nous avons déplacé une plus grande partie du pipeline de notifications pour utiliser Cassandra, la charge de travail appliquée à notre cluster Cassandra a augmenté, y compris à la fois une charge en régime permanent et une variété de tâches planifiées par lots en rafale.

Le 25 mars, le cluster Cassandra a été soumis à une charge de travail supérieure à la normale de la part de plusieurs services back-end distincts, mais il était toujours dans les limites de sa capacité. Cependant, certaines tâches planifiées ont ensuite appliqué des charges de travail importantes et en rafale au cluster Cassandra, ce qui a placé plusieurs nœuds du cluster Cassandra dans un état de surcharge. Les nœuds Cassandra surchargés ont réagi en annulant diverses demandes en file d'attente, ce qui a entraîné des échecs de traitement pour les clients internes.

Les échecs de requêtes ne sont pas inattendus, bon nombre de nos clients internes disposent d'une logique de nouvelle tentative en cas d'échec pour surmonter les échecs temporaires. Cependant, ces tentatives se sont avérées contre-productives face à la surcharge de Cassandra, de nombreuses requêtes annulées étant immédiatement relancées, ce qui a prolongé la période de surcharge plus longtemps que nécessaire, les tentatives diminuant au fil du temps.

En résumé, des fluctuations importantes dans notre charge de travail Cassandra ont dépassé la capacité de traitement du cluster, ce qui a entraîné des pannes. De plus, la logique de nouvelle tentative du client a entraîné un temps de dissipation de la charge de travail beaucoup plus long, ce qui a prolongé la période d'interruption du service.

Ce que nous faisons à ce sujet

Même avec un excellent système de surveillance et d’alerte, les charges de travail en rafale sont dangereuses : au moment où leur impact peut être mesuré, les dégâts peuvent déjà être faits. Au lieu de cela, une charge de travail globale présentant une faible variabilité devrait être l’objectif. Dans cet esprit, nous avons rééquilibré nos tâches planifiées afin qu’elles soient réparties dans le temps pour minimiser leur chevauchement. En outre, nous aplatissons l’intensité de nos tâches planifiées afin que chacune ait une charge beaucoup plus cohérente et prévisible, bien qu’appliquée sur une période de temps plus longue.

De plus, même si nos ensembles de données sont déjà séparés de manière logique, le fait de disposer d'un seul cluster Cassandra partagé pour l'ensemble du pipeline de notifications reste problématique. En plus du fait que la charge de travail combinée de plusieurs systèmes est difficile à modéliser et à prévoir avec précision, cela signifie également que lorsqu'une surcharge se produit, elle peut avoir un impact sur plusieurs systèmes. Pour réduire cet effet d'entraînement de surcharge, nous allons isoler les systèmes associés pour utiliser des clusters Cassandra distincts, éliminant ainsi la possibilité pour les systèmes d'interférer les uns avec les autres via Cassandra.

Nos politiques de détection des échecs 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 d’échec pour inclure des scénarios de surcharge, à la fois dans nos sessions du vendredi d’échec et au-delà.

Nous prenons au sérieux chaque panne affectant nos clients et prendrons les mesures ci-dessus (et plusieurs autres) pour rendre PagerDuty encore plus fiable. Si vous avez des questions ou des commentaires, veuillez nous en informer.