Autoskalierung bei PostgreSQL und MariaDB: Wie Full-Stack-Autoskalierung die Datenbanklücke schließt

Wenn Plattformanbieter von automatischer Skalierung sprechen, meinen sie damit meist eines: die automatische Skalierung von Anwendungen, also das Hinzufügen oder Entfernen von Web-Instanzen je nach Datenverkehr. Das Prinzip ist allgemein bekannt: Man definiert eine Metrik, legt einen Schwellenwert fest und lässt die Plattform entsprechend reagieren.

Die meisten Plattformen behandeln die Datenbankkapazität jedoch nach wie vor als separates, meist manuell zu lösendes Problem. Teams planen entweder im Voraus für die schlimmste Stunde des schlimmsten Tages, passen ihre Pläne anhand eines Kalenders an oder basteln ihre eigene Skalierungslogik auf Kubernetes oder RDS zusammen. Das Ergebnis ist in jedem Fall dasselbe: Kapazität, die nicht zum Bedarf passt, und Betriebsaufwand, der sich nicht lohnt.

Was „Full-Stack-Autoscaling“ tatsächlich skaliert

Der Begriff wird oft recht locker verwendet. So nutzen wir ihn bei Upsun:

Full-Stack-Autoscaling: Jede Ebene deines Stacks skaliert sich je nach Bedarf von selbst, nativ und auf einer einzigen Plattform: Anwendungen, Worker und verwaltete Datenbanken.

Konkret skalieren drei Dinge horizontal auf derselben Upsun-Primitiv:

• Anwendungen: deine Web-Ebene.
• Worker: Hintergrund- und asynchrone Prozesse wie Zahlungen, Videotranskodierung, KI-Inferenz und geplante Batch-Jobs.
• Verwaltete Datenbanken: schreibgeschützte Replikate von PostgreSQL und MariaDB

Alle drei reagieren auf dieselben Signale: die durchschnittliche CPU- und Speicherauslastung über alle laufenden Instanzen hinweg. Alle drei folgen derselben Logik: Kapazität hinzufügen, wenn die Auslastung über einem Schwellenwert bleibt, und Kapazität entfernen, wenn sie darunter liegt. Alle drei befinden sich im selben Projekt, auf derselben Rechnung und folgen einem einheitlichen Konzept.

So funktioniert die automatische Skalierung von Lese-Replikaten

Die automatische Skalierung bei Upsun erfolgt horizontal: Es werden ganze Instanzen eines Dienstes hinzugefügt oder entfernt. Bei Datenbanken bedeutet das, den Lese-Replikat-Pool deines primären PostgreSQL- oder MariaDB-Dienstes zu skalieren. Du konfigurierst einmalig ein Basis-Replikat; die automatische Skalierung passt die Poolgröße von da an entsprechend der Auslastung an.

Die Plattform überwacht die durchschnittliche CPU- und Speicherauslastung deines laufenden Replik-Pools. Wenn die Auslastung während des Bewertungszeitraums über deinem Schwellenwert für die Skalierung nach oben bleibt, wird eine zusätzliche Replik in den Cluster aufgenommen. Wenn sie während des Bewertungszeitraums unter deinem Schwellenwert für die Skalierung nach unten bleibt, wird eine zusätzliche Replik entfernt. Ein Abkühlungsfenster zwischen den Aktionen verhindert, dass der Pool bei kurzen Auslastungsspitzen ständig auf und ab schwankt.

Die Standardeinstellungen geben dir einen Eindruck davon, wie das funktioniert:

• Schwellenwert für die Skalierung nach oben: 80 % CPU-Auslastung für 5 Minuten
• Schwellenwert für die Verkleinerung: 20 % CPU-Auslastung für 5 Minuten
• Abkühlphase: 5 Minuten zwischen den Skalierungsmaßnahmen
• Instanz-Limits: 1 bis 8 pro Umgebung, regional abhängig

Du kannst CPU, Arbeitsspeicher oder beides als Auslöser verwenden und jeden Schwellenwert pro Umgebung anpassen – nicht nur in der Produktivumgebung, sondern auch in der Entwicklung und im Staging.

Zwei technische Details sind wichtig, um realistische Erwartungen zu haben:

