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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

СПАСИБО ЗА ВНИМАНИЕ! E-mail: [email protected] www.nprts.ru