Vývoj architektury obchodního a clearingového systému Moskevské burzy. Část 1

Ahoj všichni! Jmenuji se Sergey Kostanbaev, na burze vyvíjím jádro obchodního systému.

Když hollywoodské filmy ukazují burzu v New Yorku, vždy to vypadá takto: davy lidí, každý něco křičí, mává papíry, nastává naprostý chaos. To se zde na moskevské burze nikdy nestalo, protože obchodování je od samého počátku vedeno elektronicky a je založeno na dvou hlavních platformách – Spectra (forexový trh) a ASTS (devizový, akciový a peněžní trh). A dnes chci mluvit o vývoji architektury obchodního a clearingového systému ASTS, o různých řešeních a zjištěních. Příběh bude dlouhý, takže jsem ho musela rozdělit na dvě části.

Jsme jednou z mála burz na světě, která obchoduje s aktivy všech tříd a poskytuje celou řadu směnárenských služeb. Například loni jsme se umístili na druhém místě na světě v objemu obchodů s dluhopisy, 25. místo mezi všemi burzami, 13. místo v kapitalizaci mezi veřejnými burzami.

Pro profesionální účastníky obchodování jsou klíčové parametry jako doba odezvy, stabilita rozložení času (jitter) a spolehlivost celého komplexu. V současnosti zpracováváme desítky milionů transakcí denně. Zpracování každé transakce jádrem systému trvá desítky mikrosekund. Mobilní operátoři na Silvestra nebo samotné vyhledávače mají samozřejmě vyšší vytížení než u nás, ale z hlediska vytížení se s námi ve spojení s výše zmíněnými vlastnostmi může srovnávat málokdo, zdá se mi. Zároveň je pro nás důležité, aby se systém ani na vteřinu nezpomalil, fungoval naprosto stabilně a všichni uživatelé byli na stejné úrovni.

Trochu historie

V roce 1994 byl na moskevské mezibankovní měnové burze (MICEX) spuštěn australský systém ASTS a od tohoto okamžiku lze počítat ruskou historii elektronického obchodování. V roce 1998 byla architektura burzy modernizována za účelem zavedení internetového obchodování. Od té doby rychlost zavádění nových řešení a architektonických změn ve všech systémech a subsystémech jen nabírá na síle.

V těchto letech výměnný systém fungoval na špičkovém hardwaru – ultra spolehlivých serverech HP Superdome 9000 (postavených na PA-RISC), ve kterém bylo duplikováno naprosto vše: vstupní/výstupní subsystémy, síť, RAM (ve skutečnosti existovalo pole RAID RAM), procesory (hot-swap). Bylo možné změnit jakoukoli komponentu serveru bez zastavení stroje. Na tato zařízení jsme spoléhali a považovali jsme je prakticky za bezpečná. Operačním systémem byl systém HP UX podobný Unixu.

Zhruba od roku 2010 se ale objevil fenomén, kterému se říká vysokofrekvenční obchodování (HFT), neboli vysokofrekvenční obchodování – zjednodušeně řečeno burzovní roboti. Za pouhé 2,5 roku se zatížení našich serverů zvýšilo 140krát.

Vydržet takovou zátěž se starou architekturou a vybavením nebylo možné. Bylo potřeba se nějak přizpůsobit.

začátek

Požadavky na výměnný systém lze rozdělit do dvou typů:

• Transakce. Pokud chcete koupit dolary, akcie nebo něco jiného, ​​odešlete transakci do obchodního systému a obdržíte odpověď o úspěchu.
• Žádosti o informace. Chcete-li zjistit aktuální cenu, prohlédněte si knihu objednávek nebo indexy a odešlete žádosti o informace.

Schématicky lze jádro systému rozdělit do tří úrovní:

• Klientská úroveň, na které makléři a klienti pracují. Všechny komunikují s přístupovými servery.
• Servery brány jsou servery pro ukládání do mezipaměti, které lokálně zpracovávají všechny požadavky na informace. Chcete vědět, za jakou cenu se aktuálně obchodují akcie Sberbank? Požadavek jde na přístupový server.
• Ale pokud chcete koupit akcie, pak požadavek jde na centrální server (Trade Engine). Pro každý typ trhu existuje jeden takový server, hrají zásadní roli, právě pro ně jsme tento systém vytvořili.

