Chez PagerDuty, nous devons relever des défis architecturaux intéressants afin de garantir la distribution des alertes et d'offrir à nos clients le plus haut niveau de fiabilité possible. Nous avons déjà indiqué que si vous recevez une alerte, vous serez informé que nous vous fournirons une notification d'alerte. 200 OK depuis le point de terminaison d'événement PagerDuty , vous volonté Vous serez averti(e)… même si le centre de données avec lequel vous avez communiqué disparaît immédiatement après votre requête. Afin de maintenir cette garantie, nous devons enregistrer l'événement de manière synchrone dans plusieurs centres de données. Nous utilisons Apache Cassandra pour y parvenir et, par conséquent, s'appuyer fortement sur la majorité quorum lit et écrit.

Avec de telles garanties en place, nos déploiements Cassandra présentent des exigences particulières. Un déploiement Cassandra typique chez PagerDuty se compose de cinq nœuds répartis sur trois centres de données, avec un facteur de réplication de cinq. Cette configuration est parfaitement adaptée aux opérations de lecture et d'écriture par quorum géodistribuées à haute disponibilité, et nous avons J'en ai déjà parlé. Nous ne sommes toutefois pas là pour en parler aujourd'hui. Nous allons plutôt aborder un sujet un peu plus intéressant : les zones de lecture intensive déterministes, malgré une distribution des données parfaitement homogène et des schémas d'accès uniformes !

Ces boîtes chauffent beaucoup…

Nous avons constaté depuis quelque temps que les serveurs Cassandra de l'un de nos datacenters (AWS us-west-1) chauffent plus que les autres. Nous avons également réalisé que le matériel de ce datacenter était légèrement plus ancien et moins performant que celui des deux autres. L'explication semblait simple : le matériel moins performant de ce datacenter entraînait une charge plus élevée que celui, plus performant, du reste de l'anneau. L'un des serveurs de l'anneau possède plus de cœurs que les autres (hébergé chez Linode) et est donc le moins chargé, ce qui confirme l'hypothèse matérielle. Voici un graphique de la charge sur 5 minutes pour l'ensemble des serveurs de l'un de nos anneaux Cassandra :

On peut clairement voir la case « plus forte » en bas avec la charge la plus faible, les hôtes « faibles » us-west-1 en haut et les hôtes moins faibles us-west-2 au milieu. Le rasoir d'Occam , n'est-ce pas ? Pas si vite.

Plus de données, plus de visibilité

Avec une hypothèse matérielle saine et fiable en tête, nous étions rassurés et n'avons pas jugé nécessaire de poursuivre les investigations. Le temps a passé, notre activité s'est développée, et notre charge Cassandra a augmenté en conséquence. Il était temps d'optimiser nos opérations Cassandra. La première chose requise pour optimiser correctement un cluster Cassandra est, bien sûr, PLUS DE DONNÉES !

Une mise à jour de Cassandra nous a généré une quantité impressionnante de données, impossible à exploiter. Nous avons donc entrepris la création de nouveaux tableaux de bord pour tenter d'y déceler des informations pertinentes. Plusieurs surprises sont apparues, mais l'une d'entre elles, en particulier, est restée inexpliquée : si les écritures étaient uniformément réparties sur tous les nœuds, la charge de lecture était asymétrique. Des investigations plus poussées ont révélé la présence de ce même phénomène dans plusieurs services présentant une topologie similaire.

Trois hôtes recevaient systématiquement plus de lectures que les deux autres. Ce résultat était surprenant, car la charge de lecture entrant dans le système était symétrique et, avec un facteur de réplication égal à la taille du cluster, tout aurait dû être équilibré. L'analyse de la topologie a révélé que les hôtes les plus sollicités appartenaient tous au cluster us-west-1 et à Linode. En écartant Linode comme cas particulier (en raison de son plus grand nombre de cœurs de processeur), il est apparu clairement que l'hypothèse matérielle était erronée : ces nœuds surchargés étaient effectivement plus actifs que les autres.

