MegaFon шиг корпораци яагаад тооцоонд Tarantool хэрэгтэй байна вэ? Гаднаас нь харахад худалдагч ихэвчлэн ирдэг, ямар нэгэн том хайрцаг авчирч, залгуурыг залгуурт залгадаг - энэ бол тооцоо юм! Нэгэн цагт ийм байсан, гэхдээ одоо энэ нь эртний бөгөөд ийм үлэг гүрвэлүүд аль хэдийн устаж үгүй болсон эсвэл устаж үгүй болж байна. Эхлээд тооцоо хийх нь нэхэмжлэх гаргах систем юм - тоолох машин эсвэл тооцоолуур. Орчин үеийн харилцаа холбоонд ийм байна гэрээ байгуулахаас эхлээд дуусгавар болох хүртэлх захиалагчтай харилцах бүх амьдралын мөчлөгийн автоматжуулалтын системБодит цагийн тооцоо, төлбөр хүлээн авах гэх мэт. Харилцаа холбооны компаниудад төлбөр тооцоо хийх нь том, хүчирхэг, зэвсгээр дүүрэн байлдааны роботтой адил юм.
Tarantool үүнд ямар хамаатай вэ? Тэд энэ тухай ярих болно Олег Ивлев и Андрей Князев. Олег бол компанийн ерөнхий архитектор юм Гадаадын компаниудад ажиллаж байсан арвин туршлагатай Андрей бизнесийн системийн захирал юм. Тэдний илтгэлийн бичлэгээс Та яагаад R&D нь корпорацуудад хэрэгтэй байдаг, Tarantool гэж юу вэ, босоо цар хүрээ, даяаршлын мухардмал байдал нь компанид энэ мэдээллийн санг бий болгох урьдчилсан нөхцөл болсон, технологийн сорилт, архитектурын өөрчлөлт, MegaFon-ийн техностак нь Netflix-тэй хэрхэн төстэй болохыг олж мэдэх болно. , Google болон Amazon.
Төсөл "Нэгдсэн тооцоо"
Энэ төсөл нь "Нэгдсэн тооцоо" гэж нэрлэгддэг. Энд л Tarantool хамгийн сайн чанараа харуулсан.
Hi-End төхөөрөмжийн бүтээмжийн өсөлт нь захиалагчдын баазын өсөлт, үйлчилгээний тооны өсөлтийг гүйцэхгүй байсан бөгөөд M2M, IoT, салбаруудын онцлогоос шалтгаалан захиалагч, үйлчилгээний тоо цаашид өсөх төлөвтэй байсан. зах зээлд гарах хугацаа муудах. Тус компани нь одоогийн 8 өөр тооцооны системийн оронд дэлхийн жишигт нийцсэн өвөрмөц модульчлагдсан архитектур бүхий нэгдсэн бизнесийн системийг бий болгохоор шийдсэн.
MegaFon бол нэг компанид найман компани юм. 2009 онд өөрчлөн байгуулалт дууссан: Орос даяар салбарууд нэг компани болох МегаФон ХК (одоо PJSC) болж нэгдсэн. Ийнхүү тус компани өөрийн гэсэн “захиалгат” шийдэл, салбарын онцлог, өөр өөр зохион байгуулалтын бүтэц, IT, маркетинг бүхий 8 тооцооны системтэй.
Холбооны нийтлэг бүтээгдэхүүн гаргах хүртэл бүх зүйл сайхан байсан. Энд маш олон бэрхшээл гарч ирэв: зарим хүмүүсийн хувьд тарифыг дугуйрсан, зарим нь дугуйрсан, бусад хүмүүсийн хувьд арифметик дундаж дээр үндэслэн тооцдог. Ийм олон мянган мөч байдаг.
Тооцооны системийн цорын ганц хувилбар, нэг ханган нийлүүлэгч байсан ч тохиргоонууд нь маш их ялгаатай байсан тул нэгтгэхэд удаан хугацаа зарцуулсан. Бид тэдний тоог цөөлөхийг оролдсон бөгөөд олон корпорациудад танил болсон хоёр дахь асуудалтай тулгарсан.
Босоо масштаб. Тэр үеийн хамгийн дажгүй техник хэрэгсэл ч гэсэн хэрэгцээг хангаж чадахгүй байв. Бид Superdome Hi-End шугамын Hewlett-Packard төхөөрөмжийг ашигласан боловч хоёр салбарынхаа хэрэгцээг хангаж чадаагүй. Би их хэмжээний үйл ажиллагааны зардал, хөрөнгө оруулалтгүйгээр хэвтээ масштабтай байхыг хүсч байсан.
Захиалагч, үйлчилгээний тоо өснө гэсэн хүлээлт. Зөвлөхүүд IoT ба M2M-ийн тухай түүхийг харилцаа холбооны ертөнцөд удаан хугацаагаар авчирсаар ирсэн: утас, индүү бүр SIM карттай, хоёр хөргөгчинд байх цаг ирнэ. Өнөөдөр бид нэг тооны захиалагчтай байгаа ч ойрын ирээдүйд илүү олон байх болно.
Технологийн сорилтууд
Эдгээр дөрвөн шалтгаан нь биднийг ноцтой өөрчлөлт хийхэд түлхэц өгсөн. Системийг шинэчлэх, эхнээс нь дизайн хийх хоёрын хооронд сонголт байсан. Бид удаан бодож, нухацтай шийдвэр гаргаж, тендер тоглосон. Үүний үр дүнд бид анхнаасаа дизайн хийхээр шийдсэн бөгөөд сонирхолтой сорилтууд болох технологийн сорилтуудыг даван туулсан.
Өргөтгөх чадвар
Хэрэв өмнө нь байсан бол хэлье, хэлье 8 сая захиалагчийн 15 тооцоо, одоо энэ нь ажиллах ёстой байсан 100 сая захиалагч ба түүнээс дээш - ачаалал нь түүнээс дээш хэмжээтэй байна.
Бид Mail.ru эсвэл Netflix зэрэг томоохон интернет тоглуулагчтай харьцуулах боломжтой болсон.
Гэхдээ ачаалал, захиалагчийн баазыг нэмэгдүүлэх цаашдын хөдөлгөөн нь бидний өмнө ноцтой сорилтуудыг тавьж байна.
Манай өргөн уудам орны газарзүй
Калининград, Владивосток хоёрын хооронд 7500 км, 10 цагийн бүс. Гэрлийн хурд нь хязгаарлагдмал бөгөөд ийм зайд саатал аль хэдийн мэдэгдэхүйц байна. Орчин үеийн хамгийн гайхалтай оптик сувгууд дээр 150 мс нь бодит цагийн тооцоо хийхэд хэтэрхий их байдаг, ялангуяа одоо Орост харилцаа холбоонд байдаг. Нэмж дурдахад, та ажлын нэг өдөрт шинэчлэх шаардлагатай бөгөөд өөр өөр цагийн бүстэй бол энэ нь асуудал юм.
Бид зөвхөн захиалгын төлбөрөөр үйлчилгээ үзүүлдэггүй, бидэнд нарийн төвөгтэй тариф, багц, төрөл бүрийн тохируулагч байдаг. Бид захиалагчийг ярихыг зөвшөөрөх эсвэл татгалзахаас гадна түүнд тодорхой квот өгөх хэрэгтэй - дуудлага, үйлдлийг бодит цаг хугацаанд нь тооцоолж, тэр анзаарахгүй байх ёстой.
алдааг тэсвэрлэх чадвар
Энэ бол төвлөрлийн нөгөө тал юм.
Хэрэв бид бүх захиалагчдыг нэг системд цуглуулдаг бол аливаа онцгой байдлын үйл явдал, гамшиг нь бизнесийн хувьд сүйрэлд хүргэдэг. Тиймээс бид системийг бүхэлд нь захиалагчийн үндсэн дээр ослын нөлөөллийг арилгахаар төлөвлөж байна.
Энэ нь дахин босоо байдлаар масштаблахаас татгалзсаны үр дагавар юм. Бид хэвтээ байдлаар томрохдоо хэдэн зуугаас хэдэн мянга хүртэл серверийн тоог нэмэгдүүлсэн. Тэдгээрийг удирдаж, сольж болох, мэдээллийн технологийн дэд бүтцийг автоматаар нөөцлөх, түгээсэн системийг сэргээх шаардлагатай.
Бид ийм сонирхолтой сорилтуудтай тулгарсан. Бид системийг зохион бүтээсэн бөгөөд тэр үед бид дэлхийн шилдэг туршлагыг хайж олохыг хичээж, бид хэр чиг хандлагад байгаа, дэвшилтэт технологийг хэр дагаж мөрдөж байгааг шалгахыг хичээсэн.
Дэлхийн туршлага
Гайхалтай нь бид дэлхийн харилцаа холбоонд нэг ч лавлагаа олоогүй.
Европ захиалагчдын тоо, цар хүрээгээрээ, АНУ тарифынхаа тэгш байдлын хувьд унасан. Бид Хятадад заримыг нь судалж, Энэтхэгээс заримыг нь олж, Энэтхэгийн Vodafone компаниас мэргэжилтнүүдийг хөлсөлсөн.
Архитектурт дүн шинжилгээ хийхийн тулд бид IBM-ээр ахлуулсан Мөрөөдлийн багийг цуглуулсан - янз бүрийн салбарын архитекторууд. Эдгээр хүмүүс бидний хийж байгаа зүйлийг хангалттай үнэлж, манай архитектурт тодорхой мэдлэгийг авчирч чадна.
Хэмжээ
Дүрслэх хэдэн тоо.
Бид системийг зохион бүтээдэг Нэг тэрбумын нөөцтэй 80 сая захиалагч. Ингэж бид ирээдүйн босгыг арилгадаг. Энэ нь бид Хятадыг эзлэх гэж байгаадаа биш, харин IoT болон M2M-ийн дайралтаас болж байгаа юм.
Бодит цаг хугацаанд 300 сая баримт бичиг боловсруулагдсан. Хэдийгээр бид 80 сая захиалагчтай ч авлага цуглуулах шаардлагатай бол боломжит үйлчлүүлэгчид болон биднийг орхисон хүмүүстэй хамтран ажилладаг. Тиймээс бодит хэмжээ нь мэдэгдэхүйц том байна.
2 тэрбум гүйлгээ Үлдэгдэл өдөр бүр өөрчлөгддөг - эдгээр нь төлбөр, төлбөр, дуудлага болон бусад үйл явдлууд юм. 200 TB өгөгдөл идэвхтэй өөрчлөгдөж байна, бага зэрэг удаан өөрчлөх 8 PB өгөгдөл, мөн энэ нь архив биш, харин нэг тооцооны шууд өгөгдөл юм. Дата төвөөр масштаблах - 5 сайт дээр 14 мянган сервер.
Технологийн стек
Архитектурыг төлөвлөж, системийг угсарч эхлэхдээ хамгийн сонирхолтой, дэвшилтэт технологиудыг оруулж ирсэн. Үр дүн нь ямар ч интернет тоглуулагч болон өндөр ачаалалтай систем үйлдвэрлэдэг корпорациудад танил болсон технологийн стек юм.
Стек нь бусад томоохон тоглогчдын стектэй төстэй: Netflix, Twitter, Viber. Энэ нь 6 бүрэлдэхүүн хэсгээс бүрдэх боловч бид үүнийг богиносгож, нэгтгэхийг хүсч байна.
Уян хатан байдал сайн, гэхдээ томоохон корпорацид нэгдэхгүй байх арга байхгүй.
Бид ижил Oracle-г Tarantool болгон өөрчлөхгүй. Томоохон компаниудын бодит байдал дээр энэ бол утопи буюу 5-10 жилийн загалмайтны аян дайн, үр дүн нь тодорхойгүй байна. Гэхдээ Кассандра, Коучбаз хоёрыг Tarantool-оор хялбархан сольж болох бөгөөд бид үүний төлөө хичээж байна.
Яагаад Tarantool гэж?
Бид яагаад энэ мэдээллийн санг сонгох болсон талаар 4 энгийн шалгуур байдаг.
Хурд. Бид MegaFon үйлдвэрлэлийн системд ачааллын туршилт хийсэн. Tarantool ялсан - энэ нь хамгийн сайн гүйцэтгэлийг харуулсан.
Энэ нь бусад системүүд нь MegaFon-ийн хэрэгцээг хангахгүй гэсэн үг биш юм. Одоогийн санах ойн шийдлүүд нь маш бүтээмжтэй тул компанийн нөөц хангалттай хэмжээнд байна. Гэхдээ бид ачааллын шалгалтыг оролцуулаад хоцрогдсон хүнтэй биш, удирдагчтай харьцах сонирхолтой байна.
Tarantool нь урт хугацаанд ч гэсэн компанийн хэрэгцээг хангадаг.
TCO зардал. MegaFon-ийн эзлэхүүн дээр Couchbase-ийг дэмжих нь одон орны хэмжээний мөнгө шаарддаг боловч Tarantool-ийн хувьд нөхцөл байдал илүү тааламжтай бөгөөд тэдгээр нь үйл ажиллагааны хувьд ижил төстэй байдаг.
Бидний сонголтод бага зэрэг нөлөөлсөн бас нэг сайхан онцлог нь Tarantool нь бусад мэдээллийн сангаас илүү санах ойтой ажилладаг. Тэр харуулж байна хамгийн их үр ашиг.
Найдвартай байдал. MegaFon найдвартай байдалд хөрөнгө оруулалт хийдэг, магадгүй бусад хүмүүсээс илүү. Тиймээс бид Тарантоолыг хараад шаардлагад нийцүүлэх ёстой гэдгийг ойлгосон.
Бид цаг хугацаа, санхүүгээ зориулж, Mail.ru-тай хамтран энтерпрайз хувилбарыг бүтээсэн бөгөөд одоо өөр хэд хэдэн компанид ашиглагдаж байна.
Tarantool-enterprise нь аюулгүй байдал, найдвартай байдал, мод бэлтгэлийн хувьд биднийг бүрэн хангасан.
Түншлэл
Миний хувьд хамгийн чухал зүйл хөгжүүлэгчтэй шууд харилцах. Тарантоолын залуус яг ингэж авлига өгсөн.
Хэрэв та тоглогч, ялангуяа зангуу үйлчлүүлэгчтэй ажилладаг тоглогч дээр ирээд, танд үүнийг хийх боломжтой мэдээллийн сан хэрэгтэй гэж хэлбэл, тэр ихэвчлэн хариулдаг:
- За, тэр овоолгын ёроолд тавигдах шаардлагуудыг тавь - хэзээ нэгэн цагт бид тэдэнд хүрэх байх.
Олон хүмүүс ойрын 2-3 жилийн замын зурагтай байдаг бөгөөд тэнд нэгтгэх нь бараг боломжгүй боловч Tarantool хөгжүүлэгчид зөвхөн MegaFon-оос бус нээлттэй байдгаараа гайхшруулж, системээ хэрэглэгчдэд тохируулдаг. Энэ нь дажгүй бөгөөд бидэнд үнэхээр таалагдаж байна.
Бид Tarantool ашигласан газар
Бид Tarantool-ийг хэд хэдэн элементэд ашигладаг. Эхнийх нь нисгэгч юм, бид хаягийн лавлах систем дээр хийсэн. Нэгэн цагт би үүнийг Yandex.Maps болон Google Maps-тэй төстэй систем болгохыг хүсч байсан ч арай өөр болсон.
Жишээлбэл, борлуулалтын интерфейс дэх хаягийн каталог. Oracle дээр хүссэн хаягаа хайхад 12-13 секунд зарцуулагдана. - эвгүй тоо. Бид Tarantool руу шилжиж, консол дээрх өөр мэдээллийн баазаар Oracle-г сольж, ижил хайлт хийх үед бид 200 дахин хурдтай болно! Гурав дахь үсгийн дараа хот гарч ирнэ. Одоо бид интерфэйсийг тохируулж байна, ингэснээр эхнийх нь дараа ийм зүйл тохиолдох болно. Гэсэн хэдий ч хариу өгөх хурд нь огт өөр юм - секундын оронд миллисекунд.
Хоёрдахь програм нь хоёр шатлалт IT гэж нэрлэгддэг загварлаг сэдэв юм. Учир нь корпорацууд тийшээ явах ёстой гэж өнцөг булан бүрээс зөвлөхүүд хэлдэг.
Дэд бүтцийн давхарга байдаг, дээр нь домэйнууд байдаг, жишээлбэл, харилцаа холбоо, корпорацийн систем, корпорацийн тайлан гэх мэт тооцооны систем. Энэ бол хүрэх шаардлагагүй гол цөм юм. Энэ нь мэдээжийн хэрэг боломжтой, гэхдээ энэ нь корпорацид мөнгө авчирдаг тул чанарыг гажуудуулж байна.
Дараа нь микро үйлчилгээний давхарга ирдэг - оператор эсвэл бусад тоглогчийг юугаараа ялгадаг. Бичил үйлчилгээг тодорхой кэш дээр үндэслэн хурдан үүсгэж, өөр өөр домэйнуудаас өгөгдлийг авчрах боломжтой. Энд туршилт хийх талбар - Хэрэв ямар нэг зүйл болохгүй бол би нэг микро үйлчилгээг хааж, нөгөөг нээсэн. Энэ нь зах зээлд гарах хугацааг үнэхээр нэмэгдүүлж, компанийн найдвартай байдал, хурдыг нэмэгдүүлдэг.
Бичил үйлчилгээ нь MegaFon дахь Tarantool-ийн гол үүрэг байж магадгүй юм.
Бид Tarantool ашиглахаар төлөвлөж буй газар
Хэрэв бид амжилттай тооцооны төслийг Deutsche Telekom, Svyazcom, Vodafone India зэрэг компаниудын өөрчлөлтийн хөтөлбөрүүдтэй харьцуулж үзвэл энэ нь гайхалтай динамик, бүтээлч юм. Энэхүү төслийг хэрэгжүүлэх явцад зөвхөн MegaFon болон түүний бүтэц өөрчлөгдсөн төдийгүй Mail.ru дээр Tarantool аж ахуйн нэгж гарч ирсэн бөгөөд манай борлуулагч Nexign (хуучин Петр-Сервис) - BSS Box (хайрцагтай тооцооны шийдэл) гарч ирэв.
Энэ нь нэг ёсондоо Оросын зах зээлийн хувьд түүхэн төсөл юм. Үүнийг Фредерик Бруксын "Домгийн хүн-сар" номонд бичсэнтэй харьцуулж болно. Дараа нь 60-аад онд IBM 360 хүнийг хөлсөлж, үндсэн фрэймийн шинэ OS/5 үйлдлийн системийг хөгжүүлжээ. Бидэнд 000-гаас бага, харин манайх хантаазтай, нээлттэй эхийн хэрэглээ, шинэ хандлагыг харгалзан бид илүү үр бүтээлтэй ажилладаг.
Тооцооны эсвэл илүү өргөнөөр хэлбэл бизнесийн системийн домайнуудыг доор харуулав. Байгууллагын хүмүүс CRM-ийг маш сайн мэддэг. Хүн бүр өөр системтэй байх ёстой: Open API, API Gateway.
Нээлттэй API
Тоонууд болон Open API одоогоор хэрхэн ажилладаг талаар дахин харцгаая. Түүний ачаалал Секундэд 10 гүйлгээ. Бид микро үйлчилгээний давхаргыг идэвхтэй хөгжүүлж, MegaFon нийтийн API-г бүтээхээр төлөвлөж байгаа тул энэ хэсэгт ирээдүйд илүү их өсөлт гарна гэж найдаж байна. 100 мянган гүйлгээ хийх нь гарцаагүй.
SSO дахь Mail.ru-тай харьцуулж чадах эсэхийг би мэдэхгүй байна - залуус секундэд 1 гүйлгээ хийдэг бололтой. Тэдний шийдэл нь бидний хувьд маш сонирхолтой бөгөөд бид тэдний туршлагыг ашиглахаар төлөвлөж байна - жишээлбэл, Tarantool ашиглан SSO-ийн функциональ нөөцлөлт хийх. Одоо Mail.ru-ийн хөгжүүлэгчид бидний төлөө үүнийг хийж байна.
CRM
CRM бол 80 сая захиалагчтай ижилхэн бөгөөд бид тэрбумд хүргэхийг хүсч байна, учир нь гурван жилийн түүхийг багтаасан 300 сая баримт бичиг байдаг. Бид энд шинэ үйлчилгээг үнэхээр тэсэн ядан хүлээж байна өсөлтийн цэг нь холбогдсон үйлчилгээ юм. Энэ бол өсөх бөмбөг, учир нь илүү олон үйлчилгээ байх болно. Үүний дагуу бидэнд түүх хэрэгтэй болно, бид үүнд бүдрэхийг хүсэхгүй байна.
Нэхэмжлэх гаргах тал дээр өөрөө тооцоо хийх, харилцагчийн авлагатай ажиллах тусдаа домэйн болгон хувиргасан. Гүйцэтгэлийг сайжруулахын тулд, хэрэглээний домэйн архитектурын архитектурын загвар.
Систем нь домайнуудад хуваагдаж, ачааллыг хуваарилж, алдааны хүлцэл хангагдсан. Нэмж дурдахад бид хуваарилагдсан архитектуртай ажилласан.
Бусад бүх зүйл нь аж ахуйн нэгжийн түвшний шийдэл юм. Дуудлагын санд - Өдөрт 2 тэрбум, сард 60 тэрбум. Заримдаа та тэдгээрийг нэг сарын дотор тоолох хэрэгтэй бөгөөд энэ нь илүү хурдан болно. Санхүүгийн хяналт - энэ нь яг л байнга өсч, өсөн нэмэгдэж буй 300 сая юм: захиалагчид ихэвчлэн операторуудын хооронд гүйж, энэ хэсгийг нэмэгдүүлдэг.
Мобайл холбооны хамгийн харилцаа холбооны бүрэлдэхүүн хэсэг онлайн тооцоо. Эдгээр нь танд дуудлага хийх, залгахгүй байх, бодит цаг хугацаанд шийдвэр гаргах боломжийг олгодог системүүд юм. Энд ачаалал нь секундэд 30 гүйлгээ юм, гэхдээ өгөгдөл дамжуулах өсөлтийг харгалзан бид төлөвлөж байна 250 гүйлгээ, тиймээс бид Tarantool-ийг маш их сонирхож байна.
Өмнөх зураг нь бидний Tarantool ашиглах гэж байгаа домэйнууд юм. CRM нь мэдээжийн хэрэг илүү өргөн хүрээтэй бөгөөд бид үүнийг үндсэндээ ашиглах болно.
Бидний тооцоолсон TTX 100 сая захиалагч намайг архитекторын хувьд андуурч байна - 101 сая бол яах вэ? Та бүх зүйлийг дахин хийх шаардлагатай байна уу? Үүнээс урьдчилан сэргийлэхийн тулд бид кэшийг ашигладаг бөгөөд үүний зэрэгцээ хүртээмжийг нэмэгдүүлдэг.
Ерөнхийдөө Tarantool ашиглах хоёр арга байдаг. Эхлээд - микро үйлчилгээний түвшинд бүх кэшийг бүтээх. Миний ойлгож байгаагаар VimpelCom ийм замаар явж, үйлчлүүлэгчдийн кэшийг бий болгож байна.
Бид борлуулагчдаас бага хамааралтай, BSS цөмийг өөрчилж байгаа тул хайрцагнаас гарсан ганц үйлчлүүлэгч файлтай болсон. Гэхдээ бид үүнийг өргөжүүлэхийг хүсч байна. Тиймээс бид арай өөр хандлагыг авч байна - систем дотор кэш хийх.
Ингэснээр синхрончлол багатай байдаг - нэг систем нь кэш болон үндсэн үндсэн эх сурвалжийг хоёуланг нь хариуцдаг.
Энэ арга нь зөвхөн шинэчлэлттэй холбоотой хэсгүүд, өөрөөр хэлбэл өгөгдлийн өөрчлөлтүүд шинэчлэгдэх үед гүйлгээний араг яс бүхий Tarantool арга барилтай сайн тохирдог. Бусад бүх зүйлийг өөр газар хадгалах боломжтой. Асар том мэдээллийн нуур, удирдагдаагүй дэлхийн кэш байхгүй. Кэшүүд нь систем, бүтээгдэхүүн, үйлчлүүлэгчдэд зориулагдсан эсвэл засвар үйлчилгээ хийхэд хялбар болгох зорилготой юм. Захиалагч дуудаж, үйлчилгээнийхээ чанарт сэтгэл дундуур байх үед та чанартай үйлчилгээ үзүүлэхийг хүсдэг.
RTO ба RPO
МТ-д хоёр нэр томъёо байдаг - RTO и RPO.
Сэргээх хугацааны зорилго алдаа гарсаны дараа үйлчилгээг сэргээхэд шаардагдах хугацаа юм. RTO = 0 гэдэг нь ямар нэг зүйл бүтэлгүйтсэн ч үйлчилгээ үргэлжлүүлэн ажиллана гэсэн үг.
Сэргээх цэгийн зорилго - энэ бол өгөгдөл сэргээх хугацаа, тодорхой хугацаанд бид хичнээн их мэдээлэл алдаж болох юм. RPO = 0 нь бид өгөгдлийг алдахгүй гэсэн үг юм.
Тарантуулын даалгавар
Tarantool-ийн асуудлыг шийдэхийг хичээцгээе.
Өгсөн: хүн бүрийн ойлгодог програмуудын сагс, жишээлбэл, Amazon эсвэл өөр газар. Шаардлагатай Ингэснээр дэлгүүрийн тэрэг долоо хоногт 24 өдөр 7 цаг буюу 99,99% ажилладаг. Бидэнд ирж буй захиалга эмх цэгцтэй байх ёстой, учир нь бид захиалагчийн холболтыг санамсаргүй байдлаар асааж, унтрааж чадахгүй - бүх зүйл хатуу нийцтэй байх ёстой. Өмнөх захиалга нь дараагийн захиалгад нөлөөлдөг тул өгөгдөл чухал - юу ч алга болохгүй.
шийдвэр. Та үүнийг шууд шийдэхийг оролдож, мэдээллийн баазын хөгжүүлэгчдээс асууж болно, гэхдээ асуудлыг математикийн аргаар шийдэж чадахгүй. Та теорем, хадгалалтын хууль, квант физикийг санаж чадна, гэхдээ яагаад үүнийг DB түвшинд шийдэж чадахгүй байна.
Хуучин архитектурын сайн арга нь энд ажилладаг - та сэдвийн талбарыг сайн мэдэж, энэ тааврыг шийдэхийн тулд үүнийг ашиглах хэрэгтэй.
Бидний шийдэл: Газарзүйн тархсан кластер болох Tarantool дээр програмуудын тархсан бүртгэлийг бий болгох. Диаграммд эдгээр нь гурван өөр өгөгдөл боловсруулах төв юм - хоёр нь Уралын өмнө, нэг нь Уралын цаана байдаг бөгөөд бид эдгээр төвүүдийн дунд бүх хүсэлтийг хуваарилдаг.
Өдгөө мэдээллийн технологийн салбарт тэргүүлэгчдийн нэг гэгддэг Netflix 2012 он хүртэл ганцхан дата төвтэй байсан. Католик Христийн Мэндэлсний Баярын өмнөх өдөр буюу 24-р сарын XNUMX-нд энэ дата төв унтарсан. Канад, АНУ-ын хэрэглэгчид дуртай киногоороо үлдэж, маш их бухимдаж, олон нийтийн сүлжээнд энэ талаар бичжээ. Netflix одоо баруун зүүн эрэгт гурван дата төв, баруун Европт нэг дата төвтэй.
Бид эхлээд гео-тархлагдсан шийдлийг барьж байна - алдааг тэсвэрлэх чадвар нь бидний хувьд чухал юм.
Тэгэхээр бидэнд кластер байна, гэхдээ RPO = 0, RTO = 0-ийн талаар юу хэлэх вэ? Сэдвээс хамааран шийдэл нь энгийн.
Хэрэглээнд юу чухал вэ? Хоёр хэсэг: Сагс шидэлт TO худалдан авах шийдвэр гаргах, мөн ОДОО. Харилцаа холбооны DO хэсгийг ихэвчлэн нэрлэдэг барих захиалга буюу захиалгын хэлэлцээр. Харилцаа холбооны хувьд энэ нь онлайн дэлгүүрээс хамаагүй хэцүү байж болох юм, учир нь тэнд үйлчлүүлэгчид үйлчлэх ёстой, 5 сонголтыг санал болгодог бөгөөд энэ бүхэн хэсэг хугацаанд тохиолддог боловч сагс дүүрсэн байдаг. Энэ мөчид бүтэлгүйтэх боломжтой, гэхдээ энэ нь хүний хяналтан дор интерактив байдлаар тохиолддог тул энэ нь аймшигтай биш юм.
Хэрэв Москвагийн дата төв гэнэт бүтэлгүйтвэл автоматаар өөр дата төв рүү шилжсэнээр бид үргэлжлүүлэн ажиллах болно. Онолын хувьд нэг бүтээгдэхүүн тэргэнцэрт алга болж магадгүй, гэхдээ та үүнийг хараад дахин сагсанд нэмээд үргэлжлүүлэн ажиллана. Энэ тохиолдолд RTO = 0.
Үүний зэрэгцээ хоёрдахь сонголт байна: "Илгээх" дээр дарахад бид өгөгдлийг алдахгүй байхыг хүсч байна. Энэ мөчөөс эхлэн автоматжуулалт ажиллаж эхэлдэг - энэ бол RPO = 0. Эдгээр хоёр өөр хэв маягийг ашигласнаар нэг тохиолдолд энэ нь зүгээр л нэг солих боломжтой мастер бүхий гео тархсан кластер, өөр тохиолдолд чуулгын зарим төрлийн бичлэг байж болно. Загвар нь өөр өөр байж болох ч бид асуудлыг шийддэг.
Цаашилбал, програмуудын тархсан бүртгэлтэй бол бид үүнийг бүгдийг нь өргөжүүлж чадна - энэ бүртгэлд ханддаг олон диспетчер, гүйцэтгэгчтэй болно.
Кассандра, Тарантол хоёр хамтдаа
Өөр нэг тохиолдол бий - "үлдэгдлийг харуулах". Кассандра, Тарантоол хоёрын хамтарсан хэрэглээний нэгэн сонирхолтой тохиолдол энд байна.
Өдөрт 2 тэрбум дуудлага хийх нь хязгаар биш бөгөөд үүнээс ч их байх болно, учир нь бид Кассандра ашигладаг. Маркетерууд урсгалыг эх сурвалжаар нь өнгөөр ялгах дуртай байдаг; жишээлбэл, нийгмийн сүлжээнд илүү дэлгэрэнгүй мэдээлэл гарч байна. Энэ бүхэн түүхийг нэмдэг.
Кассандра нь ямар ч хэмжээтэй хэвтээ байдлаар масштаблах боломжийг олгодог.
Бид Кассандратай эвтэйхэн санагддаг, гэхдээ энэ нь нэг асуудалтай байдаг - энэ нь уншихад тийм ч сайн биш юм. Бичлэг дээр бүх зүйл хэвийн, секундэд 30 бол асуудал биш - унших асуудал.
Тиймээс кэштэй сэдэв гарч ирсэн бөгөөд үүнтэй зэрэгцэн бид дараахь асуудлыг шийдсэн: онлайн тооцооны шилжүүлэгчээс төхөөрөмж Кассандра руу ачаалах файлд орж ирдэг хуучин уламжлалт тохиолдол байдаг. Бид IBM менежерийн файл дамжуулах зөвлөгөөг ашиглан эдгээр файлуудыг найдвартай татаж авах асуудалтай тулгарсан - TCP гэхээсээ илүү UDP протоколыг ашиглан файл дамжуулалтыг үр дүнтэй удирдах шийдлүүд байдаг. Энэ сайн байна, гэхдээ хэдхэн минут байна, бид бүгдийг нь ачаалж амжаагүй байгаа тул дуудлагын төвийн оператор үйлчлүүлэгчийн үлдэгдэлд юу тохиолдсон талаар хариулж чадахгүй байна - бид хүлээх хэрэгтэй.
Үүнээс урьдчилан сэргийлэхийн тулд бид Бид зэрэгцээ функциональ нөөцийг ашигладаг. Бид Кафкагаар дамжуулан Тарантоол руу үйл явдлыг илгээж, агрегатуудыг бодит цаг хугацаанд дахин тооцоолоход, жишээ нь өнөөдрийн хувьд бэлэн мөнгөний үлдэгдэл, ямар ч хурдаар үлдэгдлийг шилжүүлэх боломжтой, жишээлбэл, секундэд 100 мянган гүйлгээ, ижил 2 секунд.
Зорилго нь дуудлага хийсний дараа 2 секундын дотор таны хувийн дансанд зөвхөн өөрчлөгдсөн үлдэгдэл төдийгүй яагаад өөрчлөгдсөн тухай мэдээлэл байх болно.
дүгнэлт
Эдгээр нь Tarantool ашиглах жишээнүүд байв. Mail.ru-ийн нээлттэй байдал, янз бүрийн хэргийг авч үзэх хүсэл бидэнд үнэхээр таалагдсан.
BCG эсвэл McKinsey, Accenture эсвэл IBM-ийн зөвлөхүүдэд шинэ зүйлээр биднийг гайхшруулах нь аль хэдийн хэцүү байдаг - тэдний санал болгож буй зүйлийн ихэнх нь бид аль хэдийн хийсэн, хийсэн эсвэл хийхээр төлөвлөж байна. Tarantool нь манай технологийн стек дэх зохих байр сууриа эзэлж, одоо байгаа олон технологийг орлох болно гэж би бодож байна. Бид энэ төслийн хөгжлийн идэвхтэй үе шатанд байна.
Олег, Андрей нарын илтгэл нь өнгөрсөн жилийн Тарантоол бага хурлын шилдэг илтгэлүүдийн нэг бөгөөд 17-р сарын XNUMX-нд Олег Ивлев үг хэлэх болно. тайлангийн хамт . Александр Деулин мөн Мегафон компаниас илтгэл тавина . Юу өөрчлөгдсөн, ямар төлөвлөгөө хэрэгжсэнийг сонирхоцгооё. Оролцох - бага хурал үнэ төлбөргүй, таны хийх ёстой зүйл . Бүгд болон бага хурлын хөтөлбөр бий болсон байна: шинэ тохиолдол, Tarantool ашиглах шинэ туршлага, архитектур, аж ахуйн нэгж, хичээл, бичил үйлчилгээ.
Эх сурвалж: www.habr.com