Nagyobb munkaterületekre váltás úgy, hogy senki ne várjon

Minden Mythex-projektnek saját munkaterülete van: egy kis felhős számítógép, ahol az agent kódot ír, és ahol az app előnézete fut. Az új munkaterületek memóriáját 1 GB-ról 2 GB-ra emeltük, de a régebbiek 1 GB-on maradtak — az ellenőrzés napján ezek körülbelül a negyede volt. Az első javításunk akkor helyezte át a projektet nagyobb munkaterületre, amikor legközelebb megnyitották. Az első éles napján ez egy embert hét percig várakoztatott. Ezért kemény időkorlátot állítottunk be, majd az áthelyezést egyáltalán kivettük a projekt megnyitásából.

Miért maradtak kicsik a régi munkaterületek

A sandbox-szolgáltatónk a munkaterület méretét a létrehozáskor rögzíti, és minden szünet és folytatás során megtartja. A sablon módosítása — az a recept, amelyből az új munkaterületek épülnek — csak a módosítás után létrehozott munkaterületekre hat. A már meglévőket senki nem méretezi át.

Ez számított. Az egyik kis munkaterület elfogyott a memóriából egy git push közben, miközben az előnézete indult, és 11 percig nem válaszolt. Egy publikálás ezen bukott el.

Első próbálkozás: a projekt áthelyezése ébredéskor

A munkaterületek szünetelnek, amikor senki nem használja őket, és akkor ébrednek, amikor megnyitják a projektet. Az ébredés tűnt a megfelelő pillanatnak az áthelyezésre, mert addig senki nem dolgozik benne.

Az áthelyezés így működött:

1. Ellenőrizd a méretet. Ha a munkaterület 2 GB-nál kisebb, helyezd át. Ha a mérete ismeretlen, ne csinálj semmit.
2. Ne zavarj egy publikálást. A publikálás a munkaterület fájljait olvassa, ezért ha fut, ugorj át az áthelyezésen.
3. Csomagold be a projektet. Archiváld a projekt teljes tartalmát — beleértve a git-előzményeit, vagyis a projekt összes checkpointját, és az app .env fájlját, amely a tulajdonosé —, de hagyd ki a telepített függőségeket (node_modules), mert azokat újra lehet telepíteni.
4. Másold át közvetlenül. Az archívumot a régi munkaterületről egy friss, 2 GB-os munkaterületre streameljük, így sosem kell beleférnie a saját szerverünk memóriájába.
5. Hasonlítsd össze váltás előtt. Mindkét munkaterületen számold meg a fájlokat, olvasd ki a legutolsó checkpointot, és számold meg a checkpointokat. Csak akkor válts, ha mindhárom egyezik.
6. Bármilyen hiba esetén tartsd meg a régit. Bármilyen hiba vagy eltérés eldobja az új munkaterületet, és a projekt a régiben nyílik meg, mint korábban.

Az összehasonlításnak egy része többet nyomott a latban, mint első ránézésre. Az ellenőrzés az adminisztrátor fiókjaként fut, és a git nem olvas olyan repository-t, amelyet más felhasználó birtokol. Mindkét oldalon semmit nem írt ki — és a „semmi” egyezett a „semmivel”, így az ellenőrzés úgy ment át, hogy egyáltalán nem hasonlította össze az előzményeket. Megmondtuk a gitnek, hogy bízzon a könyvtárban, és írtunk egy tesztet, hogy ez ne csúszhasson vissza.

Mi romlott el az első napon

Az első éles napon az egyik projekt csomagolása egy öt perces parancs-időkorlátba ütközött — az ébredésen belül. A tulajdonos hét percet várt, mire a munkaterülete megnyílt. És mivel az áthelyezés nem sikerült, a projekt még mindig kicsi volt, így a következő megnyitáskor újra megpróbálták volna, és újra várakoztatták volna.

Egy migráció, amely arra kényszeríti az embert, hogy várjon a saját projektje megnyitására, rossz üzlet. Az egész lényege az volt, hogy ébredéskor senki nem veszi észre.

Második próbálkozás: kemény költségvetés

Ugyanazon a napon négy dolgot változtattunk meg:

• Egy perc az egész áthelyezésre. Minden lépés — a méret ellenőrzése, a csomagolás, az új munkaterület létrehozása, a másolás, a kicsomagolás, az összehasonlítás — egyetlen 60 másodperces keretből osztozik. Amikor kifut, a projekt a régi munkaterületen nyílik meg.
• Állítsd le a munkát, ne csak a várakozást. Nem elég, ha mi feladjuk, ha az archiválás közben még fut a munkaterületen, amelyet a tulajdonos éppen használni fog. Minden archiváló parancsot most magán a munkaterületen belül öljük meg, röviddel a keret vége előtt. Ha az új munkaterület a feladásunk után érkezik meg, eldobjuk.
• Ne várakoztasd a tulajdonost a takarításra. Az ideiglenes archívum törlése most a háttérben történik.
• Ne próbálkozz minden megnyitásnál újra. Az az egy projekt, amelyet nem lehetett áthelyezni, 24 órára ki van hagyva, így egy hiba legfeljebb egy késleltetést okoz naponta, nem minden megnyitásnál egyet.

Harmadik próbálkozás: vedd ki az ébredésből

Azzal a legrosszabb eset egy perc lett. De egy perc akkor is egy perc, és rájöttünk, hogy az áthelyezésnek egyáltalán nem kell senki útjában állnia.

Nincs már olyan munkaterület, amelyet 1 GB-ra hoznának létre. Tehát ez nem folyamatos folyamat; egyszeri feladat egy rögzített munkaterületlistával. Az ébredésen belül elvégezve egy valódi ember fizetett minden lassú áthelyezésért, és csak úgy tudtuk meg, hogy egy munkaterület nem költözik át, hogy valaki éppen várt rá.

Ezért az áthelyezést teljesen kivettük az ébredésből. A projekt megnyitása ugyanúgy történik, mint korábban. A maradék kicsi munkaterületeket egy felügyelt kötegként kezeljük: senki nem vár rá, és az olyan munkaterület, amely nem költözik át, a köteg jelentésében jelenik meg, ahol megnézhetjük, nem pedig a tulajdonos szeme előtt.

Amit ebből tanultunk

• Az átméretezés nem mindig lehetséges. Ha egy platform a méretet a létrehozáskor rögzíti, az alapérték emelése csak az újonnan létrehozottaknak segít. A régiekkel számolni kell.
• „Még senki nem használja” attól még azt jelenti, hogy valaki vár. Egy termékbe való belépés közben végzett munkát egy ember figyeli.
• Költségvetést adj minden olyan dologra, ami a felhasználó útjában van, és állítsd le a munkát, amikor kifut. Ha a saját oldalunkon időkorlátba ütközünk, miközben a parancs máshol tovább fut, csak áthelyezzük a problémát.
• Az egyszeri migrációnak egyszeri feladatban a helye. Ha a mindennapi műveletekbe rejted, könnyebb megírni, és drágább futtatni.
• Teszteld a biztonsági ellenőrzéseidet. Egy összehasonlítás, amely semmit nem hasonlít össze, pontosan úgy néz ki, mint egy sikeres.

Ha Mythexen építesz, nincs teendőd: a cél egyszerűen az, hogy kevesebb munkaterület fogyjon ki a memóriából, és a projekt megnyitása ugyanolyan gyors maradjon. Hogyan szünetelnek és ébrednek a munkaterületek, azt a dokumentáció privát munkaterület része írja le. Egy másik, memóriahiányos történetért lásd a folyamatjelző címkében rejtőző memóriahiba cikket.