Kapazitätsplanung für Datenbanken

Veröffentlicht: 2016-06-21

Hinweis: Dieser Beitrag ist inspiriert von Julia Evans’ jüngstem Beitrag zur Kapazitätsplanung.

RDBMS

Lassen Sie uns zunächst einige Grundregeln aufstellen. Ja ... dieser Beitrag richtet sich an diejenigen von uns, die MySQL mit jeweils einem einzigen Autor und zwei oder mehr Read Replicas verwenden. Vieles, worüber ich hier sprechen werde, gilt anders oder gar nicht für geclusterte Multi-Writer-Datenspeicher, obwohl diese auch ihre eigenen Kompromisse und Einschränkungen mit sich bringen. Also … Ihre Laufleistung wird definitiv variieren.

Dieser Blogbeitrag GILT jedoch unabhängig davon, ob Sie selbst gehostete physische Hosts verwenden oder sich in AWS befinden, wo Sie magische reservierte Instanzen und nahezu sofortige Bereitstellung verwenden können. In „der Cloud“ zu sein, hindert Sie nicht daran, die Fähigkeiten und Grenzen Ihrer Infrastruktur zu kennen, und entbindet Sie nicht von dieser Verantwortung gegenüber Ihrem Team und Ihren Kunden.

Scherben

Ich habe bereits in einem meiner früheren Posts große Züge davon behandelt, ich habe mich dort hauptsächlich auf die Vorteile von funktionalem oder horizontalem Sharding konzentriert. Ja, das ist eine absolute Voraussetzung, denn was Sie für den Zugriff auf die Datenbankschicht verwenden, entscheidet darüber, wie viel Flexibilität Sie bei der Skalierung haben.

Wenn Sie ein brandneues Unternehmen sind, benötigen Sie am ersten Tag möglicherweise kein funktionales Sharding, aber wenn Sie hoffen (und ich vermute, dass Sie das tun), um zu wachsen, sperren Sie sich nicht mit einem Open-Source-ORM ein, das Ihnen keine Aufteilung erlaubt Ihre Daten funktional auf der ganzen Linie. Bonuspunkte, wenn Sie Ihr Unternehmen auch nicht mit all Ihren relationalen Daten in einem einzigen Schema starten.

Fähigkeit, Lese- und Schreibvorgänge aufzuteilen

Dies ist etwas, das Sie können müssen, aber nicht unbedingt als eine in Stein gemeißelte Regel durchsetzen. Es wird Anwendungsfälle geben, in denen ein Schreibvorgang sehr bald danach gelesen werden muss und in denen die Toleranz für Dinge wie Verzögerungen/eventuelle Konsistenz gering ist. Diese sind in Ordnung, aber in den gleichen Anwendungen gibt es auch Szenarien für Lesevorgänge, die eine längere Zeitspanne eventueller Konsistenz tolerieren können . Wenn solche Lesevorgänge ein hohes Volumen haben, möchten Sie wirklich, dass dieses Volumen an Ihren einzigen Autor geht, wenn es nicht wirklich sein muss? Tun Sie sich selbst einen Gefallen und stellen Sie bald in Ihren Wachstumstagen sicher, dass Sie die Verwendung einer Lese- oder Schreib-IP in Ihrem Code steuern können.

Nun zum Denkprozess der tatsächlichen Kapazitätsplanung … Ein Datenbank-Cluster hält nicht Schritt, was kann ich tun?

Bestimmen Sie den Systemengpass

  • Haben Sie Engpässe beim Schreiben oder Lesen?
  • Zeigt das Problem eine so hohe CPU?
  • Zeigt es sich als E/A-Kapazität?
  • Ist es eine wachsende Verzögerung bei den Replikaten ohne einen eindeutigen Schuldigen für die Leseabfrage?
  • Sind es Schlösser?
  • Woher weiß ich überhaupt, was es ist?

Jeder davon kann ein eigener Beitrag sein. Der Punkt, den ich zu machen versuche, ist, dass Sie mit Ihrem System und DB-spezifischen Metriken vertraut sein müssen, um herauszufinden, welches Stück der Engpass ist.

Sie brauchen eine Grundlinie

Stellen Sie immer sicher, dass Sie mindestens ein paar Wochen zurück grundlegende Systemmetriken zur Verfügung haben, die Sie visualisieren können. Viele Tools bieten dies (Cacti, Munin, Graphite…etc). Sobald Sie wissen, an welche Systemmetrik Sie hauptsächlich gebunden sind, müssen Sie Basis- und Spitzenwerte festlegen. Andernfalls wird die Bestimmung, ob es sich bei Ihrem aktuellen Problem um einen von einer neuen Anwendung verursachten Fehler im Vergleich zu echtem Wachstum handelt, viel fehleranfälliger sein, als Sie möchten.

