Как я перевёл ферму торговых алгоритмов в облако и сделал её почти автономной

Недавно я прошёл курсы по дата-инжинирингу и почти полностью переписал своё решение для алгоритмической торговли. Ключевое изменение — полный переезд в облако.

Домашние компьютеры больше не участвуют в процессе. Теперь они либо на продажу, либо на выброс.

Инфраструктура

Я арендую облачные ресурсы примерно на 25 000 ₽ в месяц. Выбрал VK Cloud — провайдеров сейчас много, но по цене они плюс-минус одинаковые.

Хранилище данных

• Свечные данные

• Параметры инструментов

• Результаты расчётов

Всё хранится в S3-совместимом объектном хранилище:

• всегда доступно;

• масштабируется бесконечно;

• стоимость — около 0.20 ₽ за 10 ГБ.

Вычисления
Все расчёты выполняются в Kubernetes-кластере:

• 10 серверов;

• на каждом — по 10 контейнеров, внутри каждого в один момент времени выполняется один расчёт или исследование;

• итого ~100 параллельных потоков.

Главный плюс — эластичность. Нужно срочно посчитать больше — добавил ещё 50 серверов в пару кликов. Не нужно — отключил.
Стоимость — около 20 000 ₽ в месяц.

База данных
Отдельный сервер с PostgreSQL:

• не для хранения рыночных данных;

• используется как диспетчер очередей расчётов.
  Стоимость — ~4 000 ₽.

Торговый сервер
Для самой торговли ещё в феврале арендован сервер на стороне брокера:

• там крутится торговый движок;

• он читает новые алгоритмы напрямую из S3;

• задержки выставления ордеров минимальные.
  Стоимость — ~7 000 ₽.

В итоге система работает 24×7×365.
Я не думаю про электричество, интернет, железо, бэкапы и отказы — всё это делает облако. Я просто плачу деньги. Очень удобно.

Как всё работает по шагам

1. Обновление данных
   Раз в сутки в Kubernetes запускаются задания:

   • обращаются к двум брокерам и Binance;

   • обновляют инструменты;

   • докачивают рыночные данные;

   • сохраняют всё в S3;

   • создают задания на расчёт в БД.

2. Диспетчеризация
   В кластере постоянно работает диспетчер:

   • проверяет очередь расчётов;

   • при появлении задания сразу запускает его;

   • сам выбирает свободные хосты;

   • сам выделяет и освобождает ресурсы.

3. Расчёты
   Алгоритмы запускаются в отдельных pods:

   • забирают данные из S3;

   • выполняют расчёты;

   • складывают результаты обратно в S3.

4. Формирование портфеля
   Торговый движок каждое утро:

   • смотрит, какие новые алгоритмы появились;

   • обновляет портфель методом вытеснения:

     • худшие алгоритмы «увольняются»;

     • лучшие — включаются в торговлю.

Новый подход к тестированию стратегий

Подход к тестированию тоже сильно изменился.

Раньше:

• IS / OOS

• WFO

Теперь к этому добавился Монте-Карло.

Мои торговые системы относятся к set-and-forget:

• у них нет параметров;

• оптимизировать в WFO нечего.

Поэтому WFO по сути свёлся к проверке найденного алгоритма на всей истории.

Текущий процесс:

1. Деление выборки на IS / OOS.

2. Поиск алгоритма на IS.

3. Отбрасывание всего, что на OOS уходит в минус.

4. Эмуляция торговли на всей истории → получаю цепочку сделок.

5. Монте-Карло:

   • много раз случайно переставляю сделки;

   • для каждого варианта считаю метрики (PF, DD, Sharpe, Sortino и т.д.).

6. Агрегация результатов:

   • строю распределения;

   • считаю доверительные интервалы;

   • анализирую «толстые хвосты».

На основе этого рассчитываю Deflated Sharpe Ratio.

Зачем он нужен:

• обычный Sharpe переоценивает результат при множестве тестов;

• DSR оценивает вероятность того, что результат статистически значим, а не получен случайно.

Интерпретация:

• DSR ≈ 0 — результат незначим;

• DSR → 1 — высокая вероятность, что стратегия реальна.

Итог

В результате я стал ещё на несколько шагов ближе к цели:

алгоритмы торгуют полностью автономно, без моего постоянного участия.

Инфраструктура масштабируется, расчёты автоматизированы, отбор стратегий статистически обоснован.
Я просто задаю направление — всё остальное система делает сама.