Cloudflare Workers თუ Vercel: დაბალი ფასი მიგრაციას მარტივს არ ხდის

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

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

რას აჩვენებს Workers-ის სამი ფასობრივი სცენარი

Cloudflare-ის Workers-ის ფასების დოკუმენტაციით, Paid გეგმის მინიმუმი თვეში 5 დოლარია და მოიცავს 10 მილიონ მოთხოვნასა და 30 მილიონ CPU მილიწამს. დამატებითი მილიონი მოთხოვნა 0,30 დოლარი ღირს, დამატებითი მილიონი CPU მილიწამი — 0,02 დოლარი; გამავალ ტრაფიკზე ცალკე გადასახადი არ არის. სტატიკურ ფაილზე პირდაპირი მოთხოვნა უფასოა, მაგრამ Worker-ის ქეშიდან მომსახურებული მოთხოვნა მოთხოვნების მრიცხველში შედის. CPU დრო კოდის შესრულებისას ირიცხება და არა გარე სერვისის პასუხის ლოდინისას.

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

• მცირე SaaS: თვეში 2 მილიონი მოთხოვნა, საშუალოდ 5 მილიწამი CPU თითოეულზე და 50 გიგაბაიტი გამავალი ტრაფიკი. ჯამი 10 მილიონი CPU მილიწამია. მოთხოვნებიც და CPU დროც ჩართულ მოცულობაში რჩება, ამიტომ Workers-ის ანგარიში 5 დოლარია.
• მზარდი აპი: 20 მილიონი მოთხოვნა, საშუალოდ 10 მილიწამი CPU და 500 გიგაბაიტი გამავალი ტრაფიკი. ლიმიტს ზემოთ დარჩენილი 10 მილიონი მოთხოვნა 3 დოლარია; 200 მილიონი CPU მილიწამიდან დამატებითი 170 მილიონი — 3,40 დოლარი. საბაზო გადასახადით ჯამი 11,40 დოლარია.
• გამოთვლით დატვირთული აპი: 100 მილიონი მოთხოვნა, საშუალოდ 50 მილიწამი CPU და 2 ტერაბაიტი გამავალი ტრაფიკი. დამატებითი მოთხოვნები 27 დოლარია, ხოლო 5 მილიარდი CPU მილიწამიდან ჩართულ მოცულობას ზემოთ დარჩენილი დრო — 99,40 დოლარი. ჯამი 131,40 დოლარია.

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

რატომ არ აქვს Vercel-ს ერთი შესადარებელი თანხა

Vercel-ის ფასების წესები განასხვავებს გადაცემულ მონაცემებს, edge მოთხოვნებსა და გამოთვლითი რესურსების მოხმარებას. Hobby გეგმას ზოგი ჩართული მოცულობა აქვს, Pro გეგმაზე კი გამოყენების კრედიტი და შემდგომი მოხმარების ტარიფები მოქმედებს; CDN-ისთვის ხელმისაწვდომია ფიქსირებული მოცულობის მოდელიც. ამიტომ Workers-ის ზემოთ დათვლილ თანხებს Vercel-ის შესაბამის ფასად ვერ გადავაქცევთ მხოლოდ მოთხოვნების საერთო რაოდენობითა და გამავალი ტრაფიკით.

Vercel Functions-ის ფასების აღწერაში Fluid Compute-ის მრიცხველებია აქტიური CPU დრო, გამოყოფილი მეხსიერების დრო და ფუნქციის გამოძახებები; CPU-სა და მეხსიერების ერთეულის ფასი ფუნქციის რეგიონზეც არის დამოკიდებული. გარე სერვისის პასუხის ლოდინისას CPU-ს ანგარიშვა ჩერდება, ხოლო დაკავებული მეხსიერების დრო მიმდინარე მოთხოვნის განმავლობაში გრძელდება. მაგალითად, მონაცემთა ბაზის ნელი პასუხი CPU-ს მცირე მოხმარებასთან ერთად მეხსიერების მეტ დროს შეიძლება ნიშნავდეს. Vercel-ის დასათვლელად საჭიროა ამ მრიცხველებისა და CDN-ის მოხმარების ცალკე აღება, შემდეგ კი იმავე აპის Workers-ზე მოსალოდნელ მოთხოვნებსა და CPU დროსთან შედარება.