Jádrem obchodního systému je chytrá in-memory databáze, ve které jsou všechny transakce směnnými transakcemi. Báze byla napsána v C, jedinou externí závislostí byla knihovna libc a neexistovala vůbec žádná dynamická alokace paměti. Aby se zkrátila doba zpracování, systém začíná se statickou sadou polí a se statickým přemístěním dat: nejprve se do paměti načtou všechna data pro aktuální den a neprovádí se žádný další přístup na disk, veškerá práce se provádí pouze v paměti. Když se systém spustí, všechna referenční data jsou již setříděna, takže vyhledávání funguje velmi efektivně a zabere jen málo času za běhu. Všechny tabulky jsou vytvořeny s rušivými seznamy a stromy pro dynamické datové struktury, takže nevyžadují alokaci paměti za běhu.

Pojďme si krátce projít historii vývoje našeho obchodního a clearingového systému.
První verze architektury obchodního a clearingového systému byla postavena na takzvané unixové interakci: byla použita sdílená paměť, semafory a fronty a každý proces sestával z jediného vlákna. Tento přístup byl rozšířen na počátku 1990. let.

První verze systému obsahovala dvě úrovně Gateway a centrální server obchodního systému. Pracovní postup byl takový:

• Klient odešle požadavek, který se dostane do brány. Kontroluje platnost formátu (nikoli však samotných dat) a odmítá nesprávné transakce.
• Pokud byla odeslána žádost o informace, je provedena lokálně; pokud mluvíme o transakci, pak je přesměrována na centrální server.
• Obchodní stroj poté transakci zpracuje, upraví místní paměť a odešle odpověď na transakci a samotnou transakci k replikaci pomocí samostatného replikačního jádra.
• Brána obdrží odpověď od centrálního uzlu a předá ji klientovi.
• Po nějaké době brána přijme transakci prostřednictvím replikačního mechanismu a tentokrát ji provede lokálně a změní své datové struktury tak, aby další požadavky na informace zobrazovaly nejnovější data.

Ve skutečnosti popisuje model replikace, ve kterém brána zcela replikovala akce prováděné v obchodním systému. Samostatný replikační kanál zajistil, že transakce byly prováděny ve stejném pořadí napříč více přístupovými uzly.

Vzhledem k tomu, že kód byl jednovláknový, bylo pro obsluhu mnoha klientů použito klasické schéma s procesními vidlemi. Bylo však velmi nákladné forkovat celou databázi, takže byly použity odlehčené servisní procesy, které sbíraly pakety z TCP relací a přenášely je do jedné fronty (SystemV Message Queue). Gateway a Trade Engine pracovaly pouze s touto frontou a odebíraly odtud transakce k provedení. Na ni již nebylo možné odeslat odpověď, protože nebylo jasné, který proces služby ji má číst. Uchýlili jsme se tedy k triku: každý rozvětvený proces si sám pro sebe vytvořil frontu odpovědí, a když do příchozí fronty přišel požadavek, okamžitě se do něj přidal tag pro frontu odpovědí.

Neustálé kopírování velkého množství dat z fronty do fronty způsobilo problémy, zvláště typické pro žádosti o informace. Použili jsme proto další trik: každý proces kromě fronty odpovědí vytvářel také sdílenou paměť (SystemV Shared Memory). Do něj byly umístěny samotné balíčky a do fronty byla uložena pouze značka, která umožňovala najít původní balíček. To pomohlo uložit data do mezipaměti procesoru.

SystemV IPC obsahuje nástroje pro prohlížení stavu fronty, paměti a objektů semaforu. Aktivně jsme toho využili, abychom pochopili, co se v konkrétním okamžiku děje v systému, kde se hromadily pakety, co bylo blokováno atd.

První upgrady

