Der unternehmenskritische Anwendungsfall in der Patientenversorgung, der zu einer Kubernetes-Odyssee wurde

Ausfallzeiten können schwerwiegende Folgen haben.

Für die Unternehmen der Medizintechnik gilt dieses Wort mehr als für die meisten anderen Branchen – hier können die „schweren Folgen“ im wahrsten Sinne des Wortes auch den Tod bedeuten. Wir hatten kürzlich Gelegenheit, den Technologie-Stack eines Unternehmens zu analysieren, das die medizinische Datenaufzeichnung von Stift und Papier auf sichere digitale Daten umstellen möchte, auf die jederzeit und überall auf der Welt zugegriffen werden kann. Diese Daten reichen von Patienteninformationen über Behandlungsanweisungen, biologische Marker, medizinische Analysen, historische Aufzeichnungen und alles andere, was zwischen Gesundheitsteams ausgetauscht wird.

Von Anfang an hat das Unternehmen versucht, eine scheinbar einfache Frage zu beantworten: „Wie können wir Pflegekräften dabei helfen, Daten einfach in Echtzeit aufzuzeichnen?“ Mit dem Wachstum des Unternehmens wurde die Lösung dieser Herausforderung jedoch immer komplexer, da Daten skaliert werden mussten und ständig verfügbar sein mussten. Hier beschreiben wir, wie der technische Werdegang des Unternehmens zur Einführung von Kubernetes und NGINX Ingress Controller geführt hat.

Tech Stack auf einen Blick

• Betriebssystem – Linux
• Container-Orchestrierung – Microsoft Azure Kubernetes Service
• Netzwerk – Kubernetes , NGINX Ingress Controller basierend auf NGINX Plus
• Softwareentwicklungssprache/Framework – .Net 
• Überwachung, Beobachtung und Alarmierung – Prometheus
• Überwachungs-Dashboard – Grafana
• Protokollierung – Grafana Loki
• Datenbank – Azure SQL-Dienst
• Anwendungsserver – Azure App Service , .Net
• Messaging und Streaming – Azure Event Hubs
• Zwischenspeichern – Redis
• Sicherheit – NGINX App Protect
• Standort und Infrastruktur – Zwei Verfügbarkeitszonen, 2 Kubernetes-Cluster, 15–20 Knoten, 60–100 Pods 
• DevOps – Azure DevOps-Dienste

Hier sehen Sie, wo NGINX in ihre Architektur passt:

Das Problem mit Papier

Die regelmäßige Erfassung des Patientenstatus und der Pflegeinformationen ist eine zentrale Aufgabe des medizinischen Personals. Traditionell haben sie Patienteninformationen auf Papier oder in jüngerer Zeit auf Laptops oder Tablets aufgezeichnet. Es gibt ein paar schwerwiegende Nachteile:

• Da Mitarbeiter im Gesundheitswesen täglich mit Dutzenden von Patienten zu tun haben, ist es in der Regel nicht praktikabel, während der Behandlung ausführliche Notizen zu machen. Dies hat zur Folge, dass die Mitarbeiter ihre Notizen erst am Ende ihrer Schicht schreiben. Aufgrund der geistigen und körperlichen Erschöpfung ist man zu diesem Zeitpunkt versucht, nur allgemeine Kommentare aufzuzeichnen.
• Die Mitarbeiter müssen sich außerdem auf ihr Gedächtnis verlassen, wenn es um Einzelheiten des Patientenverhaltens geht. Ungenauigkeiten können Muster verschleiern, die bei korrekter und konsistenter Dokumentation im Laufe der Zeit die Diagnose schwerwiegenderer gesundheitlicher Probleme erleichtern.
• Papierunterlagen können nicht ohne weiteres zwischen Abteilungen einer einzigen Abteilung ausgetauscht werden, ganz zu schweigen von anderen Stellen wie Rettungssanitätern, Mitarbeitern der Notaufnahme und Versicherungsunternehmen. Bei Laptops oder Tablets sieht es kaum besser aus, sofern diese nicht an einen zentralen Datenspeicher oder die Cloud angeschlossen sind.

