ວິທີການ Serverless ສໍາລັບການພັດທະນາຢ່າງໄວວາຂອງການບໍລິການວິດີໂອທີ່ເຮັດວຽກ

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

ມອບໃຫ້: ບັນຊີຮາກກ່ຽວກັບ AWS, ບໍ່ມີຂໍ້ຈໍາກັດກ່ຽວກັບທາງເລືອກຂອງເຕັກໂນໂລຢີ stack, ຫນຶ່ງ backend, ແລະຫນຶ່ງເດືອນສໍາລັບການພັດທະນາ.

ໜ້າ ວຽກ: ປະຕິບັດການບໍລິການສົ່ງເສີມການຂາຍທີ່ຜູ້ໃຊ້ອັບໂຫລດຈາກຫນຶ່ງຫາສີ່ວິດີໂອທີ່ຍາວນານຈາກຫນຶ່ງຫາສີ່ວິນາທີ, ເຊິ່ງຫຼັງຈາກນັ້ນຈະຖືກຝັງຢູ່ໃນຊຸດວິດີໂອຕົ້ນສະບັບ.

ການຕັດສິນໃຈ

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

ການແກ້ໄຂມາດຕະຖານສໍາລັບການເຮັດວຽກກັບວິດີໂອແມ່ນ FFmpeg, ຜົນປະໂຫຍດຂອງ console ຂ້າມເວທີທີ່, ໂດຍຜ່ານການໂຕ້ຖຽງ, ອະນຸຍາດໃຫ້ທ່ານສາມາດຕັດແລະ overdub ສຽງ. ທັງໝົດທີ່ຍັງເຫຼືອໃຫ້ເຮັດແມ່ນຂຽນຫໍ່ ແລະປ່ອຍມັນເຂົ້າໄປໃນຊີວິດ. ພວກເຮົາຂຽນແບບຕົ້ນແບບທີ່ຕິດສອງວິດີໂອເຂົ້າກັນ, ແລະ... ຄວາມມ່ວນກໍ່ເລີ່ມຂຶ້ນ. ຫ້ອງສະຫມຸດແມ່ນອີງໃສ່ .NET Core 2, ມັນຄວນຈະດໍາເນີນການຢູ່ໃນເຄື່ອງ virtual ໃດ, ດັ່ງນັ້ນພວກເຮົາເອົາຕົວຢ່າງ AWS EC2 ແລະທຸກສິ່ງທຸກຢ່າງຈະເຮັດວຽກ.

ຂໍ້ຄວາມທີ່ເຊື່ອງໄວ້ບໍ່, ມັນຈະບໍ່ເຮັດວຽກ
.
ເຖິງແມ່ນວ່າ FFmpeg ເຮັດໃຫ້ວຽກງານງ່າຍຂຶ້ນ, ສໍາລັບການແກ້ໄຂທີ່ເຮັດວຽກຢ່າງແທ້ຈິງ, ທ່ານຈໍາເປັນຕ້ອງສ້າງຕົວຢ່າງ EC2 ແລະອອກແບບໂຄງສ້າງເຄືອຂ່າຍສໍາລັບມັນ, ລວມທັງ Load Balancer. ວຽກງານທີ່ງ່າຍດາຍຂອງການປະຕິບັດຈາກຈຸດເລີ່ມຕົ້ນກາຍເປັນ "ເລັກນ້ອຍ" ສັບສົນ, ແລະໂຄງສ້າງພື້ນຖານເລີ່ມຕົ້ນທີ່ຈະຕ້ອງການເງິນທັນທີ - ທຸກໆຊົ່ວໂມງຈໍານວນເງິນສໍາລັບການແລ່ນແມ່ນຖອນອອກຈາກບັນຊີລູກຄ້າ.

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

ໂດຍວິທີທາງການ, ເຖິງວ່າຈະມີຄວາມບໍ່ມັກຢ່າງຈະແຈ້ງຂອງນັກພັດທະນາ AWS ສໍາລັບ .NET, ພວກເຂົາສະຫນັບສະຫນູນ .NET Core 2.1 ເປັນ runtime, ເຊິ່ງສະຫນອງໂອກາດການພັດທະນາຢ່າງເຕັມທີ່.

ແລະ cherry ໃນ cake - AWS ໃຫ້ບໍລິການແຍກຕ່າງຫາກສໍາລັບການເຮັດວຽກກັບໄຟລ໌ວິດີໂອ - AWS Elemental MediaConvert .

