Москвагийн биржийн арилжаа, клирингийн системийн архитектурын хувьсал. 1-р хэсэг

Сайн уу! Намайг Сергей Костанбаев гэдэг, бирж дээр би арилжааны системийн гол цөмийг боловсруулж байна.

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

Бид дэлхийн бүх төрлийн хөрөнгийн арилжаа хийдэг, биржийн иж бүрэн үйлчилгээ үзүүлдэг цөөхөн биржүүдийн нэг юм. Тухайлбал, өнгөрсөн онд бид бондын арилжаагаар дэлхийд хоёрдугаарт, бүх хөрөнгийн биржээс 25 дугаар байрт, хөрөнгийн биржээс 13 дугаар байрт орсон.

Мэргэжлийн арилжаанд оролцогчдын хувьд хариу өгөх хугацаа, цаг хугацааны хуваарилалтын тогтвортой байдал (життер) болон бүхэл бүтэн цогцолборын найдвартай байдал зэрэг үзүүлэлтүүд чухал юм. Одоогоор бид өдөрт хэдэн арван сая гүйлгээг боловсруулж байна. Гүйлгээ бүрийг системийн цөм боловсруулахад хэдэн арван микросекунд шаардлагатай. Мэдээж шинэ жилийн үдэш үүрэн холбооны операторууд эсвэл хайлтын системүүд өөрсдөө манайхаас илүү ачаалалтай байдаг ч ачааллын хувьд дээр дурдсан шинж чанаруудтай зэрэгцээд бидэнтэй харьцуулах хүн ховор байх шиг байна. Үүний зэрэгцээ систем нэг секундын турш удаашрахгүй, туйлын тогтвортой ажиллаж, бүх хэрэглэгчид тэгш эрхтэй байх нь бидний хувьд чухал юм.

Бага зэрэг түүх

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

Тэр жилүүдэд солилцооны систем нь өндөр чанартай техник хангамж дээр ажилладаг байсан - хэт найдвартай HP Superdome 9000 серверүүд (энэ нь дээр бүтээгдсэн). Pa-risc), бүх зүйл давхардсан: оролт/гаралтын дэд системүүд, сүлжээ, RAM (үнэндээ RAM-ийн RAID массив байсан), процессорууд (халуунаар солигдох боломжтой). Машиныг зогсоохгүйгээр серверийн аль ч бүрэлдэхүүн хэсгийг өөрчлөх боломжтой байсан. Бид эдгээр төхөөрөмжүүдэд найдаж, бараг л эвдрэлээс хамгаалагдсан гэж үзсэн. Үйлдлийн систем нь Unix-тэй төстэй HP UX систем байсан.

Гэвч 2010 оноос хойш өндөр давтамжийн арилжаа (HFT) буюу өндөр давтамжийн арилжаа гэж нэрлэгдэх үзэгдэл бий болсон - энгийнээр хэлбэл хөрөнгийн биржийн роботууд. Ердөө 2,5 жилийн хугацаанд манай серверийн ачаалал 140 дахин нэмэгдсэн.

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

Начало

Биржийн системд өгөх хүсэлтийг хоёр төрөлд хувааж болно.

• Гүйлгээ. Хэрэв та доллар, хувьцаа эсвэл өөр зүйл худалдаж авахыг хүсч байвал арилжааны систем рүү гүйлгээ илгээж, амжилтын тухай хариу хүлээн авна.
• Мэдээллийн хүсэлт. Хэрэв та одоогийн үнийг мэдэхийг хүсвэл захиалгын дэвтэр эсвэл индексийг үзэж, мэдээллийн хүсэлтийг илгээнэ үү.

Схемийн хувьд системийн цөмийг гурван түвшинд хувааж болно.

