Архитектура системы алгоритмической торговли

Здесь приведен перевод статьи www.quantinsti.com/blog/algorithmic-trading-system-architecture/

Алгоритмическая автоматизированная торговля или алгоритмическая торговля в течение нескольких последних лет находится в центре внимания торгового мира. Доля объемов, относящихся к этой форме торговли, растет все это время. В результате, она стала высоко конкурентным рынком, в значительной степени зависящим от технологий. Далее, базовая архитектура претерпела значительные изменения за последнее десятилетие и этот процесс продолжается. Сегодня необходимо внедрять технологические новшества для того, чтобы конкурировать в мире алгоритмической торговли, что делает его местом большой концентрации достижений в области компьютерных и сетевых технологий.

Традиционная архитектура

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

1. Получает рыночные данные.

2. Передает заявки и получает ответы от биржи.

Рисунок:

Обычно получаемые рыночные данные информируют систему о последнем портфеле заявок. Он может содержать некоторую дополнительную информацию, такую, как объем торгов, достигнутый к данному моменту, цену последней сделки и количество платежных средств. Вместе с тем, чтобы принять решение по данным, трейдеру может понадобиться просмотреть старые цифры или извлечь определенные параметры из истории торгов. Для этого в обычной системе будет иметься база исторической информации для хранения рыночных данных и инструменты для того, чтобы использовать эту базу. Анализ будет также включать в себя изучение последних сделок трейдера. Поэтому понадобится еще одна база данных для хранения торговых решений. И последнее, но не менее важное — GUI-интерфейс трейдера для просмотра всей этой информации на экране.

Теперь можно разбить всю систему на:

Биржу (Биржи) — внешний мир

Сервер

Прием рыночных данных

Хранение рыночных данных

Хранение заявок, генерируемых пользователем

Приложение

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

Интерфейс для просмотра информации, включая данные и заявки

Менеджер заявок, отправляющий заявки на биржу.

Рисунок:

Новая архитектура

Традиционная архитектура не может масштабироваться в соответствии с потребностями и запросами автоматизированной торговли с прямым выходом на рынок. Задержка между началом события и формированием заявки вышла за пределы возможностей человеческого контроля и вступила в мир миллисекунд и микросекунд. Таким образом, инструменты для обработки и анализа рыночных данных необходимо соответствующим образом адаптировать. Управление заявками также должно быть более надежным и способным обрабатывать гораздо больше заявок в секунду. Так как временные рамки настолько малы, по сравнению с временем реакции человека, то система управления рисками также должна обрабатывать заявки в режиме реального времени, причем, полностью автоматизированным способом.

Например, даже если время реакции на заявку составляет 1 миллисекунду (что очень много, по сравнению с теми задержками, которые мы видим сегодня), система все еще способна сделать 1000 торговых решений в одну секунду. Это означает, что каждое из этих 1000 торговых решений должно пройти через Систему Управления Рисками в течение той же самой одной секунды, чтобы достичь биржи. Это просто проблема сложности. Поскольку архитектура в настоящее время включает в себя автоматическую логику, 100 трейдеров теперь могут быть заменены одной системой. Это увеличивает масштаб проблемы. Таким образом, каждый из логических блоков генерирует 1000 заявок и 100 таких блоков означают 100 000 заявок за каждую секунду. Это означает, что раздел, отвечающий за процессы принятия решений и отправку заявок, должен быть намного быстрее, чем приемник рыночных данных, чтобы соответствовать скорости передачи данных.

Следовательно, уровень инфраструктуры, который потребуется для этого модуля, должен быть намного выше, по сравнению с традиционной системой (рассмотренной в предыдущем разделе). Таким образом, движок, который запускает логику принятия решений, также известный как движок «Обработки сложных событий», или ОСП, переехал из приложения на сервер. Уровень приложений в настоящее время немного глубже, чем пользовательский интерфейс для просмотра и передачи параметров в ОСП.

Проблема масштабирования также приводит к интересной ситуации. Скажем, 100 различных логик запускаются по одному событию рыночных данных (как было описано в предыдущем примере). Однако могут возникнуть общие части сложных расчетов, которые необходимо выполнить для большинства из 100 логических блоков. Например, вычисление «грек» для опционов. Если бы каждая логика функционировала независимо от других, то каждый блок делал бы тот же расчет «грек», который бы излишне расходовал ресурсы процессора. В целях оптимизации избыточности расчета сложные избыточные расчеты, как правило, выделяются в отдельный расчетный движок, который посылает «греки» как входные данные на ОСП.

