Kein voreiliges Sharding: Kubernetes-Muster für skalierbare Web-Apps

Skalierbare Web-Apps liefern unter wachsender Last gleichbleibende Latenz und Verfügbarkeit, indem sie die richtige Architektur mit Autoscaling, Caching, Datenpartitionierung und SLO-getriebenen Tests verbinden. Die zentralen Hebel sind die Wahl der Architektur, Muster für die Datenbankskalierung, der Aufbau von Caching und CDN, Autoscaling sowie laufendes Testen und Monitoring. Wenn Sie nur eine Sache sofort angehen wollen: Suchen Sie Ihren offensichtlichsten Engpass (meist die Datenbank oder ein nicht gecachter Hot Path) und beheben Sie diesen zuerst, bevor Sie in Autoscaling oder Änderungen an der Infrastruktur investieren.

---

Kurz gefasst:

• Beheben Sie zuerst den kritischsten Engpass, meist die Datenbank oder einen nicht gecachten Hot Path, bevor Sie in Autoscaling oder den Umbau der Infrastruktur investieren.

• Horizontale Skalierung setzt zustandslose, idempotente und lose gekoppelte Dienste voraus, während vertikale Skalierung durch die Obergrenzen der Instanztypen und durch zustandsbehaftete Dienste begrenzt ist.

• Optimieren Sie Abfragen und ergänzen Sie Read Replicas, um die Kapazität der Datenbank zu erhöhen, bevor Sie komplexes Sharding erwägen, das erhebliche Komplexität mit sich bringt.

• Nutzen Sie Lasttests mit offenem Regelkreis bei hohen Anfrageraten, um die Grenzen des Systems genau zu messen, mit Fokus auf Perzentil-Latenzen und kontrolliertes Nachgeben bei Überlast.

• Setzen Sie striktes Rate Limiting, eine sauber konfigurierte Cache-Sicherheit und sorgfältige Cache-Invalidierung um, denn Skalierung verstärkt Angriffsfläche und Sicherheitsrisiken.

---

Arten der Skalierung und die Prinzipien dahinter

Vertikale Skalierung bedeutet, einem einzelnen Server mehr CPU, Arbeitsspeicher oder Festplattenplatz zu geben. Das ist einfach und oft die schnellste Lösung, doch jeder Instanztyp in der Cloud hat eine Obergrenze, und zustandsbehaftete Dienste, die auf lokale Festplatten oder auf Sitzungsdaten im Arbeitsspeicher angewiesen sind, stossen hart an diese Grenze. Horizontale Skalierung bedeutet, hinter einem Load Balancer weitere Maschinen oder Instanzen zu ergänzen. Sie hat praktisch keine Obergrenze, verlangt aber, dass Ihre Anwendungsschicht viele Kopien ihrer selbst betreiben kann, ohne sich beim eigenen Zustand ins Gehege zu kommen. Diagonale Skalierung mischt beides: Sie machen jeden Knoten etwas grösser und erhöhen zugleich die Anzahl Knoten. So wachsen die meisten Produktivsysteme tatsächlich.

Die Wahl hängt von Ihren Rahmenbedingungen ab. Ein Analyse-Job für einen einzelnen Mandanten, der für einen Batch-Lauf viel Arbeitsspeicher braucht, eignet sich gut für vertikale Skalierung. Eine öffentliche API mit unvorhersehbaren Lastspitzen braucht horizontale Skalierung. Verwaltete Cloud-Dienste begrenzen die vertikale Skalierung oft auf eine bestimmte Instanzklasse, was Sie früher zur horizontalen Skalierung drängt, als Sie vielleicht erwarten.

Horizontale Skalierung funktioniert nur, wenn Ihre Dienste einigen Gestaltungsprinzipien folgen:

• Zustandslosigkeit: Keine Anfrage darf von Daten abhängen, die nur auf jener Instanz liegen, welche die vorherige Anfrage bearbeitet hat.

