Бид бүгд үлгэрт дуртай. Бид галын дэргэд суугаад өнгөрсөн ялалтууд, тулалдаанууд эсвэл зүгээр л ажлын туршлагаа ярих дуртай.
Өнөөдөр яг ийм өдөр. Та яг одоо галын дэргэд байхгүй байсан ч бид танд зориулж түүхтэй. Бид Tarantool дээр хадгалахтай хэрхэн ажиллаж эхэлсэн түүх.
Нэгэн цагт манай компани бүгдэд зориулсан хоёр "цул", нэг "тааз"-тай байсан бөгөөд тэдгээр цул аажмаар аажмаар ойртож, манай компанийн нислэгийг хязгаарлаж, бидний хөгжлийг хязгаарлаж байв. Тэгээд тодорхой ойлголт байсан: нэг л өдөр бид энэ таазыг хүчтэй цохих болно.
Одоо тоног төхөөрөмжөөс эхлээд бизнесийн логик хүртэл бүх зүйлийг, бүх зүйлийг салгах үзэл баримтлал давамгайлж байна. Үүний үр дүнд бид, жишээ нь, сүлжээний түвшинд бараг бие даасан хоёр DC-тэй болсон. Тэгээд бүх зүйл шал өөр болсон.
Өнөөдөр CI/CD, K8S гэх мэт хэлбэрээр өөрчлөлт хийх маш олон хэрэгсэл, хэрэгслүүд байдаг. “Цул” үед ийм олон гадаад үг хэрэггүй байсан. Мэдээллийн сан дахь "хадгалах" хэсгийг засахад л хангалттай байсан.
Гэвч цаг хугацаа урагшилж, хүсэлтийн тоо дагаад урагшилж, заримдаа бидний чадавхаас давсан RPS-ийг буудаж байв. ТУХН-ийн орнууд зах зээлд нэвтэрснээр анхны цул процессорын өгөгдлийн сангийн ачаалал 90% -иас доош буугаагүй бөгөөд RPS нь 2400 түвшинд хэвээр байв. Эдгээр нь зүгээр л жижиг сонгогчид биш, харин асар их асуултууд байв. Их хэмжээний IO-ийн дэвсгэр дээр өгөгдлийн бараг тал хувь нь ажиллах боломжтой олон тооны шалгалтууд болон НЭГДСЭН.
Бүрэн хэмжээний Хар Баасан гарагийн борлуулалт тайзан дээр гарч эхлэхэд Wildberries Орост анх удаа зохион байгуулсан хүмүүсийн нэг байсан тул нөхцөл байдал бүрэн гунигтай болов. Эцсийн эцэст ийм өдрүүдэд ачаалал гурав дахин нэмэгддэг.
Өө, эдгээр "цул цаг үе"! Та үүнтэй төстэй зүйлтэй тулгарсан гэдэгт би итгэлтэй байна, гэхдээ энэ нь танд хэрхэн тохиолдож болохыг ойлгохгүй хэвээр байна.
Та юу хийж чадах вэ - загвар нь технологид байдаг. Ойролцоогоор 5 жилийн өмнө бид сайтын бүх логикийг сайтар хадгалсан .NET болон MS SQL сервер дээрх одоо байгаа сайтын хэлбэрээр эдгээр загваруудын аль нэгийг дахин бодож үзэх шаардлагатай болсон. Би үүнийг маш болгоомжтой хадгалсан тул ийм цул хөрөөдөх нь урт бөгөөд тийм ч амар таашаал биш байв.
Жижиг ухралт.
Төрөл бүрийн арга хэмжээн дээр би: "Хэрэв та цул үзээгүй бол ургаагүй байна!" Энэ талаарх таны бодлыг би сонирхож байна, сэтгэгдэл дээр бичнэ үү.
Аянгын чимээ
"Галдаа" эргэн орцгооё. "Цул" функцийн ачааллыг хуваарилахын тулд бид системийг нээлттэй эхийн технологид суурилсан микро үйлчилгээнд хуваахаар шийдсэн. Учир нь хамгийн багадаа тэдгээрийг масштабаар тооцоход хямд байдаг. Мөн бид 100% (мөн маш их хэмжээгээр) масштаблах ёстой гэдгийг ойлгосон. Эцсийн эцэст, тэр үед аль хэдийн хөрш орнуудын зах зээлд нэвтрэх боломжтой байсан бөгөөд бүртгэлийн тоо, түүнчлэн захиалгын тоо улам бүр нэмэгдэж эхэлсэн.
Монолитоос микро үйлчилгээнд шилжих эхний нэр дэвшигчдэд дүн шинжилгээ хийсний дараа бид тэдгээрийн бичсэн бичгийн 80% нь арын албаны системээс, мөн урд оффисоос уншдаг гэдгийг ойлгосон. Юуны өмнө энэ нь бидний хувьд хэд хэдэн чухал дэд системүүдтэй холбоотой байсан - хэрэглэгчийн өгөгдөл, нэмэлт үйлчлүүлэгчдийн хөнгөлөлт, купоны талаархи мэдээлэлд үндэслэн барааны эцсийн өртөгийг тооцоолох систем юм.
Доголтой. Одоо төсөөлөхөд аймшигтай боловч дээр дурдсан дэд системүүдээс гадна бүтээгдэхүүний каталог, хэрэглэгчийн сагс, бүтээгдэхүүний хайлтын систем, бүтээгдэхүүний каталогийг шүүх систем, төрөл бүрийн зөвлөмжийн системүүд манай цул хэсгээс хасагдсан. Тэд тус бүрийг ажиллуулахын тулд нарийн тохируулсан системийн тусдаа ангиуд байдаг боловч нэг удаа тэд бүгд нэг "байшинд" амьдардаг байв.
Бид нэн даруй үйлчлүүлэгчдийнхээ мэдээллийг sharded систем рүү шилжүүлэхээр төлөвлөсөн. Бараа бүтээгдэхүүний эцсийн өртөгийг тооцоолох функцийг устгах нь уншихад сайн масштабтай байх шаардлагатай байсан, учир нь энэ нь хамгийн их RPS ачааллыг бий болгож, мэдээллийн санд хэрэгжүүлэхэд хамгийн хэцүү байсан (тооцоолох үйл явцад маш их өгөгдөл оролцдог).
Үүний үр дүнд бид Tarantool-тэй сайн тохирох схемийг гаргасан.
Тухайн үед микро үйлчилгээг ажиллуулахын тулд виртуал болон техник хангамжийн машин дээр хэд хэдэн мэдээллийн төвтэй ажиллах схемийг сонгосон. Зурагт үзүүлсэнчлэн Tarantool хуулбарлах сонголтыг мастер-мастер болон мастер-боол горимд ашигласан.
Архитектур. Сонголт 1. Хэрэглэгчийн үйлчилгээ
Одоогийн байдлаар 24 хэлтэрхий байгаа бөгөөд тус бүр нь 2 тохиолдолтой (ДС тус бүрд нэг), бүгд мастер-мастер горимд байна.
Өгөгдлийн сангийн дээд талд мэдээллийн сангийн хуулбарт ханддаг програмууд байдаг. Програмууд нь Tarantool Go драйверын интерфейсийг хэрэгжүүлдэг манай тусгай номын сангаар дамжуулан Tarantool-тэй ажилладаг. Тэр бүх хуулбарыг харж, уншиж, бичихийн тулд мастертай хамтран ажиллаж чадна. Үндсэндээ энэ нь хуулбарыг сонгох, дахин оролдох, таслагч болон хурдны хязгаарлалт зэрэг логикийг нэмсэн хуулбарын багц загварыг хэрэгжүүлдэг.
Энэ тохиолдолд хуулбар сонгох бодлогыг хэлтэрхийнүүдийн хүрээнд тохируулах боломжтой. Жишээлбэл, roundrobin.
Архитектур. Сонголт 2. Барааны эцсийн өртгийг тооцох үйлчилгээ
Хэдэн сарын өмнө барааны эцсийн өртгийг тооцоолох хүсэлтийн ихэнх нь зарчмын хувьд мэдээллийн сангүйгээр ажилладаг шинэ үйлчилгээнд очсон боловч хэсэг хугацааны өмнө бүх зүйлийг 100% Tarantool-ийн тусламжтайгаар боловсруулсан.
Үйлчилгээний мэдээллийн сан нь синхрончлогч нь өгөгдөл цуглуулдаг 4 мастераас бүрдэх ба эдгээр хуулбарлах мастер тус бүр нь зөвхөн уншигдах хуулбаруудад өгөгдлийг түгээдэг. Мастер бүр ойролцоогоор 15 ийм хуулбартай байдаг.
Эхний эсвэл хоёр дахь схемд нэг DC боломжгүй бол програм нь хоёр дахь схемд өгөгдлийг хүлээн авах боломжтой.
Tarantool-д хуулбарлах нь нэлээд уян хатан бөгөөд ажиллах үед тохируулах боломжтой гэдгийг тэмдэглэх нь зүйтэй. Бусад системд хүндрэлүүд гарч ирэв. Жишээлбэл, PostgreSQL дэх max_wal_senders болон max_replication_slots параметрүүдийг өөрчлөхөд шидтэнг дахин эхлүүлэх шаардлагатай бөгөөд энэ нь зарим тохиолдолд програм болон DBMS хоорондын холболтыг таслахад хүргэдэг.
Хай, тэгвэл та олох болно!
Бид яагаад үүнийг "жирийн хүмүүс шиг" хийлгүй, ердийн бус аргыг сонгосон юм бэ? Энэ нь хэвийн гэж тооцогддог зүйлээс хамаарна. Олон хүмүүс ерөнхийдөө Mongo-ээс кластер хийж, түүнийгээ гурван газарзүйн тархалттай DC-д тараадаг.
Тэр үед бид хоёр Redis төсөлтэй байсан. Эхнийх нь кэш, хоёр дахь нь тийм ч чухал биш өгөгдлийг хадгалах байнгын хадгалалт юм. Түүнд нэлээд хэцүү байсан, зарим талаараа бидний буруу. Заримдаа нэлээд их хэмжээний эзэлхүүнтэй байсан бөгөөд үе үе сайт нь муудаж байв. Бид энэ системийг мастер-боол хувилбарт ашигласан. Мөн мастерт ямар нэг зүйл тохиолдож, хуулбар нь эвдэрсэн тохиолдол олон байсан.
Өөрөөр хэлбэл, Редис нь төлөвтэй бус харин харьяалалгүй ажилд тохиромжтой. Зарчмын хувьд энэ нь ихэнх асуудлыг шийдвэрлэх боломжийг олгодог, гэхдээ тэдгээр нь хос индекс бүхий түлхүүр-үнэгийн шийдэл байсан тохиолдолд л боломжтой юм. Гэхдээ тэр үед Редис тууштай, хуулбарласандаа нэлээд гунигтай байсан. Үүнээс гадна гүйцэтгэлийн талаар гомдол ирсэн.
Бид MySQL болон PostgreSQL-ийн талаар бодсон. Гэхдээ эхнийх нь ямар нэг байдлаар бидний сэтгэлд хүрсэнгүй, хоёр дахь нь өөрөө нэлээд боловсронгуй бүтээгдэхүүн бөгөөд үүн дээр энгийн үйлчилгээг бий болгох нь зохисгүй юм.
Бид RIAK, Cassandra, тэр ч байтугай график мэдээллийн санг туршиж үзсэн. Эдгээр нь бүгд үйлчилгээ бий болгох бүх нийтийн хэрэгслийн үүрэг гүйцэтгэхэд тохиромжгүй нэлээд нарийн шийдэл юм.
Эцэст нь бид Тарантуул дээр суурьшлаа.
1.6 хувилбар дээр байх үед бид түүн рүү хандсан. Түлхүүр утгын симбиоз ба харилцааны мэдээллийн сангийн функцээр бид үүнийг сонирхож байсан. Хоёрдогч индексүүд, гүйлгээнүүд, орон зайнууд байдаг бөгөөд эдгээр нь хүснэгттэй адил боловч энгийн биш, та тэдгээрт өөр өөр тооны багана хадгалах боломжтой. Гэхдээ Tarantool-ийн алуурчин шинж чанар нь хоёрдогч индексүүд бөгөөд түлхүүрийн үнэ цэнэ, гүйлгээний чадвар юм.
Чатаар туслахад бэлэн орос хэлээр ярьдаг нийгэмлэг бас үүрэг гүйцэтгэсэн. Бид үүнийг идэвхтэй ашиглаж, шууд чатаар амьдардаг. Мөн илт алдаа, алдаагүйгээр зохистой тууштай байх талаар бүү мартаарай. Хэрэв та Tarantool-ийн түүхийг харвал бид репликацийн үед маш их өвдөж, бүтэлгүйтсэн боловч түүний буруугаас болж бид хэзээ ч өгөгдлийг алдаж байгаагүй!
Хэрэгжилт нь бүдүүлэг эхэлсэн
Тэр үед манай хөгжүүлэлтийн үндсэн стек нь Tarantool-ийн холбогч байхгүй байсан .NET байсан. Бид тэр даруй Go-д ямар нэгэн зүйл хийж эхлэв. Энэ нь Луатай ч сайн ажилласан. Тэр үеийн гол асуудал нь дибаг хийхтэй холбоотой байсан: .NET дээр бүх зүйл сайхан байдаг, гэхдээ үүний дараа логуудаас өөр дибаг хийх боломжгүй байхад суулгагдсан Луагийн ертөнцөд ороход хэцүү байсан. Нэмж дурдахад зарим шалтгааны улмаас хуулбар нь үе үе задарч байсан тул би Tarantool хөдөлгүүрийн бүтцийг судлах шаардлагатай болсон. Чат нь үүнд тусалсан бөгөөд бага зэрэг баримт бичиг, заримдаа бид кодыг хардаг байсан. Тэр үед бичиг баримт нь тийм байсан.
Ингээд хэдэн сарын хугацаанд би толгойгоо эргүүлж, Тарантоолтой хамтран ажилласнаар зохих үр дүнд хүрч чадсан. Бид шинэ микро үйлчилгээг бий болгоход тусалсан git дэх лавлагааны хөгжүүлэлтийг эмхэтгэсэн. Жишээлбэл, даалгавар гарч ирэхэд: өөр бичил үйлчилгээ үүсгэхийн тулд хөгжүүлэгч репозитор дахь лавлагааны шийдлийн эх кодыг үзсэн бөгөөд шинээр бий болгоход долоо хоногоос илүүгүй хугацаа шаардагдана.
Эдгээр нь онцгой үе байсан. Уламжлал ёсоор бол та дараагийн ширээний админ дээр очоод "Надад виртуал машин өгөөч" гэж асууж болно. Гучин минутын дараа машин аль хэдийн тантай хамт байсан. Та өөрийгөө холбож, бүх зүйлийг суулгаж, урсгалыг тань руу илгээсэн.
Өнөөдөр энэ нь ажиллахаа больсон: та үйлчилгээнд хяналт, бүртгэл нэмэх, функцийг тестээр хамрах, виртуал машин захиалах эсвэл Куберт хүргэх гэх мэт хэрэгтэй. Ерөнхийдөө энэ нь илүү удаан үргэлжлэх бөгөөд илүү төвөгтэй байх болно.
Хувааж, захир. Луатай ямар холбоотой вэ?
Ноцтой асуудал тулгарсан: зарим багууд Луа дахь маш их логиктой үйлчилгээнд өөрчлөлтүүдийг найдвартай хийж чадахгүй байв. Энэ нь ихэвчлэн үйлчилгээ ажиллахгүй байх дагалддаг.
Өөрөөр хэлбэл, хөгжүүлэгчид ямар нэгэн өөрчлөлтийг бэлдэж байна. Tarantool шилжилт хөдөлгөөнийг хийж эхэлсэн боловч хуулбар нь хуучин кодтой хэвээр байна; Зарим DDL эсвэл өөр ямар нэг зүйл хуулбарлах замаар тэнд ирдэг бөгөөд код нь анхааралдаа аваагүй тул зүгээр л задарч унадаг. Үүний үр дүнд администраторуудад зориулсан шинэчлэлтийн журмыг A4 хуудсан дээр байрлуулсан: хуулбарлахыг зогсоох, үүнийг шинэчлэх, хуулбарлахыг асаах, энд унтраах, тэнд шинэчлэх. Хар дарсан зүүд!
Үүний үр дүнд бид ихэвчлэн Луад юу ч хийхгүй байхыг хичээдэг. Зүгээр л iproto (сервертэй харилцах хоёртын протокол) ашигла, тэгээд л болоо. Магадгүй энэ нь хөгжүүлэгчдийн дунд мэдлэг дутмаг байж болох ч энэ үүднээс авч үзвэл систем нь нарийн төвөгтэй юм.
Энэ зохиолыг бид дандаа сохроор дагадаггүй. Өнөөдөр бидэнд хар цагаан байхгүй: нэг бол бүх зүйл Луад байна, эсвэл бүх зүйл Го-д байна. Дараа нь шилжилт хөдөлгөөний асуудалтай тулгарахгүйн тулд тэдгээрийг хэрхэн нэгтгэж болохыг бид аль хэдийн ойлгосон.
Тарантоол одоо хаана байна?
Tarantool нь хөнгөлөлтийн купоныг харгалзан барааны эцсийн өртгийг тооцоолох үйлчилгээнд ашиглагддаг бөгөөд үүнийг "Дэмжүүлэгч" гэж нэрлэдэг. Өмнө нь хэлсэнчлэн тэр одоо тэтгэвэртээ гарч байна: түүнийг урьдчилан тооцоолсон үнэ бүхий шинэ каталогийн үйлчилгээгээр сольж байгаа боловч зургаан сарын өмнө бүх тооцоог Promotizer дээр хийсэн. Өмнө нь түүний логикийн тал нь Луа хэлээр бичигдсэн байдаг. Хоёр жилийн өмнө уг үйлчилгээг хадгалах газар болгож, хөнгөлөлтийн механизм бага зэрэг өөрчлөгдөж, үйлчилгээ нь гүйцэтгэл муутай байсан тул логикийг Go-д дахин бичсэн.
Хамгийн чухал үйлчилгээний нэг бол хэрэглэгчийн профайл юм. Өөрөөр хэлбэл, Wildberries-ийн бүх хэрэглэгчид Tarantool-д хадгалагддаг бөгөөд тэдгээрийн 50 сая орчим нь Go үйлчилгээнд холбогдсон хэд хэдэн DC-д тархсан хэрэглэгчийн ID-аар хуваагдсан систем юм.
RPS-ийн мэдээлснээр Промоутер нэг удаа тэргүүлэгч байсан бөгөөд 6 мянган хүсэлтэд хүрч байжээ. Нэг удаа манайд 50-60 хувь байсан. Одоо RPS-ийн тэргүүлэгч нь 12 мянга орчим хэрэглэгчийн профайл юм. Энэ үйлчилгээ нь хэрэглэгчийн ID-ийн мужид хуваагдсан өөрчлөн хуваалтыг ашигладаг. Үйлчилгээ нь 20 гаруй машинд үйлчилдэг боловч энэ нь хэтэрхий олон тул 4-5 машины хүчин чадал хангалттай тул хуваарилагдсан нөөцийг багасгахаар төлөвлөж байна.
Session үйлчилгээ нь vshard болон Cartridge дээрх бидний анхны үйлчилгээ юм. Vshard-г тохируулах, Cartridge-г шинэчлэх нь биднээс бага зэрэг хүчин чармайлт шаардсан боловч эцэст нь бүх зүйл амжилттай болсон.
Вэбсайт болон гар утасны програм дээр янз бүрийн баннер байрлуулах үйлчилгээ нь Tarantool дээр шууд гарсан анхны үйлчилгээ юм. Энэхүү үйлчилгээ нь 6-7 жилийн настай, одоог хүртэл ажиллаж байгаа, дахин ачаалж байгаагүй гэдгээрээ онцлог юм. Мастер-мастер хуулбарыг ашигласан. Юу ч хэзээ ч эвдэрч байгаагүй.
Зарим тохиолдолд мэдээллийг хурдан давхар шалгахын тулд агуулахын системд хурдан лавлагааны функцийг ашиглахын тулд Tarantool ашиглах жишээ бий. Үүний тулд бид Redis-ийг ашиглахыг оролдсон боловч санах ойн өгөгдөл нь Tarantool-ээс илүү их зай эзэлдэг.
Хүлээлгийн жагсаалт, үйлчлүүлэгчийн захиалга, одоо байгаа загварлаг түүх, хойшлогдсон бараа зэрэг үйлчилгээ нь Tarantool-тэй ажилладаг. Санах ойн хамгийн сүүлийн үйлчилгээ нь ойролцоогоор 120 ГБ эзэлнэ. Энэ бол дээрх үйлчилгээнүүдийн хамгийн цогц үйлчилгээ юм.
дүгнэлт
Түлхүүр-утга, гүйлгээний чадвартай хослуулсан хоёрдогч индексүүдийн ачаар Tarantool нь микро үйлчилгээнд суурилсан архитектурт тохиромжтой. Гэсэн хэдий ч бид Луа-д маш их логиктой үйлчилгээнд өөрчлөлт оруулахад бэрхшээлтэй тулгарсан - үйлчилгээнүүд ихэвчлэн ажиллахаа больсон. Бид үүнийг даван туулж чадаагүй бөгөөд цаг хугацаа өнгөрөхөд бид Луа, Го хоёрын өөр өөр хослолыг олж авсан: бид нэг хэлийг хаана, нөгөө хэлийг хаана ашиглахаа мэддэг.
Энэ сэдвээр өөр юу унших вэ
- Tarantool ашиглан эхнээс нь өндөр ачаалалтай програм үүсгэх
- Tarantool Cartridge-ийн найдвартай удирдагчийн сонголт
- Telegram суваг Tarantool бүтээгдэхүүний тухай мэдээ
- Олон нийтийн чат дээр Tarantool-ийн талаар ярилц
Эх сурвалж: www.habr.com