Хотя уровень приложений виден в первую очередь, некоторые проверки рисков (которые в настоящее время являются операциями, требовательными к ресурсам, ведущими к проблеме масштабирования), могут быть выгружены на уровень приложений, особенно те, которые связаны с достоверностью данных, вводимых пользователем, таких, как опечатки на клавиатуре или неверный щелчок мышкой. Остальные проверки рисков выполняются в настоящее время отдельной Системой Управления Рисками (СУР) в рамках Менеджера Заявок (МЗ) непосредственно перед отправкой заявки. Проблема масштабирования также означает, что там, где раньше было 100 различных трейдеров, управляющих своими рисками, в настоящее время есть только одна система СУР для управления рисками во всех логических блоках / стратегиях. Тем не менее, некоторые проверки рисков могут быть связаны с определенными стратегиями, а некоторые, возможно, необходимо сделать во всех стратегиях. Следовательно, сама СУР включает в себя СУР уровня стратегий (ССУР) и глобальную СУР (ГСУР). Она также может включать в себя пользовательский интерфейс для просмотра ССУР и ГСУР.

Рисунок:

Появление протоколов

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

Тем не менее, чтобы добавить новую биржу к системе, необходимо разработать и подключить новый адаптер к архитектуре, поскольку каждая биржа использует свой уникальный протокол, который оптимизирован для функций, которые выполняет биржа. Чтобы избежать этих хлопот с включением адаптера были разработаны стандартные протоколы. Наиболее известным среди них является протокол FIX (Exchange Financial Information). Он не только делает легко управляемым подключение к различным направлениям, но и резко облегчает выход на рынок, когда речь идет о подключении к новым каналам.

Наличие стандартных протоколов позволяет легко интегрировать сторонних поставщиков, так как аналитика или рыночные данные также легко подгружаются. В результате рынок становится очень эффективным, так как интеграция с новым направлением / поставщиком более не является сдерживающим фактором.

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

Рисунок:

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

При наличии строительных блоков алгоритмической торговой системы, стратегии оптимизируются к способности обрабатывать огромные объемы данных в реальном времени и быстро принимать торговые решения. Но с появлением стандартных протоколов связи, таких, как FIX, технологические преграды выходу на рынок при установке алгоритмического управления торговыми операциями стали ниже, и, следовательно, повысилась конкурентоспособность. Поскольку у серверов больше память и выше тактовая частота, фокус внимания смещается в сторону уменьшения задержки на принятие решений. С течением времени сокращение задержки стало необходимым по многим причинам, таким как:

1) Стратегия имеет смысл только в среде с низкой задержкой.

2) Выживает сильнейший — конкуренты обходят вас, если вы не достаточно быстры.

Проблема, однако, в том, что задержка — это действительно всеобъемлющий термин, который охватывает несколько различных типов задержек. Делать количественную оценку их всех как одного общего термина, как правило, не имеет особого смысла. Хотя это очень легко понять, довольно трудно дать этому количественную оценку. В связи с этим становится все более важным подход к проблеме снижения задержки.

Если мы посмотрим на основной жизненный цикл:

1. Пакет рыночных данных публикуется биржей

2. Пакет путешествует по проводам

3. Пакет поступает на маршрутизатор на стороне сервера.

4. Маршрутизатор передает пакет по сети на стороне сервера.

5. Пакет поступает на Ethernet-порт сервера.

6. В зависимости от протокола (UDP / TCP) производится обработка и пакет без своих заголовков и конечных структур приходит к памяти адаптера.

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

8. Этот пакет теперь проходит через несколько модулей системы — ОСП, список тикеров и т.д.

9. ОСП анализирует и посылает запрос на заявку.

10. Запрос на заявку снова проходит обратно через цикл как пакет рыночных данных.

Высокая задержка на любом из этих этапов обеспечивает высокую задержку всего цикла. Следовательно, оптимизация задержки, как правило, начинается с первого шага в этом цикле, которым мы можем управлять — «Пакет перемещается по проводам». Проще всего здесь было бы как можно больше сократить расстояние до пункта назначения. Размещение сервера клиента на бирже предоставляется самой биржей, чтобы торговый сервер находился в непосредственной близости. Следующая диаграмма иллюстрирует те преимущества, которые могут быть достигнуты за счет сокращения расстояния.

Рисунок:

Время прохождения сигнала в обоих направлениях в длинной линии (мС) на километр.

Для любого вида высокочастотных стратегий с участием одного пункта назначения, размещение сервера клиента на бирже стало де-факто обязательным. Тем не менее, стратегии с несколькими пунктами назначения нуждаются в тщательном планировании. Некоторые факторы, такие, как время, затраченное на достижение места назначения для отклика на запросы на заявки и его сравнение с временем пинга между двумя пунктами назначения, должны быть рассмотрены до принятия такого решения. Решение также может зависеть от характера стратегии.

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

Задержка распространения сигнала

Время, необходимое для посылки битов по проводам.