• Idempotenz: Wiederholte Anfragen (bei Load Balancing und Autoscaling häufig) dürfen keine doppelten Nebeneffekte auslösen.

• Abgegrenzte Kontexte: Jeder Dienst besitzt einen klar abgegrenzten Teil der Daten und der Logik, was horizontale Repliken voneinander unabhängig hält.

Die Architekturempfehlungen aus Google Cloud’s reliability framework raten gerade deshalb zu einem Umbau hin zu horizontaler Skalierbarkeit und zustandslosem Design, weil damit die Obergrenze der einzelnen Instanz wegfällt, an die vertikale Skalierung irgendwann stösst.

Die Datenschicht skalieren, ohne alles neu zu schreiben

Die Datenbank ist der Ort, an dem die meisten Skalierungspläne scheitern, vor allem weil Teams zum Sharding greifen, bevor sie günstigere Mittel ausprobiert haben. Beginnen Sie damit, langsame Abfragen mit dem Query Planner Ihrer Datenbank oder einem Werkzeug wie pg_stat_statements zu identifizieren, und ergänzen Sie dann Indizes, die zu Ihren tatsächlichen Abfragemustern passen, statt zu raten. Erstaunlich viele «Skalierungsprobleme» verschwinden, sobald der richtige zusammengesetzte Index existiert.

Sind Indizierung und Abfrageoptimierung ausgereizt, sind Read Replicas der nächste Hebel. Sie kopieren Daten asynchron auf einen oder mehrere sekundäre Knoten; leselastigen Verkehr (Dashboards, Reporting, Suche) leiten Sie auf die Repliken, während Schreibvorgänge auf der Primärdatenbank bleiben. Der Haken ist die Replikationsverzögerung: Repliken sind nicht sofort konsistent. Jede Funktion, die ihre eigenen Schreibvorgänge unmittelbar liest (jemand schreibt einen Kommentar und will ihn sofort sehen), muss deshalb entweder von der Primärdatenbank lesen oder eine kurze Verzögerung aushalten.

Sharding dagegen teilt Daten horizontal über mehrere unabhängige Datenbanken auf, von denen jede eine Teilmenge der Zeilen hält (nach Kund:innen-ID, Region oder einem anderen Schlüssel). Es löst Grenzen beim Schreibdurchsatz, an die Replikation nicht herankommt, bringt aber echte Komplexität mit: Abfragen über mehrere Shards hinweg, Rebalancing und Migrationslogik. Greifen Sie erst zum Sharding, wenn Replikation und Indizierung nicht mehr genügen, nicht als ersten Schritt.

Praktische Schritte, die unabhängig von der Grössenordnung gelten:

• Erst messen, dann optimieren: Nutzen Sie Slow-Query-Logs, um den tatsächlichen Engpass zu finden, statt ihn zu vermuten.

• Read Replicas ergänzen für Reporting- und Suchverkehr, bevor Sie über Sharding nachdenken.

• Replikationsverzögerung laufend überwachen, denn eine hinterherhinkende Replik, die unbemerkt veraltete Daten ausliefert, ist schlimmer als gar keine Replik.

• Einen Connection Pooler wie pgbouncer einsetzen, damit unter Last die Verbindungen nicht ausgehen, denn die meisten Datenbanken haben harte Limiten für gleichzeitige Verbindungen, und eine gesprächige Anwendung erreicht diese Grenze lange vor CPU oder Arbeitsspeicher.

Profi-Tipp: Prüfen Sie, bevor Sie eine Replik oder einen Shard ergänzen, ob allein ein Connection Pooler Ihre Symptome behebt: Viele Vorfälle nach dem Muster «Datenbank überlastet» sind in Wirklichkeit Vorfälle nach dem Muster «zu viele untätige Verbindungen».

