API-Gateway- & Reverse-Proxy-Experte

Was macht API-Gateway- & Reverse-Proxy-Experte?

Konfiguriere und optimiere API-Gateways und Reverse-Proxys für Routing, Authentifizierung, Ratenbegrenzung und Traffic-Management.

Entscheidungspunkte

Auswahl der Authentifizierungsstrategie

Traffic-Muster & Anforderungen
├── Nur interne Dienste
│   └── API-Key-Authentifizierung
│       ├── Geringe Komplexität, schnelle Validierung
│       └── Kong: key-auth-Plugin, Traefik: forwardAuth
├── Kundenorientierte API mit Sitzungsbedarf
│   └── JWT-Authentifizierung
│       ├── Zustandslos, enthält Benutzeransprüche
│       └── Kong: jwt-Plugin, Nginx: lua-resty-jwt
├── Enterprise-B2B-Integration
│   └── mTLS-Authentifizierung
│       ├── Zertifikatsbasiert, höchste Sicherheit
│       └── Kong: mtls-auth, Nginx: ssl_verify_client
└── Integration von Drittanbieter-SaaS
    └── OAuth2-Ablauf
        ├── Token-Austausch, delegierte Authentifizierung
        └── Kong: oauth2-Plugin, AWS API Gateway: Authorizer

Auswahl der Gateway-Technologie

Anforderungen → Wahl
├── Plugin-Ökosystem & GUI benötigt
│   └── Kong Enterprise/OSS
├── Kubernetes-nativ mit automatischer Erkennung
│   └── Traefik v3 oder Ingress-NGINX
├── Maximale Leistung, minimale Funktionen
│   └── Nginx oder Envoy
└── Cloud-verwaltet, serverlose Skalierung
    └── AWS API Gateway oder Azure Application Gateway

Upstream-Routing-Strategie

Dienstarchitektur → Routing-Methode
├── Microservices mit Service Discovery
│   └── Dynamische Upstream-Ziele
│       ├── Consul/Eureka-Integration
│       └── Load-Balancing basierend auf Health Checks
├── Statische Backend-Dienste
│   └── Feste Upstream-Pools
│       ├── Round-Robin oder Least-Connections
│       └── Gewichtetes Routing für Canary-Bereitstellungen
└── Multi-Region-Bereitstellung
    └── Geografisches Routing
        ├── Latenzbasiert oder Geo-IP
        └── Fallback auf sekundäre Regionen

Fehlermodi

Gateway-Timeout-Kaskade

Symptom: Langsame API-Antworten (>10s) unter Last
Erkennung: Antwortzeiten steigen, während Upstream-Dienste normale Latenz melden
Ursache: Gateway-Timeout höher als Upstream-Timeout, was zur Anfragenwarteschlange führt
Behebung: Gateway-Lese-Timeout < Upstream-Timeout setzen (Gateway: 30s, Upstream: 25s)

Authentifizierungsumgehung

Symptom: Unautorisierte Anfragen erreichen Backend-Dienste
Erkennung: Backend-Logs zeigen Anfragen ohne erwartete Auth-Header
Ursache: Reihenfolge der Routen erlaubt permissive Regeln vor Auth-Regeln
Behebung: Auth-Middleware auf globale Ebene verschieben oder sicherstellen, dass spezifische Routen zuerst in der Konfiguration kommen

Circuit-Breaker-Thrashing

Symptom: Zeitweise 503-Fehler bei Traffic-Spitzen
Erkennung: Circuit-Breaker öffnet/schließt schnell (mehrmals pro Minute)
Ursache: Schwelle zu empfindlich oder Health-Check falsch konfiguriert
Behebung: Fehlerschwelle (5+ Fehler) und Erholungszeit (mindestens 30s) anpassen

Ablauf von SSL-Zertifikaten

Symptom: HTTPS-Handshake-Fehler, Browser-Zertifikatwarnungen
Erkennung: SSL-Zertifikatsprüfung zeigt Ablauf innerhalb von 30 Tagen
Ursache: Manuelle Zertifikatsverwaltung ohne Erneuerungsautomatisierung
Behebung: cert-manager (K8s) oder ACME-Client mit automatischer Erneuerung implementieren

Ressourcenerschöpfung

Symptom: Gateway akzeptiert keine Verbindungen mehr, Speicher/CPU bei 100%
Erkennung: Verbindungsabgelehnt-Fehler, Gateway-Health-Checks schlagen fehl
Ursache: Keine Verbindungslimits oder Speicherlecks in Plugins
Behebung: worker_connections (Nginx) oder Verbindungspool-Limits (Kong) setzen, Gateway neu starten

Ausgearbeitete Beispiele

Szenario: E-Commerce-API-Gateway-Einrichtung

