Au cours des quelques dernières années, l'expérience client de New Relic était liée au décompte inspecté ou IC (de l'anglais « Inspected Count ») — notre unité interne de mesure pour le calcul du « coût » d'une requête. Lorsque les clients effectuent une action à partir d'une requête ou du chargement d'une page, cette action inspecte un certain nombre de points de données dans la base de données New Relic (NRDB). En 2017, nous avons présenté les limites de décompte inspecté (Inspected Count Limits), une capacité qui fait référence au coût cumulatif des points de données client inspectés au cours d'une plage de 15 minutes.
Récemment, nous avons annoncé que nous avions supprimé ces limites pour tous les clients de New Relic. Ainsi, il n'y a plus de requêtes abandonnées en raison des limites IC ni d'attente de 15 minutes pour la réinitialisation de ces limites. Par contre, la capacité de requête a doublé pour les deux options de données et les requêtes ne sont plus rejetées lorsque les nouvelles limites sont atteintes.
Pour bien comprendre pourquoi nous avons pu accomplir ceci, il faut comprendre un peu ce qui a changé sous le capot de NRDB au cours des quelques dernières années.
Ce qui n'a pas changé
Quelques éléments importants n'ont pas changé dans NRDB.
Le premier est qu'il y a une énorme différence entre les requêtes NRDB « normales » et l'extrême que sont les grandes requêtes. Les requêtes normales (à la médiane) observent quelques millions de points de données et leur exécution prend moins de 100 ms. Par contre, les 99,99 centiles des requêtes observe des dizaines de milliards de points de données et leur exécution prend 10 secondes. Il peut sembler inutile de passer tant de temps à réfléchir à ces valeurs hors norme extrêmes, mais dans un système massivement multitenant comme NRDB, ces événements, dont la probabilité est de 1 sur 10 000, se produisent constamment.
L'autre élément du système qui reste inchangé (au moins en ce qui concerne le thème du jour) est la façon dont nous stockons les données sur les disques. Au fur et à mesure que nous recevons des données de la part de nos clients, celles-ci sont enregistrées dans ce que nous appelons des « fichiers d'archive ». Les fichiers d'archive stockent un seul type de données, pour un seul client et sont limités en taille et par la plage temporelle des données qu'ils contiennent. Lorsqu'une requête est exécutée, les fichiers d'archive sont essentiellement la plus petite unité de travail. Nous pouvons distribuer différents fichiers d'archive vers différents nœuds à interroger en parallèle, mais tout fichier d'archive unique doit être entièrement traité sur un seul nœud.
NRDB en 2017
En 2017, NRDB utilisait une architecture de data center classique avec une grande quantité de matériels « bare-metal » dans une configuration relativement statique. Les nœuds de calcul de notre « worker de requêtes » combinaient plusieurs milliers de processus Java individuels dans un énorme cluster partagé organisé en un anneau de hachage ou « hash ring » cohérent.
En termes opérationnels, cette approche est conceptuellement et relativement simple et présente aussi des avantages économiques. Les requêtes normales utilisaient une petite part des ressources du cluster, mais les grandes requêtes occasionnelles pouvaient exiger une plus grande proportion des ressources afin de répondre plus rapidement qu'il n'aurait été possible si les UC étaient strictement alloués aux single-tenants.
Si cela fonctionne bien pour les grandes requêtes ponctuelles, cela ouvre toutefois la porte à des problèmes d'équité importants pour tous les tenants. Si un utilisateur exécutant une grande requête n'avait généralement pas d'effet notable sur qui que ce soit d'autre, l'exécution d'un grand nombre de telles requêtes avait le potentiel d'impacter d'autres utilisateurs de manière significative en l'absence de garde-fous. Cet argument nous a amenés à introduire les limites de décompte inspecté (Inspected Count Limits). Les limites IC nous ont permis de voir un tenant qui entraînait vraisemblablement la détérioration de l'expérience des autres utilisateurs et ralentissait légèrement le taux de requêtes (en rejetant une fraction de leurs requêtes) afin d'assurer l'utilisation équitable des ressources.
NRDB en 2024
Depuis, il y a eu de nombreux changements. En particulier, nous avons migré NRDB vers le cloud public et vers une architecture cellulaire. Au lieu d'avoir un cluster partagé et énorme de calcul des requêtes, nous exécutons désormais des douzaines de clusters isolées de calcul des requêtes avec la capacité de rapidement et dynamiquement redistribuer les charges de travail entre eux. De concert avec cette nouvelle architecture, nous avons également mis en place des mécanismes de rétroaction en temps quasi réel pour comprendre les workloads de requêtes des utilisateurs individuels.
Résultat, il n'est plus possible pour un single‑tenant de priver les autres clients de ressources de calcul. Lorsqu'un utilisateur a un pic d'utilisation anormal pouvant saturer un cluster, nous pouvons le détecter et acheminer les workloads des autres clients vers d'autres clusters afin qu'ils continuent à tourner sans détérioration. En même temps, les requêtes du premier client continuent d'être exécutées, mais peut-être un peu plus lentement que normal si elles ont atteint le plafond de capacités allouées.
En conséquence, nous avons observé deux choses : tout d'abord, la disponibilité de notre requête et les objectifs de niveau de service des performances ont vu une amélioration par 100 (soit deux ordres de grandeur) ; ensuite, les temps de déclenchement de limitation du décompte inspecté (IC) n'étaient plus corrélés avec d'autres mesures de l'intégrité (ou de la santé) du système. En d'autres termes, nous pouvions désormais fournir une meilleure expérience à tous nos clients sans imposer de limites IC à qui que ce soit.
Cela signifie-t-il qu'il n'y a plus de limites sur les requêtes NRDB ? Pas tout à fait. Mais ces limites sont bien plus focalisées, nuancées et adaptables, de telle sorte que nous pensons que la plupart des utilisateurs ne les remarqueront jamais.
Étapes suivantes
Pour en savoir plus sur ce qui se passe sous le capot de NRDB, consultez ce billet de blog.
Les opinions exprimées sur ce blog sont celles de l'auteur et ne reflètent pas nécessairement celles de New Relic. Toutes les solutions proposées par l'auteur sont spécifiques à l'environnement et ne font pas partie des solutions commerciales ou du support proposés par New Relic. Veuillez nous rejoindre exclusivement sur l'Explorers Hub (discuss.newrelic.com) pour toute question et assistance concernant cet article de blog. Ce blog peut contenir des liens vers du contenu de sites tiers. En fournissant de tels liens, New Relic n'adopte, ne garantit, n'approuve ou n'approuve pas les informations, vues ou produits disponibles sur ces sites.