Verwaltete Datenbankdienste (Amazon RDS, Cloud SQL, PlanetScale) tauschen etwas Kontrolle gegen planbare Skalierung, automatische Backups und weniger Betriebsaufwand. Sie sind sinnvoll, wenn Ihr Team klein und Ihr Wachstum absehbar ist. Selbst betreiben lohnt sich, wenn Sie eine bestimmte Erweiterung brauchen, bei sehr grossem Volumen die Kosten eng steuern wollen oder eine Konfiguration benötigen, die ein verwalteter Dienst nicht freigibt. Der Wechsel zwischen beiden Welten wird schwieriger, je länger Sie warten: Entscheiden Sie also früh und nicht mitten in der Krise.

Caching, CDNs und ein sicheres Cache-Design

Caching ist der Hebel mit der grössten Wirkung auf dieser Liste, weil er Arbeit ganz beseitigt, statt sie zu verteilen. Statische Dateien (JavaScript-Bundles, Bilder, Schriften) gehören mit langer Cache-Lebensdauer an den Rand des CDN. Dynamische, nutzerspezifische Antworten brauchen kurzlebige Caches oder gar keine, und alles mit berechtigungsrelevanten Daten sollte standardmässig Cache-Control: private oder no-store erhalten, solange Sie nicht ausdrücklich geprüft haben, dass eine Weitergabe unbedenklich ist.

Beim Entwurf der Cache-Keys beginnen die meisten Sicherheitsprobleme rund ums Caching. Das OWASP Web Cache Security Cheat Sheet behandelt Caching als Teil des Berechtigungsmodells: Wenn eine Eingabe einer Anfrage (ein Header, ein Cookie, ein Query-Parameter) die Antwort verändern kann, aber nicht im Cache-Key enthalten ist, kann ein Angreifer den Cache vergiften, oder eine Person erhält die gecachte Antwort einer anderen. Jede Eingabe, welche die Antwort beeinflusst, gehört in den Key, in einen Vary-Header, oder die Route darf gar nicht gecacht werden.

• Statische Dateien am Edge cachen, mit langer max-age und versionierten URLs.

• Dynamische, personalisierte Antworten aus gemeinsam genutzten Caches heraushalten, sofern der Key nicht vollständig abbildet, was sie persönlich macht.

• Nutzen Sie den Header Vary bewusst, nicht als Standard, denn ein zu breites Vary kann das Caching komplett aushebeln.

• Gezielt nach Key-Muster invalidieren, nicht auf Verdacht, und die Invalidierungspfade in einer Staging-Umgebung testen, die den Produktivverkehr abbildet.

Die Cache-Konfiguration als Sicherheitsgrenze zu behandeln, nicht nur als Stellschraube für die Leistung, ist der Grundsatz, auf den das OWASP-Cheat-Sheet seine Empfehlungen stützt, denn eine falsch konfigurierte Cache-Schicht ist eine wiederkehrende Ursache dafür, dass Daten über Mandantengrenzen hinweg sichtbar werden.

Die Wahl des CDN ist zugleich eine Vertrauensentscheidung: Sie erweitern Ihren Sicherheitsperimeter auf Dritte. Mit Subresource Integrity (SRI) können Browser prüfen, ob ein geladenes Skript oder Stylesheet einem erwarteten Hash entspricht, und Werkzeuge aus dem Sigstore-Umfeld dehnen diese Prüfung auf signierte Software-Artefakte aus. Das begrenzt den Schaden, falls ein CDN oder eine Abhängigkeit kompromittiert wird.

Architektur-Grundlagen, die Skalierung erst ermöglichen

Kein noch so gutes Autoscaling repariert eine Architektur, die nicht für den parallelen Betrieb gebaut wurde. Zustandslose Frontend-Dienste, bei denen jede Instanz jede Anfrage bearbeiten kann, sind die Voraussetzung dafür, dass horizontale Skalierung und Load Balancing überhaupt funktionieren. Sobald ein Dienst Sitzungsdaten im lokalen Arbeitsspeicher hält oder auf die lokale Festplatte schreibt, entsteht ein Punkt, der sich nicht frei replizieren lässt, und Sie brauchen irgendwann Sticky Sessions oder einen gemeinsamen Session-Speicher (üblicherweise Redis), um darum herumzukommen.

