Miks viisime Mythexi serverid ARM-ile

1. septembril viisime Mythexi tootmise tagaosa x86-serveritelt väiksematele ARM-põhistele AWS Graviton-serveritele ning viisime ka platvormi andmebaasi Graviton-instantsile. Põhjus oli lihtne: pärast seda, kui kolisime raske töö — iga kasutaja rakenduse käitamise ja ehitamise — eraldatud projektipõhistesse liivakastidesse, kasutasid meie peaserverid oma mälust tippudes umbes kolmandikku. Väiksemad ARM-masinad sobivad päris koormusega ja vähendasid kuist serverikulu umbes 30%.

Mida meie serverid nüüd teevad

Varem tegid tagaosa serverid palju tööd otse. Septembri keskpaigaks olime lõpetanud kalliste osade kolimise — iga projekti koodi käitamise, paketi paigaldamise ja rakenduse ehitamise — privaatsetesse pilveliivakastesse, ühte projekti kohta. Sama annab igale projektile oma isoleeritud keskkonna ja elava eelvaate.

Meie enda serveritele jäi koordineerimine: API, orkestraator, mis haldab liivakaste ja avaldamist, autentimine, arveldus ja väravas. See töö on ühtlane ja kerge. Pärast kolimist tippusid serverid umbes 1,3 GB mälu juures masinatel, kus on umbes kolm korda rohkem.

Miks ARM

AWS-i Graviton-protsessorid on ARM-kiibid, mille on disainind AWS. Sama raha eest saad üldiselt rohkem võimsust kui võrreldav x86-instants või sama võimsuse odavamalt — ja meie koormuse puhul (Node.js-teenused, Docker, Postgres) ei seo meid miski x86-ga.

Me kolisime:

• kaks rakendusserverit keskmise suurusega x86-instantsidelt väikestele Graviton-instantsidele, igaühel 2 GB RAM-i,
• platvormi andmebaasi väikeselt x86-andmebaasi instantsilt selle Graviton-vastele.

Üks päris keerukus: pildid kahele arhitektuurile

Meie stagingukeskkond töötab veel väikesel x86-serveril. Tootmine töötab nüüd ARM-il. Ühele ehitatud konteineripilt ei tööta teisel.

Seetõttu ehitatakse iga pilt nüüd mõlemale arhitektuurile ühe sildi all — multi-arch-pilt. Docker valib igal masinal automaatselt õige variandi ja deploy-torustik ei pea teadma, millisesse keskkonda ta saadab. Hind on pikem CI-ehitus; kasu on see, et staging ja tootmine jooksevad täpselt sama koodiga täpselt samast sildist.

Tagasivõtu planeerimine enne kolimist

Protsessori arhitektuuri muutmine elava teenuse all on muutus, mida tahad saada minutitega tagasi võtta. Enne lülitamist:

• hoidsime eelmise serveri malli versiooni nimega tagasivõtmise sihtmärgina,
• tegime andmebaasist hetktõmmise vahetult enne andmebaasi suuruse muutmist ja
• kirjutasime juhendi, mis katab kolimise ja tagasitee.

Tagasivõttu ei vajanud. Teeksime seda samamoodi uuesti.

Mida jälgida

Väiksematel serveritel on vähem varu. Sellest järgneb kaks asja:

1. Kui raske töö kunagi nendele serveritele tagasi kolib, ei piisa 2 GB-st. Parandus on siis suurem Graviton-suurus, mitte tagasipöördumine x86-le.
2. Väikesed masinad vajavad swap-i. Nädal hiljem külmus üks neist serveritest mälusurve tõttu, ilma et ta tehniliselt mälu otsa oleks saanud — lugu puuduvast swap-failist.

Mida sellest õppisime

• Mõõda pärast arhitektuurimuutusi uuesti. Töö kolimine liivakastidesse muutis seda, mida meie serverid vajasid; instantsisuurused polnud järele jõudnud.
• ARM on madala riskiga võit tavapäraste veebipinude puhul, kui su pildid on multi-arch.
• Kirjuta tagasivõtt esimesena. See muudab muutuse rahulikumaks, isegi kui seda kunagi ei kasuta.