1. Die Replikation erfolgt asynchron. Schreibvorgänge treffen zuerst auf den Primärserver und werden dann an die Replikate weitergeleitet. Verzögerungen betragen in der Regel einige Millisekunden. Wenn deine Anwendung jedoch bei kritischen Daten „Read-after-Write“-Konsistenz benötigt und diese Verzögerung nicht tolerieren kann, leite diese Abfragen an den Primärserver weiter.
2. Replikate sind streng schreibgeschützt. Schreibversuche auf einem Replikat führen zu einem SQL-Fehler. Dies wird auf Engine-Ebene durchgesetzt, nicht in der Anwendungslogik.

Dein Programm ist dafür verantwortlich, Leseabfragen an die Replik weiterzuleiten. Die Verbindungszeichenfolge wird über PLATFORM_RELATIONSHIPS unter dem Namen der Replik-Beziehung (z. B. „database-readonly“) bereitgestellt. Die meisten ORMs und Datenbankbibliotheken unterstützen dieses Muster mit einer separaten Leseverbindung. Es handelt sich um eine Änderung am Programm, nicht an der Infrastruktur.

Warum „nativ“ das entscheidende Wort ist

Es gibt derzeit drei weitere Möglichkeiten, eine automatische Skalierung von Datenbanken zu erreichen. Jede davon ist real, und jede bringt Kompromisse mit sich, die Upsun ausdrücklich zu vermeiden versucht.

1. Serverlose Datenbanken von Drittanbietern: Manche Plattformen leiten Kunden zu einer separaten Datenbank-Engine weiter. Netlify beispielsweise stellt sein Datenbankprodukt auf Neon bereit. Das funktioniert zwar, aber dadurch befinden sich deine Daten bei einem anderen Anbieter, unterliegen einem anderen SLA, einer anderen Abrechnung und oft auch einer anderen Regionszuordnung als deine Anwendung.
2. Selbermachen auf Kubernetes: Du kannst einen PostgreSQL-Operator mit HPA ausführen, benutzerdefinierte Metrik-Adapter konfigurieren und auf diese Weise eine automatische Skalierung erreichen. Du bist dabei auch selbst für die Operator-Upgrades, die HA-Topologie, die Failover-Tests und den Bereitschaftsdienst für das Ganze verantwortlich. 
3. Manuelle Skalierung bei cloud-Anbietern: Bei AWS kannst du HPA für deine App einrichten, RDS-Lesereplikate mit zeitgesteuerter oder alarmgesteuerter Skalierung konfigurieren, CloudWatch-Metriken einrichten und das Ganze betreiben. Gleiches funktionales Ergebnis, deutlich mehr betrieblicher Aufwand – und du bist für jeden einzelnen Teil der Integration selbst verantwortlich.

Die automatische Skalierung der Lesereplikate von Upsun läuft direkt auf den verwalteten PostgreSQL- und MariaDB-Diensten, die dein Projekt bereits unterstützen. Keine dritte Engine, keine zusätzliche Ebene und kein zusätzlicher Aufbau erforderlich.

Wann die automatische Skalierung von Lesereplikaten die richtige Wahl ist

Diese Funktion ist bewusst auf einen bestimmten Anwendungsbereich beschränkt. Sie ist für Workloads konzipiert, bei denen das Hinzufügen von Lesekapazität tatsächlich die Datenbank entlastet.

Sie eignet sich besonders gut für:

• Leselastige Produktionsanwendungen, darunter Listenseiten, Dashboards und suchgesteuerte Benutzeroberflächen
• Berichts- und Analyseaufträge, die auf Produktionsdaten zurückgreifen
• Hintergrundjobs, die häufig abfragen, aber selten schreiben
• Kampagnen- oder ereignisgesteuerten Traffic wie Flash-Sales, Ticketverkäufe, Anmeldezeiträume und Content-Veröffentlichungen
• Anwendungen, die auf verwaltetem PostgreSQL oder MariaDB auf Upsun Flex laufen

Nicht geeignet für:

• Schreibintensive Workloads: Wenn dein Engpass der Schreibdurchsatz auf der Primärdatenbank ist, hilft das Hinzufügen von Lese-Replikaten nicht. Die Skalierung von Schreibvorgängen ist ein ganz anderes Problem, das normalerweise durch Sharding, Partitionierung oder eine grundlegend andere Speicherarchitektur gelöst wird. Diese Funktion versucht nicht, das zu lösen.
• Vorhersehbare Workloads mit geringer Schwankung: Ein internes Dashboard mit gleichmäßiger, moderater Auslastung ist oft besser mit einer festen Anzahl von Instanzen und optimierten vertikalen Ressourcen bedient. Autoscaling bietet einen Mehrwert, wenn die Nachfrage tatsächlich schwankt.
   

