SRE: შესრულების ანალიზი. კონფიგურაციის მეთოდი Go-ში მარტივი ვებ სერვერის გამოყენებით

შესრულების ანალიზი და tuning არის მძლავრი ინსტრუმენტი კლიენტებისთვის შესრულების შესაბამისობის შესამოწმებლად.

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

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

სტრატეგია

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

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

მარტივი HTTP სერვერის არქიტექტურა

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

გაანალიზებული აპლიკაცია არის HTTP სერვერი, რომელიც გამოკითხავს Postgresql-ს თითოეული მოთხოვნისთვის. გარდა ამისა, არსებობს Prometheus, node_exporter და Grafana აპლიკაციებისა და სისტემის მეტრიკის შეგროვებისა და ჩვენებისთვის.

გამარტივებისთვის, მიგვაჩნია, რომ ჰორიზონტალური სკალირების (და გამოთვლების გამარტივებისთვის) თითოეული სერვისი და მონაცემთა ბაზა განლაგებულია ერთად:

მიზნების განსაზღვრა

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

В Google SRE წიგნი დეტალურად არის განხილული შერჩევისა და მოდელირების მეთოდები. მოდით იგივე გავაკეთოთ და ავაშენოთ მოდელები:

• შეყოვნება: მოთხოვნების 99% უნდა დასრულდეს 60 ms-ზე ნაკლებ დროში;
• ღირებულება: სერვისმა უნდა მოიხმაროს მინიმალური თანხა, რაც ჩვენი აზრით, გონივრულად შესაძლებელია. ამისათვის ჩვენ მაქსიმალურად ვზრდით გამტარუნარიანობას;
• სიმძლავრის დაგეგმვა: მოითხოვს გაგებას და დოკუმენტირებას, თუ რამდენი ეგზემპლარია საჭირო აპლიკაციის გასაშვებად, მთლიანი მასშტაბის ფუნქციონირების ჩათვლით, და რამდენი ინსტანცია იქნება საჭირო საწყისი დატვირთვისა და უზრუნველყოფის მოთხოვნების დასაკმაყოფილებლად. ჭარბი რაოდენობა n+1.

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

სატესტო გარემოს დაყენება

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

ტრანზაქციის დატვირთვა

ეს გარემო იყენებს Vegeta შექმნათ მორგებული HTTP მოთხოვნის მაჩვენებელი შეწყვეტამდე:

$ make load-test LOAD_TEST_RATE=50
echo "POST http://localhost:8080" | vegeta attack -body tests/fixtures/age_no_match.json -rate=50 -duration=0 | tee results.bin | vegeta report

დაკვირვება

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

პროფილირება

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

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

შესრულება, დაკვირვება, ანალიზი.

მოდით გავაკეთოთ ექსპერიმენტი. ჩვენ შევასრულებთ, დავაკვირდებით და გავაანალიზებთ, სანამ არ დავკმაყოფილდებით შესრულებით. მოდით ავირჩიოთ თვითნებურად დაბალი დატვირთვის მნიშვნელობა მისი გამოსაყენებლად პირველი დაკვირვების შედეგების მისაღებად. ყოველ მომდევნო ეტაპზე ჩვენ გავზრდით დატვირთვას გარკვეული სკალირების ფაქტორით, რომელიც არჩეულია გარკვეული ვარიაციით. თითოეული დატვირთვის ტესტირების გაშვება შესრულებულია მოთხოვნის რაოდენობის კორექტირებით: make load-test LOAD_TEST_RATE=X.

50 მოთხოვნა წამში

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

მოდით შევხედოთ ხარჯების მხარეს:

10000 მოთხოვნა წამში / 50 მოთხოვნა თითო სერვერზე = 200 სერვერი + 1

ჩვენ კვლავ შეგვიძლია გავაუმჯობესოთ ეს მაჩვენებელი.

500 მოთხოვნა წამში

უფრო საინტერესო რამ ხდება მაშინ, როდესაც დატვირთვა წამში 500 მოთხოვნას მიაღწევს:

ისევ, ზედა მარცხენა გრაფიკზე ხედავთ, რომ აპლიკაცია ნორმალურ დატვირთვას იწერს. თუ ეს ასე არ არის, არის პრობლემა სერვერზე, რომელზეც აპლიკაცია მუშაობს. პასუხის შეყოვნების გრაფიკი მდებარეობს ზედა მარჯვნივ, რომელიც აჩვენებს, რომ 500 მოთხოვნა წამში იწვევს პასუხის დაყოვნებას 25-40 ms. 99-ე პროცენტული მაინც კარგად ჯდება ზემოთ არჩეულ 60ms SLO-ში.

