Мартин Томпсон в своей презентации о совеременных биржевых технологиях поднял интересную тему «честности» доступа к бирже.
Схема и реалии
Десять лет назад все биржи строили свою инфраструктуру примерно таким образом:
У биржи имелось два биржевых движка. Один из них был Primary, а второй — Secondary — работал в режиме hot standby, копируя состояние Primary-движка, всегда готовый заменить Primary на случай выхода того из строя.
Через множество шлюзов клиенты подключаются к бирже. Через шлюзы ордера (orders) идут в биржевой движок, и через шлюзы обратно идут сообщения об исполнении ордеров (executions).
Здесь возникает интересная проблема. На схеме все шлюзы изображены одинаково, и они представляют собой один и тот же программно-аппаратный комплекс, размноженный на несколько экземпляров. Длина сетевых кабелей от каждого шлюза до биржевого движка строго одинакова. По видимости, абсолютно нет никакой разницы для клиента, к какому именно шлюзу он подключен.
Но в реальной жизни эти шлюзы не эквивалентны. Например, к какому-то шлюзу может быть подключено 10 клиентов, а какому-то 15. На каком-то шлюзе по какой-то причине оборудование нагревается чуть больше, чем на другом. На каком-то шлюзе, какой-то клиент нагружает шлюз больше, чем остальные. Как биржи обеспечивают равноправие клиентов, «честность» доступа к бирже?
Обеспечение честности при доступе к бирже
Во-первых, клиенту предоставляется право подключаться не к одному, а к нескольким шлюзам. Главная причина — шлюз может выйти из строя, у клиента может оборваться связь с данным конкретным шлюзом. Значит, у клиента должен быть запасной канал связи с биржей, чтобы в случае внештатной ситуации продолжать торговать, или отменить все свои ордера.
Во-вторых, биржа сама определяет, как каким именно шлюзам из всего пула должен подключаться клиент. При подключении клиента к бирже, при заключении договора, биржа предоставляет список IP-адресов шлюзов, к которым данному клиенту разрешен доступ. Если он попытается подключиться намеренно или по ошибке к другому шлюзу по IP-адресу, соединение не будет установлено, а служба поддержки биржи тут же позвонить клиенту и станет задавать вопросы. Биржа при подключении каждого нового клиента выбирает шлюзы по своему собственному усмотрению, например, смотрит, какие из шлюзов в данный момент наименее загружены.
В-третьих, биржа не разрешает клиенту подключиться ко всем шлюзам биржи, даже если у того есть такие финансовые возможности. Почему?
Имея несколько подключений к бирже, клиент, если его торговая стратегия чувствительна к latency (например, маркет-мейкер), обычно определяет до начала торгового дня, какой именно шлюз сегодня отвечает лучше. Каждый день производительность каждого шлюза может меняться по разным причинам. Поэтому замер производительности надо производить каждый день. Например, клиент может проверить ping до каждого шлюза, или до открытия рынка послать несколько ордеров, и получить отлуп (reject), замерив время ответа от каждого шлюза. Это вполне честно, допустимо и не нарушает ничьих прав.
Теперь представьте, если у всех клиентов есть доступ ко всем шлюзам биржи скажем GW1 ~ GW10? Все клиенты произведут замеры перед началом торгового дня, и у всех окажется, что шлюз GW5 отвечает лучше всего. И как только биржа откроется, все клиенты направят свои ордера на GW5 и … потопят его водопадом своих ордеров. Чтобы этого не произошло, биржа ограничивает клиенту максимальное число доступных для подключения шлюзов.
Но даже этот подход не защищает биржу и ее клиентов от участников торгов, которые желают «немножечко искривить» игровое поле в свою пользу. Что могут сделать такие участники? Выбрав быстрый шлюз для своих ордеров, на другие шлюзы они могут начать посылать «мусор»: ордера, с нереально низкими или нереально высокими ценами, ордера, которые никогда не будут исполнены. Единственное назначение такого «мусора», нагрузить шлюзы обработкой бесполезных сообщений, тем самым снизить производительность этих шлюзов и значит снизить скорость обработки ордеров от конкурентов. Этот нечестный прием называется «staffing«.
Лично я был свидетелем этого феномена на одной из бирж, когда перед открытием рынка все участники торгов начинали посылать свои ордера в таком объёме, что шлюзы просто не справлялись с их обработкой. Если до открытия торгов ответ от шлюза приходил через 300 микросекунды, то во время открытия торгов ответ на ордер мог вернуться через 2-3 секунды. Ордер, отправленный на шлюз GW1, мог оказаться позади ордера, который был отправлен позднее через шлюз GW2 только потому, что GW2 обработал ордер быстрее, а GW1 в это время «пыхтел» над лавиной ордеров от других клиентов.
Как биржи борются против staffing-а?
Как биржи могут бороться с этим нечестным приемом? Например, рассылать всем участникам торгов предупреждения о том, что все ордера, отправленные на биржу должны быть посланы с намерением совершить сделку (intention to trade). В случае аудита со стороны биржи, если окажется, что за ордерами участника нет реального клиента, или он их посылал просто так, то в лучшем случае такого участника сильно оштрафуют, в худшем — лишат доступа к бирже.
Но как решить эту проблему раз и навсегда, не прибегая к увещеваниям и рассылкам писем? Очень просто: надо ликвидировать пул шлюзов и подключать всех клиентов через один шлюз.
При такой архитектуре сразу снимается проблема со staffing-ом и нерадивыми клиентам. Всем клиентам биржи больше не надо делать ping-замеры перед началом торгов. Все сообщения всех клиентов обрабатываются через один и тот же шлюз, и все таким образом находятся в одинаковом положении и не мешают друг другу. Биржевые законы позволяют подключать клиентов разного типа к разным шлюзам. Например, все retail-клиенты работают через GW2, а все маркет-мейкеры — через GW1.
Приоритеты
В этой архитектуре высочайший приоритет получает скорость работы шлюза, его способность обрабатывать весь поток сообщений от всех клиентов без задержек и без jitter. Также ПО шлюза должно иметь запас производительности и быть способно обрабатывать неожиданные всплески сообщений, которые случаются в результате появления каких-то новостей или спекулятивных ожиданий, а иногда даже просто в начале и конце торгового дня. Чтобы написать такое ПО, надо хорошо понимать машину, хорошо разбираться в concurrency и хорошо владеть инструментами оптимизации, мониторинга и замера производительности.
Algo & DMA: технологии биржевой торговли 