ການວິເຄາະລາຍລະອຽດຂອງ AWS Lambda

ການແປພາສາຂອງບົດຄວາມໄດ້ຖືກກະກຽມໂດຍສະເພາະສໍາລັບນັກສຶກສາຂອງຫຼັກສູດ "ການບໍລິການຄລາວ". ມີຄວາມສົນໃຈໃນການພັດທະນາໃນທິດທາງນີ້? ເບິ່ງຫ້ອງຮຽນຕົ້ນສະບັບໂດຍ Egor Zuev (TeamLead at InBit) "ບໍລິການ AWS EC2" ແລະເຂົ້າຮ່ວມກຸ່ມຫຼັກສູດຕໍ່ໄປ: ເລີ່ມວັນທີ 26 ກັນຍາ.

ມີຄົນຍ້າຍໄປຍັງ AWS Lambda ຫຼາຍຂຶ້ນເພື່ອຂະຫຍາຍຂະໜາດ, ປະສິດທິພາບ, ການປະຢັດ, ແລະຄວາມສາມາດໃນການຈັດການຄຳຮ້ອງຂໍນັບລ້ານ ຫຼືຫຼາຍພັນຕື້ຕໍ່ເດືອນ. ເພື່ອເຮັດສິ່ງນີ້, ທ່ານບໍ່ຈໍາເປັນຕ້ອງຈັດການໂຄງສ້າງພື້ນຖານທີ່ການບໍລິການດໍາເນີນການ. ແລະ autoscaling ອະນຸຍາດໃຫ້ທ່ານໃຫ້ບໍລິການຫຼາຍພັນຄໍາຮ້ອງຂໍພ້ອມໆກັນຕໍ່ວິນາທີ. ຂ້າພະເຈົ້າຄິດວ່າ AWS Lambda ສາມາດຖືກເອີ້ນເປັນບໍລິການ AWS ທີ່ນິຍົມຫຼາຍທີ່ສຸດ.

AWS Lambda

AWS Lambda ແມ່ນການບໍລິການຄອມພິວເຕີທີ່ບໍ່ມີເຊີບເວີທີ່ຂັບເຄື່ອນດ້ວຍເຫດການທີ່ຊ່ວຍໃຫ້ທ່ານສາມາດແລ່ນລະຫັດໂດຍບໍ່ມີການຈັດຫາຫຼືການຄຸ້ມຄອງເຄື່ອງແມ່ຂ່າຍແລະຂະຫຍາຍການບໍລິການ AWS ອື່ນໆໂດຍໃຊ້ເຫດຜົນແບບກໍານົດເອງ. Lambda ອັດຕະໂນມັດຕອບສະຫນອງຕໍ່ເຫດການຕ່າງໆ (ເອີ້ນວ່າ triggers), ເຊັ່ນການຮ້ອງຂໍ HTTP ຜ່ານ Amazon API Gateway, ການປ່ຽນແປງຂໍ້ມູນໃນ Amazon S3 buckets ຫຼືຕາຕະລາງ Amazon DynamoDB; ຫຼືທ່ານສາມາດແລ່ນລະຫັດຂອງທ່ານຜ່ານການໂທ API ໂດຍໃຊ້ AWS SDK ແລະການປ່ຽນສະຖານະໃນ AWS Step Functions.

Lambda ແລ່ນລະຫັດໃນໂຄງສ້າງພື້ນຖານຄອມພິວເຕີທີ່ມີສູງແລະມີຄວາມຮັບຜິດຊອບຢ່າງເຕັມທີ່ໃນການຄຸ້ມຄອງແພລະຕະຟອມທີ່ຕິດພັນ, ລວມທັງການບໍາລຸງຮັກສາເຄື່ອງແມ່ຂ່າຍແລະລະບົບປະຕິບັດການ, ການສະຫນອງຊັບພະຍາກອນ, ການປັບຂະຫນາດອັດຕະໂນມັດ, ການກວດສອບລະຫັດແລະການເຂົ້າສູ່ລະບົບ. ນັ້ນແມ່ນ, ທ່ານພຽງແຕ່ຕ້ອງການອັບໂຫລດລະຫັດຂອງທ່ານແລະກໍານົດວິທີການແລະເວລາທີ່ມັນຄວນຈະຖືກປະຕິບັດ. ໃນທາງກັບກັນ, ການບໍລິການຈະດູແລການເປີດຕົວຂອງມັນແລະຮັບປະກັນຄວາມພ້ອມຂອງຄໍາຮ້ອງສະຫມັກຂອງທ່ານ.