ღირებულების თვალსაზრისით:

10000 მოთხოვნა წამში / 500 მოთხოვნა თითო სერვერზე = 20 სერვერი + 1

ყველაფრის გაუმჯობესება მაინც შეიძლება.

1000 მოთხოვნა წამში

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

პროფილირება

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

$ curl http://localhost:8080/debug/pprof/profile?seconds=29 > cpu.1000_reqs_sec_no_optimizations.prof

შედეგები შეიძლება გამოჩნდეს შემდეგნაირად:

$ go tool pprof -http=:12345 cpu.1000_reqs_sec_no_optimizations.prof

გრაფიკი აჩვენებს სად და რამდენს ხარჯავს აპლიკაცია CPU დროს. საწყისი აღწერილობიდან ბრენდან გრეგი:

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

ანალიზი - ჰიპოთეზა

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

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

თუ კურსორს გადაახვევთ გრაფიკზე ფუნქციის სახელს, გამოჩნდება მთლიანი დრო, რომელიც იყო დასტაზე გამართვის დროს. HTTPServe ფუნქცია იყო დროის 65%-ში, სხვა გაშვების ფუნქციები runtime.mcall, mstart и gc, დარჩენილი დრო დასჭირდა. სახალისო ფაქტი: მთლიანი დროის 5% იხარჯება DNS შეკითხვებზე:

მისამართები, რომლებსაც პროგრამა ეძებს, ეკუთვნის Postgresql-ს. Დააკლიკეთ FindByAge:

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

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

აპლიკაციის დაყენება - ექსპერიმენტი

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

db, err := sql.Open("postgres", dbConnectionString)
db.SetMaxOpenConns(8)

if err != nil {
   return nil, err
}

შესრულება, დაკვირვება, ანალიზი

ტესტის გადატვირთვის შემდეგ 1000 მოთხოვნით წამში, ცხადია, რომ p99-ის შეყოვნების დონეები ნორმალურად დაბრუნდა SLO 60ms!

რა ღირს?

10000 მოთხოვნა წამში / 1000 მოთხოვნა თითო სერვერზე = 10 სერვერი + 1

მოდით გავაკეთოთ ეს კიდევ უკეთესი!

2000 მოთხოვნა წამში

დატვირთვის გაორმაგება გვიჩვენებს იგივეს, ზედა მარცხენა გრაფიკი აჩვენებს, რომ აპლიკაცია ახერხებს წამში 2000 მოთხოვნის დამუშავებას, p100 არის 60ms-ზე დაბალი, p99 აკმაყოფილებს SLO-ს.

ღირებულების თვალსაზრისით:

10000 მოთხოვნა წამში / 2000 მოთხოვნა თითო სერვერზე = 5 სერვერი + 1

3000 მოთხოვნა წამში

აქ აპლიკაციას შეუძლია 3000 მოთხოვნის დამუშავება p99 შეყოვნებით 60 ms-ზე ნაკლები. SLO არ ირღვევა და ღირებულება მიიღება შემდეგნაირად:

10000 მოთხოვნა წამში / 3000 მოთხოვნაზე სერვერზე = 4 სერვერი + 1 (ავტორმა დააგროვა, დაახლ. მთარგმნელი)

მოდი ვცადოთ ანალიზის კიდევ ერთი რაუნდი.

ანალიზი - ჰიპოთეზა

ჩვენ ვაგროვებთ და ვაჩვენებთ აპლიკაციის გამართვის შედეგებს წამში 3000 მოთხოვნით:

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

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

აპლიკაციის დაყენება - ექსპერიმენტი

ინსტალაციას ცდილობს MaxIdleConns აუზის ზომის ტოლი (ასევე აღწერილია აქ):

db, err := sql.Open("postgres", dbConnectionString)
db.SetMaxOpenConns(8)
db.SetMaxIdleConns(8)
if err != nil {
   return nil, err
}

შესრულება, დაკვირვება, ანალიზი

3000 მოთხოვნა წამში

p99 არის 60ms-ზე ნაკლები, საგრძნობლად ნაკლები p100!

ფლეიმის გრაფიკის შემოწმება აჩვენებს, რომ კავშირი აღარ არის შესამჩნევი! მოდით შევამოწმოთ უფრო დეტალურად pg(*conn).query - ჩვენ ასევე ვერ ვამჩნევთ აქ დამყარებულ კავშირს.

დასკვნა

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

წყარო: www.habr.com