Построение тестовых окружений из веток и желудей

Дисклеймер

В статье используются антипаттерны построения отказоустойчивых систем. Описанное может привести к потере данных, простою стенда или использующей его команды.

Без использования IaC и без глубокого знания ОС повторение концепта не приведет к желаемому результату. Только к краху и тупику, достижению неуспеха.

В команде должен быть DevOps или системный администратор, который сможет реализовать и поддерживать систему.

Когда это может быть полезно

  • Если проект требователен к ресурсам (RAM, дисковое пространство).
  • Если есть большие датасеты, полное дублирование которых не целесообразно экономически.
  • Бюджет на тестовые окружения сильно ограничен, разница между стоимостью облачных ресурсов и использованием bare metal неблагоприятно влияет на проект.
  • Есть неиспользуемое оборудование.
  • Стенд может простаивать и не критична его постоянная доступность.
  • Проект невозможно затащить в k8s по технической причине или нецелесообразности.

Pros and Cons

Ветки и желуди
Облако

Примечание

Стоимость
+
-
До 6 раз в пользу bare metal

(на примере Selectel:
  • Bare metal: 6 Cores, 64G RAM, 2x480 SSH - ~6 т.р/мес.;
  • Cloud VM: ~38 т.р./мес.;
  • K8s: ~41 т.р./мес.)
Простота управления
-
+
Требует знаний администрирования
Надежность
-
+
Может сломаться и придется самостоятельно решать проблемы с оборудованием

Концепт

  • Берем железо, близкое по стоимости к $40 за сервер, в необходимом количестве.
  • Используем ansible для первичной подготовки (установка софта, переразбивка дисков, настройка сети и т.д.).
  • Для обеспечения связности используем оверлей сеть на базе tinc vpn или openvswitch.
  • Вместо ВМ используем lxc контейнеры с стораджем на базе zfs.
  • Для развертывания контейнеров используем terraform.
  • Ассеты храним во внешнем хранилище, что позволяет при потере данных быстро развернуть окружение снова.
  • Все настройки храним в гит, на всех проектах используем CI\CD.

Проект, когда это пригодилось

Вводные требования:

  • Семь человек в тестировании.
  • Нужны стабильные стенды под мобилки, в количестве не меньше 2х штук.
  • Набор данных для развертывания бэка занимает ~700гб после распаковки (база и ассеты).
  • Базу нужно готовить, делать анонимизацию данных
  • Системные требования для бэк системы ~12Gb RAM, 4+ CPU.
  • Тестовые данные желательно обновлять после релиза каждой задачи, чтобы не получить проблем с накопленными ошибками и не получить пенальти на изменение схемы при деплое задачи.

Итого имеем:

Потребность в 9 стендах. Как стенд считаем сервер БД + сервер приложений.

Для них нужно:
(9х(700+100)+9х100)=8100 Gb диска
9х(4х2)=72 CPU
9x(12+8)=180 Gb RAM

В ценах среднестатистического крупного облачного провайдера это будет стоить 217 т. рублей или $2.380 в месяц. (данные на 13.06.2024 г)
Довольно круглая сумма для заказной разработки. Сразу появляется желание уменьшить стоимость.

Также не забываем, что данные надо готовить. А это или простой стенда, или отдельно выделенный сервер для подготовки данных.

Пришло время веток и желудей

Сервер с параметрами “Intel i7+/AMD Ryzen, 64Gb RAM, x2 SSD/NVMe или кастомный набор дисков, 1Gb LAN” можно арендовать за сумму, близкую к 5-6 т. рублей или $55-$65.

Если итоговую суммарную ёмкость, описанную выше, пересчитывать в менее дорогое решение, то получится примерно такая схема:
Схема 1, общий вид системы
На одну рабочую ноду поместится по 3 стенда, с учетом небольшого оверселлинга по CPU.

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

Также нужно обновлять регулярно обновлять данные и максимально грамотно утилизировать ресурсы, которые ввиду низкой стоимости не отличаются производительностью.
Схема 2, дисковая подсистема.
Для организации хранения данных используем ZFS.

Она позволит объединить производительность трех дисков на чтение и имеет кэш записи на выделенном для этого SSD.

При этом поддерживает доступные на запись снапшоты и (если надо) сжатие на лету.

Такая организация места позволяет провернуть хитрость:
  • Исходные данные загружаются на сторадж, распаковываются.
  • Монтируются в VM или контейнер, производится подготовка данных (деперсонализация, внесение нужных для тестирования изменений, и т.д.).
  • После этого VM или контейнер останавливаются, создается снапшот холодной копии данных, полностью готовый для работы и доступный на запись.
  • Т.к. в системе уже подготовлена оверлей сеть, то этот снапшот встроенными средствами файловой системы экспортируется и становится доступным на виртуальной машине, служащей СУБД для стенда.
  • Настраиваем движок базы так, чтобы временные данные хранились на локальном диске.
  • Отключаем синхронную запись.
  • Настраиваем кэш для NFS также на локальный диск ВМ.

В итоге получаем емкую по ресурсам, производительную и дешевую систему.

Если нужно обновление данных - обновляем в фоне, после чего делаем новые снапшоты. Всё это не прерывая работу стендов, т.к. снапшоты полностью независимы.

Нужно откатить БД? - удаляем снапшот, делаем новый с нужной версии мастер-снапшота, монтируем, работаем дальше.

Данные занимают много места? - окей, выборочно включаем сжатие на лету, получаем бонусом (в зависимости от данных) до х4 емкости диска.

Вышел из строя жесткий диск? - не беда, меняем, заливаем образ ВМ с бэкапа или же ассеты с внешнего стораджа.

При условии того, что система будет описана в IaC, а процесс подготовки данных автоматизирован это займет какое-то время, но потребует минимального количества трудозатрат.

Итоговая стоимость аренды такого стенда будет кратно меньше, чем аренда облака (~$350 vs. $2000+)

Выводы

При условиях, что нет потребности в отказоустойчивых стендах для тестов продукта, можно очень сильно удешевить стоимость производства на долгосроке за счет аренды, используя IaC совместно с простыми и надежными технологиями.

Описание инфраструктуры как кода потребует на момент постройки стенда вложений в виде трудозатрат, но при этом позволит как переиспользовать этот код как для работы с стендами, так и сократить время на онбординг новых сотрудников.

Описание похожей системы занимает примерно человеко-месяц, но при этом каждый последующий месяц владения системой будет экономить в среднем $1.6k.

Если вам нужна похожая система, ревью расходов на инфраструктуру, оптимизировать или отладить вашу систему - напишите нам
через почту: client@softwarecats.dev
телеграм @alex_zarubin

И мы договоримся с вами об онлайн-встрече, чтобы подробнее обсудить ваш проект и вашу проблему.
Руководитель направления DevOps и Поддержки Software Cats