Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
14/11 
Кострома 
Торговая платформа НП 
РТС: задачи, архитектура 
и подход к тестированию 
Сергей Замолоцких
НП РТС 
НП РТС основано в 1995 году и до декабря 2011 года 
было частью биржевой группы РТС. 
Члены НП РТС – более 100 ком...
НП РТС 
К концу 2012 года НП РТС подготовила инфраструктуру для 
создания биржевой группы - ОАО «Санкт-петербургская 
бирж...
Проект по созданию платформы 
В сентябре 2013 года стояла задача запуска в опытную 
эксплуатацию за 9 месяцев версии с фун...
Архитектура платформы 
1. Операционная система Linux. Быстрые модули написаны на 
C++. Управляющие и некритичные к скорост...
Модульное тестирование 1 
Архитектура платформы позволяет 
тестировать модули системы с помощью задания данных во 
входных...
Модульное тестирование 2 
Широкое покрытие функционала модульными тестами 
написанными разработчиками. 
Автоматизированное...
Модульное тестирование 3 
Автоматизированное тестирование с использованием прототипа. 
В этом случае вручную формируются т...
Case 1. Отладка многопоточной бизнес 
логики. На примере модуля расчета 
рисков. 
В основе система массового обслуживания:...
Case 1. Отладка многопоточной бизнес 
логики 2 
Выполняются задачи 
- Онлайн обработка входящих приказов 
- Изменение вход...
Case 1. Отладка многопоточной бизнес 
логики 3 
Система тестирования состоит из 
- Прототипа для проверки расчета по одном...
Комплексное тестирование 
Тестирование жизненного цикла системы. 
Комплексное тестирование функциональных блоков. 
Комплек...
Case 2. Восстановление 
Главное требование: 
При сбое отосланная клиентам информация 
должна остаться валидной. Это касает...
Case 2. Восстановление 1 
В ходе проектирования рассматривались разные варианты 
архитектуры, различные в части восстановл...
Case 2. Восстановление 2 
Восстановление проводится в первую очередь на основе 
содержимого исходящих потоков модулей, зат...
Case 2. Восстановление 3 
В исходящий поток пишутся ссылки на исходные сообщения. 
Также сохраняются срезы данных - заявок...
Case 2. Восстановление 4 
Казалось возможным создать не слишком сложную систему 
восстановления на таких принципах. Однако...
Case 2. Восстановление 5 
Нужно проверять разные комплексные сценарии 
восстановления. Облегчается тем что контейнер позво...
СПАСИБО ЗА ВНИМАНИЕ! 
E-mail: misha@rts.ru 
www.nprts.ru
Upcoming SlideShare
Loading in …5
×

TMPA-2014 (Trading Systems Testing): New Exchange Platform NP RTS

2,117 views

Published on

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.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

