AWS Lambda эсвэл Cloud Run: cold start биш, concurrency үнийг эргүүлнэ

Тасалдсан, богино event function-д ердийн AWS Lambda тохиромжтой сонголт. Харин HTTP хүсэлтүүд гаднын үйлчилгээний хариуг зэрэг хүлээдэг бол Google Cloud Run нэг instance-ийн нөөцийг тэдэнд хуваалцаж, тооцоолох нөөцийн зардлыг бууруулж чадна. Сонголтыг cold start-ын ганц хэмжилтээр бус, хүсэлт бүрийн үргэлжлэх хугацаа болон бодит давхцлаар шийднэ.

Сарын нэг сая хүсэлттэй нөхцөлт тооцоонд богино event хоёр үйлчилгээний үнэгүй хэмжээнд багтана. Нэг нэгээрээ ажиллах урт HTTP хүсэлтэд Lambda-ийн тооцоолсон төлбөр бага, харин I/O хүлээх хугацаа нь бүрэн давхцсан хүсэлтэд Cloud Run-ийн тооцоолсон доод төлбөр бага гарна. Эдгээр нь үйлчилгээ ажиллуулж хэмжсэн дүн биш, нийтлэгдсэн тарифт ижил таамаг хэрэглэсэн жишээ юм.

Төлбөрийг ямар хугацаанд ногдуулдаг вэ

Харьцуулалт ердийн Lambda function болон Cloud Run service-ийн request-based billing-д хамаарна. AWS Lambda-ийн тариф хүсэлтийн тоо, тохируулсан санах ойгоор үржүүлсэн ажиллах хугацааг GB-секундээр тооцдог. Сарын үнэгүй хэмжээ нь нэг сая хүсэлт, 400 мянган GB-секунд; АНУ-ын жишиг x86 тарифын эхний шатанд нэг сая хүсэлт $0.20, нэг GB-секунд $0.0000166667 байна. Санах ой нэмэгдэхэд Lambda-д олгох CPU нөөц мөн өсдөг учраас хоёр өөр тохиргооны гүйцэтгэх хугацаа заавал ижил байхгүй.

Cloud Run-ийн request-based тариф us-central1 бүсэд идэвхтэй нэг vCPU-секундийг $0.000024, нэг GiB-секундийг $0.0000025, нэг сая хүсэлтийг $0.40-өөр үнэлдэг. Сарын үнэгүй хэмжээ нь 180 мянган vCPU-секунд, 360 мянган GiB-секунд, хоёр сая хүсэлт; төлбөрт орох instance-ийн хугацааг 100 миллисекундээр дээш тоймлоно. Нэг instance дээр зэрэг ажилласан хүсэлтүүд хуваарилсан CPU, санах ойг хамт хэрэглэнэ. Instance эхлэх болон унтрах хугацаа ч тооцогдож болох тул зөвхөн хүсэлт боловсруулах хугацаанд үндэслэсэн дүн доод тооцоо болно.

Доорх жишээнд Lambda-ийн АНУ-ын тариф, Cloud Run-ийн us-central1 тарифыг хэрэглэж, хөнгөлөлтгүй, өөр хэрэглээгүй дансны бүтэн үнэгүй хэмжээг workload бүрт тусад нь олгов. Гурван workload нэг дансанд зэрэг ажиллавал үнэгүй хэмжээг хооронд нь хуваана. Монгол дахь хэрэглэгч рүү дамжих сүлжээний зардал, gateway, лог, VPC холболт, валютын хөрвүүлэлт болон татварыг оруулаагүй. Иймээс тоонуудыг хэрэглэгчид хүрэх нийт үйлчилгээний үнэ гэж ойлгож болохгүй.

Ижил сая хүсэлт, гурван өөр үр дүн

