🥇Tarantool картриджі: үш жолдағы Lua серверінің бөлінуі

Бізде Mail.ru Group-та Tarantool бар - бұл Луадағы қолданбалы сервер, ол сонымен қатар біріктірілген дерекқор (немесе керісінше?). Бұл жылдам және керемет, бірақ бір сервердің мүмкіндіктері әлі де шексіз емес. Тік масштабтау да панацея емес, сондықтан Tarantool-да көлденең масштабтауға арналған құралдар бар — vshard модулі [1]. Ол бірнеше серверлер арқылы деректерді бөлуге мүмкіндік береді, бірақ оны орнату және бизнес логикасын бұрау үшін онымен жұмыс істеу керек.

Жақсы жаңалық: біз конустарды жинадық (мысалы [2], [3]) және осы мәселені шешуді айтарлықтай жеңілдететін басқа құрылымды ұсынды.

Tarantool картриджі күрделі үлестірілген жүйелерді дамытудың жаңа негізі болып табылады. Ол инфрақұрылымдық мәселелерді шешудің орнына бизнес логикасын жазуға назар аударуға мүмкіндік береді. Қысқаша айтқанда, мен сізге бұл құрылым қалай жұмыс істейтінін және онымен таратылған қызметтерді қалай жазу керектігін айтамын.

Ал, мәселе неде?

Бізде тарантул бар, бізде вшард бар - сізге тағы не керек?

Біріншіден, бұл ыңғайлылық мәселесі. Vshard конфигурациясы Lua кестелері арқылы конфигурацияланады. Бірнеше Tarantool процестерінің бөлінген жүйесі дұрыс жұмыс істеуі үшін конфигурация барлық жерде бірдей болуы керек. Оны ешкім қолмен жасағысы келмейді. Сондықтан, сценарийлердің барлық түрлері, Ansible, орналастыру жүйелері қолданылады.

Картридж vshard конфигурациясын өзі басқарады, ол мұны өздігінен жасайды меншікті бөлінген конфигурация. Негізінде бұл қарапайым YAML файлы, оның көшірмесі Tarantool бағдарламасының әрбір данасында сақталады. Жеңілдету мынада: рамканың өзі оның конфигурациясын бақылайды және оның барлық жерде бірдей болуын қамтамасыз етеді.

Екіншіден, бұл қайтадан ыңғайлылық мәселесі. Vshard конфигурациясы бизнес логикасын дамытуға ешқандай қатысы жоқ және тек бағдарламашыны жұмыстан алшақтатады. Біз жобаның архитектурасын талқылағанда, көбінесе жеке құрамдас бөліктер мен олардың өзара әрекеттесуі туралы айтамыз. 3 деректер орталығына арналған кластерді шығару туралы ойлауға әлі ерте.

Біз бұл мәселелерді бірте-бірте шешіп отырдық және белгілі бір уақытта біз қосымшамен жұмысты оның бүкіл өмірлік циклі бойына жеңілдетуге мүмкіндік беретін тәсілді әзірлей алдық: жасау, әзірлеу, тестілеу, CI/CD, техникалық қызмет көрсету.

Картридж әрбір Tarantool процесі үшін рөл тұжырымдамасын ұсынады. Рөлдер - әзірлеушіге код жазуға назар аударуға мүмкіндік беретін тұжырымдама. Жобада қол жетімді барлық рөлдерді Tarantool бір данасында іске қосуға болады және бұл сынақтар үшін жеткілікті болады.

Tarantool картриджінің негізгі мүмкіндіктері:

автоматтандырылған кластерлік оркестрлеу;
қолданба функционалдығын жаңа рөлдермен кеңейту;
әзірлеуге және орналастыруға арналған қолданба үлгісі;
кірістірілген автоматты бөлшектеу;
Luatest тест жүйесімен интеграция;
WebUI және API көмегімен кластерді басқару;
орау және орналастыру құралдары.

Сәлем Әлем!

Мен рамканың өзін көрсетуді күте алмаймын, сондықтан архитектура туралы әңгімені кейінірек қалдырып, қарапайым бастайық. Tarantool өзі орнатылып қойған деп есептесек, тек қана істеу керек

$ tarantoolctl rocks install cartridge-cli
$ export PATH=$PWD/.rocks/bin/:$PATH

Бұл екі пәрмен пәрмен жолы утилиталарын орнатады және үлгіден бірінші қолданбаны жасауға мүмкіндік береді:

$ cartridge create --name myapp

Ал біз мынаны аламыз:

myapp/
├── .git/
├── .gitignore
├── app/roles/custom.lua
├── deps.sh
├── init.lua
├── myapp-scm-1.rockspec
├── test
│   ├── helper
│   │   ├── integration.lua
│   │   └── unit.lua
│   ├── helper.lua
│   ├── integration/api_test.lua
│   └── unit/sample_test.lua
└── tmp/

Бұл «Сәлем, әлем!» бар гит репозиторийі. қолдану. Тәуелділіктерді (соның ішінде рамканың өзін) орнатқаннан кейін оны бірден іске қосып көрейік:

$ tarantoolctl rocks make
$ ./init.lua --http-port 8080

Сонымен, бізде іске қосылған болашақ ортақ қолданбаның бір түйіні бар. Ізденімпаз қарапайым адам бірден веб-интерфейсті ашып, тінтуірдің көмегімен бір түйіннен кластерді конфигурациялай алады және нәтижеден ләззат алады, бірақ қуануға әлі ерте. Әзірге қолданба пайдалы нәрсені қалай жасау керектігін білмейді, сондықтан мен орналастыру туралы кейінірек айтатын боламын, енді кодты жазу уақыты келді.

Қолданбаларды әзірлеу

Елестетіп көріңізші, біз деректерді қабылдауға, оны сақтауға және күніне бір рет есепті құруға арналған жобаны әзірлеп жатырмыз.

Біз диаграмманы салуды бастаймыз және оған үш компонентті орналастырамыз: шлюз, сақтау және жоспарлаушы. Біз сәулетпен айналысамыз. Біз vshard-ды сақтау ретінде пайдаланатындықтан, схемаға vsard-маршрутизатор мен vshard-сақтауын қосамыз. Шлюз де, жоспарлаушы да қоймаға тікелей қол жеткізе алмайды, бұл үшін маршрутизатор бар, ол осы үшін жасалған.

Бұл диаграмма әлі де жобада жасайтын нәрсені дәл көрсетпейді, өйткені құрамдас бөліктер дерексіз болып көрінеді. Біз әлі де оның нақты Tarantool-ға қалай жобаланатынын көруіміз керек - компоненттерімізді процестер бойынша топтастырайық.

Vshard-маршрутизатор мен шлюзді бөлек даналарда сақтаудың мағынасы жоқ. Неліктен бұл маршрутизатордың жауапкершілігі болса, желіні тағы бір рет өтуіміз керек? Оларды бірдей процесс ішінде іске қосу керек. Яғни, шлюз де, vsard.router.cfg екеуі де бір процесте инициализацияланады және олардың жергілікті түрде өзара әрекеттесуіне мүмкіндік береді.

Дизайн кезеңінде үш компонентпен жұмыс істеу ыңғайлы болды, бірақ әзірлеуші ретінде кодты жазу кезінде мен Tarnatool үш данасын іске қосу туралы ойлағым келмейді. Маған сынақтарды орындау және шлюзді дұрыс жазғанымды тексеру керек. Немесе әріптестеріме бір ерекшелік көрсеткім келеді. Неліктен мен үш дананы орналастырумен алаңдауым керек? Рөлдер ұғымы осылай туды. Рөл - өмірлік циклін Картридж басқаратын кәдімгі luash модулі. Бұл мысалда олардың төртеуі бар - шлюз, маршрутизатор, қойма, жоспарлаушы. Басқа жобада көбірек болуы мүмкін. Барлық рөлдерді бір процесте іске қосуға болады және бұл жеткілікті болады.

Кезеңге немесе өндіріске орналастыруға келгенде, біз әрбір Tarantool процесіне аппараттық құралдардың мүмкіндіктеріне байланысты рөлдер жиынтығын тағайындаймыз:

Топологияны басқару

Қай рөлдердің орындалып жатқаны туралы ақпарат бір жерде сақталуы керек. Және бұл «бір жерде» - мен жоғарыда айтқан таратылған конфигурация. Ондағы ең маңыздысы – кластердің топологиясы. Мұнда 3 Tarantool процесінің 5 репликация тобы берілген:

Біз деректерді жоғалтқымыз келмейді, сондықтан біз іске қосылған процестер туралы ақпаратқа қамқорлық жасаймыз. Картридж конфигурацияны екі фазалық міндеттемемен қадағалайды. Конфигурацияны жаңартқымыз келгенде, ол алдымен барлық даналардың қолжетімділігін және жаңа конфигурацияны қабылдауға дайын екенін тексереді. Осыдан кейін екінші кезең конфигурацияны қолданады. Осылайша, бір көшірме уақытша қолжетімсіз болса да, жаман ештеңе болмайды. Конфигурация жай ғана қолданылмайды және сіз қатені алдын ала көресіз.

Топология бөлімінде әрбір репликация тобының көшбасшысы сияқты маңызды параметр бар. Бұл әдетте жазылатын данаға жатады. Қалғандары көбінесе тек оқуға арналған, бірақ ерекше жағдайлар болуы мүмкін. Кейде батыл әзірлеушілер қақтығыстардан қорықпайды және деректерді бірнеше репликаға параллель жаза алады, бірақ бәріне қарамастан, екі рет орындалмауы керек кейбір операциялар бар. Бұл үшін көшбасшының белгісі бар.

Рөлдердің өмірі

Мұндай архитектурада дерексіз рөл болуы үшін, рамка оларды қандай да бір жолмен басқаруы керек. Әрине, басқару Tarantool процесін қайта бастамастан жүзеге асырылады. Рөлдерді басқару үшін 4 кері шақыру бар. Картридждің өзі оларды таратылған конфигурацияда не жазғанына байланысты шақырады, осылайша конфигурацияны нақты рөлдерге қолданады.

function init()
function validate_config()
function apply_config()
function stop()

Әрбір рөлдің функциясы бар init. Ол рөл қосылғанда немесе Tarantool қайта іске қосылғанда бір рет шақырылады. Мұнда, мысалы, box.space.create инициализациясы ыңғайлы немесе жоспарлаушы белгілі бір аралықтарда жұмысты орындайтын кейбір фондық талшықты іске қоса алады.

жалғыз функция init жеткіліксіз болуы мүмкін. Картридж рөлдерге топологияны сақтау үшін пайдаланатын таратылған конфигурацияның артықшылығын пайдалануға мүмкіндік береді. Біз сол конфигурацияда жаңа бөлімді жариялай аламыз және онда бизнес конфигурациясының фрагментін сақтай аламыз. Менің мысалда бұл деректер схемасы немесе жоспарлаушы рөліне арналған кесте параметрлері болуы мүмкін.

Кластер қоңыраулары validate_config и apply_config таратылған конфигурация өзгерген сайын. Конфигурация екі фазалық тапсырма арқылы қолданылғанда, кластер әрбір рөлдің осы жаңа конфигурацияны қабылдауға дайын екенін тексереді және қажет болса, пайдаланушыға қате туралы хабарлайды. Барлығы конфигурацияның қалыпты екеніне келіскен кезде, содан кейін apply_config.

Рөлдердің де әдісі бар stopБұл рөлдің маңыздылығын тазарту үшін қажет. Бұл серверде жоспарлаушы енді қажет емес десек, ол өзі бастаған талшықтарды тоқтата алады init.

Рөлдер бір-бірімен әрекеттесе алады. Біз Луада функционалдық шақыруларды жазуға үйренгенбіз, бірақ бұл процесте бізге қажет рөл болмауы мүмкін. Желі арқылы қоңырау шалуды жеңілдету үшін біз Tarantool ішіне орнатылған стандартты нетбокс негізінде құрастырылған rpc (қашықтағы процедураны шақыру) көмекші модулін қолданамыз. Бұл, мысалы, шлюзіңіз жоспарлаушыдан бір күн күтпей, дәл қазір тапсырманы орындауды сұрағысы келсе, пайдалы болуы мүмкін.

Тағы бір маңызды мәселе - ақауларға төзімділікті қамтамасыз ету. Картридж денсаулықты бақылау үшін SWIM протоколын пайдаланады [4]. Бір сөзбен айтқанда, процестер UDP арқылы бір-бірімен «сыбыстармен» алмасады - әрбір процесс көршілеріне соңғы жаңалықтарды айтады және олар жауап береді. Егер кенеттен жауап келмесе, Тарантол бірдеңе дұрыс емес деп күдіктене бастайды және біраз уақыттан кейін ол өлімді айтып, осы жаңалықты айналасындағыларға айта бастайды.

Осы хаттама негізінде Картридж ақауларды автоматты түрде өңдеуді ұйымдастырады. Әрбір процесс өз ортасын бақылайды және көшбасшы кенеттен жауап беруді тоқтатса, реплика өз рөлін қабылдай алады және Картридж іске қосылған рөлдерді сәйкесінше конфигурациялайды.

Бұл жерде абай болу керек, себебі алға-артқа жиі ауысу репликация кезінде деректер қақтығыстарына әкелуі мүмкін. Кездейсоқ автоматты ауыстыруды қосу, әрине, оған тұрарлық емес. Сіз не болып жатқанын нақты түсінуіңіз керек және көшбасшы қалпына келтірілгеннен кейін және тәж оған қайтарылғаннан кейін репликация бұзылмайтынына сенімді болуыңыз керек.