ເມື່ອໃດທີ່ຈະປ່ຽນເປັນ Lambda?

AWS Lambda ເປັນແພລະຕະຟອມຄອມພິວເຕີ້ທີ່ສະດວກສະບາຍທີ່ເຫມາະສົມສໍາລັບຫຼາຍໆກໍລະນີ, ຕາບໃດທີ່ພາສາແລະເວລາແລ່ນຂອງລະຫັດຂອງທ່ານໄດ້ຮັບການສະຫນັບສະຫນູນຈາກການບໍລິການ. ຖ້າທ່ານຕ້ອງການເນັ້ນໃສ່ລະຫັດແລະເຫດຜົນທາງທຸລະກິດຂອງເຈົ້າໃນຂະນະທີ່ອອກບໍລິການບໍາລຸງຮັກສາເຄື່ອງແມ່ຂ່າຍ, ການຈັດຫາ, ແລະການປັບຂະຫນາດດ້ວຍຄ່າໃຊ້ຈ່າຍທີ່ສົມເຫດສົມຜົນ, AWS Lambda ແມ່ນແນ່ນອນທາງທີ່ຈະໄປ.

Lambda ແມ່ນເຫມາະສົມສໍາລັບການສ້າງການໂຕ້ຕອບການຂຽນໂປລແກລມ, ແລະເມື່ອນໍາໃຊ້ຮ່ວມກັນກັບ API Gateway, ທ່ານສາມາດຫຼຸດຜ່ອນຄ່າໃຊ້ຈ່າຍຢ່າງຫຼວງຫຼາຍແລະເຂົ້າສູ່ຕະຫຼາດໄວຂຶ້ນ. ມີວິທີທີ່ແຕກຕ່າງກັນທີ່ຈະໃຊ້ຟັງຊັນ Lambda ແລະທາງເລືອກໃນການຈັດຕັ້ງສະຖາປັດຕະຍະກໍາ serverless - ທຸກຄົນສາມາດເລືອກສິ່ງທີ່ເຫມາະສົມໂດຍອີງໃສ່ເປົ້າຫມາຍຂອງພວກເຂົາ.

Lambda ຊ່ວຍໃຫ້ທ່ານສາມາດປະຕິບັດວຽກງານທີ່ກວ້າງຂວາງ. ດັ່ງນັ້ນ, ຂໍຂອບໃຈກັບການສະຫນັບສະຫນູນ CloudWatch, ທ່ານສາມາດສ້າງວຽກງານທີ່ເລື່ອນເວລາແລະອັດຕະໂນມັດຂະບວນການສ່ວນບຸກຄົນ. ບໍ່ມີຂໍ້ຈໍາກັດກ່ຽວກັບລັກສະນະແລະຄວາມເຂັ້ມຂົ້ນຂອງການນໍາໃຊ້ການບໍລິການ (ການບໍລິໂພກຫນ່ວຍຄວາມຈໍາແລະເວລາຖືກພິຈາລະນາ), ແລະບໍ່ມີຫຍັງປ້ອງກັນທ່ານຈາກການເຮັດວຽກເປັນລະບົບກ່ຽວກັບ microservice ເຕັມຮູບແບບໂດຍອີງໃສ່ Lambda.

ໃນທີ່ນີ້ທ່ານສາມາດສ້າງການປະຕິບັດທີ່ເນັ້ນໃສ່ການບໍລິການທີ່ບໍ່ດໍາເນີນການຢ່າງຕໍ່ເນື່ອງ. ຕົວຢ່າງປົກກະຕິແມ່ນການຂະຫຍາຍຮູບພາບ. ເຖິງແມ່ນວ່າໃນກໍລະນີຂອງລະບົບແຈກຢາຍ, ຫນ້າທີ່ Lambda ຍັງຄົງກ່ຽວຂ້ອງ.

