Auf größere Arbeitsbereiche umstellen, ohne dass jemand warten muss

Jedes Mythex-Projekt bekommt seinen eigenen Arbeitsbereich: einen kleinen Cloud-Computer, auf dem der Agent Code schreibt und die Vorschau deiner App läuft. Wir hatten neue Arbeitsbereiche von 1 GB Arbeitsspeicher auf 2 GB angehoben, aber ältere blieben bei 1 GB, am Tag unserer Prüfung etwa ein Viertel von ihnen. Unser erster Fix verschob ein Projekt beim nächsten Öffnen in einen größeren Arbeitsbereich. Am ersten Tag im Produktivbetrieb ließ das eine Person sieben Minuten warten. Wir setzten dem ein hartes Zeitlimit, und dann nahmen wir die Verschiebung ganz aus dem Öffnen eines Projekts heraus.

Warum alte Arbeitsbereiche klein blieben

Unser Sandbox-Anbieter legt die Größe eines Arbeitsbereichs bei seiner Erstellung fest und behält sie durch jede Pause und jedes Wiederaufwachen bei. Eine Änderung der Vorlage, also des Rezepts, aus dem neue Arbeitsbereiche gebaut werden, wirkt nur auf Arbeitsbereiche, die nach der Änderung entstehen. Keiner ändert die Größe bestehender.

Das war wichtig. Einer der kleinen Arbeitsbereiche lief während eines git push aus dem Speicher, während seine Vorschau gerade startete, und reagierte 11 Minuten lang nicht mehr. Ein Publish scheiterte deswegen.

Erster Versuch: das Projekt beim Aufwecken verschieben

Arbeitsbereiche pausieren, wenn sie niemand nutzt, und wachen auf, wenn das Projekt geöffnet wird. Das Aufwachen schien der richtige Moment für eine Verschiebung, weil dann noch niemand in dem Projekt arbeitet.

Die Verschiebung lief so ab:

1. Größe prüfen. Ist der Arbeitsbereich kleiner als 2 GB, verschieben. Ist die Größe unbekannt, nichts tun.
2. Einen Publish nicht stören. Ein Publish liest die Dateien des Arbeitsbereichs, läuft gerade einer, wird die Verschiebung übersprungen.
3. Das Projekt packen. Alles im Projekt archivieren, einschließlich seines Git-Verlaufs, also jedes Checkpoints des Projekts, und der .env-Datei der App, die dem Besitzer gehört. Installierte Abhängigkeiten (node_modules) lässt man weg, die lassen sich neu installieren.
4. Direkt hinüberkopieren. Das Archiv wird aus dem alten Arbeitsbereich direkt in einen neuen mit 2 GB gestreamt, sodass es nie in den Speicher unseres eigenen Servers passen muss.
5. Vor dem Umschalten vergleichen. In beiden Arbeitsbereichen die Dateien zählen, den neuesten Checkpoint lesen und die Checkpoints zählen. Nur umschalten, wenn alle drei übereinstimmen.
6. Bei jedem Fehler den alten behalten. Jeder Fehler oder jede Abweichung verwirft den neuen Arbeitsbereich, und das Projekt öffnet sich wie zuvor im alten.

Ein Detail beim Vergleich war wichtiger, als es aussieht. Die Prüfung läuft als Administratorkonto, und Git weigert sich, ein Repository zu lesen, das einem anderen Benutzer gehört. Auf beiden Seiten kam deshalb nichts heraus, und „nichts“ stimmte mit „nichts“ überein. Die Prüfung bestand also, ohne irgendeine Historie zu vergleichen. Wir haben Git angewiesen, dem Verzeichnis zu vertrauen, und einen Test ergänzt, damit das nicht wieder passiert.

Was am ersten Tag schiefging

Am ersten Tag im Produktivbetrieb lief das Packen eines Projekts in ein Fünf-Minuten-Zeitlimit für Befehle, mitten im Aufwecken. Der Besitzer wartete sieben Minuten, bis sein Arbeitsbereich sich öffnete. Und weil die Verschiebung gescheitert war, blieb das Projekt klein, sodass das nächste Öffnen es erneut versucht und die Person wieder hätte warten lassen.

