Proč jsme přesunuli servery Mythexu na ARM

1. září jsme produkční backend Mythexu přesunuli z x86 serverů na menší ARM servery AWS Graviton a platformovou databázi také na instanci Graviton. Spouštěčem bylo prosté: poté, co jsme těžkou práci – běh a sestavování aplikace každého uživatele – přesunuli do izolovaných sandboxů jednotlivých projektů, naše hlavní servery dosahovaly špičky kolem třetiny paměti. Menší ARM stroje odpovídají skutečnému zatížení a snížily měsíční účet za servery zhruba o 30 %.

Co naše servery dělají teď

Dřív backendové servery dělaly spoustu práce přímo. Kolem poloviny září jsme dokončili přesun drahých částí – běhu kódu každého projektu, instalace balíčků, sestavování aplikací – do soukromých cloudových sandboxů, jednoho na projekt. Díky tomu má každý projekt i vlastní izolované prostředí a živý náhled.

Na našich vlastních serverech zůstala koordinace: API, orchestrátor, který spravuje sandboxy a publikování, autentizace, fakturace a brána. Ta práce je stálá a lehká. Po přesunu servery dosahovaly špičky kolem 1,3 GB paměti na strojích s asi trojnásobnou kapacitou.

Proč ARM

Procesory Graviton od AWS jsou ARM čipy, které navrhl AWS. Za stejné peníze obvykle dostanete víc výkonu než u srovnatelné x86 instance, nebo stejný výkon za méně – a pro zátěž jako naše (služby v Node.js, Docker, Postgres) nás nic k x86 neváže.

Přesunuli jsme:

• Dva aplikační servery z instancí x86 střední velikosti na malé instance Graviton se 2 GB RAM každá.
• Platformovou databázi z malé x86 databázové instance na její ekvivalent Graviton.

Jedna skutečná komplikace: obrazy pro dvě architektury

Náš staging stále běží na malém x86 serveru. Produkce teď běží na ARM. Kontejnerový obraz sestavený pro jednu architekturu na té druhé neběží.

Každý obraz se proto nyní sestavuje pro obě architektury pod jednou značkou – multi-arch obraz. Docker na každém stroji automaticky vybere správnou variantu a pipeline nasazení nemusí vědět, do kterého prostředí nahrává. Cena je delší sestavení v CI; přínos je, že staging a produkce běží přesně stejný kód ze stejné značky.

Plánování návratu ještě před přesunem

Změna architektury CPU pod živou službou je přesně ten druh změny, který chcete být schopni vrátit během minut. Před přepnutím jsme:

• ponechali předchozí verzi šablony serveru jako pojmenovaný cíl pro návrat,
• před změnou velikosti databáze pořídili její snímek a
• sepsali runbook pokrývající přesun i cestu zpět.

Návrat jsme nepotřebovali. Udělali bychom to znovu stejně.

Na co si dát pozor

Menší servery mají méně rezervy. Z toho plynou dvě věci:

1. Pokud se těžká práce kdy vrátí na tyto servery, 2 GB nebude stačit. Řešením pak bude větší velikost Graviton, ne návrat k x86.
2. Malé stroje potřebují swap. O týden později jeden z těchto serverů zamrzl kvůli tlaku na paměť, aniž by technicky došla paměť – příběh chybějícího swapového souboru.

Co jsme si z toho odnesli

• Po změnách architektury přeměřte. Přesun práce do sandboxů změnil, co naše servery potřebují; velikosti instancí tomu nestačily.
• ARM je málo rizikový zisk pro typické webové stacky, jakmile jsou vaše obrazy multi-arch.
• Nejdřív napište návrat. I když ho nikdy nepoužijete, změna se tak dělá klidněji.