Устройство называется CEPappliance. CEP — от Complex Event Processing, а appliance — (и так должно быть понятно, но на всякий случай) “устройство” с английского.

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

В 2015 году мы осознали, что у нас получилось достойное творение, которое позволяет обрабатывать потоки данных с гарантированной задержкой в 2-3 микросекунды. И мы начали искать возможности превратить начатое в коммерческий продукт и, вероятно, перестать работать на “дядю”, заняться только нашим продуктом, посвящая ему все свое время. В конце 2015 мы нашли первого клиента, оставили “дядей” и пустились в “свободное плавание”.

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

Работая на “дядей” мы неплохо изучили технические аспекты и потребности торговли финансовыми инструментами на биржах и ориентировались в первую очередь на них. Это автоматизированная торговля (HFT, Algo Trading), контроль рисков (Pre-trade), организация “прямого” доступа к торгам (Direct Market Access) и т.п.

Но нам удалось сделать CEPappliance достаточно универсальным устройством, применимым в областях, где нужно прокачивать много данных и делать это не только быстро, но и с гарантированными малыми задержками. Благодаря встроенной поддержке стандартных сетевых протоколов и внесению минимальных задержек устройство применимо в телекоммуникациях для обнаружения нарушений безопасности в сетях, управления загрузкой сетей. Устройство может применяться в телематике, когда нужно за нескольких микросекунд принять решение и среагировать на поступление сигналов с датчиков. При этом логика обработки данных устройством может быть сложной. Для ее описания (программирования) мы используем некоторые приемы технологии Complex Event Processing (CEP).

CEPappliance было задумано и создавалось для решения задач, которые в упрощенном виде можно сформулировать так: с суммарной задержкой менее 3 микросекунд

1. получить входные данные (сигнал) по сетевому интерфейсу в формате протоколов Ethernet, TCP/IP, UDP, FIX, FAST, TWIME (FIX SBE) и т.п.;
2. разобрать и извлечь пользовательские данные;
3. проанализировать пользовательские данные;
4. сформировать выходные данные (реакцию) и отправить их по сетевому интерфейсу.

CEPappliance отличается от программного решения, выполняемого на архитектурах с центральным процессором тем, что ядром архитектуры устройства является программируемая пользователем вентильная матрица (ППВМ, FPGA), на которой реализованы все без исключения этапы решения описанных задач.

Архитектуры с центральным процессором развиваются. Появляются гибридные варианты (см. рис. 1, рис. 2 и рис. 3), в которых время доставки данных от сетевых интерфейсов до процессора (и обратно) сокращается за счет переноса обработки протоколов сетевого и прикладного уровней с центрального процессора в сетевые карты. Тем не менее, время доставки данных составляет 1 — 3 микросекунды (в одну сторону) и вносит ощутимый вклад в задержку, которая отдаляет момент реакции от момента поступления сигнала¹.

На FPGA мы разместили компоненты для разбора, извлечения, анализа входных данных и формирования выходных данных на одном кристалле образно говоря «без посредников» (см. рис. 4), которые обязательно присутствуют в решениях с центральным процессором.


Рис. 1. Логическая схема традиционного решения с центральным процессором


Рис. 2. Логическая схема гибридного решения с центральным процессором и TCP Offload Engine на сетевой карте


Рис. 3.Логическая схема гибридного решения с центральным процессором, TCP Offload Engine и реализацией протоколов прикладного уровня в сетевой карте


Рис. 4. Логическая схема CEPappliance

В CEPappliance компоненты для разбора, извлечения, анализа входных данных и формирования выходных данных, расположены на кристалле FPGA и непосредственно взаимодействуют между собой.

Для этого пришлось “изобрести велосипед” заново. Напомню, что начинали мы работу (в далеком 2010 году) над CEPappliance в режиме хобби. Все делали сами “как надо и правильно”. В итоге, помимо прочего, мы реализовали Ethernet, TCP/IP, UDP, FIX и FAST “с нуля”.

Нам удалось создать эти компоненты так, что разбор входных данных происходит со скоростью их поступления (at wire speed). Компоненты реализуют соответствующие стандарты, которые “высечены в камне” и не часто изменяются. Для стандартных протоков мы предусмотрели механизм настройки. Например, модули протоколов FIX, FAST, TWIME и др. настраиваются с помощью параметров, задаваемых пользователем, и шаблонов или схем, описывающих структуру сообщений.

В то же время мы исходили из того, что (пользовательскте) алгоритмы обработки данных могут изменяться. Например, торговые стратегии или проверки, выполняемые брокером для минимизации рисков (pre-trade risk checks), следуют за изменением ситуации на рынке, модернизацией микроархитектуры биржи или требованиями регуляторов.

Разработка алгоритмов для FPGA непосредственно на “железячных” языках (VHDL, Verilog и т.п.) требует значительно больше времени для кодирования, отладки и тестирования, чем разработка на языках высокого уровня [2]. Для этого также необходимы специальные навыки, которыми программисты, пишущие программы на языках высокого уровня, как правило, не обладают. И если вы планируете использовать FPGA для ускорения выполнения своих алгоритмов, то вам придется передать детальное описание алгоритма FPGA-разработчику, который будет его реализовывать. Иногда это крайне нежелательно, так как передача описания алгоритма создает для его обладателя риск потери конкурентного преимущества.

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

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

Собственный язык программирования, процессор и компилятор позволяют нам реализовывать на FPGA (аппаратно) функции, доступные пользователю. Эти функции могут представлять из себя части алгоритма или весь алгоритм целиком — зависит от целесообразности такой реализации, пожеланий и возможностей пользователя. Такой подход может значительно ускорить выполнение программ в CEPappliance в некоторых случаях.

Предоставив пользователю возможность самостоятельно программировать CEPappliance мы, очевидно, должны были предоставить и инструментарий для отладки этих программ. Без такого инструментария трудно будет воспользоваться всеми преимуществами CEPappliance. Поэтому мы разработали эмулятор устройства, который на 100% совместим с самим устройством. Отладив программу на эмуляторе, можно изменить конфигурацию (в большинстве случаев это смена IP адреса) и сходу запустить программу на устройстве.

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

А для автоматического тестирования пользовательских программ, написанных для CEPappliance, у нас есть специальный инструмент — Test Bench, который читает тестовые сценарии в табличном виде и выполняет их. Один и тот же набор тестов можно выполнять как с устройством, так и с его эмулятором.

Ну и подводя некоторые итоги… Наши платы стоят в датацентре Московской биржи и успешно торгуют. Про результаты торгов рассказать не можем — это не наша тема, но клиент весьма доволен (и этот текст с ним согласован).

Впереди много работы по развитию устройства, поиск клиентов в областях за пределами биржевой торговли и много новых идей!

---

¹Про то, как образуется эта задержка в случае обмена данными по TCP/IP можно почитать в [1]. А здесь рассказано, как эту задержку можно уменьшить за счет реализации гибридной архитектуры с применением FPGA.

Ссылки

1. S. Larsen and P. Sarangam, “Architectural Breakdown of End-to-End Latency in a TCP/IP Network,” International Journal of Parallel Programming, Springer, 2009.
2. David F. Bacon, Rodric Rabbah, and Sunil Shukla. FPGA Programming for the Masses. ACM Queue, Vol 11(2), February 2013.

https://habrahabr.ru/post/334574/