მონაცემთა ბაზები ცხოვრობს Kubernetes-ში?

რატომღაც, ისტორიულად, IT ინდუსტრია იყოფა ორ პირობით ბანაკად რაიმე მიზეზით: ისინი, ვინც არიან „მომხრენი“ და ისინი, ვინც არიან „წინააღმდეგები“. უფრო მეტიც, დავის საგანი შეიძლება იყოს სრულიად თვითნებური. რომელი ოპერაციული სისტემა უკეთესია: Win თუ Linux? Android ან iOS სმარტფონზე? ყველაფერი ღრუბლებში უნდა შეინახო თუ ცივ RAID საცავზე დააყენო და ხრახნები სეიფში ჩადო? აქვთ თუ არა PHP ადამიანებს უფლება ეძახიან პროგრამისტებს? ეს დავები, ზოგჯერ, ექსკლუზიურად ეგზისტენციალურ ხასიათს ატარებს და არ გააჩნია სხვა საფუძველი, გარდა სპორტული ინტერესისა.

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

და, როგორც ჩანს, ეს იქნება უბრალო დავა ერთი და იმავე მონეტის ორ მხარეს შორის. ისეთივე უაზრო და დაუნდობელი, როგორც მარადიული დაპირისპირება Win vs Linux-ს შორის, რომელშიც ადეკვატური ხალხი სადღაც შუაშია. მაგრამ კონტეინერიზაციის შემთხვევაში ყველაფერი ასე მარტივი არ არის. ჩვეულებრივ, ასეთ დავებში არ არის სწორი მხარე, მაგრამ მონაცემთა ბაზების შესანახად კონტეინერების „გამოყენების“ ან „გამოუყენებლობის“ შემთხვევაში, ყველაფერი თავდაყირა დგება. რადგან გარკვეული გაგებით, ამ მიდგომის ორივე მომხრეც და მოწინააღმდეგეებიც მართლები არიან.

Ნათელი მხარე

Light Side-ის არგუმენტი შეიძლება მოკლედ იყოს აღწერილი ერთი ფრაზით: "გამარჯობა, 2k19 არის ფანჯრის მიღმა!" ეს, რა თქმა უნდა, პოპულიზმივით ჟღერს, მაგრამ თუ სიტუაციას დეტალურად ჩავუღრმავდებით, ამას თავისი უპირატესობები აქვს. მოდით, ახლავე დავახარისხოთ ისინი.

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

მართალია, მონაცემები. ნებისმიერი პროექტის გული მისი მონაცემებია: ეს შეიძლება იყოს ტიპიური DBMS - MySQL, Postgre, MongoDB, ან საძიებლად გამოყენებული საცავი (ElasticSearch), გასაღების მნიშვნელობების შენახვა ქეშისთვის - მაგალითად, redis და ა.შ. ამჟამად ჩვენ არ ვართ ჩვენ ვისაუბრებთ არასწორი backend-ის განხორციელების ვარიანტებზე, როდესაც მონაცემთა ბაზის ავარია ხდება ცუდად დაწერილი მოთხოვნების გამო, და ამის ნაცვლად ვისაუბრებთ იმაზე, რომ უზრუნველყოს ამ მონაცემთა ბაზის შეცდომის ტოლერანტობა კლიენტის დატვირთვის ქვეშ. ყოველივე ამის შემდეგ, როდესაც ჩვენ ვაქცევთ ჩვენს აპლიკაციას კონტეინერში და ვაძლევთ მას თავისუფლად მასშტაბის საშუალებას ნებისმიერი შემომავალი მოთხოვნის დასამუშავებლად, ეს ბუნებრივად ზრდის მონაცემთა ბაზაზე დატვირთვას.

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

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

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

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

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

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

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