Dienstgrenzen sind ebenso wichtig wie Zustandslosigkeit. Ein modularer Monolith, also eine einzelne ausrollbare Anwendung, die intern in klar getrennte Module gegliedert ist, trägt sehr weit, solange jedes Modul sauber und das Ganze zustandslos ist. Er ist einfacher zu betreiben, zu testen und auszuliefern als eine Microservices-Architektur und für die meisten Teams der richtige Ausgangspunkt. Microservices rechtfertigen ihre Komplexität dann, wenn verschiedene Teile des Systems wirklich unabhängig skaliert, ausgeliefert oder verantwortet werden müssen, und nicht, weil das Architekturdiagramm anspruchsvoller aussieht. Der praktikable Weg ist, einen Dienst erst dann herauszulösen, wenn ein bestimmtes Modul dem Skalierungs- oder Verantwortungsmodell des Monolithen entwachsen ist, und nicht alles auf einmal.

Ereignisgetriebene Muster entkoppeln jene Teile Ihres Systems, die unterschiedlich schnell laufen. Ein Schreibvorgang in eine Queue (RabbitMQ, Amazon SQS) oder einen Stream (Kafka, Kinesis) lässt eine Anfrage an der Oberfläche rasch zurückkehren, während Hintergrundprozesse die langsamere Verarbeitung asynchron erledigen. Das zählt besonders bei schreiblastigen Lasten: Ein Checkout im Onlinehandel kann die Bestellung annehmen und Lageraktualisierung, Bestätigungsmail und Analyse-Ereignisse in die Queue legen, statt die Kundschaft warten zu lassen, bis alles synchron erledigt ist.

• Frontend- und API-Dienste zustandslos halten, damit jede Instanz jede Anfrage bedienen kann.

• Mit einem modularen Monolithen starten und Dienste erst herauslösen, wenn ein Modul ihm entwachsen ist.

• Queues oder Streams nutzen, um langsame Hintergrundarbeit zu entkoppeln vom Anfragepfad, auf den Nutzer:innen warten.

Zusammen entscheiden diese Weichenstellungen darüber, ob Autoscaling überhaupt hilft. Mehr Instanzen eines zustandsbehafteten, eng gekoppelten Dienstes schaffen oft nur mehr Verstecke für Fehler, nicht mehr Kapazität.

Autoscaling in der Praxis

Autoscaling gibt es in drei Varianten, und die falsche zu wählen ist ein häufiger Fehler. Metrikbasiertes Autoscaling reagiert auf Live-Signale wie Anfragen pro Sekunde oder Queue-Länge. Geplantes Autoscaling nimmt bekannte Muster vorweg, etwa den abendlichen Verkehrsanstieg eines Händlers. Vorausschauendes Autoscaling prognostiziert die Nachfrage im Voraus und lohnt sich vor allem dort, wo die Bereitstellung langsam ist, etwa beim Hochfahren von GPU-Knoten, wo eine Reaktion nach der Lastspitze bereits zu spät kommt.

Auf Kubernetes decken vier Bausteine die meisten Fälle ab:

1. Der Horizontal Pod Autoscaler (HPA) ergänzt oder entfernt Pod-Repliken auf Basis von CPU, Arbeitsspeicher oder eigenen Metriken wie Anfragen pro Sekunde.

2. Der Vertical Pod Autoscaler (VPA) passt die CPU- und Speicheranforderungen bestehender Pods an, damit sie ohne manuelles Nachjustieren richtig dimensioniert sind.

3. Cluster Autoscaler oder Karpenter ergänzen oder entfernen Knoten, damit genug Grundkapazität für jene Pods vorhanden ist, die der HPA betreiben will; Karpenter stellt Knoten bedarfsgerecht bereit statt aus festen Vorlagen für Knotengruppen.

