Skalierung, Monitoring und produktiver Betrieb

Skalierung, Monitoring und produktiver Betrieb

0:00 Ich fange mit einer Einschränkung an, die beim Entwurf einer Architektur gern übersehen wird: Queue Mode und Binärdaten im Dateisystem schließen sich aus. Das steht so in der Dokumentation, und es ist keine Kleinigkeit — wenn Ihr Prozess Dateien verarbeitet und gleichzeitig skalieren soll, brauchen Sie einen externen Objektspeicher.

0:19 Wer das erst beim Umbau merkt, plant zweimal. Dieses Modul zeigt, wie n8n skaliert, was man dafür einrichten muss und, mindestens so wichtig, woran man im Betrieb erkennt, dass etwas nicht stimmt.

Skalierung, Monitoring und produktiver Betrieb

0:31 Wir bleiben am sechsten Tag und beim Betrieb. Zuerst das Ausführungsmodell: Wie verteilt n8n Arbeit auf mehrere Prozesse? Dann Hochverfügbarkeit und Last — zwei Dinge, die man leicht verwechselt. Danach die Datenmengen, die sich im Betrieb ansammeln, und was man dagegen tut. Und zum Schluss das Beobachten: Metriken, Protokolle und die Frage, wer eigentlich reagiert, wenn eine Schwelle überschritten wird.

Ausführungsmodell und Queue Mode

0:56 Fangen wir beim Ausführungsmodell an. Das Prinzip ist aus vielen Systemen bekannt: Eine Instanz nimmt an, mehrere arbeiten ab. In n8n heißt das Queue Mode — und die Dokumentation nennt es schlicht den Modus mit der besten Skalierbarkeit. Im Queue Mode laufen mehrere n8n-Instanzen. Eine Main Instance nimmt Auslöser und Webhook-Aufrufe entgegen und erzeugt eine Ausführung, ohne sie auszuführen.

1:21 Worker holen sie sich und führen sie aus. Denken Sie an die Anmeldung einer Werkstatt: Dort wird der Auftrag angenommen und ein Zettel geschrieben; gearbeitet wird in der Halle, und zwar von so vielen Leuten, wie gerade da sind. Der Vorteil dieser Trennung: Sie können die Halle vergrößern, ohne die Anmeldung anzufassen — und genau das ist Skalierung.

1:42 Fünf Stationen, und der interessante Teil ist, was dabei wo liegt. Die Main Instance erzeugt die Ausführung. Redis nimmt die Kennung in die Warteschlange — nur die Kennung, nicht die Daten. Ein Worker holt sie ab und liest den Workflow aus der Datenbank. Und das Ergebnis geht zurück in die Datenbank, gefolgt von einer Meldung. Sie sehen: Redis ist der Vermittler, die Datenbank ist die Wahrheit.

2:06 Daraus folgt unmittelbar, warum die Datenbankwahl in diesem Modus so wichtig wird — sie trägt die gesamte Last aller Worker. Vier Voraussetzungen. Der Ausführungsmodus muss auf der Main Instance und auf jedem Worker gesetzt sein. Derselbe Verschlüsselungsschlüssel muss auf allen Prozessen liegen — sonst scheitern Credentials, und zwar sporadisch; das hatten wir im Sicherheitsmodul.

2:30 PostgreSQL als Datenbank, denn SQLite ist im Queue Mode ausdrücklich nicht empfohlen. Und Redis als Vermittler der Warteschlange. Diese vier sind keine Empfehlungen, sondern die Grundausstattung. Wer eine davon weglässt, betreibt kein Queue-Mode-Setup, sondern hat ein Problem mit Verzögerung. Der erste Punkt ist der unangenehmste, weil er nur manchmal auftritt: Ein Worker hat einen abweichenden Schlüssel, und Credentials scheitern sporadisch — je nachdem, welcher Worker den Auftrag zieht.

