FAQ VKontakte-ს არქიტექტურისა და მუშაობის შესახებ

VKontakte-ს შექმნის ისტორია ვიკიპედიაშია, ეს თავად პაველმა თქვა. როგორც ჩანს, მას უკვე ყველა იცნობს. საიტის შიდა, არქიტექტურისა და სტრუქტურის შესახებ HighLoad++ Pavel-ზე მითხრა ჯერ კიდევ 2010 წელს. მას შემდეგ ბევრმა სერვერმა გაჟონა, ამიტომ ჩვენ განვაახლებთ ინფორმაციას: გავკვეთთ, ამოვავლებთ შიგთავსს, ავწონით და ტექნიკური თვალსაზრისით შევხედავთ VK მოწყობილობას.

ალექსეი აკულოვიჩი (AterCattus) backend დეველოპერი VKontakte გუნდში. ამ მოხსენების ტრანსკრიპტი არის კოლექტიური პასუხი ხშირად დასმულ კითხვებზე პლატფორმის მუშაობის, ინფრასტრუქტურის, სერვერების და მათ შორის ურთიერთქმედების შესახებ, მაგრამ არა განვითარების შესახებ, კერძოდ. რკინის შესახებ. ცალკე, მონაცემთა ბაზების შესახებ და იმის შესახებ, თუ რა აქვს VK-ს, ჟურნალების შეგროვებისა და მთლიანი პროექტის მონიტორინგის შესახებ. დეტალები ჭრილის ქვეშ.

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

• მედიის ატვირთვა, შენახვა, დამუშავება, გავრცელება: ვიდეო, პირდაპირი სტრიმინგი, აუდიო, ფოტოები, დოკუმენტები.
• ინფრასტრუქტურა, პლატფორმა, დეველოპერის მონიტორინგი, ჟურნალები, რეგიონალური ქეშები, CDN, საკუთრების RPC პროტოკოლი.
• ინტეგრაცია გარე სერვისებთან: push-შეტყობინებები, გარე ბმულების ანალიზი, RSS feed.
• კოლეგების დახმარება სხვადასხვა კითხვებში, რომლებზეც პასუხები უცნობ კოდში ჩაძირვას მოითხოვს.

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

ზოგადი არქიტექტურა

ყველაფერი, როგორც ყოველთვის, იწყება სერვერით ან სერვერების ჯგუფით, რომლებიც იღებენ მოთხოვნებს.

წინა სერვერი

წინა სერვერი იღებს მოთხოვნებს HTTPS, RTMP და WSS საშუალებით.

HTTPS - ეს არის მოთხოვნები საიტის ძირითადი და მობილური ვებ ვერსიებისთვის: vk.com და m.vk.com და ჩვენი API-ის სხვა ოფიციალური და არაოფიციალური კლიენტები: მობილური კლიენტები, მესინჯერები. მიღება გვაქვს RTMP-ტრაფიკი პირდაპირი ტრანსლაციისთვის ცალკეული წინა სერვერებით და WSS- კავშირები Streaming API-სთვის.

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

ჩვენ აღარ ვისაუბრებთ WSS-სა და RTMP-ზე, არამედ მხოლოდ სტანდარტულ HTTPS მოთხოვნებზე, რომლებიც ჩვეულებრივ ასოცირდება ვებ პროექტთან.

ხერხდება

ფრონტის უკან, როგორც წესი, არის backend სერვერები. ისინი ამუშავებენ მოთხოვნებს, რომლებსაც წინა სერვერი იღებს კლიენტებისგან.

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

დატვირთვის განაწილება

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

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

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

ჩვენ გვაქვს ათასობით ასეთი სერვერი. თითოეული ფიზიკური სერვერი აწარმოებს kPHP ჯგუფს ყველა ბირთვის გადასამუშავებლად (რადგან kPHP არის ერთი ხრახნიანი).

კონტენტის სერვერი

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

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

pu/pp

თუ გახსენით ქსელის ჩანართი VK-ში, დაინახეთ pu/pp.

რა არის pu/pp? თუ დავხურავთ ერთ სერვერს მეორის მიყოლებით, მაშინ დახურულ სერვერზე ფაილის ატვირთვისა და ჩამოტვირთვის ორი ვარიანტი არსებობს: პირდაპირ მეშვეობით http://cs100500.userapi.com/path ან შუალედური სერვერის საშუალებით - http://pu.vk.com/c100500/path.

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

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

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

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

საკამათო საკითხი ისაა, რომ ამ შემთხვევაში კლიენტი ინარჩუნებს ნაკლებ კავშირს. თუ არსებობს ერთი და იგივე IP რამდენიმე აპარატისთვის - იგივე ჰოსტთან: pu.vk.com ან pp.vk.com, კლიენტის ბრაუზერს აქვს ლიმიტი ერთ ჰოსტზე ერთდროული მოთხოვნის რაოდენობაზე. მაგრამ ყველგან გავრცელებული HTTP/2-ის დროს, მე მჯერა, რომ ეს აღარ არის აქტუალური.

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

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