კონტეინერიზაცია და, ფაქტობრივად, თქვენი პროექტის მონაცემთა ბაზის განაწილებული ფიზიკური ტოპოლოგია დაგეხმარებათ თავიდან აიცილოთ ასეთი გადამოწმების მომენტები. არ ენდობით ახალბედას? ᲙᲐᲠᲒᲘ! მოდით მივცეთ მას საკუთარი კლასტერი სამუშაოდ და მონაცემთა ბაზის გათიშვა სხვა კლასტერებისგან - სინქრონიზაცია მხოლოდ ხელით დაჭერით და ორი კლავიშის სინქრონული როტაციით (ერთი გუნდის ლიდერისთვის, მეორე ადმინისტრატორისთვის). და ყველა ბედნიერია.

ახლა კი დროა გადავიდეთ მონაცემთა ბაზის კლასტერიზაციის მოწინააღმდეგეებად.

Ბნელი მხარე

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

ვეთანხმები, პროექტები, რომლებსაც ნამდვილად სჭირდებათ ბაზა კონტეინერში, შეიძლება ერთი ხელის თითით დაითვალოს არა საუკეთესო საღარავი მანქანის ოპერატორი. უმეტესწილად, თვით k8-ების ან Docker Swarm-ის გამოყენებაც კი ზედმეტია - საკმაოდ ხშირად ამ ინსტრუმენტებს მიმართავენ ტექნოლოგიების ზოგადი აჟიოტაჟის და სქესის პიროვნების „ყოვლისშემძლე“ დამოკიდებულების გამო, რათა ყველაფერი გადაიტანონ. ღრუბლები და კონტეინერები. ისე, იმიტომ რომ ახლა მოდაშია და ამას ყველა აკეთებს.

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

ზოგადად, არსებობს მოსაზრება, რომ დოკერ/კუბის მაფია სულელურად ანადგურებს კლიენტებს, რომლებიც ამ ინფრასტრუქტურის საკითხებს აუთსორსს უწევენ. ყოველივე ამის შემდეგ, კლასტერებთან მუშაობისთვის, ჩვენ გვჭირდება ინჟინრები, რომლებსაც ამის უნარი აქვთ და ზოგადად ესმით განხორციელებული გადაწყვეტის არქიტექტურა. ჩვენ ერთხელ უკვე აღვწერეთ ჩვენი საქმე რესპუბლიკის პუბლიკაციასთან - იქ მოვამზადეთ კლიენტის გუნდი კუბერნეტისის რეალობაში მუშაობისთვის და ყველა კმაყოფილი დარჩა. და წესიერი იყო. ხშირად, k8s „განმახორციელებლები“ ​​მძევლად იღებენ კლიენტის ინფრასტრუქტურას - რადგან ახლა მხოლოდ მათ ესმით, როგორ მუშაობს იქ ყველაფერი; კლიენტის მხარეს არ არიან სპეციალისტები.

ახლა წარმოიდგინეთ, რომ ამ გზით ჩვენ ვაწარმოებთ არა მხოლოდ ვებ სერვერის ნაწილს, არამედ მონაცემთა ბაზის შენარჩუნებას. ჩვენ ვთქვით, რომ BD არის გული, ხოლო გულის დაკარგვა ფატალურია ნებისმიერი ცოცხალი ორგანიზმისთვის. მოკლედ, პერსპექტივები არ არის საუკეთესო. ასე რომ, ჰიპ კუბერნეტისის ნაცვლად, ბევრმა პროექტმა უბრალოდ არ უნდა შეაწუხოს AWS-ის ნორმალური ტარიფი, რომელიც გადაჭრის ყველა პრობლემას მათ საიტზე/პროექტზე დატვირთვასთან დაკავშირებით. მაგრამ AWS აღარ არის მოდური და ჩვენება ფულზე მეტი ღირს - სამწუხაროდ, IT გარემოშიც.

ᲙᲐᲠᲒᲘ. შესაძლოა, პროექტს ნამდვილად სჭირდება კლასტერირება, მაგრამ თუ ყველაფერი ნათელია მოქალაქეობის არმქონე აპლიკაციებით, მაშინ როგორ შეგვიძლია მოვაწყოთ ღირსეული ქსელური კავშირი კლასტერული მონაცემთა ბაზისთვის?

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

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

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

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

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

გამონაკლისის ნაცვლად

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

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

წყარო: www.habr.com