2:59 Der zweite ist eine Bequemlichkeit aus der Entwicklung: SQLite bleibt stehen, weil es dort funktioniert hat. Der dritte ist ein Denkfehler beim Skalieren: Die Zahl der Worker wird erhöht, aber die Datenbank bleibt der Engpass — dann fahren Sie mehr Lastwagen auf eine Straße, die schon voll ist. Und der vierte ist ein Detail aus der Dokumentation: Worker teilen sich ein Dateisystem, ohne eigene Ereignisprotokolle zu bekommen.

Hochverfügbarkeit und Last

3:24 Jetzt zu einer Unterscheidung, die in Architekturgesprächen ständig verschwimmt: Mehr Worker heißt mehr Durchsatz. Es heißt nicht mehr Verfügbarkeit. Multi-Main bedeutet mehrere Main-Instanzen nebeneinander. Es setzt eine Lizenz voraus, ist standardmäßig ausgeschaltet und wird über eine Umgebungsvariable eingeschaltet. Eine der Instanzen führt; ein Leader-Key mit Laufzeit und Prüfintervall regelt, welche das ist.

3:49 Der Vergleich: Es gibt mehrere Anmeldungen, aber nur eine hat gerade den Schlüssel zum Auftragsbuch — und wenn sie ausfällt, übernimmt eine andere binnen Sekunden. Genau das ist der Unterschied zu mehr Workern: Die machen die Halle größer, aber wenn die Anmeldung schließt, kommt kein Auftrag mehr herein. Vier Punkte, und sie sortieren die Werkzeuge nach ihrem Zweck. Mehr Worker erhöhen den Durchsatz der Ausführungen.

4:14 Eigene Webhook-Prozessoren nehmen der Main Instance die Annahme ab — sinnvoll, wenn die Last beim Entgegennehmen liegt und nicht beim Verarbeiten. Multi-Main verteilt die Annahme und hält sie beim Ausfall einer Instanz aufrecht; das ist die Verfügbarkeitsfrage. Und Worker Concurrency bestimmt, wie viele Läufe ein einzelner Worker gleichzeitig trägt.

4:35 Bevor Sie skalieren, messen Sie also, wo es klemmt — sonst vergrößern Sie die falsche Seite. Der erste Punkt ist ein Planungsfehler: Multi-Main wird eingeplant, ohne die Lizenz dafür zu haben. Der zweite ist der Messfehler von eben: Die Last liegt auf der Annahme, aber skaliert werden die Worker. Der dritte ist ein Detail, das im Betrieb schmerzt: Der Load Balancer verteilt Webhooks, ohne die Sitzungsbindung zu beachten — dann landen zusammengehörige Aufrufe auf verschiedenen Prozessen.

5:04 Und der vierte ist die ungeprüfte Annahme: Der Ausfall einer Main Instance wird nie erprobt. Hochverfügbarkeit, die man nicht getestet hat, ist eine Vermutung — wie die Sicherung im letzten Modul.

Daten im Betrieb

5:16 Kommen wir zu den Datenmengen. Was sich im Betrieb ansammelt, muss auch wieder verschwinden — und dafür gibt es in n8n mehrere Stellschrauben, die man kennen sollte, bevor die Datenbank voll ist. Vier Orte, und Sie kennen alle aus Modul sieben. Ausführungsdaten je Lauf, abhängig von den Workflow-Einstellungen — das ist die größte Menge. Binärdaten, je nach gewählter Ablage.

5:39 Data Tables, begrenzt auf 200 Mebibyte je Instanz. Und Protokolle, sofern sie ungefiltert geschrieben werden. Die Aufzählung wirkt harmlos, bis man sie mit der Laufzahl multipliziert: Ein Workflow, der stündlich läuft, kommt im Jahr auf fast neuntausend Ausführungen. Wenn jede zwei Kilobyte speichert, sind das noch keine zwanzig Megabyte — bei einer PDF je Lauf sieht die Rechnung anders aus.

