AWS Lambda-მ სტანდარტული Node.js სერვერი პირდაპირ მიიღო

2026 წლის 12 ოქტომბერს AWS-მა Lambda Web Functions ხელმისაწვდომი გახადა: სტანდარტული Node.js HTTP სერვერი ახლა Lambda-ში პორტზე უსმენს მოთხოვნებს, ხოლო საწყის ეტაპზე მხარდაჭერილია Node.js 24, Arm64 და სერვისის ხუთი რეგიონი. ვებაპლიკაციას Lambda-ს event handler-ად გადაწერა აღარ სჭირდება; HTTPS endpoint მოთხოვნებს უშუალოდ გაშვებულ სერვერთან აკავშირებს.

Express-ის, Hono-სა და Fastify-ს მსგავსი ჩარჩოებით აგებული აპლიკაციისთვის ეს ნიშნავს ჩვეულებრივი სერვერის პროგრამული მოდელის შენარჩუნებას. ერთ შესრულების გარემოს რამდენიმე HTTP მოთხოვნის პარალელურად მომსახურება შეუძლია, მაშინ როცა ტრადიციული Lambda Event Function ერთ გამოძახებაზე ერთ event-ს ამუშავებს. არჩევანის საზღვარი დატვირთვის ტიპია: ვებმოთხოვნები სერვერთან მიდის, ხოლო რიგებიდან და სხვა AWS სერვისებიდან წამოსული მოვლენები event handler-ის მოდელში რჩება.

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

Web Function-ის კოდი ჩვეულებრივ HTTP სერვერს იწყებს. Lambda გარემოს ცვლადით AWS_LAMBDA_HTTP_ENDPOINT აწვდის მისამართსა და პორტს, რომლებზეც აპლიკაციამ უნდა მოუსმინოს; ლოკალური გაშვებისას ამავე ცვლადის განსაზღვრა დეველოპერს შეუძლია. გამოქვეყნებულ Express მაგალითს სპეციალური Lambda ადაპტერი არ სჭირდება. ამიტომ არსებული მარშრუტებისა და middleware-ის შენარჩუნება შესაძლებელია, თუ აპლიკაცია თავსებადია გამოცხადებულ runtime-თან და გაშვების გარემოსთან.

ჩვეულებრივ HTTP ინტეგრაციაში, მაგალითად Event Function-ის გამოძახებისას, შემოსული მოთხოვნა ფუნქციის event-ად გადაიქცევა, დამმუშავებელი კი პასუხს აბრუნებს. Web Function-ში თავად სერვერის პროცესია მოთხოვნის მიმღები. ამ განსხვავებას გავლენა აქვს ერთდროულ მოთხოვნებზე: Web Function-ის შესრულების გარემო მრავალ მოთხოვნას ინაწილებს, რის გამოც დატვირთვის თითოეული ზრდა აუცილებელი არ არის ცალკე გარემოს ამოქმედებას ნიშნავდეს. ერთ გარემოში ზედა ზღვარი 128 პარალელური მოთხოვნაა; რეალური განაწილება მასშტაბირების პარამეტრებზეც არის დამოკიდებული.

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

ხუთი საწყისი რეგიონი და გლობალური endpoint

საწყის ხელმისაწვდომობაში შედის US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Tokyo) და Europe (Ireland). საქართველოს რეგიონი ამ სიაში არ არის, ამიტომ ფუნქციის შექმნისა და მართვის რეგიონი გუნდმა ჩამოთვლილთაგან უნდა აირჩიოს. ეს სია არ უდრის ყველა შესაძლო შესრულების ადგილს: მრავალრეგიონულ endpoint-ს კოდი არჩეულ სამიზნე რეგიონებშიც შეუძლია გაავრცელოს, თუნდაც მართვის რეგიონი სხვა იყოს.

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

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

CloudFront-ის როლი საჯარო მისამართსა და დაცვაში

