AWS Lambda жирийн Node.js сервер ажиллуулна, гэхдээ таван бүсээр хязгаарлагдав

AWS-ийн 2026 оны 10 дугаар сарын 12-ны зарлалд Lambda Web Functions нь порт сонсдог Node.js серверийг handler, adapter-гүй ажиллуулахаар Виржиниа, Охайо, Орегон, Токио, Ирландын таван бүсэд нээгдэж, эхний хувилбар нь Node.js 24 runtime болон Arm64 архитектур ашиглана гэжээ. Express, Hono, Fastify зэрэг framework-ээр бичсэн HTTP аппын маршрутыг Lambda event хэлбэрт дахин хөрвүүлэх шаардлагагүй болсон нь энэ нээлтийн гол өөрчлөлт юм.

Web Function нэг ажиллах орчинд хэд хэдэн HTTP хүсэлтийг зэрэг хүлээн авч, CPU-г идэвхтэй ажилласан хугацаагаар тооцно. Энэ нь өгөгдлийн сан эсвэл гаднын API-ийн хариуг хүлээдэг серверт өмнөх Event Function загвараас өөр зардал, багтаамжийн нөхцөл бүрдүүлнэ. Гэхдээ аппын код шууд шилжих боломжтой байлаа ч байршуулалтын тохиргоо, native хамаарал болон бүсийн сонголтыг тусад нь шийдэх хэрэгтэй.

Node.js сервер Lambda-д хэрхэн ажиллах вэ

Web Function-д апп ердийн HTTP сервер шиг асаж, AWS_LAMBDA_HTTP_ENDPOINT орчны хувьсагчид өгсөн хаяг, портыг сонсоно. Lambda ирсэн хүсэлтийг тэр серверт хүргэх тул Express-ийн route эсвэл Fastify-ийн endpoint-ийг event handler болгон дахин бичихгүй. Локал орчинд ашигладаг үндсэн кодын бүтэц хадгалагдах боловч сервер ямар хаягт сонсохоо байршуулалтын орчноос авах ёстой.

Байршуулалт Web Function, revision, endpoint гэсэн нөөцөөр зохион байгуулагдана. Revision нь код, тохиргооны өөрчлөгдөхгүй хувилбар; HTTPS endpoint хүсэлтийг сонгосон revision рүү чиглүүлж, шаардлагатай үед хувилбаруудын хооронд урсгал хуваарилна. Ийм бүтэц нь серверийн HTTP кодыг хадгалах боломж өгдөг ч одоогийн Lambda function URL эсвэл API Gateway-ийн тохиргоог автоматаар өвлүүлнэ гэсэн үг биш.

Эхний runtime-ийн зааг нь ялангуяа native модультай төслүүдэд хамаатай. Цэвэр JavaScript кодын логикийг архитектураас болж өөрчлөх шаардлага бага боловч системийн binary агуулсан хамаарал Linux Arm64-д тохирсон байх ёстой. Тиймээс handler-ийг халах нь аппыг багцлах, түүнийг ажиллуулах орчны хамаарлыг шалгах ажлыг халж байгаа хэрэг биш.

Зэрэгцээ хүсэлт төлбөрийг яаж өөрчлөх вэ

Event Function-ийн ажиллах орчин нэг мөчид нэг invocation боловсруулдаг. Web Function-ийн сервер харин нэг орчиндоо олон HTTP хүсэлт авч чадна; хүлээж буй холболт бүрт шинэ орчин асаах шаардлага багасаж болно. Энэ ялгаа удаан нээлттэй streaming хариу, олон богино API хүсэлт эсвэл сервер дээр дүрслэх хуудастай аппад илүү мэдрэгдэнэ.

Төлбөрт хүсэлт, хэрэглэсэн санах ой, идэвхтэй CPU хугацаа болон өгөгдөл дамжуулалт орно. Өгөгдлийн сангийн хариу иртэл CPU сул байвал тэр хүлээлтийг CPU ажилласан хугацаа мэт тооцохгүй, харин орчин амьд байх хугацаанд хэрэглэсэн санах ой тооцогдсоор байна. Иймээс I/O ихтэй маршрутын CPU зардал буурч болох ч нийт төлбөр заавал багасна гэж урьдчилан хэлэх боломжгүй.

Зэрэгцээ ажиллагаа нь аппын өөрийн нөөцөд мөн ачаалал өгнө. Нэг сервер олон хүсэлт авахад CPU их хэрэглэдэг route бусад хариуг удаашруулж болох бөгөөд endpoint-ийн орчны тоо, хүсэлтийн хурдны хязгаар нь нэмэлт ачааллыг тогтооно. Өмнөх загварын нэг хүсэлтэд нэг орчин гэсэн харьцаа арилснаар багтаамжийг зөвхөн ажиллах орчны тоогоор хэмжих нь хангалтгүй болно.

Web Adapter-аас шилжихэд үлдэх ажил

