Post Mortem ຢູ່ໃນຄວາມບໍ່ພ້ອມຂອງ Quay.io

ຫມາຍ​ເຫດ​. ແປ.: ໃນຕົ້ນເດືອນສິງຫາ, Red Hat ໄດ້ເວົ້າຢ່າງເປີດເຜີຍກ່ຽວກັບການແກ້ໄຂບັນຫາການເຂົ້າເຖິງທີ່ຜູ້ໃຊ້ບໍລິການຂອງຕົນໄດ້ພົບໃນເດືອນກ່ອນຫນ້າ. Quay.io (ມັນແມ່ນອີງໃສ່ການລົງທະບຽນສໍາລັບຮູບພາບບັນຈຸ, ທີ່ບໍລິສັດໄດ້ຮັບພ້ອມກັບການຊື້ CoreOS). ໂດຍບໍ່ຄໍານຶງເຖິງຄວາມສົນໃຈຂອງທ່ານໃນການບໍລິການດັ່ງກ່າວ, ເສັ້ນທາງທີ່ວິສະວະກອນ SRE ຂອງບໍລິສັດໄດ້ປະຕິບັດເພື່ອວິນິດໄສແລະລົບລ້າງສາເຫດຂອງອຸປະຕິເຫດແມ່ນຄໍາແນະນໍາ.

ວັນທີ 19 ພຶດສະພາ, ຕອນເຊົ້າ (ເວລາກາງເວັນຕາເວັນອອກ, EDT), ການບໍລິການ quay.io crashed. ອຸບັດຕິເຫດດັ່ງກ່າວໄດ້ສົ່ງຜົນກະທົບຕໍ່ຜູ້ບໍລິໂພກຂອງ quay.io ແລະໂຄງການ Open Source ໂດຍໃຊ້ quay.io ເປັນເວທີສໍາລັບການກໍ່ສ້າງແລະແຈກຢາຍຊອບແວ. Red Hat ໃຫ້ຄຸນຄ່າຄວາມໄວ້ວາງໃຈຂອງທັງສອງ.

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

«ມີຫຍັງປ່ຽນແປງ?" - ນີ້ແມ່ນຄໍາຖາມທໍາອິດທີ່ມັກຈະຖືກຖາມໃນກໍລະນີດັ່ງກ່າວ. ພວກ​ເຮົາ​ສັງ​ເກດ​ເຫັນ​ວ່າ​ບໍ່​ດົນ​ກ່ອນ​ທີ່​ຈະ​ບັນ​ຫາ​, ກຸ່ມ OpenShift ອຸ​ທິດ (ທີ່​ດໍາ​ເນີນ​ການ quay.io​) ໄດ້​ເລີ່ມ​ຕົ້ນ​ການ​ປັບ​ປຸງ​ສະ​ບັບ 4.3.19​. ນັບຕັ້ງແຕ່ quay.io ແລ່ນໃນ Red Hat OpenShift Dedicated (OSD), ການປັບປຸງປົກກະຕິແມ່ນເປັນປົກກະຕິແລະບໍ່ເຄີຍເຮັດໃຫ້ເກີດບັນຫາ. ຍິ່ງໄປກວ່ານັ້ນ, ໃນໄລຍະຫົກເດືອນທີ່ຜ່ານມາ, ພວກເຮົາໄດ້ປັບປຸງກຸ່ມ Quay ຫຼາຍຄັ້ງໂດຍບໍ່ມີການຂັດຂວາງການບໍລິການ.

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

ການວິເຄາະສາເຫດຂອງຮາກ

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

