Abschaffung der Inspected-Count-Limits: technischer Hintergrund

In den letzten paar Jahren war das New Relic Kundenerlebnis eng mit den „Inspected Counts“ (IC) verknüpft, einer internen Maßeinheit, mit der wir die „Kosten“ einer Abfrage berechnen. Bei jedem durch Kund:innen initiierten Vorgang, ob eine Abfrage oder das Laden der Ergebnisseite, wird eine bestimmte Anzahl an Datenpunkten in der New Relic Datenbank (NRDB) geprüft. 2017 führten wir IC-Limits ein, basierend auf den kumulativen Kosten der geprüften Kundendatenpunkte über eine Zeitspanne von 15 Minuten.

Vor Kurzem gaben wir bekannt, dass wir diese Limits nun für alle New Relic Kund:innen abgeschafft haben. So werden keine Abfragen mehr aufgrund von IC-Limits abgewiesen, die Wartezeit von 15 Minuten bis zum Zurücksetzen der Limits entfällt, unsere Abfragekapazität für beide Datenoptionen ist jetzt verdoppelt und Abfragen werden nicht mehr zurückgewiesen, wenn neue Limits erreicht werden.

Diese Änderung wurde möglich, weil sich in NRDB in den letzten paar Jahren einiges geändert hat.

Was sich nicht geändert hat

Einige wichtige Dinge haben sich in NRDB nicht geändert.

Es gibt immer noch eine erheblichen Unterschied zwischen den „normalen“ NRDB-Abfragen und den umfangreichsten Abfragen. Normale Abfragen prüfen in der Regel ein paar Millionen Datenpunkte und dauern weniger als 100 Millisekunden. Das 99,99. Perzentil der Abfragen hingegen ruft mehrere Milliarden an Datenpunkten auf und nimmt 10 Sekunden oder mehr in Anspruch. Es mag unnötig erscheinen, sich Gedanken über diese Extreme zu machen, die vielleicht eine von 10.000 Abfragen betreffen, aber in einem riesigen Multi-Tenant-System wie NRDB finden sie häufig genug statt.

Der andere in diesem Zusammenhang unveränderte Aspekt ist die Speicherung der Daten. Wenn wir Daten von unseren Kund:innen erhalten, werden sie in die sogenannten „Archivdateien“ gespeichert. Archivdateien enthalten pro Kund:in einen einzigen Datentyp und sind auf eine bestimmte Dateigröße und Zeitspanne der enthaltenen Daten beschränkt. Wird eine Abfrage ausgeführt, dienen die Archivdateien quasi als die kleinste Arbeitseinheit. Wir können mehrere Archivdateien zur gleichzeitigen Abfrage auf verschiedene Knoten verteilen, aber eine einzelne Archivdatei muss jeweils auf einem einzelnen Knoten verarbeitet werden.

NRDB im Jahr 2017

2017 befand sich die NRDB in einer herkömmlichen Rechenzentrum-Architektur mit zahlreichen Bare-Metal-Hardwarekomponenten in einer relativ statischen Konfiguration. Unsere Abfrage-Worker-Knoten fassten mehrere Tausend separate Java-Prozesse in einem riesigen, freigegebenen Cluster zusammen, der wiederum als herkömmlicher konsistenter Hash-Ring organisiert war.

Dieser Ansatz ist in Konzept und Ausführung relativ simpel und zahlt sich auch rechnerisch aus. Normale Abfragen beanspruchten nur einen geringen Anteil der Clusterressourcen, und gelegentliche große Abfragen hatten Zugang zu einem viel größeren Ressourcenpool und konnten daher schneller verarbeitet werden, als wenn CPUs bestimmten einzelnen Mandanten zugewiesen wären.

Das funktioniert zwar gut für umfangreiche einmalige Abfragen, kann aber zu einer ungerechten mandantenweiten Verteilung führen. Die Verarbeitung einer einzelnen großen Abfrage wirkte sich nicht merklich auf andere Benutzer:innen aus, aber eine größere Anzahl solcher Abfragen ohne Begrenzung konnte andere Benutzer:innen erheblich beeinträchtigen. Deshalb entschieden wir uns, Limits für Inspected Counts einzuführen. IC-Limits halfen uns festzustellen, ob ein bestimmter Mandant eine Verschlechterung des Benutzererlebnisses für andere Benutzer:innen verursachte. Indem wir die Abfragerate dieses Mandanten durch Zurückweisen eines geringen Teils der Abfragen etwas verlangsamten, konnten wir eine faire Ressourcennutzung gewährleisten.

NRDB im Jahr 2024

In der Zwischenzeit hat sich einiges geändert. Die größte Neuerung ist die Tatsache, dass wir NRDB in die Public Cloud und in eine zellenbasierte Architektur migriert haben. Anstatt nur einen riesigen, freigegebenen Compute-Cluster für Abfragen zu haben, nutzen wir jetzt Dutzende separater Compute-Cluster, die die Workloads rasch und dynamisch unter sich verteilen können. Gleichzeitig haben wir mit dieser neuen Architektur neue Feedbackmechanismen implementiert, die uns nahezu in Echtzeit Informationen zu den Abfragen-Workloads einzelner Benutzer:innen geben.

So kann ein einzelner Mandant keinen anderen Kund:innen mehr Computing-Ressourcen vorenthalten. Wenn die Nutzung durch einen Benutzer ungewöhnlich stark ansteigt, sodass ein Cluster komplett ausgelastet werden könnte, erkennen wir das und können die Workloads der anderen Kund:innen auf andere Cluster umleiten, so dass die Workloads ohne Beeinträchtigung weiterlaufen können. Die Abfragen des ersten Benutzers laufen derweil weiter, allerdings eventuell ein wenig langsamer, wenn die zugewiesene Kapazität ausgeschöpft ist.

Zwei positive Dinge fielen uns bei der ganzen Sache auf: 1. verbesserten sich unsere SLOs für Abfrageverfügbarkeit sowie Performance um zwei Größenordnungen, und 2. korrelierten die Zeiten, zu denen unsere bestehenden IC-Limits aktiviert wurden, nicht mehr mit anderen Messgrößen für die System-Health. Anders ausgedrückt, konnten wir jetzt allen unserer Kund:innen ein besseres Nutzungserlebnis bieten, ohne einige durch IC-Limits einzuschränken.

Heißt das, dass es bei NRDB-Abfragen keinerlei Begrenzungen mehr gibt? Nein, nicht ganz. Aber die Begrenzungen werden weitaus gezielter, nuancierter und flexibler angewandt, sodass die meisten Benutzer:innen sie wahrscheinlich niemals bemerken werden.