Af hverju við færðum þjóna Mythex yfir á ARM

1. september færðum við framleiðslubakenda Mythex frá x86-þjónum yfir á minni ARM-þjóna sem byggjast á AWS Graviton, og færðum líka gagnagrunn vettvangsins yfir á Graviton-tilvik. Kveikjan var einföld: eftir að við höfðum fært þunga vinnuna, að keyra og smíða forrit hvers notanda, inn í einangraða sandkassa fyrir hvert verkefni, fór álagstoppur aðalþjónanna í um þriðjung af minninu. Minni ARM-vélar passa við raunverulegt álag og lækkuðu mánaðarlegan þjónareikning um um 30%.

Hvað þjónarnir okkar gera núna

Fyrr á tímanum gerðu bakendaþjónarnir mikla vinnu beint. Um miðjan september kláruðum við að færa dýru hlutana, að keyra kóða hvers verkefnis, setja upp pakka og smíða forrit, yfir í einkasandkassa í skýinu, einn fyrir hvert verkefni. Það gefur líka hverju verkefni sitt eigið einangraða umhverfi og lifandi forsýningu.

Það sem var áfram á eigin þjónum okkar er samhæfingin: API-ið, orchestrator sem stýrir sandkössum og birtingu, auðkenning, reikningagerð og gáttin. Sú vinna er stöðug og létt. Eftir flutninginn voru þjónarnir í álagstoppi í um 1,3 GB af minni á vélum með um þrefalt meira.

Af hverju ARM

Graviton-örgjörvar AWS eru ARM-flögur sem AWS hannar. Fyrir sama verð færðu yfirleitt meiri afkastagetu en sambærilegt x86-tilvik, eða sömu afkastagetu fyrir minna, og fyrir álag eins og okkar (Node.js-þjónustur, Docker, Postgres) er ekkert sem bindur okkur við x86.

Við færðum:

• Tvo forritaþjóna úr meðalstórum x86-tilvikum yfir í litla Graviton-tilvik með 2 GB vinnsluminni hvort.
• Gagnagrunn vettvangsins úr litlu x86-gagnagrunnstilviki yfir í Graviton-hliðstæðuna.

Eina raunverulega flækjan: myndir fyrir tvær örgjörvagerðir

Staging-umhverfið okkar keyrir enn á litlum x86-þjóni. Framleiðslan keyrir núna á ARM. Gámamynd sem er smíðuð fyrir aðra keyrir ekki á hinni.

Þess vegna er hver mynd nú smíðuð fyrir báðar örgjörvagerðirnar undir einu merki, fjölarkitektúr-mynd (multi-arch). Docker velur réttu útgáfuna á hverri vél sjálfkrafa, og birtingarferlið þarf ekki að vita í hvaða umhverfi það ýtir út. Kostnaðurinn er lengri CI-smíð; ávinningurinn er að staging og framleiðsla keyra nákvæmlega sama kóða úr nákvæmlega sama merki.

Að skipuleggja afturköllun áður en flutt er

Að skipta um örgjörvaarkitektúr undir þjónustu í gangi er það sem þú vilt geta afturkallað á nokkrum mínútum. Áður en við skiptum gerðum við þetta:

• héldum fyrri þjónasniðmátinu sem nefndu afturköllunarmarki,
• tókum gagnagrunnsafrit rétt áður en við breyttum stærð gagnagrunnsins, og
• skrifuðum runbook sem nær yfir flutninginn og leiðina til baka.

Við þurftum ekki afturköllunina. Við myndum samt gera hana eins.

Hverju við myndum fylgjast með

Minni þjónar hafa minna svigrúm. Tvennt leiðir af því:

1. Ef þung vinna færist einhvern tímann aftur á þessa þjóna duga 2 GB ekki. Lausnin þá er stærri Graviton-stærð, ekki að fara aftur yfir á x86.
2. Litlar vélar þurfa skiptisvæði. Viku síðar frysti einn af þessum þjónum vegna minnisálags án þess að hafa tæknilega klárað minnið — sagan um vanta skiptiskrá.

Það sem við lærðum

• Mældu aftur eftir arkitektúrbreytingar. Að færa vinnu í sandkassa breytti því hvað þjónarnir okkar þurftu; stærðir tilvikanna höfðu ekki náð því.
• ARM er áhættulítill ávinningur fyrir venjulega vefstafla þegar myndirnar þínar eru fjölarkitektúr.
• Skrifaðu afturköllunina fyrst. Það gerir breytinguna rólegri, jafnvel þótt þú notir hana aldrei.