Bioyino - განაწილებული, მასშტაბირებადი მეტრიკის აგრეგატორი

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

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

პრეტენზია 1. Github-მა, პროექტის შემქმნელმა, შეწყვიტა მისი მხარდაჭერა: გამოაქვეყნა პატჩები და შესწორებები, მიიღო ჩვენი და (არა მხოლოდ ჩვენი) PR. ბოლო რამდენიმე თვეში (სადღაც 2018 წლის თებერვალ-მარტიდან) აქტიურობა განახლდა, ​​მაგრამ მანამდე თითქმის 2 წელი სრული სიმშვიდე იყო. გარდა ამისა, მიმდინარეობს პროექტის შემუშავება გიჰუბის შიდა საჭიროებისთვის, რაც შეიძლება სერიოზული დაბრკოლება გახდეს ახალი ფუნქციების დანერგვაში.

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

Როგორც იყო

როგორ უნდა ყოფილიყო

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

და ბოლოს, პრეტენზია X. წერის დროს, ჩვენ მზად ვართ წარვუდგინოთ ის ყველა 14 მეტნაკლებად სამუშაო statsd იმპლემენტაციას, რომელიც ჩვენ შევძელით. წარმოვიდგინოთ, რომ რომელიმე ერთი ინფრასტრუქტურა იმდენად გაიზარდა, რომ 4 მილიონი MPS-ის მიღება საკმარისი აღარ არის. ან თუნდაც ის ჯერ კიდევ არ გაიზარდა, მაგრამ მეტრიკა უკვე იმდენად მნიშვნელოვანია თქვენთვის, რომ სქემებში 2-3 წუთიანი ჩავარდნაც კი შეიძლება უკვე კრიტიკული გახდეს და მენეჯერებს შორის გადაულახავი დეპრესიის შეტევები გამოიწვიოს. ვინაიდან დეპრესიის მკურნალობა უმადური ამოცანაა, საჭიროა ტექნიკური გადაწყვეტილებები.

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

ვინაიდან სკალირების ადგილი გვქონდა, გადავწყვიტეთ დაგვეწყო შეცდომების ტოლერანტობით. "შესახებ! შეცდომის ტოლერანტობა! ეს მარტივია, ჩვენ შეგვიძლია ამის გაკეთება, ”ვფიქრობდით და გავუშვით 2 სერვერი, თითოეულზე ავიღეთ ბრუბეკის ასლი. ამისათვის ჩვენ მოგვიწია ტრაფიკის კოპირება მეტრიკებით ორივე სერვერზე და ამისთვის დაწერაც კი მცირე კომუნალური. ჩვენ ამით მოვაგვარეთ ხარვეზების ტოლერანტობის პრობლემა, მაგრამ... არც ისე კარგად. თავიდან ყველაფერი მშვენივრად ჩანდა: თითოეული ბრუბეკი აგროვებს აგრეგაციის საკუთარ ვერსიას, წერს მონაცემებს Graphite-ზე ყოველ 30 წამში ერთხელ, გადაწერს ძველ ინტერვალს (ეს კეთდება Graphite მხარეს). თუ ერთი სერვერი მოულოდნელად იშლება, ჩვენ ყოველთვის გვაქვს მეორე გაერთიანებული მონაცემების საკუთარი ასლით. მაგრამ აქ არის პრობლემა: თუ სერვერი ვერ ხერხდება, გრაფიკებზე გამოჩნდება "ხერხი". ეს გამოწვეულია იმით, რომ ბრუბეკის 30 წამიანი ინტერვალები არ არის სინქრონიზებული და ავარიის მომენტში ერთი მათგანი არ არის გადაწერილი. როდესაც მეორე სერვერი იწყება, იგივე ხდება. საკმაოდ ასატანია, მაგრამ უკეთესი მინდა! მასშტაბურობის პრობლემა ასევე არ გაქრა. ყველა მეტრიკა მაინც „დაფრინავს“ ერთ სერვერზე და, შესაბამისად, ჩვენ შემოიფარგლება იგივე 2-4 მილიონი MPS, რაც დამოკიდებულია ქსელის დონეზე.

