NATS ist eine zentrale Komponente der Architektur. NATS ist ein verteiltes Messaging-System, welches häufig für Microservices verwendet wird.

Unser Backend (oder auch andere Systeme) publizieren Events in NATS, die dann beispielsweise in N8n über ein Trigger konsumiert werden.

Grundlagen

Übersicht

NATS kann grob in zwei Varianten unterteilt werden, NATS Core und NATS JetStream.

NATS Core ist das Grundsystem von NATS und bietet schnelle, leichtgewichtige Kommunikationsmöglichkeiten wie Publish/Subscribe, Request/Reply und Queueing. Dabei werden Nachrichten in der Regel nur flüchtig übertragen: Geht ein Empfänger offline, gehen die Nachrichten verloren. Der Fokus liegt auf extrem niedriger Latenz und hoher Performance.

NATS JetStream erweitert NATS Core um Funktionen wie Persistenz, wiederholtes Lesen von Nachrichten und zeitversetzte Verarbeitung. Nachrichten können gespeichert werden, was eine zuverlässige Zustellung, Wiederholungen und komplexe Workflows ermöglicht. JetStream ist damit besonders geeignet für Szenarien, in denen eine dauerhafte Verarbeitung oder Event-Sourcing erforderlich ist, während Core eher für schnelle, vorübergehende Nachrichtenübertragung optimiert ist.

Accounts

Accounts sind eine Möglichkeit, Mandanten oder Anwendungen innerhalb eines Clusters oder NATS Servers voneinander abzugrenzen. Jeder Account besitzt einen eigenen Namespace für Subjekte, verwaltet seine Benutzer und deren Berechtigungen und bietet so eine klare Trennung zwischen unterschiedlichen Workloads. Gleichzeitig lassen sich über Exports und Imports bestimmte Subjekte gezielt mit anderen Accounts teilen, sodass Kommunikation zwischen getrennten Bereichen möglich bleibt. Auf diese Weise stellen Accounts die Grundlage für Multi-Tenancy, Sicherheit und flexible Skalierung in NATS dar.

Wir verwenden zwei verschiedene Accounts:

Benutzer können jeweils nur einem Account zugeordnet werden.

Authentifizierung

Die Kommunikation ist TLS verschlüsselt, es kommen die TLS Zertifikate aus HashiCorp KeyVault zum Einsatz. Diese werden dann einzelnen Accounts zugewiesen. Der NATS Server validiert das Zertifikat an Hand der Zertifikatskette und mapt dann die Zertifikatsinformationen zu einem User. Üblicherweise wird dabei ein SAN (Subject Alternative Name) in Form einer Mail-Adresse verwendet. Diese gibt es in unserem Fall nicht, sodass das Subject verwendet wird. Wichtig ist, dass das Subject in RFC2253 Form verwendet werden muss.

Diese Subject wird dann dem Account zugeordnet:

Da ein User nur einem Account zugeordnet werden kann, gibt es einen admin User für administrative Tätigkeiten sowie einen JetStream Admin User für die Account-Verwaltung.

Berechtigungen des Backend Users

NATS wird neben dem Eventmanagement auch für die Task Queue mit Taskiq eingesetzt. Beides läuft über JetStream, NATS Core Subjects (früher taskiq_tasks mit einer Queue Group) werden nicht mehr verwendet. Das Backend legt den Stream für die Task Queue selbst an und aktualisiert ihn (siehe Task Queue (Taskiq)), benötigt also Zugriff auf die JetStream API. Der backend User hat daher aktuell weiterhin weitreichende Berechtigungen:

Backend, Worker und Scheduler verwenden alle dasselbe Zertifikat und damit denselben User. Eine Einschränkung auf die tatsächlich benötigten Subjects (mksp.>, tasks.mksp.backend, JetStream API für MKSP_TASKS, _INBOX.>) ist noch offen.

JetStream Konfiguration

In unserem Fall ist Persistenz auch bei einem zeitweisen Ausfall der Internetverbindung im Makerspace notwendig, sodass wir JetStream mit Message Retention verwenden. Dabei müssen die wichtigen Komponenten vorab angelegt werden.

NATS CLI konfigurieren

Zur Administration bietet sich die Verwendung der NATS CLI an. Diese muss einmalig eingerichtet werden, dafür sind die entsprechenden Zertifikatsdateien notwendig. Wir legen zwei Kontexte an, einen für den Cluster Admin, einen für den JetStream Admin:

Anschließend wählen wir den richtigen Kontext aus, in diesem Fall den JetStream Admin Context:

JetStream initialisieren

JetStream ist in so genannte Streams unterteilt, welche bestimmte Subjects in einem Stream zusammenfassen. Wir nutzen für alle Events einen gemeinsamen Präfix (mksp), sodass wir den Stream hierfür erstellen. Die NATS Dokumentation selbst beschreibt die Konzepte sehr gut:

• JetStream im Allgemeinen: https://docs.nats.io/nats-concepts/jetstream
• JetStream Streams: https://docs.nats.io/nats-concepts/jetstream/streams

Wir legen nun also ein Stream namens backend_events an:

Task Queue (Taskiq)

Die asynchronen Tasks zwischen Backend und Worker laufen über einen eigenen Stream. Dieser wird nicht manuell angelegt: Backend, Worker und Scheduler legen ihn beim Start an und passen ihn an, falls die Konfiguration im Code (src/worker/broker.py) abweicht. Änderungen daher bitte im Code und nicht über die NATS CLI vornehmen.

Tasks, die erstellt werden während der Worker nicht läuft, bleiben damit im Stream liegen und werden abgearbeitet, sobald der Worker wieder verfügbar ist. Per-Message TTL setzt NATS Server 2.11 oder neuer voraus.

JetStream Consumer

Consumer sind eine Auswahl / Ansicht von Teilen eines Streams. Details finden sich wieder in der NATS Dokumentation: https://docs.nats.io/nats-concepts/jetstream/consumers

Consumer können entweder persistent sein (dauerhaft, ein Client kann dann den bestehenden Consumer neben) oder flüchtig (ephemeral), in diesem Fall wird der Consumer beim Erstellen des Clients (beispielsweise durch N8n) angelegt. In der Regel werden Consumer durch einen Filter auf bestimmte Subjects beschränkt, diese dürfen sich nicht überschneiden. Da die NATS JavaScript Client Library (die von n8n verwendet wird) es leider nicht sinnvoll erlaubt, ephemeral Consumer anzulegen verwenden wir dauerhafte Consumer-Namen.

Die Consumer können dann wie folgt angelegt werden:

Troubleshooting

Man kann über die NATS CLI mit dem Server interagieren.

JetStream

Streams

Man kann sich die vorhandenen Streams und die Anzahl der Nachrichten anschauen. Die Anzahl sollte üblicherweise 0 sein, wenn die Zahl höher ist, werden Events nicht richtig abgearbeitet. Neben backend_events gibt es den Stream MKSP_TASKS der Task Queue; liegen dort dauerhaft Nachrichten, läuft der Worker nicht oder holt keine Tasks ab (prüfen mit nats consumer info MKSP_TASKS mksp_backend_worker).

Ebenso kann man sich - falls vorhandenen - die Nachrichten im Stream anzeigen lassen:

Consumer

Die bestehenden Consumer kann man sich ebenfalls im Jetstream Context anzeigen lassen:

In dieser Tabelle sieht man bereits die "unprocessed" Nachrichten. Ist diese Zahl größer als 0 s sieht also gut, wenn n8n die Nachrichten nicht korrekt verarbeitet. Man kann sich ebenfalls die Details eines Consumers anzeigen lassen:

Insbesondere die letzten beiden Zeilen sind wichtig:

• Unprocessed Messages sind Nachrichten, die noch nicht abgerufen wurden. Dies sollte immer 0 sein
• Waiting Pulls: die Anzahl der verbundenen Clients. Üblicherweise sollte das nur n8n sein, also immer 1.

Server

Man kann sich ebenfalls die aktiven Verbindungen anzeigen:

Die Ausgabe oben stammt aus der Zeit vor der Umstellung der Task Queue auf JetStream, die Verbindung backend_fastapi gibt es inzwischen nicht mehr.

Der Name ist hierbei frei vergeben, in unserem Fall im Backend Code (abhängig von der Rolle des Prozesses). Jeder Prozess hält genau eine Verbindung, über die sowohl Tasks als auch Events laufen. Wir erwarten die folgenden Clients:

Man kann sich ebenfalls die Subscriptions der jeweiligen Connections anschauen. Hierfür muss die Ausgabe auf JSON umgestellt werden:

Auch diese Ausgabe stammt aus der Zeit vor der JetStream-Umstellung: Die Subscription auf taskiq_tasks gibt es nicht mehr, der Worker holt Tasks über den Pull Consumer mksp_backend_worker ab.