V první řadě jsme se zbavili jednoprocesové brány. Jeho významnou nevýhodou bylo, že dokázal zpracovat buď jednu replikační transakci nebo jeden požadavek na informace od klienta. A jak se zátěž zvyšuje, Gateway bude trvat déle, než zpracuje požadavky, a nebude schopna zpracovat tok replikace. Pokud navíc klient odeslal transakci, pak stačí jen zkontrolovat její platnost a přeposlat dál. Proto jsme jeden proces brány nahradili více komponentami, které mohou běžet paralelně: vícevláknové informační a transakční procesy běžící nezávisle na sobě na sdílené paměťové oblasti pomocí zamykání RW. A zároveň jsme zavedli procesy expedice a replikace.

Vliv vysokofrekvenčního obchodování

Výše uvedená verze architektury existovala až do roku 2010. Mezitím jsme již nebyli spokojeni s výkonem serverů HP Superdome. Navíc architektura PA-RISC byla prakticky mrtvá, výrobce nenabízel žádné výrazné aktualizace. V důsledku toho jsme začali přecházet z HP UX/PA RISC na Linux/x86. Přechod začal adaptací přístupových serverů.

Proč jsme museli znovu měnit architekturu? Faktem je, že vysokofrekvenční obchodování výrazně změnilo profil zatížení jádra systému.

Řekněme, že máme malou transakci, která způsobila významnou změnu ceny – někdo koupil půl miliardy dolarů. Po několika milisekundách si toho všimnou všichni účastníci trhu a začnou provádět korekci. Požadavky se přirozeně řadí do obrovské fronty, kterou systému bude trvat dlouho, než ji vyčistí.

Při tomto intervalu 50 ms je průměrná rychlost asi 16 tisíc transakcí za sekundu. Pokud zkrátíme okno na 20 ms, dostaneme průměrnou rychlost 90 tisíc transakcí za sekundu s 200 tisíci transakcemi na vrcholu. Jinými slovy, zatížení není konstantní, s náhlými výbuchy. A fronta žádostí musí být vždy rychle vyřízena.

Ale proč se tam vůbec fronta tvoří? V našem příkladu si tedy mnoho uživatelů všimlo změny ceny a podle toho odeslalo transakce. Přijdou do brány, ta je serializuje, nastaví určité pořadí a odešle je do sítě. Směrovače zamíchají pakety a přepošlou je dál. Komu balíček dorazil jako první, transakce „vyhrála“. V důsledku toho si klienti burz začali všímat, že pokud byla stejná transakce odeslána z několika bran, šance na její rychlé zpracování se zvýšily. Brzy začali výměnní roboti bombardovat Gateway žádostmi a zvedla se lavina transakcí.

Nové kolo evoluce

Po rozsáhlém testování a výzkumu jsme přešli na jádro operačního systému pracujícího v reálném čase. Pro tento účel jsme zvolili RedHat Enterprise MRG Linux, kde MRG je zkratka pro messaging real-time grid. Výhodou záplat v reálném čase je, že optimalizují systém pro co nejrychlejší provedení: všechny procesy jsou seřazeny ve frontě FIFO, jádra lze izolovat, žádné vyhazování, všechny transakce jsou zpracovávány v přísném pořadí.

Červená - práce s frontou v běžném jádře, zelená - práce v jádře pracujícím v reálném čase.

Ale dosáhnout nízké latence na běžných serverech není tak snadné:

• Velmi ruší režim SMI, který je v architektuře x86 základem pro práci s důležitými periferiemi. Zpracování všemožných hardwarových událostí a správu komponent a zařízení provádí firmware v tzv. transparentním SMI režimu, ve kterém operační systém vůbec nevidí, co firmware dělá. Všichni hlavní dodavatelé zpravidla nabízejí speciální rozšíření pro firmwarové servery, která umožňují snížit množství zpracování SMI.
• Nemělo by docházet k dynamickému řízení frekvence procesoru, což vede k dalším prostojům.
• Při vyprázdnění protokolu systému souborů dochází v jádře k určitým procesům, které způsobují nepředvídatelná zpoždění.
• Musíte věnovat pozornost věcem jako CPU Affinity, Interrupt affinity, NUMA.

