Vom Ingress bis zum Index: Wo verteilte Systeme unter Last brechen

Wenn Nutzerzahlen sprunghaft ansteigen, geraten verteilte Architekturen schnell an ihre Grenzen. Doch reicht es, in Kubernetes einfach mehr Anwendungs-Pods hochzufahren?

Meist verlagert das die Engpässe nur – von ausgelasteten Web-Nodes hin zu verschränkten Datenbank-Locks, Ingress-Socket-Exhaustion oder schleichendem Storage-I/O-Throttling.

Der Vortrag zeigt Performance als schichtübergreifendes Phänomen. Als praxisnahes Beispiel dient Keycloak, ein verteiltes Identity & Access Management. Fallstricke bei Skalierung, Token-Handling und Session-Caching lassen sich dabei auch auf moderne Microservice-Landschaften übertragen.

Wir starten bei der Definition messbarer Service Level Indicators (SLIs) und klären, warum klassische Lasttests im „Closed Workload Model“ oft trügerische Ergebnisse liefern.

Anschließend beleuchten wir, wie ein „Open Model“ – beispielsweise mit Gatling, Constant Arrival Rates, verteilter Lastgenerierung und entkoppelter Metrikerfassung – dabei hilft, eine Anwendung auf reale Traffic-Muster vorzubereiten. Dabei betrachten wir auch, welche Probleme in den einzelnen Schichten auftreten können.

Transcript

1. Vom Ingress bis zum Index: Wo verteilte Systeme unter Last brechen Alexander Schwartz | Principal Software Engineer | IBM Java User Group | Karlsruhe (DE) | 2026-10-22
2. Was macht ein Identity und Access Management? Wenn’s gut läuft: Wenn’s nicht läuft: • • • • • Anmelden und Tokens ausstellen Tokens erneuern Tokens validieren Abmelden • Keine Anwendung erreichbar für Mitarbeiter Kein Shopping für Kunden
3. Keycloak ist ein Open Source Identity and Access Management Solution 🎂 Erster Commit 2013-07-02 🏆 Cloud Native Computing Foundation Incubating project seit April 2023 📜 Apache License, Version 2.0 ⭐ 37k GitHub Sterne Keycloak DevDay Darmstadt Apr 8+9, 2027
4. Keycloak standalone betreiben Request < Token > Log in f ri Ve Services Cloud API en ok t y
5. Keycloak first contact
6. Nutzer:innen glücklich machen Service Level Indicators (SLI) beschreiben beobachtbares Verhalten, um es zu quantifizieren und mit Stakeholdern verhandelbar zu machen: • • • Verfügbarkeit 👍 (99,x % über X Monate) Fehlerrate ⚖ (99,x% über X Monate) Latenz⏱ (50./95./99. Perzentil) (für eine bestimmte Menge an Last, vgl. RED Methode) Ziel: Kosten für Infrastruktur und Ausfallzeit ausbalancieren.
7. Nutzer:innen simulieren • • • Logins pro Sekunde Anzahl Token Refreshes pro Sekunde Anzahl gleichzeitiger Sessions über alle Nutzer:innen Implizit: Session-Länge, Logout-Verhalten Fallen: • • • TLS-Reconnect für Token Refresh modellieren, Connection Pool pro User. Open Model ohne Coordinated Omission. 500 Connections pro Sekunde pro Linux Lasttreiber (net.ipv4.tcp_fin_timeout)
8. Messen, messen, messen… • • • Übergreifendes Dashboard für alle Lasttreiber Dashboard für die Anwendung (gleiches wie später für Produktion) Tracing in der Anwendung aktivieren
9. Ingress • • Kann zum Bottleneck werden für das Loadbalancing Mussten ab 5000 Connections pro Sekunde bei TLS Passthrough hochskalieren
10. Keycloak (aka “Die Java-Anwendung”) Braucht CPU, Connection Pools, Network IO: • • • • • TLS-Verbindungen aufbauen (bei TLS Passthrough) Passwort prüfen (Argon2 Password Hashing) Session aus der Datenbank laden bzw. Speichern Session-Caching (read/write auf benachbarte Knoten) Signaturen prüfen und berechnen
11. Load Shedding als Lebensretter • • HTTP Worker-Pool limitieren Queue-Size festlegen Was Stand heute noch nicht geht: Priorisieren von Requests
12. Analyse des Java-Prozesses • • • • • Thread Dumps vs. Java Flight Recorder Async Profiling CPU und Memory Allocation Profiling Datenbank Connection Pool vs. HTTP Threads vs. CPU cores Kubernetes CPU Core Limit vs. Throttlings vs. Number of Native threads Datenbank-Verbindungen Initial vs. Min vs. Max und Prepared Statements
13. Datenbank • • • • • • • Datenbank-Connection-Proxy ja oder nein MySQL/MariaDB: Gap Locks bei Isolation Level Repeatable Read (aber nicht Read Committed) MS SQL Lock escalation bei: Read Committed (aber nicht Read Committed Snapshot Isolation) Bei sequenziellem sekundären Index: Last-Page-Insert-Contention oder Latch Contention (ggf. Buckets einführen) Aktualisierung indexierter Felder vermeiden (Index Write Amplification) Async vs. synchronous commit WAL, WAL forwarding, IOPS, Cache
14. Happy users, happy life!
15. Lasttest, Überwachung und Optimierung • • • • Nutzer:innen-zentrierte SLI definieren Messen und Observability Engpässe gibt es überall: Limits, Lock-Contention, Netzwerk-Latenzen Load Shedding als Rettungsanker
16. Links • • • • • Slides: Keycloak https://www.keycloak.org/ Keycloak Observability https://www.keycloak.org/guides#observability Keycloak Benchmark https://www.keycloak.org/keycloak-benchmark/ KeycloakCon EU & KubeCon EU (15. März 2027, Barcelona, ES) https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/co-locatedevents/keycloakcon/ Keycloak DevDay (8.-9. April 2027, Darmstadt, DE) https://keycloak-day.dev/
17. Contact Alexander Schwartz Principal Software Engineer aschwart@redhat.com https://www.ahus1.de @ahus1.de @ahus1@fosstodon.org