Cassandra Opérations de lecture vs Opérations d'écriture

Nous effectuons des écritures par quorum, mais en raison de notre facteur de réplication élevé, tous les nœuds doivent écrire les données. coordinateur Une confirmation majoritaire suffit pour réussir, l'écriture est tout de même envoyée à tous les nœuds. Nous effectuons également des lectures par quorum, mais contrairement aux écritures, la lecture n'est envoyée qu'au nombre minimal de nœuds requis. Dans notre cas, ce nombre est de trois… très suspect.

Le coordinateur est chargé de sélectionner les nœuds dont il souhaite lire les données. Il s'avère qu'il sélectionne les nœuds qui ont été… répondre le plus rapidement Certes, le matériel légèrement moins performant n'est pas plus performant, alors comment expliquer cela ?

RTT existe

Nos clusters Cassandra étant géographiquement répartis, la communication entre les nœuds prend un certain temps. Ce temps dépend de la source et de la destination, car les relations ne sont pas équilatérales. Voici un schéma illustrant notre topologie et les latences aller-retour approximatives entre les nœuds :

Si l'on suppose un instant que tous les membres ont une latence de lecture équivalente, on peut calculer la probabilité qu'un nœud donné reçoive une requête de lecture d'un coordinateur donné. Ainsi, pour chaque nœud de l'anneau, on recherche les voisins les plus proches (et donc les réponses les plus rapides). À l'aide d'étiquettes [AE] Comme indiqué dans le diagramme précédent, nous pouvons générer un tableau :

Grâce à ce tableau, nous pouvons constater que les nœuds DE ne recevront qu'une lecture dans 2/5 des cas, ce qui signifie que les nœuds AC finissent par recevoir environ 60 % de lectures de plus que leurs homologues !

Distribution de lecture dans le monde réel

En pratique, nous ne sommes pas loin du compte. En observant le graphique des opérations de lecture, on constate que les nœuds us-west-2 effectuent en moyenne 75 lectures/seconde, tandis que les autres en enregistrent environ 115 à 120 – soit près de 60 % de plus ! Ce chiffre fluctue légèrement en fonction de l’apparition de nouvelles routes et des variations de latence de lecture locale, mais même en tenant compte de ces variables, nos résultats restent remarquablement proches des prédictions du tableau de distribution.

Leçons apprises et points à retenir

Maintenant que nous comprenons tout cela, la question qui se pose naturellement est : « Que pouvons-nous faire ? » Déplacer les centres de données pour qu'ils soient équidistants du réseau serait une tentative vaine, car les routes Internet peuvent facilement changer. Répartir nos lectures de manière inégale, en sollicitant davantage les nœuds DE comme nœuds coordinateurs, entraînerait une perte de performance inutile, car les clients des autres centres de données devraient emprunter une route Internet pour atteindre le cluster. Malheureusement, il semble que la solution la plus appropriée soit simplement d'augmenter le nombre de nœuds AC et d'absorber la charge. Cela peut poser problème en cas de perte d'un centre de données, mais reste gérable tant que les centres restants ne sont pas sous-dimensionnés.

Ce fut un enseignement très intéressant pour nous. La réponse paraît maintenant évidente, mais cela illustre à quel point il est facile de formuler des hypothèses sur ses systèmes qui ne se vérifient pas dans la réalité. Il convient également de noter que Il ne s'agit pas d'un comportement spécifique à Cassandra. Tout système géographiquement distribué qui répartit les tâches vers les hôtes ayant le temps de réponse le plus court sera sujet à ce phénomène. Pensez-y si vous devez un jour concevoir un système aux caractéristiques similaires… en espérant vous avoir fait gagner du temps !

Un grand merci à tous les ingénieurs de PagerDuty qui ont consacré du temps à résoudre ce problème ; cet article n’aurait pas été possible sans eux ! N’hésitez pas à consulter nos interventions au Cassandra Summit sur ce sujet et bien d’autres. Donny Nadolny et Paul Rechsteiner .