Біз бәріміз әңгімелерді жақсы көреміз. Біз оттың айналасында отырып, өткен жеңістеріміз, шайқастарымыз немесе жай ғана жұмыс тәжірибеміз туралы сөйлескенді ұнатамыз.
Бүгін дәл сондай күн. Дәл қазір сіз оттың басында болмасаңыз да, бізде сізге арналған әңгіме бар. Tarantool-де сақтаумен жұмыс істеуді бастағанымыз туралы әңгіме.
Бір кездері біздің компанияда барлығына арналған бірнеше «монолит» және бір «төбе» болды, бұл монолиттер баяу, бірақ сенімді түрде жақындап, компаниямыздың ұшуын, біздің дамуымызды шектеді. Әрі анық түсінік болды: бір күні біз бұл төбені қатты соғамыз.
Қазір жабдықтан бизнес логикасына дейін барлығын және барлығын бөлу идеологиясы басым болып отыр. Нәтижесінде, бізде, мысалы, желі деңгейінде іс жүзінде тәуелсіз екі DC бар. Содан кейін бәрі мүлдем басқаша болды.
Бүгінгі таңда CI/CD, K8S және т.б. түріндегі өзгерістер енгізуге арналған көптеген құралдар мен құралдар бар. «Монолиттік» заманда бізге мұнша көп шетел сөздері қажет емес еді. Дерекқордағы «сақтауды» түзету жеткілікті болды.
Бірақ уақыт алға жылжыды және сұраныстардың саны онымен бірге алға жылжыды, кейде RPS біздің мүмкіндіктерімізден асып түседі. ТМД елдерінің нарыққа шығуымен бірінші монолиттің дерекқор процессорының жүктемесі 90% -дан төмен түспеді, ал RPS 2400 деңгейінде қалды. Бұл жай ғана шағын селекторлар емес, сонымен қатар үлкен сұраныстар болды. үлкен IO фонында деректердің жартысына жуығы үшін жұмыс істей алатын тексерулер мен JOIN тобы.
Сахнада толыққанды қара жұма сатылымдары пайда бола бастағанда - және Wildberries оларды Ресейде алғашқылардың бірі болып өткізді - жағдай мүлдем қайғылы болды. Өйткені, мұндай күндердегі жүктеме үш есе артады.
О, бұл «монолитті уақыт»! Сізде ұқсас нәрсені бастан өткергеніңізге сенімдімін және сіз мұның қалай болуы мүмкін екенін әлі түсіне алмайсыз.
Сіз не істей аласыз - сән технологияға тән. Шамамен 5 жыл бұрын біз сайттың барлық логикасын мұқият сақтайтын .NET және MS SQL серверіндегі бар сайт түрінде осы модтардың бірін қайта қарастыруға тура келді. Мен оны мұқият сақтағаным сонша, мұндай монолитті аралау ұзақ және оңай емес рахатқа айналды.
Кішкентай ауытқу.
Түрлі іс-шараларда мен айтамын: «Егер сіз монолит көрмеген болсаңыз, онда сіз өспегенсіз!» Мені осы мәселе бойынша сіздің пікіріңіз қызықтырады, оны түсініктемелерде жазыңыз.
Найзағай дыбысы
Ендеше, өзіміздің «алауымызға» оралайық. «Монолиттік» функционалдық жүктемені бөлу үшін біз жүйені ашық бастапқы технологиялар негізіндегі микросервистерге бөлуді шештік. Өйткені, кем дегенде, оларды масштабтау арзанырақ. Біз масштабтауымыз керек екенін 100% түсіндік (және көп). Өйткені, сол кездің өзінде-ақ көршілес елдердің нарығына шығуға мүмкіндік туып, тіркеу саны да, тапсырыстар саны да бұдан да күшті өсе бастады.
Монолиттен микросервистерге көшуге алғашқы үміткерлерді талдай отырып, біз олардағы жазудың 80% бэк-офис жүйелерінен, ал оқу фронт-офистен келетінін түсіндік. Ең алдымен, бұл біз үшін бірнеше маңызды ішкі жүйеге қатысты - пайдаланушы деректері және тұтынушылардың қосымша жеңілдіктері мен купондары туралы ақпарат негізінде тауарлардың түпкілікті құнын есептеу жүйесі.
Шегіністі. Енді елестету қорқынышты, бірақ жоғарыда аталған ішкі жүйелерден басқа, өнім каталогтары, пайдаланушының сатып алу себеті, өнімді іздеу жүйесі, өнім каталогтарын сүзгілеу жүйесі және әртүрлі ұсыныстар жүйелері де біздің монолиттен алынып тасталды. Олардың әрқайсысының жұмыс істеуі үшін тар реттелген жүйелердің жеке сыныптары бар, бірақ бір кездері олардың барлығы бір «үйде» өмір сүрді.
Біз бірден клиенттеріміз туралы деректерді sharded жүйеге көшіруді жоспарладық. Тауарлардың түпкілікті құнын есептеу функционалдығын алып тастау оқу үшін жақсы масштабтауды талап етті, өйткені ол ең үлкен RPS жүктемесін жасады және деректер базасы үшін енгізу ең қиын болды (есептеу процесіне көптеген деректер қатысады).
Нәтижесінде біз Tarantool-ге жақсы сәйкес келетін схеманы ойлап таптық.
Ол кезде микросервистердің жұмыс істеуі үшін виртуалды және аппараттық машиналарда бірнеше деректер орталықтарымен жұмыс істеу схемалары таңдалды. Суреттерде көрсетілгендей, Tarantool репликация опциялары мастер-мастер және мастер-құлдық режимдерінде қолданылған.
Архитектура. 1-параметр. Пайдаланушы қызметі
Қазіргі уақытта 24 үзінді бар, олардың әрқайсысында 2 данасы бар (әр DC үшін бір), барлығы мастер-мастер режимінде.
Дерекқордың жоғарғы жағында дерекқор репликаларына қатынасатын қолданбалар бар. Қолданбалар Tarantool Go драйверінің интерфейсін жүзеге асыратын пайдаланушы кітапханасы арқылы Tarantool-мен жұмыс істейді. Ол барлық көшірмелерді көреді және оқу және жазу шеберімен бірге жұмыс істей алады. Негізінде ол көшірмелерді таңдау, қайталау әрекеттерін орындау, автоматты ажыратқыш және жылдамдық шегі үшін логиканы қосатын реплика жиынтығы үлгісін жүзеге асырады.
Бұл жағдайда көшірмелерді таңдау саясатын үзінділер контекстінде теңшеуге болады. Мысалы, roundrobin.
Архитектура. Нұсқа 2. Тауардың соңғы құнын есептеу қызметі
Бірнеше ай бұрын тауарлардың түпкілікті құнын есептеуге арналған сұраныстардың көпшілігі жаңа қызметке жіберілді, ол негізінен дерекқорсыз жұмыс істейді, бірақ біраз уақыт бұрын барлығын Tarantool көмегімен 100% өңдеген.
Қызметтік дерекқор синхронизатор деректерді жинайтын 4 шеберден тұрады және осы репликация шеберлерінің әрқайсысы деректерді тек оқуға арналған көшірмелерге таратады. Әрбір шеберде шамамен 15 осындай көшірме бар.
Бірінші немесе екінші схемада бір тұрақты ток қолжетімсіз болса, қолданба деректерді екіншісінде қабылдай алады.
Айта кету керек, Tarantool-да репликация өте икемді және оны орындау уақытында конфигурациялауға болады. Басқа жүйелерде қиындықтар туындады. Мысалы, PostgreSQL жүйесінде max_wal_senders және max_replication_slots параметрлерін өзгерту шеберді қайта іске қосуды талап етеді, бұл кейбір жағдайларда қолданба мен ДҚБЖ арасындағы байланыстардың үзілуіне әкелуі мүмкін.
Ізде, сонда табасың!
Неліктен біз мұны «қалыпты адамдар сияқты» жасамай, әдеттегі емес жолды таңдадық? Бұл қалыпты деп саналатын нәрсеге байланысты. Көпшілігі әдетте Mongo-дан кластер жасайды және оны үш гео-таратылған DC бойынша таратады.
Ол кезде бізде екі Redis жобасы болды. Біріншісі кэш болды, ал екіншісі тым маңызды емес деректерге арналған тұрақты сақтау болды. Онымен өте қиын болды, ішінара біздің кінәміз. Кейде өте үлкен көлемдер кілтте болды және мезгіл-мезгіл сайт нашарлай бастады. Біз бұл жүйені master-slave нұсқасында қолдандық. Ал шеберге бірдеңе болып, репликация бұзылған жағдайлар көп болды.
Яғни, Редис штаттық емес, азаматтығы жоқ тапсырмалар үшін жақсы. Негізінде, ол көптеген мәселелерді шешуге мүмкіндік берді, бірақ олар индекстер жұбы бар кілт-мәндік шешімдер болған жағдайда ғана. Бірақ сол кезде Редис табандылығы мен қайталануымен өте қайғылы болды. Сонымен қатар, өнімділікке қатысты шағымдар болды.
Біз MySQL және PostgreSQL туралы ойладық. Бірақ біріншісі бізге ұнамады, ал екіншісі - бұл өте күрделі өнім және оған қарапайым қызметтерді құру орынсыз болар еді.
Біз RIAK, Cassandra, тіпті графикалық мәліметтер базасын қолданып көрдік. Мұның бәрі қызметтерді құрудың жалпы әмбебап құралы рөліне сәйкес келмейтін жеткілікті тауашалық шешімдер.
Ақырында біз Тарантолға орналастық.
Біз оған 1.6 нұсқасында болған кезде жүгіндік. Бізді оған кілт-мәннің симбиозы және реляциялық деректер қорының функционалдығы қызықтырды. Қосымша индекстер, транзакциялар және бос орындар бар, олар кестелер сияқты, бірақ қарапайым емес, оларда әртүрлі баған сандарын сақтауға болады. Бірақ Tarantool-тың өлтіретін ерекшелігі кілт-мәнмен және транзакциялықпен біріктірілген қосалқы индекстер болды.
Чатқа көмектесуге дайын жауап беретін орыстілді қауым да рөл атқарды. Біз мұны белсенді түрде қолданып, чатта тікелей өмір сүреміз. Айқын қателіктер мен қателіктерсіз лайықты табандылық туралы ұмытпаңыз. Егер сіз Tarantool-пен тарихымызға қарасаңыз, репликацияда бізде көп қиындықтар мен сәтсіздіктер болды, бірақ оның кінәсінен деректерді жоғалтпадық!
Іске асыру қиын басталды
Ол кезде біздің негізгі әзірлеу стегі .NET болды, оған Tarantool үшін қосқыш жоқ. Біз бірден Go бағдарламасында бірдеңе істей бастадық. Бұл Луамен де жақсы жұмыс істеді. Ол кездегі басты мәселе жөндеуде болды: .NET-те мұның бәрі тамаша, бірақ одан кейін журналдардан басқа жөндеу болмаған кезде енгізілген Lua әлеміне ену қиын болды. Сонымен қатар, қандай да бір себептермен репликация мезгіл-мезгіл бұзылып кетті, сондықтан мен Tarantool қозғалтқышының құрылымын зерттеуге тура келді. Бұған чат көмектесті, ал аз дәрежеде құжаттама; кейде біз кодты қарадық. Ол кезде құжаттама да солай болатын.
Осылайша, бірнеше айдың ішінде мен Tarantool-пен жұмыс істеуден жақсы нәтижелерге қол жеткіздім. Біз git-те жаңа микросервистерді құруға көмектесетін анықтамалық әзірлемелерді құрастырдық. Мысалы, тапсырма пайда болған кезде: басқа микросервисті жасау үшін әзірлеуші репозиторийдегі анықтамалық шешімнің бастапқы кодын қарады және жаңасын жасау бір аптадан аспады.
Бұл ерекше уақыт болды. Әдеттегідей, келесі үстелдегі әкімшіге барып: «Маған виртуалды машина беріңіз» деп сұрауға болады. Шамамен отыз минуттан кейін көлік сізде болды. Сіз өзіңіз қостыңыз, бәрін орнаттыңыз және трафик сізге жіберілді.
Бүгін бұл жұмыс істемейді: қызметке бақылау мен тіркеуді қосу, функционалдылықты сынақтармен қамту, виртуалды машинаға тапсырыс беру немесе Куберге жеткізу және т.б. Тұтастай алғанда, бұл ұзағырақ және қиынырақ болса да, осылайша жақсы болады.
Бөліңіз және басқарыңыз. Луамен не шаруасы бар?
Маңызды дилемма болды: кейбір командалар Луада логикасы көп қызметке өзгертулерді сенімді түрде енгізе алмады. Бұл көбінесе қызметтің жұмыс істемеуімен бірге жүрді.
Яғни, әзірлеушілер қандай да бір өзгерісті дайындап жатыр. Tarantool тасымалдауды бастайды, бірақ көшірме әлі де ескі кодта; Кейбір DDL немесе басқа нәрсе репликация арқылы келеді және код ескерілмегендіктен жай ғана ыдырап қалады. Нәтижесінде әкімшілерді жаңарту процедурасы A4 парағында жасалды: репликацияны тоқтатыңыз, оны жаңартыңыз, репликацияны қосыңыз, осы жерден өшіріңіз, сол жерде жаңартыңыз. Қорқыныш!
Нәтижесінде біз көбінесе Луада ештеңе істемеуге тырысамыз. Жай ғана iproto (сервермен өзара әрекеттесу үшін екілік протокол) пайдаланыңыз және бәрі де. Бұл әзірлеушілер арасында білімнің жетіспеушілігі болуы мүмкін, бірақ бұл тұрғыдан алғанда жүйе күрделі.
Біз бұл сценарийді үнемі соқыр орындай бермейміз. Бүгін бізде ақ пен қара жоқ: не бәрі Луада, не бәрі Года. Кейінірек көші-қон проблемаларына тап болмас үшін оларды қалай біріктіруге болатынын біз қазірдің өзінде түсінеміз.
Tarantool қазір қайда?
Tarantool «Промоутер» деп те аталатын жеңілдік купондарын ескере отырып, тауарлардың түпкілікті құнын есептеу қызметінде қолданылады. Жоғарыда айтқанымдай, ол қазір зейнеткерлікке шықты: оның орнына бағалары алдын ала есептелген жаңа каталог қызметі келеді, бірақ жарты жыл бұрын барлық есептеулер Promotizer-де жасалды. Бұрын оның логикасының жартысы Луада жазылған. Екі жыл бұрын қызмет сақтау орнына айналды, ал логика Go бағдарламасында қайта жазылды, өйткені жеңілдіктер механикасы аздап өзгерді және қызметтің өнімділігі болмады.
Ең маңызды қызметтердің бірі - пайдаланушы профилі. Яғни, барлық Wildberries пайдаланушылары Tarantool-да сақталады және олардың шамамен 50 миллионы бар.Go қызметтеріне қосылған бірнеше DC арқылы таратылатын пайдаланушы идентификаторы арқылы бөлінген жүйе.
RPS мәліметтері бойынша, Промоутер бір кездері 6 мың сұранысқа жеткен көшбасшы болды. Бір кезде қолымызда 50-60 дана болатын. Қазір RPS көшбасшысы - пайдаланушы профильдері, шамамен 12 мың. Бұл қызмет пайдаланушы идентификаторларының диапазондарына бөлінген реттелетін үзінділерді пайдаланады. Қызмет 20-дан астам станокқа қызмет көрсетеді, бірақ бұл тым көп, біз бөлінген ресурстарды қысқартуды жоспарлап отырмыз, өйткені оған 4-5 машинаның қуаты жетеді.
Сеанс қызметі - бұл vshard және Cartridge жүйесіндегі бірінші қызметіміз. Vshard орнату және Картриджді жаңарту бізден біраз күш салуды талап етті, бірақ соңында бәрі ойдағыдай болды.
Веб-сайтта және мобильді қосымшада әртүрлі баннерлерді көрсету қызметі Tarantool-да тікелей шығарылған алғашқылардың бірі болды. Бұл қызмет 6-7 жыл бұрын жұмыс істеп тұрғанымен және ешқашан қайта іске қосылмағанымен ерекшеленеді. Мастер-мастер репликациясы қолданылды. Ешқашан ештеңе бұзылған жоқ.
Кейбір жағдайларда ақпаратты жылдам екі рет тексеру үшін қойма жүйесінде жылдам анықтамалық функционалдылық үшін Tarantool пайдалану мысалы бар. Біз бұл үшін Redis-ті қолдануға тырыстық, бірақ жадтағы деректер Tarantool-ға қарағанда көбірек орын алды.
Күту тізімінің қызметтері, клиент жазылымдары, қазіргі уақыттағы сәнді әңгімелер және кейінге қалдырылған тауарлар Tarantool-пен бірге жұмыс істейді. Жадтағы соңғы қызмет шамамен 120 ГБ алады. Бұл жоғарыда аталған қызметтердің ішіндегі ең ауқымдысы.
қорытынды
Кілт-мәнмен және транзакциялықпен біріктірілген қайталама индекстердің арқасында Tarantool микросервистерге негізделген архитектуралар үшін өте қолайлы. Дегенмен, біз Луада логикасы көп қызметтерге өзгертулерді енгізу кезінде қиындықтарға тап болдық - қызметтер жиі жұмысын тоқтатты. Біз мұны жеңе алмадық және уақыт өте келе біз Луа мен Гоның әртүрлі комбинацияларына келдік: біз бір тілді қайда және басқасын қайда қолдану керектігін білеміз.
Тақырып бойынша тағы не оқу керек
- Tarantool көмегімен нөлден бастап жоғары жүктеме қосымшасын жасау
- Tarantool картриджіндегі сенімді көшбасшы таңдау
- Өнім туралы жаңалықтары бар Tarantool Telegram арнасы
- Қауымдастық чатында Tarantool-ді талқылаңыз
Ақпарат көзі: www.habr.com