Web HighLoad - ວິທີທີ່ພວກເຮົາຈັດການການຈະລາຈອນສໍາລັບຫລາຍສິບພັນໂດເມນ

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

ຂ້າງລຸ່ມນີ້ການຕັດແມ່ນວິທີທີ່ພວກເຮົາຈັດການ nodes ດ້ານຫນ້າແລະອອກໃບຢັ້ງຢືນ SSL ສໍາລັບຫຼາຍຮ້ອຍພັນເວັບໄຊທ໌.

ການຕັ້ງຫນ້າສໍາລັບເວັບໄຊທ໌ຫນຶ່ງ, ເຖິງແມ່ນວ່າຂະຫນາດໃຫຍ່ຫຼາຍ, ແມ່ນງ່າຍ. ພວກເຮົາເອົາ nginx ຫຼື haproxy ຫຼື lighttpd, ຕັ້ງຄ່າມັນຕາມຄໍາແນະນໍາແລະລືມກ່ຽວກັບມັນ. ຖ້າພວກເຮົາຕ້ອງການປ່ຽນບາງສິ່ງບາງຢ່າງ, ພວກເຮົາໂຫຼດໃຫມ່ແລະລືມອີກເທື່ອຫນຶ່ງ.

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

ເປັນຫຍັງມີໂນດທີ່ເຊື່ອຖືໄດ້ຫຼາຍທົ່ວໂລກ?

• ຄຸນະພາບຂອງການບໍລິການສໍາລັບການຈະລາຈອນຂອງລູກຄ້າ - ການຮ້ອງຂໍຈາກສະຫະລັດຕ້ອງໄດ້ຮັບການປຸງແຕ່ງໃນສະຫະລັດ (ລວມທັງການໂຈມຕີ, parsing ແລະຄວາມຜິດປົກກະຕິອື່ນໆ), ແລະບໍ່ດຶງໄປ Moscow ຫຼືເອີຣົບ, unpredictably ເພີ່ມທະວີການຊັກຊ້າການປຸງແຕ່ງ.

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

• ຄວາມຕ້ອງການທີ່ເຂັ້ມງວດສໍາລັບການບໍລິການຢ່າງຕໍ່ເນື່ອງ - ສູນທໍາຄວາມສະອາດບໍ່ຄວນຂຶ້ນກັບກັນແລະກັນຫຼືເຫດການທ້ອງຖິ່ນໃນໂລກທີ່ມີການປ່ຽນແປງຢ່າງໄວວາຂອງພວກເຮົາ. ທ່ານໄດ້ຕັດໄຟຟ້າທັງໝົດ 11 ຊັ້ນຂອງ MMTS-9 ເປັນເວລາໜຶ່ງອາທິດບໍ? - ບໍ່ມີບັນຫາ. ບໍ່ແມ່ນລູກຄ້າດຽວທີ່ບໍ່ມີການເຊື່ອມຕໍ່ທາງດ້ານຮ່າງກາຍໃນສະຖານທີ່ສະເພາະນີ້ຈະທົນທຸກ, ແລະການບໍລິການເວັບຈະບໍ່ທົນທຸກພາຍໃຕ້ສະຖານະການໃດໆ.

ວິທີການຈັດການທັງຫມົດນີ້?

ການຕັ້ງຄ່າບໍລິການຄວນຈະຖືກແຈກຢາຍໃຫ້ທຸກໂຫນດທາງໜ້າໄວເທົ່າທີ່ຈະໄວໄດ້ (ໂດຍສະເພາະທັນທີ). ທ່ານບໍ່ສາມາດພຽງແຕ່ໃຊ້ເວລາແລະສ້າງ configs ຂໍ້ຄວາມແລະ reboot daemons ໃນທຸກການປ່ຽນແປງ - nginx ດຽວກັນເຮັດໃຫ້ຂະບວນການປິດລົງ (ພະນັກງານປິດລົງ) ສໍາລັບສອງສາມນາທີເພີ່ມເຕີມ (ຫຼືບາງຊົ່ວໂມງຖ້າຫາກວ່າມີ websocket sessions ຍາວ).

