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

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

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

Биз дүйнөдөгү бардык класстардагы активдерди соодалаган жана биржа кызматтарынын толук спектрин камсыз кылган бир нече биржалардын бирибиз. Мисалы, өткөн жылы биз облигациялардын соодасынын көлөмү боюнча дүйнөдө экинчи, бардык биржалар арасында 25-орун, коомдук биржалар арасында капиталдаштыруу боюнча 13-орунда болдук.

Кесиптик соода катышуучулары үчүн жооп берүү убактысы, убакыт бөлүштүрүүнүн туруктуулугу (jitter) жана бүткүл комплекстин ишенимдүүлүгү сыяктуу параметрлер абдан маанилүү. Учурда биз күнүнө он миллиондогон транзакцияларды иштетебиз. Системанын ядросу тарабынан ар бир транзакцияны иштетүү ондогон микросекундду талап кылат. Албетте, жаңы жыл түнү уюлдук операторлор же издөө системаларынын өздөрү биздикине караганда көбүрөөк жүктөмгө ээ, бирок иш жүгү боюнча жогоруда айтылган өзгөчөлүктөр менен кошо биз менен салыштыра тургандар аз, менимче. Ошол эле учурда система бир секундага да басаңдабай, таптакыр туруктуу иштеп, бардык колдонуучулар бирдей шартта болушу биз үчүн маанилүү.

Бир аз тарых

1994-жылы, австралиялык ASTS системасы Москва банктар аралык валюта биржасында (MICEX) ишке киргизилген жана ошол учурдан тартып россиялык электрондук сооданын тарыхын эсептөөгө болот. 1998-жылы интернет-сооданы киргизүү үчүн биржа архитектурасы модернизацияланган. Ошондон бери бардык системаларда жана подсистемаларда жаңы чечимдерди жана архитектуралык өзгөрүүлөрдү ишке ашыруунун ылдамдыгы гана күч алууда.

Ошол жылдары алмашуу системасы жогорку деңгээлдеги аппараттык жабдыктарда - өтө ишенимдүү HP Superdome 9000 серверинде иштеген (бул жерде курулган). PA-RISC), анда баары кайталанган: киргизүү/чыгаруу подсистемалары, тармак, оперативдүү эс тутум (чындыгында RAMдын RAID массиви бар болчу), процессорлор (ысык алмаштыруучу). Машинаны токтотпостон сервердин каалаган компонентин өзгөртүүгө мүмкүн болгон. Биз бул түзмөктөргө таянып, аларды иш жүзүндө коопсуз деп эсептедик. Иштөө системасы Unix сыяктуу HP UX системасы болгон.

Бирок, болжол менен 2010-жылдан бери, жогорку жыштыктагы соода (HFT) же жогорку жыштыктагы соода деп аталган көрүнүш пайда болду - жөнөкөй тил менен айтканда, биржа роботтору. Болгону 2,5 жылдын ичинде биздин серверлердеги жүк 140 эсеге өстү.

Мындай жүктү эски архитектура жана жабдуулар менен көтөрүү мүмкүн эмес болчу. Кандайдыр бир түрдө көнүү керек болчу.

баштап

Алмашуу системасына суроо-талаптар эки түргө бөлүнөт:

• Транзакциялар. Эгер сиз долларды, акцияларды же башка нерсени сатып алгыңыз келсе, анда сиз соода системасына транзакция жөнөтүп, ийгилик жөнүндө жооп аласыз.
• Маалымат суроо-талаптары. Эгерде сиз учурдагы бааны билгиңиз келсе, буйрутма китебин же индексти карап көрүңүз, андан кийин маалымат сурамдарын жөнөтүңүз.

Схематикалык жактан системанын өзөгүн үч деңгээлге бөлүүгө болот:

• Брокерлер жана кардарлар иштеген кардар деңгээли. Алардын баары кирүү серверлери менен иштешет.
• Шлюз серверлери бардык маалыматтык суроо-талаптарды жергиликтүү түрдө иштеткен серверлерди кэштейт. Учурда Сбербанктын акциялары кандай баа менен сатылып жатканын билгиңиз келеби? Сурам кирүү серверине барат.
• Бирок, эгерде сиз акцияларды сатып алгыңыз келсе, анда сурам борбордук серверге (Trade Engine) барат. Рыноктун ар бир түрү үчүн бирден ушундай сервер бар, алар маанилүү роль ойнойт, биз бул системаны алар үчүн түздүк.

соода системасынын өзөгү бардык бүтүмдөр алмашуу бүтүмдөр болуп саналат акылдуу-эсте маалымат базасы болуп саналат. Негизги C тилинде жазылган, бир гана тышкы көз карандылыктар libc китепканасы болгон жана динамикалык эстутум такыр бөлүштүрүлгөн эмес. Иштеп чыгуу убактысын кыскартуу үчүн система массивдердин статикалык топтому менен жана маалыматтарды статикалык көчүрүү менен башталат: биринчиден, учурдагы күндүн бардык маалыматтары эстутумга жүктөлөт жана андан ары дискке кирүүгө болбойт, бардык иштер эстутумда гана аткарылат. Система башталганда, бардык маалымдама маалыматтары иргелет, ошондуктан издөө абдан натыйжалуу иштейт жана иштөө убактысында аз убакыт талап кылынат. Бардык таблицалар динамикалык маалымат структуралары үчүн интрузивдик тизмелер жана дарактар ​​менен түзүлгөн, ошондуктан алар иштөө учурунда эстутумду бөлүштүрүүнү талап кылбайт.

Биздин соода жана клирингдик системабыздын өнүгүү тарыхына кыскача токтоло кетели.
Соода жана клиринг системасынын архитектурасынын биринчи версиясы Unix өз ара аракеттешүүсү деп аталган нерсеге курулган: жалпы эс тутум, семафорлор жана кезектер колдонулган жана ар бир процесс бир жиптен турган. Бул ыкма 1990-жылдардын башында кеңири жайылган.

Системанын биринчи версиясында Gatewayдин эки деңгээлин жана соода системасынын борбордук сервери камтылган. Иш агымы мындай болгон:

• кардар Gateway жетет, сурам жөнөтөт. Ал форматтын жарактуулугун текшерет (бирок маалыматтын өзү эмес) жана туура эмес транзакцияларды четке кагат.
• Эгерде маалыматтык суроо-талап жөнөтүлгөн болсо, ал жергиликтүү түрдө аткарылат; эгерде биз транзакция жөнүндө сөз кыла турган болсок, анда ал борбордук серверге багытталат.
• Соода кыймылдаткычы андан кийин транзакцияны иштеп чыгат, жергиликтүү эстутумду өзгөртөт жана транзакцияга жоопту жана транзакциянын өзүнө өзүнчө репликациялоо кыймылдаткычын колдонуу менен репликациялоо үчүн жөнөтөт.
• Gateway борбордук түйүндөн жооп алат жана аны кардарга жөнөтөт.
• Бир нече убакыт өткөндөн кийин, Gateway репликация механизми аркылуу транзакцияны кабыл алат жана бул жолу аны локалдык түрдө аткарат, кийинки маалыматтык суроо-талаптар акыркы маалыматтарды көрсөтүү үчүн өзүнүн маалымат структураларын өзгөртөт.

Чынында, бул Gateway соода системасында аткарылган иш-аракеттерди толугу менен кайталаган репликация моделин сүрөттөйт. Өзүнчө репликация каналы транзакциялардын бир нече кирүү түйүндөрүндө бирдей тартипте аткарылышын камсыз кылды.

Код бир жиптүү болгондуктан, көптөгөн кардарларды тейлөө үчүн процесс айрылары менен классикалык схема колдонулган. Бирок, бардык маалымат базасын айрыруу абдан кымбатка турду, ошондуктан TCP сеанстарынан пакеттерди чогултуп, аларды бир кезекке (SystemV Message Queue) өткөрүп берүүчү жеңил тейлөө процесстери колдонулган. Gateway жана Trade Engine бул кезек менен гана иштеген, ал жерден транзакцияларды аткаруу үчүн алган. Ага жооп жөнөтүү мүмкүн болбой калды, анткени аны кайсы кызмат процесси окушу керектиги такталган эмес. Ошентип, биз айла-амалга кайрылдык: ар бир айры процесс өзүнө жооп кезегин түздү жана кирүүчү кезекке суроо-талап келгенде, ага жооп кезегинин теги дароо кошулду.

Дайыма чоң көлөмдөгү маалыматтарды кезектен кезекке көчүрүү көйгөйлөрдү жаратты, айрыкча маалымат сурамдарына мүнөздүү. Ошондуктан, биз дагы бир трюк колдондук: жооп кезегинен тышкары, ар бир процесс ошондой эле жалпы эстутумду (SystemV Shared Memory) түздү. Пакеттердин өздөрү ага жайгаштырылып, кезекте бир гана теги сакталып, түпнуска пакетти табууга мүмкүнчүлүк түзүлдү. Бул процессордун кэшинде маалыматтарды сактоого жардам берди.

SystemV IPC кезектин, эс тутумдун жана семафор объекттеринин абалын көрүү үчүн утилиталарды камтыйт. Биз муну белгилүү бир учурда системада эмне болуп жатканын, пакеттер кайда чогулганын, эмне бөгөттөлгөндүгүн жана башкаларын түшүнүү үчүн активдүү колдондук.

Биринчи модернизациялар

Биринчиден, биз бир процесстик шлюзден кутулдук. Анын олуттуу кемчилиги, ал бир репликация транзакциясын же кардардын бир маалымат суроо-талабын чече алаарында болгон. Жана жүк көбөйгөн сайын, Gateway суроо-талаптарды иштеп чыгууга көбүрөөк убакыт талап кылынат жана репликация агымын иштете албайт. Мындан тышкары, эгерде кардар транзакцияны жөнөтсө, анда сиз анын жарактуулугун текшерип, андан ары жөнөтүшүңүз керек. Ошондуктан, биз бирдиктүү Gateway процессин параллелдүү иштей турган бир нече компоненттер менен алмаштырдык: RW кулпусун колдонуу менен жалпы эс тутум аймагында бири-биринен көз карандысыз иштеген көп агымдуу маалымат жана транзакция процесстери. Ошол эле учурда биз жөнөтүү жана репликация процесстерин киргиздик.

Жогорку жыштыктагы сооданын таасири

Архитектуранын жогорудагы версиясы 2010-жылга чейин болгон. Ошол эле учурда, биз HP Superdome серверлеринин иштешине канааттанбай калдык. Мындан тышкары, PA-RISC архитектурасы дээрлик өлүп калган; сатуучу эч кандай олуттуу жаңыртууларды сунуш кылган эмес. Натыйжада, биз HP UX/PA RISCден Linux/x86га өтө баштадык. Өтүү кирүү серверлерин адаптациялоо менен башталды.

Эмне үчүн кайра архитектураны өзгөртүүгө туура келди? Чындыгында, жогорку жыштыктагы соода системанын өзөгүндө жүктөө профилин олуттуу түрдө өзгөрттү.

Баанын олуттуу өзгөрүшүнө алып келген кичинекей транзакция болду дейли – кимдир бирөө жарым миллиард доллар сатып алды. Бир-эки миллисекунддан кийин рыноктун бардык катышуучулары муну байкап, оңдоо иштерин жүргүзө башташат. Албетте, суроо-талаптар чоң кезекке тизилет, аны тазалоо үчүн система көп убакытты талап кылат.

Бул 50 мс аралыкта орточо ылдамдыгы секундасына 16 миң транзакцияны түзөт. Эгерде биз терезени 20 мсге чейин кыскартсак, анда биз секундасына 90 миң транзакциянын орточо ылдамдыгын алабыз, 200 миң транзакция чокусунда. Башкача айтканда, жүк туруктуу эмес, капысынан жарылуулар менен. Ал эми суроо-талаптар ар дайым тез иштелип чыгышы керек.

Бирок эмне үчүн деги эле кезек бар? Ошентип, биздин мисалда көптөгөн колдонуучулар баанын өзгөрүшүн байкап, ошого жараша транзакцияларды жөнөтүштү. Алар Gatewayге келишет, ал аларды сериялаштырат, белгилүү бир тартипти орнотот жана аларды тармакка жөнөтөт. Маршрутизаторлор пакеттерди аралаштырып, кайра жөнөтүшөт. Кимдин пакети биринчи келсе, ошол транзакция "утуп алган". Натыйжада, алмашуу кардарлар бир эле транзакция бир нече Gateways жөнөтүлгөн болсо, анда аны тез иштетүү мүмкүнчүлүгү жогорулаганын байкай баштады. Көп өтпөй, алмашуу роботтору 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 мкс чейин кыскарды.

Эми системанын архитектурасына кандай негизги өзгөртүүлөр киргизилгенин кененирээк карап чыгалы.

Ысык резервдик эпос

Товар серверлерине өткөндө биз алардын ишенимдүүлүгү аз экенин билчүбүз. Ошондуктан, жаңы архитектураны түзүүдө биз бир же бир нече түйүндөрдүн иштебей калуу мүмкүнчүлүгүн априори кабыл алганбыз. Ошондуктан, резервдик машиналарга өтө тез өтө турган ысык күтүү системасы керек болчу.

Мындан тышкары, башка талаптар бар:

• Эч кандай шартта сиз иштетилген транзакцияларды жоготпошуңуз керек.
• Система биздин инфраструктурабыз үчүн ачык-айкын болушу керек.
• Кардарлар үзүлгөн байланыштарды көрбөшү керек.
• Резервдер олуттуу кечигүүнү киргизбеши керек, анткени бул алмашуу үчүн маанилүү фактор.

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

Натыйжада, биз төмөнкү схемага келдик:

• Негизги сервер Gateway серверлери менен түздөн-түз иштешет.
• Негизги серверде алынган бардык транзакциялар өзүнчө канал аркылуу заматта резервдик серверге көчүрүлгөн. Арбитр (губернатор) кандайдыр бир көйгөй жаралса, которууну координациялайт.

  

• Негизги сервер ар бир транзакцияны иштеп чыгып, резервдик серверден ырастоону күткөн. Кечигүүнү минималдаштыруу үчүн, биз транзакциянын камдык серверде аякташын күтүүдөн качтык. Тармак боюнча өтүү үчүн транзакцияга кеткен убакыт аткаруу убактысы менен салыштырылгандыктан, кошумча кечигүү кошулган жок.
• Биз мурунку транзакциянын негизги жана резервдик серверлеринин иштетүү статусун гана текшере алдык, ал эми учурдагы транзакциянын иштетүү статусу белгисиз болчу. Биз дагы эле бир жиптүү процесстерди колдонуп жаткандыктан, Камдык көчүрмөдөн жооп күтүү бүтүндөй иштетүү агымын жайлатмак, ошондуктан биз акылга сыярлык компромисске келдик: мурунку транзакциянын жыйынтыгын текшердик.

Схема төмөнкүдөй иштеген.

Негизги сервер жооп бербей калды дейли, бирок Шлюз байланышты улантат. Камдык серверде тайм-аут пайда болот, ал Губернатор менен байланышат, ал ага негизги сервердин ролун дайындайт жана бардык шлюздар жаңы негизги серверге өтөт.

Эгерде негизги сервер кайра онлайнга кирсе, анда ал ички тайм-аутту да ишке киргизет, анткени белгилүү бир убакыт бою Шлюздан серверге чалуулар болгон эмес. Анан ал да губернаторго кайрылып, аны схемадан чыгарат. Натыйжада, биржа соода мезгилинин аягына чейин бир сервер менен иштейт. Сервердин иштебей калуу ыктымалдыгы өтө төмөн болгондуктан, бул схема абдан алгылыктуу деп эсептелген, ал татаал логиканы камтыган эмес жана аны текшерүү оңой болгон.

Уландысы бар.

Source: www.habr.com