Tarantool Cartridge: Lua backend sharding სამ ხაზში

Mail.ru Group-ში გვაქვს Tarantool - ეს არის აპლიკაციის სერვერი ლუაში, რომელიც ასევე მოქმედებს როგორც მონაცემთა ბაზა (ან პირიქით?). ეს არის სწრაფი და მაგარი, მაგრამ ერთი სერვერის შესაძლებლობები ჯერ კიდევ არ არის შეუზღუდავი. ვერტიკალური სკალირება ასევე არ არის პანაცეა, ამიტომ Tarantool-ს აქვს ინსტრუმენტები ჰორიზონტალური სკალაციისთვის - vshard მოდული [1]. ის საშუალებას გაძლევთ დაშალოთ მონაცემები რამდენიმე სერვერზე, მაგრამ თქვენ უნდა შეაერთოთ ისინი, რომ დააყენოთ და დაურთოთ ბიზნეს ლოგიკა.

კარგი ამბავი: ჩვენ მოვაგროვეთ რამდენიმე დიდი კადრი (მაგ [2], [3]) და შექმნა სხვა ჩარჩო, რომელიც მნიშვნელოვნად გაამარტივებს ამ პრობლემის გადაჭრას.

ტარანტულის ვაზნა არის ახალი ჩარჩო რთული განაწილებული სისტემების განვითარებისთვის. ეს საშუალებას გაძლევთ ფოკუსირება მოახდინოთ ბიზნეს ლოგიკის დაწერაზე, ინფრასტრუქტურული პრობლემების გადაჭრის ნაცვლად. ჭრილის ქვემოთ მე გეტყვით, როგორ მუშაობს ეს ჩარჩო და როგორ უნდა დაწეროთ განაწილებული სერვისები მისი გამოყენებით.

კონკრეტულად რა პრობლემაა?

ტარანტულა გვაქვს, ვშარდი გვაქვს - მეტი რა გინდა?

პირველ რიგში, ეს არის მოხერხებულობის საკითხი. 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/

ეს არის git საცავი მზა "Hello, World!" განაცხადი. შევეცადოთ მისი დაუყონებლივ გაშვება, ადრე დაყენებული დამოკიდებულებების (მათ შორის თავად ჩარჩოს ჩათვლით):

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

ასე რომ, ჩვენ გვაქვს ერთი კვანძი, რომელიც მუშაობს მომავალი გახეხილი აპლიკაციისთვის. ცნობისმოყვარე უბრალო ადამიანს შეუძლია დაუყოვნებლივ გახსნას ვებ ინტერფეისი, დააკონფიგურიროს ერთი კვანძის კლასტერი მაუსით და დატკბეს შედეგით, მაგრამ ჯერ ნაადრევია გახარება. ჯერჯერობით, აპლიკაცია ვერაფერს აკეთებს სასარგებლო, ამიტომ მოგვიანებით გეტყვით განლაგების შესახებ, მაგრამ ახლა დროა დაწეროთ კოდი.

აპლიკაციის შემუშავება

წარმოიდგინეთ, ჩვენ ვგეგმავთ პროექტს, რომელმაც უნდა მიიღოს მონაცემები, შეინახოს და შეადგინოს ანგარიში დღეში ერთხელ.

ვიწყებთ დიაგრამის დახატვას და მასზე ვათავსებთ სამ კომპონენტს: კარიბჭე, საცავი და გრაფიკი. ჩვენ ვმუშაობთ არქიტექტურაზე შემდგომში. ვინაიდან ჩვენ ვიყენებთ vshard-ს როგორც მეხსიერებას, ჩვენ ვამატებთ vshard-როუტერს და vshard-storage-ს სქემას. არც კარიბჭე და არც გრაფიკი პირდაპირ არ შედიან საცავზე; სწორედ ამისთვის არის როუტერი, რისთვისაც ის შეიქმნა.

ეს დიაგრამა ჯერ კიდევ არ წარმოადგენს ზუსტად იმას, რასაც ჩვენ ავაშენებთ პროექტში, რადგან კომპონენტები აბსტრაქტულად გამოიყურება. ჩვენ ჯერ კიდევ უნდა ვნახოთ, როგორ იქნება ეს დაპროექტებული რეალურ Tarantool-ზე - მოდით დავაჯგუფოთ ჩვენი კომპონენტები პროცესის მიხედვით.

აზრი არ აქვს vshard-როუტერის და კარიბჭის ცალკეულ ინსტანციებზე შენარჩუნებას. რატომ გვჭირდება კიდევ ერთხელ სერფინგი ქსელში, თუ ეს უკვე როუტერის პასუხისმგებლობაა? ისინი უნდა განხორციელდეს იმავე პროცესში. ანუ, როგორც gateway, ასევე vshard.router.cfg ინიციალიზებულია ერთ პროცესში, და მიეცით მათ ლოკალური ინტერაქცია.

დიზაინის ეტაპზე მოსახერხებელი იყო სამ კომპონენტთან მუშაობა, მაგრამ მე, როგორც დეველოპერი, კოდის წერისას, არ მინდა ვიფიქრო Tarnatool-ის სამი ინსტანციის გაშვებაზე. უნდა ჩავატარო ტესტები და შევამოწმო, რომ სწორად დავწერე gateway. ან იქნებ მსურს ჩემი კოლეგებისთვის მახასიათებლის დემონსტრირება. რატომ უნდა გავიარო სამი ასლის განთავსება? ასე დაიბადა როლების კონცეფცია. როლი არის ჩვეულებრივი 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.

როლებს შეუძლიათ ერთმანეთთან ურთიერთობა. ჩვენ შეჩვეული ვართ ფუნქციის ზარების წერას Lua-ში, მაგრამ შეიძლება მოხდეს, რომ მოცემულ პროცესს არ ჰქონდეს ის როლი, რომელიც ჩვენ გვჭირდება. ქსელში ზარების გასაადვილებლად, ჩვენ ვიყენებთ rpc (დისტანციური პროცედურის ზარი) დამხმარე მოდულს, რომელიც აგებულია Tarantool-ში ჩაშენებული სტანდარტული netbox-ის საფუძველზე. ეს შეიძლება იყოს სასარგებლო, თუ, მაგალითად, თქვენს კარიბჭეს სურს პირდაპირ სთხოვოს განრიგს სამუშაოს შესრულება ახლავე, ვიდრე ერთი დღე დაელოდო.

კიდევ ერთი მნიშვნელოვანი პუნქტია შეცდომების ტოლერანტობის უზრუნველყოფა. კარტრიჯი იყენებს SWIM პროტოკოლს ჯანმრთელობის მონიტორინგისთვის [4]. მოკლედ, პროცესები უცვლიან ერთმანეთს "ჭორებს" UDP-ის საშუალებით - თითოეული პროცესი მეზობლებს უახლეს ამბებს ეუბნება და ისინი პასუხობენ. თუ მოულოდნელად პასუხი არ მოვიდა, ტარანტული იწყებს ეჭვს, რომ რაღაც არასწორია და გარკვეული პერიოდის შემდეგ ის იხსენებს სიკვდილს და იწყებს ყველას ამ ამბების შესახებ.

ამ პროტოკოლის საფუძველზე, კარტრიჯი აწყობს ავტომატური წარუმატებლობის დამუშავებას. თითოეული პროცესი აკონტროლებს მის გარემოს და თუ ლიდერი მოულოდნელად შეწყვეტს რეაგირებას, რეპლიკას შეუძლია მიიღოს მისი როლი და კარტრიჯი შესაბამისად აკონფიგურირებს გაშვებულ როლებს.

აქ ფრთხილად უნდა იყოთ, რადგან ხშირმა წინ და უკან გადართვამ შეიძლება გამოიწვიოს მონაცემთა კონფლიქტი რეპლიკაციის დროს. რა თქმა უნდა, თქვენ არ უნდა ჩართოთ ავტომატური უკმარისობა შემთხვევით. ნათლად უნდა გვესმოდეს რა ხდება და დარწმუნებული ვიყოთ, რომ რეპლიკაცია არ გატყდება ლიდერის აღდგენის და გვირგვინის დაბრუნების შემდეგ.

ამ ყველაფრიდან შეიძლება გქონდეთ განცდა, რომ როლები მიკროსერვისების მსგავსია. გარკვეული გაგებით, ისინი მხოლოდ ასეა, მხოლოდ როგორც მოდულები Tarantool პროცესებში. მაგრამ ასევე არსებობს მთელი რიგი ფუნდამენტური განსხვავებები. პირველ რიგში, პროექტის ყველა როლი უნდა ცხოვრობდეს იმავე კოდის ბაზაში. და Tarantool-ის ყველა პროცესი უნდა იყოს გაშვებული იმავე კოდის ბაზიდან, ისე, რომ არ იყოს ისეთი სიურპრიზები, როგორიც ჩვენ ვცდილობთ განლაგების ინიციალიზაციას, მაგრამ ის უბრალოდ არ არსებობს. ასევე, არ უნდა დაუშვათ განსხვავებები კოდის ვერსიებში, რადგან სისტემის ქცევა ასეთ სიტუაციაში ძალიან რთულია პროგნოზირება და გამართვა.

Docker-ისგან განსხვავებით, ჩვენ არ შეგვიძლია უბრალოდ ავიღოთ როლი "იმიჯი", გადავიტანოთ იგი სხვა მანქანაზე და გავუშვათ იქ. ჩვენი როლები არ არის ისეთი იზოლირებული, როგორც Docker კონტეინერები. ასევე, ჩვენ არ შეგვიძლია ორი იდენტური როლის შესრულება ერთ ინსტანციაზე. როლი ან არსებობს ან არ არსებობს; გარკვეული გაგებით, ეს არის სინგლი. და მესამე, როლები უნდა იყოს იგივე მთელი რეპლიკაციის ჯგუფში, რადგან წინააღმდეგ შემთხვევაში ეს იქნება აბსურდი - მონაცემები იგივეა, მაგრამ კონფიგურაცია განსხვავებულია.

განლაგების ინსტრუმენტები

მე დავპირდი, რომ მეჩვენებინა, თუ როგორ ეხმარება კარტრიჯი აპლიკაციების დანერგვას. სხვებისთვის ცხოვრების გასაადვილებლად, ჩარჩო პაკეტებს RPM პაკეტებს:

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

დაინსტალირებული პაკეტი შეიცავს თითქმის ყველაფერს, რაც გჭირდებათ: როგორც აპლიკაციას, ასევე დაყენებულ დამოკიდებულებებს. 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

აქ არის ერთი საინტერესო ნიუანსი. იმის ნაცვლად, რომ მიუთითოთ მხოლოდ ორობითი პროტოკოლის პორტი, ჩვენ ვაზუსტებთ პროცესის მთელ საჯარო მისამართს ჰოსტის სახელის ჩათვლით. ეს აუცილებელია იმისთვის, რომ კლასტერულმა კვანძებმა იცოდნენ როგორ დაუკავშირდნენ ერთმანეთს. ცუდი იდეაა გამოიყენოთ 0.0.0.0 advertise_uri მისამართად; ეს უნდა იყოს გარე IP მისამართი და არა სოკეტი. ამის გარეშე არაფერი იმუშავებს, ასე რომ კარტრიჯი უბრალოდ არ მოგცემთ საშუალებას გაუშვათ კვანძი არასწორი advertise_uri-ით.

ახლა, როდესაც კონფიგურაცია მზად არის, შეგიძლიათ დაიწყოთ პროცესები. ვინაიდან ჩვეულებრივი systemd ერთეული არ იძლევა ერთზე მეტი პროცესის დაწყების საშუალებას, კარტრიჯზე აპლიკაციები ინსტალირებულია ე.წ. ინსტანციური ერთეულები, რომლებიც მუშაობენ ასე:

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

კონფიგურაციაში დავაზუსტეთ HTTP პორტი, რომელზეც კარტრიჯი ემსახურება ვებ ინტერფეისს - 8080. მოდით გადავიდეთ მასზე და გადავხედოთ:

ჩვენ ვხედავთ, რომ მიუხედავად იმისა, რომ პროცესები მიმდინარეობს, ისინი ჯერ არ არის კონფიგურირებული. ვაზნამ ჯერ არ იცის ვინ ვისთან უნდა გაიმეოროს და გადაწყვეტილებას დამოუკიდებლად ვერ იღებს, ამიტომ ელოდება ჩვენს ქმედებებს. მაგრამ დიდი არჩევანი არ გვაქვს: ახალი კლასტერის სიცოცხლე იწყება პირველი კვანძის კონფიგურაციით. შემდეგ ჩვენ დავამატებთ დანარჩენებს კლასტერში, მივანიჭებთ მათ როლებს და ამ ეტაპზე განლაგება შეიძლება ჩაითვალოს წარმატებით დასრულებულად.

მოდით დავასხათ ერთი ჭიქა თქვენი საყვარელი სასმელი და დავისვენოთ ხანგრძლივი სამუშაო კვირის შემდეგ. აპლიკაციის გამოყენება შესაძლებელია.

შედეგები

როგორია შედეგები? სცადეთ, გამოიყენეთ იგი, დატოვეთ გამოხმაურება, შექმენით ბილეთები Github-ზე.

ლიტერატურა

[1] Tarantool » 2.2 » Reference » Rocks reference » Module vshard

[2] როგორ განვახორციელეთ Alfa-Bank-ის საინვესტიციო ბიზნესის ბირთვი Tarantool-ზე დაფუძნებული

[3] ახალი თაობის ბილინგის არქიტექტურა: ტრანსფორმაცია Tarantool-ზე გადასვლით

[4] SWIM - კასეტური მშენებლობის პროტოკოლი

[5] GitHub - tarantool/cartridge-cli

[6] GitHub - ტარანტული/კარტრიჯი

წყარო: www.habr.com