Sun

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

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

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

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

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

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

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

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

მზე შიგნიდან

უკუ პროქსი nginx-ზე, ქეში ან RAM-ში ან სწრაფ Optane/NVMe დისკებზე. მაგალითი: http://sun4-2.userapi.com/c100500/path — ბმული "მზეზე", რომელიც მდებარეობს მეოთხე რეგიონში, მეორე სერვერის ჯგუფში. ის ხურავს ბილიკის ფაილს, რომელიც ფიზიკურად დევს სერვერზე 100500.

Cache

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

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

ეს არის მულტიმედიური შინაარსის ქეშირება; აქ მომხმარებლის მონაცემები არ ინახება - მხოლოდ მუსიკა, ვიდეო, ფოტოები.

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

როგორ მუშაობს იგი?

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

ამავდროულად, დემონები - სერვისები რეგიონებში - დროდადრო მოდიან API-ზე და ამბობენ: ”მე ვარ ასეთი და ასეთი ქეში, მომეცი ჩემს რეგიონში ყველაზე პოპულარული ფაილების სია, რომლებიც ჯერ არ არის ჩემზე. ” API აწვდის რეიტინგის მიხედვით დალაგებულ ფაილებს, დემონი ჩამოტვირთავს მათ, მიჰყავს რეგიონებში და აწვდის ფაილებს იქიდან. ეს არის ფუნდამენტური განსხვავება pu/pp-სა და Sun-ს შორის ქეშებიდან: ისინი აძლევენ ფაილს დაუყოვნებლივ, მაშინაც კი, თუ ეს ფაილი არ არის ქეშში, და ქეში ჯერ ჩამოტვირთავს ფაილს საკუთარ თავში, შემდეგ კი იწყებს მის დაბრუნებას.

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

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

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

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

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

მონაცემთა ბაზები ან ძრავები

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

ეს აუცილებელი ღონისძიებაა. ეს იმიტომ მოხდა, რომ 2008-2009 წლებში, როდესაც VK-ს პოპულარობის ფეთქებადი ზრდა ჰქონდა, პროექტი მთლიანად მუშაობდა MySQL-ზე და Memcache-ზე და იყო პრობლემები. MySQL-ს უყვარდა ფაილების ავარია და კორუმპირება, რის შემდეგაც ის არ აღდგება, ხოლო Memcache-ს ეტაპობრივად შეუმცირდა შესრულება და უნდა გადატვირთვა.

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

გამოსავალი წარმატებული იყო. არსებობდა ამის შესაძლებლობა, ასევე უკიდურესი აუცილებლობა, რადგან სკალირების სხვა გზები იმ დროს არ არსებობდა. არ იყო მონაცემთა ბაზების თაიგული, NoSQL ჯერ არ არსებობდა, იყო მხოლოდ MySQL, Memcache, PostrgreSQL - და ეს არის ის.

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

ძრავების ტიპები

გუნდმა დაწერა საკმაოდ ბევრი ძრავა. აქ არის მხოლოდ რამდენიმე მათგანი: მეგობარი, მინიშნებები, სურათი, ipdb, ასოები, სიები, ჟურნალები, memcached, meowdb, სიახლეები, ნოსტრადამუსი, ფოტო, დასაკრავი სიები, pmemcached, sandbox, ძიება, საცავი, მოწონებები, ამოცანები,…

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

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

კლასტერები

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

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

იმისათვის, რომ ეს იმუშაოს, თქვენ უნდა დაამატოთ კიდევ ერთი ერთეული, რომელიც მდებარეობს კოდსა და ძრავებს შორის - მარიონეტული.

RPC პროქსი

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

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

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

სპეციფიკური განხორციელება

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

MySQL-სთვის, რომელიც ჯერ კიდევ გვაქვს აქეთ-იქით, ვიყენებთ db-proxy-ს, ხოლო ClickHouse-ისთვის - კნუტების სახლი.

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

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

TL-ს სქემის მაგალითი, რომლის მიხედვითაც მუშაობს ყველა ძრავა.

memcache.not_found                                = memcache.Value;
memcache.strvalue	value:string flags:int = memcache.Value;
memcache.addOrIncr key:string flags:int delay:int value:long = memcache.Value;

tasks.task
    fields_mask:#
    flags:int
    tag:%(Vector int)
    data:string
    id:fields_mask.0?long
    retries:fields_mask.1?int
    scheduled_time:fields_mask.2?int
    deadline:fields_mask.3?int
    = tasks.Task;
 
tasks.addTask type_name:string queue_id:%(Vector int) task:%tasks.Task = Long;

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

RPC TL-ზე TCP/UDP-ზე... UDP?

ჩვენ გვაქვს RPC პროტოკოლი ძრავის მოთხოვნების შესასრულებლად, რომელიც მუშაობს TL სქემის თავზე. ეს ყველაფერი მუშაობს TCP/UDP კავშირზე. TCP გასაგებია, მაგრამ რატომ გვჭირდება UDP ხშირად?

UDP ეხმარება თავიდან აიცილოთ სერვერებს შორის კავშირების დიდი რაოდენობა. თუ თითოეულ სერვერს აქვს RPC პროქსი და, ზოგადად, მას შეუძლია ნებისმიერ ძრავზე გადასვლა, მაშინ თითოეულ სერვერზე არის ათიათასობით TCP კავშირი. არის დატვირთვა, მაგრამ უსარგებლოა. UDP-ის შემთხვევაში ეს პრობლემა არ არსებობს.

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

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

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

მონაცემთა მუდმივი შენახვა

ძრავები წერენ ბილოგებს. Binlog არის ფაილი, რომლის ბოლოს ემატება მოვლენა მდგომარეობის ან მონაცემების ცვლილების შესახებ. სხვადასხვა გადაწყვეტილებებში მას სხვანაირად უწოდებენ: ორობითი ჟურნალი, WAL, AOF, მაგრამ პრინციპი იგივეა.

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

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

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

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

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

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

მონაცემთა რეპლიკაცია

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

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

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

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

მონაცემთა გაზიარება RPC პროქსიში

როგორ მუშაობს გაზიარება? როგორ ესმის პროქსი, რომელ კლასტერში უნდა გაგზავნოს? კოდში არ არის ნათქვამი: "გაგზავნეთ 15 ფრაგმენტად!" - არა, ამას აკეთებს პროქსი.

უმარტივესი სქემა პირველია - მოთხოვნაში პირველი ნომერი.

get(photo100_500) => 100 % N.

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

ეს გამოსადეგია, როდესაც გვინდა გვქონდეს ერთი ერთეულის მონაცემთა ლოკალიზაცია. ვთქვათ 100 არის მომხმარებლის ან ჯგუფის ID და გვსურს, რომ ერთი ერთეულის ყველა მონაცემი იყოს ერთ ნაწილზე რთული მოთხოვნებისთვის.

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

hash(photo100_500) => 3539886280 % N

ჩვენ ასევე ვიღებთ ჰეშს, გაყოფის ნარჩენს და ფრაგმენტის ნომერს.

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

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

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

ჟურნალები

ჩვენ ვწერთ ჟურნალებს რამდენიმე გზით. ყველაზე აშკარა და მარტივი არის ჩაწერეთ ჟურნალები memcache-ში.

ring-buffer: prefix.idx = line

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

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

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

ძრავი ძალიან ძველია, არის მტევანი, რომლებიც უკვე 6-7 წლისაა. მასში არის პრობლემები, რომელთა გადაჭრასაც ვცდილობთ, მაგალითად, დავიწყეთ ClickHouse-ის აქტიური გამოყენება ჟურნალების შესანახად.

ჟურნალების შეგროვება ClickHouse-ში

ეს დიაგრამა გვიჩვენებს, თუ როგორ შევდივართ ჩვენს ძრავებში.

არის კოდი, რომელიც ლოკალურად მიდის RPC-ის მეშვეობით RPC-პროქსისკენ და ესმის სად უნდა წავიდეს ძრავამდე. თუ გვინდა დავწეროთ ჟურნალები ClickHouse-ში, ჩვენ უნდა შევცვალოთ ორი ნაწილი ამ სქემაში:

• შეცვალეთ ზოგიერთი ძრავა ClickHouse-ით;
• შეცვალეთ RPC პროქსი, რომელსაც არ შეუძლია ClickHouse-ზე წვდომა, რაიმე გადაწყვეტილებით, რომელიც შეიძლება და RPC-ის მეშვეობით.

ძრავა მარტივია - ჩვენ ვცვლით მას სერვერით ან სერვერების კლასტერით ClickHouse-ით.

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

ზოგჯერ ჩვენ არ გვინდა RPC სქემის დანერგვა არასტანდარტულ გადაწყვეტილებებში, მაგალითად, nginx-ში. ამიტომ, KittenHouse-ს აქვს შესაძლებლობა მიიღოს ჟურნალები UDP-ის საშუალებით.

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

მონიტორინგი

ჩვენ გვაქვს ორი ტიპის ჟურნალი: ადმინისტრატორების მიერ შეგროვებული მათ სერვერებზე და ისინი დაწერილი დეველოპერების მიერ კოდიდან. ისინი შეესაბამება მეტრიკის ორ ტიპს: სისტემა და პროდუქტი.

