Fehlerhafte Orchestration Layers und Ausfall der Selbstheilungskräfte von Microservice-Strukturen

Fehlerhafter Orchestration Layer: Was tun, wenn das Microservice-Immunsystem ausfällt?
Kommentare

Microservices boomen nicht umsonst, aber ihre Wartung ist mitunter aufwändiger als die monolithischer Systeme. Das macht sie für gelegentliche Verschnupfungen anfällig. Im Bezug auf den Orchestration Layer haben sich in einer Umfrage nun zwei Probleme herauskristallisiert, die nicht unbedingt alltäglich sind, aber Beachtung verdienen.

Die Umfrage wurde von der Firma Dynatrace, die virtuelle Monitoring-Assistenten vertreibt, unter ihren Usern durchgeführt. Zwei interessante Tatsachen sind dem Team dabei zurückgemeldet worden, wie Martin Goodwell auf dem Blog der Firma schreibt. Sie betreffen mit dem Orchestration-Layer ein Tool, das für das Management immer komplexerer und weiter ausufernder Microservice-Strukturen notwendig geworden ist. Es dient der besseren Steuerbarkeit verteilter Systeme, vor allem durch Automatisierungsfunktionen und sogenannte Selbstheilungsfähigkeiten. Daniel Jacobson, der Director of Engineering des Microservices-Vorreiters Netflix, beschreibt den Orchestration Layer folgendermaßen:

An API Orchestration Layer (OL) is an abstraction layer that takes generically-modeled data elements and/or features and prepares them in a more specific way for a targeted developer or application.

Automatisierung

Jedoch besteht über die Erfordernis des Orchestration Layers anscheinend nicht allzu große Einigkeit, denn das erste Ergebnis der Umfrage lautet, dass viele Microservices-Nutzer überhaupt keinen Orchestration-Layer verwenden. Dementsprechend geraten schon bei geringen Komplexitäten die Dinge außer Kontrolle. Unnötigerweise, muss man sagen, denn mit Netflix OSS steht ein hochwertiges Open-Source-Toolset zur Verfügung, das noch dazu durch zahlreiche Tools und Libraries ergänzt werden kann. Diese sparen durch Automatisierung Zeit und Kosten, sollte ein Service nicht zu erreichen sein.

Eine Service Registry etwa sorgt dafür, dass sich Microservices beim Start registrieren müssen. Klienten können so schon dem Aufrufen des Services klären, ob dieser überhaupt verfügbar ist. Nicht verfügbare Services werden dergestalt gar nicht erst angewählt.

Circuit Breaker dagegen überwachen den Status der Endpoints, um teure Request Timeouts im Falle eines unverfügbaren Endpoints zu vermeiden. Sie sollen ähnlich einer Überstromschutzeinrichtung die Verbindung zum nicht erreichbaren Endpoint abbrechen – daher der Name – und diesen als gegenwärtig nicht verfügbar ausweisen. Im weiteren Verlauf wird der Service regelmäßig angefragt, um seinen Status zu eruieren.

DevOps Docker Camp

Das neue DevOps Docker Camp mit Erkan Yanar

Lernen Sie die Konzepte von Docker und die darauf aufbauenden Infrastrukturen umfassend kennen. Bauen Sie Schritt für Schritt eine eigene Infrastruktur für und mit Docker auf!

Orchestration Layer erschwert Fehlerbehandlung?

Der Orchestration Layer soll eigentlich dazu dienen, Systeme resilienter zu machen, d.h. sie in die Lage zu versetzen, sich bei Problemen selbst zu helfen und dadurch eventuelle sogar stärker zu werden. Die Umfrage des Dynatrace-Teams ergab nun, dass einige der Befragten paradoxerweise mit Ausfällen des Orchestration Layers zu kämpfen hatten. Auch wenn im Artikel dann wie üblich begonnen wird, das eigene Produkt anzupreisen, ist das aufgeworfene Problem doch diskutierenswert.

Denn schließlich ist der Orchestration Layer ja gerade mit der Behebung von Fehlern und Ausschaltung von Fehlerquellen beauftragt. Viele ITler werden deshalb geneigt sein, zuerst ihre eigenen Services zu überprüfen, bevor sie irgendwann auf das eigentliche Problem stoßen. Bis dahin ist aber schon jede Menge wertvolle Zeit verschwendet worden, da niemand ein Tool verdächtigt, das ausgerechnet dem Troubleshooting dient und außerdem im Ruf steht, selten auszufallen. Insofern kann man sich der Schlussfolgerung Goodwells durchaus anschließen:

The lessons we gleaned from our customers’ experiences leads us to the conclusion that monitoring of the orchestration layer should be an integral feature of all full-stack monitoring tools. Service registries, circuit breakers, and other orchestration tools should be part of all newly created environments, as should database connection pools and messaging queues.

Fazit

Manchmal ist der Täter doch derjenige, von dem man es am wenigsten erwartet. Man wird sich also Mittel und Wege überlegen müssen, die Überwachung des Überwachers in den regulären Workflow der Fehlerbereinigung zu integrieren. Monitoring kann da nur der Anfang sein.

Aufmacherbild: Anton_Ivanov / Shutterstock.com

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -