Health Samurai Lab: Aidbox Horizontal & Vertical Scaling

8 CPU-Kerne, ein FHIR-Server. Alle Kerne einer einzelnen Aidbox-Instanz zuweisen oder sie auf mehrere aufteilen? Wir haben beide Ansätze einem Benchmark unterzogen — vertikales Scaling (mehr Kerne pro Instanz) und horizontales Scaling (mehr Instanzen mit weniger Kernen).

In unserem vorherigen Artikel „Game of Pools" haben wir gezeigt, dass Aidbox beim Hinzufügen von CPU-Kernen nahezu linear skaliert. Doch lineares vertikales Wachstum ist nur die halbe Geschichte. Was passiert, wenn dieselben Kerne auf mehrere Instanzen verteilt werden?

Wie Aidbox in einem Cluster funktioniert

Aidbox stützt sich in hohem Maße auf Caches: Validierungs-Engine, Routing, Subscriptions und mehr. Beim horizontalen Scaling besteht die größte Herausforderung darin, diese Caches instanzübergreifend synchron zu halten. Die übliche Lösung ist ein externer Dienst wie Redis.

Aidbox verfolgt einen anderen Ansatz — kein externer Cache erforderlich. Die instanzübergreifende Synchronisierung erfolgt über den PostgreSQL-Mechanismus LISTEN/NOTIFY: Wenn eine Instanz Daten aktualisiert, erhalten die anderen eine Benachrichtigung und invalidieren ihren Cache. PostgreSQL, das für den Betrieb ohnehin erforderlich ist, dient gleichzeitig als Event-Bus. Keine zusätzliche Infrastruktur erforderlich.

Wenn Ihre Instanz vollständig statisch ist (d. h. zur Laufzeit werden keine Systemressourcen erstellt), können Sie die Cache-Synchronisierung vollständig deaktivieren. Dies bringt einen geringen Leistungsgewinn, da der LISTEN/NOTIFY-Overhead entfällt.

Testaufbau

Alle Tests liefen auf einer einzigen Maschine. Die Aidbox-Instanzen befinden sich hinter nginx (least_conn). Datenbank: eine einzelne PostgreSQL-18-Instanz. Die Last wurde mit k6 erzeugt (5 Minuten, CRUD-Szenario über 9 FHIR-Ressourcentypen). Vor jedem Durchlauf: 30 Sekunden Warmup + 60 Sekunden Cooldown. Die Anzahl der VUs skaliert proportional zur CPU-Kernanzahl (37 VUs pro Kern, 300 VUs für 8 Kerne), um die Latenz über alle Konfigurationen hinweg vergleichbar zu halten.

Vertikales Scaling: Eine Instanz auf 1, 2, 4, 8 Kernen

Bevor wir Kerne auf mehrere Instanzen aufteilen, legen wir zunächst einen Basiswert fest — wie Aidbox vertikal skaliert, wenn alle Kerne einer einzigen Instanz zugewiesen werden:

Eine Verdopplung der CPUs verdoppelt den RPS. Die Latenz bleibt stabil (Durchschnitt 70–90 ms), da die Last proportional zur Kapazität wächst. Bei 8 Kernen beträgt der Multiplikator 7,0× statt dem theoretischen Ideal von 8× — Verluste durch Konkurrenz um gemeinsame Ressourcen (Arbeitsspeicher, GC, PostgreSQL, Netzwerk). Ein solides Ergebnis: Das vertikale Scaling von Aidbox ist vorhersehbar und effizient.

Horizontales Scaling: Aufteilung von 8 Kernen auf Instanzen

Das zentrale Experiment. Dieselben 8 Kerne werden unterschiedlich verteilt:

Effizienz des horizontalen Scalings

Die Degradation verläuft bis 4×2 allmählich und bei 8×1 sprunghaft:

• 1×8 → 2×4: −5,8 % (5747 → 5412)
• 2×4 → 4×2: −7,5 % (5412 → 5004)
• 4×2 → 8×1: −21,5 % (5004 → 3926)
• 1×8 → 8×1: −31,7 % insgesamt

Die Spalte „Effizienz" zeigt, welchen Anteil des theoretischen Maximums (8 × 813 = 6.500 RPS) jede Konfiguration erreicht, sortiert nach Effizienz:

Arbeitsspeicherverbrauch

Horizontales Scaling hat einen versteckten Kostenpunkt: Jede JVM-Instanz bringt ihren eigenen Arbeitsspeicher-Overhead mit sich. Acht Einzelkern-Instanzen verbrauchen deutlich mehr RAM als eine Acht-Kern-Instanz. Angesichts steigender Hardware-Preise (bedingt durch den KI-Hype) kann dies die Betriebskosten von Aidbox spürbar erhöhen.

• Der Wechsel von 1×8 auf 2×4 erhöht den Durchschnitt nur um +0,5 GB, während 8×1 sowohl im Mittelwert als auch im Spitzenwert ungefähr 5× mehr Arbeitsspeicher benötigt
• Praktische Schlussfolgerung: 2×4 ist häufig der optimale Kompromiss zwischen Fehlertoleranz und RAM-Budget, während 8×1 nur unter sehr spezifischen Isolationsanforderungen sinnvoll ist

Zentrale Erkenntnisse

1. Vertikales Scaling gewinnt beim reinen RPS. Eine einzelne Instanz auf 8 Kernen holt das Maximum aus der Hardware heraus. Horizontale Aufteilung verursacht stets Overhead.
2. Horizontales Scaling lohnt sich, wenn Fehlertoleranz gefragt ist. 2×4 verliert im Vergleich zu 1×8 nur 6 % RPS, bietet jedoch Redundanz und das beste P99 (80,5 ms gegenüber 87–90 ms). Fällt eine Instanz aus, bedient die andere weiterhin die Anfragen.
3. Der Wendepunkt liegt bei 2 CPUs pro Instanz. Konfigurationen mit 2+ CPUs (2×4, 4×2) erhalten eine Effizienz von 79–85 %. Unterhalb von 2 CPUs wird der JVM-Overhead kritisch — 8×1 verliert rund 40 % Effizienz und weist das schlechteste P99 aller Konfigurationen auf.
4. Der Preis der Isolation. Der Gesamt-RPS einer horizontalen Konfiguration ist bei gleicher Kernanzahl stets niedriger als beim vertikalen Ansatz. Jede JVM bringt ihren eigenen Overhead mit: Cache-Start, GC, Netzwerk, grundlegender Arbeitsspeicherverbrauch. Je kleiner die Instanzen, desto größer der Overhead-Anteil am gesamten Ressourcenbudget.

Ausblick

Im nächsten Artikel verlassen wir den Teststand und beobachten, wie sich Aidbox in einer produktionsnahen Produktionsumgebung verhält. Außerdem berechnen wir die tatsächlichen Kosten für den Betrieb von Aidbox in der Cloud.

Siehe auch: Health Samurai Lab: Game of Pools.