სისტემის სტაბილურობა მაღალი დატვირთვის პირობებში

ამოცანა

Blitzly რამდენიმე AI აგენტს Scout, Brand, Outreach, Legal და Launch ერთიან პროცესში იყენებს, რათა ერთი ბიზნეს იდეა რეალურ გაშვებამდე მიიყვანოს. საჯარო ბეტას დროს ტრაფიკი არაპროგნოზირებადი იყო: მოლოდინის სიაში რეგისტრაციები, AI აგენტების გაშვებები და გვერდების ჩატვირთვები ერთდროულად იზრდებოდა ისეთი კომბინაციებით, რასაც ლაბორატორიული ტესტები სრულად ვერ იმეორებდა.

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

მიზანი სისტემის თავიდან აშენება არ ყოფილა. საჭირო იყო Blitzly-ის უკვე მოქმედი ინფრასტრუქტურის გამყარება და მისი რეალურ მომხმარებლებზე გამოცდა.

ჩვენი მიდგომა

Blitzly-ის მთელ სამუშაო გზაზე მონიტორინგი ჩავრთეთ Vercel-ის edge და serverless ფუნქციებიდან AWS სერვისებამდე, Supabase-ის მონაცემთა ბაზამდე და Redis caching-მდე და სისტემა რეალური ბეტა ტრაფიკის მიხედვით გავაუმჯობესეთ.

რეალური ტრაფიკი როგორც დატვირთვის ტესტი

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

Caching მაღალი დატვირთვისთვის

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

ერთდროული მოთხოვნებისა და მარშრუტიზაციის ოპტიმიზაცია

ვაკვირდებოდით, როგორ ნაწილდებოდა ტრაფიკი Vercel-ის ფუნქციებსა და AWS-ის პროცესებს შორის, შემდეგ კი Nginx-ის routing და backend კონფიგურაცია გავაუმჯობესეთ. ზედმეტი მეხსიერების მოხმარების პრობლემები გამოსწორდა და მოთხოვნები ისე გადანაწილდა, რომ ერთი სერვერის გადატვირთვას მთელი სისტემა აღარ გაეჩერებინა.

შედეგები

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