Warum wir die Server von Mythex auf ARM umgestellt haben

Am 19. September haben wir das Produktions-Backend von Mythex von x86-Servern auf kleinere ARM-basierte AWS-Graviton-Server umgestellt und die Plattform-Datenbank ebenfalls auf eine Graviton-Instanz gebracht. Der Auslöser war einfach: Nachdem wir die schwere Arbeit, also das Ausführen und Bauen der App jedes Nutzers, in isolierte Sandboxes pro Projekt verlagert hatten, lagen unsere Hauptserver bei Spitzenlast bei etwa einem Drittel ihres Speichers. Kleinere ARM-Maschinen passen zur tatsächlichen Last und senken die monatliche Serverrechnung um rund 30 Prozent.

Was unsere Server heute tatsächlich tun

Früher haben die Backend-Server viel Arbeit direkt erledigt. Um die Mitte des Septembers haben wir die teuren Teile, also das Ausführen des Codes jedes Projekts, das Installieren von Paketen und das Bauen von Apps, in private Cloud-Sandboxes verlagert, eine pro Projekt. Dadurch bekommt jedes Projekt auch seine eigene isolierte Umgebung und Live-Vorschau.

Auf unseren eigenen Servern blieb die Koordination: die API, der Orchestrator, der Sandboxes und Veröffentlichungen verwaltet, die Authentifizierung, die Abrechnung und das Gateway. Diese Arbeit ist stetig und leicht. Nach der Umstellung lagen die Server bei Spitzenlast um 1,3 GB Speicher, auf Maschinen mit etwa dem Dreifachen davon.

Warum ARM

Die Graviton-Prozessoren von AWS sind ARM-Chips, die AWS selbst entwickelt. Für denselben Preis bekommt man in der Regel mehr Leistung als bei einer vergleichbaren x86-Instanz, oder dieselbe Leistung für weniger Geld. Und für eine Last wie unsere (Node.js-Dienste, Docker, Postgres) gibt es nichts, das uns an x86 bindet.

Wir haben umgestellt:

• Zwei App-Server von mittelgroßen x86-Instanzen auf kleine Graviton-Instanzen mit je 2 GB RAM.
• Die Plattform-Datenbank von einer kleinen x86-Datenbankinstanz auf ihr Graviton-Gegenstück.

Die eine echte Schwierigkeit: Images für zwei Architekturen

Unsere Staging-Umgebung läuft weiterhin auf einem kleinen x86-Server. Die Produktion läuft jetzt auf ARM. Ein für eine Architektur gebautes Container-Image läuft auf der anderen nicht.

Deshalb wird jedes Image jetzt für beide Architekturen unter einem Tag gebaut, ein Multi-Arch-Image. Docker wählt auf jeder Maschine automatisch die passende Variante, und die Deployment-Pipeline muss nicht wissen, in welche Umgebung sie gerade schreibt. Der Preis ist ein längerer CI-Build. Der Gewinn ist, dass Staging und Produktion genau denselben Code aus genau demselben Tag ausführen.

Den Rückweg vor dem Umzug planen

Eine Änderung der CPU-Architektur unter einem laufenden Dienst ist genau die Art von Änderung, die Sie in wenigen Minuten rückgängig machen können wollen. Vor dem Wechsel haben wir:

• die vorherige Version der Server-Vorlage als benanntes Rollback-Ziel behalten,
• unmittelbar vor der Größenänderung der Datenbank einen Datenbank-Snapshot erstellt und
• ein Runbook geschrieben, das den Umzug und den Rückweg beschreibt.

Den Rollback haben wir nicht gebraucht. Wir würden es trotzdem genauso machen.

Worauf wir achten würden

Kleinere Server haben weniger Reserven. Daraus folgen zwei Dinge:

1. Wandert die schwere Arbeit je wieder auf diese Server, reichen 2 GB nicht. Die Lösung wäre dann eine größere Graviton-Größe, nicht die Rückkehr zu x86.
2. Kleine Maschinen brauchen Swap. Eine Woche später ist einer dieser Server durch Speicherdruck eingefroren, ohne technisch den Speicher aufzubrauchen. Die Geschichte der fehlenden Swap-Datei.

Was wir daraus mitnehmen

• Nach Architekturänderungen neu messen. Das Verlagern der Arbeit in Sandboxes hat verändert, was unsere Server brauchten. Die Instanzgrößen waren noch nicht nachgezogen.
• ARM ist ein risikoarmer Gewinn für typische Web-Stacks, sobald Ihre Images für mehrere Architekturen gebaut sind.
• Schreiben Sie den Rollback zuerst. Das macht die Änderung ruhiger, auch wenn Sie ihn nie brauchen.