Przechodzimy na większe przestrzenie robocze bez czekania

Każdy projekt Mythex ma własną przestrzeń roboczą: mały komputer w chmurze, na którym agent pisze kod, a podgląd Twojej aplikacji działa. Przeszliśmy na 2 GB pamięci dla nowych przestrzeni, ale starsze pozostały przy 1 GB. Tego dnia, gdy to sprawdziliśmy, było to około jednej czwartej z nich. Nasza pierwsza poprawka przenosiła projekt do większej przestrzeni przy następnym otwarciu. W pierwszym dniu na produkcji sprawiła, że jedna osoba czekała siedem minut. Nałożyliśmy na to twardy limit czasu, a potem wyjęliśmy przenoszenie z samego otwierania projektu.

Dlaczego stare przestrzenie pozostały małe

Nasz dostawca piaskownic ustala rozmiar przestrzeni w chwili jej tworzenia i zachowuje go przez każde uśpienie i wybudzenie. Zmiana szablonu, czyli przepisu, z którego budowane są nowe przestrzenie, dotyczy tylko przestrzeni utworzonych po tej zmianie. Nic nie zmienia rozmiaru istniejących.

Miało to znaczenie. Jedna z małych przestrzeni wyczerpała pamięć podczas git push, gdy startował jej podgląd, i przez 11 minut nie odpowiadała. Publikacja przez to się nie powiodła.

Pierwsza próba: przenieś projekt przy wybudzeniu

Przestrzenie usypiają, gdy nikt z nich nie korzysta, i budzą się przy otwarciu projektu. Wybudzenie wydawało się właściwym momentem na przeniesienie projektu, bo nikt w nim jeszcze nie pracuje.

Przenoszenie działało tak:

Sprawdź rozmiar. Jeśli przestrzeń ma mniej niż 2 GB, przenieś ją. Jeśli rozmiar jest nieznany, nic nie rób.
Nie przeszkadzaj publikacji. Publikacja czyta pliki przestrzeni, więc jeśli trwa, pomiń przenoszenie.
Spakuj projekt. Zarchiwizuj wszystko w projekcie, włącznie z jego historią git, czyli każdym punktem kontrolnym projektu, oraz plikiem .env aplikacji, który należy do właściciela. Pomiń zainstalowane zależności (node_modules), bo można je zainstalować ponownie.
Przenieś bezpośrednio. Przesyłaj archiwum ze starej przestrzeni prosto do nowej, 2-gigabajtowej, żeby nigdy nie musiało zmieścić się w pamięci naszego serwera.
Porównaj przed przełączeniem. Policz pliki, odczytaj najnowszy punkt kontrolny i policz punkty kontrolne w obu przestrzeniach. Przełącz tylko wtedy, gdy wszystkie trzy wartości się zgadzają.
Przy każdej awarii zachowaj starą. Każdy błąd lub niezgodność usuwa nową przestrzeń i otwiera projekt w starej, jak wcześniej.

Jeden szczegół w porównaniu był ważniejszy, niż wygląda. Sprawdzenie działa jako konto administratora, a git odmawia odczytu repozytorium należącego do innego użytkownika. Po obu stronach nic nie wypisało, a „nic” zgodziło się z „niczym”, więc sprawdzenie przeszło, nie porównując żadnej historii. Powiedzieliśmy gitowi, żeby ufał temu katalogowi, i dodaliśmy test, który uniemożliwia powrót tego błędu.

Co poszło źle pierwszego dnia

Pierwszego dnia na produkcji pakowanie jednego projektu trafiło na pięciominutowy limit polecenia, w trakcie wybudzania. Właściciel czekał siedem minut, aż jego przestrzeń się otworzy. A ponieważ przeniesienie się nie udało, projekt nadal był mały, więc przy następnym otwarciu próba powtórzyłaby się i kazałaby mu czekać ponownie.