ດັ່ງນັ້ນ, ຖ້າທ່ານບໍ່ຕ້ອງການຈັດການກັບການຈັດສັນແລະການຄຸ້ມຄອງຊັບພະຍາກອນຄອມພິວເຕີ້, ລອງໃຊ້ AWS Lambda; ຖ້າ​ຫາກ​ວ່າ​ທ່ານ​ບໍ່​ຈໍາ​ເປັນ​ຕ້ອງ​ການ​ຄິດ​ໄລ່​ຢ່າງ​ຮຸນ​ແຮງ​, ຊັບ​ພະ​ຍາ​ກອນ​ຫຼາຍ​, ຍັງ​ພະ​ຍາ​ຍາມ AWS Lambda​; ຖ້າລະຫັດຂອງທ່ານເຮັດວຽກເປັນໄລຍະ, ນັ້ນແມ່ນ, ທ່ານຄວນລອງ AWS Lambda.

ຄວາມປອດໄພ

ມາຮອດປະຈຸ, ບໍ່ມີການຮ້ອງທຸກກ່ຽວກັບຄວາມປອດໄພ. ໃນທາງກົງກັນຂ້າມ, ເນື່ອງຈາກຫຼາຍຂະບວນການພາຍໃນແລະລັກສະນະການປະຕິບັດຂອງຕົວແບບນີ້ໄດ້ຖືກເຊື່ອງໄວ້ຈາກຜູ້ໃຊ້ຂອງສະພາບແວດລ້ອມ runtime ທີ່ຖືກຄຸ້ມຄອງຂອງ AWS Lambda, ບາງກົດລະບຽບທີ່ຍອມຮັບໂດຍທົ່ວໄປຂອງຄວາມປອດໄພຂອງຄລາວຈະບໍ່ກ່ຽວຂ້ອງ.

ເຊັ່ນດຽວກັນກັບການບໍລິການຂອງ AWS ສ່ວນໃຫຍ່, Lambda ແມ່ນສະຫນອງໃຫ້ຢູ່ໃນພື້ນຖານຄວາມປອດໄພຮ່ວມກັນແລະການປະຕິບັດຕາມລະຫວ່າງ AWS ແລະລູກຄ້າ. ຫຼັກການນີ້ຊ່ວຍຫຼຸດຜ່ອນຄວາມຫນັກຫນ່ວງໃນການດໍາເນີນງານຂອງລູກຄ້າ, ນັບຕັ້ງແຕ່ AWS ປະຕິບັດຫນ້າທີ່ໃນການຮັກສາ, ບໍລິຫານແລະຕິດຕາມກວດກາອົງປະກອບການບໍລິການ - ຈາກລະບົບປະຕິບັດການຂອງເຈົ້າພາບແລະຊັ້ນ virtualization ໄປສູ່ຄວາມປອດໄພທາງດ້ານຮ່າງກາຍຂອງຊັບສິນພື້ນຖານໂຄງລ່າງ.

ເວົ້າສະເພາະກ່ຽວກັບ AWS Lambda, AWS ແມ່ນຮັບຜິດຊອບໃນການຄຸ້ມຄອງໂຄງສ້າງພື້ນຖານ, ການບໍລິການທີ່ຕິດພັນ, ລະບົບປະຕິບັດການ, ແລະແພລະຕະຟອມແອັບພລິເຄຊັນ. ໃນຂະນະທີ່ລູກຄ້າມີຄວາມຮັບຜິດຊອບຕໍ່ຄວາມປອດໄພຂອງລະຫັດຂອງລາວ, ການເກັບຮັກສາຂໍ້ມູນລັບ, ການຄວບຄຸມການເຂົ້າເຖິງມັນ, ເຊັ່ນດຽວກັນກັບການບໍລິການແລະຊັບພະຍາກອນຂອງ Lambda (Identity and Access Management, IAM), ລວມທັງຢູ່ໃນຂອບເຂດຈໍາກັດຂອງຫນ້າທີ່ນໍາໃຊ້.

ແຜນວາດຂ້າງລຸ່ມນີ້ສະແດງໃຫ້ເຫັນຮູບແບບຄວາມຮັບຜິດຊອບຮ່ວມກັນຍ້ອນວ່າມັນໃຊ້ກັບ AWS Lambda. ຄວາມຮັບຜິດຊອບຂອງ AWS ແມ່ນສີສົ້ມແລະຄວາມຮັບຜິດຊອບຂອງລູກຄ້າແມ່ນສີຟ້າ. ດັ່ງທີ່ເຈົ້າສາມາດເຫັນໄດ້, AWS ມີຄວາມຮັບຜິດຊອບຫຼາຍຂຶ້ນຕໍ່ແອັບພລິເຄຊັນທີ່ນຳໃຊ້ຢູ່ໃນການບໍລິການ.

