როგორ მივიყვანეთ დეპლოიმენტები ნულოვან 502 შეცდომამდე

Mythex-ის ბექენდის ყოველ დეპლოიმენტზე რამდენიმე მოთხოვნა 502 Bad Gateway-ით ვარდებოდა. არც ისე ბევრი — მაგრამ დეპლოიმენტის დროს 502 ნიშნავს, რომ ვიღაცის დაწკაპუნებამ არაფერი გააკეთა, ან აგება, რომელსაც ის უყურებდა, წამით გაჩერდა. ეს ორ ცალკე პრობლემად გავარკვიეთ: თვით-გამოსწორებადი ვოჩდოგი, რომელიც დეპლოიმენტებს ებრძოდა, და უფსკრული იმ მომენტს შორის, როცა სერვერი უსმენას წყვეტს, და იმ მომენტს შორის, როცა დატვირთვის ბალანსერი მას ტრაფიკს წყვეტს. გასწორების შემდეგ მომდევნო სამ წარმოების დეპლოიმენტზე რაოდენობა 10-დან 6-მდე და შემდეგ 0-მდე ჩამოვიდა.

მოწყობა

ჩვენი API და ორკესტრატორი კონტეინერებად მუშაობს სერვერების მცირე ჯგუფზე, AWS Application Load Balancer-ის (ALB) უკან. დეპლოიმენტი სერვერებს თითო-თითოდ განაახლებს: გამოყოფს ძველ კონტეინერებს, ახალს ამოქმედებს და გადადის შემდეგზე. ყოველ სერვერზე ვოჩდოგი ამოწმებს, რომ კონტეინერები ამუშავებულია და ყოველ ჩავარდნილს ხელახლა ამოქმედებს — მისი დანიშნულებაა, რომ 3 საათზე ჩამოვარდნილი პროცესი ვინმეს გამოღვიძებისა და ჩარევის გარეშე დაბრუნდეს.

ორივე ცალკე გონივრულია. ერთად კი არა.

პრობლემა 1: ვოჩდოგი დეპლოიმენტს ეჯიბრებოდა

ვოჩდოგი წუთში ერთხელ მუშაობდა და ერთი ჩავარდნილი ჯანმრთელობის შემოწმების შემდეგ „განკურნებას“ იწყებდა. დეპლოიმენტი განზრახ გამოყოფს სერვისებს 150 წამამდე — ამ დროს ჯანმრთელობის შემოწმება უნდა ჩავარდეს. ამიტომ ვოჩდოგი ყოველი დეპლოიმენტის დროს მუშაობდა.

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

გამოსწორებები:

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

პრობლემა 2: სერვერი ტრაფიკამდე წავიდა

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

მაგრამ ALB ჯანმრთელობას მხოლოდ ხანდახან ამოწმებს, და სჭირდება რამდენიმე მიმდევრობითი ჩავარდნა, სანამ სამიზნეს მარშრუტს მოხსნის — დაახლოებით 60 წამამდე მთლიანად. ამიტომ დაახლოებით 55 წამის განმავლობაში დატვირთვის ბალანსერი ისევ აგზავნიდა რეალურ მოთხოვნებს სერვერზე, რომელიც უკვე უსმენას წყვეტდა. ეს იყო ჩვენი 502-ები.

გამოსწორება იყო ორი ვადის შესაბამისობაში მოყვანა:

• სამიზნე ჯგუფი ახლა ყოველ 5 წამში ამოწმებს და სამიზნეს 2 ჩავარდნის შემდეგ უჯანმრთელოდ ნიშნავს — დაახლოებით 10 წამში შენიშნავს.
• გამოყვანა რეალურ ტრაფიკს 15 წამით ემსახურება ჩავარდნის დაწყების შემდეგ, რომ ყოველთვის იყოს გადაფარვა.
• ეს პარამეტრები ცხოვრობს ინფრასტრუქტურის მომზადების სკრიპტში და არა კონსოლში, სადაც ვინმემ ერთხელ დააწკაპუნა.

რიცხვების ერთმანეთთან შეთანხმება

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

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

გაზომვა იოლად ირღვევა

ჩვენმა პირველმა გაზომვამ თქვა, რომ სუფთა დეპლოიმენტი დაახლოებით 3%-ით გატეხილი იყო. ასე არ იყო. ჩვენ ყოველ არა-200 პასუხს ვითვლიდით, ხოლო ჯანმრთელობის ენდფოინთის 503 დრენაჟის დროს არ არის ჩავარდნა — ეს დრენაჟი თავის საქმეს აკეთებს, ეუბნება ბალანსერს, რომ ეს სერვერი არ აირჩიოს, სანამ ის რეალურ მოთხოვნებს აგრძელებს.

მომხმარებელს 502 აღენიშნება: მოთხოვნამ ვერაფერს მიაღწია. მხოლოდ მათი დათვლა მისცემდა სწორ სურათს — 10, შემდეგ 6, შემდეგ 0 სამ წარმოების დეპლოიმენტზე.

რა ვისწავლეთ

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

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