ໂດຍເນື້ອແທ້ແລ້ວຂອງການເຮັດວຽກແມ່ນງ່າຍດາຍ incredibly: ພວກເຮົາເອົາການເຊື່ອມຕໍ່ S3 ກັບວິດີໂອອອກ, ຂຽນຜ່ານ AWS Console, .NET SDK ຫຼືພຽງແຕ່ JSON ສິ່ງທີ່ພວກເຮົາຕ້ອງການທີ່ຈະເຮັດແນວໃດກັບວິດີໂອແລະໂທຫາການບໍລິການ. ມັນຕົວມັນເອງປະຕິບັດຄິວສໍາລັບການປະມວນຜົນຄໍາຮ້ອງຂໍທີ່ເຂົ້າມາ, ອັບໂຫລດຜົນໄດ້ຮັບໄປຫາ S3 ຕົວມັນເອງແລະ, ສໍາຄັນທີ່ສຸດ, ສ້າງເຫດການ CloudWatch ສໍາລັບການປ່ຽນແປງສະຖານະພາບແຕ່ລະຄົນ. ນີ້ອະນຸຍາດໃຫ້ພວກເຮົາປະຕິບັດ lambda triggers ເພື່ອສໍາເລັດການປະມວນຜົນວິດີໂອ.

ນີ້ແມ່ນສິ່ງທີ່ສະຖາປັດຕະຍະກໍາສຸດທ້າຍເບິ່ງຄືວ່າ:

backend ທັງຫມົດແມ່ນຕັ້ງຢູ່ໃນສອງ lambdas. ອີກອັນຫນຶ່ງແມ່ນສໍາລັບການຫມຸນວິດີໂອຕັ້ງ, ເນື່ອງຈາກວ່າການເຮັດວຽກດັ່ງກ່າວບໍ່ສາມາດເຮັດໄດ້ໃນຫນຶ່ງຜ່ານ.

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

ຜິດພະລາດ

• AWS MediaConvert, ສໍາລັບບາງເຫດຜົນທີ່ບໍ່ຮູ້ຈັກ, ພຽງແຕ່ໃຊ້ສຽງກັບແຕ່ລະຊິ້ນວິດີໂອແຍກຕ່າງຫາກ, ແຕ່ພວກເຮົາຕ້ອງການເພງທີ່ຊື່ນຊົມຈາກຫນ້າຈໍທັງຫມົດ.
• ວິດີໂອແນວຕັ້ງຕ້ອງໄດ້ຮັບການປະມວນຜົນແຍກຕ່າງຫາກ. AWS ບໍ່ມັກແຖບສີດຳ ແລະວາງລູກກິ້ງຢູ່ທີ່ 90°.

ເດີ່ນສະເກັດງ່າຍ

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

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

ລວມ

Serverless ບໍ່ແມ່ນ panacea. ແຕ່ມັນຈະເຮັດໃຫ້ຊີວິດງ່າຍຂຶ້ນຫຼາຍໃນສະຖານະການທີ່ມີສາມຂໍ້ຈໍາກັດ: "ຊັບພະຍາກອນຈໍາກັດ - ໄລຍະສັ້ນ - ເງິນຫນ້ອຍ."

ຄຸນລັກສະນະຂອງແອັບພລິເຄຊັນທີ່ເຫມາະສົມສໍາລັບ Serverless

• ໂດຍບໍ່ມີການຂະບວນການແລ່ນຍາວ. API Gateway hard limit ແມ່ນ 29 ວິນາທີ, lambda hard limit ແມ່ນ 5 ນາທີ;
• ອະທິບາຍໂດຍສະຖາປັດຕະຍະກໍາເຫດການ;
• ແບ່ງອອກເປັນສ່ວນປະສົມທີ່ວ່າງໆເຊັ່ນ SOA;
• ບໍ່ຮຽກຮ້ອງໃຫ້ມີການເຮັດວຽກຫຼາຍກັບສະພາບຂອງທ່ານ;
• ຂຽນໃນ .NET Core. ເພື່ອເຮັດວຽກກັບ .NET Framework, ທ່ານຍັງຕ້ອງການ Docker ຢ່າງຫນ້ອຍກັບ runtime ທີ່ເຫມາະສົມ.

ຜົນປະໂຫຍດຂອງວິທີການ Serverless

• ຫຼຸດຜ່ອນຄ່າໃຊ້ຈ່າຍພື້ນຖານໂຄງລ່າງ;
• ຫຼຸດຜ່ອນຄ່າໃຊ້ຈ່າຍໃນການສະຫນອງການແກ້ໄຂ;
• ຂະຫຍາຍອັດຕະໂນມັດ;
• ການ​ພັດ​ທະ​ນາ​ໃນ​ຂອບ​ເຂດ​ຕັດ​ຂອງ​ຄວາມ​ຄືບ​ຫນ້າ​ຂອງ​ເຕັກ​ໂນ​ໂລ​ຊີ​.

ຂໍ້ເສຍ, ມີຕົວຢ່າງສະເພາະ

• ການແຈກຢາຍການຕິດຕາມ ແລະການບັນທຶກ - ແກ້ໄຂບາງສ່ວນຜ່ານ AWS X-Ray ແລະ AWS CloudWatch;
• ການດີບັກທີ່ບໍ່ສະດວກ;
• Cold Start ໃນເວລາທີ່ບໍ່ມີການໂຫຼດ;
• ການໂຕ້ຕອບຜູ້ໃຊ້-hostile AWS ແມ່ນບັນຫາທົ່ວໄປ :)

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