Зошто ги префрливме серверите на Mythex на ARM

На 19 септември ја префрливме продукциската backend инфраструктура на Mythex од x86 сервери на помали ARM сервери базирани на AWS Graviton, а и базата на платформата ја префрливме на Graviton инстанца. Поттикот беше едноставен: откако ја префрливме тешката работа — извршувањето и градењето на апликацијата на секој корисник — во изолирани sandbox средини по проект, нашите главни сервери врвеа на околу третина од својата меморија. Помали ARM машини одговараат на вистинското оптоварување и ја намалија месечната сметка за сервери за околу 30%.

Што всушност работат нашите сервери сега

Порано, backend серверите извршуваа многу работа директно. Околу средината на септември ги префрливме скапите делови — извршување на кодот на секој проект, инсталирање пакети, градење апликации — во приватни cloud sandbox средини, по една за секој проект. Тоа е и она што му дава на секој проект своја изолирана средина и жив преглед.

На нашите сервери остана координацијата: API-то, orchestrator-от што управува со sandbox-ите и објавувањето, автентикацијата, наплатата и gateway-от. Таа работа е постојана и лесна. По префрлувањето, серверите врвеа на околу 1,3 GB меморија на машини со околу три пати повеќе.

Зошто ARM

Graviton процесорите на AWS се ARM чипови дизајнирани од AWS. За истата цена, обично добивате повеќе капацитет од споредлива x86 инстанца, или истиот капацитет за помалку — а за оптоварување како нашето (Node.js сервиси, Docker, Postgres) ништо не нè врзува за x86.

Префрливме:

• Два апликациски сервери од средни x86 инстанци на мали Graviton инстанци со по 2 GB RAM.
• Базата на платформата од мала x86 база на податоци на нејзиниот Graviton еквивалент.

Единствената вистинска компликација: слики за две архитектури

Nашата staging средина сè уште работи на мал x86 сервер. Продукцијата сега работи на ARM. Container слика изградена за едната не работи на другата.

Затоа секоја слика сега се гради за двете архитектури под еден таг — multi-arch слика. Docker автоматски ја избира вистинската варијанта на секоја машина, а деплој пајплајнот не мора да знае во која средина се пушта. Цената е подолго CI градење; придобивката е што staging и продукцијата работат ист код од ист таг.

Планирање на враќањето пред префрлувањето

Промената на CPU архитектура под жив сервис е нешто што сакате да можете да го вратите назад за минути. Пред да префрлиме, ние:

• ја зачувавме претходната верзија на шаблонот на серверот како именуван цел за враќање,
• направивме snapshot на базата непосредно пред да ја промениме нејзината големина, и
• напишавме runbook што ги опфаќа префрлувањето и патот назад.

Не ни требаше враќањето. Пак би го направиле истото.

Што би требало да внимаваме

Помалите сервери имаат помалку резерва. Од тоа следуваат две работи:

1. Ако тешката работа некогаш се врати на овие сервери, 2 GB нема да бидат доволни. Тогаш решението е поголема Graviton големина, не враќање на x86.
2. Малите машини имаат потреба од swap. Една недела подоцна, еден од овие сервери се замрзна од притисок на меморија, без технички да остане без неа — приказната за недостасувачката swap датотека.

Што извлековме

• Измерете повторно по промени на архитектурата. Преместувањето на работата во sandbox-и ги промени потребите на нашите сервери; големините на инстанците не се ажурирале.
• ARM е мал ризик со висока добивка за типичните web stack-ови кога вашите слики се multi-arch.
• Прво напишете го враќањето. Тоа ја смирува промената дури и ако никогаш не го користите.