un: პროქსიებისა და ორიგინების გეომეტრია

un

სტუმარი

1 / ?

კვანძები, წიბოები, მიმართულებები

მოთხოვნა როგორც გრაფზე სეირნობა

ყველა კომპონენტი, რომელსაც მოთხოვნა ეხება, არის კვანძი: კლიენტი, DNS რეზოლვერი, CDN-ის ეჯი, რევერს პროქსი, ბეკენდის რეპლიკა, მონაცემთა ბაზა, ქეში.

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

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

რატომ არის მნიშვნელოვანი? როგორც კი გრაფს დახატავ, თვისებები თავისთავად გამოჩნდება, რომლებიც კოდში უხილავია:

- ჰოპების რაოდენობა (Hop count): ბილიკში არსებული კიდეების რაოდენობა. ყოველი ჰოპი ამატებს ლატენტობას (ქსელის რაუნდ ტრიპი + 노დის დამუშავება). ნაკლები ჰოპი = ლატენტობის დაბალი ზღვარი.

- შემავალი ხარისხი (In-degree): რამდენი კიდე მიუთითებს კვანძში. მაღალი შემავალი ხარისხი ნიშნავს, რომ კვანძი ბევრი წყაროდან იღებს მოთხოვნებს და უნდა გააფართოვოს ან დაიცვას თავი.

- გამავალი ხარისხი (Out-degree): რამდენი კიდე გამოდის კვანძიდან. მაღალი გამავალი ხარისხი ნიშნავს, რომ კვანძი დამოკიდებულია ბევრ ქვედა დონის სერვისზე და აქვს ბევრი გზა, რომ გაფუჭდეს.

- ჭრელი კვანძი (Cut vertex): ერთადერთი კვანძი, რომლის ამოღებაც გრაფს ანაწევრებს. რევერსული პროქსი პარტნიორის გარეშე არის ჭრელი კვანძი; მისი ამოღება ყველა წვდომას აუქმებს მის წყაროებთან.

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

დახატეთ (ან ტექსტურად აღწერეთ) მოთხოვნის გრაფი შემდეგი სისტემისთვის: client browser -> CDN edge -> reverse proxy -> backend replica -> database. დათვალეთ ჰოპები. ამოიცანით ჭრელი კვანძები. იწინასწარმეტყველეთ ერთი ოპერაციული შედეგი იმისა, რომ ერთმანეთის მიყოლებით გაქვთ ასე ბევრი ჭრელი კვანძი.

სადაც ტრაფიკი კონცენტრირდება

ფან-ინი = კონცენტრაცია

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

Fan-in ნიმუში: ბევრი კლიენტი → ერთი CDN; ბევრი CDN კიდე → რამდენიმე origin პროქსი; ბევრი პროქსი → ნაკლები ბეკენდის რეპლიკა; ბევრი ბეკენდი → ერთი მონაცემთა ბაზა.

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

Fan-Out = დამოკიდებულება

კვანძის Out-degree = მისგან გამომავალი კიდეების რაოდენობა. მაღალი out-degree ნიშნავს ბევრ downstream დამოკიდებულებას.

ბეკენდი, რომელიც იძახებს მონაცემთა ბაზას, ორ ქეშს, სამ გარე API-ს და ერთ რიგს, აქვს out-degree 7. მისი წარმატების ალბათობა 대략 უდრის თითოეული downstream-ის წარმატების ალბათობის ნამრავლს (თუ ყველა საჭიროა წარმატებული პასუხისთვის).

0.999 ^ 7 ≈ 0.993: ბეკენდი, რომელსაც აქვს 7 downstream, თითოეული 99.9%-იანი საიმედოობით, თავად შეძლებს მხოლოდ ~99.3%-იან საიმედოობას, თუნდაც საკუთარი ბაგების გარეშე.

Out-degree-ის შემცირება შესაძლებელია: downstream-ის შედეგების ქეშირებით, არაკრიტიკული downstream-ების არასავალდებულოდ გამოცხადებით (graceful degradation), და პარალელიზაციით იქ, სადაც ეს შესაძლებელია.

ასიმეტრია

ფან-ინი კონცენტრირებს დატვირთვას; ფან-აუტი ამრავებს რისკს. კარგად ფორმირებული გრაფი ამცირებს ორივეს ყველაზე მაღალი გავლენის მქონე კვანძებში.

მონაცემთა ბაზა (უმაღლესი fan-in): აგრესიულად ქეშირება დატვირთვის შესამცირებლად. წაკითხვის რეპლიკები (read replicas) fan-in-ის გასავრცელებლად რამდენიმე 노დზე.

ორкестრატორი სერვისი (უმაღლესი fan-out): წრიული გამრთველები (circuit breakers) თითოეული დამოკიდებულებისთვის, გლუვი დეგრადაცია, ბალკჰედები (bulkheads).

ბეკენდის რეპლიკა იძახებს 4 დაქვემდებარებულ სერვისს, თითოეული დამოუკიდებლად 99.95%-იანი ხელმისაწვდომობით. (1) რა არის ბეკენდის ხელმისაწვდომობის ზედა ზღვარი, თუ ყველა 4 გამოძახება საჭიროა წარმატებული პასუხისთვის? (2) თუ ამ 4-დან 2 დაქვემდებარებული გახდება ოფციონალური გლუვი დეგრადაციის საშუალებით (შეიცვლება ქეშირებული ფოლბეკებით, როცა მიუწვდომელია), რა გახდება ეს ზღვარი?

ჩასმული კვანძი ყიდულობს მოქნილობას

ინდირექცია = შუალედური კვანძის დამატება

პროქსის გარეშე გრაფი არის: client -> backend. კლიენტმა უნდა იცოდეს ბეკენდის მისამართი. ბეკენდის გადატანა მოითხოვს კლიენტის განახლებას (DNS-ის ან კონფიგურაციის მეშვეობით). ეს არის მჭიდრო ბმა.

პროქსით გრაფი ხდება: client -> proxy -> backend. კლიენტი იცნობს მხოლოდ პროქსის მისამართს. ბეკენდის გადატანა მოითხოვს პროქსის upstream კონფიგურაციის განახლებას, და არა კლიენტის.

გრაფის ოპერაცია: არსებულ კიდეს შორის კვანძის ჩასმა. ახალი კიდე client -> proxy სტაბილურია; ახალი კიდე proxy -> backend ახლა გუნდის მართვის ქვეშაა.

გეომეტრიული კითხვა: ინდირექცია ამატებს ფენას, რომელიც აშორებს upstream ცვლილებას downstream ცვლილებისგან. თითოეული ფენის კიდეები შეიძლება დამოუკიდებლად გადაკეთდეს.

ინდირექციის ღირებულება

თითოეული ფენა ამატებს:

- ლატენტურობის ერთ ჰოპს (კლიენტიდან პროქსიმდე კიდე)

- კიდევ ერთ საჭრელ წვეროს გზაზე (თავად პროქსი)

- კიდევ ერთ ადგილს, სადაც შეიძლება მოხდეს არასწორი კონფიგურაცია

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

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

გუნდი არსებულ რევერს პროქსის წინ ამატებს CDN-ს. გზა `client -> proxy -> backend` (2 ჰოპი) იცვლება `client -> CDN -> proxy -> backend`-ით (3 ჰოპი). დაასახელეთ ინდირექციის ორი სარგებელი (გრაფთეორიული ტერმინები მისასალმებელია) და ორი ხარჯი.

წაიკითხე არქიტექტურა როგორც გრაფი

სინთეზი

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

გამოიყენეთ ყველა ოთხი.

ახალ სერვისს აქვს შემდეგი არქიტექტურა: clients -> CDN -> reverse proxy (2 replicas) -> backend tier (8 replicas) -> { DB primary, cache cluster (3 nodes), external API }.

проანალიზეთ: (1) რა არის მაქსიმალური ჰოპების რაოდენობა ერთი მოთხოვნის გზაზე, (2) რომელი ტიერი აქვს ყველაზე მაღალი fan-in (და რას ნიშნავს ეს მასშტაბირებისთვის), (3) რა არის backend-ის ხელმისაწვდომობის ჭერი, თუ DB არის 99.95%, cache არის 99.95%, ხოლო external API არის 99.9% და ყველა საჭიროა, და (4) რომელი ერთი 노დის ამოღება გათიშავს ყველაზე მეტ მომხმარებელს?

თანმხლები შენიშვნები

ეს geometry-of გაკვეთილი Proxies & Origins მთავარ გაკვეთილს გადააკეთებს მიმართული გრაფის ანალიზად.

ამ კურსის შემდეგი თანმხლები geometry_of_stateless_horizontal_scaling იღებს მთავარი scaling გაკვეთილის რეპლიკა-მათემატიკას და გეომეტრიულად გამოიყვანს რიგის მრუდს, Little-ის კანონსა და 80%-იანი გამოყენების მუხლს.

კარგად შეასრულეთ.