QCon კონფერენცია. ქაოსის დაუფლება: Netflix-ის გზამკვლევი მიკროსერვისებისთვის. ნაწილი 4

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

QCon კონფერენცია. ქაოსის დაუფლება: Netflix-ის გზამკვლევი მიკროსერვისებისთვის. ნაწილი 1
QCon კონფერენცია. ქაოსის დაუფლება: Netflix-ის გზამკვლევი მიკროსერვისებისთვის. ნაწილი 2
QCon კონფერენცია. ქაოსის დაუფლება: Netflix-ის გზამკვლევი მიკროსერვისებისთვის. ნაწილი 3

ოპერაციული დრიფტისგან განსხვავებით, სერვისის ინტერნაციონალიზაციისთვის ახალი ენების დანერგვა და ახალი ტექნოლოგიები, როგორიცაა კონტეინერები, არის შეგნებული გადაწყვეტილებები გარემოსთვის ახალი სირთულის დასამატებლად. ჩემი ოპერაციების გუნდი სტანდარტიზებული იყო Netflix-ის საუკეთესო ტექნოლოგიების საგზაო რუკაზე, რომელიც დაფუძნებული იყო Java-სა და EC2-ზე დაფუძნებულ წინასწარ განსაზღვრულ საუკეთესო პრაქტიკაში, მაგრამ როგორც ბიზნესი იზრდებოდა, დეველოპერებმა დაიწყეს ახალი კომპონენტების დამატება, როგორიცაა Python, Ruby, Node-JS და Docker.

მე ძალიან ვამაყობ, რომ ჩვენ ვიყავით პირველი, ვინც მხარს ვუჭერდით ჩვენს პროდუქტს მშვენივრად იმუშაოს მომხმარებელთა საჩივრების მოლოდინში. ყველაფერი საკმაოდ მარტივად დაიწყო - ჩვენ გვქონდა ოპერაციული პროგრამები Python-ში და რამდენიმე back-office აპლიკაცია Ruby-ში, მაგრამ ყველაფერი უფრო საინტერესო გახდა, როდესაც ჩვენმა ვებ დეველოპერებმა განაცხადეს, რომ აპირებდნენ JVM-ის გათიშვას და აპირებდნენ ინტერნეტის გადატანას. განაცხადი Node პროგრამულ პლატფორმაზე.js. Docker-ის დანერგვის შემდეგ, ყველაფერი გაცილებით რთული გახდა. ჩვენ მივყვებოდით ლოგიკას და ის ტექნოლოგიები, რომლებიც ჩვენ გამოვიმუშავეთ, რეალობად იქცა, როდესაც ჩვენ განვახორციელეთ ისინი მომხმარებლებისთვის, რადგან მათ დიდი აზრი ჰქონდათ. მე გეტყვით, რატომ არის ასე.

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

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

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

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

• პროდუქტიულობის ინსტრუმენტები. ახალი ტექნოლოგიების მართვა მოითხოვდა ახალ ინსტრუმენტებს, რადგან UI გუნდს, რომელიც იყენებდა ძალიან კარგ სკრიპტებს ეფექტური მოდელის შესაქმნელად, არ სჭირდებოდა დიდი დროის დახარჯვა ინფრასტრუქტურის მართვაზე, მათ მხოლოდ სკრიპტების დაწერა და მათი ფუნქციონირების შემოწმება მოუწიათ.
  Opportunity Insight და Sorting - ძირითადი მაგალითია ახალი ინსტრუმენტები, რომლებიც საჭიროა დრაივერის მუშაობის შესახებ ინფორმაციის გამოსავლენად. საჭირო იყო იმის ცოდნა, თუ რამდენად იყო დაკავებული პროცესორი, როგორ იყენებდნენ მეხსიერებას და ამ ინფორმაციის შეგროვებას სხვადასხვა ინსტრუმენტები სჭირდებოდა.
• საბაზისო სურათების ფრაგმენტაცია - მარტივი ბაზის AMI გახდა უფრო ფრაგმენტული და სპეციალიზებული.
• კვანძის მართვა. არ არის ხელმისაწვდომი თაროზე არსებული არქიტექტურა ან ტექნოლოგია, რომელიც საშუალებას მოგცემთ მართოთ კვანძები ღრუბელში, ამიტომ ჩვენ ავაშენეთ Titus, კონტეინერის მართვის პლატფორმა, რომელიც უზრუნველყოფს კონტეინერების მასშტაბურ და საიმედო განლაგებას და ღრუბლის ინტეგრაციას Amazon AWS-თან.
• ბიბლიოთეკის ან პლატფორმის დუბლირება. ახალი ტექნოლოგიების უზრუნველყოფა პლატფორმის იგივე ძირითადი ფუნქციონირებით მოითხოვდა მის დუბლირებას ღრუბელზე დაფუძნებულ Node.js დეველოპერის ინსტრუმენტებში.
• სწავლის მრუდი და ინდუსტრიული გამოცდილება. ახალი ტექნოლოგიების დანერგვა აუცილებლად ქმნის ახალ გამოწვევებს, რომელთა გადალახვა და სწავლა უნდა მოხდეს.

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

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

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

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

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

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

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