ເມື່ອໂຫຼດການຕັ້ງຄ່າ nginx ຄືນໃໝ່, ຮູບພາບຕໍ່ໄປນີ້ແມ່ນຂ້ອນຂ້າງປົກກະຕິ:

ກ່ຽວ​ກັບ​ການ​ນໍາ​ໃຊ້​ຄວາມ​ຊົງ​ຈໍາ​:

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

ເປັນຫຍັງນີ້ຈຶ່ງບໍ່ແມ່ນບັນຫາໃນເວລາທີ່ nginx ກໍາລັງເລີ່ມຕົ້ນ? ບໍ່ມີ HTTP/2, ບໍ່ມີ WebSocket, ບໍ່ມີການເຊື່ອມຕໍ່ທີ່ມີຊີວິດຊີວາອັນໃຫຍ່ຫຼວງ. 70% ຂອງການເຂົ້າຊົມເວັບແມ່ນ HTTP/2, ຊຶ່ງຫມາຍຄວາມວ່າການເຊື່ອມຕໍ່ຍາວຫຼາຍ.

ການແກ້ໄຂແມ່ນງ່າຍດາຍ - ຢ່າໃຊ້ nginx, ບໍ່ຈັດການຫນ້າໂດຍອີງໃສ່ໄຟລ໌ຂໍ້ຄວາມ, ແລະແນ່ນອນວ່າບໍ່ສົ່ງການຕັ້ງຄ່າຂໍ້ຄວາມ zipped ຜ່ານຊ່ອງທາງ transpacific. ແນ່ນອນ, ຊ່ອງທາງແມ່ນຮັບປະກັນແລະສະຫງວນ, ແຕ່ນັ້ນບໍ່ໄດ້ເຮັດໃຫ້ພວກເຂົາຂ້າມທະວີບຫນ້ອຍລົງ.

ພວກ​ເຮົາ​ມີ server-balancer ທາງ​ຫນ້າ​ຂອງ​ພວກ​ເຮົາ​ເອງ, ພາຍ​ໃນ​ທີ່​ຂ້າ​ພະ​ເຈົ້າ​ຈະ​ເວົ້າ​ເຖິງ​ໃນ​ບົດ​ຄວາມ​ຕໍ່​ໄປ​ນີ້. ສິ່ງທີ່ສໍາຄັນທີ່ມັນສາມາດເຮັດໄດ້ແມ່ນນໍາໃຊ້ການປ່ຽນແປງການຕັ້ງຄ່າຫຼາຍພັນຄັ້ງຕໍ່ວິນາທີ, ໂດຍບໍ່ມີການເລີ່ມຕົ້ນໃຫມ່, ການໂຫຼດໃຫມ່, ການບໍລິໂພກຄວາມຈໍາເພີ່ມຂຶ້ນຢ່າງກະທັນຫັນ, ແລະສິ່ງທັງຫມົດ. ນີ້ແມ່ນຄ້າຍຄືກັນກັບ Hot Code Reload, ຕົວຢ່າງໃນ Erlang. ຂໍ້ມູນຖືກເກັບໄວ້ໃນຖານຂໍ້ມູນທີ່ແຈກຢາຍໂດຍ geo-value ແລະຖືກອ່ານທັນທີໂດຍຕົວກະຕຸ້ນດ້ານຫນ້າ. ເຫຼົ່ານັ້ນ. ທ່ານອັບໂຫລດໃບຢັ້ງຢືນ SSL ຜ່ານເວັບຫຼື API ໃນ Moscow, ແລະໃນສອງສາມວິນາທີມັນກໍ່ພ້ອມທີ່ຈະໄປສູນທໍາຄວາມສະອາດຂອງພວກເຮົາໃນ Los Angeles. ຖ້າສົງຄາມໂລກເກີດຂຶ້ນຢ່າງກະທັນຫັນແລະອິນເຕີເນັດຫາຍໄປທົ່ວໂລກ, ໂນດຂອງພວກເຮົາຈະສືບຕໍ່ເຮັດວຽກອັດຕະໂນມັດແລະສ້ອມແປງສະຫມອງທີ່ແຕກຫັກທັນທີທີ່ຫນຶ່ງໃນຊ່ອງທາງທີ່ອຸທິດຕົນ Los Angeles-Amsterdam-Moscow, Moscow-Amsterdam-Hong Kong- Los-Los ກາຍເປັນທີ່ມີຢູ່.

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

