Развитието на архитектурата на системата за търговия и клиринг на Московската борса. Част 2

Това е продължение на дълга история за нашия трънлив път към създаването на мощна система с високо натоварване, която осигурява работата на борсата. Първата част е тук: habr.com/en/post/444300

Мистериозна грешка

След многобройни тестове актуализираната система за търговия и клиринг беше пусната в експлоатация и се натъкнахме на грешка, за която можем да напишем детективско-мистична история.

Малко след стартирането на главния сървър, една от транзакциите беше обработена с грешка. Въпреки това всичко беше наред на резервния сървър. Оказа се, че проста математическа операция за изчисляване на степента на главния сървър дава отрицателен резултат от реалния аргумент! Продължихме проучването и в регистъра SSE2 открихме разлика в един бит, който отговаря за закръгляването при работа с числа с плаваща запетая.

Написахме проста тестова програма за изчисляване на експонентата с набор от битове за закръгляване. Оказа се, че във версията на RedHat Linux, която използвахме, имаше грешка в работата с математическата функция, когато беше вмъкнат злополучният бит. Докладвахме това на RedHat, след известно време получихме корекция от тях и я пуснахме. Грешката вече не се появяваше, но не беше ясно откъде идва този бит? Функцията отговаряше за това fesetround от езика C. Внимателно анализирахме нашия код в търсене на предполагаемата грешка: проверихме всички възможни ситуации; разгледа всички функции, които използват закръгляване; се опита да възпроизведе неуспешна сесия; използвани различни компилатори с различни опции; Използвани са статичен и динамичен анализ.

Причината за грешката не може да бъде намерена.

След това започнаха проверка на хардуера: извършиха тестове за натоварване на процесорите; провери RAM; Дори проведохме тестове за много малко вероятния сценарий на многобитова грешка в една клетка. Безрезултатно.

В крайна сметка се спряхме на теория от света на физиката на високите енергии: някаква високоенергийна частица влетя в нашия център за данни, проби стената на корпуса, удари процесора и накара ключалката да се забие точно в това парче. Тази абсурдна теория беше наречена „неутрино“. Ако сте далеч от физиката на елементарните частици: неутриното почти не взаимодействат с външния свят и със сигурност не са в състояние да повлияят на работата на процесора.

Тъй като не беше възможно да се открие причината за повредата, сървърът „нарушител“ беше премахнат от работа за всеки случай.

След известно време започнахме да подобряваме системата за горещо архивиране: въведохме така наречените „топли резерви“ (топли) - асинхронни реплики. Те получиха поток от транзакции, които можеха да бъдат разположени в различни центрове за данни, но затоплянията не взаимодействаха активно с други сървъри.

Защо беше направено това? Ако резервният сървър се повреди, топъл, свързан към основния сървър, става новият резервен. Тоест след повреда системата не остава с един основен сървър до края на търговската сесия.

И когато новата версия на системата беше тествана и въведена в експлоатация, отново се появи битовата грешка за закръгляне. Освен това с увеличаването на броя на топлите сървъри грешката започна да се появява по-често. В същото време продавачът нямаше какво да покаже, тъй като нямаше конкретни доказателства.

При поредния анализ на ситуацията се появи теория, че проблемът може да е свързан с ОС. Написахме проста програма, която извиква функция в безкраен цикъл fesetround, запомня текущото състояние и го проверява чрез заспиване и това се прави в много конкурентни нишки. След като избрахме параметрите за заспиване и броя на нишките, започнахме последователно да възпроизвеждаме повредата на бита след около 5 минути стартиране на помощната програма. Поддръжката на Red Hat обаче не успя да го възпроизведе. Тестването на други наши сървъри показа, че само тези с определени процесори са податливи на грешката. В същото време преминаването към ново ядро ​​реши проблема. В крайна сметка просто сменихме операционната система и истинската причина за грешката остана неясна.

И изведнъж миналата година на Хабре беше публикувана статия “Как намерих грешка в процесорите Intel Skylake" Ситуацията, описана в него, беше много подобна на нашата, но авторът продължи разследването и изложи теория, че грешката е в микрокода. И когато Linux ядрата се актуализират, производителите също актуализират микрокода.

По-нататъшно развитие на системата

Въпреки че се отървахме от грешката, тази история ни принуди да преразгледаме системната архитектура. В края на краищата не бяхме защитени от повторението на такива грешки.

Следните принципи са в основата на следващите подобрения на резервационната система:

