სტატიის თარგმანი: Envoy threading მოდელი - https://blog.envoyproxy.io/envoy-threading-model-a8d44b922310

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

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

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

Threading მიმოხილვა

Envoy იყენებს სამ სხვადასხვა ტიპის ნაკადს:

• მთავარი: ეს თემა აკონტროლებს პროცესის დაწყებას და შეწყვეტას, XDS (xDiscovery Service) API-ს ყველა დამუშავებას, მათ შორის DNS-ს, ჯანმრთელობის შემოწმებას, კლასტერების და მუშაობის დროის მენეჯმენტს, სტატისტიკის გადატვირთვას, ადმინისტრირებას და პროცესის ზოგად მართვას - Linux სიგნალებს. ცხელი გადატვირთვა და ა.შ. ხდება ამ თემაში არის ასინქრონული და "არაბლოკირებადი". ზოგადად, მთავარი თემა კოორდინაციას უწევს ყველა კრიტიკულ ფუნქციონალურ პროცესს, რომელიც არ საჭიროებს დიდი რაოდენობით CPU-ს გასაშვებად. ეს საშუალებას აძლევს საკონტროლო კოდის უმეტესობას დაიწეროს ისე, თითქოს ეს იყოს ერთი ხრახნიანი.
• თანამშრომელი: ნაგულისხმევად, Envoy ქმნის მუშა ძაფს სისტემის თითოეული ტექნიკის ძაფისთვის, ეს შეიძლება კონტროლდებოდეს ოფციის გამოყენებით --concurrency. თითოეული მუშა თემა აწარმოებს „არადაბლოკვის“ მოვლენის ციკლს, რომელიც პასუხისმგებელია თითოეული მსმენელის მოსმენაზე; წერის დროს (29 წლის 2017 ივლისი) არ ხდება მსმენელის განაწილება, ახალი კავშირების მიღება, ფილტრის დასტას ინსტალაცია. კავშირი და ყველა შემავალი/გამომავალი (IO) ოპერაციების დამუშავება კავშირის სიცოცხლის განმავლობაში. კიდევ ერთხელ, ეს საშუალებას აძლევს კავშირის მართვის კოდების უმეტესობას დაიწეროს ისე, თითქოს ეს იყოს ერთი ხრახნიანი.
• ფაილების გამწმენდი: თითოეულ ფაილს, რომელსაც Envoy წერს, ძირითადად წვდომის ჟურნალებს, ამჟამად აქვს დამოუკიდებელი ბლოკირების თემა. ეს გამოწვეულია იმით, რომ ფაილური სისტემის მიერ ქეშირებული ფაილების ჩაწერა გამოყენების დროსაც კი O_NONBLOCK შეიძლება ზოგჯერ დაბლოკოს (კვნესა). როდესაც მუშა ძაფებს სჭირდებათ ფაილში ჩაწერა, მონაცემები რეალურად გადაინაცვლებს მეხსიერების ბუფერში, სადაც ისინი საბოლოოდ იშლება ძაფში. ჩამოიბანეთ. ეს არის კოდის ერთი სფერო, სადაც ტექნიკურად ყველა მუშა ძაფს შეუძლია დაბლოკოს ერთი და იგივე საკეტი მეხსიერების ბუფერის შევსების მცდელობისას.

კავშირის მართვა

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

ამას რამდენიმე მნიშვნელოვანი შედეგი აქვს:

• ყველა კავშირის აუზი Envoy-ში მინიჭებულია მუშა ძაფზე. ასე რომ, მიუხედავად იმისა, რომ HTTP/2 კავშირის აუზები ახორციელებენ მხოლოდ ერთ კავშირს თითოეულ ზემორეულ ჰოსტთან ერთდროულად, თუ არის ოთხი მუშა ძაფები, იქნება ოთხი HTTP/2 კავშირი თითო ზემორე ჰოსტზე სტაბილურ მდგომარეობაში.
• მიზეზი, რის გამოც Envoy მუშაობს ამ გზით, არის ის, რომ ყველაფრის ერთ მუშა თემაში შენახვით, თითქმის ყველა კოდი შეიძლება დაიწეროს დაბლოკვის გარეშე და თითქოს ერთი ნაკადი იყოს. ეს დიზაინი აადვილებს ბევრი კოდის დაწერას და წარმოუდგენლად კარგად მასშტაბებს მუშა ძაფების თითქმის შეუზღუდავი რაოდენობით.
• თუმცა, ერთ-ერთი მთავარი ნაბიჯი არის ის, რომ მეხსიერების აუზისა და კავშირის ეფექტურობის თვალსაზრისით, რეალურად ძალიან მნიშვნელოვანია კონფიგურაციის კონფიგურაცია. --concurrency. საჭიროზე მეტი მუშა ძაფების ქონა დაკარგავს მეხსიერებას, შექმნის მეტ უმოქმედო კავშირებს და შეამცირებს კავშირის გაერთიანების სიჩქარეს. Lyft-ში ჩვენი დესპანის გვერდითი კარის კონტეინერები მუშაობს ძალიან დაბალი კონკურენტულობით ისე, რომ შესრულება უხეშად ემთხვევა იმ სერვისებს, რომელთა გვერდით იჯდეს. ჩვენ ვმართავთ Envoy-ს, როგორც edge proxy, მხოლოდ მაქსიმალური კონკურენტულობისას.

რას ნიშნავს დაუბლოკავი?

ტერმინი „არაბლოკირებადი“ აქამდე არაერთხელ იქნა გამოყენებული, როდესაც განიხილავდნენ თუ როგორ მუშაობს ძირითადი და მუშა ძაფები. ყველა კოდი იწერება იმ ვარაუდით, რომ არაფერი არ არის დაბლოკილი. თუმცა, ეს არ არის მთლად სიმართლე (რაც არ არის მთლად სიმართლე?).

Envoy იყენებს რამდენიმე ხანგრძლივი პროცესის საკეტს:

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

თემის ადგილობრივი საცავი

იმის გამო, რომ ენვოი განასხვავებს ძირითადი ძაფის პასუხისმგებლობებს მუშა ძაფის პასუხისმგებლობებისგან, არსებობს მოთხოვნა, რომ რთული დამუშავება შეიძლება განხორციელდეს მთავარ ძაფზე და შემდეგ მიეწოდოს თითოეულ მუშა ძაფს უაღრესად ერთდროულად. ეს განყოფილება აღწერს Envoy Thread Local Storage (TLS) მაღალ დონეზე. შემდეგ ნაწილში მე აღვწერ, თუ როგორ გამოიყენება ის კლასტერის მართვისთვის.


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

Envoy-ის TLS (Thread local storage) სისტემა მუშაობს შემდეგნაირად:

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

მიუხედავად იმისა, რომ ეს არის ძალიან მარტივი და წარმოუდგენლად ძლიერი პარადიგმა, ის ძალიან ჰგავს RCU (Read-Copy-Update) ბლოკირების კონცეფციას. არსებითად, მუშათა ძაფები არასოდეს ხედავენ მონაცემთა რაიმე ცვლილებას TLS სლოტებში მუშაობის დროს. ცვლილება ხდება მხოლოდ სამუშაო მოვლენებს შორის დასვენების პერიოდში.

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

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

კლასტერული განახლების თემატიკა

ამ განყოფილებაში მე აღვწერ, თუ როგორ გამოიყენება TLS (Thread local storage) კლასტერის სამართავად. კლასტერის მართვა მოიცავს xDS API და/ან DNS დამუშავებას, ასევე ჯანმრთელობის შემოწმებას.


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

1. Cluster Manager არის კომპონენტი Envoy-ში, რომელიც მართავს ყველა ცნობილ კლასტერულ ზედა ნაკადს, Cluster Discovery Service (CDS) API, Secret Discovery Service (SDS) და Endpoint Discovery Service (EDS) API-ებს, DNS-ს და აქტიურ გარე შემოწმებას. ჯანმრთელობის შემოწმება. ის პასუხისმგებელია თითოეული ზემორეული კლასტერის „საბოლოოდ თანმიმდევრული“ ხედის შექმნაზე, რომელიც მოიცავს აღმოჩენილ მასპინძლებს და ასევე ჯანმრთელობის მდგომარეობას.
2. ჯანმრთელობის შემმოწმებელი ახორციელებს ჯანმრთელობის აქტიურ შემოწმებას და აცნობებს ჯანმრთელობის მდგომარეობის ცვლილებებს კლასტერის მენეჯერს.
3. CDS (Cluster Discovery Service) / SDS (Secret Discovery Service) / EDS (Endpoint Discovery Service) / DNS შესრულებულია კლასტერის წევრობის დასადგენად. მდგომარეობის ცვლილება უბრუნდება კლასტერის მენეჯერს.
4. თითოეული მუშა ძაფი განუწყვეტლივ ახორციელებს მოვლენის ციკლს.
5. როდესაც კლასტერის მენეჯერი ადგენს, რომ კლასტერის მდგომარეობა შეიცვალა, ის ქმნის კლასტერის მდგომარეობის ახალ სურათს მხოლოდ წასაკითხად და აგზავნის მას თითოეულ მუშა თემაში.
6. მომდევნო მშვიდი პერიოდის განმავლობაში, მუშა თემა განაახლებს სნეპშოტს გამოყოფილ TLS სლოტში.
7. I/O მოვლენის დროს, რომელმაც უნდა განსაზღვროს ჰოსტი ბალანსის ჩასატვირთად, დატვირთვის ბალანსერი მოითხოვს TLS (Thread local storage) სლოტს ჰოსტის შესახებ ინფორმაციის მისაღებად. ეს არ საჭიროებს საკეტებს. ასევე გაითვალისწინეთ, რომ TLS-ს ასევე შეუძლია განახლების მოვლენების გააქტიურება, რათა დატვირთვის ბალანსერებმა და სხვა კომპონენტებმა შეძლონ ქეშის, მონაცემთა სტრუქტურების და ა.შ. ეს სცილდება ამ პოსტის ფარგლებს, მაგრამ გამოიყენება კოდის სხვადასხვა ადგილას.

ზემოაღნიშნული პროცედურის გამოყენებით, Envoy-ს შეუძლია დაამუშავოს ყველა მოთხოვნა ყოველგვარი დაბლოკვის გარეშე (გარდა ზემოთ აღწერილისა). გარდა თავად TLS კოდის სირთულისა, კოდის უმეტესობას არ სჭირდება იმის გაგება, თუ როგორ მუშაობს მრავალნაკადური და შეიძლება დაიწეროს ერთნაკადად. ეს აადვილებს კოდის უმეტესობის დაწერას უმაღლესი შესრულების გარდა.

სხვა ქვესისტემები, რომლებიც იყენებენ TLS-ს

TLS (Thread local storage) და RCU (Read Copy Update) ფართოდ გამოიყენება Envoy-ში.

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

• შესრულების დროს ფუნქციონირების შეცვლის მექანიზმი: ჩართული ფუნქციების მიმდინარე სია გამოითვლება მთავარ თემაში. შემდეგ თითოეულ მუშა ძაფს ეძლევა მხოლოდ წაკითხვის სურათი RCU სემანტიკის გამოყენებით.
• მარშრუტების ცხრილების შეცვლა: RDS-ის (Route Discovery Service) მიერ მოწოდებული მარშრუტების ცხრილებისთვის, მარშრუტების ცხრილები იქმნება მთავარ თემაში. მხოლოდ წაკითხვადი სნეპშოტი შემდგომში მიეწოდება თითოეულ მუშა თემას RCU (Read Copy Update) სემანტიკის გამოყენებით. ეს ხდის მარშრუტების ცხრილების შეცვლას ატომურად ეფექტური.
• HTTP სათაურის ქეშირება: როგორც ირკვევა, HTTP სათაურის გამოთვლა თითოეული მოთხოვნისთვის (თითო ბირთვზე ~25K+ RPS-ის გაშვებისას) საკმაოდ ძვირია. Envoy ცენტრალიზებულად ითვლის სათაურს დაახლოებით ყოველ ნახევარ წამში და აწვდის მას თითოეულ მუშაკს TLS და RCU საშუალებით.

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

ცნობილი შესრულების ხარვეზები

მიუხედავად იმისა, რომ Envoy საკმაოდ კარგად მუშაობს მთლიანობაში, არის რამდენიმე მნიშვნელოვანი სფერო, რომელიც მოითხოვს ყურადღებას, როდესაც ის გამოიყენება ძალიან მაღალი კონკურენტულობითა და გამტარუნარიანობით:

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

დასკვნა

Envoy-ის threading მოდელი შექმნილია იმისათვის, რომ უზრუნველყოს პროგრამირების სიმარტივე და მასიური პარალელიზმი პოტენციურად ფუჭოვანი მეხსიერების და კავშირების ხარჯზე, თუ არასწორად არის კონფიგურირებული. ეს მოდელი საშუალებას აძლევს მას ძალიან კარგად შეასრულოს ძაფების ძალიან მაღალი რაოდენობა და გამტარუნარიანობა.
როგორც მოკლედ აღვნიშნე Twitter-ზე, დიზაინი ასევე შეიძლება იმუშაოს მომხმარებლის რეჟიმის სრული ქსელის დასტაზე, როგორიცაა DPDK (Data Plane Development Kit), რამაც შეიძლება გამოიწვიოს ჩვეულებრივი სერვერები მილიონობით მოთხოვნას წამში სრული L7 დამუშავებით. ძალიან საინტერესო იქნება იმის ხილვა, თუ რა აშენდება მომდევნო რამდენიმე წლის განმავლობაში.
ერთი ბოლო სწრაფი კომენტარი: მე ბევრჯერ მკითხეს, რატომ ავირჩიეთ C++ Envoy-სთვის. მიზეზი რჩება ის, რომ ის ჯერ კიდევ არის ერთადერთი ფართოდ გამოყენებული ინდუსტრიული კლასის ენა, რომელშიც შეიძლება აშენდეს ამ პოსტში აღწერილი არქიტექტურა. C++ ნამდვილად არ არის შესაფერისი ყველა ან თუნდაც მრავალი პროექტისთვის, მაგრამ გარკვეული გამოყენების შემთხვევებისთვის ის მაინც ერთადერთი ინსტრუმენტია სამუშაოს შესასრულებლად.

კოდის ბმულები

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

• github.com/lyft/envoy/blob/master/include/envoy/thread_local/thread_local.h
• github.com/lyft/envoy/blob/master/source/common/thread_local/thread_local_impl.h
• github.com/lyft/envoy/blob/master/include/envoy/upstream/cluster_manager.h
• github.com/lyft/envoy/blob/master/source/common/upstream/cluster_manager_impl.h

წყარო: www.habr.com