მონაცემთა ბაზის გაღვიძება მკვდარი კავშირების გარეშე

Mythex-ზე გამოქვეყნებული აპები და მათი მონაცემთა ბაზები ძილში გადადიან, როცა არავინ იყენებს. როცა აპი იღვიძებდა, პირველ მოთხოვნას 10–12 წამით აჩერებდა, რადგან ცდილობდა ხელახლა გამოეყენებინა მონაცემთა ბაზის კავშირები, რომლებიც ყველაფრის ძილში ყოფნისას მოკვდა. ახლა Spring Boot აპებს ვაძლევთ მონაცემთა ბაზის პარამეტრებს, რომლებიც ძილის შემდეგაც უსაფრთხოა, და აგენტს ვეუბნებით, რომ ნებისმიერი სტეკის აპი ერთნაირად ააგოს. პლატფორმის ჰოსტინგზე გაღვიძების შემდეგ პირველი მოთხოვნა 12.7 წამიდან 2.3 წამამდე ჩამოვიდა.

რატომ სძინავთ აპებსა და მონაცემთა ბაზებს

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

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

სიმპტომი: ნელი პირველი ვიზიტი

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

ძილთან ერთად ხდება შემდეგი:

1. აპი მუშაობს, პულში რამდენიმე უმოქმედო კავშირით.
2. ვიზიტორი არ მოდის. აპის მანქანა იძინებს — გაყინული, პულით ხელუხლებლად.
3. მონაცემთა ბაზა იძინებს და თავის მხარეს ყველა კავშირს აგდებს.
4. ვიზიტორი მოდის. აპი ზუსტად ისე იღვიძებს, როგორც იყო, და ჯერ კიდევ იჭერს კავშირებს, რომლებსაც ბაზა აღარ იცნობს.
5. პულმა ერთ-ერთი ასეთი კავშირი გასცა. მას უნდა გაარკვიოს, რომ მკვდარია — ცდით და ლოდინით — სანამ მასზე უარს იტყვის.

Spring Boot აპში ამ მკვდარი კავშირების შემოწმებას პირველი მოთხოვნა დაახლოებით 10 წამით ბლოკავდა, სანამ ის „Connection is not available“-ით ჩავარდებოდა. ვიზიტორისთვის საიტი უბრალოდ იჭედებოდა, შემდეგ კი შეიძლებოდა შეცდომა გამოეჩინა.

რატომ შეექმნა Spring აპებს ყველაზე მეტი პრობლემა

Spring Boot პოპულარული Java ჩარჩოა, და ნაგულისხმევად იყენებს კავშირების პულს სახელად HikariCP. Spring ამ პულს პარამეტრებიდან აკონფიგურირებს, მათ შორის იმით, რამდენი უმოქმედო კავშირი უნდა შეინახოს.

მაგრამ Mythex ყოველ აპს მონაცემთა ბაზას ერთი DATABASE_URL-ით აძლევს, ფორმით postgresql://user:pass@host/db. Spring ამ ფორმატს პირდაპირ ვერ კითხულობს. ამიტომ Mythex-ზე აგებული Spring აპები საკუთარ პულს კოდში ქმნიდნენ, ამ URL-ის დამუშავებით — და ხელით აგებული პული ყველა spring.datasource.* პარამეტრს უგულებელყოფს. მაშინაც კი, თუ ვინმე სწორ პულის პარამეტრებს იცნობდა, მათი გამოყენების ადგილი არ არსებობდა.

გამოსწორება, ნაწილი 1: პარამეტრები, რომლებსაც Spring იყენებს

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

• SPRING_DATASOURCE_URL, SPRING_DATASOURCE_USERNAME და SPRING_DATASOURCE_PASSWORD, გადაყვანილი DATABASE_URL-იდან (SSL სავალდებულოა, თუ URL სხვას არ ამბობს).
• პულის პარამეტრები, რომლებიც ძილს უძლებს:

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

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

დეტალი, რომელმაც თითქმის არაფერი გააკეთა

Spring გარემოს ცვლადებს თავის პარამეტრებზე წესით აგებს, რომელშიც შეცდომის დაშვება ადვილია. პარამეტრი minimum-idle უნდა ჩაიწეროს როგორც SPRING_DATASOURCE_HIKARI_MINIMUMIDLE — ტირეები ამოღებულია, სიტყვები ერთმანეთზეა მიწებებული. თუ დაწერთ SPRING_DATASOURCE_HIKARI_MINIMUM_IDLE-ად, რაც უფრო ბუნებრივად ჩანს, ის სხვა, არარსებულ პარამეტრს (minimum.idle) ეძებს და უხმოდ უგულებელყოფილია.

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

გამოსწორება, ნაწილი 2: ყველა სხვა სტეკი

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

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

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

შედეგი

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

რა ვისწავლეთ

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

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