Eine Migration, die jemanden beim Öffnen des eigenen Projekts warten lässt, ist ein schlechter Tausch. Der ganze Sinn, sie beim Aufwecken auszuführen, war, dass es niemand merkt.

Zweiter Versuch: ein hartes Budget

Am selben Tag änderten wir vier Dinge:

• Eine Minute für die gesamte Verschiebung. Jeder Schritt, also Größe prüfen, Packen, neuen Arbeitsbereich erstellen, Kopieren, Entpacken, Vergleichen, teilt sich ein einziges Budget von 60 Sekunden. Ist es aufgebraucht, öffnet sich das Projekt im alten Arbeitsbereich.
• Die Arbeit selbst stoppen, nicht nur das Warten. Aufzugeben reicht auf unserer Seite nicht, wenn das Archivieren im Arbeitsbereich weiterläuft, den der Besitzer gleich nutzt. Jeder Archivbefehl wird jetzt im Arbeitsbereich selbst kurz vor Ende des Budgets beendet. Kommt der neue Arbeitsbereich an, nachdem wir aufgegeben haben, wird er verworfen.
• Den Besitzer nicht auf das Aufräumen warten lassen. Das Löschen des temporären Archivs läuft jetzt im Hintergrund.
• Nicht bei jedem Öffnen erneut versuchen. Ein Projekt, das nicht verschoben werden konnte, wird 24 Stunden in Ruhe gelassen, sodass ein Fehlschlag höchstens eine Verzögerung pro Tag kostet und nicht eine pro Öffnen.

Dritter Versuch: es aus dem Aufwecken herausnehmen

Damit war der schlimmste Fall eine Minute. Aber eine Minute bleibt eine Minute, und wir erkannten, dass die Verschiebung überhaupt nicht auf dem Weg irgendeines Menschen liegen musste.

Es wird inzwischen kein Arbeitsbereich mehr mit 1 GB erstellt. Das ist also kein laufender Vorgang, sondern ein einmaliger Auftrag mit einer festen Liste von Arbeitsbereichen. Ihn im Aufwecken laufen zu lassen hieß, dass ein echter Mensch jede langsame Verschiebung bezahlte, und den einzigen Hinweis darauf, dass ein Arbeitsbereich sich nicht verschieben lässt, bekamen wir erst, wenn jemand gerade darauf gewartet hatte.

Also haben wir die Verschiebung aus dem Aufwecken ganz entfernt. Ein Projekt zu öffnen tut, was es vorher tat. Die übrigen kleinen Arbeitsbereiche werden stattdessen als überwachter Stapel behandelt: Niemand wartet darauf, und ein Arbeitsbereich, der sich nicht verschieben lässt, taucht im Bericht des Stapels auf, wo wir ihn uns ansehen können, statt vor der Person, der er gehört.

Was wir daraus gelernt haben

• Größenänderungen sind nicht immer möglich. Legt eine Plattform die Größe bei der Erstellung fest, hilft es nur neuen Dingen, den Standard anzuheben. Plane für die alten.
• „Noch niemand nutzt es“ heißt trotzdem, dass jemand wartet. Arbeit, die auf dem Weg in ein Produkt erledigt wird, sieht ein Mensch.
• Setze jeder Operation, die im Weg eines Nutzers liegt, ein Budget und stoppe die Arbeit, wenn es aufgebraucht ist. Auf unserer Seite abzubrechen, während ein Befehl woanders weiterläuft, verschiebt das Problem nur.
• Eine einmalige Migration gehört in einen einmaligen Auftrag. Sie in alltägliche Aktionen zu verstecken macht sie billiger zu schreiben und teurer im Betrieb.
• Teste deine Sicherheitsprüfungen. Ein Vergleich, der nichts vergleicht, sieht genauso aus wie einer, der bestanden hat.

Wenn du auf Mythex baust, musst du nichts tun. Das Ziel ist einfach, dass weniger Arbeitsbereiche aus dem Speicher laufen, während das Öffnen eines Projekts so schnell bleibt wie zuvor. Wie Arbeitsbereiche pausieren und aufwachen, steht in der Dokumentation unter privater Arbeitsbereich. Eine weitere Geschichte über Speicherprobleme findest du unter der Speicherfehler, der sich in einer Fortschrittsanzeige versteckte.