Ово је наставак дуге приче о нашем трновитом путу ка стварању моћног система високог оптерећења који обезбеђује рад Берзе. Први део је овде:
Мистериозна грешка
Након бројних тестирања, ажурирани систем трговања и клиринга је пуштен у рад, а ми смо наишли на грешку о којој бисмо могли да напишемо детективско-мистичну причу.
Убрзо након покретања на главном серверу, једна од трансакција је обрађена са грешком. Међутим, на бацкуп серверу је све било у реду. Испоставило се да је једноставна математичка операција израчунавања експонента на главном серверу дала негативан резултат из правог аргумента! Наставили смо истраживање и у регистру ССЕ2 смо пронашли разлику у једном биту, који је одговоран за заокруживање при раду са бројевима с помичним зарезом.
Написали смо једноставан тест услужни програм за израчунавање експонента са постављеним битом заокруживања. Испоставило се да је у верзији РедХат Линук-а коју смо користили дошло до грешке у раду са математичком функцијом када је несрећни бит убачен. То смо пријавили РедХат-у, након неког времена добили смо закрпу од њих и избацили је. Грешка се више није јављала, али није било јасно одакле је уопште дошао овај бит? Функција је била одговорна за то fesetround из језика Ц. Пажљиво смо анализирали наш код у потрази за наводном грешком: проверили смо све могуће ситуације; погледао све функције које су користиле заокруживање; покушао да репродукује неуспелу сесију; користили различите компајлере са различитим опцијама; Коришћене су статичка и динамичка анализа.
Узрок грешке није пронађен.
Затим су почели да провере хардвер: извршили су тестирање оптерећења процесора; проверио РАМ; Чак смо спровели тестове за веома мало вероватан сценарио вишебитне грешке у једној ћелији. Без успеха.
На крају смо се определили за теорију из света физике високих енергија: нека високоенергетска честица је улетела у наш дата центар, пробила зид кућишта, ударила у процесор и изазвала да се брава окидача заглави баш у том делу. Ова апсурдна теорија названа је „неутрино“. Ако сте далеко од физике честица: неутрини готово да немају интеракцију са спољним светом, и сигурно нису у стању да утичу на рад процесора.
Пошто није било могуће пронаћи узрок квара, „увредљиви“ сервер је за сваки случај уклоњен из рада.
После неког времена почели смо да побољшавамо систем вруће резервне копије: увели смо такозване „топле резерве“ (топле) - асинхроне реплике. Добили су низ трансакција које су се могле налазити у различитим центрима података, али топли нису активно комуницирали са другим серверима.
Зашто је то урађено? Ако резервни сервер не успе, онда топло везан за главни сервер постаје нова резервна копија. То јест, након квара, систем не остаје са једним главним сервером до краја трговачке сесије.
А када је нова верзија система тестирана и пуштена у рад, поново се појавила грешка бита заокруживања. Штавише, са повећањем броја топлих сервера, грешка је почела да се појављује чешће. У исто време, продавац није имао шта да покаже, јер није било конкретних доказа.
Током следеће анализе ситуације појавила се теорија да би проблем могао бити везан за ОС. Написали смо једноставан програм који позива функцију у бесконачној петљи fesetround, памти тренутно стање и проверава га кроз спавање, а то се ради у многим конкурентским нитима. Након одабира параметара за спавање и броја нити, почели смо доследно да репродукујемо квар бита након око 5 минута покретања услужног програма. Међутим, Ред Хат подршка није успела да то репродукује. Тестирање осталих наших сервера показало је да су само они са одређеним процесорима подложни грешци. У исто време, прелазак на ново језгро решио је проблем. На крају смо једноставно заменили ОС, а прави узрок грешке је остао нејасан.
И одједном је прошле године објављен чланак на Хабреу “" Ситуација која је у њој описана била је врло слична нашој, али је аутор продужио истрагу и изнео теорију да је грешка у микрокоду. А када се Линук кернели ажурирају, произвођачи такође ажурирају микрокод.
Даљи развој система
Иако смо се решили грешке, ова прича нас је натерала да преиспитамо архитектуру система. На крају крајева, нисмо били заштићени од понављања таквих грешака.
Следећи принципи су чинили основу за следећа побољшања система резервација:
- Не можете веровати никоме. Сервери можда неће исправно функционисати.
- Већинска резерва.
- Обезбеђивање консензуса. Као логичан додатак већинској резерви.
- Двоструки неуспеси су могући.
- Виталност. Нова шема вруће приправности не би требало да буде гора од претходне. Трговање треба да се одвија без прекида до последњег сервера.
- Благо повећање латенције. Сваки застој повлачи велике финансијске губитке.
- Минимална мрежна интеракција да би кашњење било што мање.
- Избор новог главног сервера за секунде.
Ниједно решење доступно на тржишту нам није одговарало, а Рафт протокол је још био у повоју, па смо креирали сопствено решење.
Умрежавање
Поред система резервација, започели смо модернизацију мрежне интеракције. У/И подсистем се састојао од многих процеса, који су имали најгори утицај на подрхтавање и кашњење. Са стотинама процеса који рукују ТЦП везама, били смо приморани да стално прелазимо између њих, а на микросекундној скали ово је прилично дуготрајна операција. Али најгоре је то што када је процес примио пакет на обраду, послао га је у један СистемВ ред, а затим чекао догађај из другог СистемВ реда. Међутим, када постоји велики број чворова, долазак новог ТЦП пакета у једном процесу и пријем података у ред у другом представљају два конкурентна догађаја за ОС. У овом случају, ако нема доступних физичких процесора за оба задатка, један ће бити обрађен, а други ће бити стављен у ред чекања. Немогуће је предвидети последице.
У таквим ситуацијама може се користити динамичка контрола приоритета процеса, али то ће захтевати коришћење системских позива који захтевају велике ресурсе. Као резултат тога, прешли смо на једну нит користећи класични еполл, што је значајно повећало брзину и смањило време обраде трансакције. Такође смо се ослободили одвојених мрежних комуникационих процеса и комуникације преко СистемВ-а, значајно смањили број системских позива и почели да контролишемо приоритете рада. Само на И/О подсистему било је могуће уштедети око 8-17 микросекунди, у зависности од сценарија. Ова једнонитна шема се од тада користи непромењена; једна еполл нит са маргином је довољна за сервисирање свих веза.
Обрада трансакција
Све веће оптерећење нашег система захтевало је надоградњу скоро свих његових компоненти. Али, нажалост, стагнација у расту брзине процесора последњих година више није омогућила директно скалирање процеса. Због тога смо одлучили да процес Енгине поделимо на три нивоа, од којих је најоптерећенији систем за проверу ризика, који процењује доступност средстава на рачунима и креира саме трансакције. Али новац може бити у различитим валутама и требало је схватити на основу чега треба да се подели обрада захтева.
Логично решење је да се подели по валути: један сервер тргује у доларима, други у фунтама, а трећи у еврима. Али ако се са таквом шемом пошаљу две трансакције за куповину различитих валута, онда ће се појавити проблем десинхронизације новчаника. Али синхронизација је тешка и скупа. Стога би било исправно да се дели одвојено по новчаницима и одвојено по инструментима. Иначе, већина западних берзи нема задатак да проверава ризике тако акутно као ми, па се то најчешће ради ван мреже. Требало је да применимо онлајн верификацију.
Хајде да објаснимо на примеру. Трговац жели да купи 30 долара, а захтев иде на валидацију трансакције: проверавамо да ли је овом трговцу дозвољен овај начин трговања и да ли има потребна права. Ако је све у реду, захтев иде у систем верификације ризика, тј. ради провере довољности средстава за закључење трансакције. Постоји напомена да је потребан износ тренутно блокиран. Захтев се затим прослеђује систему трговања, који одобрава или не одобрава трансакцију. Рецимо да је трансакција одобрена - тада систем верификације ризика означава да је новац деблокиран, а рубље се претварају у доларе.
Генерално, систем за проверу ризика садржи сложене алгоритме и врши велику количину прорачуна који захтевају велике ресурсе, а не само проверава „стање рачуна“, како се чини на први поглед.
Када смо почели да делимо Енгине процес на нивое, наишли смо на проблем: код који је био доступан у то време активно је користио исти низ података у фазама валидације и верификације, што је захтевало поновно писање целе базе кода. Као резултат тога, од савремених процесора смо позајмили технику за обраду инструкција: сваки од њих је подељен на мале фазе и неколико радњи се обављају паралелно у једном циклусу.
Након мале адаптације кода, направили смо цевовод за паралелну обраду трансакција, у којем је трансакција подељена у 4 фазе цевовода: мрежна интеракција, валидација, извршење и објављивање резултата
Погледајмо пример. Имамо два система за обраду, серијски и паралелни. Прва трансакција стиже и шаље се на валидацију у оба система. Друга трансакција одмах стиже: у паралелном систему се одмах покреће, ау секвенцијалном систему се ставља у ред чекања да прва трансакција прође кроз тренутну фазу обраде. Односно, главна предност цевоводне обраде је што брже обрађујемо ред трансакција.
Тако смо дошли до АСТС+ система.
Истина, ни са транспортерима није све тако глатко. Рецимо да имамо трансакцију која утиче на низове података у суседној трансакцији; ово је типична ситуација за размену. Таква трансакција се не може извршити у цевоводу јер може утицати на друге. Ова ситуација се назива опасност од података, и такве трансакције се једноставно обрађују одвојено: када понестане „брзе“ трансакције у реду, цевовод се зауставља, систем обрађује „спору“ трансакцију, а затим поново покреће цевовод. На срећу, удео таквих трансакција у укупном току је веома мали, тако да се цевовод тако ретко зауставља да не утиче на укупне перформансе.
Затим смо почели да решавамо проблем синхронизације три нити извршења. Резултат је био систем заснован на прстенастом баферу са ћелијама фиксне величине. У овом систему све је подложно брзини обраде, подаци се не копирају.
- Сви долазни мрежни пакети улазе у фазу алокације.
- Постављамо их у низ и означавамо их као доступне за фазу #1.
- Друга трансакција је стигла, поново је доступна за фазу број 1.
- Прва нит обраде види доступне трансакције, обрађује их и премешта их у следећу фазу друге нити обраде.
- Затим обрађује прву трансакцију и означава одговарајућу ћелију
deleted— сада је доступан за нову употребу.
Цео ред се обрађује на овај начин.
Обрада сваке фазе траје јединицама или десетинама микросекунди. А ако користимо стандардне шеме синхронизације ОС, онда ћемо изгубити више времена на самој синхронизацији. Зато смо почели да користимо спинлоцк. Међутим, ово је веома лоша форма у систему у реалном времену, и РедХат стриктно не препоручује да се то ради, тако да примењујемо спинлоцк на 100 мс, а затим прелазимо у режим семафора да елиминишемо могућност застоја.
Као резултат тога, постигли смо учинак од око 8 милиона трансакција у секунди. И буквално два месеца касније у о ЛМАКС Дисруптору видели смо опис кола са истом функционалношћу.
Сада може постојати неколико нити извршења у једној фази. Све трансакције су обрађене једна по једна, редоследом којим су примљене. Као резултат тога, вршне перформансе су порасле са 18 хиљада на 50 хиљада трансакција у секунди.
Систем управљања берзанским ризиком
Нема ограничења за савршенство и убрзо смо поново почели са модернизацијом: у оквиру АСТС+, почели смо да премештамо системе управљања ризицима и операција поравнања у аутономне компоненте. Развили смо флексибилну модерну архитектуру и нови хијерархијски модел ризика, и покушали да користимо класу где год је то могуће fixed_point уместо double.
Али одмах је настао проблем: како синхронизовати сву пословну логику која функционише већ дуги низ година и пренети је на нови систем? Као резултат тога, прва верзија прототипа новог система морала је бити напуштена. Друга верзија, која је тренутно у производњи, заснована је на истом коду, који ради и у трговачком и у ризичном делу. Током развоја, најтеже је било гит мерге између две верзије. Наш колега Евгениј Мазуренок је обављао ову операцију сваке недеље и сваки пут је псовао веома дуго.
Приликом избора новог система, одмах смо морали да решимо проблем интеракције. Приликом избора магистрале података, било је неопходно обезбедити стабилно подрхтавање и минимално кашњење. ИнфиниБанд РДМА мрежа је била најпогоднија за ово: просечно време обраде је 4 пута мање него у 10 Г Етхернет мрежама. Али оно што нас је заиста очарало је разлика у процентима - 99 и 99,9.
Наравно, ИнфиниБанд има своје изазове. Прво, другачији АПИ - ибвербс уместо сокета. Друго, скоро да не постоје широко доступна решења за размену порука отвореног кода. Покушали смо да направимо сопствени прототип, али се показало да је то веома тешко, па смо одабрали комерцијално решење – Цонфинити Лов Латенци Мессагинг (раније ИБМ МК ЛЛМ).
Тада се појавио задатак правилног поделе система ризика. Ако једноставно уклоните Риск Енгине и не направите средњи чвор, онда се трансакције из два извора могу мешати.
Такозвана Ултра Лов Латенци решења имају режим поновног редоследа: трансакције из два извора се могу распоредити по траженом редоследу по пријему, што се реализује коришћењем посебног канала за размену информација о поруџбини. Али ми још не користимо овај режим: он компликује цео процес, а у бројним решењима уопште није подржан. Поред тога, свакој трансакцији би морале бити додељене одговарајуће временске ознаке, а у нашој шеми овај механизам је веома тешко правилно применити. Због тога смо користили класичну шему са брокером порука, односно са диспечером који дистрибуира поруке између Риск Енгине-а.
Други проблем се односио на приступ клијента: ако постоји неколико Риск Гатеваи-а, клијент треба да се повеже са сваким од њих, а то ће захтевати промене на слоју клијента. Желели смо да побегнемо од овога у овој фази, тако да тренутни Риск Гатеваи дизајн обрађује цео ток података. Ово у великој мери ограничава максималну пропусност, али у великој мери поједностављује интеграцију система.
Дуплирање
Наш систем не би требало да има ни једну тачку квара, то јест, све компоненте морају бити дуплиране, укључујући посредника порука. Овај проблем смо решили коришћењем ЦЛЛМ система: он садржи РЦМС кластер у коме два диспечера могу да раде у мастер-славе режиму, а када један не успе, систем се аутоматски пребацује на други.
Рад са резервним дата центром
ИнфиниБанд је оптимизован за рад као локална мрежа, односно за повезивање опреме за монтирање у рацк, а ИнфиниБанд мрежа се не може поставити између два географски дистрибуирана дата центра. Због тога смо имплементирали мост/диспечер, који се повезује са складиштем порука преко обичних Етхернет мрежа и преноси све трансакције у другу ИБ мрежу. Када треба да мигрирамо из дата центра, можемо изабрати са којим центром података ћемо сада радити.
Резултати
Све наведено није урађено одједном, било је потребно неколико итерација развоја нове архитектуре. Прототип смо направили за месец дана, али је било потребно више од две године да га доведемо у радно стање. Покушали смо да постигнемо најбољи компромис између повећања времена обраде трансакција и повећања поузданости система.
Пошто је систем доста ажуриран, имплементирали смо опоравак података из два независна извора. Ако складиште порука из неког разлога не функционише исправно, можете преузети дневник трансакција из другог извора - из Риск Енгине-а. Овај принцип се посматра у целом систему.
Између осталог, успели смо да сачувамо клијентски АПИ тако да ни брокери ни било ко други не би захтевали значајне прераде нове архитектуре. Морали смо да променимо неке интерфејсе, али није било потребе да се праве значајне промене у оперативном моделу.
Тренутну верзију наше платформе назвали смо Ребус - као скраћеница за две најуочљивије иновације у архитектури, Риск Енгине и БУС.
У почетку смо желели да доделимо само клириншки део, али резултат је био огроман дистрибуирани систем. Клијенти сада могу да комуницирају или са Траде Гатеваи-ом, Цлеаринг Гатеваи-ом или са оба.
Шта смо на крају постигли:
Смањен ниво кашњења. Са малим обимом трансакција, систем ради исто као и претходна верзија, али у исто време може издржати много веће оптерећење.
Врхунске перформансе су порасле са 50 хиљада на 180 хиљада трансакција у секунди. Даље повећање омета једини ток усклађивања налога.
Постоје два начина за даље побољшање: паралелно подударање и промена начина на који функционише са мрежним пролазом. Сада сви мрежни пролази раде према шеми репликације, која под таквим оптерећењем престаје да функционише нормално.
На крају, могу дати неколико савета онима који финализују системе предузећа:
- Будите спремни на најгоре у сваком тренутку. Проблеми увек настају неочекивано.
- Обично је немогуће брзо преправити архитектуру. Нарочито ако треба да постигнете максималну поузданост за више индикатора. Што више чворова, више ресурса је потребно за подршку.
- Сва прилагођена и власничка решења ће захтевати додатне ресурсе за истраживање, подршку и одржавање.
- Не одлажите решавање проблема поузданости система и опоравка након кварова; узмите их у обзир у почетној фази пројектовања.
Извор: ввв.хабр.цом