Publish ორჯერ დაჭერა ახლა ერთხელ აქვეყნებს

ერთი აპის სამი publish მოთხოვნა 84 მილიწამის ინტერვალით მოვიდა ჩვენს API-ში, და თითოეულმა ამ აპის სრული დეპლოი დაიწყო. ისინი ერთმანეთს ერთსა და იმავე hosting-ზე ეჯიბრებოდნენ, შედეგად რამდენიმე გამოშვება ჩავარდა, რადგან სხვა უკვე მიაღწია იქ, და ერთადერთი ხილული ნიშანი იყო ელფოსტა „release failed“-ით — თვითონ აპი საბოლოოდ კარგად იყო. ახლა publish, რომელიც მოდის მაშინ, როცა იგივე აპისთვის სხვა publish უკვე მიმდინარეობს, მეორე აშენებას არ იწყებს. მონაცემთა ბაზა წყვეტს, რომელი მოთხოვნა გაიმარჯვებს, და დანარჩენებს სიმართლეს ეუბნება: publish უკვე მიმდინარეობს.

რა მოხდა

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

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

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

რატომ ვერაფერმა შეაჩერა

publish-ის კოდს უკვე ჰქონდა ნაბიჯი, რომელიც პროექტის მიმდინარე დეპლოიებს ამოწმებდა. მაგრამ ის აქტიურად აწერდა ყველა მიმდინარე დეპლოის ჩავარდნილად დაწყებამდე — „შეცვლილია ახალი publish-ის მიერ“. ის იმისთვის იყო, რომ გაეწმინდა აშენებები, რომლებიც გაჩერებული პროცესის შემდეგ დარჩა.

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

პირველი publish-ისთვის აპს მეორე, უფრო უცნაური სიმპტომიც ჰქონდა. დეპლოის ჩანაწერი ჯერ არ არსებობდა სახელდებულად, ამიტომ ორი ერთდროული პირველი publish ერთსა და იმავე ჩანაწერს ცდილობდა ჩასმას. მონაცემთა ბაზას აქვს უნიკალური ინდექსი აპის ბმულის სახელზე (მისი slug, როგორიცაა your-app your-app.mythex.ai-ში), ამიტომ მეორე ჩასმა ჩავარდა. API ამას ითარგმნიდა როგორც „ეს ბმულის სახელი დაკავებულია“ — და მომხმარებელს ურჩევდა, აპი გადაერქმია, რომელიც იმ მომენტში უკვე წარმატებით იქვეყნებოდა ამ სახელით.

გამოსწორება: ბლოკი თავად არის დაკავება

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

ბლოკს ასევე სჭირდება გზა, როგორ გამოვიდეს, როცა მისი მფლობელი კვდება. თუ API publish-ის შუაში გადაიტვირთა, ჩანაწერი სამუდამოდ დარჩებოდა „building“-ად და აპის გამოქვეყნება შეუძლებელი იქნებოდა. ამიტომ ჩანაწერი, რომლის მფლობელიც heartbeat-ს აღარ აგზავნის — გაშვებული publish ჩანაწერს ყოველ 30 წამში ანახლებს, და ხუთი წუთი სიჩუმე მკვდრად ითვლება — შეიძლება ხელახლა იქნას დაკავებული. ეს ზღვარი heartbeat-იდან მოდის და არა ვარაუდიდან, რამდენ ხანს უნდა გრძელდებოდეს აშენება. მომხმარებლის საკუთარი Dockerfile-ის აშენებამ შეიძლება კანონიერად დიდხანს გასტანოს, და ნელი აშენება, რომელიც ჯერ კიდევ აგზავნის heartbeat-ს, თავის დაკავებას ინარჩუნებს.

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

წაგებულს სიმართლის თქმა

მოთხოვნას, რომელიც აგებს, ახლა მკაფიო პასუხი მიიღებს: publish_in_progress, მიმდინარე დეპლოის ID-თან ერთად. Publish-ის დაწყების ყველა ადგილი ამას ამუშავებს:

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

როგორ შევამოწმეთ

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

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

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

რა ავიღეთ ამ ამბიდან

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

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