Мы все наблюдали декабрьские события. Высокая волатильность рынка, резкие движения курсов валют, цен акций и фьючерсов на них, сопровождались и еще одним фактором – очень высокой активностью клиентов биржи. В этих условиях ключевая задача биржи — обеспечение непрерывности торгов и максимальной отказоустойчивости систем. С этими задачами мы справились. А как мы готовимся к пиковым нагрузкам? Совместно с участниками рынка — на регулярной основе проводим нагрузочное тестирование.
Нагрузочное тестирование – это возможность, как для биржи, так и для участников рынка – определить предельно допустимые нагрузки на действующую технологическую инфраструктуру. Основные компоненты инфраструктуры – программно-аппаратное обеспечение, каналы связи, архитектурные решения, процессы управления, поддержки и модернизации.
В обычные дни, объемы торгов, активность участников, количество сделок/заявок – уровень потоков рыночных данных и его интенсивность — меняются достаточно плавно, в хорошо прогнозируемых пределах. Но иногда, на рынке возникают всплески активности, нарушающие обычный ход событий. Например, при выходе важной экономической новости число заявок возрастает в разы, что и продемонстрировал рынок осенью 2014 года. В подобных случаях аномальных нагрузок, вместе с участниками торгов мы должны иметь достаточный запас по производительности торговой системы и пропускной способности каналов связи.
Основные цели тестирования формулируются так:
• Смоделировать пиковые нагрузки и их влияние на программно-аппаратный комплекс биржи и участника.
• Подтвердить способность всего комплекса обрабатывать поток данных по интенсивности превышающий средние рыночные показатели в 2-3 раза. То есть обеспечить «запас прочности» всей системы в 2-3 раза.
• Привести в соответствие весь инфраструктурный комплекс “биржа-участник”, включая стыки «биржа-участник», «биржа-провайдер» и «провайдер-участник.
Нагрузочное тестирование позволяет оценить примерные объемы данных, которые будут получать от нас участники торгов в течение будущего года. Брокеры, как и биржа, на основе анализа результатов тестирования, получают возможность своевременно подготовить свою инфраструктуру к расчетным нагрузкам, скорректировать дальнейшую работу по оптимизации сетевой и торговой архитектуры, получить ответы на вопросы: «Где узкие места? Какие компоненты инфраструктуры нуждаются в модернизации? Какой бюджет на это выделить?». Именно к решению последнего вопроса и привязано время проведения тестирования – осень.
Нагрузка, расписание, сценарий
Нагрузка при тестировании создается собственными роботизированными системами, созданными специально для тестирования торговых платформ биржи. Эти симуляторы умеют создавать профиль нагрузки, соответствующий реальным торгам, как по соотношению поставленных и снятых заявок, так и по колебаниям ценового коридора и другим рыночным параметрам. В реальности больше 90% заявок снимается самими клиентами в течении миллисекунд – это действительность алгоритмической торговли, однако нагрузка на систему от заявки, которая не приводит к сделке, никуда не исчезает. “Вот так роботы нас и мучают своим мусором, прибыли никакой, а инфраструктуру приходится всем из-за них модернизировать,” – иронизируют наши IT.
Аналогичные автоматы готовят к тестированию брокеры и вендоры торгового программного обеспечения. В этом году соотношение нагрузки составило 50 на 50 между биржей и участниками торгов. Всего в этом году в тестировании приняло участие более 70 профессиональных участников рынка и вендоров.
Общая продолжительность тестирования – 4 часа – в которые полностью укладывается расписание реального торгового дня с перерывом на клиринговую сессию. Целевые числа заявок для каждого рынка превышают текущие средние дневные значения в 1,5-2 раза. Тестируются три рынка на двух технологических платформах с максимальными числами заявок за сессию:
• Фондовый рынок (ASTS) – 30 000 000
• Валютный рынок (ASTS) – 30 000 000
• Срочный рынок (SPECTRA) – 60 000 000
Перед началом тестирования к торговым платформам подключаются все серверы доступа. И по мере увеличения нагрузки в тесте регистрируются серверы, не способные с ней справиться.
В ходе тестирования создается нагрузка в 2-3 раза превышающая пиковые частоты заявок реального рынка в секундных интервалах, но не достигающая пределов возможностей торговых платформ. Непосредственно измерение предельной производительности платформ и их подсистем производится кратковременно на финальном этапе теста, чтобы полученные результаты по измерениям задержек не искажались образовавшимися очередями на обработку заявок.
Помимо самих торговых платформ тестируются сервисы и подсистемы критичные к нагрузкам и активно используемые участниками торгов и их клиентами:
• Индекс-серверы.
• Web-сайт и связанные с ним информационные сервисы.
• FIX udp multicast marketdata серверы.
• FIX transactional серверы.
В тестировании симулируется переключение на резервные системы и каналы связи, что также важно для участников торгов. Они могут отработать данные процедуры и при необходимости локализовать узкие места на своей стороне.
Важно
Биржа – огромный конгломерат сетей со сложной архитектурой. На текущий момент программно-аппаратный комплекс биржи распределен между двумя дата-центрами.
• Основной – М1 – расположен на Варшавском шоссе;
• Резервный — в здании Биржи в Кисловском переулке.
Разбираемся, как это работает…
Существует 6 типовых схем подключения к бирже (изображены на рис. “Схема подключения”) и тестируются участники всех схем. При таком разнообразии все же основная часть участников рынка (брокеры, банки, провайдеры, вендоры) подключена по универсальной схеме. 7 авторизованных операторов связи специально для биржи организовали частные сети (L3 VPN), к которым вместе с участниками подключены основной и резервный дата-центры.
Каждому участнику торгов рекомендуется применять отказоустойчивое подключение к бирже – минимум два канала связи, что необходимо в целях резервирования и перераспределения нагрузки для предотвращения заторов трафика в периоды пиковой активности торговой сессии.
Одним из “узких мест” технологической инфраструктуры, выявляемых, в том числе в процессе тестирования, является “последняя миля” подключения участника к сети оператора связи. Рекомендованная минимальная пропускная способность выделенного канала связи без использования технологии FAST UDP multicast marketdata — 10 Мбит/с. С использованием FAST UDP multicast marketdata — 30 Мбит/с для фондового рынка, 20 Мбит/с для валютного и на 15 Мбит/с для срочного (в случае получения данных с нескольких рынков, цифры суммируются).
С точки зрения нагрузочного тестирования и обработки результатов наиболее репрезентативными для нас являются данные на выходных коммутаторах от биржи в зону colocation, когда клиенты получают данные напрямую от биржи, без использования оператора связи. Клиенты ставят свое оборудование (серверы) на территории дата-центра биржи. Серверы располагаются рядом с аппаратным комплексом, и подключение идет напрямую к торговым платформам сетевыми кабелями на скорости 100 Мбит/сек, 1 Гбит/с или 10 Гбит/сек.
Именно здесь и начинается борьба за каждую микросекунду в скорости передачи данных. На коллокации, как правило, находятся серверы высокочастотных трейдеров (HFT – high frequency trading, они же ГТА – гиперактивные торговые автоматы), для которых важно получение/отправка данных на максимальной скорости и с минимальным разбросом. Замеры на коллокации позволяют нам наиболее точно измерить все задержки, исключив влияние независимых от нас сетей.
Общая схема нагрузочного тестирования
Общая схема нагрузочного тестирования выглядит следующим образом:
На этих участках мы измеряем основные показатели:
— Утилизация локальных сетей: утилизация процессора на сетевом устройстве. Измеряем с целью проверки пропускной способности собственной локальной сети: трафик должен свободно ходить от одной точки до другой. В торговой сети все подключения на 10 Гбит/с.
— CPU utilization: уровень загруженности сетевых устройств, который не должен превышать 60-70% для их нормальной работы. Превышение ведет к тому, что коммутатор перестает справляться с объемом трафика, что приводит к потерям пакетов.
— Latency: время между получением сетевого сообщения с приказом на постановку/ снятие/ изменение заявки на каком-либо коммутаторе на пути между сервером доступа и клиентом и получением ответа на приказ. Измерения на разных коммутаторах позволяют оценить все составляющие задержек, включая каналы связи и программные компоненты комплекса
— Jitter: статистический разброс значений задержки (latency). Постоянство latency – важный для всех категорий клиентов показатель. Как правило, измеряются максимальные времена отклика для лучших 50% (медиана), 80%, 90%, 99% приказов. Соотношение этих величин дает хорошее представление о разбросе значений задержек.
Чем измеряем ?
В нашем арсенале есть несколько инструментов измерения.
— Адаптированные под нас общепризнанные решения, например, Network Node Management от HP, с помощью которого измеряется утилизация каналов связи.
— Внутренние средства логирования событий с микросекундной точностью в нашем ПО, а также старый добрый tcpdump.
— В 2014 году мы впервые использовали возможности прецизионной измерительной системы Corvil — для контроля параметров latency и jitter в зоне коллокации, чувствительной к микросекундным задержкам. Эта система используется, в том числе такими крупнейшими биржами мира как NASDAQ и NYSE.
Пример выгрузки данных от Corvil смотрите ниже.
Что получилось – краткие итоги
Подробные итоги тестирования всех биржевых систем, серверов доступа, шлюзов и т.д. можно найти в подробном отчете, но для наглядности приведем некоторые цифры:
Фондовый рынок
Валютный рынок
Нагрузочное тестирование характеризовалось большой активностью по частоте и количеству сделок, в 25 раз превышавшей типичные значения для нормальных торгов.
Срочный рынок
Внедрение в июле 2014 года новой версии ТКС SPECTRA с оптимизированным матчингом, а также выделение отдельной ветки репликации данных с ускоренной раздачей, позволило увеличить производительность ядра ТКС до 52 000 транзакций в секунду и стабилизировать latency RTT заявки. В ходе нагрузочного тестирования планово был проведен клиринг и промежуточный клиринг, и, несмотря на большие объемы заявок и сделок, обе процедуры прошли штатно в запланированный интервал времени.
Следует отметить, что обе системы (ASTS и SPECTRA) не имеют технологических ограничений на количество заявок и сделок за один торговый день, достигнутые цифры обусловлены временем и программой тестирования.
Хотим поблагодарить клиентов, операторов связи, вендоров и всех специалистов за активное участие в тестировании, что делает результаты тестов более точными и cправедливыми.
Нагрузочное тестирование – это возможность, как для биржи, так и для участников рынка – определить предельно допустимые нагрузки на действующую технологическую инфраструктуру. Основные компоненты инфраструктуры – программно-аппаратное обеспечение, каналы связи, архитектурные решения, процессы управления, поддержки и модернизации.
В обычные дни, объемы торгов, активность участников, количество сделок/заявок – уровень потоков рыночных данных и его интенсивность — меняются достаточно плавно, в хорошо прогнозируемых пределах. Но иногда, на рынке возникают всплески активности, нарушающие обычный ход событий. Например, при выходе важной экономической новости число заявок возрастает в разы, что и продемонстрировал рынок осенью 2014 года. В подобных случаях аномальных нагрузок, вместе с участниками торгов мы должны иметь достаточный запас по производительности торговой системы и пропускной способности каналов связи.
Основные цели тестирования формулируются так:
• Смоделировать пиковые нагрузки и их влияние на программно-аппаратный комплекс биржи и участника.
• Подтвердить способность всего комплекса обрабатывать поток данных по интенсивности превышающий средние рыночные показатели в 2-3 раза. То есть обеспечить «запас прочности» всей системы в 2-3 раза.
• Привести в соответствие весь инфраструктурный комплекс “биржа-участник”, включая стыки «биржа-участник», «биржа-провайдер» и «провайдер-участник.
Нагрузочное тестирование позволяет оценить примерные объемы данных, которые будут получать от нас участники торгов в течение будущего года. Брокеры, как и биржа, на основе анализа результатов тестирования, получают возможность своевременно подготовить свою инфраструктуру к расчетным нагрузкам, скорректировать дальнейшую работу по оптимизации сетевой и торговой архитектуры, получить ответы на вопросы: «Где узкие места? Какие компоненты инфраструктуры нуждаются в модернизации? Какой бюджет на это выделить?». Именно к решению последнего вопроса и привязано время проведения тестирования – осень.
Нагрузка, расписание, сценарий
Нагрузка при тестировании создается собственными роботизированными системами, созданными специально для тестирования торговых платформ биржи. Эти симуляторы умеют создавать профиль нагрузки, соответствующий реальным торгам, как по соотношению поставленных и снятых заявок, так и по колебаниям ценового коридора и другим рыночным параметрам. В реальности больше 90% заявок снимается самими клиентами в течении миллисекунд – это действительность алгоритмической торговли, однако нагрузка на систему от заявки, которая не приводит к сделке, никуда не исчезает. “Вот так роботы нас и мучают своим мусором, прибыли никакой, а инфраструктуру приходится всем из-за них модернизировать,” – иронизируют наши IT.
Аналогичные автоматы готовят к тестированию брокеры и вендоры торгового программного обеспечения. В этом году соотношение нагрузки составило 50 на 50 между биржей и участниками торгов. Всего в этом году в тестировании приняло участие более 70 профессиональных участников рынка и вендоров.
Общая продолжительность тестирования – 4 часа – в которые полностью укладывается расписание реального торгового дня с перерывом на клиринговую сессию. Целевые числа заявок для каждого рынка превышают текущие средние дневные значения в 1,5-2 раза. Тестируются три рынка на двух технологических платформах с максимальными числами заявок за сессию:
• Фондовый рынок (ASTS) – 30 000 000
• Валютный рынок (ASTS) – 30 000 000
• Срочный рынок (SPECTRA) – 60 000 000
Перед началом тестирования к торговым платформам подключаются все серверы доступа. И по мере увеличения нагрузки в тесте регистрируются серверы, не способные с ней справиться.
В ходе тестирования создается нагрузка в 2-3 раза превышающая пиковые частоты заявок реального рынка в секундных интервалах, но не достигающая пределов возможностей торговых платформ. Непосредственно измерение предельной производительности платформ и их подсистем производится кратковременно на финальном этапе теста, чтобы полученные результаты по измерениям задержек не искажались образовавшимися очередями на обработку заявок.
Помимо самих торговых платформ тестируются сервисы и подсистемы критичные к нагрузкам и активно используемые участниками торгов и их клиентами:
• Индекс-серверы.
• Web-сайт и связанные с ним информационные сервисы.
• FIX udp multicast marketdata серверы.
• FIX transactional серверы.
В тестировании симулируется переключение на резервные системы и каналы связи, что также важно для участников торгов. Они могут отработать данные процедуры и при необходимости локализовать узкие места на своей стороне.
Важно
Биржа – огромный конгломерат сетей со сложной архитектурой. На текущий момент программно-аппаратный комплекс биржи распределен между двумя дата-центрами.
• Основной – М1 – расположен на Варшавском шоссе;
• Резервный — в здании Биржи в Кисловском переулке.
Разбираемся, как это работает…
Существует 6 типовых схем подключения к бирже (изображены на рис. “Схема подключения”) и тестируются участники всех схем. При таком разнообразии все же основная часть участников рынка (брокеры, банки, провайдеры, вендоры) подключена по универсальной схеме. 7 авторизованных операторов связи специально для биржи организовали частные сети (L3 VPN), к которым вместе с участниками подключены основной и резервный дата-центры.
Каждому участнику торгов рекомендуется применять отказоустойчивое подключение к бирже – минимум два канала связи, что необходимо в целях резервирования и перераспределения нагрузки для предотвращения заторов трафика в периоды пиковой активности торговой сессии.
Одним из “узких мест” технологической инфраструктуры, выявляемых, в том числе в процессе тестирования, является “последняя миля” подключения участника к сети оператора связи. Рекомендованная минимальная пропускная способность выделенного канала связи без использования технологии FAST UDP multicast marketdata — 10 Мбит/с. С использованием FAST UDP multicast marketdata — 30 Мбит/с для фондового рынка, 20 Мбит/с для валютного и на 15 Мбит/с для срочного (в случае получения данных с нескольких рынков, цифры суммируются).
С точки зрения нагрузочного тестирования и обработки результатов наиболее репрезентативными для нас являются данные на выходных коммутаторах от биржи в зону colocation, когда клиенты получают данные напрямую от биржи, без использования оператора связи. Клиенты ставят свое оборудование (серверы) на территории дата-центра биржи. Серверы располагаются рядом с аппаратным комплексом, и подключение идет напрямую к торговым платформам сетевыми кабелями на скорости 100 Мбит/сек, 1 Гбит/с или 10 Гбит/сек.
Именно здесь и начинается борьба за каждую микросекунду в скорости передачи данных. На коллокации, как правило, находятся серверы высокочастотных трейдеров (HFT – high frequency trading, они же ГТА – гиперактивные торговые автоматы), для которых важно получение/отправка данных на максимальной скорости и с минимальным разбросом. Замеры на коллокации позволяют нам наиболее точно измерить все задержки, исключив влияние независимых от нас сетей.
Общая схема нагрузочного тестирования
Общая схема нагрузочного тестирования выглядит следующим образом:
На этих участках мы измеряем основные показатели:
— Утилизация локальных сетей: утилизация процессора на сетевом устройстве. Измеряем с целью проверки пропускной способности собственной локальной сети: трафик должен свободно ходить от одной точки до другой. В торговой сети все подключения на 10 Гбит/с.
— CPU utilization: уровень загруженности сетевых устройств, который не должен превышать 60-70% для их нормальной работы. Превышение ведет к тому, что коммутатор перестает справляться с объемом трафика, что приводит к потерям пакетов.
— Latency: время между получением сетевого сообщения с приказом на постановку/ снятие/ изменение заявки на каком-либо коммутаторе на пути между сервером доступа и клиентом и получением ответа на приказ. Измерения на разных коммутаторах позволяют оценить все составляющие задержек, включая каналы связи и программные компоненты комплекса
— Jitter: статистический разброс значений задержки (latency). Постоянство latency – важный для всех категорий клиентов показатель. Как правило, измеряются максимальные времена отклика для лучших 50% (медиана), 80%, 90%, 99% приказов. Соотношение этих величин дает хорошее представление о разбросе значений задержек.
Чем измеряем ?
В нашем арсенале есть несколько инструментов измерения.
— Адаптированные под нас общепризнанные решения, например, Network Node Management от HP, с помощью которого измеряется утилизация каналов связи.
— Внутренние средства логирования событий с микросекундной точностью в нашем ПО, а также старый добрый tcpdump.
— В 2014 году мы впервые использовали возможности прецизионной измерительной системы Corvil — для контроля параметров latency и jitter в зоне коллокации, чувствительной к микросекундным задержкам. Эта система используется, в том числе такими крупнейшими биржами мира как NASDAQ и NYSE.
Пример выгрузки данных от Corvil смотрите ниже.
Что получилось – краткие итоги
Подробные итоги тестирования всех биржевых систем, серверов доступа, шлюзов и т.д. можно найти в подробном отчете, но для наглядности приведем некоторые цифры:
Фондовый рынок
| Достигнутые значения (шт.) | Максимальная скорость обработки (шт. в сек.) | |
|---|---|---|
| Заявки | 40 599 733 | 9621 |
| Сделки | 2 992 713 | 1318 |
| Транзакции | 80 537 469 | 19100 |
Валютный рынок
Нагрузочное тестирование характеризовалось большой активностью по частоте и количеству сделок, в 25 раз превышавшей типичные значения для нормальных торгов.
| Достигнутые значения (шт.) | Максимальная скорость обработки (шт. в сек.) | |
|---|---|---|
| Заявки | 32 994 049 | 5700 |
| Сделки | 747 539 | 700 |
| Транзакции | 65 568 622 | 11324 |
Срочный рынок
Внедрение в июле 2014 года новой версии ТКС SPECTRA с оптимизированным матчингом, а также выделение отдельной ветки репликации данных с ускоренной раздачей, позволило увеличить производительность ядра ТКС до 52 000 транзакций в секунду и стабилизировать latency RTT заявки. В ходе нагрузочного тестирования планово был проведен клиринг и промежуточный клиринг, и, несмотря на большие объемы заявок и сделок, обе процедуры прошли штатно в запланированный интервал времени.
| Достигнутые значения (шт.) | Максимальная скорость обработки (шт. в сек.) | |
|---|---|---|
| Заявки | 63 815 090 | 36 000 |
| Сделки | 3 787 105 | 4 953 |
Следует отметить, что обе системы (ASTS и SPECTRA) не имеют технологических ограничений на количество заявок и сделок за один торговый день, достигнутые цифры обусловлены временем и программой тестирования.
Хотим поблагодарить клиентов, операторов связи, вендоров и всех специалистов за активное участие в тестировании, что делает результаты тестов более точными и cправедливыми.