Um diese Herausforderungen zu bewältigen, hat das Unternehmen ein vereinfachtes Datenaufzeichnungssystem entwickelt, das Schnellzugriffe auf Patienteninformationen und die Aufzeichnung gängiger Ereignisse wie die Abgabe von Medikamenten ermöglicht. Dieser einfache Zugriff und die einfache Nutzung ermöglichen die Aufzeichnung von Patienteninteraktionen in Echtzeit, während sie stattfinden.

Alle Daten werden in vom Unternehmen verwalteten Cloud-Systemen gespeichert und die App lässt sich in andere elektronische Patientenaktensysteme integrieren, um einen umfassenden Längsschnitt durch das Verhalten der Bewohner zu ermöglichen. Dadurch können Pflegekräfte eine bessere Kontinuität in der Pflege gewährleisten, eine sichere Verlaufsaufzeichnung erstellen und die Daten problemlos mit anderen Gesundheitssoftwaresystemen teilen.

Auch Ärzte und andere Fachkräfte nutzen die Plattform bei der Aufnahme oder sonstigen Betreuung von Patienten. Es gibt eine Aufzeichnung der Präferenzen und persönlichen Bedürfnisse, die der Patient in jede Einrichtung mitnimmt. Diese können verwendet werden, um den Patienten dabei zu helfen, sich in einer neuen Umgebung wohl zu fühlen, was zu besseren Ergebnissen, wie beispielsweise einer kürzeren Genesungszeit, führt.

Für die Dauer der Speicherung von Patientendaten durch Unternehmen gelten strenge gesetzliche Vorgaben. Die Entwickler des Unternehmens haben die Software so konzipiert, dass sie eine extrem hohe Verfügbarkeit mit Betriebszeit-SLAs bietet, die viel besser sind als die von generischen Cloud-Anwendungen. Einen Krankenwagen warten zu lassen, weil die Patientenakte nicht geladen werden kann, ist keine Option.

Die Reise von der Garage über die Cloud zu Kubernetes

Wie viele Startups sparte das Unternehmen zunächst Geld, indem es die erste Proof-of-Concept-Anwendung auf einem Server im Haus eines Mitgründers ausführte. Als klar wurde, dass die Idee tragfähig war, verlagerte das Unternehmen seine Infrastruktur in die Cloud, anstatt die Hardware in einem Rechenzentrum zu verwalten. Da es sich um einen Microsoft-Shop handelt, haben sie sich für Azure entschieden. Die ursprüngliche Architektur führte Anwendungen auf herkömmlichen virtuellen Maschinen (VMs) im Azure App Service aus, einem verwalteten Anwendungsbereitstellungsdienst, der den IIS-Webserver von Microsoft betreibt. Für die Datenspeicherung und den Datenabruf entschied sich das Unternehmen für die Verwendung des SQL Servers von Microsoft, der in einer VM als verwaltete Anwendung ausgeführt wird.

Nach mehreren Betriebsjahren in der Cloud wuchs das Unternehmen schnell und hatte mit Skalierungsproblemen zu kämpfen. Es musste unendlich skalierbar sein, und zwar horizontal statt vertikal, da letzteres mit VMs langsam und teuer ist. Diese Anforderung führte ziemlich natürlich zu Containerisierung und Kubernetes als mögliche Lösung. Ein weiteres Argument für die Containerisierung war, dass die Entwickler des Unternehmens häufig Updates für die Anwendung und Infrastruktur bereitstellen müssen, ohne Ausfälle zu riskieren. Da ständig Patientennotizen über mehrere Zeitzonen hinweg hinzugefügt werden, gibt es keine natürlichen Ausfallzeiten, um Änderungen in die Produktion umzusetzen, ohne dass das Risiko besteht, dass Kunden unmittelbar von Störungen betroffen sind.