ແບບຈໍາລອງຄວາມຮັບຜິດຊອບຮ່ວມກັນໃຊ້ໄດ້ກັບ AWS Lambda

ເວລາແລ່ນຂອງ Lambda

ປະໂຫຍດຕົ້ນຕໍຂອງ Lambda ແມ່ນວ່າໂດຍການປະຕິບັດຫນ້າທີ່ໃນນາມຂອງເຈົ້າ, ການບໍລິການຕົວມັນເອງຈັດສັນຊັບພະຍາກອນທີ່ຈໍາເປັນ. ທ່ານສາມາດຫຼີກເວັ້ນການເສຍເວລາແລະຄວາມພະຍາຍາມໃນການຄຸ້ມຄອງລະບົບແລະສຸມໃສ່ເຫດຜົນທາງທຸລະກິດແລະການເຂົ້າລະຫັດ.

ການບໍລິການ Lambda ແບ່ງອອກເປັນສອງຍົນ. ທໍາອິດແມ່ນຍົນຄວບຄຸມ. ອີງຕາມວິກິພີເດຍ, ຍົນຄວບຄຸມແມ່ນສ່ວນຫນຶ່ງຂອງເຄືອຂ່າຍທີ່ຮັບຜິດຊອບໃນການຂົນສົ່ງສັນຍານການຈະລາຈອນແລະເສັ້ນທາງ. ມັນ​ເປັນ​ອົງ​ປະ​ກອບ​ຕົ້ນ​ຕໍ​ທີ່​ເຮັດ​ໃຫ້​ການ​ຕັດ​ສິນ​ໃຈ​ໃນ​ທົ່ວ​ໂລກ​ກ່ຽວ​ກັບ​ການ​ຈັດ​ຫາ​, ການ​ບໍ​ລິ​ການ​, ແລະ​ການ​ແຈກ​ຢາຍ​ພາ​ລະ​ວຽກ​. ນອກຈາກນັ້ນ, ຍົນຄວບຄຸມເຮັດຫນ້າທີ່ເປັນ topology ເຄືອຂ່າຍຂອງຜູ້ໃຫ້ບໍລິການແກ້ໄຂ, ຮັບຜິດຊອບສໍາລັບເສັ້ນທາງແລະການຄຸ້ມຄອງການຈະລາຈອນ.

ຍົນທີສອງແມ່ນຍົນຂໍ້ມູນ. ມັນ, ຄືກັບຍົນຄວບຄຸມ, ມີວຽກງານຂອງຕົນເອງ. ຍົນຄວບຄຸມໃຫ້ APIs ສໍາລັບການຈັດການຟັງຊັນ (CreateFunction, UpdateFunctionCode) ແລະຄວບຄຸມວິທີທີ່ Lambda ສື່ສານກັບບໍລິການ AWS ອື່ນໆ. ຍົນຂໍ້ມູນຄວບຄຸມ Invoke API, ເຊິ່ງໃຊ້ຟັງຊັນ Lambda. ຫຼັງຈາກຟັງຊັນໃດໜຶ່ງຖືກເອີ້ນ, ຍົນຄວບຄຸມຈະຈັດສັນ ຫຼືເລືອກສະພາບແວດລ້ອມ runtime ທີ່ມີຢູ່ແລ້ວທີ່ກຽມໄວ້ລ່ວງໜ້າສໍາລັບຟັງຊັນນັ້ນ, ແລະຫຼັງຈາກນັ້ນປະຕິບັດລະຫັດໃນມັນ.

AWS Lambda ຮອງຮັບພາສາການຂຽນໂປລແກລມທີ່ຫຼາກຫຼາຍ, ລວມທັງ Java 8, Python 3.7, Go, NodeJS 8, .NET Core 2, ແລະອື່ນໆ, ຜ່ານສະພາບແວດລ້ອມເວລາແລ່ນຂອງເຂົາເຈົ້າ. AWS ປັບປຸງພວກມັນຢ່າງເປັນປົກກະຕິ, ແຈກຢາຍແຜ່ນປ້ອງກັນຄວາມປອດໄພ, ແລະປະຕິບັດກິດຈະກໍາບໍາລຸງຮັກສາອື່ນໆໃນສະພາບແວດລ້ອມເຫຼົ່ານີ້. Lambda ອະ​ນຸ​ຍາດ​ໃຫ້​ທ່ານ​ນໍາ​ໃຊ້​ພາ​ສາ​ອື່ນໆ​ເຊັ່ນ​ດຽວ​ກັນ​, ໃຫ້​ທ່ານ​ປະ​ຕິ​ບັດ runtime ທີ່​ເຫມາະ​ສົມ​ຕົວ​ທ່ານ​ເອງ​. ແລະຫຼັງຈາກນັ້ນທ່ານຈະຕ້ອງໄດ້ດູແລການບໍາລຸງຮັກສາຂອງມັນ, ລວມທັງການຕິດຕາມຄວາມປອດໄພຂອງມັນ.

