Ambassador: Stellvertreter für ausgehende Aufrufe

Integration

Ambassador

Stellvertreter für ausgehende Aufrufe

Die Idee und ihr Nutzen

Das Beitragsprogramm einer Versicherung ist zwanzig Jahre alt und fragt für jede Beitragsberechnung bei einem externen Wetterdienst das Hagelrisiko ab. Die Sicherheitsvorgaben der Versicherung verlangen inzwischen eine verschlüsselte Verbindung zum Wetterdienst, doch das Beitragsprogramm beherrscht keine Verschlüsselung und wartet unbegrenzt, wenn der Wetterdienst nicht antwortet. Ein kleines Hilfsprogramm auf dem Rechner des Beitragsprogramms übernimmt deshalb den Aufruf: Das Beitragsprogramm fragt nur noch das Hilfsprogramm. Das Hilfsprogramm stellt die verschlüsselte Verbindung zum Wetterdienst her, bricht das Warten nach einer festen Zeit ab und meldet dem Beitragsprogramm dann einen Fehler. Ein solches Hilfsprogramm, das ein Programm bei seinen ausgehenden Aufrufen vertritt, heißt Ambassador, englisch für Botschafter.

Bausteine: Beitragsprogramm: altes Programm, berechnet Beiträge; Ambassador: misst Dauer und Fehler jedes Aufrufs; Wetterdienst: liefert das Hagelrisiko. Verbindungen: Beitragsprogramm — Ambassador (unverschlüsselt); Ambassador — Wetterdienst (verschlüsselt, mit Zeitgrenze). Das Beitragsprogramm fragt nur den Ambassador; er stellt die verschlüsselte Verbindung zum Wetterdienst her.

Wie funktioniert es?

Das Beitragsprogramm berechnet den Beitrag für ein Angebot einer Wohngebäudeversicherung in einer Region mit häufigem Hagel und braucht dafür das aktuelle Hagelrisiko. Das Beitragsprogramm schickt die Frage nach dem Hagelrisiko an localhost:9000, die Adresse des Ambassadors auf demselben Rechner. localhost bezeichnet immer den eigenen Rechner. Diese Anfrage verlässt den Rechner also nicht und muss deshalb nicht verschlüsselt werden. Der Ambassador baut eine verschlüsselte Verbindung zum Wetterdienst auf und leitet die Anfrage weiter. Für die Verschlüsselung nutzt der Ambassador TLS, das Verfahren, das auch Webbrowser für Adressen mit https verwenden. Die Verschlüsselung verhindert, dass jemand unterwegs zwischen Ambassador und Wetterdienst die Daten mitliest oder verändert. Der Ambassador wartet höchstens zwei Sekunden auf die Antwort. Der Wetterdienst antwortet sonst in weniger als einer halben Sekunde; zwei Sekunden lassen ihm Spielraum, ohne dass die Beitragsberechnung lange aufgehalten wird. Eine solche Höchstdauer, nach der ein Programm das Warten auf eine Antwort abbricht, heißt Zeitgrenze. Im Normalfall antwortet der Wetterdienst rechtzeitig mit „Hagelrisiko: hoch“, und der Ambassador gibt die Antwort an das Beitragsprogramm weiter, das damit den Beitrag berechnet. An einem Nachmittag ist der Wetterdienst überlastet und antwortet nicht. Nach zwei Sekunden bricht der Ambassador den Versuch ab und meldet dem Beitragsprogramm „Fehler: Wetterdienst nicht erreichbar“. Das Beitragsprogramm hängt nicht fest, sondern markiert das Angebot zur späteren Prüfung. Zum Schluss schickt der Ambassador die Messwerte „Dauer 2 s, Aufruf gescheitert“ an die Betriebsüberwachung, die dem Betriebsteam Dauer und Ergebnis der Aufrufe anzeigt. Daran sieht das Betriebsteam, dass der Wetterdienst gerade nicht antwortet.

Für die Berechnung des Beitrags bleibt das Beitragsprogramm zuständig. Das Beitragsprogramm entscheidet auch selbst, was es nach einem gemeldeten Fehler tut. Welche Zeitgrenze gilt und welche Adresse der Wetterdienst hat, steht in einer Einstellungsdatei des Ambassadors. Ändert sich die Adresse des Wetterdienstes, passt das Betriebsteam die Einstellungsdatei des Ambassadors an und nicht den Code des Beitragsprogramms. Eingeführt hat das Betriebsteam den Ambassador ebenfalls ohne Änderung am Code des Beitragsprogramms: Das Betriebsteam hat den Ambassador auf dem Rechner des Beitragsprogramms installiert und in der Einstellungsdatei des Beitragsprogramms die Zieladresse von der Adresse des Wetterdienstes auf localhost:9000 geändert. Der Wetterdienst gehört einem anderen Unternehmen. Die Versicherung kann am Wetterdienst nichts ändern und weiß nicht, wann er überlastet ist. Ausfälle des Wetterdienstes verhindert der Ambassador nicht. Der Ambassador sorgt nur dafür, dass das Beitragsprogramm einen Ausfall schneller bemerkt und darauf reagieren kann.