• Не можеш да се довериш на никого. Сървърите може да не функционират правилно.
• Резервация на мнозинството.
• Осигуряване на консенсус. Като логично допълнение към резерва на мнозинството.
• Възможни са двойни провали.
• Жизненост. Новата схема за горещ режим на готовност не трябва да е по-лоша от предишната. Търговията трябва да продължи без прекъсване до последния сървър.
• Леко увеличение на латентността. Всеки престой води до огромни финансови загуби.
• Минимално взаимодействие с мрежата, за да се запази забавянето възможно най-ниско.
• Избор на нов главен сървър за секунди.

Нито едно от наличните на пазара решения не ни подхождаше, а протоколът Raft беше още в начален стадий, така че създадохме собствено решение.

Работа в мрежа

В допълнение към системата за резервации започнахме да модернизираме мрежовото взаимодействие. I/O подсистемата се състоеше от много процеси, които имаха най-лошо въздействие върху трептенето и латентността. Със стотици процеси, обработващи TCP връзки, ние бяхме принудени постоянно да превключваме между тях и в мащаб на микросекунди това е доста времеемка операция. Но най-лошото е, че когато даден процес получи пакет за обработка, той го изпрати до една SystemV опашка и след това изчака събитие от друга SystemV опашка. Въпреки това, когато има голям брой възли, пристигането на нов TCP пакет в един процес и получаването на данни в опашката в друг представляват две конкуриращи се събития за ОС. В този случай, ако няма налични физически процесори и за двете задачи, едната ще бъде обработена, а втората ще бъде поставена в чакаща опашка. Невъзможно е да се предвидят последствията.

В такива ситуации може да се използва динамичен контрол на приоритета на процеса, но това ще изисква използването на ресурсоемки системни повиквания. В резултат на това преминахме към една нишка, използвайки класическия epoll, което значително увеличи скоростта и намали времето за обработка на транзакцията. Също така се отървахме от отделните мрежови комуникационни процеси и комуникацията чрез SystemV, значително намалихме броя на системните повиквания и започнахме да контролираме приоритетите на операциите. Само на I/O подсистемата беше възможно да се спестят около 8-17 микросекунди, в зависимост от сценария. Тази еднонишкова схема се използва непроменена оттогава; една epoll нишка с резерв е достатъчна, за да обслужи всички връзки.

Обработка на транзакция

Нарастващото натоварване на нашата система наложи надграждане на почти всички нейни компоненти. Но, за съжаление, стагнацията в растежа на тактовите честоти на процесора през последните години вече не позволява директно мащабиране на процесите. Затова решихме да разделим процеса на Engine на три нива, като най-натовареното от тях е системата за проверка на риска, която оценява наличността на средства в сметките и създава самите транзакции. Но парите могат да бъдат в различни валути и беше необходимо да се разбере на каква база трябва да се раздели обработката на заявките.

Логичното решение е да го разделим по валути: един сървър търгува в долари, друг в лири, а трети в евро. Но ако с такава схема се изпратят две транзакции за закупуване на различни валути, тогава ще възникне проблемът с десинхронизирането на портфейла. Но синхронизирането е трудно и скъпо. Следователно би било правилно да шардите отделно по портфейли и отделно по инструменти. Между другото, повечето западни борси нямат задачата да проверяват рисковете толкова остро, колкото ние, така че най-често това се прави офлайн. Трябваше да приложим онлайн проверка.

Нека обясним с пример. Търговец иска да купи $30 и заявката отива за валидиране на транзакцията: ние проверяваме дали този търговец има право на този режим на търговия и дали има необходимите права. Ако всичко е наред, заявката отива към системата за проверка на риска, т.е. за проверка на достатъчно средства за сключване на сделка. Има забележка, че необходимата сума в момента е блокирана. След това заявката се препраща към системата за търговия, която одобрява или отхвърля транзакцията. Да кажем, че транзакцията е одобрена - тогава системата за проверка на риска отбелязва, че парите са деблокирани и рублите се превръщат в долари.

Като цяло системата за проверка на риска съдържа сложни алгоритми и извършва голямо количество много ресурсоемки изчисления, а не просто проверява „салдото по сметката“, както може да изглежда на пръв поглед.

Когато започнахме да разделяме процеса на Engine на нива, се натъкнахме на проблем: кодът, който беше наличен по това време, активно използваше същия масив от данни на етапите на валидиране и проверка, което изискваше пренаписване на цялата кодова база. В резултат на това заимствахме техника за обработка на инструкции от съвременни процесори: всяка от тях е разделена на малки етапи и няколко действия се изпълняват паралелно в един цикъл.

След малка адаптация на кода създадохме конвейер за паралелна обработка на транзакции, в който транзакцията беше разделена на 4 етапа на конвейера: мрежово взаимодействие, валидиране, изпълнение и публикуване на резултата

Нека разгледаме един пример. Имаме две системи за обработка, серийна и паралелна. Първата транзакция пристига и се изпраща за валидиране и в двете системи. Втората транзакция пристига веднага: в паралелна система тя незабавно се приема за работа, а в последователна система се поставя на опашка, чакаща първата транзакция да премине през текущия етап на обработка. Тоест, основното предимство на конвейерната обработка е, че обработваме опашката на транзакциите по-бързо.

Ето как измислихме системата ASTS+.

Вярно е, че и с конвейерите не всичко е толкова гладко. Да кажем, че имаме транзакция, която засяга масиви от данни в съседна транзакция; това е типична ситуация за обмен. Такава транзакция не може да бъде изпълнена в конвейер, защото може да засегне други. Тази ситуация се нарича опасност от данни и такива транзакции просто се обработват отделно: когато „бързите“ транзакции в опашката свършат, тръбопроводът спира, системата обработва „бавната“ транзакция и след това стартира тръбопровода отново. За щастие делът на такива транзакции в общия поток е много малък, така че тръбопроводът спира толкова рядко, че не засяга цялостната производителност.

След това започнахме да решаваме проблема със синхронизирането на три нишки на изпълнение. Резултатът беше система, базирана на пръстеновиден буфер с клетки с фиксиран размер. В тази система всичко зависи от скоростта на обработка, данните не се копират.

• Всички входящи мрежови пакети влизат в етапа на разпределение.
• Поставяме ги в масив и ги маркираме като налични за етап #1.
• Пристигна втората транзакция, тя отново е налична за етап №1.
• Първата обработваща нишка вижда наличните транзакции, обработва ги и ги премества към следващия етап на втората обработваща нишка.
• След това обработва първата транзакция и маркира съответната клетка deleted — вече е достъпен за нова употреба.

По този начин се обработва цялата опашка.

Обработката на всеки етап отнема единици или десетки микросекунди. И ако използваме стандартни схеми за синхронизация на ОС, тогава ще загубим повече време за самата синхронизация. Ето защо започнахме да използваме spinlock. Това обаче е много лоша форма в система в реално време и RedHat категорично не препоръчва да се прави това, така че ние прилагаме спинлок за 100 ms и след това превключваме към семафорен режим, за да елиминираме възможността за блокиране.

В резултат на това постигнахме производителност от около 8 милиона транзакции в секунда. И буквално два месеца по-късно в Статия относно LMAX Disruptor видяхме описание на верига със същата функционалност.

Сега може да има няколко нишки на изпълнение на един етап. Всички транзакции бяха обработени една по една, в реда, в който бяха получени. В резултат на това пиковата производителност се увеличи от 18 хиляди на 50 хиляди транзакции в секунда.

Система за управление на борсовия риск

Няма ограничение за съвършенството и скоро започнахме отново модернизация: в рамките на ASTS+ започнахме да преместваме системите за управление на риска и сетълмент в автономни компоненти. Разработихме гъвкава модерна архитектура и нов йерархичен модел на риска и се опитахме да използваме класа, когато е възможно fixed_point вместо double.

Но веднага възникна проблем: как да синхронизирате цялата бизнес логика, която работи от много години, и да я прехвърлите в новата система? В резултат на това първата версия на прототипа на новата система трябваше да бъде изоставена. Втората версия, която в момента работи в производство, се основава на същия код, който работи както в търговската, така и в рисковата част. По време на разработката най-трудното нещо беше git merge между две версии. Нашият колега Евгений Мазуренок извършваше тази операция всяка седмица и всеки път ругаеше много дълго време.

При избора на нова система веднага трябваше да решим проблема с взаимодействието. При избора на шина за данни беше необходимо да се осигури стабилно трептене и минимална латентност. Мрежата InfiniBand RDMA беше най-подходяща за това: средното време за обработка е 4 пъти по-малко, отколкото в 10 G Ethernet мрежи. Но това, което наистина ни плени, е разликата в процентилите - 99 и 99,9.

Разбира се, InfiniBand има своите предизвикателства. Първо, различен API - ibverbs вместо сокети. Второ, почти няма широко достъпни решения за съобщения с отворен код. Опитахме се да направим собствен прототип, но се оказа много трудно, затова избрахме комерсиално решение - Confinity Low Latency Messaging (бивш IBM MQ LLM).

Тогава възникна задачата за правилното разделяне на рисковата система. Ако просто премахнете Risk Engine и не създадете междинен възел, тогава транзакциите от два източника могат да бъдат смесени.

Така наречените решения с ултра ниска латентност имат режим на пренареждане: транзакциите от два източника могат да бъдат подредени в необходимия ред при получаване; това се осъществява чрез отделен канал за обмен на информация за поръчката. Но ние все още не използваме този режим: той усложнява целия процес и в редица решения изобщо не се поддържа. Освен това на всяка транзакция ще трябва да бъдат присвоени съответни времеви отпечатъци, а в нашата схема този механизъм е много труден за правилно прилагане. Затова използвахме класическата схема с брокер на съобщения, тоест с диспечер, който разпределя съобщенията между Risk Engine.

Вторият проблем беше свързан с достъпа на клиента: ако има няколко шлюза за риск, клиентът трябва да се свърже с всеки от тях и това ще изисква промени в клиентския слой. Искахме да избягаме от това на този етап, така че настоящият дизайн на Risk Gateway обработва целия поток от данни. Това значително ограничава максималната производителност, но значително опростява системната интеграция.

Дублиране

Нашата система не трябва да има нито една точка на отказ, тоест всички компоненти трябва да бъдат дублирани, включително брокера на съобщения. Решихме този проблем с помощта на системата CLLM: тя съдържа RCMS клъстер, в който двама диспечери могат да работят в режим master-slave и когато единият се повреди, системата автоматично превключва към другия.

Работа с резервен център за данни

InfiniBand е оптимизиран за работа като локална мрежа, т.е. за свързване на оборудване, монтирано в стелаж, и InfiniBand мрежа не може да бъде положена между два географски разпределени центъра за данни. Затова внедрихме мост/диспечер, който се свързва към хранилището за съобщения чрез обикновени Ethernet мрежи и препредава всички транзакции към втора IB мрежа. Когато трябва да мигрираме от център за данни, можем да изберем с кой център за данни да работим сега.

Резултати от

Всичко по-горе не беше направено наведнъж; бяха необходими няколко повторения за разработване на нова архитектура. Създадохме прототипа за месец, но отне повече от две години, за да го приведем в работно състояние. Опитахме се да постигнем най-добрия компромис между увеличаване на времето за обработка на транзакции и увеличаване на надеждността на системата.

Тъй като системата беше сериозно актуализирана, внедрихме възстановяване на данни от два независими източника. Ако хранилището за съобщения не функционира правилно по някаква причина, можете да вземете регистъра на транзакциите от втори източник - от Risk Engine. Този принцип се спазва в цялата система.

Освен всичко друго, успяхме да запазим клиентския API, така че нито брокерите, нито някой друг да изисква значителна преработка за новата архитектура. Трябваше да променим някои интерфейси, но нямаше нужда да правим съществени промени в операционния модел.

Нарекохме текущата версия на нашата платформа Rebus - като съкращение за двете най-забележими иновации в архитектурата Risk Engine и BUS.

Първоначално искахме да разпределим само клиринговата част, но резултатът беше огромна разпределена система. Клиентите вече могат да взаимодействат с Trade Gateway, Clearing Gateway или и с двете.

Какво в крайна сметка постигнахме:

Намалено ниво на латентност. При малък обем транзакции системата работи по същия начин като предишната версия, но в същото време може да издържи много по-голямо натоварване.

Пиковата производителност се увеличи от 50 хиляди на 180 хиляди транзакции в секунда. По-нататъшното увеличение е възпрепятствано от единствения поток от съвпадение на поръчки.

Има два начина за по-нататъшно подобрение: паралелно съпоставяне и промяна на начина, по който работи с Gateway. Сега всички Gateways работят по схема за репликация, която при такова натоварване престава да функционира нормално.

И накрая, мога да дам някои съвети на тези, които финализират корпоративни системи:

• Бъдете готови за най-лошото по всяко време. Проблемите винаги възникват неочаквано.
• Обикновено е невъзможно бързо да се преработи архитектура. Особено ако трябва да постигнете максимална надеждност по множество показатели. Колкото повече възли, толкова повече ресурси са необходими за поддръжка.
• Всички персонализирани и частни решения ще изискват допълнителни ресурси за проучване, поддръжка и поддръжка.
• Не отлагайте решаването на проблеми с надеждността на системата и възстановяването след повреди; вземете ги предвид в началния етап на проектиране.

Източник: www.habr.com