ມັນເຮັດວຽກທັງຫມົດແນວໃດແລະການບໍລິການຈະປະຕິບັດຫນ້າທີ່ຂອງເຈົ້າແນວໃດ?

ແຕ່ລະຫນ້າທີ່ເຮັດວຽກຢູ່ໃນສະພາບແວດລ້ອມທີ່ອຸທິດຕົນຫນຶ່ງຫຼືຫຼາຍກວ່ານັ້ນ, ເຊິ່ງມີພຽງແຕ່ສໍາລັບຊີວິດຂອງຫນ້າທີ່ນັ້ນແລະຖືກທໍາລາຍ. ແຕ່ລະສະພາບແວດລ້ອມເຮັດໃຫ້ການໂທພຽງແຕ່ຄັ້ງດຽວ, ແຕ່ມັນຖືກນໍາໃຊ້ຄືນໃຫມ່ຖ້າຫາກວ່າມີການໂທ serial ຫຼາຍໄປຫາຫນ້າທີ່ດຽວກັນ. ສະພາບແວດລ້ອມ runtime ທັງຫມົດແລ່ນຢູ່ໃນເຄື່ອງ virtual ທີ່ມີຮາດແວ virtualization - ອັນທີ່ເອີ້ນວ່າ microVMs. microVM ແຕ່ລະອັນຖືກມອບໝາຍໃຫ້ບັນຊີ AWS ສະເພາະ ແລະສາມາດນຳໃຊ້ຄືນໄດ້ໂດຍສະພາບແວດລ້ອມເພື່ອປະຕິບັດໜ້າທີ່ຕ່າງກັນພາຍໃນບັນຊີນັ້ນ. MicroVMs ໄດ້ຖືກບັນຈຸເຂົ້າໃນການກໍ່ສ້າງຂອງແພລະຕະຟອມຮາດແວ Lambda Worker, ເຊິ່ງເປັນເຈົ້າຂອງແລະດໍາເນີນການໂດຍ AWS. ເວລາແລ່ນດຽວກັນບໍ່ສາມາດຖືກໃຊ້ໂດຍຟັງຊັນຕ່າງໆ, ຫຼື microVMs ເປັນເອກະລັກຂອງບັນຊີ AWS ທີ່ແຕກຕ່າງກັນ.

ຮູບແບບການໂດດດ່ຽວ AWS Lambda

ການໂດດດ່ຽວຂອງສະພາບແວດລ້ອມເວລາແລ່ນແມ່ນປະຕິບັດໂດຍໃຊ້ກົນໄກຫຼາຍຢ່າງ. ໃນລະດັບສູງສຸດຂອງແຕ່ລະສະພາບແວດລ້ອມມີສໍາເນົາແຍກຕ່າງຫາກຂອງອົງປະກອບດັ່ງຕໍ່ໄປນີ້:

• ລະຫັດຟັງຊັນ
• ຊັ້ນ Lambda ໃດຖືກເລືອກສໍາລັບຟັງຊັນ
• ສະພາບແວດລ້ອມການປະຕິບັດຫນ້າທີ່
• ພື້ນທີ່ຜູ້ໃຊ້ຫນ້ອຍທີ່ສຸດໂດຍອີງໃສ່ Amazon Linux

ກົນໄກຕໍ່ໄປນີ້ຖືກໃຊ້ເພື່ອແຍກສະພາບແວດລ້ອມການປະຕິບັດທີ່ແຕກຕ່າງກັນ:

• cgroups - ຈໍາກັດການເຂົ້າເຖິງ CPU, ຫນ່ວຍຄວາມຈໍາ, ການເກັບຮັກສາແລະຊັບພະຍາກອນເຄືອຂ່າຍສໍາລັບແຕ່ລະສະພາບແວດລ້ອມ runtime;
• namespaces - grouping process IDs, user IDs, network interfaces and other resources managed by the Linux kernel. ແຕ່ລະ runtime ແລ່ນຢູ່ໃນ namespace ຂອງຕົນເອງ;
• seccomp-bpf - ຈໍາກັດການໂທລະບົບທີ່ສາມາດນໍາໃຊ້ໃນເວລາແລ່ນ;
• iptables ແລະຕາຕະລາງ routing - ການໂດດດ່ຽວຂອງສະພາບແວດລ້ອມການປະຕິບັດຈາກກັນແລະກັນ;
• chroot - ສະຫນອງການເຂົ້າເຖິງຈໍາກັດກັບລະບົບໄຟລ໌ທີ່ຕິດພັນ.

ສົມທົບກັບເຕັກໂນໂລຊີການໂດດດ່ຽວຂອງ AWS, ກົນໄກເຫຼົ່ານີ້ຮັບປະກັນການແຍກເວລາແລ່ນທີ່ເຊື່ອຖືໄດ້. ສະພາບແວດລ້ອມທີ່ໂດດດ່ຽວດ້ວຍວິທີນີ້ບໍ່ສາມາດເຂົ້າເຖິງ ຫຼືແກ້ໄຂຂໍ້ມູນຈາກສະພາບແວດລ້ອມອື່ນໄດ້.

ເຖິງແມ່ນວ່າການແລ່ນຫຼາຍໆຄັ້ງຂອງບັນຊີ AWS ດຽວກັນສາມາດແລ່ນຢູ່ໃນ microVM ດຽວ, ພາຍໃຕ້ສະຖານະການໃດທີ່ microVM ສາມາດຖືກແບ່ງປັນລະຫວ່າງບັນຊີ AWS ທີ່ແຕກຕ່າງກັນ. AWS Lambda ໃຊ້ພຽງແຕ່ສອງກົນໄກເພື່ອແຍກ microVMs: EC2 instances ແລະ Firecracker. ການໂດດດ່ຽວຂອງແຂກໃນ Lambda ໂດຍອີງໃສ່ຕົວຢ່າງ EC2 ມີມາຕັ້ງແຕ່ປີ 2015. Firecracker ເປັນ hypervisor ແຫຼ່ງເປີດໃໝ່ທີ່ອອກແບບສະເພາະໂດຍ AWS ສຳລັບການໂຫຼດວຽກທີ່ບໍ່ມີເຊີບເວີ ແລະຖືກນຳສະເໜີໃນປີ 2018. ຮາດແວທາງກາຍະພາບທີ່ໃຊ້ microVMs ຖືກແບ່ງປັນລະຫວ່າງວຽກໃນທົ່ວບັນຊີຕ່າງໆ.

ປະຫຍັດສະພາບແວດລ້ອມແລະລັດຂະບວນການ

ເຖິງແມ່ນວ່າເວລາແລ່ນຂອງ Lambda ແມ່ນເປັນເອກະລັກຂອງຫນ້າທີ່ທີ່ແຕກຕ່າງກັນ, ພວກເຂົາສາມາດເອີ້ນຟັງຊັນດຽວກັນເລື້ອຍໆ, ຊຶ່ງຫມາຍຄວາມວ່າເວລາແລ່ນສາມາດຢູ່ລອດໄດ້ຫຼາຍຊົ່ວໂມງກ່ອນທີ່ຈະຖືກທໍາລາຍ.

ແຕ່ລະເວລາແລ່ນຂອງ Lambda ຍັງມີລະບົບໄຟລ໌ທີ່ສາມາດຂຽນໄດ້ຜ່ານລະບົບ /tmp directory. ເນື້ອໃນຂອງມັນບໍ່ສາມາດເຂົ້າເຖິງໄດ້ຈາກ runtime ອື່ນ. ເທົ່າທີ່ຄວາມຄົງຕົວຂອງຂະບວນການທີ່ກ່ຽວຂ້ອງ, ໄຟລ໌ທີ່ຂຽນໃສ່ /tmp ມີຢູ່ສໍາລັບວົງຈອນຊີວິດທັງຫມົດຂອງສະພາບແວດລ້ອມ runtime. ນີ້ອະນຸຍາດໃຫ້ຜົນໄດ້ຮັບຂອງການໂທຫຼາຍສະສົມ, ເຊິ່ງເປັນປະໂຫຍດໂດຍສະເພາະສໍາລັບການດໍາເນີນງານທີ່ມີລາຄາແພງເຊັ່ນການໂຫຼດຮູບແບບການຮຽນຮູ້ເຄື່ອງຈັກ.