6:05 Vier Punkte, und der erste ist die Einschränkung aus meiner Einleitung. Der Queue Mode unterstützt keine Ablage im Dateisystem. Wer beides braucht — Skalierung und Dateien —, nutzt einen externen S3-kompatiblen Speicher. Die Datenbank als Ablage funktioniert, wächst aber mit jeder Datei mit; für gelegentliche kleine Anhänge in Ordnung, für einen Dokumentenprozess nicht.

6:27 Und der vierte Punkt verbindet dieses Modul mit dem letzten: Die Wahl wirkt unmittelbar auf Sicherung und Wiederherstellung. Was außerhalb der Datenbank liegt, muss getrennt gesichert werden. Fünf Schritte. Legen Sie je Workflow fest, welche Läufe überhaupt gespeichert werden. Aktivieren Sie das Pruning der Ausführungsdaten und setzen Sie die Frist.

6:48 Prüfen Sie, ob diese Frist zur Aufbewahrungspflicht passt — das ist der Punkt, an dem Betrieb und Datenschutz sich treffen, und beide Seiten haben eine Meinung dazu. Legen Sie für Binärdaten Ablageort und Lebenszyklus fest. Und messen Sie den Füllstand, statt auf die erste Störung zu warten. Die Fußzeile bringt die Arbeitsteilung auf den Punkt: Die Frist ist eine fachliche Entscheidung, die Technik setzt sie nur um.

7:13 Der erste Punkt ist der stille: Pruning ist aus, und die Datenbank wächst über Monate — auffallen wird es beim Sicherungslauf oder bei der Speicherrechnung. Der zweite ist eine halbe Abstimmung: Die Frist wird technisch gesetzt, ohne die Aufbewahrungspflicht zu prüfen. Der dritte ist ein häufiger Konfigurationsfehler: Der Objektspeicher wird eingerichtet, aber ohne Lebenszyklusregel — dann räumt n8n seine Verweise auf und die Dateien bleiben liegen.

7:38 Und der vierte ist die Zahl aus Modul sechs: Der Füllstand der Data Tables fällt erst auf, wenn Schreibzugriffe scheitern.

Beobachten und verantworten

7:46 Zum Abschluss das Beobachten. Und gleich eine Warnung vorweg: Ein Endpunkt, der nach außen zeigt, verrät mehr über Ihren Betrieb, als Ihnen lieb sein kann. n8n stellt Metriken über einen eigenen Endpunkt bereit. Er ist standardmäßig abgeschaltet und wird über eine Umgebungsvariable eingeschaltet — das ist wieder ein Fall von „vorhanden, aber nicht aktiv".

8:08 Main- und Worker-Instanzen können ihn anbieten. Und dann die Warnung, die in der Dokumentation eigens hervorgehoben ist: Er gehört nur internen Diensten zugänglich gemacht. Öffentlich gibt er Betriebsinterna preis — Durchsatz, Fehlerraten, Systemzustand. Das ist für einen Angreifer wertvolle Aufklärung und für Sie kein Nutzen.

8:29 Fünf Signale, und sie beantworten verschiedene Fragen. Health- und Readiness-Endpunkte sagen, ob eine Instanz lebt und bereit ist — das braucht Ihr Orchestrierungswerkzeug. Prometheus-Metriken geben Durchsatz, Fehler und Warteschlange. Queue-Metriken zeigen aktive, abgeschlossene und gescheiterte Aufträge — die sind im Queue Mode das Herzstück.

8:50 Log Streaming schickt Ereignisse in ein externes System. Und OpenTelemetry-Tracing verfolgt den Weg eines Laufs über Systemgrenzen. Die Fußzeile nennt ein nützliches Detail: Auf Multi-Main verrät eine eigene Kennzahl, welche Instanz gerade führt. Vier Punkte, und keiner davon ist Technik. Schwellen, ab denen jemand benachrichtigt wird, und wer das ist. Ein Runbook je wiederkehrender Störung, auffindbar auch nachts.

