Bewährte Verfahren

Dieser Leitfaden beschreibt Muster, Entwurfsprinzipien und Strategien, die sich in Tausenden Bereitstellungen bewährt haben.

Entwurfsprinzipien

1. Einfach beginnen und schrittweise wachsen

Vermeiden Sie unnötige Komplexität am Anfang. Beginnen Sie mit dem einfachsten Entwurf für die aktuellen Anforderungen und entwickeln Sie ihn weiter.

Gut: eine Datenbank, ein Anwendungsserver und ein Lastverteiler. Schlecht: Microservices in 5 Regionen mit ereignisbasierter Zustandsspeicherung ab dem ersten Tag.

2. Ausfälle einplanen

Gehen Sie von Komponentenausfällen aus. Bauen Sie Redundanz und kontrollierte Leistungseinschränkungen ein.

Gut: Multi-AZ-Datenbank, Failover-Replikate und Circuit Breaker. Schlecht: ein einzelner Ausfallpunkt an beliebiger Stelle.

3. Vor der Optimierung messen

Optimieren Sie nicht ohne Daten. Nutzen Sie Analysemodule und Überwachung.

Gut: echte Engpässe mit dem Skalierbarkeitsanalysator bestimmen. Schlecht: „Die Datenbank ist vermutlich langsam, fügen wir einen Cache hinzu.“

4. Vor- und Nachteile verstehen

Jede Architekturentscheidung erfordert Abwägungen. Dokumentieren Sie diese.

Gut: „Für den schnellen Markteintritt wählen wir einen Monolithen und migrieren bei 100k Nutzern zu Microservices.“ Schlecht: „Microservices machen uns skalierbar“, ohne die zusätzliche Komplexität zu verstehen.

5. Alles automatisieren

Manuelle Prozesse skalieren nicht. Automatisieren Sie Bereitstellung, Überwachung und Skalierung.

Gut: Infrastructure as Code mit Terraform, automatische Skalierungsgruppen und CI/CD-Pipelines. Schlecht: manuelle Serverbereitstellung und Skalierungsentscheidungen.

Häufige Architekturmuster

Muster: monolithische Webanwendung

Geeignet für: MVP, ein Team und <100k Nutzer.

Topologie:

Users
  ↓
Load Balancer (ELB)
  ↓
App Servers (3+ instances, auto-scaled)
  ↓
Cache Layer (Redis)
  ↓
Database (Primary + Read Replicas)
  ↓
Object Storage (S3)

Vorteile:

• Einfache Entwicklung und Fehlersuche.
• Einfache Bereitstellung und horizontale Skalierung.
• Geringer Betriebsaufwand.

Nachteile:

• Große Codebasen werden schwer wartbar.
• Gemeinsame Datenbank begrenzt die Skalierung.
• Bindung an Sprache und Framework.

Weiterentwickeln: wenn die Datenbank bei 50k+ Nutzern zum Engpass wird.

Muster: Microservices-Architektur

Geeignet für: große Teams, >100k Nutzer und mehrere Dienste.

Topologie:

API Gateway
├─ Auth Service
├─ User Service
├─ Product Service
├─ Order Service
├─ Payment Service
├─ Notification Service
└─ Analytics Service

Shared Infrastructure:
- Service Mesh (Istio, Linkerd)
- Message Bus (Kafka, RabbitMQ)
- Distributed Tracing
- Centralized Logging

Vorteile:

• Unabhängige Skalierung der Dienste.
• Eigenständige Teams.
• Flexible Technologiewahl mit mehreren Sprachen.
• Einzelne Dienste leicht bereitstellbar.

Nachteile:

• Höhere betriebliche Komplexität.
• Verteilte Herausforderungen wie verzögerte Konsistenz und Fehlersuche.
• Netzwerklatenz zwischen Diensten.
• Erfordert ausgereifte DevOps-Verfahren.

Geeignet: wenn der Monolith begrenzt UND die Teamstruktur dazu passt.

Muster: serverlos, FaaS

Geeignet für: ereignisgesteuerte und schwankende Last sowie Kostenbewusstsein.

Topologie:

API Gateway
  ↓
Lambda Functions (auto-scaled to zero)
  ├─ DynamoDB (serverless database)
  ├─ S3 (object storage)
  ├─ SQS/SNS (messaging)
  └─ CloudWatch Logs

Vorteile:

• Nur genutzte Rechenzeit bezahlen.
• Automatische Reduktion auf null bei Leerlauf.
• Einfache Entwicklung und Bereitstellung.
• Keine Infrastrukturverwaltung.

Nachteile:

• Kaltstartlatenz.
• Begrenzte Umgebungsanpassung.
• Anbieterbindung an AWS Lambda oder GCP Functions.
• Schwierigere Fehlersuche als bei klassischen Servern.

Geeignet: für Lastspitzen, seltene Aufgaben und Startups mit kleinen Betriebsteams.

Muster: Data Lake und Analyse

Geeignet für: große Datenmengen, maschinelles Lernen und Analyselasten.

Topologie:

Data Sources (streaming + batch)
  ↓
Data Ingestion (Kafka, Kinesis, SQS)
  ↓
Data Lake (S3, Blob Storage)
  ↓
ETL/Transform (Spark, Glue, Dataflow)
  ↓
Data Warehouse (Redshift, BigQuery, Snowflake)
  ↓
BI/ML Tools (Tableau, DataStudio, SageMaker)

Zu beachten:

• Datenqualität und Governance.
• Schemafestlegung beim Lesen oder Schreiben.
• Personenbezogene Daten und Datenschutz.
• Optimierung der Abfrageleistung.

Optimierungsstrategien

Kostenoptimierung

1. Bedarfsgerechte Dimensionierung

• Tatsächliche Nutzung statt Maximalkapazität überwachen.
• Muster mit CloudWatch oder vergleichbaren Werkzeugen finden.
• Überdimensionierte Instanzen verkleinern.

2. Reservierte Instanzen

• Gleichmäßige Grundlast vorhersagen.
• Reservierungen für 1-3 Jahre mit 20-40% Rabatt erwerben.
• Mit automatischer Skalierung für variable Last kombinieren.

3. Spot-Instanzen

• Für fehlertolerante, unkritische Lasten nutzen.
• 70% günstiger als bedarfsabhängige Instanzen.
• Mit 2-5% Unterbrechungsrate rechnen.

4. Cache-Strategie

• Häufige Daten mit Redis im Arbeitsspeicher halten.
• Reduziert die Datenbanklast um 50-80%.
• CDN für statische Inhalte verwenden: 80%+ Kostensenkung.

5. Datenübertragung

• Dieser oft teure Bestandteil wird leicht übersehen.
• VPC-Endpunkte zur Vermeidung von Übertragungsgebühren nutzen.
• Daten während der Übertragung komprimieren.
• CloudFront für globale Verteilung nutzen.

Skalierbarkeit optimieren

1. Horizontale Skalierung

• Weitere Server hinter dem Lastverteiler.
• Datenbank: Lesereplikate mit Primär-/Replikamodell.
• Cache: zusätzliche Cache-Knoten.

2. Datenbank-Sharding

• Daten nach Nutzer-ID, Region oder Datum aufteilen.
• Jeder Teil skaliert unabhängig.
• Nachteil: komplexe Koordination.

3. Verbindungspooling

• Datenbankverbindungen wiederverwenden.
• 2-3x höherer Durchsatz.
• Weniger Verbindungsaufwand.

4. Cache-Strategie

• Häufige Daten auf Anwendungsebene puffern.
• API-Antworten mit Invalidierungsstrategie speichern.
• Datenbankabfragen im ORM puffern.

Bewährte Sicherheitsverfahren

1. Verschlüsselung

• Übertragung: TLS 1.3 an allen Endpunkten.
• Speicherung: AES-256 mit KMS-Schlüsseln.
• Datenbank: verschlüsselte Volumes und anwendungsseitiger Schutz personenbezogener Daten.

2. Authentifizierung und Autorisierung

• MFA für alle Konten.
• OAuth 2.0 für Drittanbieter.
• IAM nach minimalen Rechten.
• RBAC für Anwendungsnutzer.

3. Netzwerksicherheit

• VPC-Isolation und private Datenbanksubnetze.
• Sicherheitsgruppen mit wenigen erlaubten Ports.
• NACLs als zusätzliche Schicht.
• WAF zum Schutz von Webanwendungen am Lastverteiler.

4. Datenschutz

• Tokenisierung und Maskierung personenbezogener Daten.
• Feldverschlüsselung für vertrauliche Angaben.
• Aufbewahrungsrichtlinien und Löschen alter Daten.
• Wiederherstellung aus Backups testen.

5. Überwachung und Audits

• CloudTrail oder Auditprotokolle für alle API-Aufrufe.
• CloudWatch-Alarme für Anomalien.
• Regelmäßige Sicherheitsprüfungen.
• Betriebshandbuch zur Vorfallreaktion.

Bewährte Leistungsmaßnahmen

1. Latenz

• CDN für statische Inhalte.
• Indizes für häufige Abfragen.
• Abfragen optimieren und N+1 vermeiden.
• API-Anfragen bündeln.

2. Durchsatz

• Last über Server verteilen.
• Datenbankverbindungen poolen.
• Lange Aufgaben asynchron verarbeiten.
• CPU-gebundene Last vertikal skalieren.

3. Zuverlässigkeit

• Zustandsprüfungen mit Selbstheilung.
• Circuit Breaker für Abhängigkeiten.
• Wiederholungen mit exponentieller Wartezeit.
• Kontrollierte Leistungseinschränkung.

Bewährte Bereitstellungsverfahren

1. Infrastructure as Code

• Alles in Terraform oder CloudFormation.
• Versionskontrolle.
• Prüfung durch Kollegen vor Anwendung.
• Zuerst in Staging testen.

2. Kontinuierliche Bereitstellung

• Automatische Unit-, Integrations- und e2e-Tests.
• Schrittweise Canary-Bereitstellung.
• Blau-Grün-Bereitstellung ohne Ausfallzeit.
• Rücksetzstrategie.

3. Überwachung und Beobachtbarkeit

• Strukturierte JSON-Protokolle.
• Verteilte Ablaufverfolgung mit X-Ray oder Jaeger.
• Metriken mit Prometheus oder CloudWatch.
• Alarme für SLOs, nicht nur Fehler.

Antimuster: was zu vermeiden ist

❌ Einzelner Ausfallpunkt ohne Redundanz. ❌ Überentwicklung, bevor Wachstum Komplexität verlangt. ❌ Kosten ignorieren durch unnötige Funktionen. ❌ Manuell skalieren, obwohl Automatisierung nötig ist. ❌ Keine Überwachung und damit fehlende Sichtbarkeit. ❌ Kein Notfallwiederherstellungsplan: Hoffnung ist keine Strategie. ❌ Alles in einer Verfügbarkeitszone, anfällig für Rechenzentrumsausfälle.

Nächste Schritte

• Muster erkunden → Musterbibliothek
• Architekturanalyse lernen → Analysemodule
• Governance-Verfahren → Governance