Web Function-ს საკუთარი HTTPS endpoint აქვს და დინამიკურ HTTP პასუხს დამოუკიდებლად გასცემს. Amazon CloudFront მის წინ მაშინ ჩნდება, როცა აპლიკაციას სტატიკური შიგთავსის ქეშირება, საკუთარი დომენი ან origin-ზე წვდომის შეზღუდვა სჭირდება. ასეთ სქემაში CloudFront ქეშირებულ ფაილებს მომხმარებელთან ახლოს აწვდის, დინამიკურ მოთხოვნებს კი Web Function-ს უგზავნის. შესაბამისად, Node.js აპლიკაციის სერვერული მარშრუტები ცალკე CDN ფენის დამატებისას უცვლელი შეიძლება დარჩეს.

დაცული origin-ისთვის CloudFront-ის origin access control, ანუ OAC, მოთხოვნებს ხელს აწერს. Web Function-ის endpoint შეიძლება ისე იყოს გამართული, რომ მხოლოდ შესაბამის CloudFront განაწილებას მისცეს გამოძახების უფლება. ეს ფუნქცია განსაკუთრებით მნიშვნელოვანია, თუ გარე ტრაფიკი მხოლოდ CloudFront-ის მისამართით უნდა შევიდეს: წინააღმდეგ შემთხვევაში საჯარო endpoint-მდე პირდაპირი გზაც იარსებებს. CloudFront-ის ქეშის ქცევა კონკრეტული მარშრუტების შიგთავსზეა დამოკიდებული.

სად რთულდება განთავსება და რევიზიის შეცვლა

სწრაფი CLI ბრძანება ინფრასტრუქტურის კოდით გაშვების ყველა დეტალს ვერ ფარავს. ეიდან სტილის 12 ოქტომბრის პრაქტიკულ ჩანაწერში აღწერილია, რომ AWS CLI-ის 2.37.12 ვერსიას Web Functions-ის ბრძანებების სრული ნაკრები არ ჰქონდა, 2.37.13-ს კი ჰქონდა. მის მიერ გამოყენებული SAM CLI 1.168.0 ლოკალურ CodeUri-ს Web Function-ისთვის ავტომატურად არ ფუთავდა; არქივის ვერსიონირებულ S3 ობიექტად ატვირთვა და მისი VersionId-ის გადაცემა ცალკე გახდა საჭირო.

იმავე CloudFormation განთავსებაში კოდის ცვლილებამ ახალი უცვლელი რევიზია შექმნა, endpoint ახალ რევიზიაზე გადაიყვანა და ძველი წაშალა. ამ პროცესმა native canary გაშვება გაართულა: მოთხოვნების წილებად გასაყოფად ძველი და ახალი რევიზიები ერთდროულად უნდა არსებობდეს. თავად Web Function-ის endpoint რევიზიებს შორის ტრაფიკის წონით განაწილებას უჭერს მხარს; პრობლემა სტილის მიერ აღწერილი CloudFormation განახლების პროცესში გამოჩნდა. ეს შედეგი ყველა განთავსების მეთოდზე არ ვრცელდება.

არქიტექტურული არჩევანი მოკლედ ასე იშლება:

• პროგრამის შესასვლელი: არსებული Node.js HTTP სერვერისთვის Web Function პირდაპირი გზაა; მოვლენაზე რეაგირებისთვის Event Function-ის handler შესაბამისი მოდელია.
• გაშვების ადგილი: მართვის საწყისი რეგიონები შეზღუდულია, MultiRegion endpoint კი შესრულებას სხვა სამიზნე რეგიონებშიც ანაწილებს; აპლიკაციის მონაცემთა ბაზის მდებარეობა ცალკე საკითხია.
• გარე წვდომა: საკუთარი HTTPS endpoint საკმარისია უშუალო გამოძახებისთვის, CloudFront-ის OAC კი დაცულ origin-სა და CDN-ის ფენას აერთიანებს.
• გამოშვების კონტროლი: CLI-ისა და SAM-ის შესაძლებლობები, ასევე ძველი რევიზიის შენარჩუნება, ეტაპობრივი განთავსების გეგმას განსაზღვრავს.

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

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

• Cloudflare Turnstile ჩასვით? სერვერული შემოწმების გარეშე დაცვა არ მუშაობს
• AWS Lambda თუ Cloudflare Workers: სწრაფი edge-ს უფრო მკაცრი ჩარჩო ახლავს
• GitHub Copilot თუ Amazon Q: AWS-კოდზე სპეციალისტი ზოგად ასისტენტს უსწრებს