Kwa Nini Tulihamisha Seva za Mythex Kwenda ARM

Tarehe 19 Septemba tulihamisha backend ya uzalishaji ya Mythex kutoka seva za x86 kwenda seva ndogo za AWS Graviton zenye ARM, na tukahamisha pia database ya jukwaa kwenda instance ya Graviton. Kichochezi kilikuwa rahisi: baada ya kuhamisha kazi nzito — kuendesha na kujenga app ya kila mtumiaji — kwenye sandboxes zilizotengwa za kila mradi, seva zetu kuu zilikuwa zikifikia kilele cha takriban theluthi moja ya kumbukumbu yao. Mashine ndogo za ARM zinatosha mzigo halisi na zinapunguza bili ya seva ya kila mwezi kwa takriban 30%.

Seva zetu sasa zinafanya nini

Awali, seva za backend zilifanya kazi nyingi moja kwa moja. Karibu katikati ya Septemba tulimaliza kuhamisha sehemu ghali — kuendesha msimbo wa kila mradi, kusakinisha packages, kujenga apps — kwenda sandboxes za wingu za faragha, moja kwa kila mradi. Hiyo ndiyo pia inayompa kila mradi mazingira yake yaliyotengwa na preview ya moja kwa moja.

Kilichobaki kwenye seva zetu ni uratibu: API, orchestrator inayosimamia sandboxes na uchapishaji, uthibitishaji, bili, na gateway. Kazi hiyo ni thabiti na nyepesi. Baada ya kuhamisha, seva zilifikia kilele cha takriban GB 1.3 za kumbukumbu kwenye mashine zenye takriban mara tatu ya hiyo.

Kwa nini ARM

Processors za Graviton za AWS ni chips za ARM zilizobuniwa na AWS. Kwa gharama sawa kwa kawaida unapata uwezo zaidi kuliko instance linganifu ya x86, au uwezo uleule kwa bei nafuu — na kwa mzigo kama wetu (huduma za Node.js, Docker, Postgres) hakuna kinachotufunga kwenye x86.

Tulihamisha:

• Seva mbili za app kutoka instances za x86 za ukubwa wa kati kwenda instances ndogo za Graviton zenye GB 2 za RAM kila moja.
• Database ya jukwaa kutoka instance ndogo ya database ya x86 kwenda sawa yake ya Graviton.

Changamoto moja halisi: picha kwa usanifu wawili

Mazingira yetu ya staging bado yanaendeshwa kwenye seva ndogo ya x86. Uzalishaji sasa unaendeshwa kwenye ARM. Picha ya container iliyojengwa kwa moja haiendeshwi kwenye nyingine.

Kwa hiyo kila picha sasa inajengwa kwa usanifu wote wawili chini ya tag moja — picha ya multi-arch. Docker inachagua toleo sahihi kwenye kila mashine kiotomatiki, na pipeline ya deploy haihitaji kujua inasukuma kwenye mazingira gani. Gharama ni build ya CI ndefu zaidi; faida ni kwamba staging na uzalishaji zinaendesha msimbo uleule kabisa kutoka tag uleule.

Kupanga rollback kabla ya kuhamisha

Kubadilisha usanifu wa CPU chini ya huduma hai ni aina ya mabadiliko unayotaka kuweza kuyarudisha ndani ya dakika. Kabla ya kubadilisha, tulifanya:

• kuhifadhi toleo la awali la template ya seva kama lengo lenye jina la rollback,
• kuchukua snapshot ya database muda mfupi kabla ya kubadilisha ukubwa wake, na
• kuandika runbook inayofunika mabadiliko na njia ya kurudi.

Hatukuhitaji rollback. Bado tungefanya kwa njia ile ile.

Tuliyopaswa kuangalia

Seva ndogo zina nafasi ndogo ya kupumua. Mambo mawili yanafuata:

1. Kazi nzito ikirudi kwenye seva hizi siku moja, GB 2 hazitatosha. Suluhisho basi ni ukubwa mkubwa zaidi wa Graviton, si kurudi x86.
2. Mashine ndogo zinahitaji swap. Wiki moja baadaye mojawapo ya seva hizi iliganda kwa shinikizo la kumbukumbu bila kwa kweli kuishiwa — hadithi ya faili la swap lililokosekana.

Tulichojifunza

• Pima tena baada ya mabadiliko ya usanifu. Kuhamisha kazi kwenda sandboxes kulibadilisha kile seva zetu zilichohitaji; ukubwa wa instances haukuwa umefikia bado.
• ARM ni faida yenye hatari ndogo kwa stacks za kawaida za wavuti mara picha zako zikiwa multi-arch.
• Andika rollback kwanza. Inafanya mabadiliko kuwa tulivu hata kama hutaitumia kamwe.