© GreenFlash/Shutterstock.com
Teil 2: Infrastrukturen und Organisation

Alles verändert sich


Im ersten Teil dieser Serie haben wir ein Projekt vorgestellt, das ein Antragsverfahren für Bürger beinhaltet, und die Gründe für die Architekturentscheidungen für Microservices und Workflow-Engine beschrieben. Diesmal stellen wir die im Rahmen des Projekts verwendete bzw. entstandene Infrastruktur vor und beleuchten organisatorische Aspekte.

Die Architektur des Gesamtsystems ist in Abbildung 1 zu sehen. Am linken und rechten Rand befinden sich einige querschnittliche Komponenten (Cross-cutting Concerns), die in einem verteilten System eine wichtige Rolle spielen. Dabei geht es zum einen um Möglichkeiten der Überwachung der einzelnen Teilsysteme, zum anderen vor allem um Sicherheitsaspekte. Das hier vorgestellte Produkt hat eine Onlineantragsmöglichkeit, sodass die Sicherheit der Anwendungen im Internet sowie der darüber bereitgestellten Daten (Stichwort Verschlüsselung) eine sehr hohe Priorität besitzt. Des Weiteren ist ein einheitliches Vorgehen zur Authentifizierung und Autorisierung für das Gesamtsystem sicherzustellen. Das hier vorgestellte System wird im Übrigen vollständig On Premise betrieben.

kaps_architekturen_2_1.tif_fmt1.jpgAbb. 1: Die Architektur des Gesamtsystems

Die Infrastruktur

Klassische Webanwendungen werden bei uns aktuell noch in Wildfly-Application-Servern betrieben. Das funktioniert sehr gut und das notwendige Know-how ist bei den Entwicklern vorhanden. Allerdings kommt es mit zunehmender Anzahl von Anwendungen zu einem Konflikt mit einem eher klassisch aufgestellten IT-Betrieb. Es ist diesem nicht zumutbar, für jede einzelne Anwendung eine eigene virtuelle Maschine mit einem eigenen Application-Server zu betreiben. Abgesehen von der Tatsache, dass das zu einer Ressourcenverschwendung führen würde, müsste eine dreistellige Zahl an Servern betreut werden. Es wird versucht, dem entgegenzuwirken, indem in Zukunft mehr Anwendungen mit Hilfe von Containern deployt werden. Neben den neuesten Sternen wie Quarkus oder Micronaut geht alternativ die Entwicklung des Wildfly durch die Einführung von Galleon [1] auch mehr in die Cloud-native-Richtung und ermöglicht es dadurch, einen schlanken Application-Server einfacher in Containern betreiben zu können.

Containermanagement

Da mit der Zeit die Zahl der Container in den diversen Umgebungen stark gestiegen ist, wächst der Bedarf an einer einfachen Möglichkeit, diese managen zu können.

Das Werkzeug Portainer [2] bietet eine aufgeräumte Oberfläche für die Verwaltung und das Management von Containerumgebungen. Es können diverse Hosts sowie Registries angebunden, laufende Container gestartet, gestoppt, überwacht und analysiert werden. Portainer lässt sich sehr einfach in Betrieb nehmen und bietet sowohl für Entwickler als auch für den Betrieb nützliche Funktionen. Container können auch manuell gepullt, gebaut, Netzwerke, Volumes und Images verwaltet werden. Es wird ebenso der Docker Swarm Mode unterstützt, also das Betreiben diverser Nodes als Cluster.

Observability

Unter Observability versteht man die Möglichkeiten der Überwachung und Beobachtung des Verhaltens von Software, das in die Bereiche Logging, Monitoring/Metriken und Tracing unterteilt wird und für verteilte Systeme enorm wichtig ist.

Logging

Die Herausforderung des Logmanagements in verteilten Architekturen ist seit Langem gelöst. Lösungen wie der Elastic Stack [3] ermöglichen es, sämtliche Lognachrichten aus diversen Services, ob nun betrieben in einem Container oder in einem Application-Server, an eine zentrale Stelle zu übermitteln, wo sie aufbereitet, zerlegt, indiziert und ausgewertet werden können.

Beim Elastic Stack sammeln sogenannte File-Beats die Logdateien ein und senden den Inhalt zeilenweise, wenn gewünscht vorselektiert (z. B. nach bestimmten Loglevels), an eine oder mehrere Logstash-Instanzen. Diese wiederum verarbeiten den Input, wenden Filter an (z. B. in Form von Grok-Patterns), um die Inhalte der Meldung zu identifizieren und um im Anschluss die Ergebnisse in Elasticsearch zu persistieren. In der in diesem Projekt verwendeten Infrastruktur wurde darüber hinaus eine Redis-Datenbank verwendet, um diese Pipelines mit Puffern zu versehen. Dadurch kann verhindert werden, dass das zentrale Logmanagementsystem zusammenbricht, wenn ein Server massiv viele Meldungen in sehr kurzer Zeit erzeugt. Als Visualisierung und Auswertungswerkzeug hält der Elastic Stack Kibana bereit. Dort können Abfragen erstellt und mit visuellen Komponenten angereichert auf Dashboards dargestellt werden. Bei aufgetretenen Error-Meldungen in Produktion lassen wir uns zudem auf einem separaten Kanal in unserem Chat-Tool benachrichtigen.

Monitoring

Beim Monitoring geht es meist um die Überwachung von Systemressourcen wie CPU oder Speicher. Häufig existieren jedoch auch fachliche Anforderungen, Metriken zu sammeln, um das Verfahren steuern zu können. In diesem Projekt werden Metriken gesammelt – zu der Anzahl an Bescheiden je Art, Anzahl der Nachforderungsgründe je Art oder der Anzahl der Aussteuerungsgründe (Sonderfälle) je Art. Die letztgenannte Metrik unterstützt bei der Entscheidung, für welche Fallkonstellationen sich eine programmtechnische Umsetzung auf Grund der Menge der Fälle lohnt und für welche nicht, da es sich um Einzelfälle handelt.

Die Werkzeuge, die in diesem Projekt eingesetzt wurden, sind Prometheus [4] und Grafana [5]. Die eigenen Anwendungen und Services bieten spezielle Endpunkte an (/metrics), die von Prometheus abgefragt und persistiert werden, um im Anschluss in eigens konfigurierten Dashboards in Grafana visuell ansprechend dargestellt zu werden.

Zusätzlich bieten alle Anwendungen Endpunkte an, um den Gesundheitszustand der jeweiligen Komponenten überwachen zu können, entweder über die Integration von Dropwizard Metrics oder in Spring Boot über Actuator. Bei den über Consul [6] registrierten Services (Abb. 2) ist der Health-Status direkt in Consul ersichtlich. Es könnte alternativ Spring Boot Admin eingesetzt werden, sollte keine Service Registry mit ähnlicher Funktionalität im Einsatz sein.

kaps_architekturen_2_2.tif_fmt1.jpgAbb. 2: Übersicht der Services in Consul

Tracing

Beim Tracing geht es darum, einen Request von seinem Ursprung bis zum Ende verfolgen zu können. Das ist absolut sinnvoll und notwendig, wenn ein Request mehrere Servic...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang