ຄອມພິວເຕີ້ຄລາວທີ່ຖືກອະທິບາຍ: 11 ແນວຄິດທາງສະຖາປັດຕະຍະກຳທີ່ທ່ານຕ້ອງຮູ້ (4K Masterclass).

ສິ່ງທີ່ວິດີໂອນີ້ກວມເອົາ

• - ກຳແພງສະຖາປັດຕະຍະກຳ & ແຜນຜັງແມ່ແບບ
• - 01. ການຂະຫຍາຍຕາມແນວຕັ້ງ ທຽບກັບ ແນວນອນ
• - 02. ສະຖາປັດຕະຍະກຳການດຸ່ນດ່ຽງການໂຫຼດ (L4 ທຽບກັບ L7 & ການກວດສຸຂະພາບ)
• - 03. ການປັບຂະໜາດອັດຕະໂນມັດ & ຄວາມຢືດຢຸ່ນ
• - 04. Serverless (FaaS & Firecracker MicroVMs)

ບົດບັນທຶກທີ່ແປແລ້ວ

ແປຈາກຄຳບັນຍາຍຕົ້ນສະບັບພາສາອັງກິດ. ສຽງ ແລະ ຄຳບັນຍາຍທີ່ມີໃຫ້ແມ່ນຄວບຄຸມໂດຍ YouTube.

- ກຳແພງສະຖາປັດຕະຍະກຳ & ແຜນຜັງແມ່ແບບ

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

0:34 ໃນຫ້ອງຮຽນຕົ້ນສະບັບນີ້, ພວກເຮົາຈະອະທິບາຍແຜນການວິສາຫະກິດທັງໝົດ: ຈາກ ການຂະໜາດ ແລະ ການດຸ່ນດ່ຽງການໂຫຼດ ໄປສູ່ serverless, ການຕັດການເຊື່ອມຕໍ່ແບບ event-driven, ລຳດັບຊັ້ນການຈັດເກັບຂໍ້ມູນ, ແລະ ເຄືອຂ່າຍຄລາວ. ເຂົ້າໃຈແນວຄິດສິບເອັດຂໍ້ນີ້, ແລະທ່ານສາມາດອອກແບບ backend ໃດກໍໄດ້ໃນ AWS, GCP, ຫຼື Azure. ນີ້ແມ່ນ The Daily Diff, ເບື້ອງຫຼັງ.

- 01. ການຂະຫຍາຍຕາມແນວຕັ້ງ ທຽບກັບ ແນວນອນ

0:57 ແນວຄິດທີໜຶ່ງ: ການຂະໜາດ. ເມື່ອແອັບພລິເຄຊັນຂອງທ່ານປະສົບກັບການຈະລາຈອນທີ່ເພີ່ມຂຶ້ນ, ທ່ານມີສອງວິທີທີ່ແຕກຕ່າງກັນພື້ນຖານ ໃນການຈັດການການໂຫຼດ: ການຂະໜາດຕາມແນວຕັ້ງ, ຫຼື ການຂະໜາດຕາມແນວນອນ. ການຂະໜາດຕາມແນວຕັ້ງ, ຫຼື ການຂະໜາດຂຶ້ນ, ໝາຍເຖິງການນຳໃຊ້ເຄື່ອງຈັກ ທີ່ມີຢູ່ຂອງທ່ານ ແລະ ເພີ່ມຊັບພະຍາກອນ: ການຍົກລະດັບຈາກສີ່ ແກນ CPU ເປັນສາມສິບສອງ, ຫຼື ການປ່ຽນ RAM ສາມສິບສອງກິກະໄບສ໌ ເປັນ ໜຶ່ງຮ້ອຍຊາວແປດ. ການຂະໜາດຕາມແນວຕັ້ງບໍ່ຈຳເປັນຕ້ອງມີການປ່ຽນແປງທາງສະຖາປັດຕະຍະກຳ: ລະຫັດຂອງທ່ານ

1:28 ແລະຖານຂໍ້ມູນຍັງຄືເກົ່າ. ແຕ່ວ່າມັນຈະພົບກັບຂໍ້ຈຳກັດຂອງຮາດແວທີ່ໂຫດຮ້າຍ. ບໍ່ມີເຄື່ອງຈັກດຽວໃນໂລກທີ່ມີສິບພັນແກນ CPU, ແລະ instance ຊັ້ນສູງມີລາຄາທີ່ເພີ່ມຂຶ້ນຢ່າງຫຼວງຫຼາຍ. ການຂະໜາດຕາມແນວນອນ, ຫຼື ການຂະໜາດອອກ, ໝາຍເຖິງການຮັກສາເຊີບເວີຂອງທ່ານ ໃຫ້ມີຂະໜາດນ້ອຍ ແລະ ລາຄາຖືກ, ແຕ່ເປີດໃຊ້ຫຼາຍ instance ພ້ອມກັນຢູ່ເບື້ອງຫຼັງ router. ຖ້າ instance ໜຶ່ງລົ້ມ, ໂນດທີ່ເຫຼືອຈະດູດຊຶມການຈະລາຈອນໂດຍບໍ່ມີ ການຢຸດເຮັດວຽກ. ກົດທອງຂອງການຂະໜາດຕາມແນວນອນແມ່ນ

