- Problemwahrnehmung
- Auf dem Airbridge-Authentifizierungsserver traten intermittierend Antwortverzögerungen auf.
- Da vor API-Anfragen Authentifizierung/Autorisierung durchgeführt wird, wirkt sich eine Verzögerung des Authentifizierungsservers direkt auf die Stabilität des gesamten Dienstes aus.
- Das Monitoring zeigte, dass Warnungen zu Antwortverzögerungen von mehr als 1 Sekunde immer häufiger wurden → Analyse der Ursache und Start der Optimierungsarbeiten.
- Ursachenanalyse
- (1) Übermäßige DB Querys: Im Prozess der Berechtigungsprüfung wurden pro Anfrage zu viele DB Querys ausgeführt; dadurch war der DB Connection Pool schnell erschöpft → Antwortverzögerungen traten auf.
- (2) Sättigung des HikariCP Connection Pools: Bei übermäßiger Ausführung von DB Querys wurde der HikariCP-Pool ausgelastet → Es wurde festgestellt, dass Threads länger als 30 Sekunden warteten.
- (3) Geringe Cache-Effizienz: TTL war mit 30 Sekunden zu kurz gesetzt + ineffiziente Caching-Logik → hohe Wahrscheinlichkeit erneut auftretender DB Querys.
- Verbesserungsstrategie
- (1) Verbesserung der Struktur für Berechtigungsprüfung und Caching
- Einführung einer DB-Sammelabfrage (
findAllBy~) → DB Querys von 134 auf 4 reduziert (-97 %).
- Einsatz von
mutableMap-Caching auf Basis des Anwendungsspeichers.
- Anwendung des Single-Responsibility-Prinzips (SRP) → Methoden getrennt und Caching-Strategien je Unterlogik festgelegt.
- (2) Einführung einer 2-Layer-Cache-Struktur
- Einsatz einer gemischten Struktur aus Local Cache (Caffeine, L1) + Remote Cache (Redis, L2).
- Die Cache-Strategien wurden in L1-Only, L2-Only und Hybrid differenziert, um die Betriebseffizienz zu verbessern.
- Analyse des Speicherverbrauchs des Caches → Erwartet wurden 500.000 Redis-Keys, Speicherbedarf ca. 190 MB, Sicherheitsbuffer gesichert.
- (3) Cache-Invalidierung auf Basis von Redis Pub/Sub
- Weg von der Abhängigkeit von TTL, hin zur Echtzeit-Synchronisierung des Caches bei Änderungen an Berechtigungsinformationen.
- Bei Änderungen auf einem Server wird der Local Cache aller Server synchron über einen Redis-Channel invalidiert.
- (4) Tuning des HikariCP Connection Pools
maximum-pool-size von 10 auf 30 erweitert.- Detaillierte Optionen wie Connection Timeout, Idle Timeout und Max Lifetime optimiert → Entschärfung von DB-I/O-Contention.
- Performancetest und Ergebnis: Auch bei großem Traffic blieb die Performance stabil.
- Verbesserungen in der Produktionsumgebung
- Nach dem Deployment verschwanden die Warnungen zu Antwortverzögerungen, und die gesamte Antwortzeit stabilisierte sich.
- Service-Zuverlässigkeit und Betriebsstabilität wurden deutlich verbessert.
- Zusätzliche Optimierung: JVM Warm-Up
- Direkt nach dem Deployment wurde ein Problem mit verzögerten Antworten bei den ersten Anfragen entdeckt, verursacht durch JIT-Kompilierungsverzögerungen.
- Einführung eines Warm-Up-Runners:
- Beim Start der Anwendung werden vorab Dummy-Anfragen ausgeführt.
- Beim Austausch von K8s Pods wird Traffic erst nach Abschluss des JIT verarbeitet → anfängliche Antwortzeit von 1,07 s auf 94 ms verkürzt.
- Fazit und Wirkung
- Das Problem der Antwortverzögerung wurde gelöst, und zugleich wurde eine Struktur geschaffen, die auf plötzliche Traffic-Spitzen reagieren kann.
- Stabilität und Zuverlässigkeit der gesamten Airbridge-Services wurden verbessert.
- Durch die bessere Nutzbarkeit des Authentifizierungsservers stieg die Produktivität bei der Entwicklung von Domain-Services.
2 Kommentare
In letzter Zeit dürfte die Zahl der Unternehmen gestiegen sein, die diesen Dienst nutzen, nachdem der Deep-Link-Dienst von Google eingestellt wurde.
Ich hoffe auf einen stabilen Service!
Oh ... auch unser Unternehmen hat hier vor Kurzem einen Vertrag abgeschlossen, und Sie arbeiten ja wirklich mit vollem Einsatz an der Leistungsverbesserung!!!