Ein logischer Ausgangspunkt für das Unternehmen war das verwaltete Kubernetes-Angebot von Microsoft, Azure Kubernetes Services (AKS). Das Team untersuchte die Best Practices von Kubernetes und kam zu dem Schluss, dass es einen Ingress-Controller benötigte, der vor seinen Kubernetes-Clustern ausgeführt wird, um den Datenverkehr und die in Knoten und Pods auf AKS ausgeführten Anwendungen effektiv zu verwalten.

Die Verkehrsführung muss flexibel und dennoch präzise sein

Das Team testete den standardmäßigen Ingress-Controller von AKS, stellte jedoch fest, dass dessen Funktionen zur Verkehrsweiterleitung den Kunden des Unternehmens Updates einfach nicht in der erforderlichen Weise bereitstellen konnten. Wenn es um die Patientenversorgung geht, gibt es keinen Raum für Unklarheiten oder widersprüchliche Informationen – es ist beispielsweise nicht akzeptabel, dass ein Pfleger für dasselbe Ereignis eine orangefarbene Flagge und ein anderer eine rote Flagge sieht. Daher müssen alle Benutzer in einer bestimmten Organisation dieselbe Version der App verwenden. Dies stellt bei Upgrades eine große Herausforderung dar. Da es keinen natürlichen Zeitpunkt gibt, um einen Kunden auf eine neue Version umzustellen, benötigte das Unternehmen eine Möglichkeit, mithilfe von Regeln auf Server- und Netzwerkebene unterschiedliche Kunden auf unterschiedliche App-Versionen umzuleiten.

Um dies zu erreichen, betreibt das Unternehmen für alle Benutzer einer Organisation dieselbe Backend-Plattform und bietet keine Mandantenfähigkeit mit Segmentierung auf der Infrastrukturebene innerhalb der Organisation an. Mit Kubernetes ist es möglich, den Datenverkehr mithilfe virtueller Netzwerkrouten und Cookies in Browsern sowie detaillierter Verkehrsregeln aufzuteilen. Das technische Team des Unternehmens stellte jedoch fest, dass der standardmäßige Ingress-Controller von AKS den Datenverkehr nur prozentual aufteilen kann und nicht mit Regeln, die bei Bedarf auf der Ebene der Kundenorganisation oder des einzelnen Benutzers gelten.

Der auf NGINX Open Source basierende NGINX Ingress Controller weist in seiner Grundkonfiguration dieselbe Einschränkung auf, weshalb sich das Unternehmen für die Umstellung auf den fortschrittlicheren NGINX Ingress Controller auf Basis von NGINX Plus entschieden hat, einem Produkt der Unternehmensklasse, das eine detaillierte Verkehrskontrolle unterstützt. Empfehlungen des NGINX Ingress Controller von Microsoft und der Kubernetes-Community aufgrund des hohen Maßes an Flexibilität und Kontrolle haben bei der Festigung meiner Entscheidung geholfen. Die Konfiguration unterstützt den Bedarf des Unternehmens an Pod-Management (im Gegensatz zum klassischen Verkehrsmanagement) besser und stellt sicher, dass Pods in den entsprechenden Zonen ausgeführt werden und der Verkehr an diese Dienste weitergeleitet wird. Manchmal wird der Datenverkehr intern umgeleitet, in den meisten Anwendungsfällen wird er aus Gründen der Beobachtung jedoch über den NGINX Ingress Controller zurückgeleitet.

Hier sind Drachen: Überwachung, Beobachtbarkeit und Anwendungsleistung