Kontext: Kong für Microservices bereitstellen, die Bestellungen, Inventar und Zahlungen mit JWT-Auth verarbeiten

Schritt 1: Routendefinition

# Zuerst Service-Endpunkte identifizieren
services:
  - orders: /api/v1/orders/* → http://orders:8080
  - inventory: /api/v1/inventory/* → http://inventory:8080  
  - payments: /api/v1/payments/* → http://payments:8080

Schritt 2: Entscheidungsbaum anwenden

• Traffic-Muster: Kundenorientierte API → JWT-Authentifizierung
• Architektur: Microservices → Dynamische Upstream-Ziele
• Anforderungen: Plugin-Ökosystem benötigt → Kong ausgewählt

Schritt 3: Plugin-Reihenfolge

# Plugins in der richtigen Reihenfolge anwenden
plugins:
  1. cors (vor Auth)
  2. jwt (Authentifizierung) 
  3. rate-limiting (nach Auth)
  4. request-transformer (zuletzt)

Experte vs. Anfänger:

• Anfängerfehler: Wendet Ratenbegrenzung vor Authentifizierung an (anonyme Benutzer verbrauchen Kontingent)
• Expertenansatz: Zuerst Auth, dann Ratenbegrenzung pro authentifiziertem Benutzer
• Anfängerfehler: Verwendet globale CORS-Richtlinie
• Expertenansatz: Unterschiedliche CORS pro Route (orders erlaubt Admin-Ursprünge, payments beschränkt auf Frontend)

Fehlerszenario: Fehlgeschlagene Canary-Bereitstellung

Situation: 20% Traffic auf neue Bestellservice-Version bereitgestellt, es treten 500-Fehler auf

Erkennungsprozess:

1. Gateway-Metriken prüfen: 500-Fehlerrate korreliert mit Bereitstellungszeit
2. Upstream-Health-Checks: Neue Version fällt bei Health Checks durch
3. Gateway-Logs: Upstream-Verbindungszeitüberschreitungen

Rollback-Verfahren:

# Schritt 1: Sofortige Traffic-Verschiebung
kong:
  routes:
    - service: orders-v1
      weight: 100  # War 80
    - service: orders-v2  
      weight: 0    # War 20

# Schritt 2: Rollback validieren
curl -H "Authorization: Bearer $JWT" \
  https://api.company.com/orders/health

# Schritt 3: Fehlgeschlagenen Upstream entfernen
kubectl scale deployment orders-v2 --replicas=0

Ursachenanalyse: Neue Version hatte eine Fehlkonfiguration des Datenbankverbindungspools, was zu Zeitüberschreitungen unter Last führte

Qualitätskontrollen

• Alle Routen haben expliziten Pfadabgleich (keine Catch-all /*-Routen)
• Authentifizierungs-Middleware vor Business-Logik-Plugins konfiguriert
• Health Checks geben 2xx für gesunde Upstreams innerhalb von 5 Sekunden zurück
• Circuit-Breaker-Schwellen gesetzt: 5 Fehler in 60s-Fenster, 30s Erholung
• TLS-Zertifikate erneuern sich automatisch mit 30+ Tagen vor Ablauf
• Ratenbegrenzung pro authentifiziertem Benutzer angewendet, nicht global
• CORS-Richtlinie beschränkt Ursprünge auf erforderliche Domänen
• Gateway-Timeout (30s) < Upstream-Timeout (25s), um Kaskaden zu verhindern
• Zugriffslogs enthalten Korrelations-ID für Anfrageverfolgung
• Gateway mit mindestens 2 Replikaten für Hochverfügbarkeit bereitgestellt

NICHT-FÜR-Grenzen

Diese Skill behandelt: Gateway-Konfiguration, Routing-Regeln, Authentifizierungs-Middleware, Reverse-Proxy-Einrichtung

Nicht für:

• Ratenbegrenzungsalgorithmen-Design → Verwende api-rate-limiting-throttling-expert
• Service-Mesh-Datenebenenkonfiguration → Verwende service-mesh-microservices-expert
• API-Spezifikation und -Design → Verwende api-architect
• Datenbankverbindungspooling → Verwende database-performance-expert
• Container-Orchestrierung → Verwende kubernetes-expert oder docker-expert
• SSL-Zertifikatserstellung → Verwende security-infrastructure-expert

Delegationsregeln:

• Für benutzerdefinierte Ratenbegrenzungsalgorithmen: "Ich werde das Ratenbegrenzungs-Plugin konfigurieren, aber für benutzerdefinierte Algorithmen verwende api-rate-limiting-throttling-expert"
• Für Service Discovery Einrichtung: "Ich werde Upstream-Ziele konfigurieren, aber für das Service-Mesh-Setup verwende service-mesh-microservices-expert"