Migracja, która każe komuś czekać na otwarcie własnego projektu, to zła wymiana. Cały sens robienia tego przy wybudzaniu polegał na tym, że nikt tego nie zauważy.

Druga próba: twardy budżet

Tego samego dnia zmieniliśmy cztery rzeczy:

Minuta na całe przeniesienie. Każdy krok, czyli sprawdzenie rozmiaru, pakowanie, tworzenie nowej przestrzeni, kopiowanie, rozpakowywanie i porównanie, dzieli jeden budżet 60 sekund. Gdy się skończy, projekt otwiera się w starej przestrzeni.
Zatrzymuj pracę, a nie tylko czekanie. Przerwanie czekania po naszej stronie nie wystarcza, jeśli archiwizacja nadal działa w przestrzeni, której właściciel zaraz użyje. Każde polecenie archiwizacji jest teraz zabijane wewnątrz przestrzeni tuż przed końcem budżetu. Jeśli nowa przestrzeń pojawi się, gdy już zrezygnowaliśmy, zostaje wyrzucona.
Nie każ właścicielowi czekać na sprzątanie. Usuwanie tymczasowego archiwum odbywa się teraz w tle.
Nie próbuj przy każdym otwarciu. Projekt, którego nie udało się przenieść, zostaje w spokoju na 24 godziny, więc awaria kosztuje najwyżej jedno opóźnienie dziennie, a nie jedno na każde otwarcie.

Trzecia próba: wyjmij to z wybudzania

To ograniczyło najgorszy przypadek do minuty. Ale minuta to wciąż minuta, i zrozumieliśmy, że przenoszenie w ogóle nie musi być na niczyjej ścieżce.

Żadna przestrzeń nie jest już tworzona w 1 GB. Nie jest to więc proces ciągły, tylko jednorazowe zadanie ze stałą listą przestrzeni. Robienie tego w trakcie wybudzania oznaczało, że prawdziwa osoba płaciła za każde wolne przeniesienie, a jedynym sposobem, by dowiedzieć się, że przestrzeni nie da się przenieść, było to, że ktoś właśnie na nią czekał.

Więc usunęliśmy przenoszenie z wybudzania całkowicie. Otwarcie projektu działa jak przedtem. Pozostałe małe przestrzenie obsługujemy jako nadzorowaną partię: nikt na to nie czeka, a przestrzeń, której nie da się przenieść, pojawia się w raporcie partii, gdzie możemy na nią spojrzeć, zamiast przed oczami osoby, do której należy.

Co z tego wynieśliśmy

Zmiany rozmiaru nie zawsze są możliwe. Gdy platforma ustala rozmiar przy tworzeniu, podniesienie domyślnej wartości pomaga tylko nowym rzeczom. Trzeba planować dla starych.
„Nikt tego jeszcze nie używa” nadal oznacza, że ktoś czeka. Praca wykonywana po drodze do produktu to praca, którą człowiek obserwuje.
Ustal budżet dla wszystkiego, co jest na ścieżce użytkownika, i zatrzymuj pracę, gdy budżet się skończy. Przerwanie czekania po swojej stronie, gdy polecenie dalej działa gdzie indziej, tylko przenosi problem.
Jednorazowa migracja należy do jednorazowego zadania. Ukrywanie jej w codziennych czynnościach sprawia, że łatwiej ją napisać, a drożej uruchomić.
Testuj zabezpieczenia. Porównanie, które nic nie porównuje, wygląda dokładnie tak samo jak takie, które przeszło.

Jeśli budujesz na Mythex, nic nie musisz robić: celem jest po prostu mniej przestrzeni wyczerpujących pamięć, przy zachowaniu tak samo szybkiego otwierania projektów. Jak przestrzenie usypiają i budzą się, opisuje dokumentacja w części prywatna przestrzeń. Inną historię o wyczerpaniu pamięci znajdziesz w tekście awaria przez brak pamięci ukryta w etykiecie postępu.