Wir führen keine Cron-Jobs bei Nextdoor aus

Hintergrund

Bei Nextdoor führen wir viele geplante Jobs für verschiedene wichtige Zwecke aus, z. B. das tägliche Senden von zig Millionen Digest-E-Mails an unsere Benutzer, das Erstellen interner Berichte über unser Wachstum und einige operative Aufgaben. Wie viele andere Internetunternehmen (z. B. Airbnb und Quora) begannen wir mit Cron und bauten schließlich unseren eigenen Cron-Ersatz, den wir Nextdoor Scheduler nannten.

Wir verwenden Nextdoor Scheduler seit über 18 Monaten und sind sehr zufrieden damit.

Also, was ist das Problem mit Cron?

Es gibt vier Hauptprobleme mit Cron.

Erstens war die Art und Weise, wie wir Cron verwenden, nicht skalierbar. Wir haben alle Cron-Jobs auf einem bulligen Scheduler-Computer (c3.8xlarge) ausgeführt. Als wir an Zugkraft gewonnen haben, haben Cron-Jobs die Maschine in Bezug auf die Nutzung der Rechenressourcen an ihre Grenzen gebracht.

Zweitens ist das Bearbeiten der Klartext-Crontab beim Verwalten von Jobs fehleranfällig, z. B. beim Hinzufügen von Jobs, Löschen von Jobs oder Anhalten von Jobs. Zum Beispiel verhinderte ein zusätzliches Sternchen, dass neulich alle Produktionsjobs ausgeführt wurden:

1 * * * * * /opt/nextdoor/some_job.sh

Drittens haben wir mit Cron viel operativen Overhead verursacht. Wir haben fast zweihundert Produktionsaufträge, die tausende Male am Tag mit unterschiedlicher Häufigkeit ausgeführt werden (z. B. minutiös, stündlich, wöchentlich). Jobausfall ist üblich. Die Oncall-Person musste fehlgeschlagene Jobs mehrmals am Tag manuell neu starten, manchmal nach Mitternacht. Hier ist ein Beispiel für eine typische Oncall-Erfahrung: 1) mit der Befehlszeile des fehlgeschlagenen Jobs ausgelagert werden; 2) ssh in die Scheduler-Maschine; 3) Kopieren & Fügen Sie die Befehlszeile ein, um den fehlgeschlagenen Job erneut auszuführen. Das ist sicherlich nicht gut für das technische Glück – ja, wir kümmern uns um das Glück unserer Mitarbeiter!

Viertens hatten wir zur Laufzeit wenig Sichtbarkeit für Produktionsjobs. Es gab keine einfache Möglichkeit zu wissen, welche Jobs ausgeführt wurden oder ob sie erfolgreich waren.

Entscheidung

Genug ist genug. Wir haben uns entschieden, einen Cron-Ersatz zu bauen. Aber warum haben wir keine Open-Source-Lösungen verwendet? Wir konnten einfach kein passendes finden. Wir sprechen Python. Wir wollten vorhandene Infrastrukturkomponenten im Unternehmen nutzen. Wir wollten es bauen, verstehen und besitzen.

Um das Skalierbarkeitsproblem zu beheben, haben wir jeden Job zu einer asynchronen Aufgabe gemacht, die auf einem Cluster von Taskworker-Computern ausgeführt werden kann. Wir können Jobs, die auf Taskworker ausgeführt werden, einfach so konfigurieren, dass sie automatisch wiederholt werden, wenn sie fehlschlagen. Unsere oncall Ingenieure lieben diese Auto-Retry-Funktion!

Um Cron zu ersetzen, haben wir das hervorragende Python—Modul ApScheduler zum Planen von Jobs verwendet, mit dem wir Jobs programmgesteuert verwalten konnten – wir haben REST-APIs, Befehlszeilentools und eine benutzerfreundliche Web-Benutzeroberfläche erstellt.

Architektur

Das folgende Bild zeigt die Architektur unseres Scheduler-Systems.