სისტემის მეტრიკა

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

პროდუქტის მეტრიკა

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

statlogsCountEvent   ( ‘stat_name’,            $key1, $key2, …)
statlogsUniqueCount ( ‘stat_name’, $uid,    $key1, $key2, …)
statlogsValuetEvent  ( ‘stat_name’, $value, $key1, $key2, …)

$stats = statlogsStatData($params)

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

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

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

საჭიროების შემთხვევაში შეგვიძლია პირდაპირ მივწეროთ ლოგ-კოლექციონერებს.

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

შემდეგი, ჟურნალების შემგროვებლები აერთიანებენ სტატისტიკას meowDB - ეს არის ჩვენი მონაცემთა ბაზა, რომელსაც ასევე შეუძლია მეტრიკის შენახვა.

შემდეგ ჩვენ შეგვიძლია გავაკეთოთ ორობითი "SQL-თან ახლოს" არჩევა კოდიდან.

ექსპერიმენტი

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

ჩვენ გვქონდა სქემა, რომელიც წერდა ჟურნალებს KittenHouse-ის მეშვეობით.

Ჩვენ გადავწყვიტეთ დაამატეთ კიდევ ერთი „*სახლი“ დიაგრამაზე, რომელიც მიიღებს ზუსტად მეტრიკას იმ ფორმატში, როგორც ჩვენი კოდი წერს მათ UDP-ის საშუალებით. შემდეგ ეს *სახლი აქცევს მათ ჩანართებად, მორების მსგავსად, რაც KittenHouse-ს ესმის. მას შეუძლია შესანიშნავად მიაწოდოს ეს ჟურნალები ClickHouse-ს, რომელსაც უნდა შეეძლოს მათი წაკითხვა.

სქემა memcache, stats-daemon და logs-collectors მონაცემთა ბაზით შეიცვალა ამით.

სქემა memcache, stats-daemon და logs-collectors მონაცემთა ბაზით შეიცვალა ამით.

• აქ არის კოდის გაგზავნა, რომელიც იწერება ადგილობრივად StatsHouse-ში.
• StatsHouse წერს UDP მეტრიკას, რომელიც უკვე გადაკეთებულია SQL ჩანართებად, KittenHouse-ში ჯგუფურად.
• KittenHouse აგზავნის მათ ClickHouse-ში.
• თუ გვინდა მათი წაკითხვა, მაშინ ვკითხულობთ მათ StatsHouse-ის გვერდის ავლით - პირდაპირ ClickHouse-დან ჩვეულებრივი SQL-ის გამოყენებით.

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

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

განლაგება

პირველ რიგში, მოდით შევხედოთ PHP-ის დანერგვას. ჩვენ ვვითარდებით ტურიზმი: გამოყენება გიტლაბი и TeamCity განლაგებისთვის. განვითარების ტოტები გაერთიანებულია მთავარ ფილიალში, მასტერიდან ტესტირებისთვის ისინი გაერთიანებულია დადგმაში, ხოლო დადგმიდან წარმოებაში.

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

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

ჩვენი ძრავებისთვის, რომლებიც ასევე არსებითად ორობითია, სქემა ძალიან ჰგავს:

• git master ფილიალი;
• ორობითი in .deb;
• ვერსია იწერება binlog copyfast-ზე;
• რეპლიკაცია სერვერებზე;
• სერვერი ამოიღებს ახალ .dep;
• დპკგ -ი;
• მოხდენილი გადატვირთვა ახალ ვერსიაზე.

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

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

• ანტონ კირიუშკინის მოხსენება Vkontakte სისტემის ადმინისტრატორი. Როგორ?" დეტალებით copyfast-ისა და ჭორის შესახებ.
• იური ნასრეთდინოვის მოხსენება "როგორ აყენებს VK მონაცემებს CLickHouse-ში ათობით ათასი სერვერიდან".
• ჩემი ანგარიში "მზარდი პროექტის არქიტექტურა VKontakte-ს მაგალითის გამოყენებით", მაგრამ განვითარების თვალსაზრისით, არა აპარატურა.

ალექსეი აკულოვიჩი არის ერთ-ერთი მათგანი, ვინც, როგორც პროგრამის კომიტეტის ნაწილი, ეხმარება PHP რუსეთი 17 მაისს PHP დეველოპერებისთვის ბოლო დროის ყველაზე დიდი ღონისძიება გახდება. ნახე რა მაგარი კომპიუტერი გვაქვს, რა დინამიკები (ორი მათგანი ავითარებს PHP core!) - როგორც ჩანს, რაღაცას ვერ გამოტოვებთ, თუ დაწერთ PHP.

წყარო: www.habr.com