Statt das Angebot zur späteren Prüfung zu markieren, könnte das Beitragsprogramm nach einem gemeldeten Fehler auch mit einem hinterlegten Standardwert weiterrechnen. Einen gescheiterten Aufruf könnte der Ambassador auch wiederholen. Das darf der Ambassador nur, wenn eine Wiederholung keinen Schaden anrichtet. Die Abfrage des Hagelrisikos lässt sich gefahrlos wiederholen. Einen Auftrag, der beim Empfänger etwas auslöst, etwa eine Zahlung, darf der Ambassador dagegen nicht ohne weitere Absicherung wiederholen.

Beteiligte: Beitragsprogramm: berechnet den Wohngebäudebeitrag, altes Programm; Ambassador: läuft auf demselben Rechner: verschlüsselt, begrenzt Wartezeit, misst; Wetterdienst: liefert das Hagelrisiko; Betriebsüberwachung: zeigt Dauer und Fehler der Aufrufe. Ablauf: 1. Das Beitragsprogramm schickt die Frage nach dem Hagelrisiko an den Ambassador auf demselben Rechner. Diese Anfrage verlässt den Rechner nicht. 2. Der Ambassador baut eine verschlüsselte Verbindung zum Wetterdienst auf und leitet die Anfrage weiter. 3. Der Wetterdienst antwortet innerhalb von zwei Sekunden mit „Hagelrisiko: hoch“. 4. Der Ambassador gibt die Antwort „Hagelrisiko: hoch“ an das Beitragsprogramm weiter, das damit den Beitrag berechnet. 5. An einem Nachmittag ist der Wetterdienst überlastet und antwortet nicht. Nach zwei Sekunden bricht der Ambassador den Versuch ab. 6. Der Ambassador meldet dem Beitragsprogramm „Fehler: Wetterdienst nicht erreichbar“. Das Beitragsprogramm hängt nicht fest, sondern markiert das Angebot zur späteren Prüfung. 7. Der Ambassador meldet der Betriebsüberwachung Dauer und Ergebnis jedes Aufrufs, hier „Dauer 2 s, Aufruf gescheitert“. Das Betriebsteam sieht so, dass der Wetterdienst gerade nicht antwortet.

Wann ist es sinnvoll und wann nicht?

Ein Ambassador lohnt sich

Ein Altsystem soll verschlüsselte Verbindungen mit begrenzter Wartezeit nach außen bekommen, aber seinen Code wollen die Entwickler nicht ändern. Niemand kennt den alten Code mehr gut, und jede Änderung müsste aufwendig getestet werden.
Programme in verschiedenen Programmiersprachen sollen dieselben Regeln für ausgehende Aufrufe bekommen. Die Sicherheitsvorgaben gelten für alle Programme der Versicherung, unabhängig von der Programmiersprache. Baut jedes Team Verschlüsselung, Zeitgrenzen und Messung selbst ein, entstehen viele leicht verschiedene Umsetzungen, die alle einzeln gepflegt werden müssen. Neben jedem Programm läuft dann ein eigenes Exemplar desselben Ambassadors. Weil jedes Programm den Ambassador nur über localhost aufruft, spielt seine Programmiersprache keine Rolle. Alle Exemplare arbeiten nach denselben Regeln für Verschlüsselung, Zeitgrenzen und Messung, die das Betriebsteam festlegt.
Das Betriebsteam braucht Messwerte zu Dauer und Ergebnis der Aufrufe eines Programms, das selbst keine solchen Messwerte liefert.

Ein Ambassador ist nicht das Richtige

Die Zieladresse steht fest im Code des alten Programms. Dann lassen sich die Anfragen nicht zum Ambassador umlenken, ohne den Code doch zu ändern.
Nur ein einziges Programm braucht Verschlüsselung, Zeitgrenze und Messung, und sein Team kann den Code ändern. Dann baut das Team diese Aufgaben direkt in das Programm ein, meist mit einer Programmbibliothek, also fertigem Code eines anderen Herstellers, den das Programm einbindet. Ein zusätzliches Programm, das installiert, überwacht und mit Sicherheitsupdates versorgt werden muss, entfällt.
Jede Millisekunde zählt. Dann ist auch der kurze Umweg über einen Ambassador auf demselben Rechner zu lang.
Die Versicherung betreibt viele Dienste auf einer gemeinsamen Plattform. Dafür gibt es das Service Mesh, das allen Diensten solche Hilfsprogramme bereitstellt und ihre Einstellungen zentral verwaltet. Kein Team muss dann einen eigenen Ambassador einrichten. Manche Bauformen eines Service Mesh kommen sogar ohne ein Hilfsprogramm neben jedem Dienst aus.
Es soll nur festgelegt werden, welche Ziele im Internet die Rechner eines Netzes erreichen dürfen. Dafür genügt ein gemeinsamer Forward Proxy, der die ausgehenden Anfragen aller Rechner eines Netzes vermittelt, statt neben einem einzelnen Programm zu laufen.