• Брокер, үйлчлүүлэгчид ажилладаг үйлчлүүлэгчийн түвшин. Тэд бүгд хандалтын серверүүдтэй харилцдаг.
• Gateway серверүүд нь бүх мэдээллийн хүсэлтийг дотооддоо боловсруулдаг серверүүдийг кэш хийдэг. Сбербанкны хувьцаа одоогоор ямар үнээр арилжаалагдаж байгааг мэдэхийг хүсч байна уу? Хүсэлт нь хандалтын сервер рүү очно.
• Гэхдээ хэрэв та хувьцаа худалдаж авахыг хүсч байгаа бол хүсэлт төв серверт (Trade Engine) очно. Зах зээлийн төрөл бүрт нэг ийм сервер байдаг бөгөөд тэдгээр нь маш чухал үүрэг гүйцэтгэдэг, бид энэ системийг тэдэнд зориулж бүтээсэн.

Арилжааны системийн цөм нь бүх гүйлгээ нь солилцооны гүйлгээ болох ухаалаг санах ойн мэдээллийн сан юм. Суурь нь C хэл дээр бичигдсэн, цорын ганц гадаад хамаарал нь libc номын сан байсан бөгөөд динамик санах ойн хуваарилалт огт байгаагүй. Боловсруулах хугацааг багасгахын тулд систем нь статик массивын багц болон статик өгөгдлийг нүүлгэн шилжүүлэх замаар эхэлдэг: нэгдүгээрт, тухайн өдрийн бүх өгөгдлийг санах ойд ачаалж, цаашид диск рүү нэвтрэх боломжгүй, бүх ажлыг зөвхөн санах ойд гүйцэтгэдэг. Систем эхлэхэд бүх лавлагааны өгөгдөл аль хэдийн эрэмблэгдсэн байдаг тул хайлт маш үр дүнтэй ажилладаг бөгөөд ажиллахад бага цаг зарцуулдаг. Бүх хүснэгтүүд нь динамик өгөгдлийн бүтцэд зориулагдсан интрузив жагсаалт, модоор хийгдсэн бөгөөд ингэснээр ажиллах үед санах ойн хуваарилалт шаарддаггүй.

Манай арилжаа, клирингийн системийн хөгжлийн түүхийг товч дурдъя.
Арилжаа, клирингийн системийн архитектурын анхны хувилбар нь Unix-ийн харилцан үйлчлэл дээр бүтээгдсэн: хуваалцсан санах ой, семафор, дарааллыг ашигласан бөгөөд процесс бүр нь нэг урсгалаас бүрддэг. Энэ хандлага 1990-ээд оны эхээр өргөн тархсан.

Системийн эхний хувилбар нь хоёр түвшний гарц, худалдааны системийн төв серверийг агуулсан. Ажлын урсгал дараах байдалтай байв.

• Үйлчлүүлэгч хүсэлт илгээдэг бөгөөд энэ нь гарцад хүрдэг. Энэ нь форматын хүчинтэй эсэхийг (гэхдээ өгөгдөл өөрөө биш) шалгаж, буруу гүйлгээнээс татгалздаг.
• Мэдээллийн хүсэлтийг илгээсэн бол орон нутгийн хэмжээнд гүйцэтгэнэ; Хэрэв бид гүйлгээний тухай ярьж байгаа бол түүнийг төв сервер рүү шилжүүлнэ.
• Дараа нь арилжааны систем нь гүйлгээг боловсруулж, дотоод санах ойг өөрчилж, гүйлгээ болон гүйлгээний хариуг тусдаа хуулбарлах хөдөлгүүр ашиглан хуулбарлахаар илгээдэг.
• Гарц нь төв зангилаанаас хариу хүлээн авч, үйлчлүүлэгч рүү дамжуулдаг.
• Хэсэг хугацааны дараа Gateway нь хуулбарлах механизмаар дамжуулан гүйлгээг хүлээн авдаг бөгөөд энэ удаад өгөгдлийн бүтцийг өөрчилснөөр өгөгдлийн бүтцийг өөрчилдөг бөгөөд ингэснээр дараагийн мэдээллийн хүсэлтүүд хамгийн сүүлийн үеийн өгөгдлийг харуулах болно.

Үнэн хэрэгтээ энэ нь гарц нь арилжааны системд гүйцэтгэсэн үйлдлүүдийг бүрэн хуулбарласан хуулбарлах загварыг тайлбарладаг. Тусдаа хуулбарлах суваг нь гүйлгээг олон хандалтын зангилаагаар ижил дарааллаар гүйцэтгэхийг баталгаажуулсан.