So funktioniert es in der Praxis

Stell dir eine E-Commerce-Anwendung auf einer verwalteten PostgreSQL-Datenbank vor. An einem normalen Wochentag bewältigen ein oder zwei Replikate die Leseauslastung, wobei die CPU-Auslastung bei etwa 30–40 % liegt. 

Am Freitagabend geht eine Kampagne online. Was dann passiert:

• Der Traffic verfünffacht sich. Während die Replikate die zusätzliche Leseauslastung auffangen, steigt die CPU-Auslastung auf über 80 %.
• Upsun fügt eine Replik hinzu. Die CPU-Auslastung beruhigt sich kurz, aber der Datenverkehr wächst weiter.
• Ein weiterer Schwellenwert wird überschritten. Eine weitere Replik wird hinzugefügt. Zum Zeitpunkt des Spitzenaufkommens ist der Pool von zwei auf sechs Repliken skaliert worden.
• Kein Neustart, kein Failover. Die Verbindungspools zu den bestehenden Replikaten bleiben aktiv. Neue Replikate treten dem Cluster bei und beginnen, den Datenverkehr zu bedienen. Produktseiten, Suche und der Checkout-Trichter bleiben innerhalb der erwarteten Latenz.
• Über Nacht geht der Datenverkehr wieder zurück. Die CPU-Auslastung sinkt unter 20 %. Upsun entfernt die Replikate nacheinander mit dazwischenliegenden Abkühlphasen, bis der Pool wieder auf dem Ausgangswert ist.

Die nächste Rechnung spiegelt die während des Spitzenauslastungszeitraums tatsächlich genutzte Kapazität wider, nicht die im Voraus dafür dimensionierte Kapazität. Die Kalendererinnerung, die manuelle Erhöhung, die Folgeerinnerung zur Rückstufung – all das entfällt.

Erste Schritte

Das Einrichten der automatischen Skalierung von Lese-Replikaten erfordert zwei Konfigurationsebenen:

1. Definiere den Replikat-Service in YAML

In deiner `.upsun/config.yaml`:

• Füge einen „postgres-replica“- oder „mariadb-replica“-Dienst hinzu
• Definiere einen Replikator-Endpunkt auf dem Primärserver
• Füge deiner Anwendung eine „database-readonly“-Beziehung hinzu

In den Dokumentationen zu PostgreSQL und MariaDB wird die Konfiguration ausführlich beschrieben.

2. Aktiviere die automatische Skalierung für die Replik

Aktiviere die automatische Skalierung für den Replikat-Dienst entweder:

• Konsole: Navigiere zur Registerkarte „Ressourcen konfigurieren“ der Umgebung.
• Upsun-CLI: Führe den Befehl „autoscaling:set“ aus:
  upsun autoscaling:set --service db-replica1 --metric cpu

Die Einstellungen entsprechen denen für die automatische Skalierung von Anwendungen und Workern:

• Schwellenwerte für das Hoch- und Herunterskalieren.
• Auswertungszeitraum.
• Abkühlphase.
• Mindest- und Höchstgrenzen für Instanzen.

Apps, Worker und verwaltete Datenbanken auf einer Plattform, in einer Komponente, auf einer Rechnung. Das ist es, was Full-Stack-Autoskalierung eigentlich bedeutet.

Weiterführende Informationen

Falls du noch keine Lesereplik konfiguriert hast, bieten diese Ressourcen eine Schritt-für-Schritt-Anleitung zur Dienstdefinition. Mehr zu Konfiguration, Optimierung und verwandten Konzepten:

Falls du noch keine Lese-Replik konfiguriert hast, bieten diese Ressourcen eine Schritt-für-Schritt-Anleitung zur Dienstdefinition. Mehr zu Konfiguration, Optimierung und verwandten Konzepten:

• Übersicht über die automatische Skalierung 
• PostgreSQL-Replikation im schreibgeschützten Modus
• MariaDB-Lese-Replikation
• Ressourcenkonfiguration