--- { "title": "Erste Schritte, um Ihre FHIR-basierte Lösung produktionsreif zu machen", "description": "Grundlegende Tipps für den Aufbau hochverfügbarer FHIR-Systeme in einer Cloud-Infrastruktur. Hier erfahren Sie, wie Sie eine produktionsreife und zuverlässige FHIR-Lösung in der Cloud entwickeln.", "date": "2022-09-22", "author": "Mike Ryzhikov", "reading-time": "6 min read", "tags": [ "Infrastructure", "System Design" ], "seo-tags": [ "fhir", "fhir in production", "high-availability", "FHIR in cloud", "reliable FHIR server", "high-availability FHIR backend", "HIPAA", "infrastructure" ] } --- Eine gut konzipierte Produktionsinfrastruktur ermöglicht es Ihrem Entwicklungsteam, nachts zu schlafen und das Wochenende entspannt zu verbringen, während Ihre Nutzer rund um die Uhr von Ihrer Anwendung profitieren. Bevor Sie Ihre FHIR-basierte Anwendung in den Produktionsbetrieb überführen, sollten Sie daher unbedingt zwei kritische Risiken berücksichtigen und minimieren: - Datenverlust - Systemausfallzeiten Diese Tipps helfen Ihnen, eine produktionsreife und zuverlässige FHIR-Lösung in der Cloud zu entwickeln. Der Einfachheit halber lassen wir die Themen Sicherheit, Netzwerke und Monitoring bewusst außen vor und konzentrieren uns stattdessen auf die Grundlagen für den weiteren Fortschritt. ## Kein Single Point of Failure! Die Infrastrukturplanung beginnt mit der Wahl der richtigen Prinzipien. Das wichtigste Prinzip beim Aufbau hochverfügbarer Systeme lautet: kein Single Point of Failure. Einfach ausgedrückt müssen Sie die Schlüsselkomponenten des Systems duplizieren, d. h. redundant auslegen. Eine grundlegende FHIR-Lösung umfasst zwei Schlüsselkomponenten, die dupliziert werden sollten: - Anwendung(en) – Aidbox [FHIR-Backend](/articles/using-fhir-to-simplify-healthcare-application-development) - Datenbank(en) – PostgreSQL Wenn Sie weitere Schlüsselkomponenten haben, können Sie dieses Prinzip auf dieselbe Weise auf alle anwenden. ![Typical FHIR solution](image-1.avif) Anwendungen und Datenbanken erfordern bei der Duplizierung unterschiedliche Ansätze und Technologien. Lassen Sie uns nacheinander betrachten, wie damit umzugehen ist. ## Keine Systemausfallzeiten. Duplizieren Sie Ihren FHIR-Server und betreiben Sie ihn parallel Um einen Single Point of Failure auf der Anwendungsebene zu vermeiden, benötigen Sie zwei oder mehr Instanzen des FHIR-Servers/Backends, die Anfragen parallel verarbeiten. Außerdem benötigen Sie einen Mechanismus, der Ihre Anwendungen überwacht, neu startet und den Datenverkehr umverteilt, falls diese ausfallen. Die konkrete Implementierung hängt von Ihrer gewählten Cloud und den verfügbaren Diensten ab. Heutzutage bieten öffentliche Clouds viele Optionen – wählen Sie daher sorgfältig entsprechend Ihrem Budget und dem gewünschten Maß an Kontrolle. Wir empfehlen ausdrücklich, den verwalteten Kubernetes-Dienst (K8s) in Betracht zu ziehen: [EKS in AWS](https://aws.amazon.com/eks/), [GKE in GCP](https://cloud.google.com/kubernetes-engine/) und [AKS in Azure](https://azure.microsoft.com/en-us/products/kubernetes-service/). Aus unserer Sicht ist dies ein optimales Preis-Leistungs-Verhältnis. Wenn Sie Ihre containerisierten Anwendungen innerhalb des Kubernetes-Clusters betreiben, übernimmt K8s folgende Aufgaben: - Neustart von fehlgeschlagenen Containern - Ersetzen von Containern - Beenden von Containern, die nicht auf Ihren benutzerdefinierten Health-Check reagieren - Weiterleitung von Datenverkehr erst dann, wenn die Container bereit sind Dieser Prozess wird als [Self-Healing](https://kubernetes.io/docs/concepts/overview/#why-you-need-kubernetes-and-what-can-it-do) bezeichnet. ![High-availability and reliable FHIR server](image-2.avif) Um diese Kubernetes-basierte Lösung zu konfigurieren, müssen Sie den Kubernetes-Cluster in einer Cloud starten und [Health Checks](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/) sowie [Self-Healing](https://kubernetes.io/docs/concepts/overview/#why-you-need-kubernetes-and-what-can-it-do)/[Liveness](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-liveness-command)-Richtlinien einrichten. Die grundlegende Self-Healing-Richtlinie umfasst folgende Parameter, die Sie an Ihre Anforderungen anpassen können: - Liveness-Prüfung alle 5 Sekunden - Umverteilung des Datenverkehrs, wenn ein Container (eine Anwendung) länger als 10 Sekunden nicht antwortet - Neustart, wenn ein Container (eine Anwendung) länger als 20 Sekunden nicht antwortet Ein Beispiel für die [Kubernetes-Liveness-Probe finden Sie hier](https://www.health-samurai.io/docs/aidbox/getting-started/run-aidbox-in-kubernetes/high-available-aidbox). > Starten Sie mit dem Aidbox [FHIR Server](https://www.health-samurai.io/aidbox) für Datenspeicherung, Integrationen, Healthcare-Analysen und mehr, oder [beauftragen Sie unser Team](https://www.health-samurai.io/services), um Ihren Softwareentwicklungsbedarf zu unterstützen. Es ist außerdem wichtig zu beachten, dass Kubernetes so konzipiert ist, dass ein einzelner Kubernetes-Cluster [über mehrere Availability-Zones hinweg betrieben werden kann](https://kubernetes.io/docs/setup/best-practices/multiple-zones/). Dies schützt Ihr Cloud-Ökosystem vor Infrastruktur- und Availability-Zone-Ausfällen. Bitte berücksichtigen Sie dies bei der Konfiguration des Clusters. Als abschließenden Schritt müssen Sie sicherstellen, dass Ihr gewählter FHIR-Server Anfragen parallel verarbeiten kann. Die Aidbox FHIR-Plattform verfügt beispielsweise über einen integrierten internen Aidbox-Cache und einen Mechanismus zur Cache-Synchronisierung zwischen Instanzen. Aidbox-Instanzen können Status- und gemeinsame Konfigurationen untereinander teilen, wodurch sie austauschbar werden. **Kurze Zusammenfassung**: Als Ergebnis verfügen Sie über eine grundlegende hochverfügbare Anwendungsschicht mit automatisiertem Anwendungs-Failover auf Basis des K8s-Self-Healing-Mechanismus. Dieser Ansatz hilft Ihnen, Systemausfallzeiten zu minimieren, und erfordert im Rahmen des Wiederherstellungsprozesses keine manuellen Eingriffe. [![Aidbox FHIR platform on AWS marketplace in one click](image-3.avif)](https://go.aws/3BEavRy) ## Kein Datenverlust. Replizieren und sichern Sie Ihre Datenbank auf die richtige Weise Um einen Single Point of Failure auf der Datenbankebene zu vermeiden, benötigen Sie ein Replikat, Backups sowie einen Failover- und Wiederherstellungsprozess (idealerweise automatisiert). In unserem Fall verwenden wir PostgreSQL, und die nachfolgenden Beispiele basieren darauf. PostgreSQL ermöglicht es Ihnen, zwei oder mehr Replikate mithilfe der [integrierten Streaming-Replikationsfunktion](https://www.postgresql.org/docs/current/runtime-config-replication.html) einzurichten. Wir empfehlen, folgende Parameter einzuhalten: - mindestens ein synchrones Replikat und - ein Replikat mit einer Verzögerung von 12–24 Stunden Dies schützt Ihre Daten, falls Sie versehentlich eine Tabelle aus der Datenbank löschen, sodass Sie diese problemlos wiederherstellen können. ![High-available FHIR infrastructure](image-4.avif) PostgreSQL-Backups lassen sich in zwei Typen unterteilen: - [Inkrementell](https://www.postgresql.org/docs/9.0/continuous-archiving.html) – führt ein Write-Ahead-Log (WAL), das jede an der Datenbank vorgenommene Änderung aufzeichnet - [Basis (vollständig)](https://www.postgresql.org/docs/9.0/continuous-archiving.html) – vollständiges Datenbank-Backup Um eine Backup-Pipeline zu konfigurieren, benötigen Sie zusätzliche Erweiterungen und eine Anwendung zum Auslösen und Ausführen des Prozesses. Wir empfehlen, [die WAL-G-Erweiterung](https://wal-g.readthedocs.io/) für PostgreSQL in Betracht zu ziehen. WAL-G ist ein Archivierungs- und Wiederherstellungswerkzeug für PostgreSQL, MySQL/MariaDB und MS SQL Server (Beta für MongoDB und Redis). Der beste Ansatz zur Speicherung von Backups in der Cloud ist [Amazons AWS S3 Dateispeicherdienst](https://aws.amazon.com/s3/) oder [Google Cloud Storage](https://cloud.google.com/storage). Darüber hinaus empfiehlt es sich als Best Practice, eine eigene dokumentierte **Backup-Richtlinie** auf Basis Ihrer Lösungsanforderungen und Nutzung zu erstellen. Diese Richtlinie bildet die Grundlage Ihrer Backup-Konfiguration. Nachfolgend finden Sie ein Beispiel der wichtigsten Variablen für diese Richtlinie, das als Referenz dienen kann: - inkrementelle Backups ~täglich - Basis-Backups (vollständig) ~wöchentlich - Backup-Aufbewahrung ~monatlich Um Ihre FHIR-basierte Lösung vor dem Go-live zu testen und zu verfeinern, probieren Sie die [kostenlose Version von Aidbox](https://www.health-samurai.io/aidbox#run). Sie bietet eine umfassende Umgebung zur Entwicklung und Validierung Ihrer Lösung mit allen erforderlichen Werkzeugen ohne Funktionseinschränkungen. ## Fazit und Checkliste Eine gut konzipierte, produktionsreife Infrastruktur sollte zuverlässig und selbstheilend sein. Das bedeutet: Fällt eine der Schlüsselkomponenten aus, balanciert sich das System neu und läuft reibungslos weiter. In der Praxis müssen Sie Ihre Komponenten duplizieren und Failover-Mechanismen auf der Anwendungs- und Datenbankebene separat einbetten. Der Kubernetes-Cluster mit nativer Health-Check-Überwachung und Self-Healing-Logik verwaltet Ihre FHIR-basierten Container, während PostgreSQL mit der WAL-G-Erweiterung und integrierten Replikationsfunktionen repliziert und gesichert wird. Die nächste große Herausforderung wird darin bestehen, einen intelligenten Failover- und Wiederherstellungsmechanismus für Datenbanken zu entwickeln. Wir werden dieses Thema in zukünftigen Artikeln ausführlich behandeln. ### Grundlegende Checkliste - Kubernetes-Cluster mit Self-Healing einrichten und in mehreren Zones betreiben - Mehrere parallel arbeitende FHIR-Server-Instanzen verwenden - Synchrones DB-Replikat einrichten - Zusätzliches DB-Replikat mit 12–24-stündiger Verzögerung einrichten - Tägliches inkrementelles Backup konfigurieren - Wöchentliches Basis-Backup (vollständig) konfigurieren - Monatliche Backup-Aufbewahrungsrichtlinie implementieren - DB-Failover- und Wiederherstellungsstrategie entwickeln und anwenden Diese Checkliste reicht aus, um Ihre Lösung vor Datenverlust und Systemausfallzeiten zu schützen. Für eine schlüsselfertige, produktionsreife Infrastruktur müssen Sie sich außerdem um Sicherheit, Netzwerke und Monitoring kümmern oder diese Aufgaben an All-in-One-SaaS-Lösungen wie [die Aidbox FHIR-Plattform in AWS](https://aws.amazon.com/marketplace/pp/prodview-l5djlpvsd6o5g) delegieren. Autor: [**Mike Ryzhikov**](https://www.linkedin.com/in/fhir-solutions/) COO bei Health Samurai Siehe auch: [Aidbox Horizontal & Vertical Scaling](/blog/aidbox-horizontal-vs-vertical-scaling) und [Aidbox HIPAA Technical Safeguards](/blog/aidbox-hipaa-book-technical-safeguards).