Musím říci, že téma nastavení linuxového hardwaru a jádra pro zpracování v reálném čase si zaslouží samostatný článek. Strávili jsme spoustu času experimentováním a zkoumáním, než jsme dosáhli dobrého výsledku.

Při přechodu ze serverů PA-RISC na x86 jsme prakticky nemuseli systémový kód příliš měnit, pouze jsme jej přizpůsobili a překonfigurovali. Zároveň jsme opravili několik chyb. Například důsledky skutečnosti, že PA RISC byl Big endian systém a x86 byl Little endian systém, rychle vypluly na povrch: data se například četla nesprávně. Záludnější chybou bylo, že PA RISC používá důsledně konzistentní (Postupně konzistentní) přístup do paměti, zatímco x86 může změnit pořadí operací čtení, takže kód, který byl absolutně platný na jedné platformě, se na druhé pokazil.

Po přechodu na x86 se výkon zvýšil téměř trojnásobně, průměrná doba zpracování transakce se snížila na 60 μs.

Pojďme se nyní blíže podívat na to, jaké klíčové změny byly provedeny v architektuře systému.

Horký záložní epos

Při přechodu na komoditní servery jsme si byli vědomi, že jsou méně spolehlivé. Proto jsme při tvorbě nové architektury a priori předpokládali možnost selhání jednoho nebo více uzlů. Proto byl potřeba hot standby systém, který by mohl velmi rychle přejít na záložní stroje.

Kromě toho existovaly další požadavky:

• Za žádných okolností byste neměli přijít o zpracované transakce.
• Systém musí být absolutně transparentní pro naši infrastrukturu.
• Klienti by neměli vidět zrušená připojení.
• Rezervace by neměly způsobit výrazné zpoždění, protože to je kritický faktor pro výměnu.

Při vytváření horkého pohotovostního systému jsme takové scénáře nepovažovali za dvojité selhání (například síť na jednom serveru přestala fungovat a hlavní server zamrzl); nezvážili možnost chyb v softwaru, protože jsou identifikovány během testování; a nevzal v úvahu nesprávnou funkci hardwaru.

V důsledku toho jsme došli k následujícímu schématu:

• Hlavní server interagoval přímo se servery brány.
• Všechny transakce přijaté na hlavním serveru byly okamžitě replikovány na záložní server prostřednictvím samostatného kanálu. Arbitr (guvernér) koordinoval výměnu, pokud se vyskytly nějaké problémy.

  

• Hlavní server zpracoval každou transakci a čekal na potvrzení ze záložního serveru. Abychom udrželi latenci na minimu, vyhnuli jsme se čekání na dokončení transakce na záložním serveru. Vzhledem k tomu, že doba potřebná k tomu, aby transakce prošla sítí, byla srovnatelná s dobou provedení, nebyla přidána žádná další latence.
• Mohli jsme pouze zkontrolovat stav zpracování hlavního a záložního serveru pro předchozí transakci a stav zpracování aktuální transakce nebyl znám. Vzhledem k tomu, že jsme stále používali jednovláknové procesy, čekání na odpověď od Backup by zpomalilo celý proces zpracování, a proto jsme udělali rozumný kompromis: zkontrolovali jsme výsledek předchozí transakce.

Schéma fungovalo následovně.

Řekněme, že hlavní server přestane reagovat, ale brány pokračují v komunikaci. Na záložním serveru dojde k vypršení časového limitu, kontaktuje guvernéra, který mu přidělí roli hlavního serveru, a všechny brány se přepnou na nový hlavní server.

Pokud se hlavní server vrátí do režimu online, spustí se také interní časový limit, protože po určitou dobu neproběhla žádná volání na server z brány. Pak se také obrátí na guvernéra a ten ho ze schématu vyloučí. Výsledkem je, že burza funguje s jedním serverem až do konce obchodního období. Vzhledem k tomu, že pravděpodobnost selhání serveru je poměrně nízká, bylo toto schéma považováno za docela přijatelné, neobsahovalo složitou logiku a bylo snadné jej otestovat.

Je třeba pokračovat.

Zdroj: www.habr.com