Чому ми перенесли сервери Mythex на ARM

Дев'ятнадцятого вересня ми перенесли виробничий бекенд Mythex із x86-серверів на менші ARM-сервери AWS Graviton, а також перевели базу платформи на інстанс Graviton. Причина була проста: після того як ми перенесли важку роботу (запуск і збірку застосунку кожного користувача) в ізольовані пісочниці проєктів, наші основні сервери використовували близько третини пам'яті в піковий час. Менші ARM-машини відповідають реальному навантаженню й зменшують місячний рахунок за сервери приблизно на 30%.

Що наші сервери роблять тепер

Раніше бекенд-сервери виконували багато роботи безпосередньо. Близько середини вересня ми перенесли дорогі частини (запуск коду кожного проєкту, встановлення пакетів, збірку застосунків) в приватні хмарні пісочниці, по одній на проєкт. Саме це дає кожному проєкту власне ізольоване середовище та живий попередній перегляд.

На наших серверах залишилася координація: API, оркестратор, що керує пісочницями та публікацією, автентифікація, білінг і шлюз. Ця робота стабільна й легка. Після переходу сервери в піку використовували близько 1,3 ГБ пам'яті на машинах, що мають приблизно втричі більше.

Чому ARM

Процесори Graviton від AWS це ARM-чіпи, які спроєктувала AWS. За ті самі гроші зазвичай отримуєш більше обчислювальної потужності, ніж від порівнянного x86-інстансу, або таку саму потужність дешевше, а для такого навантаження, як наше (сервіси Node.js, Docker, Postgres), нічого не прив'язує нас до x86.

Ми перенесли:

• Два сервери застосунків із інстансів x86 середнього розміру на невеликі інстанси Graviton з 2 ГБ оперативної пам'яті кожен.
• Базу даних платформи з невеликого x86-інстансу бази даних на його еквівалент Graviton.

Одна справжня складність: образи для двох архітектур

Наше тестове середовище досі працює на невеликому x86-сервері. Продакшен тепер працює на ARM. Образ контейнера, зібраний для однієї архітектури, на іншій не запуститься.

Тому тепер кожен образ збирається для обох архітектур під одним тегом, це мультиархітектурний образ. Docker сам вибирає потрібний варіант на кожній машині, і конвеєр розгортання не має знати, в яке середовище він надсилає образ. Ціна це довша збірка в CI; вигода в тому, що тестове середовище і продакшен запускають абсолютно той самий код з абсолютно того самого тегу.

Планування відкату до перенесення

Зміна архітектури процесора під працюючим сервісом це зміна, яку хочеться мати змогу скасувати за лічені хвилини. Перед перемиканням ми:

• зберегли попередню версію шаблону сервера як іменовану ціль для відкату,
• зробили знімок бази даних безпосередньо перед зміною розміру бази,
• написали runbook, що описує перенесення і шлях назад.

Відкат нам не знадобився. Ми зробили б так само й знову.

Що ми будемо відстежувати

Менші сервери мають менше запасу. З цього випливає дві речі:

1. Якщо важка робота колись знову перейде на ці сервери, 2 ГБ не вистачить. Тоді вирішенням буде більший розмір Graviton, а не повернення до x86.
2. Малим машинам потрібен swap. Через тиждень один із цих серверів завис від нестачі пам'яті, хоча формально вона не закінчилася: історія про відсутній файл підкачки.

Що ми з цього взяли

• Вимірюйте заново після змін архітектури. Перенесення роботи в пісочниці змінило те, що потрібно нашим серверам, а розміри інстансів не встигли за цим.
• ARM це маловизначний виграш для типових веб-стеків, коли ваші образи мультиархітектурні.
• Спершу напишіть відкат. Він робить зміну спокійнішою, навіть якщо ним так і не скористаєтесь.