Стакан зависает, когда рынок оживляется? Как починить поток рыночных данных и кто может это сделать

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

Как сломанный поток рыночных данных выглядит на экране?

Это проявляется в самые загруженные моменты, например во время заявления центрального банка или на открытии рынка. Стакан на экране замирает на секунду-другую, а потом скачет. Отменённые заявки остаются на виду. Иногда самая высокая цена, которую предлагает покупатель, оказывается выше самой низкой цены, которую просит продавец, — это называется пересечённым стаканом. На одной бирже вне аукционов открытия и закрытия такие заявки сразу же исполнились бы друг против друга. Поэтому пересечённый стакан одной биржи на вашем экране означает, что ваша копия этого стакана неверна.

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

Почему обновления пропадают или приходят не по порядку?

Поток стакана с биржи — это череда мелких изменений: заявка добавлена, заявка отменена, прошла сделка. Ваша система начинает с полной копии стакана, которую называют снимком (snapshot), и применяет изменения по порядку. Каждое изменение пронумеровано, поэтому пропуск можно заметить. В спецификации Nasdaq для потока TotalView-ITCH 5.0 сказано, что поток «состоит из последовательности упорядоченных сообщений», то есть пронумерованных по порядку.

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

Биржи исходят из того, что клиенты будут терять обновления. В документации CME Group к потоку MDP 3.0 сказано, что после пропуска «следует исходить из того, что все стаканы, которые ведёт клиентская система, могут больше не отражать правильное актуальное состояние».

В каком месте системы ломается поток?

Таких мест три, и каждое требует своего исправления. Третье инженеры называют fan-out: один поток обновлений расходится веером на множество экранов. Все три подробно разобраны в технической статье, ссылка на которую есть выше.

Первое место — приём, куда поступает поток с биржи. Некоторые биржи дают способы вернуть потерянные данные. Один из протоколов доставки Nasdaq, MoldUDP64, позволяет получателям «обнаруживать пропущенные пакеты и запрашивать их повторно». CME отправляет свой поток дважды, по линиям A и B, и ведёт отдельный поток снимков, чтобы приводить стаканы в актуальное состояние. Ничего из этого не поможет, если ваша система не замечает пропуск.

Затем собирается стакан, и здесь опасность в том, что изменение применят дважды, не по порядку или поверх не того снимка. Криптобиржа Binance описывает в своём руководстве точные шаги, как состыковать снимок с живым потоком. Стакан, собранный без них, всё равно показывает цены и выглядит нормально, но цены неверные.

Последним идёт fan-out, где стакан расходится по сотням сессий трейдеров — по одной на каждый подключённый экран. Трейдер на слабом мобильном соединении или зависший терминал читают обновления медленно. Если сервер ждёт такую сессию, ждут и все остальные. Позволить очереди обновлений этой сессии расти без ограничений — не лучше: у сервера кончается память, и он падает для всех.

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

Что измерить, прежде чем кого-то нанимать?

Возьмите самый загруженный час за последний месяц и соберите по нему такие цифры:

• Пропуски: сколько раз система обнаруживала пропавший номер обновления в потоке каждой биржи. Если система их не считает, это ваша первая находка
• Время восстановления: сколько длилась каждая пересборка стакана и что в это время видели трейдеры
• Задержка: время от отметки времени биржи в сообщении до момента, когда обновление уходит с вашего сервера к трейдеру, а на нескольких тестовых терминалах — до экрана. Берите медиану и 99-й перцентиль — время, в которое укладываются 99 обновлений из каждых 100. Синхронизируйте часы серверов с точным источником времени, иначе цифры ничего не значат
• Сессии: сколько отстало и насколько, сколько было отключено и по какой причине каждая

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

Чинить свой обработчик, купить готовый или перестроить fan-out?

Программа, которая принимает поток с биржи и ведёт стакан, называется обработчиком потока (feed handler). У вас три пути, и ваши замеры должны указать на один из них. Последние два можно совмещать.

Когда имеет смысл чинить собственный обработчик потока?

Чините имеющийся обработчик потока, когда замеры указывают на одну понятную неисправность, например незамеченные пропуски или медленную пересборку стакана, а люди, которые знают код, всё ещё рядом.

• Когда подходит: неисправность, которую можно назвать, и архитектура, которая в остальном работает
• Во что обойдётся: время инженеров и тестовый стенд, который воспроизводит ваши записи
• Кому принадлежит код: вам
• Ограничение: исправление на приёме не поможет, если проблема в доставке стакана на экраны