1. ທັນທີທີ່ພວກເຮົາເຫັນຢ່າງຫນ້ອຍຫນຶ່ງຄໍາຮ້ອງຂໍ HTTPS ສໍາລັບໂດເມນຂອງລູກຄ້າຂອງພວກເຮົາໂດຍບໍ່ມີໃບຢັ້ງຢືນ (ຫຼືມີໃບຢັ້ງຢືນຫມົດອາຍຸ), node ພາຍນອກທີ່ຍອມຮັບຄໍາຮ້ອງຂໍລາຍງານນີ້ກັບເຈົ້າຫນ້າທີ່ການຢັ້ງຢືນພາຍໃນ.

   

2. ຖ້າຜູ້ໃຊ້ບໍ່ໄດ້ຫ້າມການອອກ Let's Encrypt, ເຈົ້າຫນ້າທີ່ຢັ້ງຢືນຈະສ້າງ CSR, ໄດ້ຮັບ token ຢືນຢັນຈາກ LE ແລະສົ່ງມັນໄປຫາຫນ້າທັງຫມົດຜ່ານຊ່ອງທາງທີ່ຖືກເຂົ້າລະຫັດ. ໃນປັດຈຸບັນ node ໃດສາມາດຢືນຢັນການຮ້ອງຂໍການກວດສອບຈາກ LE.

   

3. ໃນເວລາບໍ່ພໍເທົ່າໃດ, ພວກເຮົາຈະໄດ້ຮັບໃບຢັ້ງຢືນທີ່ຖືກຕ້ອງແລະລະຫັດສ່ວນຕົວແລະສົ່ງມັນໄປຫາຫນ້າໃນແບບດຽວກັນ. ອີກເທື່ອຫນຶ່ງ, ໂດຍບໍ່ມີການ restart daemon ໄດ້

   

4. 7 ມື້ກ່ອນວັນຫມົດອາຍຸ, ຂັ້ນຕອນການໄດ້ຮັບໃບຢັ້ງຢືນຄືນໃຫມ່ແມ່ນເລີ່ມຕົ້ນ

ໃນປັດຈຸບັນພວກເຮົາກໍາລັງຫມຸນໃບຢັ້ງຢືນ 350k ໃນເວລາທີ່ແທ້ຈິງ, ໂປ່ງໃສຢ່າງສົມບູນກັບຜູ້ໃຊ້.

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

ພຽງແຕ່ຜູ້ໃຊ້ລົງທະບຽນສາມາດເຂົ້າຮ່ວມໃນການສໍາຫຼວດ. ເຂົ້າ​ສູ່​ລະ​ບົບກະລຸນາ.

ເຈົ້າຢາກຮູ້ອັນໃດກ່ອນ?

• 14,3%ສູດການຄິດໄລ່ສຳລັບການຈັດກຸ່ມ ແລະການວິເຄາະຄຸນນະພາບຂອງການເຂົ້າຊົມເວັບ <3

• 33,3%ພາຍໃນຂອງຕົວດຸ່ນດ່ຽງ DDoS-Guard7

• 9,5%ການປົກປ້ອງການຈະລາຈອນ L3/L4

• 0,0%ການປົກປ້ອງເວັບໄຊທ໌ກ່ຽວກັບການຈະລາຈອນທາງຜ່ານ0

• 14,3%Web Application Firewall3

• 28,6%ການ​ປ້ອງ​ກັນ​ຕ້ານ​ການ​ວິ​ເຄາະ​ແລະ​ການ​ຄລິກ 6​

21 ຜູ້ໃຊ້ລົງຄະແນນສຽງ. ຜູ້ໃຊ້ 6 ງົດ.

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