Mit NGINX Ingress Controller hat das technische Team die vollständige Kontrolle über das Entwickler- und Endbenutzererlebnis. Sobald sich Benutzer anmelden und eine Sitzung herstellen, können sie sofort zu einer neuen Version weitergeleitet oder zu einer älteren Version zurückgeführt werden. Patches können gleichzeitig und nahezu augenblicklich an alle Benutzer in einer Organisation gesendet werden. Die Software ist nicht auf DNS-Verbreitung oder Netzwerkaktualisierungen über die Cloud-Plattform angewiesen.

NGINX Ingress Controller erfüllt außerdem die Anforderungen des Unternehmens nach detaillierter und kontinuierlicher Überwachung. Die Anwendungsleistung ist im Gesundheitswesen äußerst wichtig. Latenzen oder Ausfallzeiten können eine erfolgreiche klinische Versorgung beeinträchtigen, insbesondere in Situationen, in denen es um Leben oder Tod geht. Nach der Umstellung auf Kubernetes begannen Kunden von Ausfallzeiten zu berichten, die dem Unternehmen nicht aufgefallen waren. Das Unternehmen entdeckte bald die Ursache des Problems: Azure App Service basiert auf Stichprobendaten. Für Durchschnittswerte und allgemeine Trends ist die Stichprobennahme gut geeignet, aber Dinge wie abgelehnte Anfragen und fehlende Ressourcen werden dabei überhaupt nicht berücksichtigt. Auch die Nutzungsspitzen, die üblicherweise jede halbe Stunde auftreten, wenn Pflegekräfte die Patientendaten einchecken und protokollieren, werden nicht angezeigt. Das Unternehmen erhielt nur ein unvollständiges Bild hinsichtlich Latenz, Fehlerquellen, fehlerhaften Anfragen und nicht verfügbarem Service.

Doch damit waren die Probleme noch nicht vorbei. Standardmäßig bewahrt Azure App Service gespeicherte Daten nur einen Monat lang auf – weit weniger als die Dutzende von Jahren, die in vielen Ländern gesetzlich vorgeschrieben sind.  Die für eine längere Aufbewahrung erforderliche Erweiterung des Datenspeichers wäre unerschwinglich teuer gewesen. Darüber hinaus kann die Azure-Lösung nicht in den Kubernetes-Netzwerkstapel sehen. NGINX Ingress Controller kann sowohl Infrastruktur- als auch Anwendungsparameter überwachen, da er Datenverkehr auf Layer 4 und Layer 7 verarbeitet.

Zur Leistungsüberwachung und -beobachtung entschied sich das Unternehmen für eine Prometheus-Zeitreihendatenbank, die an eine Grafana-Visualisierungs-Engine und ein Dashboard angeschlossen ist. Die Integration mit Prometheus und Grafana ist in die NGINX-Daten- und -Steuerungsebene vorinstalliert; das technische Team musste nur eine kleine Konfigurationsänderung vornehmen, um den gesamten Datenverkehr über die Prometheus- und Grafana-Server zu leiten. Die Informationen wurden außerdem in eine Grafana Loki-Protokollierungsdatenbank weitergeleitet, um die Protokollanalyse zu vereinfachen und dem Softwareteam im Zeitverlauf mehr Kontrolle über die Daten zu geben. 

Diese Konfiguration bietet außerdem Zukunftssicherheit gegenüber Vorfällen, die eine extrem häufige und umfangreiche Datenerfassung zur Fehlersuche und -behebung erfordern. Die Behebung dieser Art von Vorfällen könnte mit den Anwendungsüberwachungssystemen der meisten großen Cloud-Unternehmen kostspielig sein, aber die Kosten und der Aufwand von Prometheus, Grafana und Loki sind in diesem Anwendungsfall minimal. Bei allen dreien handelt es sich um stabile Open-Source-Produkte, die nach der ersten Feinabstimmung im Allgemeinen kaum mehr als ein paar Patches erfordern.

Bleiben Sie auf Kurs: Hohe Verfügbarkeit und Sicherheit im Fokus

