Multi-Server-Architektur: Trennung der Zuständigkeiten

Dieser Artikel erklärt, wie unsere Infrastruktur spezialisierte Server nutzt, um Skalierbarkeit, Zuverlässigkeit und Leistung durch Trennung der Zuständigkeiten zu erreichen.

Das Problem: Einschränkungen monolithischer Server

Wenn alles auf einem Server läuft, führt das zu:

  • Ressourcenkonkurrenz: Webserver konkurriert mit Suchdienst um CPU/Arbeitsspeicher

  • Skalierungsschwierigkeiten: Komponenten können nicht unabhängig skaliert werden

  • Single Point of Failure: Ein Server fällt aus = gesamtes System fällt aus

  • Kostenineffizienz: Instanztypen können nicht pro Workload optimiert werden

  • Deployment-Risiko: Bereitstellung einer Komponente betrifft alle anderen

Wir brauchen eine Trennung der Zuständigkeiten über mehrere Server hinweg.

Die Lösung: Spezialisierte Server-Rollen

Wir betreiben spezialisierte Server, die jeweils für ihre Workload optimiert sind:

graph TB
    subgraph prod[Production ERP Server]
        erp[Internal Management
HR, Finance, Manufacturing
24/7 uptime
Shared storage & email]
    end
    
    subgraph web[Public Website Server]
        www[Public Website
Product catalog, blog
24/7 uptime
Behind CDN]
    end
    
    subgraph dev[Development/Staging Server]
        devenv[Dev & Staging
Email campaigns
Powers off nights/weekends]
    end
    
    subgraph search[Search Service Server]
        searchsvc[Vector Search
Filter extraction
Related searches
24/7 uptime]
    end
    
    subgraph cache[Cache Server - Valkey]
        valkey[RediSearch indexes
Query embeddings
Autocomplete
24/7 uptime]
    end
    
    www --> searchsvc
    searchsvc --> valkey

Warum separate Server?

1. Ressourcen-Isolierung

Jeder Server führt einen Workload-Typ aus:

Webserver: Optimiert für HTTP-Anfragebehandlung

  • Hohe Netzwerkbandbreite

  • Moderate CPU

  • Moderater Arbeitsspeicher

  • Schnelle Festplatte für Caching

Suchdienst: Optimiert für Vektoroperationen

  • Hohe CPU (Kosinusähnlichkeit)

  • Hoher Arbeitsspeicher (Embedding-Cache)

  • Geringe Festplatten-E/A

Cache-Server: Optimiert für Speicherzugriff

  • Sehr hoher Arbeitsspeicher

  • Geringe CPU

  • Schnelles Netzwerk

Vorteil: Keine Ressourcenkonkurrenz zwischen Workloads.

2. Unabhängige Skalierung

Wir können jede Komponente unabhängig skalieren:

  • Hoher Traffic? Mehr Webserver hinter Load Balancer hinzufügen.

  • Langsame Suche? CPU des Suchservers aufrüsten oder Replikate hinzufügen.

  • Cache-Misses? Arbeitsspeicher des Cache-Servers erhöhen.

  • Vorteil: Nur das skalieren, was skaliert werden muss, nicht alles.

3. Fehlerisolierung

Fehler bleiben begrenzt:

Suchdienst ausgefallen? Website bedient weiterhin zwischengespeicherte Ergebnisse.

Cache-Server ausgefallen? Suchdienst rechnet ohne Cache (langsamer, aber funktional).

Webserver ausgefallen? Internes ERP nicht betroffen.

Vorteil: Teilausfälle breiten sich nicht auf das gesamte System aus.

4. Deployment-Sicherheit

Wir deployen über Umgebungen:

Entwicklung → Änderungen mit Debug-Tools testen

Staging → In produktionsähnlicher Umgebung testen

Produktion → Mit Vertrauen deployen

Vorteil: Probleme erkennen, bevor sie Nutzer erreichen.

5. Kostenoptimierung

Wir optimieren Kosten pro Server:

  • Entwicklungsserver: Schaltet nachts/weekends ab (50% Kostenreduktion)

  • IPv6-only-Server: Keine Elastic-IP-Kosten ($5/Monat Ersparnis pro Instanz)

  • Richtig dimensionierte Instanzen: Nur für benötigte Ressourcen pro Workload bezahlen

  • Vorteil: Niedrigere Infrastrukturkosten ohne Leistungseinbußen.

Datenfluss zwischen Servern

Das Verständnis des Datenflusses hilft zu erklären, warum die Trennung wichtig ist:

Benutzeranfrage-Fluss

Produktseiten-Anfrage:

sequenceDiagram
    participant User
    participant CDN
    participant Web as Web Server
    participant Search as Search Service
    participant Cache as Cache Server
    
    User->>CDN: Request product page
    CDN->>CDN: Check cache
    alt Cache hit
        CDN->>User: Serve cached page
    else Cache miss
        CDN->>Web: Forward request
        Web->>Search: Get related products
        Search->>Cache: Query embeddings
        Cache->>Search: Return results
        Search->>Web: Related products
        Web->>CDN: Rendered page
        CDN->>CDN: Cache response
        CDN->>User: Serve page
    end

Suchanfrage-Fluss:

sequenceDiagram
    participant User
    participant Web as Web Server
    participant Search as Search Service
    participant Cache as Cache Server
    
    User->>Web: Submit search query
    Web->>Search: Forward query
    Search->>Search: Extract filters
    Search->>Search: Compute embedding
    Search->>Cache: Vector search
    Cache->>Search: Ranked results
    Search->>Web: Product matches
    Web->>User: Render results

Vorteil: Jeder Server macht das, wofür er optimiert ist.