თუ ცოტას დაფიქრდებით პრობლემაზე და ამავდროულად თხრიან თოვლს ნიჩბით, მაშინ შეიძლება შემდეგი აშკარა იდეა მოგივიდეს თავში: გჭირდებათ statsd, რომელსაც შეუძლია მუშაობა განაწილებულ რეჟიმში. ანუ ის, რომელიც ახორციელებს სინქრონიზაციას კვანძებს შორის დროსა და მეტრიკაში. ”რა თქმა უნდა, ასეთი გამოსავალი ალბათ უკვე არსებობს”, - ვთქვით ჩვენ და მივედით Google-ში…. და ვერაფერი იპოვეს. სხვადასხვა სტატისტიკის დოკუმენტაციის გავლის შემდეგ (https://github.com/etsy/statsd/wiki#server-implementations 11.12.2017 წლის XNUMX დეკემბრის მდგომარეობით), ჩვენ აბსოლუტურად არაფერი ვიპოვეთ. როგორც ჩანს, არც დეველოპერებს და არც ამ გადაწყვეტილებების მომხმარებლებს ჯერ არ შეხვედრიათ ამდენი მეტრიკა, თორემ აუცილებლად მოიფიქრებდნენ რაღაცას.

შემდეგ კი ჩვენ გავიხსენეთ "სათამაშო" statsd - bioyino, რომელიც დაიწერა Just for Fun ჰაკათონზე (პროექტის სახელწოდება სკრიპტით იყო გენერირებული ჰაკათონის დაწყებამდე) და მივხვდით, რომ სასწრაფოდ გვჭირდებოდა საკუთარი statsd. Რისთვის?

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

რაზე დავწერო? რა თქმა უნდა, რუსთში. რატომ?

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

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

Დრო გავიდა...

საბოლოოდ, რამდენიმე წარუმატებელი მცდელობის შემდეგ, პირველი სამუშაო ვერსია მზად იყო. Რა მოხდა? ეს არის ის, რაც მოხდა.

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

UDP პაკეტები მეტრიკებით არის გაუწონასწორებელი ქსელის აღჭურვილობის კვანძებს შორის მარტივი Round Robin-ის საშუალებით. რა თქმა უნდა, ქსელის აპარატურა არ აანალიზებს პაკეტების შინაარსს და, შესაბამისად, შეუძლია წამში 4M პაკეტზე ბევრად მეტი გაყვანა, რომ აღარაფერი ვთქვათ მეტრიკაზე, რომლის შესახებაც მან საერთოდ არაფერი იცის. თუ გავითვალისწინებთ, რომ მეტრიკა არ მოდის ერთ ჯერზე თითოეულ პაკეტში, მაშინ ჩვენ არ განვიხილავთ შესრულების პრობლემებს ამ ადგილას. სერვერის გაფუჭების შემთხვევაში, ქსელური მოწყობილობა სწრაფად (1-2 წამში) აღმოაჩენს ამ ფაქტს და ამოიღებს ავარიულ სერვერს როტაციიდან. ამის შედეგად, პასიური (ანუ არალიდერი) კვანძების ჩართვა და გამორთვა შესაძლებელია, სქემებზე შეფერხების შემჩნევის გარეშე. მაქსიმუმი, რომელსაც ვკარგავთ, არის მეტრიკის ნაწილი, რომელიც შემოვიდა ბოლო წამში. ლიდერის უეცარი დაკარგვა/გამორთვა/გამორთვა მაინც შექმნის მცირე ანომალიას (30 წამის ინტერვალი ჯერ კიდევ არ არის სინქრონიზებული), მაგრამ თუ კვანძებს შორის არის კომუნიკაცია, ეს პრობლემები შეიძლება მინიმუმამდე შემცირდეს, მაგალითად, სინქრონიზაციის პაკეტების გაგზავნით. .

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

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

განვითარების დროს გაცილებით მეტი პრობლემა გამოიწვია ქსელის ნაწილმა, რომელიც პასუხისმგებელია მეტრიკის მიღებაზე. ქსელის ნაკადების ცალკეულ ერთეულებად დაყოფის მთავარი მიზანი იყო ნაკადის ხარჯვის დროის შემცირების სურვილი. არარის მონაცემების წასაკითხად სოკეტიდან. ასინქრონული UDP-ისა და რეგულარული recvmsg-ის გამოყენებით ოფციები სწრაფად გაქრა: პირველი მოიხმარს ძალიან დიდ მომხმარებლის სივრცეს CPU-ს მოვლენის დასამუშავებლად, მეორე მოითხოვს ძალიან ბევრ კონტექსტურ გადამრთველს. ამიტომ ახლა გამოიყენება recvmmsg დიდი ბუფერებით (და ბუფერები, ბატონებო ოფიცრები, თქვენთვის არაფერია!). რეგულარული UDP-ის მხარდაჭერა დაცულია მსუბუქი შემთხვევებისთვის, სადაც recvmmsg არ არის საჭირო. მულტიმესიჯის რეჟიმში შესაძლებელია მთავარის მიღწევა: დროის აბსოლუტურ უმრავლესობაში, ქსელის ძაფი აგროვებს OS რიგს - კითხულობს მონაცემებს სოკეტიდან და გადასცემს მას მომხმარებლის სივრცის ბუფერში, მხოლოდ ხანდახან გადადის შევსებული ბუფერის მიცემაზე. აგრეგატორები. სოკეტში რიგი პრაქტიკულად არ გროვდება, ჩამოშვებული პაკეტების რაოდენობა პრაქტიკულად არ იზრდება.

შენიშვნა

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

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

სტატისტიკა თითოეული სერვერისთვის შემომავალი მეტრიკის რაოდენობის შესახებ: 2 მილიონზე მეტი MPS.

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

სტატისტიკა გამავალი მეტრიკის შესახებ: მხოლოდ ერთი კვანძი აგზავნის ყოველთვის - რეიდის ბოსი.

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

შემომავალი მეტრიკის დეტალიზაცია (მეტრული სახელები დამალულია).

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

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

ამას რომ იტყვიან, სულ ესაა, იყიდეთ ჩვენი სპილოები!

წყარო: www.habr.com