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

Transcript

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide