Мәскеу биржасының сауда-клиринг жүйесінің архитектурасының эволюциясы. 1 бөлім

Бәріңе сәлем! Менің атым Сергей Костанбаев, биржада мен сауда жүйесінің негізін жасап жатырмын.

Голливуд фильмдері Нью-Йорк қор биржасын көрсеткенде, ол әрқашан былай көрінеді: адамдар көп, бәрі бірдеңе деп айғайлайды, қағаздарды бұлғайды, толық хаос болып жатыр. Бұл жерде Мәскеу биржасында ешқашан болған емес, өйткені сауда ең басынан бастап электронды түрде жүргізілді және екі негізгі платформаға негізделген - Spectra (форекс нарығы) және ASTS (шетелдік биржа, қор және ақша нарығы). Ал бүгін мен ASTS сауда және клиринг жүйесінің архитектурасының эволюциясы, әртүрлі шешімдер мен тұжырымдар туралы айтқым келеді. Әңгіме ұзақ болады, сондықтан оны екі бөлікке бөлуге тура келді.

Біз барлық санаттағы активтерді сататын және биржалық қызметтердің толық спектрін ұсынатын әлемдегі санаулы биржалардың біріміз. Мәселен, өткен жылы біз облигациялар саудасының көлемі бойынша әлемде екінші, барлық биржалар арасында 25-орын, мемлекеттік биржалар арасында капиталдандыру бойынша 13-орын болды.

Сауда-саттықтың кәсіби қатысушылары үшін жауап беру уақыты, уақытты бөлудің тұрақтылығы (джиттер) және бүкіл кешеннің сенімділігі сияқты параметрлер өте маңызды. Қазіргі уақытта біз күніне ондаған миллион транзакцияларды өңдейміз. Жүйе ядросының әрбір транзакцияны өңдеуі ондаған микросекундтарды алады. Әрине, Жаңа жыл қарсаңындағы ұялы байланыс операторларының немесе іздеу жүйелерінің өздері біздікінен жоғары жұмыс көлеміне ие, бірақ жұмыс көлемі жағынан жоғарыда аталған сипаттамалармен қоса, бізбен салыстыруға болатыны аз сияқты. Сонымен қатар, біз үшін жүйенің бір секундқа да баяуламауы, мүлдем тұрақты жұмыс істеуі және барлық пайдаланушылардың тең жағдайда болуы маңызды.

Кішкене тарих

1994 жылы австралиялық ASTS жүйесі Мәскеу банкаралық валюта биржасында (MICEX) іске қосылды және осы сәттен бастап ресейлік электронды сауда тарихын санауға болады. 1998 жылы интернет-сауданы енгізу үшін биржа архитектурасы жаңартылды. Содан бері барлық жүйелер мен ішкі жүйелерде жаңа шешімдер мен архитектуралық өзгерістерді енгізу жылдамдығы тек қана қарқын алып келеді.

Сол жылдары алмасу жүйесі жоғары сапалы аппараттық құралдарда жұмыс істеді - өте сенімді HP Superdome 9000 серверлері PA-RISC), онда бәрі қайталанатын: енгізу/шығару ішкі жүйелері, желі, жедел жад (шын мәнінде, RAID RAM массиві болды), процессорлар (ыстық ауыстырылатын). Құрылғыны тоқтатпай кез келген сервер компонентін өзгерту мүмкін болды. Біз бұл құрылғыларға сендік және оларды іс жүзінде істен шығуға қауіпсіз деп санадық. Операциялық жүйе Unix тәрізді HP UX жүйесі болды.

Бірақ шамамен 2010 жылдан бері жоғары жиілікті сауда (HFT) немесе жоғары жиілікті сауда деп аталатын құбылыс пайда болды - жай сөзбен айтқанда, биржалық роботтар. Небәрі 2,5 жылдың ішінде біздің серверлердегі жүктеме 140 есе өсті.

Ескі сәулетпен, техникамен мұндай жүктемеге төтеп беру мүмкін емес еді. Қандай да бір жолмен бейімделу керек болды.

Үй

Айырбастау жүйесіне сұраныстарды екі түрге бөлуге болады:

• Мәмілелер. Егер сіз долларды, акцияларды немесе басқа нәрсені сатып алғыңыз келсе, сіз сауда жүйесіне транзакция жібересіз және сәттілік туралы жауап аласыз.
• Ақпараттық сұраныстар. Ағымдағы бағаны білгіңіз келсе, тапсырыстар кітабын немесе индекстерді қараңыз, содан кейін ақпараттық сұрауларды жіберіңіз.

Схемалық түрде жүйенің өзегін үш деңгейге бөлуге болады:

• Брокерлер мен клиенттер жұмыс істейтін клиент деңгейі. Олардың барлығы кіру серверлерімен өзара әрекеттеседі.
• Шлюз серверлері барлық ақпараттық сұрауларды жергілікті өңдейтін серверлерді кэштеу болып табылады. Сбербанк акциялары қазіргі уақытта қандай бағамен саудаланып жатқанын білгіңіз келе ме? Сұраныс кіру серверіне жіберіледі.
• Бірақ егер сіз акцияларды сатып алғыңыз келсе, онда сұрау орталық серверге (Trade Engine) түседі. Әрбір нарық түрі үшін осындай бір сервер бар, олар маңызды рөл атқарады, біз бұл жүйені солар үшін жасадық.

Сауда жүйесінің өзегі – барлық транзакциялар биржалық операциялар болып табылатын ақылды жадтағы деректер базасы. Негіз C тілінде жазылған, жалғыз сыртқы тәуелділіктер libc кітапханасы болды және динамикалық жадты бөлу мүлде болмады. Өңдеу уақытын қысқарту үшін жүйе массивтердің статикалық жиынтығынан және деректердің статикалық орнын ауыстырудан басталады: біріншіден, ағымдағы күннің барлық деректері жадқа жүктеледі және одан әрі дискіге қол жеткізу орындалмайды, барлық жұмыс тек жадта орындалады. Жүйе іске қосылғанда, барлық анықтамалық деректер сұрыпталған, сондықтан іздеу өте тиімді жұмыс істейді және орындау уақытында аз уақыт алады. Барлық кестелер динамикалық деректер құрылымдарына арналған интрузивті тізімдермен және ағаштармен жасалған, осылайша олар орындалу уақытында жадты бөлуді қажет етпейді.

Сауда-клиринг жүйеміздің даму тарихына қысқаша тоқталайық.
Сауда және клиринг жүйесі архитектурасының бірінші нұсқасы Unix деп аталатын өзара әрекеттесу негізінде құрылды: ортақ жад, семафорлар және кезектер пайдаланылды және әрбір процесс бір ағыннан тұрды. Бұл тәсіл 1990 жылдардың басында кең тарады.

Жүйенің бірінші нұсқасында шлюздің екі деңгейі және сауда жүйесінің орталық сервері болды. Жұмыс барысы келесідей болды:

• Клиент сұраныс жібереді, ол шлюзге жетеді. Ол пішімнің жарамдылығын тексереді (бірақ деректердің өзін емес) және қате транзакцияларды қабылдамайды.
• Ақпараттық сұраныс жіберілген болса, ол жергілікті түрде орындалады; егер біз транзакция туралы айтатын болсақ, онда ол орталық серверге қайта бағытталады.
• Содан кейін сауда механизмі транзакцияны өңдейді, жергілікті жадты өзгертеді және транзакцияға жауап пен транзакцияның өзіне бөлек репликация механизмін пайдаланып қайталау үшін жібереді.
• Шлюз орталық түйіннен жауапты алады және оны клиентке жібереді.
• Біраз уақыттан кейін Шлюз репликация механизмі арқылы транзакцияны алады және бұл жолы келесі ақпараттық сұраулар соңғы деректерді көрсететіндей деректер құрылымдарын өзгерте отырып, оны жергілікті түрде орындайды.

Шын мәнінде, ол Gateway сауда жүйесінде орындалған әрекеттерді толығымен қайталаған репликация үлгісін сипаттайды. Бөлек репликация арнасы транзакциялардың бірнеше қатынас түйіндері бойынша бірдей тәртіпте орындалуын қамтамасыз етті.

Код бір ағынды болғандықтан, көптеген клиенттерге қызмет көрсету үшін технологиялық шанышқылары бар классикалық схема пайдаланылды. Дегенмен, бүкіл дерекқорды айыру өте қымбат болды, сондықтан TCP сеанстарынан пакеттерді жинайтын және оларды бір кезекке (SystemV хабарлама кезегі) тасымалдайтын жеңіл қызмет көрсету процестері пайдаланылды. Gateway және Trade Engine тек осы кезекпен жұмыс істеді, транзакцияларды орындау үшін сол жерден алды. Енді оған жауап жіберу мүмкін болмады, себебі оны қай қызмет процесі оқуы керек екені белгісіз болды. Сондықтан біз қулыққа жүгіндік: әрбір айырықша процесс өзі үшін жауап кезегін жасады және кіріс кезегіне сұрау түскенде, оған жауап кезегіне арналған тег бірден қосылды.

Деректердің үлкен көлемін кезектен кезекке үнемі көшіру әсіресе ақпараттық сұрауларға тән проблемаларды тудырады. Сондықтан біз тағы бір трюк қолдандық: жауап беру кезегімен қатар, әрбір процесс ортақ жадты (SystemV Shared Memory) құрады. Пакеттердің өзі оған орналастырылды және кезекте тек тег сақталады, бұл түпнұсқа пакетті табуға мүмкіндік береді. Бұл процессор кэшінде деректерді сақтауға көмектесті.

SystemV IPC кезек, жад және семафор нысандарының күйін көруге арналған утилиталарды қамтиды. Біз мұны белгілі бір сәтте жүйеде не болып жатқанын, пакеттер қайда жиналғанын, не бұғатталғанын және т.б. түсіну үшін белсенді түрде қолдандық.

Алғашқы модернизациялар

Ең алдымен, біз бір процесстік шлюзден құтылдық. Оның маңызды кемшілігі оның бір репликация транзакциясын немесе клиенттен бір ақпарат сұрауын өңдей алуында болды. Жүктеме ұлғайған сайын, Gateway сұрауларды өңдеуге ұзағырақ уақыт алады және репликация ағынын өңдей алмайды. Сонымен қатар, егер клиент транзакцияны жіберген болса, онда сізге тек оның жарамдылығын тексеріп, оны әрі қарай жіберу керек. Сондықтан, біз жалғыз шлюз процесін параллель жұмыс істей алатын бірнеше құрамдастармен ауыстырдық: RW құлыптауын қолдану арқылы ортақ жад аймағында бір-бірінен тәуелсіз жұмыс істейтін көп ағынды ақпарат және транзакция процестері. Сонымен бірге біз жіберу және репликация процестерін енгіздік.

Жоғары жиілікті сауданың әсері

Архитектураның жоғарыдағы нұсқасы 2010 жылға дейін болды. Осы уақытта біз HP Superdome серверлерінің өнімділігіне қанағаттанбадық. Сонымен қатар, PA-RISC архитектурасы іс жүзінде өлді; сатушы ешқандай маңызды жаңартуларды ұсынбады. Нәтижесінде біз HP UX/PA RISC жүйесінен Linux/x86 нұсқасына көшуді бастадық. Өту қол жеткізу серверлерін бейімдеуден басталды.

Неліктен архитектураны қайтадан өзгертуге тура келді? Мәселе мынада, жоғары жиілікті сауда жүйе өзегіндегі жүктеме профилін айтарлықтай өзгертті.

Айтайық, бізде бағаның айтарлықтай өзгеруіне себеп болған шағын транзакция болды - біреу жарты миллиард доллар сатып алды. Бірнеше миллисекундтан кейін нарықтың барлық қатысушылары мұны байқап, түзетуді бастайды. Әрине, сұраулар жүйені тазалау үшін көп уақытты қажет ететін үлкен кезекте тұрады.

Осы 50 мс интервалында орташа жылдамдық секундына шамамен 16 мың транзакцияны құрайды. Терезені 20 мс дейін азайтатын болсақ, біз секундына 90 мың транзакцияның орташа жылдамдығын аламыз, шыңында 200 мың транзакция. Басқаша айтқанда, жүктеме тұрақты емес, кенеттен жарылыстармен. Ал сұраныс кезегі әрқашан жылдам өңделуі керек.

Бірақ неліктен мүлде кезек бар? Сонымен, біздің мысалда көптеген пайдаланушылар бағаның өзгеруін байқады және сәйкесінше транзакцияларды жіберді. Олар шлюзге келеді, ол оларды сериялайды, белгілі бір тәртіп орнатады және оларды желіге жібереді. Маршрутизаторлар пакеттерді араластырып, қайта жібереді. Кімнің пакеті бірінші келсе, сол транзакция «жеңді». Нәтижесінде биржа клиенттері егер бір транзакция бірнеше шлюзден жіберілсе, оны жылдам өңдеу мүмкіндігі артқанын байқай бастады. Көп ұзамай айырбастау роботтары Gateway-ді сұраулармен бомбалай бастады және транзакциялар көшкіні пайда болды.

Эволюцияның жаңа кезеңі

Кең ауқымды сынақтар мен зерттеулерден кейін біз нақты уақыттағы операциялық жүйе ядросына көштік. Ол үшін біз RedHat Enterprise MRG Linux таңдадық, мұнда MRG нақты уақыттағы хабар алмасу торын білдіреді. Нақты уақыттағы патчтардың артықшылығы - олар жүйені ең жылдам орындау үшін оңтайландырады: барлық процестер FIFO кезегіне қойылған, ядроларды оқшаулауға болады, шығарулар жоқ, барлық транзакциялар қатаң ретпен өңделеді.

Қызыл – кәдімгі ядродағы кезекпен жұмыс, жасыл – нақты уақыттағы ядрода жұмыс.

Бірақ қарапайым серверлерде төмен кідіріске қол жеткізу оңай емес:

• x86 архитектурасында маңызды перифериялық құрылғылармен жұмыс істеу үшін негіз болып табылатын SMI режимі үлкен кедергі жасайды. Аппараттық құралдардың барлық түрлерін өңдеу және компоненттер мен құрылғыларды басқару операциялық жүйе микробағдарлама не істеп жатқанын мүлде көрмейтін мөлдір SMI деп аталатын режимде микробағдарлама арқылы жүзеге асырылады. Әдетте, барлық негізгі жеткізушілер микробағдарлама серверлері үшін SMI өңдеу көлемін азайтуға мүмкіндік беретін арнайы кеңейтімдерді ұсынады.
• Процессор жиілігін динамикалық басқару болмауы керек, бұл қосымша тоқтап қалуға әкеледі.
• Файлдық жүйе журналы тазартылған кезде ядрода күтпеген кідірістерді тудыратын белгілі процестер орын алады.
• Сіз CPU жақындығы, үзіліс жақындығы, NUMA сияқты нәрселерге назар аударуыңыз керек.

Мен нақты уақытта өңдеуге арналған Linux аппараттық құралдары мен ядросын орнату тақырыбы бөлек мақалаға лайық екенін айтуым керек. Біз жақсы нәтижеге қол жеткізгенге дейін көп уақытты эксперимент пен зерттеуге жұмсадық.

PA-RISC серверлерінен x86-ға көшкен кезде бізге жүйелік кодты көп өзгертудің қажеті болмады, біз оны жай ғана бейімдеп, қайта конфигурацияладық. Сонымен бірге біз бірнеше қателерді түзеттік. Мысалы, PA RISC Big endian жүйесі, ал x86 Little endian жүйесі болғанының салдары тез пайда болды: мысалы, деректер қате оқылды. Күрделі қате PA RISC пайдаланатын болды дәйекті дәйекті (Кезекті дәйекті) жадқа қол жеткізу, ал x86 оқу әрекеттерін қайта реттей алады, сондықтан бір платформада абсолютті жарамды код екіншісінде бұзылды.