Эхний нөхцөлт workload нь хүсэлт бүр 100 миллисекунд үргэлжлэх тасалдсан event. Lambda-д 512 MB санах ой, Cloud Run-д нэг vCPU ба 512 MiB санах ой онооно. Сарын нэг сая хүсэлт Lambda-д 50 мянган GB-секунд, Cloud Run-д хүсэлтүүд дангаараа ажиллавал 100 мянган vCPU-секунд, 50 мянган GiB-секунд болно. Өөр хэрэглээгүй, Cloud Run-ийн instance эхлэх нэмэлт хугацаа үнэгүй хэмжээг хэтрүүлэхгүй нөхцөлд хоёр талын тооцоолсон төлбөр $0. Энэ workload-д үнэ ялагч тодруулахгүй; event-ийг хүлээн авах арга, ажиллуулах кодын хэлбэр, эхний хариуны шаардлага илүү жинтэй.

Хоёр дахь нөхцөлт workload нь хүсэлт бүр нэг секунд үргэлжилж, Cloud Run-ийн instance дээр нэг удаад нэг хүсэлт ажилладаг HTTP үйлчилгээ. Дээрх нөөцийн тохиргоогоор Lambda 500 мянган GB-секунд хэрэглэнэ. Үнэгүй хэмжээнээс давсан 100 мянган GB-секундын төлбөр ойролцоогоор $1.67 бөгөөд хүсэлтийн тоо үнэгүй хэмжээнд багтана. Cloud Run-д нэг сая vCPU-секунд, 500 мянган GiB-секунд хуримтлагдана: үнэгүй хэмжээг хассаны дараа CPU $19.68, санах ой $0.35, нийлээд $20.03. Энэ нь ижил хугацаа гэж таамагласан тарифын харьцуулалт; 512 MB Lambda ба нэг vCPU Cloud Run-д ижил тооцоолох чадал ногдож буй хэрэг биш.

Гурав дахь нөхцөлт workload-д хүсэлт бүр мөн нэг секунд үргэлжилнэ, гэхдээ тэр хугацааны ихэнхийг гадаад I/O хариу хүлээхэд зарцуулна. Cloud Run-ийн нэг instance дээр арван хүсэлт бүрэн давхцаж, CPU, санах ой нь хүрэлцэнэ гэж үзвэл төлбөрт орох нийт идэвхтэй хугацаа 100 мянган секунд болж буурна. Ингэснээр CPU, санах ой, хүсэлтийн тоо тус бүр үнэгүй хэмжээнд багтаж, тооцоолсон доод төлбөр $0 болно. Ердийн Lambda function-д хүсэлт бүрийн ажиллах хугацаа тусдаа хуримтлагдах тул өмнөх жишээтэй адил ойролцоогоор $1.67 гарна.

Бүрэн давхцах арван хүсэлт бол бодит ачааллын амлалт биш, зардал яагаад эргэдгийг харуулах таамаг. Хүсэлтүүд жигд бус ирэх, зарим нь удаан ажиллах, эсвэл Cloud Run нэмэлт instance асаах үед нийт төлбөрт орох хугацаа өснө. Харин CPU ачаалалтай ажлыг нэг instance дээр зэрэг овоолбол хүсэлтүүд ижил нөөцийн төлөө өрсөлдөж, хариулах хугацаа сунана. Тэгэхээр хуваалцсан нөөцийн хэмнэлтийг latency-гаас салгаж үнэлж болохгүй.

Concurrency яагаад тооцоог өөрчилдөг вэ

Ердийн Lambda function-д зэрэг ажиллаж буй хүсэлт бүр тусдаа execution environment шаарддагийг AWS-ийн scaling тайлбар харуулдаг. Нэг environment завгүй байх үед шинэ хүсэлтэд өөр environment үүсэх буюу сул байгаа environment ашиглагдана. Гаднын хариу хүлээж буй хугацаа ч тухайн function-ийн үргэлжлэх хугацаанд ордог тул олон хүсэлтийн GB-секундийг нэмж тооцно. AWS-ийн Lambda Managed Instances олон хүсэлтийг нэг environment-д зэрэг боловсруулах өөр горимтой; дээрх Lambda тооцоо түүнд хамаарахгүй.