4. KEDA erweitert Autoscaling um ereignisgetriebene Auslöser und skaliert Pods anhand von Queue-Länge oder Stream-Verzögerung statt allein anhand der CPU.

Ein CNCF overview of autoscaling trade-offs beschreibt KEDA und Karpenter als sich ergänzend: KEDA entscheidet anhand eigener Auslöser, wie viele Pods nötig sind, und Karpenter stellt sicher, dass Knoten vorhanden sind, um sie zu betreiben. Zusammen bringen sie Kosten, Zuverlässigkeit und Leistung besser in Einklang als rein CPU-basiertes Skalieren.

Vorausschauendes Autoscaling rechtfertigt seine Komplexität gerade bei Lasten mit langsamer Bereitstellung. Eine CNCF-Fallstudie zum GPU-Autoscaling beschreibt einen Controller, der ein kurzfristiges Prognosemodell mit Spitzenerkennung und gestufter Skalierung kombiniert, also in Wellen statt auf einen Schlag hochskaliert. Er erreichte zehn Minuten im Voraus eine Genauigkeit von 85 % innerhalb von plus/minus 10 % und verhinderte im Test Kettenausfälle. Gestufte Skalierung zählt auch jenseits von GPUs: Hunderte Pods gleichzeitig hochzufahren kann einen Scheduler überlasten und genau jene Instabilität auslösen, die Autoscaling verhindern sollte.

Profi-Tipp: Testen Sie das Verhalten des Autoscalings mit synthetischer Last in einer Staging-Umgebung, bevor Sie ihm im Betrieb vertrauen, und setzen Sie eine harte Obergrenze für die Anzahl Repliken, damit eine entgleiste Metrik Sie nicht in eine überraschende Rechnung skaliert.

Lasttests, die verlässliche Zahlen liefern

Lasttests mit geschlossenem Regelkreis, bei denen jede virtuelle Person auf eine Antwort wartet, bevor sie die nächste Anfrage schickt, unterschätzen das Verhalten von echtem Verkehr, denn echte Nutzer:innen warten nicht höflich, bis sie an der Reihe sind. Tests mit offenem Regelkreis, die Anfragen unabhängig von der Antwortzeit mit fester Rate senden, zeigen genauer, wie sich ein System nahe seiner Grenzen verhält. Google Cloud’s load-testing guidance empfiehlt Muster mit offenem Regelkreis und nennt die Kennzahlen, die man erfassen sollte: Durchsatz, Latenz im 99. Perzentil, Parallelität und Fehlerrate, statt sich auf einen einzelnen Durchschnittswert zu verlassen, der die schlimmsten Erlebnisse verbirgt.

• Werkzeuge mit offenem Regelkreis nutzen wie k6 oder Nighthawk, um realistischen Verkehr ohne Wartepausen zu simulieren.

• Die Latenz im 99. Perzentil erfassen, nicht nur den Durchschnitt, denn Durchschnitte verbergen die langsamen Anfragen, die zu Beschwerden führen.

• Gezielt Überlasttests fahren, um zu sehen, wie das System versagt, und Load Shedding einbauen (überschüssige Anfragen sauber abweisen), damit es kontrolliert nachgibt, statt komplett umzufallen.

• Die Ergebnisse direkt in Schwellenwerte des Autoscalers und in SLOs einfliessen lassen, denn eine getestete Kapazitätszahl ist weit verlässlicher als eine Schätzung.

Monitoring, SLOs und wie aus Telemetrie Handlung wird

Service Level Objectives übersetzen «das System soll schnell und zuverlässig sein» in Zahlen, auf die Sie alarmieren können, etwa «99% der Anfragen sind in unter 300 Millisekunden abgeschlossen». Ein Fehlerbudget, also das erlaubte Mass an SLO-Verletzungen, bevor Sie die Arbeit an Funktionen zugunsten der Zuverlässigkeit pausieren, macht aus dieser Zahl ein Entscheidungswerkzeug statt ein Dashboard, das niemand anschaut.