Жоғарыда айтылғандардың барлығынан сіз рөлдердің микросервистерге ұқсайтынын сезінуіңіз мүмкін. Белгілі бір мағынада, олар тек Tarantool процестеріндегі модульдер ретінде. Бірақ бірқатар негізгі айырмашылықтар да бар. Біріншіден, барлық жоба рөлдері бір код базасында тұруы керек. Барлық Tarantool процестері бір код базасынан жұмыс істеуі керек, сондықтан жоспарлаушыны инициализациялауға тырысқан кездегідей тосынсыйлар болмайды, бірақ ол жоқ. Сондай-ақ, код нұсқаларында айырмашылықтарға жол бермеу керек, өйткені мұндай жағдайда жүйенің әрекетін болжау және жөндеу өте қиын.

Докерден айырмашылығы, біз рөлдің «бейнесін» алып, оны басқа машинаға апарып, сол жерде іске қоса алмаймыз. Біздің рөлдер Docker контейнерлері сияқты оқшауланған емес. Сондай-ақ, біз бір данада екі бірдей рөлді іске қоса алмаймыз. Рөл бар немесе жоқ, белгілі бір мағынада бұл синглтон. Үшіншіден, бүкіл репликация тобының ішінде рөлдер бірдей болуы керек, өйткені әйтпесе бұл күлкілі болар еді - деректер бірдей, бірақ конфигурация әртүрлі.

Орналастыру құралдары

Мен Cartridge қолданбаларды орналастыруға қалай көмектесетінін көрсетуге уәде бердім. Басқалардың өмірін жеңілдету үшін құрылым RPM бумаларын қамтиды:

$ cartridge pack rpm myapp -- упакует для нас ./myapp-0.1.0-1.rpm
$ sudo yum install ./myapp-0.1.0-1.rpm

Орнатылған бума сізге қажет дерлік барлығын қамтиды: қолданба да, орнатылған luash тәуелділіктері де. Tarantool серверге RPM пакетінің тәуелділігі ретінде де келеді және біздің қызметіміз іске қосылуға дайын. Бұл systemd арқылы жасалады, бірақ алдымен кішкене конфигурация жазу керек. Кем дегенде, әрбір процестің URI мекенжайын көрсетіңіз. Мысал үшін үшеу жеткілікті.

$ sudo tee /etc/tarantool/conf.d/demo.yml <<CONFIG
myapp.router: {"advertise_uri": "localhost:3301", "http_port": 8080}
myapp.storage_A: {"advertise_uri": "localhost:3302", "http_enabled": False}
myapp.storage_B: {"advertise_uri": "localhost:3303", "http_enabled": False}
CONFIG

Бұл жерде қызықты нюанс бар. Тек екілік протокол портын көрсетудің орнына, біз процестің бүкіл жалпы мекенжайын, соның ішінде хост атауын көрсетеміз. Бұл кластерлік түйіндердің бір-бірімен қосылу жолын білуі үшін қажет. advertise_uri ретінде 0.0.0.0 пайдалану жаман идея, ол байланыстыру ұясы емес, жалпыға қолжетімді IP болуы керек. Онсыз ештеңе жұмыс істемейді, сондықтан Cartridge сізге дұрыс емес advertise_uri бар түйінді іске қосуға мүмкіндік бермейді.

Енді конфигурация дайын, сіз процестерді бастауға болады. Әдеттегі жүйелік блок бірден көп процесті бастауға мүмкіндік бермейтіндіктен, Картридждегі қолданбалар деп аталатындар арқылы орнатылады. келесідей жұмыс істейтін құрастырылған бірліктер:

$ sudo systemctl start myapp@router
$ sudo systemctl start myapp@storage_A
$ sudo systemctl start myapp@storage_B

Конфигурацияда біз Картридж веб-интерфейске қызмет көрсететін HTTP портын көрсеттік - 8080. Оған өтіп, көрейік:

Біз процестер жұмыс істеп тұрғанымен, әлі конфигурацияланбағанын көреміз. Картридж кімнің кіммен қайталау керектігін әлі білмейді және өз бетінше шешім қабылдай алмайды, сондықтан ол біздің әрекеттерімізді күтуде. Ал бізде көп таңдау жоқ: жаңа кластердің өмірі бірінші түйіннің конфигурациясынан басталады. Содан кейін қалғандарын кластерге қосамыз, оларға рөлдерді тағайындаймыз және осы кезде орналастыру сәтті аяқталды деп санауға болады.

Сүйікті сусынның бір стаканын құйып, ұзақ жұмыс аптасынан кейін демалыңыз. Қолданбаны басқаруға болады.