Logisches Brandschott
Ein logisches Brandschott ist eine architektonische Trennung in IT-Systemen, die die Ausbreitung von Fehlern, Sicherheitsvorfällen oder Lastspitzen zwischen Systemteilen begrenzt.
Klassifikation
- KomplexitätMittel
- AuswirkungTechnisch
- EntscheidungstypArchitektur
- OrganisationsreifeReif
Technischer Kontext
Prinzipien & Ziele
Use Cases & Szenarien
Kompromisse
- Falsch gesetzte Systemgrenzen
- Übermäßige Fragmentierung
- Unzureichende Anpassungsfähigkeit
- Kritische Ressourcen strikt trennen
- Isolation regelmäßig testen
- Regelmäßige Überprüfungen der Estrennungsmaßnahmen
I/O & Ressourcen
- Architekturdesign
- Technische Spezifikation
- Benutzeranleitung
- Isolierte Systembereiche
- Funktionale Trennung
- Sicherheitszonen
Beschreibung
Logische Brandschotts sind ein zentrales Architektur-Pattern zur Erhöhung der Resilienz komplexer IT-Systeme. Sie trennen Services, Komponenten oder Subsysteme bewusst voneinander, sodass Störungen nicht unkontrolliert auf andere Bereiche übergreifen. Das Pattern unterstützt Stabilität, Verfügbarkeit und Compliance und wird häufig in verteilten Systemen, Cloud-Architekturen und Microservice-Landschaften eingesetzt.
✔Vorteile
- Erhöhte Resilienz des Gesamtsystems
- Reduzierter Blast Radius bei Fehlern
- Verbesserte Verfügbarkeit
✖Limitationen
- Erhöhter Implementierungs- und Betriebsaufwand
- Komplexere Architektur
- Eingeschränkte Flexibilität
Trade-offs
Metriken
- Anzahl kaskadierender Fehler
Anzahl der Fehler, die sich über Systemgrenzen hinweg ausbreiten.
- Reaktionszeit
Durchschnittliche Zeit, die benötigt wird, um auf Anfragen zu reagieren.
- Systemverfügbarkeit
Der Prozentsatz der Zeit, in der das System verfügbar ist.
Beispiele & Implementierungen
Separater Thread-Pool pro Service
Jeder Service verfügt über eigene Thread- und Ressourcenpools, um gegenseitige Beeinflussung zu vermeiden.
Getrennte Datenbankzugriffe
Kritische und nicht-kritische Services nutzen getrennte Datenbankverbindungen.
Isolierte API-Schnittstellen
Jeder Service hat eigene API-Schnittstellen, die nicht von anderen Services beeinflusst werden können.
Implementierungsschritte
Analyse kritischer Abhängigkeiten
Definition isolierter Ressourcen
Überwachung und Tests
⚠️ Technische Schulden & Engpässe
Tech Debt
- Fehlende Dokumentation der Systemgrenzen
- Unzureichende Tests für Komponenten
- Performance-Probleme bei hoher Last
Bekannte Engpässe
Beispiele für Missbrauch
- Alle Services nutzen denselben Connection Pool
- Keine Trennung zwischen verschiedenen Systemen
- Unzureichende Ressourcenverwaltung
Typische Fallen
- Optimierung vor Isolation
- Überprüfung der Integration
- Fehlerbehebung und Tests
Erforderliche Fähigkeiten
Drivers (Architectural Drivers)
Constraints
- • Begrenzte Systemressourcen
- • Bestehende Legacy-Abhängigkeiten
- • Unzureichende Dokumentation