New Exchange Platform NP RTS: Goals, Architecture and Risk Management In 2013 NP RTS launched a project to build a new versatile exchange trading platform. In addition to the standard exchange platform functionality, the platform also supports connectivity to external markets to execute orders at the best available price. The presentation will include an architectural overview of the underlying platform and describe testing approaches to manage risks and raise quality.

1. 14/11
Кострома
Торговая платформа НП
РТС: задачи, архитектура
и подход к тестированию
Сергей Замолоцких

2. НП РТС
НП РТС основано в 1995 году и до декабря 2011 года
было частью биржевой группы РТС.
Члены НП РТС – более 100 компаний, в том числе
ведущих брокеров и дилеров на российском рынке.
НП РТС ставит своей целью развитие инфраструктуры
российского финансового рынка.
2

3. НП РТС
К концу 2012 года НП РТС подготовила инфраструктуру для
создания биржевой группы - ОАО «Санкт-петербургская
биржа» и ОАО «Клиринговый центр МФБ».
В начале 2013 года НП РТС начала работу над созданием
межброкерской торговой системы с функцией best execution.
В сентябре 2013 года задача была расширена до создания
универсальной многофункциональной биржевой платформы
с поддержкой широкого спектра рынков и внешних
площадок.
3

4. Проект по созданию платформы
В сентябре 2013 года стояла задача запуска в опытную
эксплуатацию за 9 месяцев версии с функционалом Best
Execution. В целом она была решена - в июне 2014 года были
запущены торги на первой версии системы и дан доступ
тестовым участникам.
Далее шел процесс доработок под пожелания пользователей и
покрытию системы полноценной системой тестов.
В ноябре 2014 планируется обновление версии платформы и
запуск рынка иностранных ценных бумаг с расчетами в
долларах США.
4

5. Архитектура платформы
1. Операционная система Linux. Быстрые модули написаны на
C++. Управляющие и некритичные к скорости на Java.
Тестовые скрипты пишутся на python.
2. Архитектура модульная. Большинство модулей работают как
преобразователи данных - получают входящие потоки
данных, обрабатывают и выдают исходящие потоки. Есть
модули имеющий под собой БД.
3. В разработке используется универсальный контейнер,
позволяющий абстрагировать логику от работы с
интерфейсами и сильно облегчающий разработку и
тестирование модулей системы.
5

6. Модульное тестирование 1
Архитектура платформы позволяет
тестировать модули системы с помощью задания данных во
входных и выходных потоках за счет абстрагирования
реализации ПО от специфики связей в системе
создать внутри контейнера прототип модуля (например на
python) внешне идентичный промышленной реализации
6

7. Модульное тестирование 2
Широкое покрытие функционала модульными тестами
написанными разработчиками.
Автоматизированное тестирование путем ручного
формирования как тестовых входящих данных, так и
выходных данных. Применяется для логически самых простых
модулей.
7

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

9. Case 1. Отладка многопоточной бизнес
логики. На примере модуля расчета
рисков.
В основе система массового обслуживания: N=5
потоков обрабатывают изменения состояния от 100
до 1 млн портфелей.
Данные относящиеся к разным портфелям
изолированы.
Отсутствие одновременного доступа к данным из
разных потоков.
Доступ к общим данным только на чтение.
9

10. Case 1. Отладка многопоточной бизнес
логики 2
Выполняются задачи
- Онлайн обработка входящих приказов
- Изменение входящих параметров и соответствующий
пересчет всех портфелей под непрерывной нагрузкой.
10

11. Case 1. Отладка многопоточной бизнес
логики 3
Система тестирования состоит из
- Прототипа для проверки расчета по одному портфелю с
данным набором входящих параметров.
- Набора тестовых примеров для тестирования алгоритма.
- Регрессионного механизма сверки результата обработки
потока операций с результатом восстановления по срезу
позиций и заявок.
- Нагрузочного стенда для проверки корректности
многопоточной обработки по итогам выполнения различных
тестовых сценариев. При этом суммарная пропускная
способность одного экземпляра модуля должна быть не
менее 50 тыс операций в секунду.
11

12. Комплексное тестирование
Тестирование жизненного цикла системы.
Комплексное тестирование функциональных блоков.
Комплексные тесты с точки зрения клиентов.
Тестирование восстановления при нештатных ситуациях.
12

13. Case 2. Восстановление
Главное требование:
При сбое отосланная клиентам информация
должна остаться валидной. Это касается сделок, а
также операций с заявками.
Другие требования к восстановлению:
Гарантия возможности.
Надежность.
Быстрота.
13

14. Case 2. Восстановление 1
В ходе проектирования рассматривались разные варианты
архитектуры, различные в части восстановления:
1. Единая шина данных. Единый упорядоченный основной поток
торговых данных. Каждый модуль системы имеет один вход и
восстановление тривиально.
Плюсы - простота восстановления. Минусы -
производительность, ограничения в масштабировании.
2. Модульная архитектура с произвольными связями.
Плюсы - масштабирование, гибкость в
конфигурировании, минусы - сложность восстановления.
Был выбран вариант 2.
14

15. Case 2. Восстановление 2
Восстановление проводится в первую очередь на основе
содержимого исходящих потоков модулей, затем
содержимого входящих потоков.
В процессе восстановления используется механизм отсечек -
checkpoints от которых клиент потока может проводить
восстановление в режиме штатной работы.
Отсечка создается один раз в день в каждом торговом потоке.
При создании отсечки заявки снимаются и выставляются
заново, отсылаются нужные для восстановления значения
внутренних переменных.
15

16. Case 2. Восстановление 3
В исходящий поток пишутся ссылки на исходные сообщения.
Также сохраняются срезы данных - заявок и позиций, для
ускорения восстановления.
При восстановлении модуль сначала восстанавливает
внутреннее состояние, а потом начинает обработку входящих
сообщений. Это достигается конфигурированием контейнера,
но все равно нуждается в тестировании.
16

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

18. Case 2. Восстановление 5
Нужно проверять разные комплексные сценарии
восстановления. Облегчается тем что контейнер позволяет
тестировщику конфигурационно формировать нужную среду
состоящую из нескольких модулей и произвольных связей
между ними.
Также есть фреймворк для проверки состояния в контрольных
точках без формирования полного тестового выхода.
18

19. СПАСИБО ЗА ВНИМАНИЕ!
E-mail: misha@rts.ru
www.nprts.ru