საუბრის დასასრულს მოკლედ ვისაუბრებ Netflix-ის ორგანიზაციასა და არქიტექტურაზე. თავიდანვე გვქონდა სქემა სახელწოდებით Electronic Delivery, რომელიც იყო NRDP 1.x მედია ნაკადის პირველი ვერსია. ტერმინი "backstream" შეიძლება გამოყენებულ იქნას აქ, რადგან თავდაპირველად მომხმარებელს შეეძლო მხოლოდ კონტენტის ჩამოტვირთვა მოწყობილობაზე მოგვიანებით დასაკრავად. Netflix-ის პირველი ციფრული მიწოდების პლატფორმა, ჯერ კიდევ 2009 წელს, ასე გამოიყურებოდა.

მომხმარებლის მოწყობილობა შეიცავდა Netflix აპლიკაციას, რომელიც შედგებოდა UI ინტერფეისისგან, უსაფრთხოების მოდულებისგან, სერვისის აქტივაციისა და დაკვრისგან, რომელიც დაფუძნებულია NRDP პლატფორმაზე - Netflix Ready Device Platform.

იმ დროს მომხმარებლის ინტერფეისი ძალიან მარტივი იყო. ის შეიცავდა იმას, რასაც Queque Reader ერქვა და მომხმარებელი მიდიოდა საიტზე Queque-ში რაიმეს დასამატებლად და შემდეგ ნახავდა დამატებულ კონტენტს თავის მოწყობილობაზე. დადებითი ის იყო, რომ ფრონტ-ენდის გუნდი და უკანა გუნდი ეკუთვნოდა იმავე Electronic Delivery ორგანიზაციას და ჰქონდათ მჭიდრო სამუშაო ურთიერთობა. payload შეიქმნა XML-ის საფუძველზე. ამავდროულად, შეიქმნა Netflix API DVD ბიზნესისთვის, რომელიც წაახალისებდა მესამე მხარის აპლიკაციებს, მიემართათ ტრაფიკი ჩვენს სერვისზე.

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

გადასვლის პრობლემა იყო ფრაგმენტაცია, რადგან ახლა ჩვენი სისტემა ამუშავებდა ორ სერვისს, რომელიც ეფუძნება მოქმედების სრულიად განსხვავებულ პრინციპებს - ერთი Rest, JSON და OAuth, მეორე RPC, XML და მომხმარებლის უსაფრთხოების მექანიზმი, რომელიც დაფუძნებულია NTBA ტოკენ სისტემაზე. ეს იყო პირველი ჰიბრიდული არქიტექტურა.

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

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

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

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

ცოტა რეკლამა

გმადლობთ, რომ დარჩით ჩვენთან. მოგწონთ ჩვენი სტატიები? გსურთ ნახოთ უფრო საინტერესო შინაარსი? მხარი დაგვიჭირეთ შეკვეთის განთავსებით ან მეგობრებისთვის რეკომენდაციით, ღრუბელი VPS დეველოპერებისთვის 4.99 დოლარიდან, საწყისი დონის სერვერების უნიკალური ანალოგი, რომელიც ჩვენ მიერ გამოგონილია თქვენთვის: მთელი სიმართლე VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps 19$-დან ან როგორ გავაზიარო სერვერი? (ხელმისაწვდომია RAID1 და RAID10-ით, 24 ბირთვამდე და 40 გბ-მდე DDR4).

Dell R730xd 2-ჯერ იაფია Equinix Tier IV მონაცემთა ცენტრში ამსტერდამში? Მხოლოდ აქ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ტელევიზორი $199-დან ნიდერლანდებში! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99-დან! Წაიკითხო რაღაცის შესახებ როგორ ავაშენოთ ინფრასტრუქტურის კორპუსი. კლასი Dell R730xd E5-2650 v4 სერვერების გამოყენებით 9000 ევროს ღირებულების პენი?

წყარო: www.habr.com