Prečo sme presunuli servery Mythex na ARM

1. septembra sme produkčný backend Mythexu presunuli z x86 serverov na menšie ARM servery AWS Graviton a platformovú databázu sme tiež presunuli na Graviton inštanciu. Dôvod bol jednoduchý: potom, čo sme ťažkú prácu — spúšťanie a budovanie aplikácie každého používateľa — presunuli do izolovaných sandboxov jednotlivých projektov, naše hlavné servery pri špičke využívali približne tretinu pamäte. Menšie ARM stroje zodpovedajú skutočnej záťaži a mesačný účet za servery znížili zhruba o 30 %.

Čo naše servery robia teraz

Skôr išla veľká časť práce priamo cez naše backendové servery. Okolo polovice septembra sme dokončili presun drahých častí — spúšťanie kódu každého projektu, inštalovanie balíčkov, budovanie aplikácií — do súkromných cloudových sandboxov, jeden na projekt. Práve to dáva každému projektu vlastné izolované prostredie a živý náhľad.

Na našich serveroch zostala koordinácia: API, orchestrátor, ktorý spravuje sandboxy a publikovanie, autentifikácia, fakturácia a gateway. Táto práca je stála a ľahká. Po presune sa servery pri špičke pohybovali okolo 1,3 GB pamäte na strojoch s približne trojnásobnou kapacitou.

Prečo ARM

Procesory AWS Graviton sú ARM čipy, ktoré navrhol AWS. Za rovnaké peniaze zvyčajne dostanete viac výkonu než porovnateľná x86 inštancia, alebo rovnaký výkon lacnejšie — a pre takú záťaž, ako je naša (Node.js služby, Docker, Postgres), nás nič neviaže na x86.

Presunuli sme:

• Dva aplikačné servery z stredne veľkých x86 inštancií na malé Graviton inštancie s 2 GB RAM každá.
• Platformovú databázu z malej x86 databázovej inštancie na jej Graviton ekvivalent.

Jedna skutočná komplikácia: obrazy pre dve architektúry

Náš staging stále beží na malom x86 serveri. Produkcia teraz beží na ARM. Container image zostavený pre jednu z nich na druhej nepobeží.

Preto je teraz každý image zostavený pre obe architektúry pod jedným tagom — multi-arch image. Docker si na každom stroji automaticky vyberie správnu variantu a deploy pipeline nemusí vedieť, do ktorého prostredia pushuje. Cenou je dlhšie CI budovanie; prínosom je, že staging a produkcia bežia presne rovnaký kód z presne rovnakého tagu.

Plánovanie rollbacku pred presunom

Zmena CPU architektúry pod živou službou je presne ten typ zmeny, ktorú chcete vedieť vrátiť späť v priebehu minút. Pred prepnutím sme:

• ponechali predchádzajúcu verziu šablóny servera ako pomenovaný cieľ pre rollback,
• pred zmenou veľkosti databázy vytvorili jej snapshot a
• napísali runbook, ktorý pokrýva presun aj cestu späť.

Rollback sme nepotrebovali. Urobili by sme to rovnako znova.

Na čo by sme si dávali pozor

Menšie servery majú menšiu rezervu. Z toho vyplývajú dve veci:

1. Ak sa ťažká práca niekedy presunie späť na tieto servery, 2 GB nebude stačiť. Riešením potom bude väčšia Graviton veľkosť, nie návrat na x86.
2. Malé stroje potrebujú swap. O týždeň jeden z týchto serverov zamrzol kvôli tlaku na pamäť, hoci technicky nedošla pamäť — príbeh o chýbajúcom swap súbore.

Čo sme si z toho odniesli

• Po zmenách architektúry znovu merajte. Presun práce do sandboxov zmenil, čo naše servery potrebujú; veľkosti inštancií to ešte nedobehli.
• ARM je nízkorizikový zisk pre typické webové stacky, keď sú vaše obrazy multi-arch.
• Najprv napíšte rollback. Zjednoduší to zmenu, aj keď ho nikdy nepoužijete.