Не так давно на полях хабра заметил интересные комментарии про нагруженные системы от одного автора. В процессе общения я понял, насколько собеседник отлично ориентируется как практик во многих сферах построения нагруженных приложений.
Оказалось, что он работал в High Frequency Trading(HFT) - одной из самых секретных областей разработки, где крутятся баснословные суммы. Чудесным образом, он согласился приоткрыть завесу работы этой индустрии на правах анонимности.
ЧАСТЬ I. Работа в хеджфонде, зарождение HFT
В - Привет Anonymous!
В - Наше с тобой общение открывает новую рубрику "Беседа под NDA".
В - Расскажи, пожалуйста, как тебя занесло в сверх секретную сферу HFT и с какими первыми архитектурными вызовами ты там столкнулся?
А - Занесло меня в HFT и арбитраж как таковой, спустя некоторое время после того, как наш маленький и уютный хеджфонд из меньше чем десятка человек, работавший с направленными интрадей стратегиями столкнулся с значимой просадкой по депо больше чем 25% в течении полугода.
Наш направленный алготрейдинг стал сливать на стратегах, что денно и нощно, пусть и с постоянной подстройкой - стабильно давали 60%+ годовых в течении нескольких лет.
Сразу мы не понимали, что происходит, грешили на резко подскочившую эффективность рынка(что оказалось правдой), а из-за чего она подскочила, мы в хеджфонде сразу не поняли.
Но спустя пары месяцев разборов полетов предположили, да и статьи замелькали в западных финансовых СМИ, что это HFTшники пошатали нам трубу, сделавшие ставку на скорость, и стали забирать все перекосы, тем самым резко изменив как структуру микрорынка, так и опосредованно и макрорынок.
Как итог - именно осень 2008 года стала моментом окончательной смерти направленных стратегий. Хотя по факту закат направленного алготрейдинга начался еще в конце 2007 - начале 2008 года.
При том, что HFT как таковой уже в 2006 году по факту начал становиться полноценной индустрией. До этого все толкались вокруг направленного алготрейдинга разного разлива, торговли на новостях и прочем.
Но именно скорость как главный критерий успеха на рынках победила в 2008 году.
Кто-то приспособился в итоге сам нырнув в HFT и арбитражи, кто-то ушел на паперть в другие направления ?
В - Какие архитектурные решения помогли перестроится в этом переломном 2008 году?
Возможно все жили, условно, в парадигме 1 мощного сервера. А тут пришла необходимость в каком-то кластерном решение с синхронизацией(что, наверное, дорого для алго-трейдинга) ?
А - Ну тогда я долю продал и в отпуск ушел на полгода :)))
Устал банально. Ненормированный рабочий день-обычная практика, но мне как совладельцу бизнеса было грех жаловаться. Тупо выгорел, да и предметная область поднадоела, такое случается.
В - Я не так давно сам собеседовался в HFT компанию. Они говорили про 60 часовую рабочую неделю и 12-24 оклада в конце года. Наверное, для тех, кто дотянет.
А - 60 часов? Да парни вообще на расслабоне! ? 80+ часов у принципалов-легко, ну и у владельцев-легко.
В - Понятно! Высококонкурентная борьба, сама работа становится жизнью...
Правильно понимаю, что деньги, в основном, делались на арбитраже? Для этого нужен условно 1 сервер и самые быстрые каналы до разных бирж? Или как выглядела архитектура этой высокодоходной системы?
А - Не, тогда мы косили на направленных стратегиях :) Совершенно дикие мат.теории квантования уровней цены рынка, похоже на P&F с динамическим размером коробки+поиск паттернов с гибридом ловли гепов либо защиты от них на новостях+были стратегии, что сингулярный спектральный анализ использовали с аффторскими доработками, ну и всякие алгоритмы был были по выяснению диапазона цены статистически выверенного на ближайшие часы в зависимости от волатильности и дня недели(раньше прямо четкие зависимости были работающие)+алгоритмические зародыши ML для автоподстройки параметров.
А для HFT нужно были принципиально иные подходы, и там не то что сервера нужны-там нужны были FPGA с кастомным сетевым железом от SolarFlare и работа в collocation прямо около сервера биржи за отдельный прайс :)
Ну и вот в 2008 году все это наше накопленное математическое богатство направленного трейдинга накрылось тазом :) Я тогда из трейдинга ушел и пошел в другие ниши, которые не окучивал еще :) В инфобезе поработал(благо в 90е занимался разработкой полиморфных вирусов будучи студентом ? ) и прочими совсем не связанными с трейдингом задачами, хотя там тоже было интересно-настоящий хайлоад многомиллионный, куда там прежним задачам. :)
ЧАСТЬ II. Построение своей Биржи
А - Потом были еще эпизоды участия в проектах именно HFT на консервативных рынках(FPGA и вот это все в войне за 100нс tick to trade), но как-то быстро достаточно, были и результаты(до 100нс так и не добрались), но опять стало скучно, словил себя опять на мысли, что какой-то вечный день сурка :)
После прилетела противоположная задача - сделать инфраструктуру биржи для HFT. Я в общих чертах рассказывал ранее архитектуру, но в детали лезть не буду.
Скажу только что по окончанию прилетела сразу задача вернуться в трейдинг, но уже в крипте и тоже HFT. Бывший коллега, что давно за рубежом, с которым уже много лет не работали, порекомендовал через вторые руки меня, предложили хорошие условия и развязанные руки. К тому времени я старые идеи смог алгоритмически решить и решил их опробовать натурно. Для реализации идей нужны были десятки, если не сотни серверов :)
Да и интересно было покуролесить не в классическом FPGA с его 100нс tick to trade при работе в стойке, где уже все все решили. Причем это были не мы в итоге :) А на рынках, где в лучшем случае белый IP и тот же машинный зал в ДЦ+ММ договор с рибейтом за пассивное исполнение, а collocation - это нонсенс(OKex тот же вроде в 2016 году что-ли закрыл), а у остальных и collocation отродясь не было :) Так началась война за 1мкс tick to trade на CPU и сооружением обвязки для получения стабильного перцентиля даже на штормящем рынке
Что еще могу рассказать… Часть вещей до сих пор актуальна на криптобиржах, хотя прошло уже прилично времени. Они отвратно написаны с точки зрения экслойтов, но не инфобеза-а самого матчинга ордеров, и очередей рассылки как маркетдаты, так и датафида исполнения ордеров+ на очень неназываемых крутых биржах есть возможность эксплуатировать механизм рассчета квот на ордера+некоторые другие нюансы, хотя ордера канарейки на всех из них работают, но об этом все же знают, поэтому можно говорить смело :)
Не буду дальше погружаться в нюансы, высококонкурентный бизнес, бывшим коллегам не хочу малину портить ?
По архитектуре. Это может быть скучно и долго, но основной принцип, к сожалению, как всегда один, собственные реактивные велосипеды - где скорость и латентность процессинга как функциональное требование - является главным.
По факту до сих пор в части решений же откровенные ноухау работающие, совсем не классические, т.к. классические убивают высокий перцентиль и латентность.
И эти подходы будут работать и дальше. Из личных наблюдений работы над множеством проектов:
мало кто умеет проектировать высоконагруженные приложения за высокие эксплуатационные расходы
еще меньше кто умеет проектировать высоконагруженные приложения за максимально низкие эксплуатационные расходы
и единицы людей могут это делать с учетом максимально высокого перцентиля, минимальной латентности и максимально возможной низкой эксплуатационной стоимости(с учетом предыдущих двух требований, а это по определению уже не дешево с учетом как железа, так и каналов).
Хотя очевидно, что CQRS и EventSourcing+материализованное представление+NoSQL, с заворачиванием всего этого в шардинг(если возможно)-самая масштабируемая архитектура по факту. Все остальное-эрзацы. Нюансы лишь как распиливать сервера на кластер, в нюансах протоколов, в том числе и для восстановления консистентности кластера, как грамотно использовать TCP в части уменьшения стоимости сетевой передачи и прочие нюансы.
А это зависит от предметной области - как распиливать. Для биржи один датафлоу(т.к. набор материализованных представлений разный и требования к функционалу), для игры типа ММО кликера - другой, для ММО РПГ с разрушаемым миром - третий.
Нюансы реализации
В копилку нюансов реализации - используемые коллекции для материализованных представлений в случае, если держим их в памяти.
Стандартные map не подходят, чаще всего они оптимизированы на доступ, а не память, а это проблема. Материализованное представление легко может весить 100Гб в памяти, и какая нибудь самопальная реализация map на open addressing с заточкой на blittable ключи целочисленные-может в 3+ раз меньше весить на идентичных сценариях, пусть и будет уступать в те-же 3 раза по скорости доступа.
Туда же конвееризация обработки, вся инфраструктура высоконагруженного низколатентного приложения с высоким перцентилям-строится на них, есть публичные реализации тот же Disruptor подобные решения, и их либо приходится допиливать, либо брать под свои требования с корнями из 90х, которые лучше работают с пачками и ближе к железу(дурацкая идиома передавать по одному элемент конвеера вместо сразу куска памяти-торчит в том же Disruptor везде).
Туда же реализация протоколов, json и прочие структурные протоколы, если стоит вопрос ребром-идут лесом, как пример:а) прямой маппинг структуры 64 байт в массив байт через небезопасный каст-это ~700M/ops на ядроб) JSON в лучшем случае 1М+/ops на ядров) более быстрые вроде SBE выше 25М/ops на ядро не поднимутся.
Туда же реализация журнала, т.к. при 1М сохраняемых команд в секунду(запросы идут довеском сверху)-SQL сервера, даже кластеризованные-сложатся. А при 10М команд в секунду-и подавно.
Туда же реализация снапшота материализованного представления. Это конечно хорошо-взять и прогнать журнал с начала, но если журнал измеряется триллионами команд, то каждый подъем сервера-это будет еще то приключение :)
Про коллекции кстати вот какой прикол - не все среды поддерживают десятко гигабайтные массивы и нужно извращаться с виртуальными адресами :) Я вот пилил такое несколько раз с учетом предметной области(от деревьев, до справочников)
В - Видел SBE в околотрейдинговом проекте. Самописная реализация.
А - Вряд ли там больше 30М/ops было :)
Если для наружной публикации еще пойдут структурные сериализаторы(ну почему бы и нет, если перцентиль не горит), и ядрами на публикацию можно отмасштабироваться, то внутрикластерный процессинг вообще не должен иметь издержек на сериализацию
Я много экпериментировал-небезопасный каст структуры в массив байт и обратно-самый быстрый способ :) Понятно, что сетевой протокол под это дело должен быть изначально разработан, но плюсы в этом огромные по факту-этот же принцип маппинга отлично и на конвеера ложится .
Я везде по крайней мере уже 15+ лет леплю и никогда не упирался в скорость работы конвееров и сериализацию внутри кластера :)
Завершение
В - Сколько времени ушло на разработку? Через сколько лет биржа раскрутилась, стала приносить доход? И какой порядок клиентского RPS стала обслуживать?
А - Первые версии матчера ордеров были сделаны в 2004 году. А там потихоньку и повелось как хобби с периодами затухания интереса и нового подъема. Это изначально не было заказной разработкой.
Без комментариев, этот код сейчас не моя собственность.
В - Доволен ли ты своей работой? Остался ли совладельцем? Или ушёл из проекта?
А - Безусловно доволен. Без комментариев.
В - я думаю, это был замечательный опыт в работе с предельно низкими задержками. Спасибо, что поделился своими впечатлениями по работе в этой сверхсекретной сфере - HFT!
---
Больше архитектуры - System Design Интервью, посты, архитектурные каты на канале system_design_world
P.S. Захотелось работать в HFT ? :) Есть что самому рассказать под NDA? :)