ໂທໂອນຂໍ້ມູນ

Invoke API ສາມາດໃຊ້ໃນສອງໂໝດຄື: ໂໝດເຫດການ ແລະ ໂໝດຕອບສະໜອງຄຳຮ້ອງຂໍ. ໃນໂຫມດເຫດການ, ການໂທຈະຖືກເພີ່ມໃສ່ຄິວສໍາລັບການດໍາເນີນການຕໍ່ມາ. ໃນ​ຮູບ​ແບບ​ການ​ຕອບ​ສະ​ຫນອງ​ການ​ຮ້ອງ​ຂໍ​, ການ​ທໍາ​ງານ​ໄດ້​ຖືກ​ເອີ້ນ​ໃນ​ທັນ​ທີ​ທີ່​ມີ payload ສະ​ຫນອງ​ໃຫ້​, ຫຼັງ​ຈາກ​ນັ້ນ​ການ​ຕອບ​ສະ​ຫນອງ​ກັບ​ຄືນ​ມາ​. ໃນທັງສອງກໍລະນີ, ຫນ້າທີ່ເຮັດວຽກຢູ່ໃນສະພາບແວດລ້ອມ Lambda, ແຕ່ມີເສັ້ນທາງ payload ທີ່ແຕກຕ່າງກັນ.

ໃນລະຫວ່າງການໂທຫາການຕອບຮັບການຮ້ອງຂໍ, payload ໄຫຼຈາກ API ການປະມວນຜົນການຮ້ອງຂໍ (API Caller), ເຊັ່ນ AWS API Gateway ຫຼື AWS SDK, ໄປຫາ load balancer, ແລະຫຼັງຈາກນັ້ນໄປຫາການບໍລິການໂທ Lambda (ບໍລິການຮ້ອງຂໍ). ສຸດທ້າຍກໍານົດສະພາບແວດລ້ອມທີ່ເຫມາະສົມສໍາລັບການປະຕິບັດຫນ້າທີ່ແລະຜ່ານ payload ຢູ່ທີ່ນັ້ນເພື່ອເຮັດສໍາເລັດການໂທ. ຕົວດຸ່ນດ່ຽງການໂຫຼດໄດ້ຮັບການຈະລາຈອນທີ່ມີການປົກປ້ອງ TLS ຜ່ານອິນເຕີເນັດ. ການຈະລາຈອນພາຍໃນການບໍລິການ Lambda - ຫຼັງຈາກ load balancer - ຜ່ານ VPC ພາຍໃນໃນພາກພື້ນ AWS ສະເພາະ.

ຮູບແບບການປະມວນຜົນການໂທ AWS Lambda: ຮູບແບບການຮ້ອງຂໍ-ຕອບສະຫນອງ

ການໂທນັດໝາຍສາມາດເຮັດໄດ້ທັນທີ ຫຼືເພີ່ມໃສ່ຄິວ. ໃນບາງກໍລະນີ, ແຖວຖືກປະຕິບັດໂດຍໃຊ້ Amazon SQS (Amazon Simple Queue Service), ເຊິ່ງສົ່ງຕໍ່ການໂທໄປຫາບໍລິການການບັນລຸການໂທ Lambda ຜ່ານຂະບວນການ poller ພາຍໃນ. ການຈາລະຈອນທີ່ຖ່າຍທອດໄດ້ຖືກປົກປ້ອງໂດຍ TLS, ແລະບໍ່ມີການເຂົ້າລະຫັດເພີ່ມເຕີມຂອງຂໍ້ມູນທີ່ເກັບໄວ້ໃນ Amazon SQS.

ການໂທຫາເຫດການບໍ່ໄດ້ຕອບຄືນ - ພະນັກງານ Lambda ພຽງແຕ່ບໍ່ສົນໃຈຂໍ້ມູນການຕອບໂຕ້ໃດໆ. ການໂທທີ່ອີງໃສ່ເຫດການຈາກ Amazon S3, Amazon SNS, CloudWatch, ແລະແຫຼ່ງອື່ນໆແມ່ນດໍາເນີນການໂດຍ Lambda ໃນຮູບແບບເຫດການ. ການໂທຈາກ Amazon Kinesis ແລະ DynamoDB streams, SQS queues, Application Load Balancer, ແລະ API Gateway calls ຖືກປະມວນຜົນໃນຮູບແບບການຮ້ອງຂໍການຕອບຮັບ.