Код нь нэг урсгалтай байсан тул олон үйлчлүүлэгчдэд үйлчлэхийн тулд процессын сэрээ бүхий сонгодог схемийг ашигласан. Гэсэн хэдий ч мэдээллийн санг бүхэлд нь салгахад маш үнэтэй байсан тул TCP сешнүүдээс пакетуудыг цуглуулж, тэдгээрийг нэг дараалалд (SystemV Message Queue) шилжүүлдэг хөнгөн үйлчилгээний процессуудыг ашигласан. 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-д ирдэг, энэ нь тэдгээрийг цуваа болгож, тодорхой дарааллыг тогтоож, сүлжээнд илгээдэг. Чиглүүлэгчид пакетуудыг хольж, дамжуулдаг. Хэний илгээмж түрүүлж ирсэн бол тэр гүйлгээ "хожсон". Үүний үр дүнд биржийн үйлчлүүлэгчид ижил гүйлгээг хэд хэдэн гарцаас илгээсэн бол түүнийг хурдан боловсруулах боломж нэмэгдэж байгааг анзаарч эхлэв. Удалгүй солилцооны роботууд Gateway-ийг хүсэлтээр бөмбөгдөж эхэлсэн бөгөөд гүйлгээний нуранги үүссэн.

Хувьслын шинэ үе шат

Өргөн хүрээтэй туршилт, судалгаа хийсний дараа бид бодит цагийн үйлдлийн системийн цөм рүү шилжсэн. Үүний тулд бид RedHat Enterprise MRG Linux-ийг сонгосон бөгөөд MRG нь мессежийн бодит цагийн сүлжээ гэсэн үг юм. Бодит цагийн засваруудын давуу тал нь системийг аль болох хурдан гүйцэтгэхийн тулд оновчтой болгодог: бүх процессууд нь FIFO дараалалд байрладаг, цөмүүдийг тусгаарлах боломжтой, гадагшлуулахгүй, бүх гүйлгээг нарийн дарааллаар боловсруулдаг.

Улаан - ердийн цөмд дараалалтай ажиллах, ногоон - бодит цагийн цөмд ажиллах.

Гэхдээ ердийн серверүүд дээр бага хоцрогдолд хүрэх нь тийм ч хялбар биш юм:

• X86 архитектурт чухал нэмэлт төхөөрөмжтэй ажиллах үндэс суурь болох SMI горим нь ихээхэн саад учруулдаг. Бүх төрлийн техник хангамжийн үйл явдлуудыг боловсруулах, бүрэлдэхүүн хэсэг, төхөөрөмжүүдийн удирдлагыг үйлдлийн систем нь програм хангамж юу хийж байгааг огт хардаггүй тунгалаг SMI горим гэж нэрлэгддэг програм хангамжаар гүйцэтгэдэг. Дүрмээр бол бүх томоохон үйлдвэрлэгчид програм хангамжийн серверт зориулсан тусгай өргөтгөлүүдийг санал болгодог бөгөөд энэ нь SMI боловсруулалтын хэмжээг багасгах боломжийг олгодог.
• Процессорын давтамжийн динамик хяналт байх ёсгүй, энэ нь нэмэлт сул зогсолтод хүргэдэг.
• Файлын системийн бүртгэлийг цэвэрлэх үед цөмд урьдчилан таамаглах аргагүй саатал үүсгэдэг тодорхой процессууд үүсдэг.
• CPU Affinity, Interrupt affinity, NUMA гэх мэт зүйлсэд анхаарлаа хандуулах хэрэгтэй.

Бодит цагийн боловсруулалтанд зориулж Линукс тоног төхөөрөмж, цөмийг тохируулах сэдэв нь тусдаа нийтлэл байх ёстой гэж би хэлэх ёстой. Бид сайн үр дүнд хүрэхээсээ өмнө туршилт, судалгаанд маш их цаг зарцуулсан.