Das Unternehmen hat seinen Schwerpunkt schon immer auf die Sicherheit gelegt, um einen der sensibelsten Datentypen überhaupt zu schützen, und auf hohe Verfügbarkeit , um sicherzustellen, dass die App jederzeit verfügbar ist, wenn sie benötigt wird. Bei der Umstellung auf Kubernetes haben sie einige Änderungen vorgenommen, um beide Kapazitäten zu erweitern.

Um höchste Verfügbarkeit zu erreichen, setzt das technische Team ein Active-Active-, Multizonen- und Multi-Geo-Design einer verteilten Infrastruktur ein, um eine vollständige Redundanz ohne einzelne Ausfallpunkte zu gewährleisten. Das Team unterhält eine N+2-Aktiv-Aktiv-Infrastruktur mit zwei Kubernetes-Clustern in zwei verschiedenen Regionen. In jeder Region erstreckt sich die Software über mehrere Rechenzentren, um das Ausfallrisiko zu verringern und Schutz für den Fall von Fehlern auf jeder Ebene der Infrastruktur zu bieten. Mithilfe von Affinitäts- und Anti-Affinitätsregeln können Benutzer und Datenverkehr sofort auf aktive Pods umgeleitet werden, um Dienstunterbrechungen zu verhindern. 

Aus Sicherheitsgründen setzt das Team eine Web Application Firewall (WAF) ein, um sich vor fehlerhaften Anfragen und böswilligen Akteuren zu schützen. Der Schutz vor den OWASP Top 10 gehört bei den meisten WAFs zum Grundsatz. Während der Erstellung der App untersuchte das Team eine Reihe von WAFs, darunter das native Azure WAF und ModSecurity. Am Ende entschied sich das Team für NGINX App Protect mit seinem Inline-WAF und Distributed-Denial-of-Service- Schutz (DDoS).

Ein großer Vorteil von NGINX App Protect ist die Zusammenlegung mit dem NGINX Ingress Controller, wodurch sowohl eine Redundanzstelle eliminiert als auch die Latenz reduziert wird. Andere WAFs müssen außerhalb der Kubernetes-Umgebung platziert werden, was zu Latenz und Kosten beiträgt. Selbst winzige Verzögerungen (sagen wir 1 Millisekunde zusätzlich pro Anfrage) summieren sich mit der Zeit schnell.

Überraschungs-Nebenquest: Keine Ausfallzeiten für Entwickler

Nachdem die Umstellung auf AKS für den Großteil seiner Anwendungs- und Netzwerkinfrastruktur abgeschlossen ist, konnte das Unternehmen auch seine Entwicklererfahrung (DevEx) deutlich verbessern. Heutzutage erkennen Entwickler Probleme fast immer, bevor den Kunden selbst welche auffallen. Seit der Umstellung ist die Anzahl der Supportanrufe wegen Fehlern um ca. 80 % zurückgegangen!

Die Sicherheits- und Anwendungsleistungsteams des Unternehmens verfügen über ein detailliertes Grafana-Dashboard und einheitliche Warnmeldungen. Dadurch entfällt die Notwendigkeit, mehrere Systeme zu prüfen oder Auslöser für Warntexte und Anrufe aus verschiedenen Prozessen zu implementieren. Die Entwicklungs- und DevOps-Teams können jetzt täglich oder sogar mehrmals täglich Code- und Infrastrukturupdates ausliefern und äußerst granulare Blue-Green-Muster verwenden. Früher lieferten sie ein- oder zweimal pro Woche Updates und mussten dafür Zeitfenster mit geringer Auslastung wählen, was eine stressige Angelegenheit war. Jetzt wird der Code ausgeliefert, wenn er fertig ist, und die Entwickler können die Auswirkungen direkt überwachen, indem sie das Anwendungsverhalten beobachten.

Die Ergebnisse sind durchweg positiv: eine Steigerung der Softwareentwicklungsgeschwindigkeit, eine Verbesserung der Entwicklermoral und mehr gerettete Leben.