Nextdoor Scheduler ist mit Python / Tornado implementiert. Es wird als einzelner Daemon-Prozess (Scheduler-Prozess) auf einem einzelnen Computer ausgeführt, der aus drei Komponenten besteht.

  1. Scheduler (oder Core-Scheduler). Es ersetzt Cron und plant die Ausführung von Jobs. Wenn die Ausführung eines Auftrags ausgelöst wird, veröffentlicht der Scheduler-Prozess einfach eine Nachricht für den Auftrag in Amazon SQS. Ein Cluster von Taskworker-Maschinen greift auf Nachrichten von Amazon SQS zu und führt entsprechende Jobs aus. Wie oben erwähnt, verwenden wir APScheduler, um den Core Scheduler zu implementieren.
  2. Scheduler-API. Es bietet eine REST-Schnittstelle zum Verwalten von Jobs, z. B. Hinzufügen von Jobs, Anhalten / Fortsetzen eines Jobs, Entfernen von Jobs, Ändern von Jobs und manuelles Starten eines Jobs. Wir haben Befehlszeilentools auf der Scheduler-API erstellt, um Vorgänge zu vereinfachen, z. B. das gleichzeitige Anhalten einer Gruppe von Jobs.
  3. Web-Benutzeroberfläche. Es ist eine einseitige App, die mit der Scheduler-API spricht. Wir haben Backbone verwendet.js und Bootstrap zur Implementierung der Web-Benutzeroberfläche. Menschliche Bediener verwenden hauptsächlich die Web-Benutzeroberfläche, um mit Nextdoor Scheduler zu interagieren.

Informationen aller Jobs und Jobausführungen werden in einem Datenspeicher gespeichert. Wir verwenden Postgres hauptsächlich hier bei Nextdoor.

Web UI

Ingenieure lieben Web UI von Nextdoor Scheduler, das eine intuitive Möglichkeit bietet, Jobs zu verwalten, anstatt sich früher mit Blackbox-ähnlichen Crons zu befassen.

Stellenangebote

Auf dieser Seite können wir sehen, welche Jobs wir haben und wann sie das nächste Mal ausgeführt werden. Wir können auch auf „Custom Run“ klicken, um einen Job manuell zu starten.

Job bearbeiten

Wir können einen Job einfach bearbeiten, z. B. seinen Zeitplan ändern und mit einem Klick anhalten! Dies ist viel besser als das Ändern von Klartext-Crontab in den alten Tagen.

Seite Ausführungen

Schließlich haben wir eine gute Sichtbarkeit dafür, welche Jobs ausgeführt werden und ob sie erfolgreich sind oder nicht.

Rollout

Das Schreiben von Code ist einfach. Productionization ist schwierig. Als wir die Implementierung von Nextdoor Scheduler abgeschlossen hatten, hatten wir fast 200 Produktions-Cron-Jobs, die auf das neue System migriert werden mussten.

Wir haben das, was wir aus dem Taskworker-Projekt gelernt haben, angewendet, um das Nextdoor Scheduler-System einzuführen. Vier Schritte:

  1. Wir haben Nextdoor Scheduler für die Produktion eingeführt — es wurden noch keine Produktionsjobs mit dem neuen System ausgeführt.
  2. Wir haben der Basisklasse aller Jobs einen Funktionsschalter hinzugefügt.
  3. Wir haben die Funktionsschalter für jeden Job über zwei Wochen langsam und vorsichtig eingeschaltet.
  4. Wir haben die alte bullige Scheduler-Maschine heruntergefahren, auf der Cron lief.

Happy End

Mit dem neuen Nextdoor Scheduler können wir eine viel billigere Scheduler EC2-Instanz (c3.2xlarge) als zuvor (c3.8xlarge) ausführen, während die Last super niedrig bleibt, da wir Jobs auslagern, um sie auf verteilten Taskworker-Computern auszuführen.

Hier ist der CPU-Auslastungsvergleich zwischen dem alten Scheduler-Computer (oberes Diagramm) und dem neuen Scheduler-Computer (unteres Diagramm):

Wir verwenden Scheduler Jobs seit über 18 Monaten. Wir sind bisher zufrieden. Wenn Sie daran interessiert sind, an solchen Problemen und anderen interessanten Infrastrukturherausforderungen zu arbeiten, stellen wir Sie ein!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.