Dlaczego przenieśliśmy serwery Mythex na ARM
19 września przenieśliśmy produkcyjny backend Mythex z serwerów x86 na mniejsze serwery AWS Graviton oparte na ARM, a bazę danych platformy także na instancję Graviton. Powód był prosty: po tym, jak przenieśliśmy ciężką pracę — uruchamianie i budowanie aplikacji każdego użytkownika — do odizolowanych sandboksów na projekt, nasze główne serwery w szczycie zużywały około jednej trzeciej pamięci. Mniejsze maszyny ARM pasują do rzeczywistego obciążenia i obniżają miesięczny rachunek za serwery o mniej więcej 30%.
Co teraz robią nasze serwery
Wcześniej serwery backendu wykonywały dużo pracy bezpośrednio. W połowie września dokończyliśmy przenoszenie kosztownych części — uruchamiania kodu każdego projektu, instalowania pakietów, budowania aplikacji — do prywatnych sandboksów chmurowych, po jednym na projekt. To także daje każdemu projektowi własne odizolowane środowisko i podgląd na żywo.
Na naszych serwerach zostało koordynowanie: API, orkiestrator, który zarządza sandboksami i publikacją, uwierzytelnianie, rozliczenia i brama. Ta praca jest stała i lekka. Po przeniesieniu serwery w szczycie zużywały około 1,3 GB pamięci na maszynach mających około trzy razy tyle.
Dlaczego ARM
Procesory Graviton od AWS to chipy ARM zaprojektowane przez AWS. Za te same pieniądze zwykle dostajesz więcej mocy niż z porównywalną instancją x86 albo tę samą moc taniej — a przy obciążeniu takim jak nasze (usługi Node.js, Docker, Postgres) nic nie wiąże nas z x86.
Przenieśliśmy:
- Dwa serwery aplikacji z instancji x86 średniej wielkości na małe instancje Graviton z 2 GB RAM każda.
- Bazę danych platformy z małej instancji bazy x86 na jej odpowiednik Graviton.
Jedna prawdziwa komplikacja: obrazy dla dwóch architektur
Nasze środowisko stagingowe nadal działa na małym serwerze x86. Produkcja działa teraz na ARM. Obraz kontenera zbudowany dla jednej architektury nie uruchomi się na drugiej.
Dlatego każdy obraz jest teraz budowany dla obu architektur pod jednym tagiem — obraz multi-arch. Docker sam wybiera właściwy wariant na każdej maszynie, a pipeline wdrożeniowy nie musi wiedzieć, do którego środowiska wypycha. Koszt to dłuższy build CI; zysk jest taki, że staging i produkcja uruchamiają dokładnie ten sam kod z dokładnie tego samego tagu.
Zaplanowanie wycofania przed przeniesieniem
Zmiana architektury procesora pod działającą usługą to coś, co chcesz móc cofnąć w kilka minut. Przed przełączeniem:
- zachowaliśmy poprzednią wersję szablonu serwera jako nazwany cel wycofania,
- zrobiliśmy migawkę bazy tuż przed zmianą rozmiaru bazy, i
- napisaliśmy runbook obejmujący przeniesienie i drogę powrotną.
Nie musieliśmy wycofywać. Zrobilibyśmy to tak samo jeszcze raz.
Na co uważamy
Mniejsze serwery mają mniejszy zapas. Z tego wynikają dwie rzeczy:
- Jeśli ciężka praca kiedykolwiek wróci na te serwery, 2 GB nie wystarczy. Rozwiązaniem będzie wtedy większy rozmiar Graviton, a nie powrót do x86.
- Małe maszyny potrzebują wymiany. Tydzień później jeden z tych serwerów zamarzł od presji pamięci, mimo że technicznie nie zabrakło pamięci — historia brakującego pliku wymiany.
Co z tego wynieśliśmy
- Mierz ponownie po zmianach architektury. Przeniesienie pracy do sandboksów zmieniło to, czego potrzebowały nasze serwery; rozmiary instancji nie nadążyły.
- ARM to tani zysk dla typowych stosów webowych, gdy Twoje obrazy są multi-arch.
- Najpierw napisz wycofanie. Sprawia, że zmiana jest spokojniejsza, nawet jeśli nigdy z niego nie skorzystasz.