Zum Inhalt

Skalierungsstrategien

KanjiIQ ist so konzipiert, dass es von seiner aktuellen Einzelknoten-Bereitstellung zu einer Multi-Knoten-, Multi-Region-Architektur skaliert werden kann, wenn der Datenverkehr wächst.

Aktueller Stand

Metrik Wert
Cluster-Knoten 1 (Hetzner Dedicated)
Anwendungsreplikate 2
Datenbank Einzelne PostgreSQL-Instanz
Datenverkehrshandhabung ~100 Req/Min pro IP (ratenbegrenzt)

Dies bewältigt den aktuellen Datenverkehr problemlos. Die folgenden Abschnitte beschreiben den Skalierungspfad bei steigender Nachfrage.

Horizontal Pod Autoscaling (HPA)

Der erste Skalierungsschritt ist das Hinzufügen von HPA, um die Replikat-Anzahl automatisch basierend auf der Last anzupassen:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: jlpt-kanji-hpa
  namespace: jlpt-kanji
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: jlpt-kanji
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 80

Voraussetzungen: Metrics Server muss installiert sein (standardmäßig in k3s enthalten).

Auswirkung: Die Anwendung skaliert automatisch zwischen 2-10 Replikaten basierend auf CPU-/Speicherdruck, ohne Codeänderungen.

Multi-Knoten-Cluster

Wenn ein einzelner Knoten an Ressourcengrenzen stößt, fügen Sie Worker-Knoten zum k3s-Cluster hinzu:

# On the new worker node
curl -sfL https://get.k3s.io | K3S_URL=https://master:6443 \
  K3S_TOKEN=<node-token> sh -

Kubernetes plant Pods automatisch über alle verfügbaren Knoten. Die Anwendung erfordert keine Änderungen — sie ist bereits zustandslos.

Node Affinity (optional)

Um die Pod-Platzierung zu steuern:

spec:
  affinity:
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 100
          podAffinityTerm:
            labelSelector:
              matchLabels:
                app: jlpt-kanji
            topologyKey: kubernetes.io/hostname

Dies verteilt Replikate auf verschiedene Knoten für bessere Fehlertoleranz.

Datenbank-Skalierung

Connection Pooling

Fügen Sie PgBouncer als Sidecar-Container hinzu, um Datenbankverbindungen zu poolen:

containers:
  - name: pgbouncer
    image: edoburu/pgbouncer
    ports:
      - containerPort: 6432
    env:
      - name: DATABASE_URL
        valueFrom:
          secretKeyRef:
            name: jlpt-kanji-secrets
            key: database-url

Das Backend verbindet sich mit PgBouncer auf :6432 anstatt direkt mit PostgreSQL, wodurch der Verbindungsoverhead reduziert wird.

Read Replicas

Für leseintensive Workloads (Karteikarten-Abfragen) fügen Sie PostgreSQL Streaming-Replikation hinzu:

  1. Die primäre Instanz übernimmt Schreibvorgänge (Lernsitzungen, Quiz-Ergebnisse)
  2. Read Replicas übernehmen Lesevorgänge (Kanji-/Vokabelabfragen)
  3. Das Backend leitet Abfragen basierend auf dem Operationstyp weiter

Verwaltete Datenbank

Der einfachste Datenbank-Skalierungspfad ist die Migration zu einem verwalteten Dienst:

  • AWS RDS: Multi-AZ, automatisierte Backups, Read Replicas
  • GCP Cloud SQL: HA-Konfiguration, automatisches Failover
  • Hetzner Managed PostgreSQL: Wenn verfügbar

Siehe Portabilität für Migrationsdetails.

CDN-Schicht

Statische Frontend-Assets können über ein CDN für globale Leistung bereitgestellt werden:

graph LR
    U[User] --> CF[Cloudflare CDN]
    CF -->|Cache HIT| U
    CF -->|Cache MISS| N[Nginx Frontend]
    N --> CF

Da das Flutter Web Frontend statische Dateien (JS, CSS, Bilder) erzeugt, sind diese ideale CDN-Kandidaten:

  • Cache-Richtlinie: 1 Jahr für gehashte Assets, kein Cache für index.html
  • Globale PoPs: Inhalte werden vom nächstgelegenen Edge-Standort bereitgestellt
  • DDoS-Schutz: CDN absorbiert volumetrische Angriffe

Cloudflare DNS ist bereits eingerichtet — die Aktivierung des Proxy-Modus aktiviert die CDN-Schicht.

Skalierungs-Fahrplan

Datenverkehrsniveau Infrastruktur Wichtige Änderungen
Aktuell (niedrig) 1 Knoten, 2 Replikate, einzelne PG Keine Änderungen nötig
Wachsend (moderat) 1 Knoten, HPA (2-10 Replikate) HPA-Manifest hinzufügen
Hoch 2-3 Knoten, HPA, PgBouncer Worker-Knoten + Connection Pooling hinzufügen
Sehr hoch Multi-Knoten, verwaltete DB, CDN DB zu RDS/Cloud SQL migrieren, CDN aktivieren
Global Multi-Region-Cluster, Read Replicas Signifikante Architekturevolution

Jeder Schritt ist inkrementell — keine Neuschreibungen erforderlich. Der Anwendungscode bleibt über alle Skalierungsstufen hinweg unverändert.