TMPA-2014 (Trading Systems Testing): New Exchange Platform NP RTS

  1. 1. 14/11 Кострома Торговая платформа НП РТС: задачи, архитектура и подход к тестированию Сергей Замолоцких
  2. 2. НП РТС НП РТС основано в 1995 году и до декабря 2011 года было частью биржевой группы РТС. Члены НП РТС – более 100 компаний, в том числе ведущих брокеров и дилеров на российском рынке. НП РТС ставит своей целью развитие инфраструктуры российского финансового рынка. 2
  3. 3. НП РТС К концу 2012 года НП РТС подготовила инфраструктуру для создания биржевой группы - ОАО «Санкт-петербургская биржа» и ОАО «Клиринговый центр МФБ». В начале 2013 года НП РТС начала работу над созданием межброкерской торговой системы с функцией best execution. В сентябре 2013 года задача была расширена до создания универсальной многофункциональной биржевой платформы с поддержкой широкого спектра рынков и внешних площадок. 3
  4. 4. Проект по созданию платформы В сентябре 2013 года стояла задача запуска в опытную эксплуатацию за 9 месяцев версии с функционалом Best Execution. В целом она была решена - в июне 2014 года были запущены торги на первой версии системы и дан доступ тестовым участникам. Далее шел процесс доработок под пожелания пользователей и покрытию системы полноценной системой тестов. В ноябре 2014 планируется обновление версии платформы и запуск рынка иностранных ценных бумаг с расчетами в долларах США. 4
  5. 5. Архитектура платформы 1. Операционная система Linux. Быстрые модули написаны на C++. Управляющие и некритичные к скорости на Java. Тестовые скрипты пишутся на python. 2. Архитектура модульная. Большинство модулей работают как преобразователи данных - получают входящие потоки данных, обрабатывают и выдают исходящие потоки. Есть модули имеющий под собой БД. 3. В разработке используется универсальный контейнер, позволяющий абстрагировать логику от работы с интерфейсами и сильно облегчающий разработку и тестирование модулей системы. 5
  6. 6. Модульное тестирование 1 Архитектура платформы позволяет тестировать модули системы с помощью задания данных во входных и выходных потоках за счет абстрагирования реализации ПО от специфики связей в системе создать внутри контейнера прототип модуля (например на python) внешне идентичный промышленной реализации 6
  7. 7. Модульное тестирование 2 Широкое покрытие функционала модульными тестами написанными разработчиками. Автоматизированное тестирование путем ручного формирования как тестовых входящих данных, так и выходных данных. Применяется для логически самых простых модулей. 7
  8. 8. Модульное тестирование 3 Автоматизированное тестирование с использованием прототипа. В этом случае вручную формируются только входные примеры. Применяется для более сложных модулей. Проверка проводится сравнением выхода прототипа и продукта. Прототип как правило пишется отличным от продукта образом, что снижает вероятность появления одинаковых ошибок. В сложных случаях прототип пишется постановщиком для одновременной проверки правильности понимания постановки разработчиком. 8
  9. 9. Case 1. Отладка многопоточной бизнес логики. На примере модуля расчета рисков. В основе система массового обслуживания: N=5 потоков обрабатывают изменения состояния от 100 до 1 млн портфелей. Данные относящиеся к разным портфелям изолированы. Отсутствие одновременного доступа к данным из разных потоков. Доступ к общим данным только на чтение. 9
  10. 10. Case 1. Отладка многопоточной бизнес логики 2 Выполняются задачи - Онлайн обработка входящих приказов - Изменение входящих параметров и соответствующий пересчет всех портфелей под непрерывной нагрузкой. 10
  11. 11. Case 1. Отладка многопоточной бизнес логики 3 Система тестирования состоит из - Прототипа для проверки расчета по одному портфелю с данным набором входящих параметров. - Набора тестовых примеров для тестирования алгоритма. - Регрессионного механизма сверки результата обработки потока операций с результатом восстановления по срезу позиций и заявок. - Нагрузочного стенда для проверки корректности многопоточной обработки по итогам выполнения различных тестовых сценариев. При этом суммарная пропускная способность одного экземпляра модуля должна быть не менее 50 тыс операций в секунду. 11
  12. 12. Комплексное тестирование Тестирование жизненного цикла системы. Комплексное тестирование функциональных блоков. Комплексные тесты с точки зрения клиентов. Тестирование восстановления при нештатных ситуациях. 12
  13. 13. Case 2. Восстановление Главное требование: При сбое отосланная клиентам информация должна остаться валидной. Это касается сделок, а также операций с заявками. Другие требования к восстановлению: Гарантия возможности. Надежность. Быстрота. 13
  14. 14. Case 2. Восстановление 1 В ходе проектирования рассматривались разные варианты архитектуры, различные в части восстановления: 1. Единая шина данных. Единый упорядоченный основной поток торговых данных. Каждый модуль системы имеет один вход и восстановление тривиально. Плюсы - простота восстановления. Минусы - производительность, ограничения в масштабировании. 2. Модульная архитектура с произвольными связями. Плюсы - масштабирование, гибкость в конфигурировании, минусы - сложность восстановления. Был выбран вариант 2. 14
  15. 15. Case 2. Восстановление 2 Восстановление проводится в первую очередь на основе содержимого исходящих потоков модулей, затем содержимого входящих потоков. В процессе восстановления используется механизм отсечек - checkpoints от которых клиент потока может проводить восстановление в режиме штатной работы. Отсечка создается один раз в день в каждом торговом потоке. При создании отсечки заявки снимаются и выставляются заново, отсылаются нужные для восстановления значения внутренних переменных. 15
  16. 16. Case 2. Восстановление 3 В исходящий поток пишутся ссылки на исходные сообщения. Также сохраняются срезы данных - заявок и позиций, для ускорения восстановления. При восстановлении модуль сначала восстанавливает внутреннее состояние, а потом начинает обработку входящих сообщений. Это достигается конфигурированием контейнера, но все равно нуждается в тестировании. 16
  17. 17. Case 2. Восстановление 4 Казалось возможным создать не слишком сложную систему восстановления на таких принципах. Однако на практике из- за большого числа и различного характера связей некоторых модулей возникли нюансы и отладка восстановления такой системы оказалась сложнее чем ожидалось. Сложная матрица тестовых случаев - много комбинаций состояний входных линков. Восстановление не было запрототипировано, поэтому большой расход труда на формирование тестовых примеров. 17
  18. 18. Case 2. Восстановление 5 Нужно проверять разные комплексные сценарии восстановления. Облегчается тем что контейнер позволяет тестировщику конфигурационно формировать нужную среду состоящую из нескольких модулей и произвольных связей между ними. Также есть фреймворк для проверки состояния в контрольных точках без формирования полного тестового выхода. 18
  19. 19. СПАСИБО ЗА ВНИМАНИЕ! E-mail: misha@rts.ru www.nprts.ru

×