Cloud Run-д concurrency-г арваар тохируулах нь хүсэлт бүр яг арваараа нэг instance-д багцлагдана гэсэн үг биш. Ачаалал ирэх хэлбэр, аппликейшн зэрэг хүсэлт боловсруулах чадвар, CPU ашиглалт, санах ойн хэрэгцээ нь платформ хэдэн instance ажиллуулахыг өөрчилнө. Нэг сая хүсэлт сарын турш тараан ирэх үү, богино хугацаанд бөөгнөрөх үү гэдэг ч төлбөрт орох instance-ийн нийт хугацаанд нөлөөлнө. Ижил сарын хүсэлтийн тоотой хоёр үйлчилгээ ижил төлбөртэй байх албагүйн шалтгаан энэ.

Хуучин benchmark юуг хэмжсэн бэ

2020 оны IOD-ийн харьцуулсан туршилтад cold start Lambda-ийн хариунд 210 миллисекунд, Cloud Run-ийн хариунд 1090 миллисекунд нэмсэн; харин дулаан хүсэлтийн нэмэлт саатал тус тус 51 ба 32 миллисекунд байсан тул Cloud Run-ийн үзүүлэлт ойролцоогоор 37 хувиар бага байв. Хоёр талд таван секунд унтдаг Go код ажиллуулж, хүсэлтийг тухайн үйлчилгээтэй нэг бүс дэх виртуал машинаас илгээсэн. Cold start-ыг тохиргооны хувьсагч солих аргаар өдөөсөн тул эдгээр нь тэр үеийн код, бүс, туршилтын нөхцөлийн хэмжилт бөгөөд Монгол дахь хэрэглэгчийн өнөөгийн latency биш.

Тэр туршилтын I/O хувилбарт зохиогч нэг сая богино хүсэлтийг өндөр зэрэгцээ ачааллаар илгээхдээ хамгийн таатай нөхцөлд Cloud Run-ийн гурав орчим instance хүрэлцэнэ гэж тооцсон ч төлбөрт орсон хугацаа нь ойролцоогоор 19 instance ажилласантай дүйжээ. Энэ зөрүү нь онолын бүрэн давхцал бодит масштаблалттай таарахгүй байж болохыг харуулна. Мөн туршилтын нэг урсгалын CPU ажилд Lambda хурдан гарсан; CPU-ийн үр дүнг I/O хүсэлтийн үнийн давуу талтай нэг хэмжүүр мэт нийлүүлж болохгүй. Cold start, дулаан хүсэлтийн саатал, зэрэгцээ I/O ажил нь сонголтын өөр өөр хэсгийг тайлбарлана.

Аль workload-д алийг сонгох вэ

• Тасалдсан богино event: ердийн Lambda-ийн function болон тусдаа execution environment загвар тохиромжтой эхлэл. Жишиг тооцоонд хоёр үйлчилгээ хоёулаа үнэгүй хэмжээний дотор байгаа тул event-ийг хаанаас өдөөх, кодыг ямар хэлбэрээр ажиллуулах, эхний хариуг хэр хурдан авах шаардлага шийдвэрлэнэ.
• Цуваа эсвэл CPU ачаалалтай HTTP хүсэлт: ижил үргэлжлэх хугацааны нөхцөлт тооцоонд Lambda хямд гарна. Гүйцэтгэх хугацаа платформ бүрд өөр байж болох учраас CPU ажилд зөвхөн санах ойн хэмжээ эсвэл cold start-ын хуучин дүнгээр сонголт хийх үндэсгүй.
• Зэрэгцээ, I/O хүлээлт давамгайлсан HTTP хүсэлт: Cloud Run-ийн нэг instance олон хүсэлтийг тогтвортой дааж чадвал тэдгээр хүсэлт нөөцийн хугацааг хуваалцаж, тооцоолсон доод зардлыг бууруулна. Бодит сонголтод төлбөрт орсон instance-ийн нийт хугацаа, оргил ачааллын хариулах хугацаа, нэмэлт сүлжээний зардал хамт хамаарна.

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

• PostgreSQL эсвэл MySQL: benchmark-ийн ялагч workload солигдоход өөрчлөгдөнө
• Backblaze B2 эсвэл Wasabi: 90 хоногийн дүрэм хадгалалтын үнийг эргүүлнэ
• Supabase эсвэл Firebase: үнэгүй quota өсөхөд өөр төрлийн төлбөр болдог