ພວກເຮົາຍັງໄດ້ພະຍາຍາມກໍານົດຮູບແບບການຈາລະຈອນຂອງຖານຂໍ້ມູນທີ່ສາມາດເຮັດໃຫ້ເກີດ avalanche ນີ້. ແນວໃດກໍ່ຕາມ, ພວກເຮົາບໍ່ສາມາດຊອກຫາຮູບແບບໃດໆໃນໄມ້ທ່ອນໄດ້. ໃນຂະນະທີ່ລໍຖ້າ cluster ໃຫມ່ກັບ OSD 4.3.18 ກຽມພ້ອມ, ພວກເຮົາໄດ້ສືບຕໍ່ພະຍາຍາມເປີດຕົວ quay.io pods. ທຸກໆຄັ້ງທີ່ກຸ່ມບັນລຸຄວາມສາມາດເຕັມທີ່, ຖານຂໍ້ມູນຈະຄ້າງ. ນີ້ຫມາຍຄວາມວ່າມັນເປັນສິ່ງຈໍາເປັນທີ່ຈະ restart the RDS instance ນອກເຫນືອໄປຈາກ pods quay.io ທັງຫມົດ.

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

Quay.io ເຮັດວຽກຢ່າງຫມັ້ນຄົງຢູ່ໃນກຸ່ມ OSD ໃຫມ່, ດັ່ງນັ້ນພວກເຮົາໄດ້ກັບຄືນໄປບ່ອນບັນທຶກຖານຂໍ້ມູນ, ແຕ່ບໍ່ສາມາດຊອກຫາຄວາມສໍາພັນທີ່ຈະອະທິບາຍການຂັດຂວາງ. ວິສະວະກອນ OpenShift ໄດ້ເຮັດວຽກກັບພວກເຮົາເພື່ອເຂົ້າໃຈວ່າການປ່ຽນແປງໃນ Red Hat OpenShift 4.3.19 ສາມາດເຮັດໃຫ້ເກີດບັນຫາກັບ Quay. ຢ່າງໃດກໍຕາມ, ບໍ່ມີຫຍັງພົບເຫັນ, ແລະ ມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະແຜ່ພັນບັນຫາໃນສະພາບຫ້ອງທົດລອງ.

ຄວາມລົ້ມເຫຼວທີສອງ

ໃນວັນທີ 28 ເດືອນພຶດສະພາ, ບໍ່ດົນກ່ອນທ່ຽງ EDT, quay.io crashed ອີກເທື່ອຫນຶ່ງດ້ວຍອາການດຽວກັນ: ຖານຂໍ້ມູນໄດ້ຖືກບລັອກ. ແລະອີກເທື່ອຫນຶ່ງພວກເຮົາໄດ້ຖິ້ມຄວາມພະຍາຍາມທັງຫມົດຂອງພວກເຮົາເຂົ້າໄປໃນການສືບສວນ. ກ່ອນອື່ນ ໝົດ, ມັນ ຈຳ ເປັນຕ້ອງຟື້ນຟູການບໍລິການ. ແນວໃດກໍ່ຕາມ ເວລານີ້ rebooting RDS ແລະ restarting quay.io pods ບໍ່ມີຫຍັງເລີຍ: ການເຊື່ອມຕໍ່ avalanche ອື່ນໄດ້ overwhelmed ພື້ນຖານ. ແຕ່ເປັນຫຍັງ?

