ວິທີການ AWS ປຸງແຕ່ງການບໍລິການ elastic ຂອງມັນ. ຂະຫຍາຍເຊີບເວີ ແລະຖານຂໍ້ມູນ

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

AWS cloud ເປັນລະບົບທີ່ຊັບຊ້ອນຂະໜາດໃຫຍ່ທີ່ພັດທະນາໄປມາຕັ້ງແຕ່ປີ 2006 ເປັນຕົ້ນມາ. ສ່ວນຫນຶ່ງຂອງການພັດທະນານີ້ເກີດຂຶ້ນ Vasily Pantyukhin - ສະຖາປະນິກ Amazon Web Services. ໃນຖານະສະຖາປະນິກ, ລາວໄດ້ຮັບການເບິ່ງພາຍໃນບໍ່ພຽງແຕ່ຜົນໄດ້ຮັບທີ່ສຸດ, ແຕ່ຍັງຢູ່ໃນສິ່ງທ້າທາຍທີ່ AWS ເອົາຊະນະ. ຄວາມເຂົ້າໃຈຫຼາຍຂອງວິທີການເຮັດວຽກຂອງລະບົບ, ຄວາມໄວ້ວາງໃຈຫຼາຍຂຶ້ນ. ດັ່ງນັ້ນ, Vasily ຈະແບ່ງປັນຄວາມລັບຂອງບໍລິການຟັງ AWS. ຂ້າງລຸ່ມນີ້ແມ່ນການອອກແບບຂອງເຄື່ອງແມ່ຂ່າຍຂອງ AWS ທາງດ້ານຮ່າງກາຍ, ຄວາມສາມາດໃນການຂະຫຍາຍຖານຂໍ້ມູນ elastic, ຖານຂໍ້ມູນ Amazon ແບບກໍານົດເອງແລະວິທີການເພື່ອເພີ່ມປະສິດທິພາບຂອງເຄື່ອງຈັກ virtual ໃນຂະນະທີ່ຫຼຸດຜ່ອນລາຄາຂອງພວກເຂົາ. ຄວາມຮູ້ກ່ຽວກັບວິທີທາງສະຖາປັດຕະຍະກໍາຂອງ Amazon ຈະຊ່ວຍໃຫ້ທ່ານໃຊ້ບໍລິການ AWS ມີປະສິດທິພາບຫຼາຍຂຶ້ນແລະອາດຈະໃຫ້ທ່ານມີແນວຄວາມຄິດໃຫມ່ໃນການສ້າງວິທີແກ້ໄຂຂອງທ່ານເອງ.

ກ່ຽວກັບຜູ້ເວົ້າ: Vasily Pantyukhin (Hen) ເລີ່ມເປັນຜູ້ບໍລິຫານ Unix ຢູ່ບໍລິສັດ .ru, ເຮັດວຽກໃນຮາດແວ Sun Microsystem ຂະໜາດໃຫຍ່ເປັນເວລາ 6 ປີ, ແລະປະກາດໂລກທີ່ໃຫ້ຂໍ້ມູນເປັນໃຈກາງຢູ່ EMC ເປັນເວລາ 11 ປີ. ມັນໄດ້ພັດທະນາຕາມທໍາມະຊາດໄປສູ່ຄລາວສ່ວນຕົວ, ແລະໃນປີ 2017 ໄດ້ຍ້າຍໄປຢູ່ໃນສາທາລະນະ. ໃນປັດຈຸບັນລາວໃຫ້ຄໍາແນະນໍາດ້ານວິຊາການເພື່ອຊ່ວຍດໍາລົງຊີວິດແລະພັດທະນາໃນ AWS cloud.

ການປະຕິເສດ: ທຸກສິ່ງທຸກຢ່າງຂ້າງລຸ່ມນີ້ແມ່ນຄວາມຄິດເຫັນສ່ວນຕົວຂອງ Vasily ແລະອາດຈະບໍ່ກົງກັນກັບຕໍາແຫນ່ງຂອງ Amazon Web Services. ການບັນທຶກວິດີໂອ ບົດ​ລາຍ​ງານ​ທີ່​ອີງ​ໃສ່​ບົດ​ຄວາມ​ແມ່ນ​ມີ​ຢູ່​ໃນ​ຊ່ອງ YouTube ຂອງ​ພວກ​ເຮົາ​.

ເປັນຫຍັງຂ້ອຍເວົ້າກ່ຽວກັບອຸປະກອນ Amazon?

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

ທຸກສິ່ງທຸກຢ່າງແມ່ນຍິ່ງໃຫຍ່, ຍົກເວັ້ນສິ່ງດຽວ - stuck ໃນການຈະລາຈອນຕິດຂັດ. ເບິ່ງ​ຄື​ວ່າ​ເຈົ້າ​ນັ່ງ​ແລະ​ບໍ່​ໄດ້​ເຮັດ​ຫຍັງ, ແຕ່​ເຈົ້າ​ປ່ຽນ​ເກຍ​ຢູ່​ສະ​ເໝີ, ກົດ clutch, gas, brake - ມັນ​ເຮັດ​ໃຫ້​ເຈົ້າ​ເມື່ອຍ​ແທ້ໆ. ບັນຫາການສັນຈອນຕິດຂັດແມ່ນໄດ້ຮັບການແກ້ໄຂບາງສ່ວນເມື່ອຄອບຄົວໄດ້ຮັບລົດອັດຕະໂນມັດ. ໃນ​ຂະ​ນະ​ທີ່​ຂັບ​ລົດ​, ຂ້າ​ພະ​ເຈົ້າ​ມີ​ເວ​ລາ​ທີ່​ຈະ​ຄິດ​ກ່ຽວ​ກັບ​ບາງ​ສິ່ງ​ບາງ​ຢ່າງ​ແລະ​ຟັງ​ຫນັງ​ສື​ສຽງ​.

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

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

magic ໄດ້​ລົບ​ກວນ​ໜ້ອຍ​ໜຶ່ງ ເມື່ອ​ຂ້າ​ພະ​ເຈົ້າ​ມາ​ເຮັດ​ວຽກ​ເປັນ​ສະ​ຖາ​ປະ​ນິກ​ຢູ່ Amazon ຕໍ່​ມາ. ຂ້າພະເຈົ້າໄດ້ເຫັນບັນຫາທີ່ພວກເຮົາປະເຊີນ, ວິທີການແກ້ໄຂພວກມັນ, ແລະພວກເຮົາພັດທະນາການບໍລິການແນວໃດ. ດ້ວຍການເພີ່ມຄວາມເຂົ້າໃຈກ່ຽວກັບວິທີການເຮັດວຽກຂອງລະບົບ, ຄວາມຫມັ້ນໃຈໃນການບໍລິການຈະປາກົດຂຶ້ນ. ສະນັ້ນຂ້າພະເຈົ້າຢາກແບ່ງປັນຮູບພາບຂອງສິ່ງທີ່ຢູ່ພາຍໃຕ້ hood ຂອງ AWS cloud.

ພວກເຮົາຈະສົນທະນາກ່ຽວກັບຫຍັງ

ຂ້ອຍເລືອກວິທີການທີ່ມີຄວາມຫຼາກຫຼາຍ - ຂ້ອຍເລືອກ 4 ບໍລິການທີ່ຫນ້າສົນໃຈທີ່ມີມູນຄ່າເວົ້າ.

ການເພີ່ມປະສິດທິພາບຂອງເຄື່ອງແມ່ຂ່າຍ. ເມກບໍ່ຫວ່າງທີ່ມີສັນຍາລັກທາງກາຍະພາບ: ສູນຂໍ້ມູນທາງກາຍະພາບ ບ່ອນທີ່ມີເຊີບເວີທາງກາຍະພາບທີ່ຮ້ອງສຽງດັງ, ຮ້ອນຂຶ້ນ ແລະກະພິບດ້ວຍໄຟ.

ຟັງຊັນບໍ່ມີເຄື່ອງແມ່ຂ່າຍ (Lambda) ແມ່ນອາດຈະເປັນການບໍລິການທີ່ສາມາດຂະຫຍາຍໄດ້ຫຼາຍທີ່ສຸດໃນຄລາວ.

ການຂະຫຍາຍຖານຂໍ້ມູນ. ຂ້ອຍຈະບອກເຈົ້າກ່ຽວກັບວິທີທີ່ພວກເຮົາສ້າງຖານຂໍ້ມູນທີ່ສາມາດຂະຫຍາຍໄດ້ຂອງພວກເຮົາເອງ.

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

ຫມາຍ​ເຫດ​. ບົດຄວາມນີ້ຈະສົນທະນາການເພີ່ມປະສິດທິພາບຂອງເຄື່ອງແມ່ຂ່າຍແລະການຂະຫຍາຍຖານຂໍ້ມູນ. ພວກເຮົາຈະພິຈາລະນາການຂະຫຍາຍເຄືອຂ່າຍໃນບົດຄວາມຕໍ່ໄປ. ຫນ້າທີ່ serverless ຢູ່ໃສ? ບົດບັນທຶກແຍກຕ່າງຫາກໄດ້ຖືກຈັດພີມມາກ່ຽວກັບພວກເຂົາ "ຂະຫນາດນ້ອຍ, ແຕ່ສະຫລາດ. Unboxing Firecracker microvirtual" ມັນເວົ້າກ່ຽວກັບວິທີການປັບຂະຫນາດທີ່ແຕກຕ່າງກັນ, ແລະປຶກສາຫາລືຢ່າງລະອຽດກ່ຽວກັບການແກ້ໄຂ Firecracker - symbiosis ຂອງຄຸນນະພາບທີ່ດີທີ່ສຸດຂອງເຄື່ອງ virtual ແລະເຄື່ອງບັນຈຸ.

ເຊີບເວີ

ເມກແມ່ນຊົ່ວຊ້າ. ແຕ່ ephemerality ນີ້ຍັງມີ embodiment ທາງດ້ານຮ່າງກາຍ - ເຄື່ອງແມ່ຂ່າຍ. ໃນເບື້ອງຕົ້ນ, ສະຖາປັດຕະຍະກໍາຂອງພວກເຂົາແມ່ນຄລາສສິກ. ຊິບເຊັດ x86 ມາດຕະຖານ, ບັດເຄືອຂ່າຍ, Linux, Xen hypervisor ທີ່ເຄື່ອງ virtual ຖືກແລ່ນ.

ໃນປີ 2012, ສະຖາປັດຕະຍະກໍານີ້ຮັບມືກັບວຽກງານຂອງຕົນໄດ້ດີ. Xen ເປັນ hypervisor ທີ່ຍິ່ງໃຫຍ່, ແຕ່ມັນມີຈຸດອ່ອນທີ່ສໍາຄັນຫນຶ່ງ. ລາວມີພຽງພໍ overhead ສູງສໍາລັບການຈໍາລອງອຸປະກອນ. ເມື່ອບັດເຄືອຂ່າຍໃໝ່ ຫຼື SSD drives ໃໝ່, ໄວກວ່ານັ້ນມີໃຫ້, ຄ່າໃຊ້ຈ່າຍນີ້ຈະສູງເກີນໄປ. ວິທີການຈັດການກັບບັນຫານີ້? ພວກເຮົາຕັດສິນໃຈເຮັດວຽກສອງດ້ານໃນເວລາດຽວກັນ - ເພີ່ມປະສິດທິພາບທັງຮາດແວແລະ hypervisor. ວຽກງານແມ່ນຮ້າຍແຮງຫຼາຍ.

ການເພີ່ມປະສິດທິພາບຂອງຮາດແວ ແລະ hypervisor

ການ​ເຮັດ​ທຸກ​ຢ່າງ​ໃນ​ເວ​ລາ​ດຽວ​ກັນ​ແລະ​ເຮັດ​ໃຫ້​ມັນ​ດີ​ຈະ​ບໍ່​ໄດ້​ຜົນ​. ສິ່ງທີ່ "ດີ" ແມ່ນບໍ່ຈະແຈ້ງໃນເບື້ອງຕົ້ນ.

ພວກເຮົາໄດ້ຕັດສິນໃຈເອົາວິທີການວິວັດທະນາການ - ພວກເຮົາປ່ຽນອົງປະກອບທີ່ສໍາຄັນຂອງຖາປັດຕະຍະແລະຖິ້ມມັນເຂົ້າໄປໃນການຜະລິດ.

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

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

ຕໍ່ໄປພວກເຮົາໄດ້ຕັດສິນໃຈປັບປຸງການເຂົ້າເຖິງບລັອກການເກັບຮັກສາຂໍ້ມູນ EBS - Elastic Block Storage. ມັນເປັນການປະສົມປະສານຂອງເຄືອຂ່າຍແລະການເກັບຮັກສາ. ຄວາມຫຍຸ້ງຍາກແມ່ນວ່າໃນຂະນະທີ່ບັດ Network Accelerator ມີຢູ່ໃນຕະຫຼາດ, ບໍ່ມີທາງເລືອກທີ່ຈະພຽງແຕ່ຊື້ຮາດແວ Storage Accelerator. ດັ່ງນັ້ນພວກເຮົາໄດ້ຫັນໄປສູ່ການເລີ່ມຕົ້ນ ຫ້ອງທົດລອງ Annapurna, ຜູ້ທີ່ພັດທະນາຊິບ ASIC ພິເສດສໍາລັບພວກເຮົາ. ພວກເຂົາອະນຸຍາດໃຫ້ຕິດຕັ້ງປະລິມານ EBS ຫ່າງໄກສອກຫຼີກເປັນອຸປະກອນ NVMe.

ໃນຕົວຢ່າງ C4 ພວກເຮົາໄດ້ແກ້ໄຂບັນຫາສອງຢ່າງ. ທໍາອິດແມ່ນວ່າພວກເຮົາໄດ້ປະຕິບັດພື້ນຖານສໍາລັບອະນາຄົດຂອງສັນຍາ, ແຕ່ໃຫມ່ໃນເວລານັ້ນ, ເຕັກໂນໂລຊີ NVMe. ອັນທີສອງ, ພວກເຮົາ unloaded ໂຮງງານຜະລິດສູນກາງຢ່າງຫຼວງຫຼາຍໂດຍການໂອນການປະມວນຜົນການຮ້ອງຂໍ EBS ກັບບັດໃຫມ່. ມັນໄດ້ຫັນອອກມາດີ, ດັ່ງນັ້ນໃນປັດຈຸບັນ Annapurna Labs ແມ່ນສ່ວນຫນຶ່ງຂອງ Amazon.

ຮອດເດືອນພະຈິກ 2017, ພວກເຮົາຮູ້ວ່າມັນເຖິງເວລາແລ້ວທີ່ຈະປ່ຽນ hypervisor ຕົວມັນເອງ.

hypervisor ໃຫມ່ໄດ້ຖືກພັດທະນາໂດຍອີງໃສ່ໂມດູນ KVM kernel ທີ່ຖືກດັດແປງ.

ມັນໄດ້ເຮັດໃຫ້ມັນເປັນໄປໄດ້ໂດຍພື້ນຖານໃນການຫຼຸດຜ່ອນ overhead ຂອງ emulation ອຸປະກອນແລະເຮັດວຽກໂດຍກົງກັບ ASICs ໃຫມ່. ຕົວຢ່າງ C5 ແມ່ນເຄື່ອງ virtual ທໍາອິດທີ່ມີ hypervisor ໃໝ່ ແລ່ນພາຍໃຕ້ຝາປິດ. ພວກເຮົາຕັ້ງຊື່ໃຫ້ລາວ Nitro.

ການວິວັດທະນາການຂອງຕົວຢ່າງໃນເສັ້ນເວລາ.

ເຄື່ອງຈັກສະເໝືອນໃໝ່ທັງໝົດທີ່ປະກົດຕົວຕັ້ງແຕ່ເດືອນພະຈິກ 2017 ແລ່ນຢູ່ໃນ hypervisor ນີ້. ຕົວຢ່າງ Bare Metal ບໍ່ມີ hypervisor, ແຕ່ພວກມັນຍັງຖືກເອີ້ນວ່າ Nitro, ເພາະວ່າພວກເຂົາໃຊ້ບັດ Nitro ພິເສດ.

ໃນໄລຍະສອງປີຂ້າງຫນ້າ, ຈໍານວນຂອງປະເພດຂອງ Nitro instances ເກີນສອງສາມສິບ: A1, C5, M5, T3 ແລະອື່ນໆ.

ປະເພດຕົວຢ່າງ.

ວິທີການເຮັດວຽກຂອງເຄື່ອງຈັກ Nitro ທີ່ທັນສະໄຫມ

ພວກເຂົາເຈົ້າມີສາມອົງປະກອບຕົ້ນຕໍ: Nitro hypervisor (ສົນທະນາຂ້າງເທິງ), ຊິບຄວາມປອດໄພແລະບັດ Nitro.

ຊິບຄວາມປອດໄພ ປະສົມປະສານໂດຍກົງເຂົ້າໄປໃນເມນບອດ. ມັນຄວບຄຸມຫຼາຍຫນ້າທີ່ທີ່ສໍາຄັນ, ເຊັ່ນ: ການຄວບຄຸມການໂຫຼດຂອງ host OS.

ບັດ Nitro - ມີສີ່ປະເພດຂອງເຂົາເຈົ້າ. ພວກມັນທັງໝົດແມ່ນພັດທະນາໂດຍ Annapurna Labs ແລະແມ່ນອີງໃສ່ ASICs ທົ່ວໄປ. ບາງ firmware ຂອງເຂົາເຈົ້າແມ່ນຍັງທົ່ວໄປ.

ສີ່ປະເພດຂອງບັດ Nitro.

ຫນຶ່ງໃນບັດໄດ້ຖືກອອກແບບເພື່ອເຮັດວຽກຮ່ວມກັບ ເຄືອຂ່າຍVPC. ນີ້ແມ່ນສິ່ງທີ່ເຫັນໄດ້ໃນເຄື່ອງ virtual ເປັນບັດເຄືອຂ່າຍ ENA - ອະແດບເຕີເຄືອຂ່າຍ Elastic. ມັນຍັງ encapsulates ການຈະລາຈອນໃນເວລາທີ່ສົ່ງມັນຜ່ານເຄືອຂ່າຍທາງດ້ານຮ່າງກາຍ (ພວກເຮົາຈະເວົ້າກ່ຽວກັບເລື່ອງນີ້ໃນພາກທີສອງຂອງບົດຄວາມ), ຄວບຄຸມໄຟວໍຂອງກຸ່ມຄວາມປອດໄພ, ແລະຮັບຜິດຊອບສໍາລັບເສັ້ນທາງແລະເຄືອຂ່າຍອື່ນໆ.

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

ລະບົບຂອງບັດ Nitro, hypervisor ແລະຊິບຄວາມປອດໄພແມ່ນປະສົມປະສານເຂົ້າໃນເຄືອຂ່າຍ SDN ຫຼື ຊອບແວທີ່ກໍານົດເຄືອຂ່າຍ. ຮັບ​ຜິດ​ຊອບ​ສໍາ​ລັບ​ການ​ຄຸ້ມ​ຄອງ​ເຄືອ​ຂ່າຍ​ນີ້ (Control Plane​) ບັດ​ຄວບ​ຄຸມ​.

ແນ່ນອນ, ພວກເຮົາສືບຕໍ່ພັດທະນາ ASICs ໃຫມ່. ຕົວຢ່າງ, ໃນທ້າຍປີ 2018 ພວກເຂົາເຈົ້າໄດ້ປ່ອຍຕົວຊິບ Inferentia, ເຊິ່ງຊ່ວຍໃຫ້ທ່ານສາມາດເຮັດວຽກໄດ້ຢ່າງມີປະສິດທິພາບຫຼາຍຂຶ້ນກັບວຽກງານການຮຽນຮູ້ເຄື່ອງຈັກ.

ຊິບປະມວນຜົນການຮຽນຮູ້ເຄື່ອງຈັກ Inferentia.

ຖານຂໍ້ມູນທີ່ສາມາດຂະຫຍາຍໄດ້

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

• SQL — ລູກ​ຄ້າ​ແລະ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ dispatcher ເຮັດ​ວຽກ​ກ່ຽວ​ກັບ​ມັນ​.
• ການສະຫນອງ ທຸລະກໍາ - ທຸກສິ່ງທຸກຢ່າງຈະແຈ້ງຢູ່ທີ່ນີ້, ACID ແລະສິ່ງທັງຫມົດ.
• ການເກັບຂໍ້ມູນ, ເຊິ່ງສະຫນອງໃຫ້ໂດຍ buffer pools.
• ການຕັດໄມ້ — ສະ​ຫນອງ​ການ​ເຮັດ​ວຽກ​ກັບ​ການ​ເຮັດ​ໃຫມ່​ບັນ​ທຶກ​. ໃນ MySQL ພວກເຂົາຖືກເອີ້ນວ່າ Bin Logs, ໃນ PosgreSQL - ຂຽນບັນທຶກລ່ວງຫນ້າ (WAL).
• ການເກັບຮັກສາ - ການ​ບັນ​ທຶກ​ໂດຍ​ກົງ​ກັບ​ແຜ່ນ​.

ໂຄງສ້າງຖານຂໍ້ມູນຊັ້ນ.

ມີວິທີທີ່ແຕກຕ່າງກັນເພື່ອຂະຫຍາຍຖານຂໍ້ມູນ: sharding, Shared Nothing architecture, ແຜ່ນທີ່ແບ່ງປັນ.

ຢ່າງໃດກໍຕາມ, ວິທີການທັງຫມົດເຫຼົ່ານີ້ຮັກສາໂຄງສ້າງຖານຂໍ້ມູນ monolithic ດຽວກັນ. ອັນນີ້ຈຳກັດການປັບຂະໜາດຢ່າງຫຼວງຫຼາຍ. ເພື່ອແກ້ໄຂບັນຫານີ້, ພວກເຮົາພັດທະນາຖານຂໍ້ມູນຂອງຕົນເອງ - Amazon Aurora. ມັນເຂົ້າກັນໄດ້ກັບ MySQL ແລະ PostgreSQL.

Amazon Aurora

ແນວຄວາມຄິດສະຖາປັດຕະຍະກໍາຕົ້ນຕໍແມ່ນເພື່ອແຍກລະດັບການເກັບຮັກສາແລະບັນທຶກຈາກຖານຂໍ້ມູນຕົ້ນຕໍ.

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

ລະດັບການບັນທຶກແລະການເກັບຮັກສາແມ່ນແຍກຕ່າງຫາກຈາກຖານຂໍ້ມູນ.

DBMS ແບບດັ້ງເດີມຂຽນຂໍ້ມູນໃສ່ລະບົບການເກັບຮັກສາໃນຮູບແບບຂອງຕັນ. ຢູ່ Amazon Aurora, ພວກເຮົາໄດ້ສ້າງບ່ອນເກັບຂໍ້ມູນອັດສະລິຍະທີ່ສາມາດເວົ້າພາສາໄດ້ ບັນທຶກຄືນໃໝ່. ພາຍໃນ, ການເກັບຮັກສາປ່ຽນບັນທຶກເຂົ້າໄປໃນບລັອກຂໍ້ມູນ, ຕິດຕາມກວດກາຄວາມສົມບູນຂອງເຂົາເຈົ້າແລະສໍາຮອງຂໍ້ມູນອັດຕະໂນມັດ.

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

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

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

ບັນຫາດຽວແມ່ນການເກັບຂໍ້ມູນເກົ່າຢູ່ໃນການອ່ານແບບຈໍາລອງ. ແຕ່ບັນຫານີ້ກໍາລັງຖືກແກ້ໄຂ ການ​ໂອນ​ບັນ​ທຶກ redo ທັງ​ຫມົດ​ ເພື່ອ replicas ໃນໄລຍະເຄືອຂ່າຍພາຍໃນ. ຖ້າບັນທຶກຢູ່ໃນແຄດ, ມັນຖືກຫມາຍວ່າບໍ່ຖືກຕ້ອງແລະຂຽນທັບ. ຖ້າມັນບໍ່ຢູ່ໃນແຄດ, ມັນຈະຖືກຍົກເລີກຢ່າງງ່າຍດາຍ.

ພວກເຮົາຈັດຮຽງບ່ອນເກັບມ້ຽນ.

ວິທີການຂະຫຍາຍຊັ້ນ DBMS

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

ໃຫ້ສົມມຸດວ່າພວກເຮົາມີແອັບພລິເຄຊັນທີ່ຕິດຕໍ່ສື່ສານກັບ DBMS ຜ່ານແມ່ບົດ.

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

ຕໍ່ໄປ, ພວກເຮົາປ່ຽນແອັບພລິເຄຊັນຈາກໂຫນດຕົ້ນສະບັບເກົ່າໄປຫາອັນໃຫມ່. ບັນຫາເກີດຂຶ້ນ.

• ນີ້ຈະຮຽກຮ້ອງໃຫ້ມີການຢຸດຄໍາຮ້ອງສະຫມັກທີ່ສໍາຄັນ.
• ໂຫນດຕົ້ນສະບັບໃຫມ່ຈະມີ cache ເຢັນ. ການປະຕິບັດຖານຂໍ້ມູນຈະສູງສຸດພຽງແຕ່ຫຼັງຈາກ cache ໄດ້ warmed ຂຶ້ນ.

ວິທີການປັບປຸງສະຖານະການ? ຕັ້ງຄ່າພຣັອກຊີລະຫວ່າງແອັບພລິເຄຊັນ ແລະແມ່ບົດ.

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

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

ການແກ້ໄຂສຸດທ້າຍກັບ Amazon Aurora serverless

ພວກເຮົາໄດ້ແກ້ໄຂບັນຫາເຫຼົ່ານີ້ແນວໃດ?

ປະໄວ້ຕົວແທນ. ນີ້​ບໍ່​ແມ່ນ​ຕົວ​ຢ່າງ​ແຍກ​ຕ່າງ​ຫາກ​, ແຕ່​ເປັນ​ການ​ແຈກ​ຢາຍ​ທັງ​ຫມົດ​ຂອງ​ຕົວ​ແທນ​ທີ່​ຜ່ານ​ການ​ນໍາ​ໃຊ້​ທີ່​ເຊື່ອມ​ຕໍ່​ກັບ​ຖານ​ຂໍ້​ມູນ​. ໃນ​ກໍ​ລະ​ນີ​ຂອງ​ຄວາມ​ລົ້ມ​ເຫຼວ​, ໃດ​ຂອງ nodes ສາ​ມາດ​ໄດ້​ຮັບ​ການ​ທົດ​ແທນ​ເກືອບ​ທັນ​ທີ​.

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

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

ຕົວແທນທີ່ແຈກຢາຍ, ກໍລະນີທີ່ອົບອຸ່ນແລະການຕິດຕາມ.

ໂນດທີ່ມີພະລັງງານທີ່ຕ້ອງການແມ່ນມີຢູ່. Buffer pools ໄດ້ຖືກຄັດລອກໃສ່ມັນ, ແລະລະບົບເລີ່ມຕົ້ນລໍຖ້າສໍາລັບເວລາທີ່ປອດໄພເພື່ອປ່ຽນ.

ປົກກະຕິແລ້ວເວລາທີ່ຈະປ່ຽນມາຂ້ອນຂ້າງໄວ. ຫຼັງຈາກນັ້ນ, ການສື່ສານລະຫວ່າງ proxy ແລະ master node ເກົ່າຖືກໂຈະ, sessions ທັງຫມົດແມ່ນ switched ກັບ node ໃຫມ່.

ເຮັດວຽກກັບຊີວະປະຫວັດຂອງຖານຂໍ້ມູນ.

ເສັ້ນສະແດງສະແດງໃຫ້ເຫັນວ່າ suspension ແມ່ນສັ້ນຫຼາຍ. ເສັ້ນສະແດງສີຟ້າສະແດງໃຫ້ເຫັນການໂຫຼດ, ແລະຂັ້ນຕອນສີແດງສະແດງໃຫ້ເຫັນຊ່ວງເວລາຂອງການຂະຫຍາຍ. ການຫຼຸດລົງໃນໄລຍະສັ້ນໃນເສັ້ນສະແດງສີຟ້າແມ່ນຊັດເຈນວ່າຄວາມຊັກຊ້າສັ້ນ.

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

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

ກ່ຽວກັບ ໂຫຼດສູງ ++ Vasily Pantyukhin ຈະໃຫ້ບົດລາຍງານ "Houston, ພວກເຮົາມີບັນຫາ. ການອອກແບບລະບົບສໍາລັບຄວາມລົ້ມເຫຼວ, ຮູບແບບການພັດທະນາສໍາລັບການບໍລິການ Amazon cloud ພາຍໃນ" ຮູບແບບການອອກແບບໃດແດ່ສໍາລັບລະບົບການແຈກຢາຍແມ່ນໃຊ້ໂດຍຜູ້ພັດທະນາ Amazon, ແມ່ນຫຍັງທີ່ເປັນເຫດຜົນສໍາລັບຄວາມລົ້ມເຫຼວຂອງການບໍລິການ, ແມ່ນຫຍັງຄືສະຖາປັດຕະຍະກໍາ Cell, ການເຮັດວຽກຄົງທີ່, Shuffle Sharding - ມັນຈະເປັນຫນ້າສົນໃຈ. ບໍ່​ຮອດ​ເດືອນ​ກໍ​ຮອດ​ກອງ​ປະ​ຊຸມ - ຈອງປີ້ຂອງທ່ານ. ການເພີ່ມຂຶ້ນຂອງລາຄາສຸດທ້າຍໃນວັນທີ 24 ຕຸລາ.

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