რას გვაჩვენებს პირველი მოთხოვნის ტესტი

სინგაპურიდან ჩატარებულ Next.js-ის დამატებით გაზომვაში SSR და API მარშრუტებს ღამის უმოქმედობის შემდეგ ორი დღის განმავლობაში თითო პლატფორმაზე 40 ერთდროული მოთხოვნით ამოწმებდნენ. ავტორმა პირველ, „ცივ“ პასუხზე Cloudflare Workers-ისთვის დაახლოებით 700–950 მილიწამი, Vercel Serverless-ისთვის კი დაახლოებით 1 089 მილიწამი მიუთითა. გაზომილი იყო მოთხოვნის სრული დრო და არა იზოლირებულად მხოლოდ runtime-ის გაშვების ხანგრძლივობა.

შედარებას კიდევ ერთი არსებითი საზღვარი აქვს: Workers-ის ვერსიაში OpenNext ადაპტერი გამოიყენეს და თავდაპირველი აპიდან ზოგი Node.js API ამოიღეს. ასეთმა ცვლილებამ შესაძლოა შეკვრის ზომაც და შესასრულებელი სამუშაოც შეცვალოს. რიცხვები აღწერს კონკრეტულ Next.js განლაგებებს კონკრეტული სატესტო წერტილიდან; ისინი არ ნიშნავს, რომ ნებისმიერი Workers აპი Vercel-ზე სწრაფად უპასუხებს, ან რომ საქართველოში მომხმარებელი იმავე დაყოვნებას დაინახავს.

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

როგორ ცვლის რეგიონი დაყოვნებას

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

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

სად ჩნდება Next.js-ის გადატანის სამუშაო

Cloudflare-ის Next.js ინსტრუქცია Workers-ზე გაშვების ნაგულისხმევ გზად vinext-ს ასახელებს; ის ჯერ ბეტაშია და არსებული საწარმოო აპისთვის თავსებადობის შემოწმებას ითხოვს. App Router, Pages Router, Server Actions და სერვერული რენდერინგი მხარდაჭერილია, მაგრამ ზოგი next/* იმპორტი მხოლოდ ნაწილობრივ მუშაობს და გამოსახულებების ოპტიმიზაციაც ნაწილობრივ არის მხარდაჭერილი. უკვე OpenNext-ზე მომუშავე აპისთვის დოკუმენტირებული ცალკე გზაც რჩება.

vinext-ის დამატება არსებული პროექტის პარალელურად შეიძლება, თუმცა ეს ფუნქციური თანხვედრის გარანტია არ არის. მიგრაციის სამუშაო დამოკიდებულია იმაზე, რომელ Node.js ბიბლიოთეკებს, middleware-ს, სერვერულ მარშრუტებს, გამოსახულებების დამუშავებასა და ქეშის ქცევას ეყრდნობა აპი. შემოწმება უნდა მოიცავდეს იმავე გვერდებისა და API პასუხების შედეგებს, რომლებსაც გუნდი ახლა Vercel-ზე იღებს; მხოლოდ წარმატებული build მომხმარებლისთვის იმავე ქცევას არ ამტკიცებს.

განსაკუთრებით ძვირი შეიძლება აღმოჩნდეს ცვლილება, რომელიც მხოლოდ ერთ სერვერულ მარშრუტს ეხება, მაგრამ მის გარშემო დამოკიდებულებებისა და ტესტების შეცვლას მოითხოვს. საწყის სამუშაოს ემატება ახალი Next.js ვერსიების მიღებისას თავსებადობის ხელახლა შეფასება. ამ დროს ინჟინრის საათების უნივერსალური ფასი არ არსებობს; გადაწყვეტილებაში ის კონკრეტული პროექტის შეფასებად უნდა შევიდეს და არა მასპინძლობის ტარიფში დამალულ ნულოვან ხარჯად.

რომელი არჩევანი ჯდება კონკრეტულ აპს

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

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

ასევე წაიკითხეთ:

• LLM API-ის დაბალი ფასი შეიძლება მოჩვენებითი იყოს — გადამწყვეტია პასუხის სიგრძე