Speicherstrategie pro Server

Verschiedene Server nutzen verschiedene Speicherstrategien:

Webserver

S3-basierte statische Dateien: Bilder, CSS, JS werden von S3 bereitgestellt

  • Hohe Verfügbarkeit

  • Keine lokale Festplattennutzung

  • CDN-freundlich

Lokaler Cache: Nginx cacht gerenderte Seiten

  • Schneller wiederholter Zugriff

  • Automatische Entwertung

Suchdienst

NumPy-Arrays: Produkt-Embeddings als binäre Arrays gespeichert

  • Schnelle Vektoroperationen

  • Speichergemappt für Effizienz

  • 65K Produkte × 768 Dimensionen = ~190 MB

JSON-Dateien: Filter-Mappings, Phrasentabellen

  • Menschenlesbar

  • Einfach zu aktualisieren

  • Kleine Größe (<10 MB)

Cache-Server

Valkey (Redis): Query-Embeddings, beliebte Suchanfragen, Autovervollständigung

  • Im Speicher für Geschwindigkeit

  • RediSearch für Vektor-Indizes

  • Persistenz für Dauerhaftigkeit

Warum unterschiedliche Speicher?

  • NumPy: Optimiert für Vektormathematik (Kosinusähnlichkeit)

  • JSON: Optimiert für menschliche Bearbeitung (Filterregeln)

  • Valkey: Optimiert für Key-Value-Lookups (Query-Cache)

CDN-Architektur

Die öffentliche Website liegt hinter einem Content Delivery Network:

Was wird gecacht

Statische Assets (lange TTL):

  • Bilder, CSS, JavaScript

  • Schriftarten, Icons

  • 1 Jahr gecacht

Produktseiten (mittlere TTL):

  • Produktbeschreibungen

  • Spezifikationen

  • 1 Stunde gecacht

Suchseiten (kurze TTL):

  • Suchergebnisse

  • Filterkombinationen

  • 5 Minuten gecacht

Nicht gecacht:

  • Benutzerspezifischer Inhalt

  • API-Endpunkte

  • Dynamische Suche

Warum ein CDN wichtig ist

  • Globale Latenz: Edge-Standorte bedienen Inhalte näher an den Nutzern

  • Origin-Schutz: CDN absorbiert Traffic-Spitzen, schützt Origin-Server

  • DDoS-Abwehr: CDN filtert bösartigen Traffic, bevor er den Origin erreicht

  • Kostenreduktion: Weniger Origin-Anfragen = niedrigere Compute-Kosten

Deployment-Pipeline

Wir deployen über Umgebungen, um Probleme früh zu erkennen:

Entwicklungsumgebung

Zweck: Schnelle Iteration mit Debug-Tools Merkmale:

  • Automatisches Neuladen bei Codeänderungen

  • Detaillierte Fehlerseiten

  • Debug-Toolbar

  • Kein Caching

Vorteil: Schnelle Feedback-Schleife für Entwickler.

Staging-Umgebung

Zweck: Produktionsähnliches Testen Merkmale:

  • Gleiche Konfiguration wie Produktion

  • Gleiche Server-Einrichtung (Gunicorn, Nginx)

  • Gleiches Caching-Verhalten

  • Isoliert von Produktionsdaten

Vorteil: Produktionsspezifische Probleme vor dem Deployment erkennen.

Produktionsumgebung

Zweck: Echte Nutzer bedienen Merkmale:

  • Für Leistung optimiert

  • Volles Caching aktiviert

  • Monitoring und Alerting

  • Automatischer Neustart bei Crashes

Vorteil: Stabiler, zuverlässiger Service.

Referenzen

Technische Konzepte

AWS-Dienste

  • CloudFront - AWS CDN-Dokumentation

  • S3 - AWS Objektspeicher-Dokumentation

  • DynamoDB - AWS NoSQL-Datenbank-Dokumentation

Verwandte Artikel

Zusammenfassung

Unsere Multi-Server-Architektur trennt Zuständigkeiten über spezialisierte Server:

Produktions-ERP-Server:

  • Internes Managementsystem

  • 24/7 Betriebszeit

  • Gemeinsamer Speicher und E-Mail

Öffentlicher Website-Server:

  • Kundenorientierte Website

  • 24/7 Betriebszeit

  • Hinter CDN mit S3-basierten statischen Dateien

Entwicklungs-/Staging-Server:

  • Sichere Testumgebungen

  • E-Mail-Kampagnenverarbeitung

  • Kostenoptimiert (schaltet nachts/weekends ab)

Suchdienst-Server:

  • Vektor-Ähnlichkeitssuche

  • Filterextraktion

  • NumPy-basierte Embeddings

Cache-Server (Valkey):

  • Query-Embedding-Cache

  • RediSearch-Vektor-Indizes

  • Ranking beliebter Suchanfragen

Wesentliche Vorteile:

  • ✅ Ressourcenisolierung: Keine Konkurrenz zwischen Workloads

  • ✅ Unabhängige Skalierung: Nur das skalieren, was skaliert werden muss

  • ✅ Fehlerisolierung: Ausfälle breiten sich nicht aus

  • ✅ Deployment-Sicherheit: Vor Produktion testen

  • ✅ Kostenoptimierung: Richtig dimensionierte Instanzen, Zeitpläne für Abschaltung

  • ✅ Leistung: CDN-Caching, spezialisierte Speicherstrategien

Diese Architektur ermöglicht es uns, Millionen von Anfragen zu bedienen und dabei hohe Verfügbarkeit, niedrige Latenz und überschaubare Kosten zu gewährleisten.

← Zurück zum Dokumentationsindex