როგორ გადავიდეთ ღრუბელში ორ საათში Kubernetes-ის და ავტომატიზაციის წყალობით

URUS კომპანიამ სცადა Kubernetes სხვადასხვა ფორმით: დამოუკიდებელი განლაგება შიშველ მეტალზე, Google Cloud-ში და შემდეგ გადაიტანა თავისი პლატფორმა Mail.ru Cloud Solutions (MCS) ღრუბელში. იგორ შიშკინი ყვება, თუ როგორ აირჩიეს ახალი ღრუბლოვანი პროვაიდერი და როგორ მოახერხეს მასზე მიგრაცია რეკორდულ ორ საათში (t3ran), სისტემის უფროსი ადმინისტრატორი URUS-ში.

რას აკეთებს URUS?

ურბანული გარემოს ხარისხის გაუმჯობესების მრავალი გზა არსებობს და ერთ-ერთია მისი გარემოსდაცვითი კეთილგანწყობა. სწორედ ამაზე მუშაობს კომპანია URUS - Smart Digital Services. აქ ისინი ახორციელებენ გადაწყვეტილებებს, რომლებიც ეხმარება საწარმოებს აკონტროლონ მნიშვნელოვანი გარემოსდაცვითი ინდიკატორები და შეამცირონ მათი უარყოფითი გავლენა გარემოზე. სენსორები აგროვებენ მონაცემებს ჰაერის შემადგენლობის, ხმაურის დონის და სხვა პარამეტრების შესახებ და შემდეგ აგზავნიან მათ ერთიან URUS-Ekomon პლატფორმაზე ანალიზისა და რეკომენდაციების მისაღებად.

როგორ მუშაობს URUS შიგნიდან

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

H2S კონცენტრაციის მონიტორინგის გრაფიკი გვიჩვენებს რეგულარულ ღამის ემისიებს ახლომდებარე ქარხნიდან

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

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

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

როგორ ვინახავთ მონაცემებს. კუბერნეტის ამბავი შიშველ მეტალზე

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

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

თავად Kubernetes-ის დაუფლების პარალელურად, ჩვენ ასევე შევისწავლეთ მონაცემების შენახვის გზები, ხოლო მთელი ჩვენი საცავი Kubernetes-ში შევინარჩუნეთ საკუთარ აპარატურაზე, მივიღეთ შესანიშნავი ექსპერტიზა. ყველაფერი, რაც მაშინ ვცხოვრობდით Kubernetes-ზე: სრული საცავი, მონიტორინგის სისტემა, CI/CD. Kubernetes ჩვენთვის ერთ-ერთ პლატფორმად იქცა.

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

Google Cloud Platform-ზე გადასვლა დროებითი გამოსავალია

ჩვენ მივხვდით, რომ ეს არ შეიძლებოდა გაგრძელდეს და გადავიტანეთ ჩვენი მონაცემები შიშველი ლითონისგან Google Cloud Platform-ზე. სინამდვილეში, იმ დროს რუსული კომპანიისთვის ბევრი საინტერესო ვარიანტი არ არსებობდა: Google Cloud Platform-ის გარდა, მხოლოდ ამაზონი გვთავაზობდა მსგავს სერვისს, მაგრამ ჩვენ მაინც გადავწყვიტეთ Google-ის გადაწყვეტა. მაშინ ეს უფრო ეკონომიკურად მომგებიანი გვეჩვენებოდა, უფრო ახლოს იყო Upstream-თან, რომ აღარაფერი ვთქვათ იმ ფაქტზე, რომ თავად Google არის ერთგვარი PoC Kubernetes წარმოებაში.

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

როგორ ვნახეთ იდეალური ღრუბლოვანი სერვისი

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

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

იმ დროს რუსეთში Kubernetes aaS-ის რამდენიმე პროვაიდერი იყო და პროვაიდერის არჩევისას ჩვენთვის მნიშვნელოვანი იყო ჩვენი პრიორიტეტების კომპრომისზე უარის თქმა. Mail.ru Cloud Solutions-ის გუნდმა, რომელთანაც დავიწყეთ მუშაობა და ახლაც ვთანამშრომლობთ, მოგვაწოდეს სრულად ავტომატიზირებული სერვისი, API მხარდაჭერით და მოსახერხებელი მართვის პანელი, რომელიც მოიცავს Horizon-ს - მისი საშუალებით ჩვენ შეგვიძლია სწრაფად გავზარდოთ კვანძების თვითნებური რაოდენობა.

როგორ მოვახერხეთ MCS-ში მიგრაცია ორ საათში

ასეთ ნაბიჯებში ბევრ კომპანიას ექმნება სირთულეები და წარუმატებლობები, მაგრამ ჩვენს შემთხვევაში არ ყოფილა. ჩვენ გაგვიმართლა: ვინაიდან მიგრაციის დაწყებამდე უკვე Kubernetes-ზე ვმუშაობდით, ჩვენ უბრალოდ გავასწორეთ სამი ფაილი და გავუშვით ჩვენი სერვისები ახალ ღრუბლოვან პლატფორმაზე, MCS. შეგახსენებთ, რომ იმ დროისთვის ჩვენ საბოლოოდ დავტოვეთ შიშველი მეტალი და ვცხოვრობდით Google Cloud Platform-ზე. მაშასადამე, მოძრაობას დასჭირდა არაუმეტეს ორი საათისა, პლუს ცოტა მეტი დრო (დაახლოებით ერთი საათი) დაიხარჯა ჩვენი მოწყობილობებიდან მონაცემების კოპირებაზე. მაშინ ჩვენ უკვე ვიყენებდით Spinnaker-ს (მრავალ ღრუბლოვანი CD სერვისი უწყვეტი მიწოდებისთვის). ჩვენ ასევე სწრაფად დავამატეთ ის ახალ კლასტერში და ჩვეულ რეჟიმში გავაგრძელეთ მუშაობა.

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

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

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

როგორ ვხედავთ მომავალში ღრუბლებთან მუშაობას

ახლა ჩვენი მუშაობა მჭიდროდ არის მიბმული Kubernetes-თან და ის სრულიად გვერგება ინფრასტრუქტურული ამოცანების თვალსაზრისით. ამიტომ, მისგან არსად მიგრაციას არ ვგეგმავთ, თუმცა მუდმივად ვნერგავთ ახალ პრაქტიკებს და სერვისებს რუტინული ამოცანების გასამარტივებლად და ახლის ავტომატიზაციისთვის, სერვისების სტაბილურობისა და საიმედოობის გაზრდის მიზნით... ახლა ვიწყებთ Chaos Monkey სერვისს (კონკრეტულად , ვიყენებთ chaoskube-ს, მაგრამ ეს არ ცვლის კონცეფციას: ), რომელიც თავდაპირველად შეიქმნა Netflix-ის მიერ. Chaos Monkey აკეთებს ერთ მარტივ რამეს: ის შლის შემთხვევით Kubernetes pod-ს შემთხვევით დროს. ეს აუცილებელია იმისათვის, რომ ჩვენმა სერვისმა ნორმალურად იცხოვროს n–1 შემთხვევების რაოდენობით, ამიტომ ჩვენ ვავარჯიშებთ თავს მზადყოფნაში ნებისმიერი პრობლემისთვის.

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

რა ვისწავლეთ ღრუბლოვან სერვისებთან მუშაობისგან

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

წყარო: www.habr.com