Почему мы перенесли серверы Mythex на ARM

19 сентября мы перенесли продакшен-бэкенд Mythex с серверов x86 на меньшие серверы AWS Graviton на базе ARM, а базу данных платформы тоже перевели на инстанс 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. Маленьким машинам нужна подкачка. Неделю спустя один из этих серверов завис из-за нехватки памяти, хотя формально она не закончилась, — история про отсутствующий файл подкачки.

Что мы из этого вынесли

• Пересчитывайте нагрузку после смены архитектуры. Перенос работы в песочницы изменил то, что нужно нашим серверам; размеры инстансов не успели измениться.
• ARM — малорисковая победа для типичных веб-стеков, если ваши образы мультиархитектурные.
• Сначала пишите откат. Он делает изменение спокойнее, даже если вы им ни разу не воспользуетесь.