Grundlegende Servermetriken können jedoch nur so weit gehen – irgendwann werden Sie feststellen, dass Sie auch kontextbasierte Metriken benötigen. Die Abfrageleistung und die von der App wahrgenommene Leistung geben Aufschluss darüber, was die Anwendung als Antwortzeit auf Abfragen ansieht. Es gibt viele Tools, um dieses kontextlastige Tracking durchzuführen. Einige sind Open Source wie Anemometer und kommerzielle Tools wie Vivid Cortex (Wir verwenden diese bei SendGrid. Sehen Sie, wie wir hier darüber sprechen.) Auch nur das Verfolgen dieser Metriken aus der App-Perspektive und das Werfen als statsd-Metriken ist ein guter erster Schritt. Aber Sie müssen sich früh daran gewöhnen, dass das, was Ihre App wahrnimmt, das ist, was Ihre Kunden wahrnehmen. Und du musst zuerst einen Weg finden, es herauszufinden.

Lernen Sie die Verkehrsmuster Ihres Unternehmens kennen

Sind Sie ein Unternehmen, das an bestimmten Wochentagen für extreme Spitzen anfällig ist (z. B. Marketing)? Haben Sie regelmäßige Produkteinführungen, die Ihren Datenverkehr verdreifachen oder vervierfachen, wie beim Spielen? Diese Art von Fragen bestimmen, wie viel Reserve Sie behalten sollten oder ob Sie in elastisches Wachstum investieren müssen.

Bestimmen Sie das Verhältnis der rohen Verkehrszahlen zur genutzten Kapazität

Das ist einfach die Antwort auf „Wenn wir keine Code-Optimierungen vorgenommen haben, wie viele E-Mails/Verkäufe/Online-Benutzer/was auch immer“ können wir mit den Datenbankinstanzen bedienen, die wir gerade haben?

Idealerweise ist dies ein spezifischer Wert, der die Mathematik zur Planung des Jahreswachstums zu einer einfachen mathematischen Gleichung macht. Aber das Leben ist nie ideal und dieser Wert variiert je nach Saison oder ganz externen Glücksfaktoren wie der Gewinnung eines neuen Großkunden. Bei frühen Startups ist diese Zahl ein sich schneller bewegendes Ziel, aber sie sollte sich stabilisieren, wenn das Unternehmen von den Anfängen zu etablierteren Unternehmen mit vorhersehbareren Geschäftswachstumsmustern übergeht.

Muss ich wirklich mehr Maschinen kaufen?

Sie müssen einen Weg finden, um festzustellen, ob dies wirklich Kapazität ist – ich muss die Schreibvorgänge aufteilen, um mehr gleichzeitige Schreiblast zu unterstützen, oder mehr Lesereplikate hinzufügen – vs. codebasierter Leistungsengpass (bei dieser neuen Abfrage aus einer kürzlich durchgeführten Bereitstellung können die Ergebnisse wirklich in etwas Billigerem zwischengespeichert werden und die Datenbank nicht so sehr schlagen).

Wie machst du das? Sie müssen sich mit Ihren Abfragen vertraut machen. Der Babyschritt dafür ist eine Kombination aus Innotop, Slow Log und dem pt-query-digest des Percona-Toolkits. Sie können dies automatisieren, indem Sie die DB-Protokolle an einen zentralen Ort senden und den Digest-Teil automatisieren.

Aber das ist auch nicht das ganze Bild, langsame Protokolle sind leistungsintensiv, wenn Sie ihren Schwellenwert zu weit senken. Wenn Sie mit weniger selektivem Sampling leben können, müssen Sie die gesamten Konversationen zwischen der Anwendung und dem Datenspeicher erkennen. Im Open-Source-Land können Sie so einfach wie tcpdump gehen oder gehostete Produkte wie Datadog, New Relic oder VividCortex verwenden.

Einen Anruf tätigen

Kapazitätsplanung kann zu 90 % aus Wissenschaft und zu 10 % aus Kunst bestehen, aber diese 10 % sollten nicht bedeuten, dass wir nicht so viel wie möglich vom Gesamtbild anstreben sollten. Als Ingenieure können wir uns manchmal auf die fehlenden 10 % konzentrieren und nicht erkennen, dass uns diese 90 %, wenn wir die Arbeit erledigt haben, weit in eine bessere Vorstellung vom Zustand unseres Stacks, eine effizientere Nutzung unserer Zeit, die Optimierung der Leistung und die Planungskapazität bringen können vorsichtig erhöht, was letztendlich zu einer viel besseren Kapitalrendite für unsere Produkte führt.