Инженер Айдан Стилийн нээлтийн өдрийн тэмдэглэлд хуучин Lambda Web Adapter загвар нэг орчинд нэг хүсэлт боловсруулж, хүлээсэн нийт хугацаагаар төлбөр тооцдог, JSON event-ээр дамжсан хүсэлтийн биед 6 MB-ийн хязгаартай байсныг тайлбарласан. Web Function нь HTTP хүсэлтийг серверт шууд хүргэдэг учраас adapter-ийн энэ дамжуулалтын замыг ашиглахгүй.

Гэвч шилжилт нь зөвхөн adapter-ийн багцыг арилгахаар дуусахгүй. Web Function-ийн код, тохиргоо revision-д орж, endpoint нь аль revision хүсэлт авахыг удирдана. Одоо ашиглаж буй deployment pipeline, нэвтрэх эрхийн тохиргоо болон API Gateway-ийн дүрэм шинэ HTTPS endpoint-той хэрхэн уялдахыг баг бүр шийдэх шаардлагатай.

Стилийн туршсан SAM CLI хувилбар локал кодыг Web Function-д автоматаар багцлаагүй тул тэрээр хувилбартай S3 объект бэлтгэн байршуулсан байна. Энэ нь тухайн хэрэгслийн нээлтийн үеийн ажиглалт бөгөөд HTTP серверийн кодыг өөрчлөх шаардлагаас тусдаа асуудал юм. Хувилбаруудын хооронд урсгал аажмаар шилжүүлдэг багт revision-ийн амьдралын мөчлөгийг одоогийн автоматжуулалт хэрхэн удирдах нь бас чухал.

Lambda-ийн гурван загвараас алийг сонгох вэ

AWS-ийн нэршилд Event Function, Web Function, MicroVM нь өөр өөр ажиллуулах загвар. Өмнөх Lambda function-ийг Event Function гэж нэрлэх болсон ч event хүлээн авдаг handler-ийн үндсэн ажиллагаа хэвээр. Web Function нь HTTP серверийн кодод зориулагдсан бол MicroVM нь төлөв хадгалах тусгаарлагдсан орчны амьдралын мөчлөгийг хэрэглэгчээр удирдуулна.

• Дарааллын мессеж эсвэл файл нэмэгдсэн дохиогоор эхэлдэг ажилд Event Function-ийн handler загвар тохирно.
• REST, GraphQL, сервер дээр дүрслэх хуудас болон streaming HTTP хариунд Web Function-ийн порт сонсох загвар тохирно.
• Төлөвтэй тусгаарлагдсан орчныг өөрөө удирдах, жишээлбэл хэрэглэгчийн код ажиллуулах хэрэгцээнд MicroVM зориулагдсан.

Сонголтыг аппын орох хүсэлтийн төрлөөс эхэлж хийх нь ойлгомжтой. Event-ээр өдөөгддөг ажлыг HTTP сервер болгох шаардлага энэ нээлтээс үүсээгүй. Харин одоо adapter-аар дамжуулан веб апп ажиллуулж байгаа баг Web Function-ийн зэрэгцээ хүсэлт, идэвхтэй CPU төлбөрийг өөрийн workload-тай шууд харьцуулах боломжтой боллоо.

Таван бүсийн хязгаар юунд хамаарах вэ

Нээлтийн таван бүс нь Web Function-ийг анх удирдах боломжтой үндсэн бүсийн жагсаалт юм. Монголын багт Токио энэ жагсаалтын Азийн сонголт болж байгаа ч Монгол дахь хэрэглэгчийн бодит саатлыг зөвхөн газрын зураг шийдэхгүй: сүлжээний зам, аппын ашиглах өгөгдлийн сангийн байршил, сонгосон endpoint бүгд нөлөөлнө.

AWS-ийн 2026 оны 10 дугаар сарын 13-ны хэрэгжүүлэлтийн жишээнд үндсэн бүсээс кодыг Лондон руу хуулбарлаж, олон бүсийн endpoint-ээр тэнд HTTP хүсэлт гүйцэтгэсэн. Тиймээс зарласан таван бүсийг код гүйцэтгэж болох бүх газрын эцсийн жагсаалт гэж ойлгож болохгүй. Web Function-ийг үндсэн бүсээс удирдах, хуулбарыг сонгосон бүсэд ажиллуулах нь хоёр өөр тохиргоо юм.

Олон бүсийн endpoint хүсэлтийг саатлаар чиглүүлдэг тул Монголын бүх хэрэглэгч заавал Токиод очно гэсэн баталгаа байхгүй. Өгөгдлийн сантай ойр ажиллах ёстой аппад HTTP хүсэлтийн очих бүс болон өгөгдлийн байршил хоорондын зай үргэлжлэх хугацаанд нөлөөлнө. Шинэ үйлчилгээний бүсийн хязгаар хөгжүүлэгчдэд хамгийн түрүүнд үндсэн бүсээ сонгох үед тулгарч, олон бүсийн хуулбарын шийдвэр түүнээс хойш гарна.

Мөн уншаарай:

• AWS Lambda эсвэл Cloud Run: cold start биш, concurrency үнийг эргүүлнэ
• Shopify эсвэл WooCommerce: Монголын төлбөрийн хязгаар сонголтыг эргүүлнэ
• AI сургалтыг prompt-оор бүү хязгаарла: чадварыг ажлын үр дүнгээр шалга