Nachteile und typische Fehler

Ein weiteres Programm muss installiert, überwacht und mit Sicherheitsupdates versorgt werden. Das Beitragsprogramm hängt danach nicht nur vom Wetterdienst ab, sondern auch davon, dass der Ambassador auf seinem Rechner läuft. Jeder Aufruf dauert durch den Umweg über den Ambassador etwas länger. Die Fehlersuche wird schwieriger, weil ein Teil des Verhaltens nicht im Code des Beitragsprogramms steht, sondern in der Einstellungsdatei des Ambassadors. Die Zeitgrenze zum Beispiel steht nur in der Einstellungsdatei. Wer ein Problem untersucht, muss deshalb den Code des Beitragsprogramms und die Einstellungen des Ambassadors kennen.

Typische Fehler und woran man sie erkennt:

Ambassador ausgefallen: Der Ambassador fällt aus. Das Beitragsprogramm erreicht dann den Wetterdienst nicht mehr, obwohl das Beitragsprogramm selbst und der Wetterdienst laufen. Erkennbar ist das an abgewiesenen Verbindungen zu localhost:9000, während andere Programme den Wetterdienst erreichen.
Doppelte Wiederholungen: Der Ambassador meldet dem Beitragsprogramm einen Fehler. Das Beitragsprogramm schickt dieselbe Anfrage daraufhin von sich aus noch zweimal an den Ambassador. Der Ambassador wiederholt außerdem jede gescheiterte Anfrage selbst zweimal beim Wetterdienst. Aus einer Frage des Beitragsprogramms werden so bis zu neun Anfragen an den ohnehin überlasteten Wetterdienst. Wiederholungen dürfen deshalb nur an einer Stelle festgelegt sein, im Beitragsprogramm oder im Ambassador. Erkennbar ist das an deutlich mehr Anfragen beim Wetterdienst, als das Beitragsprogramm Beiträge berechnet.
Wiederholter Auftrag: Der Ambassador wiederholt einen Auftrag, der beim Empfänger etwas auslöst, etwa eine Zahlung, und der Empfänger führt den Auftrag zweimal aus. Erkennbar ist das an doppelten Buchungen nach Zeitüberschreitungen.
Zu knappe Zeitgrenze: Die Zeitgrenze in der Einstellungsdatei ist kürzer als die übliche Antwortzeit des Wetterdienstes. Der Ambassador bricht dann auch Aufrufe ab, die gelungen wären. Erkennbar ist das an vielen gescheiterten Aufrufen mit einer Dauer von genau zwei Sekunden, obwohl der Wetterdienst keine Störung meldet.
Übersehener Direktaufruf: Ein Programmteil des Beitragsprogramms ruft den Wetterdienst weiterhin direkt auf, weil seine Zieladresse nicht umgestellt wurde. Diese Anfragen bleiben unverschlüsselt und ohne Zeitgrenze. Erkennbar ist das an Verbindungen vom Rechner des Beitragsprogramms zum Wetterdienst, die nicht vom Ambassador stammen.

Weiterführend

Werkzeuge und Umsetzungen

Envoy: ein Proxy, also ein Programm, das Verbindungen stellvertretend annimmt und weiterleitet. Envoy kann als Ambassador neben einem Programm laufen und Verschlüsselung, Zeitgrenzen, Wiederholungen und Messwerte übernehmen.
Dapr: ein Hilfsprogramm, das neben einem Dienst läuft und ihm über eine lokale Schnittstelle Aufrufe anderer Dienste, das Versenden von Nachrichten und das Speichern von Daten anbietet. Für diese Aufrufe lassen sich Zeitgrenzen und Wiederholungen einstellen.
HAProxy: ein weit verbreiteter Proxy, der sich auch als lokaler Stellvertreter für ausgehende Verbindungen einsetzen lässt und dabei Verbindungen verschlüsseln und Zeitgrenzen setzen kann.

Quellen

Microsoft: Ambassador pattern: beschreibt das Muster mit Altsystemen als typischem Einsatzfall, nennt die zusätzliche Wartezeit als Grenze und warnt vor Wiederholungen bei Aufträgen, die nicht gefahrlos wiederholt werden können.
Brendan Burns, David Oppenheimer: Design Patterns for Container-based Distributed Systems: Aufsatz von 2016, der den Ambassador als Hilfsprogramm beschreibt, das die Verbindungen eines Hauptprogramms stellvertretend übernimmt.