Miksi siirsimme Mythexin palvelimet ARM-prosessoreihin

Syyskuun 19. päivänä siirsimme Mythexin tuotannon taustapalvelun x86-palvelimilta pienempiin ARM-pohjaisiin AWS Graviton -palvelimiin ja siirsimme myös alustan tietokannan Graviton-instanssiin. Syy oli yksinkertainen: sen jälkeen kun siirsimme raskaan työn, eli jokaisen käyttäjän sovelluksen ajamisen ja rakentamisen, eristettyihin projektikohtaisiin sandboxeihin, pääpalvelimemme käyttivät noin kolmasosan muististaan huipussaan. Pienemmät ARM-koneet sopivat todelliseen kuormaan ja leikkasivat kuukausittaisen palvelinlaskun noin 30 %.

Mitä palvelimemme tekevät nyt

Aiemmin taustapalvelimet tekivät paljon työtä suoraan. Noin syyskuun puolivälissä saimme valmiiksi kalliiden osien siirron — jokaisen projektin koodin ajamisen, pakettien asennuksen ja sovellusten rakentamisen — yksityisiin pilvisandboxeihin, yhteen per projekti. Juuri se antaa jokaiselle projektille oman eristetyn ympäristön ja elävän esikatselun.

Omille palvelimillemme jäi koordinointi: API, orkestroija, joka hallinnoi sandboxeja ja julkaisua, todennus, laskutus ja yhdyskäytävä. Se työ on tasaista ja kevyttä. Siirron jälkeen palvelimet huipussaan käyttivät noin 1,3 Gt muistia koneissa, joissa oli noin kolminkertainen määrä.

Miksi ARM

AWS:n Graviton-prosessorit ovat AWS:n suunnittelemia ARM-siruja. Samalla hinnalla saat yleensä enemmän kapasiteettia kuin vastaavalla x86-instanssilla, tai saman kapasiteetin halvemmalla — ja meidän kuormallemme (Node.js-palvelut, Docker, Postgres) ei ole mitään, mikä sitoisi meidät x86:een.

Siirsimme:

• Kaksi sovelluspalvelinta keskikokoisista x86-instansseista pieniin Graviton-instansseihin, joissa kummassakin on 2 Gt RAM:ia.
• Alustan tietokannan pienestä x86-tietokanta-instanssista sen Graviton-vastineeseen.

Yksi todellinen mutkikkuus: kuvat kahdelle arkkitehtuurille

Stagingympäristömme toimii yhä pienellä x86-palvelimella. Tuotanto toimii nyt ARM:illa. Konttikuva, joka on rakennettu toiselle, ei toimi toisella.

Joten jokainen kuva rakennetaan nyt molemmille arkkitehtuureille yhden tagin alla — monen arkkitehtuurin kuvana. Docker valitsee oikean version kullakin koneella automaattisesti, eikä käyttöönottoputken tarvitse tietää, mihin ympäristöön se työntää. Hinta on pidempi CI-build; hyöty on, että staging ja tuotanto ajavat täsmälleen samaa koodia samasta tagista.

Paluun suunnittelu ennen siirtoa

Suorittimen arkkitehtuurin vaihtaminen käynnissä olevan palvelun alla on sellainen muutos, jonka haluat pystyä perumaan minuuteissa. Ennen vaihtoa me:

• säilytimme edellisen palvelinmallin versiona nimettynä paluukohteena,
• otimme tietokantakuvan juuri ennen tietokannan koon muuttamista, ja
• kirjoitimme käyttöohjeen, joka kattaa siirron ja paluun.

Emme tarvinneet paluuta. Tekisimme sen silti samalla tavalla.

Mitä seuraamme

Pienemmillä palvelimilla on vähemmän varaa. Siitä seuraa kaksi asiaa:

1. Jos raskas työ siirtyy takaisin näille palvelimille, 2 Gt ei riitä. Silloin ratkaisu on suurempi Graviton-koko, ei paluu x86:een.
2. Pienet koneet tarvitsevat swapin. Viikko myöhemmin yksi näistä palvelimista jäätyi muistipaineeseen, vaikka muisti ei teknisesti loppunut — tarina puuttuvasta swap-tiedostosta.

Mitä tästä opimme

• Mittaa uudelleen arkkitehtuurimuutosten jälkeen. Raskaan työn siirto sandboxeihin muutti sitä, mitä palvelimemme tarvitsivat; instanssikoot eivät olleet ehtineet perässä.
• ARM on matalan riskin voitto tyypillisille web-pinoille, kun kuvasi ovat monen arkkitehtuurin kuvia.
• Kirjoita paluu ensin. Se tekee muutoksesta rauhallisemman, vaikka et koskaan käyttäisi sitä.