9:18 Eine Kapazitätsplanung, die zur erwarteten Last passt. Und eine regelmäßige Durchsicht der Kosten, bevor die Rechnung sie zeigt — besonders relevant, seit KI-Aufrufe im Spiel sind. Was diese vier eint: Sie verlangen eine Person, keine Konfiguration. Monitoring ohne Empfänger ist eine Datensammlung, kein Betrieb. Der erste Punkt ist die Warnung von Folie achtzehn in ihrer schlimmsten Form: Der Metrik-Endpunkt ist öffentlich erreichbar.

9:46 Der zweite ist die häufigste Unvollständigkeit: Es gibt Metriken, aber keine Schwelle und keinen Empfänger. Der dritte ist ein Betriebsklassiker mit hoher Ironie: Das Runbook liegt im Werkzeug, das beim Ausfall nicht erreichbar ist. Und der vierte ist ein Perspektivfehler: Gemessen wird die Instanz, nicht der fachliche Durchsatz der Prozesse.

10:05 Ihre Instanz kann kerngesund sein, während seit zwei Stunden kein Einsatz mehr angelegt wurde.

Übung

10:12 Jetzt entwerfen Sie die Zielarchitektur für Kesselwerk. Der Störungsdienst ist inzwischen geschäftskritisch geworden — und das ändert die Anforderungen grundlegend. Die Meldungen kommen rund um die Uhr. Notdienstfälle müssen binnen Minuten beim Bereitschaftsteam sein. Und Wartungsnachweise als PDF laufen parallel durch denselben Betrieb.

10:32 Lesen Sie diese drei Sätze als Anforderungen: Der erste verlangt Verfügbarkeit, der zweite eine Antwortzeit, der dritte eine Entscheidung über die Binärdatenablage — und damit genau die Einschränkung, mit der ich dieses Modul eröffnet habe. Drei Sätze, drei Architekturentscheidungen. So sehen echte Anforderungen aus. Das Lernziel: Betriebsanforderungen in eine Architektur übersetzen und die Entscheidungen an der erwarteten Last begründen. An der Last — nicht am Bauchgefühl.

11:01 Erfolgreich sind Sie, wenn die Architektur Ausführungsmodus, Datenbank, Ablage der Binärdaten und Zahl der Worker benennt und für drei Kennzahlen Schwelle, Empfänger und Reaktion festgelegt sind. Diese drei Spalten je Kennzahl sind der Kern — ohne Empfänger und Reaktion ist eine Schwelle nur eine Zahl. Wer früh fertig ist, schreibt das Runbook für den Ausfall eines Workers.

11:23 Eine Stunde, fünf Schritte. Schätzen Sie zuerst die erwartete Last — Meldungen je Stunde, Spitzen, Dateigrößen. Grobe Zahlen genügen, aber die Spitze müssen Sie nennen; nach ihr wird ausgelegt. Legen Sie Ausführungsmodus, Datenbank und Ablage der Binärdaten fest. Entscheiden Sie über Multi-Main und begründen Sie es. Wählen Sie drei Kennzahlen und legen Sie je Kennzahl Schwelle und Empfänger fest.

11:48 Und setzen Sie die Pruning-Fristen und halten Sie sie gegen die Aufbewahrungspflicht. Vier Fallen. Erstens, und das ist die Einleitung dieses Moduls: Binärdaten sollen ins Dateisystem, obwohl Queue Mode geplant ist — das geht nicht zusammen. Zweitens: Die Last wird geschätzt, aber nicht die Spitze; ausgelegt wird auf den Durchschnitt, und dann steht der Montagmorgen.

12:11 Drittens: Es werden zehn Kennzahlen erhoben und für keine eine Schwelle gesetzt — das ist Dekoration. Und viertens: Multi-Main wird gewählt, weil es besser klingt, nicht weil die Annahme der Engpass ist. Messen Sie zuerst, skalieren Sie danach.