Як Біржа тестує сама себе?

Ми всі спостерігали грудневі події. Висока волатильність ринку, різкі рухи курсів валют, цін акцій і ф'ючерсів на них, супроводжувалися і ще одним фактором — дуже високою активністю клієнтів біржі. У цих умовах ключове завдання біржі — забезпечення безперервності торгів та максимальної відмовостійкості систем. З цими завданнями ми впорались. А як ми готуємося до пікових навантажень? Спільно з учасниками ринку на регулярній основі проводимо навантажувальне тестування.

Навантажувальне тестування — це можливість, як на біржі, так і для учасників ринку — визначити гранично допустимі навантаження на діючу технологічну інфраструктуру. Основні компоненти інфраструктури — програмно-апаратне забезпечення, канали зв'язку, архітектурні рішення, процеси управління, підтримки та модернізації.

У звичайні дні, обсяги торгів, активність учасників, кількість угод/заявок — рівень потоків ринкових даних і його інтенсивність — змінюються досить плавно, добре прогнозованих межах. Але іноді на ринку виникають сплески активності, що порушують звичний хід подій. Наприклад, при виході важливої економічної новини число заявок зростає в рази, що і продемонстрував ринок восени 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 — розташований на Варшавському шосе;
• Резервний — в будівлі Біржі в Кисловському провулку.
Розбираємося, як це працює…

image

Існує 6 типових схем підключення до біржі (зображені на рис. „Схема підключення“) і тестуються учасники всіх схем. При такому розмаїтті все ж основна частина учасників ринку (брокери, банки, провайдери, вендори) підключена універсальною схемою. 7 авторизованих операторів зв'язку спеціально для біржі організували приватні мережі (L3 VPN), до яких разом з учасниками підключені основний і резервний дата-центри.

Кожному учаснику торгів рекомендується застосовувати надійне підключення до біржі — мінімум два канали зв'язку, що необхідно в цілях резервування та перерозподілу навантаження для запобігання заторів трафіку в періоди пікового активності торгової сесії.

Одним з „вузьких місць“ технологічної інфраструктури, що виявляються, у тому числі в процесі тестування, є „остання миля“ підключення абонента до мережі оператора зв'язку. Рекомендована мінімальна пропускна здатність виділеного каналу зв'язку без використання технології FAST UDP multicast marketdata — 10 Мбіт/с. З використанням FAST UDP multicast marketdata — 30 Мбіт/с для фондового ринку, 20 Мбіт/с для валютного і на 15 Мбіт/с для термінового (у разі отримання даних з декількох ринків, цифри підсумовуються).

З точки зору навантажувального тестування та обробки результатів найбільш репрезентативними для нас є дані на вихідних комутаторах від біржі в зону colocation, коли клієнти отримують інформацію безпосередньо від біржі, без використання оператора зв'язку. Клієнти ставлять своє обладнання (сервери) на території дата-центру біржі. Сервери розташовуються поруч з апаратним комплексом, і підключення йде безпосередньо до торгових платформ мережевими кабелями на швидкості 100 Мбіт/сек, 1 Гбіт/с або 10 Гбіт/сек.

Саме тут і починається боротьба за кожну микросекунду у швидкості передачі даних. На колокації, як правило, знаходяться сервери високочастотних трейдерів (HFT — high frequency trading, вони ж ДТА — гіперактивні торговельні автомати), для яких важливо отримання/відправлення даних на максимальній швидкості і з мінімальним розкидом. Заміри на колокації дозволяють нам найбільш точно виміряти всі затримки, виключивши вплив незалежних від нас мереж.

Загальна схема навантажувального тестування
Загальна схема навантажувального тестування виглядає таким чином:

image

На цих ділянках ми вимірюємо основні показники:

Утилізація локальних мереж: утилізація процесора на мережному пристрої. Вимірюємо з метою перевірки пропускної здатності власної локальної мережі: трафік повинен вільно ходити від однієї точки до іншої. У торговельній мережі всі підключення на 10 Гбіт/с.

CPU utilization: рівень завантаженості мережних пристроїв, який не повинен перевищувати 60-70% для їх нормальної роботи. Перевищення веде до того, що комутатор перестає справлятися з обсягом трафіку, що призводить до втрат пакетів.

Latency: час між отриманням мережевого повідомлення з наказом на постановку/ зняття/ зміна заявки на якомусь комутаторі на шляху між сервером доступу та клієнтом і отриманням відповіді на наказ. Вимірювання на різних комутаторах дозволяють оцінити всі складові затримок, включаючи канали зв'язку і програмні компоненти комплексу

Jitter: статистичний розкид значень затримки (latency). Сталість latency — важливий для всіх категорій клієнтів показник. Як правило, вимірюються максимальні часи відгуку для кращих 50% (медіана), 80%, 90%, 99% наказів. Співвідношення цих величин дає гарне уявлення про розкиді значень затримок.

image

вимірюємо ?

У нашому арсеналі є кілька інструментів вимірювання.
— Адаптовані під нас загальновизнані рішення, наприклад, Network Management Node від HP, за допомогою якого вимірюється утилізація каналів зв'язку.
— Внутрішні засоби логування подій з микросекундной точністю в нашому, а також старий добрий tcpdump.
— У 2014 році ми вперше використали можливості прецизійної вимірювальної системи Corvil — для контролю параметрів latency і jitter в зоні колокації, чутливої до микросекундным затримок. Ця система використовується, у тому числі такими найбільшими біржами світу як NASDAQ і NYSE.
Приклад вивантаження даних від Corvil дивіться нижче.

image

Що вийшло — короткі підсумки

Докладні підсумки тестування всіх біржових систем, серверів доступу, шлюзів і т. д. можна знайти в докладному звіт, але для наочності наведемо деякі цифри:
Фондовий ринок
Досягнуті значення (шт.) Максимальна швидкість обробки (шт. в сек.)
Заявки 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) не мають технологічних обмежень на кількість заявок та угод за один торговий день, досягнуті цифри обумовлені часом і програмою тестування.

Хочемо подякувати клієнтів, операторів зв'язку, вендорів і всіх фахівців за активну участь в тестуванні, що робить результати тестів більш точними і справедливими.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.