2:01 statelessness: ເຊີບເວີແອັບພລິເຄຊັນຂອງທ່ານບໍ່ສາມາດເກັບ session ຜູ້ໃຊ້, ໄຟລ໌ທີ່ອັບໂຫຼດ, ຫຼື state ຢູ່ໃນດິສກ໌ພາຍໃນຂອງພວກມັນໄດ້. State ຕ້ອງຢູ່ໃນຖານຂໍ້ມູນພາຍນອກ ຫຼື cache, ເຮັດໃຫ້ໂນດໃດກໍໄດ້ສາມາດຈັດການການຮ້ອງຂໍຂອງຜູ້ໃຊ້ໃດກໍໄດ້.

- 02. ສະຖາປັດຕະຍະກຳການດຸ່ນດ່ຽງການໂຫຼດ (L4 ທຽບກັບ L7 & ການກວດສຸຂະພາບ)

2:17 ແນວຄິດທີສອງ: ການດຸ່ນດ່ຽງການໂຫຼດ. ການຂະໜາດຕາມແນວນອນເບິ່ງຄືຈະດີໃນທາງທິດສະດີ, ແຕ່ວ່າມັນກໍນຳມາເຊິ່ງບັນຫາທັນທີ: ເມື່ອຜູ້ໃຊ້ສິບພັນຄົນເຂົ້າເຖິງຊື່ໂດເມນຂອງທ່ານ, ເຊີບເວີສະເພາະໃດທີ່ຈະໄດ້ຮັບການຈະລາຈອນຂອງພວກເຂົາ? Load balancer ເຮັດໜ້າທີ່ເປັນ reverse proxy ທີ່ຢູ່ລະຫວ່າງອິນເຕີເນັດສາທາລະນະ ແລະ private backend cluster ຂອງທ່ານ. ມັນຮັບການເຊື່ອມຕໍ່ TCP ຫຼື HTTP ທີ່ເຂົ້າມາ ແລະ ແຈກຢາຍການຮ້ອງຂໍໄປຫາ instance ທີ່ມີສຸຂະພາບດີຂອງທ່ານ.

2:47 Load balancer ປະຕິບັດງານຢູ່ສອງຊັ້ນເຄືອຂ່າຍຫຼັກ. Layer 4 Network Load Balancers ປະຕິບັດງານຢູ່ຊັ້ນ transport layer, ການກຳນົດເສັ້ນທາງຂອງແພັກເກັດ TCP ແລະ UDP ດິບໂດຍອີງໃສ່ທີ່ຢູ່ IP ແລະ port ດ້ວຍ latency ລະດັບ microsecond ແລະ ການຮ້ອງຂໍຫຼາຍລ້ານຄັ້ງຕໍ່ວິນາທີ. Layer 7 Application Load Balancers ກວດສອບໂປໂຕຄອນ HTTP ດ້ວຍຕົວມັນເອງ: ອ່ານເສັ້ນທາງ URL, request headers, cookies, ແລະ HTTP methods. ນີ້ເຮັດໃຫ້ການກຳນົດເສັ້ນທາງໂດຍອີງໃສ່ເສັ້ນທາງ: ສົ່ງການຮ້ອງຂໍ slash-api ໄປຫາ backend cluster ຂອງທ່ານ ແລະ ການຮ້ອງຂໍ slash-static ໄປຫາ

3:25 object store. ທີ່ສຳຄັນ, load balancer ປະຕິບັດການກວດສຸຂະພາບຢ່າງຫ້າວຫັນ. ທຸກໆສອງສາມວິນາທີ, balancer ຈະ ping ປາຍທາງສຸຂະພາບໃນທຸກໆ instance. ຖ້າ instance ພົບບັນຫາຫ້າຮ້ອຍຂໍ້ຜິດພາດຕິດຕໍ່ກັນສາມຄັ້ງ ຫຼື ບໍ່ຕອບສະໜອງ, ມັນຈະຖືກນຳອອກຈາກ pool ໂດຍອັດຕະໂນມັດໂດຍບໍ່ມີ ການຮ້ອງຂໍໃດໆທີ່ຕົກຄ້າງ.

- 03. ການປັບຂະໜາດອັດຕະໂນມັດ & ຄວາມຢືດຢຸ່ນ

3:45 ແນວຄິດທີສາມ: ການປັບຂະໜາດອັດຕະໂນມັດ. ຖ້າແອັບເວັບຂອງທ່ານຕ້ອງການສອງເຊີບເວີໃນເວລາສາມໂມງເຊົ້າ, ແຕ່ຊາວເຊີບເວີໃນລະຫວ່າງການເປີດຕົວຕອນທ່ຽງ, ການຄລິກປຸ່ມດ້ວຍຕົນເອງໃນ cloud console ແມ່ນວິທີທີ່ຮັບປະກັນການຢຸດເຮັດວຽກ ແລະ ການລົ້ມລະລາຍ. ການປັບຂະໜາດອັດຕະໂນມັດນຳມາເຊິ່ງຄວາມຢືດຢຸ່ນແບບໄດນາມິກໃຫ້ກັບ server pool ແບບແນວນອນ. ກຸ່ມການປັບຂະໜາດອັດຕະໂນມັດຕິດຕາມ metrics ປະສິດທິພາບເຊັ່ນ: ການນຳໃຊ້ CPU ໂດຍສະເລ່ຍ, ເຄືອຂ່າຍ I-O, ຫຼື ຄວາມເລິກຂອງ backlog ໃນຄິວ. ເມື່ອ CPU ໂດຍສະເລ່ຍເກີນຂອບເຂດທີ່ກຳນົດໄວ້ – ເຊັ່ນ,

4:19 ເຈັດສິບເປີເຊັນຕິດຕໍ່ກັນສາມນາທີ – autoscaler ຈະເປີດໃຊ້ງານ ເຄື່ອງ virtual ໃໝ່ໂດຍອັດຕະໂນມັດ, ລົງທະບຽນພວກມັນກັບ load balancer ຂອງທ່ານ, ແລະເລີ່ມຕົ້ນການກຳນົດເສັ້ນທາງການຈະລາຈອນ. ທີ່ສຳຄັນບໍ່ແພ້ກັນແມ່ນການປັບຂະໜາດເຂົ້າ: ເມື່ອຄື້ນການຈະລາຈອນຫຼຸດລົງ, autoscaler ຈະຢຸດ instance ສ່ວນເກີນເພື່ອໃຫ້ທ່ານຢຸດການຈ່າຍເງິນສຳລັບ ການຄຳນວນທີ່ບໍ່ໄດ້ໃຊ້. ເພື່ອປ້ອງກັນການ flapping – ເຊິ່ງເຊີບເວີຖືກສ້າງແລະ ທຳລາຍຢ່າງໄວວາໃນ loop ທີ່ບໍ່ສິ້ນສຸດ – ຜູ້ວາງແຜນຄລາວຈະກຳນົດ ໄລຍະເວລາ cooldown. ແນວຄິດທີສີ່: Serverless.

- 04. Serverless (FaaS & Firecracker MicroVMs)

4:53 ເປັນເວລາຫຼາຍປີ, ທີມງານການຕະຫຼາດໄດ້ໂຄສະນາ serverless ເປັນລະຫັດວິເສດ ທີ່ເຮັດວຽກຢູ່ເທິງຟ້າ. ໃນຄວາມເປັນຈິງ, serverless ຍັງໃຊ້ເຊີບເວີ – ແຕ່ທ່ານບໍ່ໄດ້ເປັນເຈົ້າຂອງ, ແກ້ໄຂ, ຫຼື ຈ່າຍເງິນໃຫ້ພວກມັນເມື່ອບໍ່ມີລະຫັດເຮັດວຽກ. ດ້ວຍ Function-as-a-Service ເຊັ່ນ AWS Lambda ຫຼື Google Cloud Functions, ທ່ານຂຽນຟັງຊັນ handler ແບບສະແຕນດ໌ໂອລົນ. ເມື່ອມີການຮ້ອງຂໍ HTTP, ການອັບໂຫຼດໄຟລ໌ S3, ຫຼື ການປ່ຽນແປງຖານຂໍ້ມູນ ເກີດຂຶ້ນ, cloud runtime ຈະເປີດເຄື່ອງ

5:23 micro-virtual-machine ທີ່ບໍ່ຖາວອນເຊັ່ນ Firecracker ໃນເວລາບໍ່ເຖິງຫ້າມິນລິວິນາທີ. ລະຫັດຂອງທ່ານຈະຖືກປະຕິບັດ, ສົ່ງຄືນການຕອບສະໜອງ, ແລະປິດລົງ. ຖ້າບໍ່ມີໃຜເຂົ້າເບິ່ງເວັບໄຊທ໌ຂອງທ່ານເປັນເວລາສາມເດືອນ, ໃບບິນຄ່າຄຳນວນຂອງທ່ານແມ່ນ ສູນໂດລາ ແລະ ສູນເຊັນ. ຖ້າຜູ້ໃຊ້ໜຶ່ງລ້ານຄົນເຂົ້າເຖິງມັນພ້ອມກັນ, ຜູ້ໃຫ້ບໍລິການຈະເປີດໃຊ້ງານ microVMs ພ້ອມກັນໜຶ່ງລ້ານເຄື່ອງ. ຂໍ້ແລກປ່ຽນທາງວິສະວະກຳແມ່ນມີຢູ່ຈິງ: cold start latency ເມື່ອເປີດໃຊ້ runtime ໃໝ່, ຂໍ້ຈຳກັດການປະຕິບັດສິບຫ້ານາທີທີ່ເຄັ່ງຄັດ ໃນ Lambda, ແລະ statelessness ທີ່ເຄັ່ງຄັດ.

5:55 Serverless ແມ່ນດີທີ່ສຸດສຳລັບ event pipelines ແລະ sporadic APIs, ແຕ່ບໍ່ເໝາະສົມສຳລັບ WebSockets ທີ່ຄົງທີ່ ຫຼື ການຝຶກອົບຮົມຫຼາຍຊົ່ວໂມງ.

- 05. ສະຖາປັດຕະຍະກຳທີ່ຂັບເຄື່ອນດ້ວຍເຫດການ (EDA & ການຕັດການເຊື່ອມຕໍ່)

6:05 ແນວຄິດທີຫ້າ: ສະຖາປັດຕະຍະກຳທີ່ຂັບເຄື່ອນດ້ວຍເຫດການ, ຫຼື EDA. ໃນສະຖາປັດຕະຍະກຳແບບດັ້ງເດີມ, ບໍລິການຕິດຕໍ່ສື່ສານແບບ synchronously. ບໍລິການ checkout ຂອງທ່ານໂທຫາ payment, payment ໂທຫາ inventory, inventory ໂທຫາ fraud, ແລະ fraud ໂທຫາ email. ນີ້ສ້າງ cascade of doom ແບບ synchronous. ຖ້າຜູ້ໃຫ້ບໍລິການອີເມວພາກສ່ວນທີສາມປະສົບບັນຫາເຄືອຂ່າຍ ແລະ ໃຊ້ເວລາສິບ ວິນາທີໃນການຕອບສະໜອງ, ການຮ້ອງຂໍ checkout ທັງໝົດຂອງລູກຄ້າຂອງທ່ານຈະໝົດເວລາດ້ວຍ ຂໍ້ຜິດພາດ. ໃນສະຖາປັດຕະຍະກຳທີ່ຂັບເຄື່ອນດ້ວຍເຫດການ, ບໍລິການຕ່າງໆຈະຖືກຕັດການເຊື່ອມຕໍ່ຢ່າງສົມບູນ.

6:37 ເມື່ອລູກຄ້າຄລິກຊື້, ບໍລິການ checkout ຈະບໍ່ໂທຫາບໍລິການ ລຸ່ມນ້ຳ. ມັນພຽງແຕ່ເຜີຍແຜ່ເຫດການທີ່ເອີ້ນວ່າ OrderPlaced ໄປຫາ Event Bus ສູນກາງເຊັ່ນ Amazon EventBridge ຫຼື SNS topic. ການ checkout ສໍາເລັດໃນຫ້າສິບມິນລິວິນາທີ. ພະນັກງານລຸ່ມນ້ຳສຳລັບການຊຳລະເງິນ, ການຫັກສິນຄ້າຄົງຄັງ, ແລະໃບຮັບເງິນທາງອີເມວ ດຶງຂໍ້ຄວາມຢ່າງເປັນເອກະລາດຈາກ SQS queues ທີ່ອຸທິດໃຫ້ແກ່ພວກເຂົາ. ຖ້າບໍລິການອີເມວລົ້ມເຫຼວເປັນເວລາໜຶ່ງຊົ່ວໂມງ, ຂໍ້ຄວາມຈະລໍຖ້າຢ່າງປອດໄພ ຖືກ buffer ໄວ້ໃນ queue ໂດຍບໍ່ມີການຕົກຄ້າງຄຳສັ່ງດຽວ.

- 06. ການຈັດການຄອນເທນເນີ (Docker & Kubernetes)

7:13 ແນວຄິດທີຫົກ: Container Orchestration. Docker ແກ້ໄຂບັນຫາການຫຸ້ມຫໍ່: ມັນຫຸ້ມຫໍ່ລະຫັດແອັບພລິເຄຊັນຂອງທ່ານ, system libraries, configuration, ແລະ runtime ເຂົ້າໄປໃນ image ທີ່ບໍ່ປ່ຽນແປງເຊິ່ງເຮັດວຽກໄດ້ຄືກັນກັບໃນ MacBook ຂອງທ່ານ ແລະ ໃນຄລາວ. ແຕ່ການຫຸ້ມຫໍ່ container ແມ່ນງ່າຍ. ການເປີດໃຊ້ຫ້າຮ້ອຍ container ໃນຫ້າສິບເຄື່ອງ virtual ທາງກາຍະພາບແມ່ນບ່ອນທີ່ ການວາງແຜນພັງທະລາຍ. ນັ້ນຄືເຫດຜົນທີ່ orchestrator container ເຊັ່ນ Kubernetes ແລະ AWS ECS

7:41 ມີຢູ່. orchestrator ໃຫ້ control plane: API server, etcd state store, ແລະ scheduler ທີ່ສະຫຼາດ. ທ່ານປະກາດ desired state ຂອງທ່ານ: ຂ້ອຍຕ້ອງການສິບ replicas ຂອງ ບໍລິການ authentication ຂອງຂ້ອຍທີ່ມີ RAM ສອງກິກະໄບສ໌ແຕ່ລະອັນ. scheduler ຈະກວດສອບ cluster, ວາງ pods ໃສ່ nodes ທີ່ມີ memory ຫວ່າງ, ຕັ້ງຄ່າເຄືອຂ່າຍພາຍໃນ, ແລະ ສືບຕໍ່ປັບປ່ຽນຄວາມເປັນຈິງ. ຖ້າ node ປະສົບບັນຫາຮາດແວ, Kubernetes ຈະກວດພົບການ ສູນເສຍ ແລະ ຈັດຕາຕະລາງ pods ທີ່ຖືກຍົກຍ້າຍທັງໝົດຄືນໃໝ່ທັນທີໃສ່

- 07. 4 ເສົາຫຼັກການເກັບຂໍ້ມູນຄລາວ (S3, EBS, DBs & Redis)

8:16 nodes ທີ່ມີສຸຂະພາບດີ. ແນວຄິດທີເຈັດ: ລຳດັບຊັ້ນການເກັບຂໍ້ມູນຄລາວ. ຜູ້ເລີ່ມຕົ້ນມັກຈະຖືວ່າການເກັບຂໍ້ມູນຄລາວເປັນຖັງດຽວທີ່ທ່ານຖິ້ມ ໄຟລ໌. ໃນສະຖາປັດຕະຍະກຳການຜະລິດ, ການເກັບຂໍ້ມູນຖືກແບ່ງອອກເປັນສີ່ເສົາຫຼັກ ທີ່ແຕກຕ່າງກັນໂດຍອີງໃສ່ຮູບແບບການເຂົ້າເຖິງ ແລະ latency. ທຳອິດແມ່ນ Object Storage, ເຊັ່ນ Amazon S3 ຫຼື Google Cloud Storage. ທ່ານເຂົ້າເຖິງໄຟລ໌ຜ່ານ HTTP REST APIs ໂດຍໃຊ້ ການໂທ PUT ແລະ GET ທີ່ງ່າຍດາຍ. ມັນສະໜອງຄວາມສາມາດຕາມແນວນອນທີ່ບໍ່ຈຳກັດໃນລາຄາສອງເຊັນຕໍ່ກິກະໄບສ໌ຕໍ່ເດືອນ,

8:49 ເຮັດໃຫ້ມັນເໝາະສຳລັບວິດີໂອ, ການອັບໂຫຼດຂອງຜູ້ໃຊ້, logs, ແລະ backups. ທີສອງແມ່ນ Block Storage, ເຊັ່ນ Amazon EBS. ເຫຼົ່ານີ້ແມ່ນ virtual hard drives ທີ່ຖືກຕິດຕັ້ງໂດຍກົງໃສ່ virtual machine ສະເພາະຜ່ານ high-speed interconnects. ພວກມັນຖືກຟໍແມັດເປັນ filesystems ມາດຕະຖານເຊັ່ນ ext4, ຮອງຮັບການເຂົ້າເຖິງການອ່ານ ແລະ ຂຽນແບບ random ທີ່ໄວເຊິ່ງຕ້ອງການໂດຍ database engines. ທີສາມແມ່ນ Managed Databases: relational engines ເຊັ່ນ PostgreSQL ໃນ RDS ທີ່ໃຫ້ ACID transactions ແລະ complex joins,

9:21 ແລະ NoSQL engines ເຊັ່ນ DynamoDB ທີ່ໃຫ້ latency ລະດັບ millisecond ຕົວເລກດຽວໃນຂະໜາດໃຫຍ່. ແລະທີສີ່ແມ່ນ In-Memory Caches ເຊັ່ນ Redis. ການອ່ານຂໍ້ມູນຈາກ RAM ໃຊ້ເວລາ microseconds ແທນທີ່ຈະເປັນ milliseconds. Caches ຕັ້ງຢູ່ໜ້າຖານຂໍ້ມູນຂອງທ່ານ, ປົກປ້ອງມັນຈາກການຈະລາຈອນການອ່ານຊ້ຳໆ ແລະ ການຈັດການ volatile user session tokens.

- 08. ຄວາມພ້ອມໃຊ້ງານສູງ & ຕົວເລກເກົ້າ (Multi-AZ Failover)

9:44 ແນວຄິດທີແປດ: High Availability, ຫຼື HA. Availability ຕອບຄຳຖາມດຽວ: ເປີເຊັນເທົ່າໃດຂອງເວລາທີ່ ແອັບພລິເຄຊັນຂອງທ່ານເຮັດວຽກ ແລະ ຜູ້ໃຊ້ສາມາດເຂົ້າເຖິງໄດ້? ໃນສັນຍາວິສາຫະກິດ, availability ຖືກວັດແທກເປັນ nines. ສອງ nines, ຫຼື ຄວາມພ້ອມໃຊ້ງານເກົ້າສິບເກົ້າເປີເຊັນ, ອະນຸຍາດໃຫ້ມີເວລາ ຢຸດເຮັດວຽກຫຼາຍກວ່າສາມວັນເຄິ່ງຕໍ່ປີ. ສີ່ nines ຫຼຸດເວລາຢຸດເຮັດວຽກທີ່ອະນຸຍາດລົງເຫຼືອຫ້າສິບສອງນາທີ, ແລະ ຫ້າ nines ອະນຸຍາດໃຫ້ມີເວລາຢຸດເຮັດວຽກທັງໝົດພຽງຫ້ານາທີຕໍ່

10:15 ປີ. ເພື່ອບັນລຸ high availability, ທ່ານຕ້ອງກຳຈັດຈຸດລົ້ມເຫຼວດຽວ ໃນທົ່ວ fault domains. ໃນຄລາວ, ນັ້ນໝາຍເຖິງການນຳໃຊ້ໃນທົ່ວຫຼາຍ Availability Zones. Availability Zone ບໍ່ແມ່ນ rack ດຽວ: ມັນແມ່ນສູນຂໍ້ມູນທາງກາຍະພາບ ທີ່ແຕກຕ່າງກັນໜຶ່ງ ຫຼື ຫຼາຍແຫ່ງທີ່ຢູ່ຫ່າງກັນຫຼາຍໄມລ໌ດ້ວຍພະລັງງານ ແລະ ລະບົບເຮັດຄວາມເຢັນທີ່ເປັນເອກະລາດ. ໂດຍການເປີດໃຊ້ instance ທີ່ຫ້າວຫັນໃນ Zone A ແລະ Zone B ດ້ວຍ ການສຳເນົາຖານຂໍ້ມູນແບບ synchronous, ຟ້າຜ່າ ຫຼື ສາຍໃຍແກ້ວນຳແສງທີ່ ເຮັດໃຫ້ສິ່ງອໍານວຍຄວາມສະດວກທາງກາຍະພາບທັງໝົດລົ້ມເຫຼວຈະສົ່ງຜົນໃຫ້ເກີດ failover ອັດຕະໂນມັດ.

10:50 ໃນສາມສິບວິນາທີ ໂດຍບໍ່ມີການແຊກແຊງຂອງມະນຸດ.

- 09. ຄວາມທົນທານ ທຽບກັບ ຄວາມພ້ອມໃຊ້ງານ (ເປັນຫຍັງ 11 ເກົ້າຈຶ່ງບໍ່ແມ່ນ Uptime)

10:53 ແນວຄິດທີ 9: ຄວາມທົນທານທຽບກັບຄວາມພ້ອມໃຊ້ງານ. ນີ້ຄືກັບດັກແນວຄິດທີ່ພົບຫຼາຍທີ່ສຸດໃນການສຳພາດສະຖາປັດຕະຍະກຳຄລາວ ວິສະວະກອນມັກຈະໃຊ້ຄຳສັບທີ່ສາມາດໃຊ້ແທນກັນໄດ້, ແຕ່ພວກມັນວັດແທກຄຸນສົມບັດທີ່ແຕກຕ່າງກັນຢ່າງສິ້ນເຊີງ. ຄວາມພ້ອມໃຊ້ງານວັດແທກເວລາທີ່ລະບົບເປີດ: ຂ້ອຍສາມາດເຮັດການເອີ້ນ API ເພື່ອອ່ານ ຫຼືຂຽນຂໍ້ມູນຂອງຂ້ອຍໄດ້ ໃນຕອນນີ້ບໍ? ຄວາມທົນທານວັດແທກການຮັກສາ: ຂໍ້ມູນຂອງຂ້ອຍຈະຢູ່ລອດໂດຍບໍ່ມີການເສື່ອມສະພາບ, ເສຍຫາຍ, ຫຼືຖືກທຳລາຍຖາວອນຕະຫຼອດສິບປີໄດ້ບໍ? bits rot, corruption, or destruction over ten years?

11:24 ເບິ່ງ Amazon S3 Standard. ຂໍ້ຕົກລົງລະດັບບໍລິການຂອງມັນສະເໜີຄວາມພ້ອມໃຊ້ງານ 99.9% ເຊິ່ງອະນຸຍາດໃຫ້ມີເວລາຢຸດເຮັດວຽກປະມານ 43 ນາທີໃນແຕ່ລະເດືອນ availability, which permits roughly forty-three minutes of downtime each month ທີ່ການຮ້ອງຂໍ API ອາດຈະສົ່ງຄືນຂໍ້ຜິດພາດ 500. ແຕ່ S3 ໃຫ້ຄຳໝັ້ນສັນຍາວ່າຈະມີຄວາມທົນທານ 11 ເກົ້າ: 99 ຈຸດເກົ້າເກົ້າເກົ້າເກົ້າເກົ້າເກົ້າເກົ້າ ເກົ້າເກົ້າເປີເຊັນ. ຖ້າທ່ານເກັບ 10 ລ້ານໄຟລ໌ໃນ S3, ທ່ານສາມາດຄາດຄະເນໄດ້ວ່າຈະສູນເສຍໄຟລ໌ສະເລ່ຍໜຶ່ງໄຟລ໌ທຸກໆ 10,000 ປີ.

11:56 average of one file every ten thousand years. S3 ບັນລຸສິ່ງນີ້ໂດຍການໃຊ້ erasure-coding objects ແລະການຈຳລອງ chunk ຕ່າງໆໃນສາມສູນຂໍ້ມູນທີ່ແຍກກັນທາງພູມສາດເປັນຢ່າງໜ້ອຍ. least three geographically separated data facilities. ໃນລະຫວ່າງການເກີດຄວາມຜິດພາດຂອງເຄືອຂ່າຍພາກພື້ນທີ່ສຳຄັນ, S3 ອາດຈະບໍ່ສາມາດໃຊ້ງານໄດ້ຊົ່ວຄາວ, ແຕ່ຂໍ້ມູນຂອງທ່ານຈະບໍ່ຖືກທໍາລາຍ.

- 10. Infrastructure as Code (Terraform ທຽບກັບ Console Drift)

12:14 ແນວຄິດທີສິບ: ພື້ນຖານໂຄງລ່າງເປັນລະຫັດ, ຫຼື IaC. ໃນຍຸກຕົ້ນຂອງຄລາວຄອມພິວເຕີ, ວິສະວະກອນໄດ້ເຂົ້າສູ່ລະບົບ AWS web management console ແລະຄລິກດ້ວຍຕົນເອງເພື່ອສ້າງເຄື່ອງຈັກສະເໝືອນ, ກຳນົດຄ່າ subnet, ແລະຕິດຄັດກຸ່ມຄວາມປອດໄພ. ອຸດສາຫະກຳເອີ້ນສິ່ງນີ້ວ່າ ClickOps, ແລະໃນການຜະລິດ, ມັນເປັນໄພພິບັດຢ່າງແທ້ຈິງ. ການປ່ຽນແປງຄອນໂຊນດ້ວຍຕົນເອງບໍ່ມີເສັ້ນທາງກວດສອບ, ບໍ່ມີກົນໄກການຍົກເລີກ, ແລະຫຼີກລ່ຽງບໍ່ໄດ້ເຮັດໃຫ້ເກີດຄວາມແຕກຕ່າງໃນການກຳນົດຄ່າລະຫວ່າງສະພາບແວດລ້ອມ staging ແລະ production. ດ້ວຍເຄື່ອງມື Infrastructure as Code ເຊັ່ນ Terraform, production environments. With Infrastructure

12:48 as Code tools like Terraform, OpenTofu, Pulumi, ຫຼື AWS CDK, ທ່ານກຳນົດສະຖາປັດຕະຍະກຳຄລາວທັງໝົດຂອງທ່ານໃນໄຟລ໌ການຕັ້ງຄ່າທີ່ເກັບໄວ້ໃນ Git. entire cloud architecture in declarative configuration files stored in Git. ທຸກໆການປ່ຽນແປງໃສ່ພອດທີ່ເປີດ ຫຼືຖານຂໍ້ມູນສຳເນົາຈະຜ່ານການຮ້ອງຂໍດຶງຂໍ້ມູນແລະການກວດສອບໂດຍເພື່ອນຮ່ວມງານ. pull request and peer review. ການແລ່ນ terraform plan ສະແດງຕົວຢ່າງຂອງ API diff ທີ່ແນ່ນອນກ່ອນ ທີ່ຈະມີການແຕະຕ້ອງຫຍັງ, ແລະການສ້າງເຄື່ອງຈຳລອງທີ່ຄືກັນກັບ production stack ຂອງທ່ານໃຊ້ເວລາ 4 ນາທີແທນທີ່ຈະເປັນ 4 ອາທິດ. stack takes four minutes instead of four weeks.

- 11. ເຄືອຂ່າຍຄລາວ (VPC, Subnets, NAT & Security Groups)

13:20 ແນວຄິດທີສິບເອັດ: Cloud Networking ແລະ Virtual Private Clouds. ເມື່ອທ່ານນຳໃຊ້ເຊີບເວີໄປຍັງຄລາວ, ພວກມັນບໍ່ໄດ້ຕັ້ງຢູ່ເປີດເຜີຍໃນອິນເຕີເນັດສາທາລະນະ. ພວກມັນຢູ່ໃນຂອບເຂດແຍກທີ່ກຳນົດໂດຍຊອບແວທີ່ເອີ້ນວ່າ VPC. called a VPC. ພາຍໃນ VPC ຂອງທ່ານ, ທ່ານຈັດສັນພື້ນທີ່ທີ່ຢູ່ IP ສ່ວນຕົວເຊັ່ນ: ten-dot-zero-dot-zero-dot-zero slash sixteen, ແລະແບ່ງມັນອອກ ເປັນ public ແລະ private subnets. public subnet ມີເສັ້ນທາງໂດຍກົງໄປຫາ Internet Gateway.

13:51 ມັນບັນຈຸຊັບສິນທີ່ເປີດເຜີຍຕໍ່ສາທາລະນະເຊັ່ນ Application Load Balancers ຂອງທ່ານ ແລະ NAT Gateways. Gateways. It is the only part of your network that possesses public IP addresses. ເຊີບເວີແອັບພລິເຄຊັນ ແລະຖານຂໍ້ມູນການຜະລິດຂອງທ່ານຢູ່ໃນ private subnets ເທົ່ານັ້ນ ໂດຍບໍ່ມີ IP ສາທາລະນະ ແລະບໍ່ມີເສັ້ນທາງເຂົ້າຈາກອິນເຕີເນັດ. internet. When your backend servers need to download security updates, internet. When your backend servers need to download security updates, ການຈະລາຈອນຂາອອກຂອງພວກມັນຈະຜ່ານ NAT Gateway ໃນ public subnet. subnet. Surrounding every instance are Security Groups: stateful virtual firewalls ທີ່ບັງຄັບໃຊ້ຫຼັກການຂອງສິດທິພິເສດຕໍ່າສຸດ.

- 12. ແຜນຜັງວິສາຫະກິດທີ່ສົມບູນ & ຄຳຕັດສິນ

14:28 ກຸ່ມຄວາມປອດໄພຖານຂໍ້ມູນຂອງທ່ານຍອມຮັບການເຊື່ອມຕໍ່ໃນພອດ 5432 ເທົ່ານັ້ນ ຈາກກຸ່ມຄວາມປອດໄພຂອງເຊີບເວີແອັບພລິເຄຊັນຂອງທ່ານ, ເຮັດໃຫ້ການເຈາະຈາກພາຍນອກເປັນໄປບໍ່ໄດ້ທາງຄະນິດສາດ. rendering outside penetration mathematically impossible. ເມື່ອທ່ານຊູມອອກ, ອົງປະກອບພື້ນຖານສິບເອັດອັນນີ້ເຊື່ອມຕໍ່ກັນເປັນລະບົບທີ່ສອດຄ່ອງກັນ. DNS ຂອງທ່ານເຊື່ອມຕໍ່ໄປຫາ Load Balancer ໃນ public subnet, ກຸ່ມ autoscaling ຈັດການການເພີ່ມຂຶ້ນຂອງການຈະລາຈອນໃນທົ່ວ Availability Zones ຫຼາຍແຫ່ງ, event buses ແຍກ backend workers, ແລະ stack ທັງໝົດຂອງທ່ານຖືກນຳໃຊ້ຈາກ Git ໂດຍໃຊ້ Infrastructure as Code. deployed from Git using Infrastructure as Code.

15:02 ຄຳຕັດສິນຂອງ masterclass ມື້ນີ້: SHIP IT. ຢຸດການຈື່ຈຳຄຳຫຍໍ້ການຕະຫຼາດຄລາວຫຼາຍຮ້ອຍຄຳ. ຮຽນຮູ້ຮູບແບບສະຖາປັດຕະຍະກຳສິບເອັດອັນນີ້, ແຍກສະຖານະຂອງທ່ານ, ແລະສ້າງລະບົບທີ່ບໍ່ສາມາດລົ້ມເຫຼວໄດ້. ບອກຂ້ອຍວ່າແນວຄິດຄລາວໃດທີ່ເຮັດໃຫ້ເຈົ້າເຈັບຫົວທີ່ສຸດເມື່ອເຈົ້າເລີ່ມຕົ້ນສ້າງ ໃນຄຳເຫັນ. ແລະເພື່ອດຶງເອົາແຜນການໂກງສະຖາປັດຕະຍະກຳທີ່ສົມບູນ, ສະໝັກສະມາຊິກຈົດໝາຍຂ່າວທີ່ the daily diff dot dev,

15:28 ລິ້ງຂ້າງລຸ່ມ. ແລະນັ້ນແມ່ນຄວາມແຕກຕ່າງສຳລັບມື້ນີ້. ຂ້ອຍຄື Niko ຈາກ Axrisi. ລວມເຂົ້າກັນຢ່າງມີຄວາມຮັບຜິດຊອບ.

ແຫຼ່ງຂໍ້ມູນ

1. AWS Well-Architected Framework (Reliability & Performance Pillars)aws.amazon.com
2. Kubernetes Architecture & Control Plane Conceptskubernetes.io
3. Martin Fowler: What is Event-Driven Architecture?martinfowler.com
4. Amazon S3 Data Durability & Availability Technical Whitepaperaws.amazon.com
5. HashiCorp: Declarative Infrastructure as Code with Terraformwww.terraform.io