Kodėl perkėlėme Mythex serverius į ARM

Rugsėjo 19 d. perkėlėme Mythex gamybinį backend iš x86 serverių į mažesnius ARM pagrindu veikiančius AWS Graviton serverius, o platformos duomenų bazę — į Graviton egzempliorių. Priežastis buvo paprasta: perkėlus sunkų darbą — kiekvienos vartotojo programėlės paleidimą ir kūrimą — į izoliuotas projektų smėlio dėžes, mūsų pagrindiniai serveriai pikuodavo maždaug trečdaliu atminties. Mažesnės ARM mašinos tinka tikrai apkrovai ir sumažino mėnesinę serverių sąskaitą maždaug 30%.

Ką mūsų serveriai daro dabar

Anksčiau backend serveriai daug darbo atlikdavo patys. Rugsėjio viduryje baigėme perkelti brangiausias dalis — kiekvieno projekto kodo vykdymą, paketų diegimą, programėlių kūrimą — į privačias debesies smėlio dėžes, po vieną kiekvienam projektui. Būtent tai suteikia kiekvienam projektui izoliuotą aplinką ir gyvą peržiūrą.

Tai, kas liko mūsų serveriuose, yra koordinavimas: API, orkestratorius, kuris valdo smėlio dėžes ir publikavimą, autentifikacija, apmokestinimas ir šliuzas. Tas darbas stabilus ir lengvas. Po perkėlimo serveriai pikuodavo apie 1,3 GB atminties, o mašinos turėjo apie tris kartus daugiau.

Kodėl ARM

AWS Graviton procesoriai yra AWS suprojektuoti ARM lustai. Už tą pačią kainą paprastai gaunate daugiau pajėgumo nei panašus x86 egzempliorius, arba tokį patį pajėgumą pigiau — o tokiai apkrovai kaip mūsų (Node.js paslaugos, Docker, Postgres) nieko nesieja su x86.

Perkėlėme:

• Du programų serverius iš vidutinio dydžio x86 egzempliorių į mažus Graviton egzempliorius po 2 GB RAM.
• Platformos duomenų bazę iš mažo x86 duomenų bazės egzemplioriaus į jo Graviton atitikmenį.

Vienintelis tikras sudėtingumas: paveikslai dviem architektūroms

Mūsų testavimo aplinka vis dar veikia mažame x86 serveryje. Gamyba dabar veikia ARM. Konteinerio paveikslas, sukurtas vienai, kitoje neveiks.

Todėl kiekvienas paveikslas dabar kuriamas abiem architektūroms pagal vieną žymę — tai daugiaarchitektūris paveikslas. Docker automatiškai parenka tinkamą variantą kiekvienoje mašinoje, o diegimo procesui nereikia žinoti, į kurią aplinką siunčiama. Kaina — ilgesnis CI kūrimas; nauda — testavimo ir gamybos aplinkos veikia tiksliai tas pats kodas iš tos pačios žymės.

Atsarginio varianto planavimas prieš perkėlimą

Keisti procesoriaus architektūrą veikiančiam servisui yra tokio pobūdžio pakeitimas, kurį norisi galėti atšaukti per kelias minutes. Prieš perjungdami, mes:

• palikome ankstesnę serverio šablono versiją kaip pavadintą atsarginį tikslą,
• padarėme duomenų bazės kopiją prieš keisdami duomenų bazės dydį, ir
• parašėme veiksmų vadovą, aprašantį perkėlimą ir grįžimą atgal.

Grįžti neprireikė. Vis tiek darytume taip pat.

Ko stebėtume

Mažesniuose serveriuose yra mažiau laisvos vietos. Iš to išplaukia du dalykai:

1. Jei sunkus darbas kada nors vėl bus perkeltas į šiuos serverius, 2 GB nepakaks. Tada sprendimas bus didesnis Graviton dydis, o ne grįžimas prie x86.
2. Maži įrenginiai reikalauja keitimosi (swap) failo. Po savaitės vienas iš šių serverių užšalo dėl atminties spaudimo, nors formaliai atminties nebuvo visiškai išnaudota — istorija apie trūkstantį keitimosi failą.

Ką iš to pasiėmėme

• Po architektūros pakeitimų matuokite iš naujo. Perkėlus darbą į smėlio dėžes pasikeitė tai, ko reikėjo mūsų serveriams; egzempliorių dydžiai neatsilygino.
• ARM yra mažos rizikos laimėjimas tipiškoms web paslaugų kraitims, kai paveikslai yra daugiaarchitektūriai.
• Pirma parašykite grįžimo planą. Jis padaro pakeitimą ramesnį, net jei niekada juo nepasinaudojate.