• Perzentil-Latenzen (p50, p95, p99), Anfragerate, Fehlerrate und Queue-Länge verfolgen als Ihre Kernsignale.

• Prometheus für die Metrikerfassung nutzen und verteiltes Tracing, um eine langsame Anfrage an der Oberfläche mit jenem Dienst oder jener Abfrage zu verknüpfen, die sie verursacht.

• Offensichtliche Gegenmassnahmen automatisieren, etwa einen hängenden Pod neu starten oder hochskalieren, wenn die Queue-Länge einen bekannten Schwellenwert überschreitet, damit Menschen nur jene Vorfälle bearbeiten, die wirklich Urteilsvermögen verlangen.

Speicher skalieren: OLTP, OLAP und ereignisgetriebene Daten

Transaktionale und analytische Lasten konkurrieren um dieselben Datenbankressourcen, wenn Sie sie dasselbe System teilen lassen. Halten Sie Ihre OLTP-Datenbank (jene für die laufenden Transaktionen) auf schnelle, kleine Lese- und Schreibvorgänge ausgerichtet und verlagern Sie Reporting, Dashboards und Analysen in einen separaten OLAP-Speicher oder ein Data Warehouse, das auf das Durchsuchen grosser historischer Datenmengen optimiert ist. Eine schwere Analyseabfrage gegen die produktive Transaktionsdatenbank ist eine häufige und völlig vermeidbare Ursache für Latenzspitzen.

Grosse Objekte, Bilder, Videos, hochgeladene Dateien, gehören in Objektspeicher (Amazon S3, Cloud Storage) hinter einem CDN und nicht in Ihre Primärdatenbank. Liefern Sie sie über unveränderliche, versionierte URLs aus (ein Dateiname mit Inhalts-Hash), damit das CDN sie unbegrenzt cachen kann, ohne je auf Änderungen prüfen zu müssen.

• OLTP- und OLAP-Lasten trennen in verschiedene Speicher, damit Reporting-Abfragen den transaktionalen Verkehr nicht aushungern.

• Grosse Binärdateien im Objektspeicher ablegen, nicht in der Datenbank, und über ein CDN ausliefern.

• Versionierte, unveränderliche URLs verwenden für cachebare Dateien, damit sich die Cache-Invalidierung erübrigt.

Bei schreiblastigen Systemen erlauben Event Sourcing und CQRS (die Trennung von Schreib- und Lesemodell), Schreib- und Lesevorgänge unabhängig zu skalieren: Hintergrundprozesse bauen aus einem Ereignisstrom optimierte Lesesichten auf, statt den laufenden Transaktionsspeicher direkt abzufragen.

Checkliste zu Kosten und Zielkonflikten, bevor Sie investieren

Nicht jeder Hebel lohnt sich für jedes Team. Caching und Abfrageoptimierungen sind schnelle Erfolge mit hoher Wirkung. Sharding, Betrieb über mehrere Regionen und vorausschauendes Autoscaling sind langfristige Investitionen, die erst sinnvoll sind, wenn einfachere Mittel ausgereizt sind und das Wachstum anhält.

• Zuerst Caching und langsame Abfragen beheben; das ist günstig und nimmt oft den grössten Teil des Schmerzes.

• Read Replicas vor Sharding ergänzen; Sharding ist das letzte Mittel, nicht der Startpunkt.

• In vorausschauendes Autoscaling nur bei langsam bereitstellbaren, vorhersehbaren Lasten investieren, etwa bei GPU-gestützten Diensten.

• Vor jeder Änderung an der Infrastruktur einen Durchgang mit SLOs und Lasttests machen, damit Sie wissen, was Sie tatsächlich beheben.

