Passare a spazi di lavoro più grandi senza far aspettare nessuno

Ogni progetto Mythex ottiene un proprio spazio di lavoro: un piccolo computer nel cloud dove l'agente scrive il codice e dove gira l'anteprima della tua app. Avevamo portato i nuovi spazi di lavoro da 1 GB a 2 GB di memoria, ma quelli più vecchi erano rimasti a 1 GB: il giorno in cui abbiamo controllato, circa un quarto di loro. La nostra prima correzione spostava un progetto in uno spazio più grande quando veniva riaperto. Il primo giorno in produzione, ha fatto aspettare una persona sette minuti. Abbiamo quindi messo un limite di tempo rigido, poi abbiamo tolto lo spostamento dall'apertura di un progetto.

Perché gli spazi vecchi restavano piccoli

Il nostro provider di sandbox imposta la dimensione di uno spazio di lavoro alla sua creazione e la mantiene attraverso ogni pausa e ripresa. Cambiare il template, cioè la ricetta da cui vengono costruiti i nuovi spazi, influisce solo sugli spazi creati dopo la modifica. Nulla ridimensiona quelli già esistenti.

Questo contava. Uno degli spazi piccoli è finito senza memoria durante un git push mentre la sua anteprima stava partendo, e ha smesso di rispondere per 11 minuti. Una pubblicazione è fallita per questo motivo.

Primo tentativo: spostare il progetto al risveglio

Gli spazi di lavoro vanno in pausa quando nessuno li usa e si risvegliano quando si apre il progetto. Il risveglio sembrava il momento giusto per spostare un progetto, perché nessuno ci sta ancora lavorando.

Lo spostamento funzionava così:

1. Controlla la dimensione. Se lo spazio è più piccolo di 2 GB, spostalo. Se la sua dimensione è sconosciuta, non fare nulla.
2. Non disturbare una pubblicazione. Una pubblicazione legge i file dello spazio, quindi se ne è in corso una, salta lo spostamento.
3. Impacchetta il progetto. Archivia tutto ciò che è nel progetto, compresa la sua cronologia git, cioè ogni checkpoint che il progetto ha, e il file .env dell'app, che appartiene al proprietario, ma escludi le dipendenze installate (node_modules), che possono essere reinstallate.
4. Copialo direttamente. Trasmetti l'archivio dallo spazio vecchio a uno nuovo da 2 GB, così non deve mai entrare nella memoria del nostro server.
5. Confronta prima di passare. Conta i file, leggi l'ultimo checkpoint e conta i checkpoint, in entrambi gli spazi. Passa solo se e tutti e tre corrispondono.
6. Mantieni il vecchio in caso di errore. Qualsiasi errore o discrepanza elimina il nuovo spazio e apre il progetto in quello vecchio, come prima.

Un dettaglio nel confronto contava più di quanto sembri. Il controllo gira con l'account amministratore, e git si rifiuta di leggere un repository di proprietà di un altro utente. Su entrambi i lati non stampava nulla, e "niente" corrispondeva a "niente", quindi il controllo passava senza confrontare alcuna cronologia. Abbiamo detto a git di fidarsi della directory e aggiunto un test perché questo non possa ripetersi.

Cosa è andato storto il primo giorno

Il primo giorno in produzione, l'impacchettamento di un progetto ha superato un timeout di cinque minuti sul comando, all'interno del risveglio. Il proprietario ha aspettato sette minuti che il suo spazio si aprisse. E poiché lo spostamento era fallito, il progetto restava piccolo, quindi all'apertura successiva ci avrebbe riprovato e l'avrebbe fatto aspettare di nuovo.

Una migrazione che costringe qualcuno ad aspettare mentre apre il proprio progetto è un cattivo compromesso. Lo scopo di farla al risveglio era che nessuno se ne accorgesse.

Secondo tentativo: un budget rigido

Lo stesso giorno abbiamo cambiato quattro cose:

• Un minuto per l'intero spostamento. Ogni passaggio, controllo della dimensione, impacchettamento, creazione del nuovo spazio, copia, decompressione, confronto, condivide un unico budget di 60 secondi. Quando scade, il progetto si apre nello spazio vecchio.
• Ferma il lavoro, non solo l'attesa. Rinunciare dal nostro lato non basta se l'archiviazione è ancora in corso dentro lo spazio che il proprietario sta per usare. Ogni comando di archiviazione ora viene terminato dentro lo spazio poco prima che il budget scada. Se il nuovo spazio arriva dopo che abbiamo rinunciato, viene eliminato.
• Non far aspettare il proprietario per la pulizia. L'eliminazione dell'archivio temporaneo ora avviene in background.
• Non riprovare a ogni apertura. Un progetto che non è stato possibile spostare viene lasciato stare per 24 ore, così un fallimento costa al massimo un ritardo al giorno, non uno a ogni apertura.

Terzo tentativo: toglierlo dal risveglio

Questo portava il caso peggiore a un minuto. Ma un minuto è comunque un minuto, e ci siamo resi conto che lo spostamento non doveva stare sul percorso di nessuno.

Nessuno spazio viene più creato a 1 GB. Quindi non è un processo continuo: è un lavoro una tantum con un elenco fisso di spazi. Farlo dentro il risveglio significava che una persona reale pagava ogni spostamento lento, e l'unico modo per sapere che uno spazio non si sarebbe spostato era che qualcuno avesse appena aspettato.

Abbiamo quindi tolto lo spostamento dal risveglio del tutto. Aprire un progetto fa quello che faceva prima. Gli spazi piccoli rimasti vengono gestiti come un lotto supervisionato: nessuno aspetta, e uno spazio che non si sposta compare nel rapporto del lotto, dove possiamo esaminarlo, invece che davanti alla persona che ne è proprietaria.

Cosa ne abbiamo ricavato

• Il ridimensionamento non è sempre possibile. Quando una piattaforma fissa una dimensione alla creazione, alzare il valore predefinito aiuta solo i nuovi elementi. Metti in conto quelli vecchi.
• "Nessuno la sta usando ancora" non significa che nessuno aspetta. Il lavoro fatto mentre una persona entra in un prodotto è lavoro che una persona osserva.
• Metti un budget su tutto ciò che sta sul percorso di un utente, e ferma il lavoro quando il budget scade. Scadere dal nostro lato mentre un comando continua a girare altrove sposta solo il problema.
• Una migrazione una tantum appartiene a un job una tantum. Nasconderla dentro le azioni quotidiane la rende più economica da scrivere e più costosa da eseguire.
• Testa i tuoi controlli di sicurezza. Un confronto che non confronta nulla sembra esattamente uguale a uno che è passato.

Se costruisci su Mythex, non c'è nulla da fare: l'obiettivo è semplicemente avere meno spazi di lavoro a corto di memoria, con l'apertura di un progetto veloce come prima. Come mettere in pausa e risvegliare gli spazi è spiegato nella documentazione alla voce spazio di lavoro privato. Per un'altra storia di memoria esaurita, vedi il crash da esaurimento della memoria nascosto in un'etichetta di avanzamento.