ღრუბლოვანი სერვისის შექმნის ისტორია, კიბერპანკის არომატით

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

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

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

კეთილი იყოს თქვენი მობრძანება კატაში.

დასაწყისი მოგზაურობა

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

ასევე იყო მთელი რიგი მოთხოვნები:

• სერვისს სჭირდება მოსახერხებელი პირადი ანგარიში;
• პლატფორმა უნდა იყოს ინტეგრირებული არსებულ ბილინგის სისტემაში;
• პროგრამული უზრუნველყოფა და აპარატურა: OpenStack + ვოლფრამის ქსოვილი (Open Contrail), რომლის „მოხარშვა“ ჩვენმა ინჟინერებმა საკმაოდ კარგად ისწავლეს.

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

• Python + Flask + Swagger + SQLAlchemy - სრულიად სტანდარტული Python ნაკრები;
• Vue.js ფრონტენტისთვის;
• ჩვენ გადავწყვიტეთ გაგვეკეთებინა ურთიერთქმედება კომპონენტებსა და სერვისებს შორის Celery-ის გამოყენებით AMQP-ზე.

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

მაშ ასე, დავიწყოთ ჩვენი გაცნობა.

Silent Bill - ბილინგი

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

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

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

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

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

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

კიდევ ერთი პრობლემა სიჩუმეა.

ბილი ჩუმად პასუხობს "Ok" ზოგიერთ API მოთხოვნას. ასე იყო, მაგალითად, როცა ტესტის დროს ვახორციელებდით დაპირებული გადახდების გადახდას (დაწვრილებით ამის შესახებ მოგვიანებით). მოთხოვნები შესრულდა სწორად და ჩვენ ვერ ვნახეთ შეცდომები.

სისტემასთან მუშაობისას UI-ის მეშვეობით მომიწია ჟურნალების შესწავლა. გაირკვა, რომ თავად ბილინგი ასრულებს მსგავს მოთხოვნებს, ცვლის ფარგლებს კონკრეტულ მომხმარებელზე, მაგალითად, ადმინისტრატორზე, გადასცემს მას su პარამეტრში.

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

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

• დაუსაბუთებელი „ფუნქციები“, რომლებიც ასე თუ ისე იმოქმედა ჩვენზე;
• დახურული წყარო (ბილინგი იწერება C++-ში), შედეგად - შეუძლებელია 1 პრობლემის გადაჭრა სხვაგვარად, გარდა „ცდისა და შეცდომისა“.

საბედნიეროდ, პროდუქტს აქვს საკმაოდ ვრცელი API და ჩვენ გვაქვს ინტეგრირებული შემდეგი ქვესისტემები ჩვენს პირად ანგარიშში:

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

გასეირნება ვოლფრამის ველებში - ვოლფრამის ქსოვილი

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

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

სისტემა ინტეგრირებულია OpenStack-თან (განხილულია ქვემოთ) Neutron მოდულის მეშვეობით.

OpenStack სერვისების ურთიერთქმედება.

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

პირველი ასე გამოიყურებოდა: ბრძანებები, რომლებიც მოითხოვდნენ დიდი რაოდენობით მონაცემების გატანას ინსტანციის კონსოლში SSH-ის საშუალებით დაკავშირებისას, უბრალოდ "გათიშეს" კავშირი, ხოლო VNC-ის საშუალებით ყველაფერი სწორად მუშაობდა.

მათთვის, ვინც არ იცნობს პრობლემას, ის საკმაოდ სასაცილოდ გამოიყურება: ls /root მუშაობს სწორად, ხოლო, მაგალითად, ზედა "იყინება" მთლიანად. საბედნიეროდ, მსგავსი პრობლემები ადრეც გვქონია. ეს გადაწყდა MTU-ის დარეგულირებით მარშრუტზე გამოთვლითი კვანძებიდან მარშრუტიზატორებამდე. სხვათა შორის, ეს არ არის TF პრობლემა.

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

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

Silicon Lifeforms - OpenStack

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

OpenStack არის ჩვენი პლატფორმის ბირთვი.

OpenStack-ს აქვს რამდენიმე ქვესისტემა, რომელთაგან ამჟამად ყველაზე აქტიურად ვიყენებთ Nova-ს, Glance-ს და Cinder-ს. თითოეულ მათგანს აქვს საკუთარი API. Nova პასუხისმგებელია გამოთვლით რესურსებზე და ინსტანციების შექმნაზე, Cinder პასუხისმგებელია მოცულობებისა და მათი სნეპშოტების მართვაზე, Glance არის გამოსახულების სერვისი, რომელიც მართავს OS შაბლონებს და მათზე მეტაინფორმაციას.

თითოეული სერვისი მუშაობს კონტეინერში და შეტყობინების ბროკერი არის „თეთრი კურდღელი“ - RabbitMQ.

ამ სისტემამ მოგვცა ყველაზე მოულოდნელი უბედურება.

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

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

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

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

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

OpenStack არის სისტემების საკმაოდ რთული ნაკრები თავისი ურთიერთქმედების ლოგიკით და მორთული API. ჩვენ გვეხმარება საკმაოდ დეტალური დოკუმენტაცია და, რა თქმა უნდა, საცდელი და შეცდომა (სად ვიქნებოდით მის გარეშე).

საცდელი გაშვება

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

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

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

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

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

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

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

გაგრძელება იქნება

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

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

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

ჩვენ ახლახან გავუშვით სერვისი.
თქვენ შეგიძლიათ გაიგოთ ყველა დეტალი ჩვენს საიტზე ონლაინი.

CLO განვითარების გუნდი

სასარგებლო ბმულები

OpenStack

• https://docs.openstack.org/nova/latest/
• https://docs.openstack.org/keystone/latest/
• https://docs.openstack.org/cinder/latest/
• https://docs.openstack.org/glance/latest/

ვოლფრამის ქსოვილი

• http://docs.tungsten.io/en/latest/user/getting-started/index.html
• https://www.juniper.net/documentation/en_US/contrail-cloud10.0/topics/concept/contrail-cloud-openstack-integration-overview.html

წყარო: www.habr.com