Скорость света, конечно, является пределом. Предложены несколько оптимизаций, чтобы уменьшить задержку распространения сигнала, помимо уменьшения физического расстояния. Например, расчетное время двухсторонней задержки для обычного кабеля между Чикаго и Нью-Йорком составляет 13,1 миллисекунды. Компания Spread networks (http://spreadnetworks.com) в октябре 2012 года объявила о уменьшении времени задержки. Расчетное время задержки составило 12,98 миллисекунд. Далее, такие компании, как Tradeworx (http://www.tradeworx.com ), стали применять СВЧ-радиосвязь, в результате чего расчетное время задержки достигло 8,5 миллисекунд. Следует отметить, что теоретический минимум составляет около 7,5 мс. Продолжающиеся инновации раздвигают границы науки, быстро достигая теоретического предела скорости света. Последние разработки в области лазерной связи, ранее принятые в оборонных технологиях, еще более уменьшают и так уже короткую задержку до наносекунд на коротких расстояниях.

Задержка сетевой обработки

Представлена маршрутизаторами, коммутаторами и т.д.

Следующий уровень оптимизации в архитектуре алгоритмической торговой системы заключается в сокращении числа сегментов, через которые пакет должен перейти, чтобы из точки А достичь точки Б. Сегмент определяется как одна часть пути между началом и пунктом назначения, в течение которого пакет не проходит через физическое устройство, такое, как маршрутизатор или коммутатор. Например, пакет может пройти то же расстояние по двум различным путям. Но на первом пути может быть 2 сегмента, по сравнению с 3-мя сегментами на втором. Если предположить, что задержка распространения сигнала такая же, то маршрутизаторы и коммутаторы каждый вносят свою собственную задержку и обычно, согласно практическим методам, чем больше сегментов, тем больше задержка.

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

Рисунок:

Первый рисунок показывает 1-секундный профиль скорости передачи данных. Мы можем видеть, что средний показатель значительно ниже полосы, доступной на 1 Гбит/сек. Тем не менее, если погрузиться глубже и посмотреть на секундный профиль (5 мс), мы увидим, что скорость передачи данных вырастала больше доступной полосы в несколько раз каждую секунду. В результате буфер пакетов на сетевой стек, как в конечных точках сети, так и в маршрутизаторах и коммутаторах может быть переполнен. Чтобы избежать этого, для алгоритмической торговой системы, как правило, выделяется значительно более высокая ширина полосы, чем наблюдаемое среднее значение.

Задержка сериализации

Время, затраченное на прохождение битов по проводам и вне их

Пакет размером 1500 байт, передаваемый по линии T1 (1544000 бит/с) будет производить задержку сериализации около 8 миллисекунд. Однако тот же 1500-байтовый пакет при использовании модема 56K (57344 бит/с) даст задержку 200 миллисекунд. Ethernet-линия 1G позволит сократить эту задержку до примерно 11 микросекунд.

Задержка на прерывания

Представлена прерываниями во время приема пакетов на сервере.

Задержка на прерывания определяется как время, прошедшее между моментом, когда прерывание генерируется и временем, когда источник прерывания обслужен. Когда генерируется прерывание? Прерывания — это сигналы процессору от аппаратного или программного обеспечения с указанием того, что некое событие требует немедленного внимания. Процессор, в свою очередь, реагирует приостановкой своей текущей деятельности, сохраняя свое состояние и обрабатывая прерывания. Всякий раз, когда пакет принят сетевой интерфейсной картой, отправляется прерывание для обработки битов, которые были загружены в приемный буфер сетевой интерфейсной карты. Время, необходимое для реагирования на это прерывание, влияет не только на обработку вновь поступающей полезной информации, но и на задержку существующих процессов на процессоре.

Компания Solarflare представила в 2011 году OpenOnload, который реализует технику, известную как обход ядра, где обработка пакета отводится не ядру операционной системы, а самому пользовательскому пространству. Весь пакет непосредственно отображается в пространстве пользователя с помощью сетевой интерфейсной карты и обрабатывается там. В результате прерываний удалось полностью избежать.

Рисунок:

Поэтому ускоряется скорость обработки каждого пакета. На следующей диаграмме наглядно демонстрируются преимущества обхода ядра.

Рисунок:

Задержка приложений

Время, затраченное приложением на обработку.

Оно зависит от нескольких пакетов, обработки, связанной с логикой приложения, сложности необходимого расчета, эффективности программирования и т.д. Увеличение числа процессоров в системе будет в целом сокращать время задержки приложений. То же самое и в случае с увеличенной тактовой частотой. Много алгоритмических торговых систем используют преимущества выделения ядер процессора на основные элементы приложения, такие, как логика стратегии, например. Это позволяет избежать задержки, вызванной переключением между ядер с одного процесса на другой.

Аналогичным образом, если программирование стратегии было завершено, имейте в виду размер кэша и локальность доступа к памяти, чтобы не было много обращений к кэш-памяти, что приводит в дальнейшем к сокращению времени задержки. Для облегчения этой задачи, многие системы используют языки программирования очень низкого уровня для оптимизации кода для конкретной архитектуры процессоров. Некоторые компании даже пошли на программирование в ПЗУ сложных вычислений на аппаратных средствах с использованием полностью программируемых матриц логических элементов (FPGA). С увеличением сложности приходит увеличение стоимости и следующая диаграмма наглядно иллюстрирует это.

Рисунок

Уровни сложности

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

 Следующий шаг

Если вы профессионал и начинаете строить собственную автоматизированную торговлю, ознакомьтесь с уже готовыми решениями компании Викинг MultiConnect (http://fkviking.ru/downloads/MultiConnect_RU.pdf )