Когда стоит купить обработчик потока или управляемый поток?

Готовый обработчик потока — это лицензируемое ПО, которое подключается к бирже, ловит пропуски и отдаёт вашей системе правильный и актуальный стакан. Управляемый поток (managed feed) идёт дальше: к биржам подключается поставщик рыночных данных, а вы берёте у него один поток в одном формате.

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

Когда стоит нанять команду, чтобы перестроить fan-out?

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

• Когда подходит: задержка растёт между вашими серверами и экранами, а не между биржей и вашими серверами
• Во что обойдётся: время инженеров и тестирования, а затем люди, которые эксплуатируют систему после запуска
• Кому принадлежит код: вам, если так записано в договоре

Как проверить компанию до того, как её нанять?

Проведите с каждой компанией из вашего списка одни и те же пять тестов:

• Прогон вашей записи — на реальной скорости и в несколько раз быстрее — через то, что компания поставляет или показывает. Сравните пропуски, пересборки стакана, время восстановления и задержки с показателями вашей текущей системы
• Как система ловит пропуск. Хороший ответ: система применяет изменение, только если его номер — следующий ожидаемый. Если номера не хватает, система недолго ждёт, а затем заново запрашивает изменение или пересобирает стакан. До тех пор она помечает стакан как устаревший. Спросите, что в это время видят трейдеры
• Что происходит с одним медленным трейдером. Попросите компанию во время прогона намеренно замедлить одну сессию. Задержки остальных сессий меняться не должны
• Как измеряется задержка: от какой отметки времени до какой точки, на каком перцентиле, при какой нагрузке и на каком оборудовании и как синхронизируются часы
• Кому принадлежит код и на каких условиях вы пользуетесь частями, которые компания оставляет за собой

Какие тревожные сигналы?

• «Добавим серверов» — первым же ответом, ещё до того, как кто-то увидел ваши замеры
• «У нас надёжное соединение, поэтому ничего не теряется». Binance отправляет обновления через WebSocket — соединение, которое не теряет данные при передаче, и всё равно в её руководстве написано, что делать клиентам, если события пропущены

Где здесь место amBrain?

amBrain строит инфраструктуру алгоритмической торговли: исполнение заявок, рыночные данные и предторговый риск-контроль.

Одна из строк на сайте amBrain гласит: «Разработка торговых терминалов, систем управления заявками и биржевая интеграция по протоколу FIX».

amBrain диагностирует медленные системы в трейдинге и AdTech: работающую платформу замеряют от начала до конца, и в отчёте названо, куда уходит время.

amBrain делает софт с 2019 года. Свою команду компания описывает одной строкой: «Команда до 40 человек, около 75% из них — сеньоры». amBrain работает в трёх форматах: полная разработка, выделенная команда или инженеры внутри вашей команды. Клиент сохраняет полное владение продуктом и кодом, кроме переиспользуемых компонентов amBrain.

Эта статья — не кейс и не описывает никакой работы для клиентов. Она не приводит ни цифр задержки для систем, которые построил amBrain, ни цен, ни сроков.

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

Частые вопросы

• Помогут ли дополнительные серверы? Сами по себе — нет. Если система применяет изменения не по порядку или ждёт свою самую медленную сессию, дополнительные серверы повторят ту же ошибку. Добавляйте серверы, когда замеры покажут, что текущим не хватает мощности
• Можно ли объединять обновления и отправлять их реже? Для стакана — да. Инженеры называют это конфляцией, и некоторые биржи делают её сами. В документации Binance скорость обновления спотового потока изменений стакана — 1000 мс или 100 мс. Скажите трейдерам, что поток показывает последнюю картину, а не каждый шаг. Сделки и подтверждения заявок не объединяйте: если выпадет хоть одно, история сделок станет неверной
• Обязательно ли переписывать всё на Rust или C++? Не обязательно. Незамеченные пропуски и сервер, который ждёт свою самую медленную сессию, — ошибки проектирования, и новый язык их не убирает. В Rust и C++ нет сборщика мусора — автоматической очистки памяти, которая может ставить на паузу программу, написанную на языке вроде Java или Go. Это помогает в тех частях системы, через которые проходит каждое обновление. Каким бы ни был язык, просите измеренную задержку на пике
• Сколько времени занимает исправление? Зависит от того, где неисправность и сколько у вас бирж и сессий. Попросите каждую компанию оценить стоимость и сроки первого этапа, который включает замеры и тестовый стенд, воспроизводящий вашу запись. Пять тестов выше используйте как критерии приёмки