Miért költöztettük a Mythex szervereit ARM-re

Szeptember 19-én az éles Mythex-backendet x86 szerverekről kisebb, ARM alapú AWS Graviton szerverekre költöztettük, az adatbázist pedig szintén egy Graviton-példányra. Az indok egyszerű volt: miután a nehéz munkát — minden felhasználó appjának futtatását és építését — izolált, projektenkénti sandboxokba helyeztük át, a fő szervereink memóriájának körülbelül egyharmadát használták csúcsidőben. A kisebb ARM-gépek jobban illenek a valós terheléshez, és a havi szerverszámlát nagyjából 30%-kal csökkentik.

Mit csinálnak most a szervereink

Korábban a backend szerverek sok munkát közvetlenül végeztek. Szeptember közepére befejeztük a drága részek átköltöztetését — minden projekt kódjának futtatását, csomagok telepítését, appok építését — privát felhő-sandboxokba, projektenként egybe. Ez adja minden projektnek a saját elszigetelt környezetét és élő előnézetét is.

A saját szervereinken maradt a koordináció: az API, az orchestrator, amely a sandboxokat és a publikálást kezeli, a hitelesítés, a számlázás és az átjáró. Ez a munka állandó és könnyű. Az átköltöztetés után a szerverek csúcsidőben körülbelül 1,3 GB memóriát használtak, háromszor akkora gépeken.

Miért ARM

Az AWS Graviton processzorai az AWS által tervezett ARM-chipek. Ugyanannyi pénzért általában több kapacitást kapsz, mint egy hasonló x86-os példányon, vagy ugyanazt kevesebbért — egy olyan terhelésnél, mint a miénk (Node.js-szolgáltatások, Docker, Postgres), semmi nem köt x86-hoz.

Az alábbiakat költöztettük:

• Két app-szerver közepes x86-os példányokról kis Graviton-példányokra, mindegyik 2 GB RAM-mal.
• A platform-adatbázist egy kis x86-os adatbázis-példányról annak Graviton-megfelelőjére.

Az egyetlen igazi bonyodalom: két architektúrára szóló képek

A stagingkörnyezetünk még egy kis x86-os szerveren fut. Az éles környezet most ARM. Egy konténerkép, amelyet az egyikre építettek, nem fut a másikon.

Ezért minden kép most mindkét architektúrára egy taggel épül — ez egy multi-arch kép. A Docker minden gépen automatikusan a megfelelő változatot választja, a deploy-folyamatnak pedig nem kell tudnia, melyik környezetbe tölt fel. Az ára hosszabb CI-build; az előnye, hogy a staging és az éles környezet pontosan ugyanazt a kódot futtatja ugyanabból a taggből.

Visszavonási terv az átköltözés előtt

Élő szolgáltatás CPU-architektúrájának megváltoztatása olyan változtatás, amelyet percek alatt szeretnél visszacsinálni. Váltás előtt:

• megtartottuk az előző szervertemplate-verziót, mint elnevezett visszaállítási célt,
• adatbázis-pillanatképet készítettünk közvetlenül az adatbázis átméretezése előtt, és
• runbookot írtunk, amely lefedi az átköltözést és a visszautat.

A visszavonásra nem volt szükség. Ugyanúgy csinálnánk újra.

Mire figyelnénk

A kisebb szervereknek kevesebb tartalékuk van. Ebből két dolog következik:

1. Ha a nehéz munka valaha visszakerül ezekre a szerverekre, a 2 GB nem lesz elég. A megoldás akkor egy nagyobb Graviton-méret, nem a visszatérés x86-ra.
2. A kis gépeknek kell swap. Egy héttel később az egyik ilyen szerver a memórianyomástól lefagyott anélkül, hogy technikailag elfogyott volna a memória — a hiányzó swap-fájl története.

Amit ebből tanultunk

• Architektúra-váltás után mérd újra. A sandboxokba való átköltözés megváltoztatta, mire volt szükségünk a szervereken; a példányméretek nem igazodtak hozzá.
• Az ARM alacsony kockázatú nyereség tipikus webes stackeknél, ha a képeid multi-arch-ak.
• Előbb írd meg a visszavonást. Nyugodtabbá teszi a változtatást, még ha soha nem is használod.