ການຕິດຕາມ

ທ່ານສາມາດຕິດຕາມ ແລະກວດສອບຟັງຊັນຂອງ Lambda ໂດຍໃຊ້ກົນໄກ ແລະການບໍລິການຂອງ AWS, ລວມທັງສິ່ງຕໍ່ໄປນີ້.

Amazon CloudWatch
ເກັບກໍາສະຖິຕິຕ່າງໆເຊັ່ນ: ຈໍານວນຄໍາຮ້ອງຂໍ, ໄລຍະເວລາຂອງການຮ້ອງຂໍ, ແລະຈໍານວນຄໍາຮ້ອງຂໍທີ່ລົ້ມເຫລວ.

Amazon CloudTrail
ອະນຸຍາດໃຫ້ທ່ານບັນທຶກ, ຕິດຕາມຢ່າງຕໍ່ເນື່ອງ, ແລະຮັກສາຂໍ້ມູນການເຄື່ອນໄຫວບັນຊີທີ່ກ່ຽວຂ້ອງກັບໂຄງສ້າງພື້ນຖານ AWS ຂອງທ່ານ. ທ່ານຈະມີປະຫວັດອັນຄົບຖ້ວນຂອງການປະຕິບັດທີ່ດໍາເນີນການໂດຍໃຊ້ AWS Management Console, AWS SDK, ເຄື່ອງມືບັນທັດຄໍາສັ່ງ, ແລະບໍລິການ AWS ອື່ນໆ.

AWS X-Ray
ສະຫນອງການເບິ່ງເຫັນຄົບຖ້ວນສົມບູນໃນທຸກຂັ້ນຕອນຂອງການດໍາເນີນການຮ້ອງຂໍໃນຄໍາຮ້ອງສະຫມັກຂອງທ່ານໂດຍອີງໃສ່ແຜນທີ່ຂອງອົງປະກອບພາຍໃນຂອງມັນ. ອະນຸຍາດໃຫ້ທ່ານວິເຄາະຄໍາຮ້ອງສະຫມັກໃນລະຫວ່າງການພັດທະນາແລະໃນສະພາບແວດລ້ອມການຜະລິດ.

ການຕັ້ງຄ່າ AWS
ທ່ານຈະສາມາດຕິດຕາມການປ່ຽນແປງຂອງການຕັ້ງຄ່າຟັງຊັນ Lambda (ລວມທັງການລຶບ) ແລະ runtimes, tags, handler names, code size, memory allocation, timeout settings and concurrency settings, as well as Lambda IAM execution role, subnetting, and security group bindings .

ສະຫລຸບ

AWS Lambda ສະເໜີຊຸດເຄື່ອງມືທີ່ມີປະສິດທິພາບໃນການສ້າງແອັບພລິເຄຊັນທີ່ປອດໄພ ແລະສາມາດຂະຫຍາຍໄດ້. ການປະຕິບັດຄວາມປອດໄພແລະການປະຕິບັດຕາມຈໍານວນຫຼາຍໃນ AWS Lambda ແມ່ນຄືກັນກັບການບໍລິການອື່ນໆຂອງ AWS, ເຖິງແມ່ນວ່າມີຂໍ້ຍົກເວັ້ນ. ມາຮອດເດືອນມີນາ 2019, Lambda ແມ່ນປະຕິບັດຕາມ SOC 1, SOC 2, SOC 3, PCI DSS, ການປະຕິບັດຕາມກົດໝາຍວ່າດ້ວຍປະກັນໄພສຸຂະພາບ ແລະ ຄວາມຮັບຜິດຊອບ (HIPAA), ແລະລະບຽບການອື່ນໆ. ດັ່ງນັ້ນ, ໃນເວລາທີ່ທ່ານກໍາລັງຄິດກ່ຽວກັບການປະຕິບັດຄໍາຮ້ອງສະຫມັກຕໍ່ໄປຂອງທ່ານ, ພິຈາລະນາການບໍລິການ AWS Lambda - ມັນອາດຈະເຫມາະສົມທີ່ສຸດສໍາລັບວຽກງານຂອງທ່ານ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com