Massnahme	Typische Kosten	Wann sie sich auszahlt
Datenbank-Indizes ergänzen	Gering	Sofort, bei den meisten abfragelastigen Systemen
CDN und Caching statischer Dateien ergänzen	Gering	Sobald Sie statische Dateien an echte Nutzer:innen ausliefern
Read Replicas ergänzen	Mittel	Wenn der Leseverkehr einer einzelnen Primärdatenbank entwächst
Sharding umsetzen	Hoch	Erst wenn die Replikation ausgereizt ist
Vorausschauendes Autoscaling	Hoch	Langsam bereitstellbare Lasten mit vorhersehbaren Spitzen

Wie der Aufbau solcher Systeme in der Praxis aussieht

Skalierungsarbeit scheitert selten daran, dass ein Team das falsche Werkzeug gewählt hat. Sie scheitert, weil sich Anforderungen mitten im Projekt verschieben, die Verantwortung wechselt oder jene Person, welche die ursprüngliche Architektur verstanden hat, geht, bevor der Engpass behoben ist. Ein Modell mit erfahrenen Köpfen an der Spitze hält dieselben Entwickler:innen von der ersten Beratung bis zur Übergabe im Projekt, genau um jene Neuschreibungen mitten im Projekt und jene Abhängigkeitsfallen zu vermeiden, die Skalierungsarbeit andernorts entgleisen lassen.

Zu den Fallstudien von Ampersand zählen Projekte wie der Betrieb einer Plattform mit vielen Websites für eine Schweizer Partei aus einem einzigen System. Dabei ging es weniger um reine Verkehrsmengen als darum, viele fast identische Websites zuverlässig aus gemeinsamer Infrastruktur zu betreiben, ein Muster, das genau die oben beschriebene Zustandslosigkeit und die sauberen Dienstgrenzen belohnt. Der sinnvolle nächste Schritt für ein Team, das die eigene Skalierungsreife beurteilen will, ist ein Audit oder ein klar abgegrenztes Pilotprojekt, bevor es sich auf einen grösseren Umbau festlegt, statt die richtige Architektur im Voraus zu erraten.

Sicherheitsfragen, die mit der Skalierung entstehen

Wer ein System hochskaliert, skaliert auch dessen Angriffsfläche. Jede neue Instanz, jede Cache-Schicht und jeder öffentliche Endpunkt ist eine weitere Fläche, die Angreifer abtasten können, und jene Abwehrmassnahmen, die bei wenig Verkehr genügten (eine einzelne Firewall-Regel, eine manuell geprüfte Anfrage), funktionieren nicht mehr, sobald sich der Verkehr auf Dutzende automatisch skalierte Instanzen verteilt.

Rate Limiting ist die erste Verteidigungslinie, und es muss greifen, bevor eine Anfrage Ihre teure Anwendungslogik erreicht, idealerweise am Load Balancer oder am API-Gateway und nicht tief in einem Dienst, der bereits CPU-Zyklen fürs Parsen der Anfrage verbraucht hat. Limiten pro Benutzer:in und pro IP fangen unterschiedliche Probleme ab: Limiten pro Benutzer:in stoppen Missbrauch über ein kompromittiertes Konto, während Limiten pro IP breiteres Scraping oder Brute-Force-Versuche erwischen, aber auch legitime Nutzer:innen hinter gemeinsam genutzter Netzwerkadressübersetzung treffen können.

DDoS-Schutz in grossem Massstab beruht in der Regel darauf, dass ein CDN oder ein spezialisierter Dienst volumetrische Angriffe abfängt, bevor sie die Ursprungsserver erreichen, denn sich aus einem verteilten Überlastangriff herauszuskalieren ist langsam und teuer im Vergleich zum Filtern am Edge.