PA-RISC серверүүдээс x86 руу шилжихдээ бид системийн кодыг бараг өөрчлөх шаардлагагүй, зүгээр л дасан зохицож, дахин тохируулсан. Үүний зэрэгцээ бид хэд хэдэн алдааг зассан. Жишээлбэл, PA RISC нь Big endian систем, x86 нь Little endian систем байсан гэсэн үр дагавар маш хурдан гарч ирэв: жишээлбэл, өгөгдлийг буруу уншсан. Хамгийн төвөгтэй алдаа нь ТХГН-ийн RISC ашигладаг тууштай тууштай (Дараалсан тууштай) санах ойн хандалт, харин x86 нь унших үйлдлийг дахин эрэмбэлж чаддаг тул нэг платформ дээр үнэхээр хүчинтэй байсан код нөгөө платформ дээр эвдэрсэн.

X86 руу шилжсэний дараа гүйцэтгэл бараг гурав дахин нэмэгдэж, гүйлгээний боловсруулалтын дундаж хугацаа 60 μs болж буурсан.

Одоо системийн архитектурт ямар гол өөрчлөлтүүд хийгдсэнийг нарийвчлан авч үзье.

Халуун нөөц баатарлаг

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

Үүнээс гадна бусад шаардлагууд байсан:

• Ямар ч тохиолдолд та боловсруулсан гүйлгээгээ алдах ёсгүй.
• Систем нь манай дэд бүтцэд туйлын ил тод байх ёстой.
• Үйлчлүүлэгчид тасарсан холболтыг харах ёсгүй.
• Захиалга нь ихээхэн саатал гаргах ёсгүй, учир нь энэ нь солилцооны чухал хүчин зүйл юм.

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

Үүний үр дүнд бид дараахь схемд хүрэв.

• Үндсэн сервер нь Gateway серверүүдтэй шууд харилцдаг.
• Үндсэн сервер дээр хүлээн авсан бүх гүйлгээг тусдаа сувгаар нөөц сервер рүү шууд хуулбарласан. Арбитр (Засаг дарга) ямар нэгэн асуудал гарвал шилжүүлэлтийг зохицуулдаг.

  

• Үндсэн сервер нь гүйлгээ бүрийг боловсруулж, нөөц серверээс баталгаажуулахыг хүлээсэн. Хоцролтыг хамгийн бага байлгахын тулд бид нөөц сервер дээр гүйлгээ дуусахыг хүлээхээс зайлсхийсэн. Сүлжээгээр дамжих гүйлгээг гүйцэтгэх хугацаатай харьцуулах боломжтой байсан тул нэмэлт хоцрогдол нэмээгүй.
• Бид зөвхөн өмнөх гүйлгээний үндсэн болон нөөц серверүүдийн боловсруулалтын төлөвийг шалгах боломжтой байсан бөгөөд одоогийн гүйлгээний боловсруулалтын төлөв тодорхойгүй байсан. Бид нэг урсгалтай процессуудыг ашигласаар байгаа тул Нөөцлөлтөөс хариу хүлээх нь боловсруулалтын бүх урсгалыг удаашруулах байсан тул бид боломжийн буулт хийсэн: өмнөх гүйлгээний үр дүнг шалгасан.

Схем нь дараах байдлаар ажиллав.

Үндсэн сервер хариу өгөхөө больсон гэж бодъё, гэхдээ гарцууд үргэлжлүүлэн харилцаж байна. Нөөц сервер дээр завсарлага гарч, Захирагчтай холбогдож, түүнд үндсэн серверийн үүргийг оноож, бүх гарцууд шинэ үндсэн сервер рүү шилжинэ.

Хэрэв үндсэн сервер дахин онлайн болвол энэ нь мөн дотоод завсарлага үүсгэдэг, учир нь тодорхой хугацаанд Gateway-аас сервер рүү дуудлага ирээгүй. Дараа нь тэр мөн Засаг даргад хандаж, түүнийг схемээс хасав. Үүний үр дүнд бирж нь арилжааны хугацаа дуустал нэг сервертэй ажилладаг. Серверийн эвдрэлийн магадлал маш бага тул энэ схемийг нэлээд хүлээн зөвшөөрч болохуйц гэж үзсэн бөгөөд энэ нь нарийн төвөгтэй логик агуулаагүй бөгөөд шалгахад хялбар байв.

Үргэлжлүүлэх.

Эх сурвалж: www.habr.com