x86-ге ауысқаннан кейін өнімділік үш есе дерлік өсті, транзакцияны өңдеудің орташа уақыты 60 мкс-қа дейін қысқарды.

Енді жүйе архитектурасына қандай негізгі өзгерістер енгізілгенін егжей-тегжейлі қарастырайық.

Ыстық резервтік эпопея

Тауар серверлеріне ауысқан кезде біз олардың сенімділігі төмен екенін білдік. Сондықтан, жаңа архитектураны құру кезінде біз бір немесе бірнеше түйіндердің істен шығу мүмкіндігін априори болжадық. Сондықтан резервтік машиналарға өте жылдам ауыса алатын ыстық күту жүйесі қажет болды.

Сонымен қатар, басқа да талаптар болды:

• Ешбір жағдайда өңделген транзакцияларды жоғалтпау керек.
• Жүйе біздің инфрақұрылымымыз үшін мүлдем ашық болуы керек.
• Клиенттер үзілген қосылымдарды көрмеуі керек.
• Брондау айтарлықтай кешіктіруді енгізбеуі керек, себебі бұл алмасу үшін маңызды фактор.

Ыстық күту жүйесін құру кезінде біз қос істен шығу сияқты сценарийлерді қарастырмадық (мысалы, бір сервердегі желі жұмысын тоқтатты және негізгі сервер қатып қалды); бағдарламалық қамтамасыз етудегі қателердің болу мүмкіндігін қарастырмады, себебі олар тестілеу кезінде анықталады; және аппараттық құралдардың дұрыс жұмыс істемеуін қарастырмады.

Нәтижесінде біз келесі схемаға келдік:

• Негізгі сервер шлюз серверлерімен тікелей әрекеттесті.
• Негізгі серверде алынған барлық транзакциялар жеке арна арқылы резервтік серверге дереу көшірілді. Төреші (губернатор) қандай да бір мәселелер туындаған жағдайда ауыстыруды үйлестірді.

  

• Негізгі сервер әрбір транзакцияны өңдеп, резервтік серверден растауды күтті. Кідірісті барынша азайту үшін сақтық көшірме серверінде транзакцияның аяқталуын күтуден аулақ болдық. Транзакцияның желі бойынша өту уақыты орындалу уақытымен салыстырылатындықтан, қосымша кідіріс қосылмаған.
• Біз тек алдыңғы транзакция үшін негізгі және резервтік серверлердің өңдеу күйін тексере алдық, ал ағымдағы транзакцияның өңдеу күйі белгісіз болды. Біз әлі де бір ағынды процестерді қолданып жатқандықтан, Сақтық көшірмеден жауап күту бүкіл өңдеу ағынын бәсеңдететін еді, сондықтан біз ақылға қонымды ымыраға келдік: біз алдыңғы транзакцияның нәтижесін тексердік.

Схема келесідей жұмыс істеді.

Негізгі сервер жауап беруді тоқтатты делік, бірақ шлюздер байланысын жалғастыруда. Сақтық көшірме серверінде күту уақыты орын алады, ол оған негізгі сервер рөлін тағайындайтын басқарушымен байланысады және барлық шлюздер жаңа негізгі серверге ауысады.

Егер негізгі сервер желіге қайта оралса, ол сонымен қатар ішкі күту уақытын қосады, себебі белгілі бір уақыт ішінде шлюзден серверге қоңыраулар болмаған. Содан кейін ол губернаторға жүгінеді және ол оны схемадан шығарып тастайды. Нәтижесінде биржа сауда кезеңінің соңына дейін бір сервермен жұмыс істейді. Сервердің істен шығу ықтималдығы өте төмен болғандықтан, бұл схема өте қолайлы деп саналды, ол күрделі логиканы қамтымайды және сынау оңай болды.

Жалғасы бар.

Ақпарат көзі: www.habr.com