Caching und Skalierung wirken zudem auf Weisen mit der Sicherheit zusammen, die leicht übersehen werden: Ein Cache mit falschem Key kann die Fehlerseite wegen Ratenbegrenzung einer Person an eine andere ausliefern oder, schlimmer, eine personalisierte, authentifizierte Antwort an nicht angemeldete Besucher:innen. Genau das ist das Risiko der Cache-Vergiftung, das im OWASP-Cheat-Sheet behandelt wird. Je weiter Sie ein System über mehr CDN-Standorte, mehr automatisch skalierte Instanzen und mehr Cache-Schichten verteilen, desto konsequenter sollten Sie jede dieser Ergänzungen als neuen Punkt betrachten, der eigene Zugriffskontrollen braucht, und nicht bloss als zusätzliche Kapazität.

Wie Ampersand Teams beim Skalieren hilft, ohne zu raten

Eine Webanwendung gut zu skalieren heisst, Architektur, Daten, Caching und Betrieb gleichzeitig richtig hinzubekommen, was mit ständig wechselnden Auftragnehmenden schwierig ist. Ampersand behält dieselben erfahrenen Entwickler:innen von der ersten Beratung bis zur Übergabe im Projekt, ob es um den Aufbau einer neuen Webanwendung oder Plattform geht, um Systemintegrationen oder um laufende technische Unterstützung im Monatsabo. Wenn Ihr System eine Kapazitätsbeurteilung oder ein klar abgegrenztes Pilotprojekt vor einer grösseren Investition braucht, schauen Sie sich die Zusammenarbeitsmodelle und Preise von Ampersand an und melden Sie sich, um den Umfang zu klären.

FAQ

Was bedeutet Skalierbarkeit bei einer Webanwendung?

Skalierbarkeit ist die Fähigkeit eines Systems, wachsende Last zu bewältigen, mehr Nutzer:innen, mehr Daten, mehr Anfragen, ohne dass Leistung oder Zuverlässigkeit entsprechend einbrechen. Erreicht wird sie meist durch eine Kombination aus horizontaler Skalierung, Caching, Datenbankoptimierung und Autoscaling und nicht durch eine einzelne Massnahme.

Wie skaliert man von null auf eine Million Nutzer:innen?

Die meisten Systeme wachsen in Etappen: Beginnen Sie mit einer gut indizierten Datenbank und einer zustandslosen Anwendungsschicht, ergänzen Sie Caching und ein CDN, sobald statische Inhalte ins Gewicht fallen, und führen Sie dann Read Replicas, Queues und Autoscaling ein, wenn der Verkehr ungleichmässig wächst. Sharding und vorausschauendes Autoscaling braucht es in der Regel erst, wenn einfachere Mittel wie Indizierung, Replikation und Caching ausgereizt sind.

Wie mache ich eine App skalierbar?

Planen Sie von Anfang an zustandslos, damit jede Instanz jede Anfrage bearbeiten kann, und ergänzen Sie mit steigender Last horizontale Skalierung, Caching und Read Replicas der Datenbank. Laufende Lasttests mit offenem Regelkreis und SLO-getriebenes Monitoring zeigen Ihnen, welchen dieser Hebel Sie als Nächstes wirklich brauchen.

Was sind Beispiele für Skalierbarkeit?

Ein Beispiel ist ein CDN, das statische Dateien am Edge cacht, sodass die Ursprungsserver weit weniger Verkehr bewältigen müssen; ein anderes ein Kubernetes-Cluster, der mit dem Horizontal Pod Autoscaler Pod-Repliken ergänzt, wenn das Anfragevolumen steigt. Read Replicas der Datenbank, die den Reporting-Verkehr aufnehmen, damit die Primärdatenbank für Transaktionen schnell bleibt, sind ein weiteres verbreitetes Muster.

Quellen

• OWASP Web Cache Security Cheat Sheet

• Google Cloud’s load-testing guidance

• CNCF overview of autoscaling trade-offs

Empfohlen

• MVP-, Web- und Mobile-App-Entwicklung Zürich

• Die Mitte: 600+ Websites für eine Schweizer Partei aus einem einzigen System.

• NeuroMynds: Die Website einer Gründerin schnell, sicher und bereit für Abonnent:innen.

• Migration von Altsystemen & Replatforming Zürich