Sidecar
Hilfsfunktionen in einem Begleitprozess
Die Idee und ihr Nutzen
Der Schadendienst einer Versicherung, also das Programm für die Bearbeitung von Schäden, schreibt während der Arbeit technische Meldungen, sogenannte Protokollzeilen. Diese Protokollzeilen sollen in einem zentralen Protokollsystem landen, in dem das Betriebsteam nach Fehlern sucht. Damit das Team des Schadendienstes den Versand nicht selbst programmieren muss, schreibt der Schadendienst seine Protokollzeilen nur in eine lokale Protokolldatei auf seinem eigenen Rechner. Ein kleines Hilfsprogramm, das auf demselben Rechner direkt neben dem Schadendienst läuft, liest diese Zeilen und schickt sie an das Protokollsystem. Dasselbe Hilfsprogramm lässt sich neben viele verschiedene Dienste setzen, denn es liest nur deren Protokolldateien, gleich in welcher Programmiersprache ein Dienst geschrieben ist. Ein solches Begleitprogramm heißt Sidecar; das englische Wort bedeutet Beiwagen eines Motorrads. Gemeint ist, dass das Hilfsprogramm neben genau einem Dienst läuft und zusammen mit ihm gestartet wird.
Wie funktioniert es?
Die Versicherung betreibt sechs Instanzen des Schadendienstes auf verschiedenen Rechnern. Eine Instanz ist ein laufendes Exemplar des Programms; die Ablaufgrafik nennt die Instanzen Kopien. Neben jeder Instanz läuft ein eigenes Exemplar desselben Sidecar-Programms. Jedes Exemplar liest nur die lokale Protokolldatei auf seinem Rechner und muss deshalb nichts über die anderen Instanzen wissen. Eine dieser Instanzen schreibt eine Protokollzeile wie „Schaden 4711 gespeichert“ in die lokale Protokolldatei. Der Sidecar dieser Instanz liest die neuen Zeilen aus der lokalen Protokolldatei, ergänzt den Namen des Rechners und der Instanz und schickt die Zeilen an das Protokollsystem. Nur der Sidecar spricht mit dem Protokollsystem. An einem Nachmittag stürzt der Sidecar ab, und neue Zeilen erscheinen vorerst nicht im Protokollsystem. Der Schadendienst bearbeitet aber weiter Schäden und schreibt weiter in die lokale Protokolldatei, denn seine Arbeit hängt nicht vom Sidecar ab. Die „Überwachung“, ein Programm, das ausgefallene Programme neu startet, bemerkt den Ausfall und startet den Sidecar neu. Der Sidecar liest die Zeilen seit dem Absturz aus der lokalen Protokolldatei nach und sendet sie nachträglich an das Protokollsystem.
Ein Sidecar ist ein eigenständiges Programm, das neben genau einer Instanz eines Dienstes läuft, meist auf demselben Rechner oder in derselben Ausführungseinheit. Eine Ausführungseinheit ist eine Gruppe von Programmen, die immer gemeinsam gestartet werden. In Kubernetes, einer verbreiteten Plattform zum Betrieb von Programmen auf vielen Rechnern, heißt eine solche Einheit Pod. Mit jeder Instanz des Schadendienstes startet die Plattform einen eigenen Sidecar. Der Sidecar teilt mit dem Schadendienst ein lokales Verzeichnis, in dem die Protokolldatei liegt, und kann den Schadendienst über eine lokale Netzwerkverbindung erreichen. Den Arbeitsspeicher des Schadendienstes teilt der Sidecar nicht. Der Schadendienst schreibt seine Protokollzeilen in die lokale Protokolldatei oder auf die Standardausgabe, den Textkanal, den jedes Programm ohne Einrichtung beschreiben kann. Adresse und Format des Protokollsystems kennt nur der Sidecar. Alle Dienste, neben denen dasselbe Sidecar-Programm läuft, liefern ihre Protokollzeilen deshalb im selben Format und mit denselben Zusatzangaben ab, gleich in welcher Programmiersprache sie geschrieben sind. Für andere Hilfsaufgaben kann ein Dienst den Sidecar auch direkt über eine lokale Netzwerkverbindung ansprechen. So kann ein Sidecar zum Beispiel verschlüsselte Verbindungen zu anderen Diensten aufbauen.
Der Sidecar bleibt ein eigenes Programm und kann unabhängig vom Schadendienst ausfallen. Die „Überwachung“ muss deshalb auch den Sidecar beobachten. Der Sidecar garantiert nicht, dass jede Protokollzeile ankommt: Nach einem Absturz kann er fehlende Zeilen nur nachliefern, solange sie noch in der lokalen Protokolldatei stehen.
Sidecar: ein eigenes Programm verschickt die Protokolle des Schadendienstes
Wann ist es sinnvoll und wann nicht?
Ein Sidecar lohnt sich
- Viele Dienste brauchen dieselbe technische Hilfsaufgabe, und jede Instanz eines Dienstes braucht sie. Solche Hilfsaufgaben sind etwa Protokolle weiterleiten, Verbindungen verschlüsseln oder Einstellungen nachladen. Ohne Sidecar steckt dieselbe Hilfsaufgabe in jedem dieser Dienste noch einmal. Mit Sidecar erledigt sie ein einziges Hilfsprogramm, von dem neben jeder Instanz ein Exemplar läuft.
- Verschiedene Teams entwickeln die Dienste in verschiedenen Programmiersprachen, und die Hilfsaufgabe soll trotzdem überall gleich erledigt werden. Die Versicherung betreibt Dutzende solcher Dienste. Baut jedes Team den Versand an das Protokollsystem selbst ein, entstehen unterschiedliche Formate, Einstellungen und Fehler. Das Team des Schadendienstes vergisst dann zum Beispiel, den Namen des Rechners mitzuschicken, und im Protokollsystem ist nicht zu erkennen, von welcher der sechs Instanzen eine Zeile stammt. Ein anderes Team baut keinen zweiten Versuch ein, und sein Dienst verliert Meldungen, wenn das Protokollsystem kurz nicht erreichbar ist.
- Die Hilfsaufgabe soll unabhängig vom Programmcode der Dienste gepflegt werden. Ändern sich Adresse oder Format des Protokollsystems, aktualisiert das Betriebsteam nur den Sidecar. Ohne Sidecar müssten das Team des Schadendienstes und die Teams aller anderen Dienste ihre Dienste anpassen, obwohl sich an der eigentlichen Arbeit der Dienste nichts geändert hat.
Ein Sidecar ist nicht das Richtige
- Eine Aufgabe wird nur von einem Dienst gebraucht und lässt sich mit wenigen Zeilen Code lösen. Ein Sidecar wäre dann ein eigenes Programm für wenige Zeilen Code. Das Team des Dienstes schreibt diese Zeilen deshalb in den Dienst selbst. Ein zusätzliches Programm, das betrieben und überwacht werden muss, entfällt.
- Alle Dienste sind in derselben Programmiersprache geschrieben, und es ist hinnehmbar, jede neue Fassung einer gemeinsamen Programmbibliothek in jeden Dienst einzubauen. Dass der Sidecar mit Diensten jeder Programmiersprache zusammenarbeitet, bringt dann nichts. Dann binden die Teams eine gemeinsame Programmbibliothek für den Protokollversand in ihre Dienste ein. Eine Programmbibliothek ist fertiger Code, den jeder Dienst einbindet. Ein zusätzliches Programm neben jeder Instanz und die lokale Übergabe über die Protokolldatei entfallen.
- Dienst und Hilfsprogramm müssen sehr häufig Daten austauschen, und jede zusätzliche Verzögerung durch die lokale Übergabe zählt. Dann baut das Team des Dienstes die Hilfsaufgabe direkt in den Dienst ein. Der Dienst erledigt die Hilfsaufgabe innerhalb seines eigenen Programms, ohne Übergabe an ein zweites Programm.
- Die Hilfsaufgabe soll unabhängig von der Zahl der Dienstinstanzen wachsen. Ein Beispiel ist das Verkleinern von Schadenfotos: Nach einem Unwetter kommen viel mehr Fotos herein, obwohl weiter sechs Instanzen des Schadendienstes laufen. Mit Sidecars gäbe es immer genau so viele Exemplare der Hilfsaufgabe wie Instanzen des Schadendienstes. Dann betreibt das Betriebsteam die Hilfsaufgabe als eigenen Dienst, den alle Instanzen über das Netz aufrufen. Von diesem Dienst startet das Betriebsteam so viele Exemplare, wie die Hilfsaufgabe braucht, und nicht eines je Instanz.
- Die Plattform bietet den Protokollversand bereits selbst an. Ein solches Angebot ist ein Programm, das einmal pro Rechner die Protokolle aller Dienste einsammelt. Sidecars würden dieselbe Aufgabe dann noch einmal erledigen. Das Betriebsteam nutzt deshalb dieses Programm der Plattform. Statt eines Sidecars neben jeder Instanz läuft nur ein Programm je Rechner, und Rechenzeit und Arbeitsspeicher für die vielen Sidecars entfallen.
Nachteile und typische Fehler
Jeder Sidecar verbraucht eigene Rechenzeit und eigenen Arbeitsspeicher, und bei Hunderten Dienstinstanzen summiert sich das. Die lokale Übergabe zwischen Dienst und Sidecar bringt eine kleine zusätzliche Verzögerung. Das Betriebsteam muss bewusst entscheiden, ob ein Ausfall des Sidecars den Dienst anhalten soll oder nicht. Außerdem muss das Betriebsteam die Sidecars genauso aktualisieren, überwachen und absichern wie jedes andere Programm. Die lokale Protokolldatei muss mindestens so lange aufbewahrt werden, wie ein Ausfall des Sidecars dauern kann.
Typische Fehler und woran man sie erkennt:
- Unbemerkter Ausfall: Die „Überwachung“ ist nur für den Schadendienst eingerichtet, nicht für den Sidecar. Ein Sidecar stürzt ab, und die „Überwachung“ startet ihn nicht neu. Die Protokollzeilen dieser Instanz fehlen dann im Protokollsystem, ohne dass es jemand bemerkt. Erkennbar ist das an einer Dienstinstanz, von der seit einiger Zeit keine Zeilen mehr ankommen, obwohl sie Schäden bearbeitet.
- Zu kurz aufbewahrte Datei: Die lokale Protokolldatei bewahrt die Zeilen zum Beispiel nur eine Stunde lang auf, ältere Zeilen werden gelöscht. Der Sidecar ist zwei Stunden lang ausgefallen. Nach dem Neustart findet der Sidecar die Zeilen aus der ersten Stunde des Ausfalls nicht mehr. Erkennbar ist das an Lücken im Protokollsystem, die genau der Zeit des Ausfalls entsprechen.
- Falsche Abhängigkeit: Das Betriebsteam richtet die Plattform so ein, dass sie bei einem Absturz des Sidecars auch die Instanz des Schadendienstes daneben anhält, obwohl der Protokollversand für die Bearbeitung von Schäden nicht nötig ist. Ein Absturz des Sidecars hält dann die Schadenbearbeitung dieser Instanz an. Erkennbar ist das an Ausfällen des Schadendienstes, die immer mit einem Absturz des Sidecars beginnen.
- Doppelt gesendete Zeilen: Der Sidecar merkt sich nur in seinem Arbeitsspeicher, bis zu welcher Zeile er gesendet hat. Mit dem Absturz geht diese Angabe verloren, und der neu gestartete Sidecar liest die lokale Protokolldatei wieder von vorn. Dabei sendet der Sidecar auch Zeilen, die er vor dem Absturz schon gesendet hatte. Erkennbar ist das an Protokollzeilen, die im Protokollsystem zweimal mit derselben Zeit erscheinen.
- Veraltete Sidecars: Die Sidecars werden nicht wie andere Programme aktualisiert und enthalten eine bekannte Sicherheitslücke. Weil neben jeder Instanz ein Exemplar desselben Sidecar-Programms läuft, haben alle sechs Exemplare neben den Instanzen des Schadendienstes dieselbe Lücke. Erkennbar ist das an Sidecars, deren Version deutlich älter ist als die der Dienste daneben.
Weiterführend
Verwandte Ansätze
- Ambassador: ein besonderer Sidecar, der für einen Dienst ausgehende Aufrufe an fremde Dienste übernimmt, etwa mit Verschlüsselung und Zeitgrenze.
- Service Mesh: setzt neben jede Instanz aller Dienste einen Sidecar, der die Verbindungen zwischen den Diensten nach einheitlichen Regeln verschlüsselt und misst.
- Observability: beschreibt, welche Angaben Programme über sich selbst schreiben sollen. Ein Sidecar für Protokolle ist ein Mittel, diese Angaben einzusammeln.
- Separation of Concerns: der Grundsatz, verschiedene Aufgaben in verschiedenen Teilen eines Systems zu halten. Der Sidecar trennt die Hilfsaufgabe Protokollversand von der Bearbeitung der Schäden.
Quellen
- Microsoft: Sidecar pattern: Beschreibung im Azure Architecture Center. Hilfsaufgaben wie Protokollierung, Betriebsüberwachung und Einstellungen laufen in einem eigenen Programm neben jeder Instanz der Anwendung. Die Seite nennt den zusätzlichen Aufwand je Instanz, die zusätzliche Verzögerung bei der Übergabe und Fälle, in denen das Muster nicht passt.
- Brendan Burns, David Oppenheimer: Design patterns for container-based distributed systems: Aufsatz vom Workshop HotCloud 2016, der den Sidecar als häufigstes Muster für eng zusammenarbeitende Programme auf einem Rechner beschreibt, mit einem Sidecar, der die Protokolle eines Webservers von der lokalen Festplatte einsammelt.