Quay ຖືກຂຽນໄວ້ໃນ Python ແລະແຕ່ລະຝັກດໍາເນີນການເປັນພາຊະນະ monolithic ດຽວ. ຊ່ວງເວລາບັນຈຸບັນຈຸແລ່ນຫຼາຍໜ້າວຽກຂະໜານພ້ອມກັນ. ພວກເຮົາໃຊ້ຫ້ອງສະຫມຸດ gevent ພາຍໃຕ້ gunicorn ເພື່ອປະມວນຜົນການຮ້ອງຂໍເວັບ. ເມື່ອຄໍາຮ້ອງຂໍເຂົ້າມາໃນ Quay (ຜ່ານ API ຂອງພວກເຮົາເອງ, ຫຼືຜ່ານ Docker's API), ມັນຖືກມອບຫມາຍໃຫ້ພະນັກງານ gevent. ໂດຍປົກກະຕິພະນັກງານນີ້ຄວນຕິດຕໍ່ກັບຖານຂໍ້ມູນ. ຫຼັງຈາກຄວາມລົ້ມເຫຼວຄັ້ງທໍາອິດ, ພວກເຮົາຄົ້ນພົບວ່າພະນັກງານ gevent ກໍາລັງເຊື່ອມຕໍ່ກັບຖານຂໍ້ມູນໂດຍໃຊ້ການຕັ້ງຄ່າເລີ່ມຕົ້ນ.

ເນື່ອງຈາກຈໍານວນ Quay pods ທີ່ສໍາຄັນແລະຫລາຍພັນຄໍາຮ້ອງຂໍທີ່ເຂົ້າມາຕໍ່ວິນາທີ, ການເຊື່ອມຕໍ່ຖານຂໍ້ມູນຈໍານວນຫລາຍສາມາດ overwhelm ຕົວຢ່າງ MySQL. ຂໍຂອບໃຈກັບການຕິດຕາມ, ມັນຮູ້ວ່າ Quay ດໍາເນີນການໂດຍສະເລ່ຍ 5 ພັນຄໍາຮ້ອງຂໍຕໍ່ວິນາທີ. ຈໍານວນຂອງການເຊື່ອມຕໍ່ກັບຖານຂໍ້ມູນແມ່ນປະມານດຽວກັນ. 5 ພັນການເຊື່ອມຕໍ່ແມ່ນດີຢູ່ໃນຄວາມສາມາດຂອງຕົວຢ່າງ RDS ຂອງພວກເຮົາ (ເຊິ່ງບໍ່ສາມາດເວົ້າກ່ຽວກັບຫລາຍສິບພັນຄົນ). ສໍາລັບເຫດຜົນບາງຢ່າງ, ມີການເພີ່ມຂຶ້ນທີ່ບໍ່ຄາດຄິດໃນຈໍານວນການເຊື່ອມຕໍ່ຢ່າງໃດກໍຕາມ, ພວກເຮົາບໍ່ໄດ້ສັງເກດເຫັນຄວາມກ່ຽວຂ້ອງໃດໆກັບຄໍາຮ້ອງຂໍທີ່ເຂົ້າມາ.

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

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

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

ເຫັນໄດ້ຊັດເຈນວ່າມີອັນອື່ນທີ່ລີ້ຢູ່ໃນກຸ່ມ.

ການສຶກສາລະອຽດ

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

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

Quay.io ເຮັດວຽກໄດ້ດີຈົນຮອດວັນທີ 9 ມິຖຸນາ. ຕອນເຊົ້ານີ້ (EDT) ພວກເຮົາເຫັນການເພີ່ມຂື້ນຢ່າງຫຼວງຫຼາຍຂອງການເຊື່ອມຕໍ່ຖານຂໍ້ມູນ. ເວລານີ້ບໍ່ມີເວລາຢຸດ, ເນື່ອງຈາກພາລາມິເຕີໃຫມ່ຈໍາກັດຈໍານວນຂອງພວກເຂົາແລະບໍ່ອະນຸຍາດໃຫ້ພວກເຂົາເກີນ MySQL throughput. ຢ່າງໃດກໍຕາມ, ປະມານເຄິ່ງຫນຶ່ງຊົ່ວໂມງ, ຜູ້ໃຊ້ຈໍານວນຫຼາຍສັງເກດເຫັນການປະຕິບັດຊ້າຂອງ quay.io. ພວກເຮົາເກັບກໍາຂໍ້ມູນທີ່ເປັນໄປໄດ້ທັງຫມົດຢ່າງໄວວາໂດຍໃຊ້ເຄື່ອງມືຕິດຕາມທີ່ເພີ່ມ. ທັນໃດນັ້ນກໍມີຮູບແບບໜຶ່ງອອກມາ.

ກ່ອນການເຊື່ອມຕໍ່ເພີ່ມຂຶ້ນ, ມີການຮ້ອງຂໍຈໍານວນຫລາຍຕໍ່ກັບ App Registry API. App Registry ເປັນຄຸນສົມບັດທີ່ຮູ້ຈັກໜ້ອຍໜຶ່ງຂອງ quay.io. ມັນອະນຸຍາດໃຫ້ທ່ານເກັບຮັກສາສິ່ງຕ່າງໆເຊັ່ນ Helm charts ແລະ containers ທີ່ມີ metadata ອຸດົມສົມບູນ. ຜູ້ໃຊ້ quay.io ສ່ວນໃຫຍ່ບໍ່ໄດ້ເຮັດວຽກກັບຄຸນສົມບັດນີ້, ແຕ່ Red Hat OpenShift ໃຊ້ມັນຢ່າງຈິງຈັງ. OperatorHub ເປັນສ່ວນຫນຶ່ງຂອງ OpenShift ເກັບຮັກສາຜູ້ປະກອບການທັງຫມົດໃນ App Registry. ຜູ້ປະກອບການເຫຼົ່ານີ້ເປັນພື້ນຖານສໍາລັບລະບົບນິເວດການເຮັດວຽກຂອງ OpenShift ແລະຮູບແບບການດໍາເນີນງານທີ່ຄູ່ຮ່ວມງານເປັນສູນກາງ (ການດໍາເນີນງານໃນມື້ 2).

ແຕ່ລະກຸ່ມ OpenShift 4 ໃຊ້ຕົວປະຕິບັດການຈາກ OperatorHub ທີ່ມີໃນຕົວເພື່ອເຜີຍແຜ່ລາຍການຂອງຕົວປະຕິບັດການທີ່ມີໃຫ້ສໍາລັບການຕິດຕັ້ງແລະສະຫນອງການປັບປຸງໃຫ້ກັບຜູ້ທີ່ຕິດຕັ້ງແລ້ວ. ດ້ວຍຄວາມນິຍົມເພີ່ມຂຶ້ນຂອງ OpenShift 4, ຈໍານວນຂອງກຸ່ມຢູ່ໃນມັນໃນທົ່ວໂລກໄດ້ເພີ່ມຂຶ້ນ. ແຕ່ລະກຸ່ມເຫຼົ່ານີ້ດາວໂຫຼດເນື້ອຫາຂອງຕົວປະຕິບັດການເພື່ອດໍາເນີນການ OperatorHub ທີ່ມີໃນຕົວ, ໂດຍໃຊ້ App Registry ພາຍໃນ quay.io ເປັນ backend. ໃນການຊອກຫາແຫຼ່ງທີ່ມາຂອງບັນຫາຂອງພວກເຮົາ, ພວກເຮົາພາດຄວາມຈິງທີ່ວ່າຍ້ອນວ່າ OpenShift ຄ່ອຍໆເຕີບໂຕໃນຄວາມນິຍົມ, ການໂຫຼດໃນຫນ້າທີ່ quay.io ທີ່ບໍ່ຄ່ອຍໃຊ້ກໍ່ເພີ່ມຂຶ້ນ..

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

ການລົບລ້າງສາເຫດ

ໃນອາທິດຕໍ່ໄປ, ພວກເຮົາໄດ້ໃຊ້ເວລາປັບປຸງລະຫັດຂອງ App Registry ຕົວມັນເອງແລະສະພາບແວດລ້ອມຂອງມັນ. ການສອບຖາມ SQL ທີ່ບໍ່ມີປະສິດຕິຜົນຢ່າງຊັດເຈນໄດ້ຖືກປະຕິບັດຄືນໃຫມ່ແລະການໂທຄໍາສັ່ງທີ່ບໍ່ຈໍາເປັນຖືກລົບລ້າງ tar (ມັນຖືກດໍາເນີນການທຸກຄັ້ງທີ່ blobs ໄດ້ຖືກດຶງ), caching ໄດ້ຖືກເພີ່ມບ່ອນໃດກໍ່ຕາມທີ່ເປັນໄປໄດ້. ຫຼັງຈາກນັ້ນພວກເຮົາໄດ້ດໍາເນີນການທົດສອບປະສິດທິພາບຢ່າງກວ້າງຂວາງແລະປຽບທຽບຄວາມໄວຂອງ App Registry ກ່ອນແລະຫຼັງຈາກການປ່ຽນແປງ.

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

ພວກເຮົາໄດ້ຮຽນຮູ້ຫຍັງ?

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

1. ຂໍ້​ມູນ​ກ່ຽວ​ກັບ​ຜູ້​ທີ່​ນໍາ​ໃຊ້​ການ​ບໍ​ລິ​ການ​ຂອງ​ທ່ານ​ແລະ​ວິ​ທີ​ການ​ແມ່ນ​ບໍ່​ເຄີຍ superfluous​. ເນື່ອງຈາກວ່າ Quay "ຫາກໍ່ເຮັດວຽກ," ພວກເຮົາບໍ່ເຄີຍໃຊ້ເວລາໃນການເພີ່ມປະສິດທິພາບການຈະລາຈອນແລະການຄຸ້ມຄອງການໂຫຼດ. ທັງຫມົດນີ້ໄດ້ສ້າງຄວາມຮູ້ສຶກທີ່ບໍ່ຖືກຕ້ອງຂອງຄວາມປອດໄພທີ່ການບໍລິການສາມາດຂະຫຍາຍໄດ້ຢ່າງບໍ່ມີກໍານົດ.
2. ເມື່ອການບໍລິການຫຼຸດລົງ, ການເອົາມັນຄືນມາ ແລະແລ່ນເປັນບຸລິມະສິດອັນດັບຕົ້ນໆ.. ເນື່ອງຈາກວ່າ Quay ຍັງສືບຕໍ່ທົນທຸກຈາກຖານຂໍ້ມູນທີ່ຖືກລັອກໃນລະຫວ່າງການຢຸດທໍາອິດ, ຂັ້ນຕອນມາດຕະຖານຂອງພວກເຮົາບໍ່ມີຜົນກະທົບທີ່ມີຈຸດປະສົງແລະພວກເຮົາບໍ່ສາມາດຟື້ນຟູການບໍລິການໂດຍໃຊ້ພວກມັນ. ນີ້ນໍາໄປສູ່ສະຖານະການທີ່ຕ້ອງໃຊ້ເວລາໃນການວິເຄາະແລະເກັບກໍາຂໍ້ມູນໃນຄວາມຫວັງທີ່ຈະຊອກຫາສາເຫດຂອງຮາກ - ແທນທີ່ຈະສຸມໃສ່ຄວາມພະຍາຍາມທັງຫມົດໃນການຟື້ນຟູການເຮັດວຽກ.
3. ປະເມີນຜົນກະທົບຂອງແຕ່ລະລັກສະນະການບໍລິການ. ລູກຄ້າບໍ່ຄ່ອຍໄດ້ໃຊ້ App Registry, ສະນັ້ນມັນບໍ່ເປັນບູລິມະສິດສຳລັບທີມງານຂອງພວກເຮົາ. ເມື່ອບາງຄຸນສົມບັດຂອງຜະລິດຕະພັນຖືກໃຊ້ເປົ່າ, ແມງໄມ້ຂອງມັນບໍ່ຄ່ອຍຈະປາກົດ, ແລະນັກພັດທະນາຢຸດການຕິດຕາມລະຫັດ. ມັນງ່າຍທີ່ຈະຕົກເປັນເຫຍື່ອຂອງຄວາມເຂົ້າໃຈຜິດວ່ານີ້ແມ່ນວິທີທີ່ມັນຄວນຈະເປັນ - ຈົນກ່ວາໃນທັນທີທັນໃດຫນ້າທີ່ພົບເຫັນຕົວມັນເອງຢູ່ໃນຈຸດໃຈກາງຂອງເຫດການໃຫຍ່.

ຈະເປັນແນວໃດຕໍ່ໄປ?

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

1. ນໍາໃຊ້ການຈໍາລອງຖານຂໍ້ມູນແບບອ່ານເທົ່ານັ້ນເພື່ອຊ່ວຍໃຫ້ການບໍລິການຈັດການການຈະລາຈອນທີ່ເຫມາະສົມໃນກໍລະນີທີ່ມີບັນຫາກັບຕົວຢ່າງ RDS ຕົ້ນຕໍ.
2. ການປັບປຸງຕົວຢ່າງ RDS. ສະບັບປະຈຸບັນຕົວມັນເອງບໍ່ແມ່ນບັນຫາ. ແທນທີ່ຈະ, ພວກເຮົາພຽງແຕ່ຕ້ອງການເອົາເສັ້ນທາງທີ່ບໍ່ຖືກຕ້ອງ (ທີ່ພວກເຮົາປະຕິບັດຕາມໃນລະຫວ່າງການລົ້ມເຫລວ); ການຮັກສາຊອບແວໃຫ້ທັນສະໄຫມຈະກໍາຈັດປັດໄຈອື່ນໃນກໍລະນີຂອງການຂັດຂ້ອງໃນອະນາຄົດ.
3. ແຄດເພີ່ມເຕີມໃນທົ່ວກຸ່ມທັງໝົດ. ພວກເຮົາສືບຕໍ່ຊອກຫາພື້ນທີ່ທີ່ຖານຄວາມຈໍາສາມາດຫຼຸດຜ່ອນການໂຫຼດໃນຖານຂໍ້ມູນ.
4. ການເພີ່ມ web application firewall (WAF) ເພື່ອເບິ່ງວ່າໃຜກໍາລັງເຊື່ອມຕໍ່ກັບ quay.io ແລະເປັນຫຍັງ.
5. ເລີ່ມຕົ້ນດ້ວຍການເປີດຕົວຄັ້ງຕໍ່ໄປ, ກຸ່ມ Red Hat OpenShift ຈະປະຖິ້ມ App Registry ໃນເງື່ອນໄຂຂອງ Operator Catalogs ໂດຍອີງໃສ່ຮູບພາບບັນຈຸທີ່ມີຢູ່ໃນ quay.io.
6. ການທົດແທນໄລຍະຍາວສໍາລັບການລົງທະບຽນ App ອາດຈະເປັນການສະຫນັບສະຫນູນສໍາລັບ Open Container Initiative (OCI) artifact specifications. ປະຈຸບັນມັນຖືກປະຕິບັດເປັນການເຮັດວຽກຂອງ Quay ພື້ນເມືອງແລະຈະມີໃຫ້ຜູ້ໃຊ້ໃນເວລາທີ່ການກໍານົດຕົວຂອງມັນເອງຖືກສະຫຼຸບ.

ທັງຫມົດຂ້າງເທິງນີ້ແມ່ນສ່ວນຫນຶ່ງຂອງການລົງທືນຢ່າງຕໍ່ເນື່ອງຂອງ Red Hat ໃນ quay.io ໃນຂະນະທີ່ພວກເຮົາຍ້າຍຈາກທີມງານ "ແບບເລີ່ມຕົ້ນ" ຂະຫນາດນ້ອຍໄປສູ່ເວທີ SRE-driven ທີ່ເປັນຜູ້ໃຫຍ່. ພວກເຮົາຮູ້ວ່າລູກຄ້າຈໍານວນຫຼາຍຂອງພວກເຮົາອີງໃສ່ quay.io ໃນການເຮັດວຽກປະຈໍາວັນຂອງພວກເຂົາ (ລວມທັງ Red Hat!) ແລະພວກເຮົາພະຍາຍາມມີຄວາມໂປ່ງໃສເທົ່າທີ່ເປັນໄປໄດ້ກ່ຽວກັບການຢຸດງານທີ່ຜ່ານມາແລະຄວາມພະຍາຍາມຢ່າງຕໍ່ເນື່ອງເພື່ອປັບປຸງ.

PS ຈາກນັກແປ

ອ່ານຍັງຢູ່ໃນ blog ຂອງພວກເຮົາ:

• «Red Hat open source code registry for CoreOS container images - Quay"
• «ເລື່ອງການປະຕິບັດຈາກຊີວິດປະຈໍາວັນຂອງພວກເຮົາ SRE. ພາກທີ 2"
• «ບູລິມະສິດ pod ໃນ Kubernetes ເຮັດໃຫ້ເກີດການຢຸດເຮັດວຽກຢູ່ Grafana Labs ແນວໃດ".

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