Защо преместихме сървърите на Mythex на ARM

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

Какво правят сървърите ни сега

По-рано бекенд сървърите вършеха много работа директно. Около средата на септември приключихме преместването на скъпите части — пускането на кода на всеки проект, инсталирането на пакети, билдването на приложения — в частни облачни пясъчници, по един за всеки проект. Така всеки проект получава собствена изолирана среда и жив преглед.

Остана на нашите сървъри координацията: API-то, оркестраторът, който управлява пясъчниците и публикуването, удостоверяването, таксуването и входния шлюз. Тази работа е постоянна и лека. След преместването сървърите достигаха пик около 1,3 GB памет на машини с около три пъти повече.

Защо ARM

Processorite Graviton на AWS са ARM чипове, проектирани от AWS. При същата цена обикновено получавате повече capacity от сравнима x86 инстанция, или същия capacity за по-малко — а за натоварване като нашето (Node.js услуги, Docker, Postgres) нищо не ни задържа на x86.

Преместихме:

• Два сървъра за приложения от инстанции x86 със среден размер към малки Graviton инстанции с по 2 GB RAM.
• Платформената база данни от малка x86 инстанция към нейния Graviton еквивалент.

Единственото истинско усложнение: образи за две архитектури

Нашата staging среда още работи на малък x86 сървър. Продукцията вече е на ARM. Образ на контейнер, билдван за едната, няма да върви на другата.

Затова всеки образ сега се билдва за двете архитектури под един таг — мулти-архитектурен образ. Docker избира правилния вариант на всяка машина автоматично и деплой конвейерът не трябва да знае в коя среда бута. Цената е по-дълъг CI билд; ползата е, че staging и продукцията пускат точно един и същи код от точно един и същи таг.

Планиране на връщането назад преди преместването

Смяната на CPU архитектура под работеща услуга е точно от онези промени, които искате да можете да отмените за минути. Преди да превключим, ние:

• запазихме предишната версия на шаблона на сървъра като именуема цел за връщане,
• направихме снимка на базата непосредствено преди да сменим размера ѝ, и
• написахме runbook, който покрива преместването и обратния път.

Не ни трябва връщане назад. Пак бихме го направили по същия начин.

Какво да следим

По-малките сървъри имат по-малко запас. От това следват две неща:

1. Ако тежката работа някога се върне на тези сървъри, 2 GB няма да стигнат. Тогава поправката е по-голям Graviton размер, а не връщане към x86.
2. Малките машини се нуждаят от swap. Седмица по-късно един от тези сървъри замръзна от натиск на паметта, без технически да е изчерпал паметта си — историята за липсващия swap файл.

Какво взехме от това

• Измервайте отново след промени в архитектурата. Преместването на работа в пясъчници промени какво ни трябва от сървърите; размерите на инстанциите не бяха стигнали дотам.
• ARM е нисък риск и печалба за типичните уеб стекове, след като образите ви са мултиархитектурни.
• Напишете връщането първо. Прави промяната по-спокойна, дори да не я ползвате никога.