Skalierbarkeit, Load Balancing und Failover: So übersteht Ihre Website Lastspitzen

Failover: der Plan B, den jedes Projekt bereits hat

Jedes Projekt bei Devora Cloud, auch im Hobby-Tarif, hat ein Failover-Replikat. Es steht gestoppt auf einem anderen Server bereit. Fällt die Primärinstanz aus, startet das Failover-Replikat und übernimmt. Kommt die Primärinstanz zurück, wird das Failover-Replikat wieder gestoppt.

Weil es im Normalbetrieb gestoppt ist, teilt dieses Replikat keinen Traffic und bringt keine zusätzliche Kapazität. Seine Aufgabe ist eine andere: Ausfallzeiten zu verkürzen, wenn ein Server Probleme hat.

• In jedem Tarif ohne Aufpreis enthalten.
• Läuft auf einem anderen Server, nicht auf der Maschine der Primärinstanz.
• Startet nur bei einem Ausfall der Primärinstanz und stoppt, wenn sie zurück ist.

Load Balancing: mehrere Kopien teilen sich den Traffic

In allen Tarifen können Sie Skalierungsreplikate hinzufügen, stundenweise abgerechnet. Jedes Replikat ist eine laufende Kopie Ihrer Anwendung in der Größe Ihres Tarifs, und der Load Balancer verteilt die Anfragen auf die gesunden Kopien. Hat eine davon ein Problem, antworten die anderen weiter.

Alle Replikate nutzen dieselbe Datenbank und denselben S3 des Projekts. Sie gewinnen also Rechenkapazität, keine neue Datenbank.

• Hobby: bis zu 2 gleichzeitig laufende Kopien.
• Pro: bis zu 3 gleichzeitig laufende Kopien.
• Enterprise: bis zu 5 gleichzeitig laufende Kopien.
• Erstes zusätzliches Replikat: voller Tarifpreis, stundenweise.
• Load Balancing: voller Stundenpreis für jede Kopie; beim Autoscaling ab der nächsten Zusatzkopie 10 % Rabatt.
• Stündliche Abrechnung, nur solange das Replikat läuft.

Ein Beispiel im Pro-Tarif (20 US$ pro Monat): Das erste Replikat kostet umgerechnet 17 US$, wenn es den ganzen Monat läuft, jedes weitere 15 US$. Schalten Sie ein Replikat nur für eine dreitägige Kampagne zu, zahlen Sie nur diese Stunden.

Autoscaling: Replikate, die bei steigender CPU starten

Autoscaling ist in allen Tarifen verfügbar und wird stundenweise abgerechnet, solange die zusätzlichen Kopien laufen. Sie legen eine CPU-Schwelle fest; überschreitet die Anwendung sie, startet die Plattform ein weiteres Replikat – bis zum Maximum Ihres Tarifs. Sinkt die Nachfrage, werden die zusätzlichen Kopien nicht mehr gebraucht und gestoppt.

Das ist die richtige Wahl für unregelmäßigen Traffic: Nachts laufen keine unnötigen Kopien, und wenn die Spitze kommt, müssen Sie nicht hektisch Kapazität nachlegen.

Failover, Load Balancing oder Autoscaling?

In der Praxis ergänzen sich alle drei: Failover schützt vor dem Ausfall eines Servers, Replikate schaffen dauerhaft Reserve und Autoscaling fängt die Spitzen ab.

Was sich in Ihrem Code ändern muss

Replikate funktionieren nur gut, wenn die Anwendung keinen Zustand auf ihrer eigenen Maschine speichert. Jede Anfrage kann bei einer anderen Kopie landen, deshalb:

• Speichern Sie Login-Sitzungen in Redis (oder in der Datenbank), nicht im Prozessspeicher – so bleiben Nutzer auf jedem Replikat angemeldet.
• Legen Sie Uploads der Nutzer in S3 ab, nie auf der Container-Festplatte. Die Festplatte wird nicht zwischen Replikaten geteilt.
• Koordinieren Sie geplante Aufgaben (Cron, Queues), damit sie nicht einmal pro Kopie laufen.
• Halten Sie die Konfiguration in Umgebungsvariablen, identisch für alle Replikate.

PostgreSQL oder Redis ist in jedem Tarif enthalten (Hobby 1 Datenbank, Pro 2, Enterprise 4), und der private S3 jedes Projekts ist bereit für Ihre Dateien.

AMD-EPYC-Server: Die Größe jeder Kopie zählt

Anwendungen laufen auf Servern mit AMD-EPYC-Prozessoren in den USA. Jedes Replikat hat dieselben CPU- und Speicherlimits wie der Tarif: Mehr Replikate erhöhen die Gesamtkapazität, machen aber keine einzelne Kopie leistungsstärker.

Die übliche Reihenfolge lautet daher: Zuerst sicherstellen, dass der Code effizient ist, dann den Tarif mit der passenden Größe pro Kopie wählen und erst danach die Kopien vervielfachen. Braucht die Anwendung pro Anfrage viel Arbeitsspeicher, hilft ein größerer Tarif mehr als viele kleine Replikate.

Für Besucher in Brasilien beschleunigt der eigene CDN-Cache von Devora die Auslieferung von Inhalten, führt die Anwendung aber nicht aus: Die Verarbeitung bleibt auf den US-Servern.

Häufige Fragen