ກໍານົດຂະຫນາດທີ່ເຫມາະສົມສໍາລັບກຸ່ມ Kafka ໃນ Kubernetes

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

Apache Kafka ເປັນແພລະຕະຟອມການຖ່າຍທອດແບບແຈກຢາຍເພື່ອສ້າງລະບົບການຖ່າຍທອດແບບສົດໆທີ່ໜ້າເຊື່ອຖື, ສາມາດຂະຫຍາຍໄດ້ ແລະມີປະສິດທິພາບສູງ. ຄວາມສາມາດທີ່ຫນ້າປະທັບໃຈຂອງມັນສາມາດຂະຫຍາຍໄດ້ໂດຍໃຊ້ Kubernetes. ສໍາລັບການນີ້ພວກເຮົາໄດ້ພັດທະນາ Open Source ຜູ້ປະກອບການ Kafka ແລະເຄື່ອງມືທີ່ເອີ້ນວ່າ Supertubes. ພວກເຂົາເຈົ້າອະນຸຍາດໃຫ້ທ່ານດໍາເນີນການ Kafka ໃນ Kubernetes ແລະນໍາໃຊ້ລັກສະນະຕ່າງໆຂອງຕົນ, ເຊັ່ນ: ປັບປັບການຕັ້ງຄ່າຂອງນາຍຫນ້າ, ຂະຫນາດໂດຍອີງໃສ່ metric ກັບ rebalancing, rack awareness, "ອ່ອນ" (ສະຫງ່າງາມ) ເປີດຕົວອັບເດດ, ແລະອື່ນໆ.

ລອງໃຊ້ Supertubes ໃນກຸ່ມຂອງທ່ານ:

curl https://getsupertubes.sh | sh и supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>

ຫຼືຕິດຕໍ່ ເອກະສານ. ນອກ​ນັ້ນ​ທ່ານ​ຍັງ​ສາ​ມາດ​ອ່ານ​ກ່ຽວ​ກັບ​ບາງ​ສ່ວນ​ຂອງ​ຄວາມ​ສາ​ມາດ​ຂອງ Kafka​, ການ​ເຮັດ​ວຽກ​ທີ່​ອັດ​ຕະ​ໂນ​ມັດ​ໂດຍ​ນໍາ​ໃຊ້ Supertubes ແລະ Kafka operator​. ພວກເຮົາໄດ້ຂຽນກ່ຽວກັບພວກມັນຢູ່ໃນ blog ແລ້ວ:

• ໂອ​ບໍ່! ຍັງມີຜູ້ປະກອບການ Kafka ອື່ນສໍາລັບ Kubernetes;
• ຕິດຕາມແລະປະຕິບັດ Kafka ໂດຍອີງໃສ່ຕົວຊີ້ວັດ Prometheus;
• Kafka rack ປູກຈິດສໍານຶກໃນ Kubernetes;
• ແລ່ນ Apache Kafka ຜ່ານ Istio - benchmark;
• ຜູ້ໃຊ້ໄດ້ກວດສອບຄວາມຖືກຕ້ອງ ແລະເຂົ້າເຖິງກຸ່ມທີ່ຄວບຄຸມດ້ວຍຕົວປະຕິບັດການ Kafka;
• ການຍົກລະດັບການມ້ວນ Kafka ແລະການຕັ້ງຄ່າແບບໄດນາມິກໃນ Kubernetes;
• ການກັ່ນຕອງອະນຸສັນຍາທູດສໍາລັບ Kafka, meshed.

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

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

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

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

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

ບົດຄວາມນີ້ຈະເວົ້າກ່ຽວກັບຂັ້ນຕອນທີ່ພວກເຮົາໃຊ້ເພື່ອໃຫ້ໄດ້ຜົນປະໂຫຍດສູງສຸດຈາກອົງປະກອບທີ່ຊ້າທີ່ສຸດໃນການຕັ້ງຄ່າເບື້ອງຕົ້ນແລະການວັດແທກຜ່ານຂອງກຸ່ມ Kafka. ການ​ຕັ້ງ​ຄ່າ​ທີ່​ທົນ​ທານ​ສູງ​ຮຽກ​ຮ້ອງ​ໃຫ້​ມີ​ຢ່າງ​ຫນ້ອຍ​ສາມ​ນາຍ​ຫນ້າ​ທີ່​ດໍາ​ເນີນ​ການ (min.insync.replicas=3), ແຈກຢາຍໃນທົ່ວສາມເຂດການເຂົ້າເຖິງທີ່ແຕກຕ່າງກັນ. ເພື່ອຕັ້ງຄ່າ, ປັບຂະໜາດ ແລະຕິດຕາມໂຄງສ້າງພື້ນຖານ Kubernetes, ພວກເຮົາໃຊ້ແພລະຕະຟອມການຈັດການບັນຈຸຂອງພວກເຮົາເອງສຳລັບຄລາວປະສົມ - ທໍ່ນ້ໍາ. ມັນສະຫນັບສະຫນູນຢູ່ໃນສະຖານທີ່ (ໂລຫະເປົ່າ, VMware) ແລະຫ້າປະເພດຂອງເມຄ (Alibaba, AWS, Azure, Google, Oracle), ເຊັ່ນດຽວກັນກັບການປະສົມປະສານໃດໆຂອງມັນ.

ຄວາມຄິດກ່ຽວກັບໂຄງລ່າງຂອງກຸ່ມ Kafka ແລະການຕັ້ງຄ່າ

ສໍາລັບຕົວຢ່າງຂ້າງລຸ່ມນີ້, ພວກເຮົາໄດ້ເລືອກ AWS ເປັນຜູ້ໃຫ້ບໍລິການຟັງແລະ EKS ເປັນການແຈກຢາຍ Kubernetes. ການຕັ້ງຄ່າທີ່ຄ້າຍຄືກັນສາມາດຖືກປະຕິບັດໂດຍໃຊ້ P.K.E. - ການແຈກຢາຍ Kubernetes ຈາກ Banzai Cloud, ໄດ້ຮັບການຢັ້ງຢືນໂດຍ CNCF.

ແຜ່ນ

Amazon ສະຫນອງການຕ່າງໆ ປະເພດປະລິມານ EBS. ຢູ່ຫຼັກ gp2 и io1 ຢ່າງໃດກໍຕາມ, ມີ SSD drives ເພື່ອຮັບປະກັນການສົ່ງຜ່ານສູງ gp2 ບໍລິໂພກສິນເຊື່ອສະສົມ (ສິນເຊື່ອ I/O), ດັ່ງນັ້ນພວກເຮົາມັກປະເພດ io1, ເຊິ່ງສະຫນອງການໄຫຼເຂົ້າສູງທີ່ສອດຄ່ອງ.

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

ການປະຕິບັດຂອງ Kafka ແມ່ນຂຶ້ນກັບຖານຄວາມຈໍາຂອງຫນ້າຂອງລະບົບປະຕິບັດການ, ດັ່ງນັ້ນພວກເຮົາຕ້ອງການຕົວຢ່າງທີ່ມີຫນ່ວຍຄວາມຈໍາພຽງພໍສໍາລັບນາຍຫນ້າ (JVM) ແລະ cache ຫນ້າ. ຕົວຢ່າງ c5.2xlarge - ເປັນ​ການ​ເລີ່ມ​ຕົ້ນ​ທີ່​ດີ​, ເນື່ອງ​ຈາກ​ວ່າ​ມັນ​ມີ 16 GB ຂອງ​ຫນ່ວຍ​ຄວາມ​ຈໍາ​ແລະ​ ປັບປຸງໃຫ້ເໝາະສົມເພື່ອເຮັດວຽກກັບ EBS. ຂໍ້ເສຍຂອງມັນແມ່ນພຽງແຕ່ສາມາດສະຫນອງປະສິດທິພາບສູງສຸດສໍາລັບການບໍ່ເກີນ 30 ນາທີທຸກໆ 24 ຊົ່ວໂມງ. ຖ້າວຽກຂອງເຈົ້າຕ້ອງການປະສິດທິພາບສູງສຸດໃນໄລຍະເວລາທີ່ຍາວນານ, ເຈົ້າອາດຕ້ອງພິຈາລະນາປະເພດຕົວຢ່າງອື່ນໆ. ນັ້ນແມ່ນສິ່ງທີ່ພວກເຮົາເຮັດ, ຢຸດຢູ່ c5.4xlarge. ມັນສະຫນອງການສົ່ງຜ່ານສູງສຸດໃນ 593,75 Mb/s. ກະແສໄຟຟ້າສູງສຸດຂອງປະລິມານ EBS io1 ສູງກວ່າຕົວຢ່າງ c5.4xlarge, ດັ່ງນັ້ນອົງປະກອບທີ່ຊ້າທີ່ສຸດຂອງໂຄງສ້າງພື້ນຖານແມ່ນອາດຈະເປັນການສົ່ງຜ່ານ I/O ຂອງປະເພດຕົວຢ່າງນີ້ (ເຊິ່ງການທົດສອບການໂຫຼດຂອງພວກເຮົາຄວນຢືນຢັນເຊັ່ນກັນ).

ເຄືອຂ່າຍ

ການສົ່ງຜ່ານເຄືອຂ່າຍຕ້ອງມີຂະຫນາດໃຫຍ່ພໍສົມທຽບກັບການປະຕິບັດຂອງ VM instance ແລະ disk, ຖ້າບໍ່ດັ່ງນັ້ນເຄືອຂ່າຍຈະກາຍເປັນຄໍຂວດ. ໃນກໍລະນີຂອງພວກເຮົາ, ການໂຕ້ຕອບເຄືອຂ່າຍ c5.4xlarge ຮອງຮັບຄວາມໄວສູງເຖິງ 10 Gb/s, ເຊິ່ງສູງກວ່າການສົ່ງຜ່ານ I/O ຂອງ VM instance.

ການນຳໃຊ້ນາຍໜ້າ

ນາຍໜ້າຄວນຖືກນຳໃຊ້ (ກຳນົດເວລາໃນ Kubernetes) ໃຫ້ກັບ nodes ທີ່ອຸທິດຕົນເພື່ອຫຼີກເວັ້ນການແຂ່ງຂັນກັບຂະບວນການອື່ນໆສຳລັບ CPU, memory, network, and disk resources.

ລຸ້ນ Java

ທາງເລືອກທີ່ມີເຫດຜົນແມ່ນ Java 11 ເພາະວ່າມັນເຂົ້າກັນໄດ້ກັບ Docker ໃນຄວາມຫມາຍທີ່ JVM ກໍານົດໂປເຊດເຊີແລະຫນ່ວຍຄວາມຈໍາທີ່ຖືກຕ້ອງກັບຖັງທີ່ນາຍຫນ້າກໍາລັງເຮັດວຽກ. ໂດຍຮູ້ວ່າຂໍ້ຈໍາກັດຂອງ CPU ມີຄວາມສໍາຄັນ, JVM ພາຍໃນແລະໂປ່ງໃສກໍານົດຈໍານວນຂອງ GC threads ແລະ JIT threads. ພວກເຮົາໄດ້ນໍາໃຊ້ຮູບພາບ Kafka banzaicloud/kafka:2.13-2.4.0ເຊິ່ງລວມມີ Kafka ເວີຊັນ 2.4.0 (Scala 2.13) ໃນ Java 11.

ຖ້າທ່ານຕ້ອງການຮຽນຮູ້ເພີ່ມເຕີມກ່ຽວກັບ Java / JVM ໃນ Kubernetes, ກວດເບິ່ງຂໍ້ຄວາມຕໍ່ໄປນີ້ຂອງພວກເຮົາ:

• ເປັນຫຍັງຄໍາຮ້ອງສະຫມັກ Java ຂອງຂ້ອຍແມ່ນ OOMKilled;
• ວິທີການຂະຫນາດບັນຈຸທີ່ຖືກຕ້ອງສໍາລັບຄໍາຮ້ອງສະຫມັກ Java 10.

ການຕັ້ງຄ່າຄວາມຊົງຈໍາຂອງນາຍຫນ້າ

ມີສອງລັກສະນະທີ່ສໍາຄັນໃນການຕັ້ງຄ່າຫນ່ວຍຄວາມຈໍາຂອງນາຍຫນ້າ: ການຕັ້ງຄ່າສໍາລັບ JVM ແລະສໍາລັບ pod Kubernetes. ຂີດຈໍາກັດຫນ່ວຍຄວາມຈໍາທີ່ກໍານົດໄວ້ສໍາລັບ pod ຈະຕ້ອງໃຫຍ່ກວ່າຂະຫນາດ heap ສູງສຸດເພື່ອໃຫ້ JVM ມີພື້ນທີ່ສໍາລັບ Java metaspace ທີ່ຢູ່ໃນຫນ່ວຍຄວາມຈໍາຂອງຕົນເອງແລະສໍາລັບ cache ຫນ້າຂອງລະບົບປະຕິບັດການທີ່ Kafka ໃຊ້ຢ່າງຫ້າວຫັນ. ໃນການທົດສອບຂອງພວກເຮົາພວກເຮົາໄດ້ເປີດຕົວນາຍຫນ້າ Kafka ທີ່ມີພາລາມິເຕີ -Xmx4G -Xms2G, ແລະຄວາມຈໍາຈໍາກັດສໍາລັບຝັກແມ່ນ 10 Gi. ກະລຸນາຮັບຊາບວ່າການຕັ້ງຄ່າໜ່ວຍຄວາມຈຳສຳລັບ JVM ສາມາດໄດ້ຮັບອັດຕະໂນມັດໂດຍໃຊ້ -XX:MaxRAMPercentage и -X:MinRAMPercentage, ອີງຕາມການຈໍາກັດຄວາມຈໍາສໍາລັບຝັກ.

ການຕັ້ງຄ່າໂປເຊດເຊີນາຍຫນ້າ

ໂດຍທົ່ວໄປແລ້ວ, ທ່ານສາມາດປັບປຸງການປະຕິບັດໂດຍການເພີ່ມຄວາມຂະຫນານໂດຍການເພີ່ມຈໍານວນຂອງກະທູ້ທີ່ໃຊ້ໂດຍ Kafka. ໂປເຊດເຊີຫຼາຍທີ່ມີຢູ່ສໍາລັບ Kafka, ດີກວ່າ. ໃນການທົດສອບຂອງພວກເຮົາ, ພວກເຮົາເລີ່ມຕົ້ນດ້ວຍຂອບເຂດຈໍາກັດຂອງ 6 ໂປເຊດເຊີແລະຄ່ອຍໆ (ຜ່ານການເຮັດຊ້ໍາອີກ) ເພີ່ມຈໍານວນຂອງພວກເຂົາເປັນ 15. ນອກຈາກນັ້ນ, ພວກເຮົາກໍານົດ. num.network.threads=12 ໃນການຕັ້ງຄ່ານາຍຫນ້າເພື່ອເພີ່ມຈໍານວນກະທູ້ທີ່ໄດ້ຮັບຂໍ້ມູນຈາກເຄືອຂ່າຍແລະສົ່ງມັນ. ທັນທີທີ່ຄົ້ນພົບວ່ານາຍຫນ້າຜູ້ຕິດຕາມບໍ່ສາມາດໄດ້ຮັບ replicas ຢ່າງໄວວາພຽງພໍ, ພວກເຂົາເຈົ້າໄດ້ຍົກຂຶ້ນມາ num.replica.fetchers ເຖິງ 4 ເພື່ອເພີ່ມຄວາມໄວທີ່ນາຍຫນ້າຜູ້ຕິດຕາມ replicated ຂໍ້ຄວາມຈາກຜູ້ນໍາ.

Load Generation Tool

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

Benchmarking

ການ​ວັດ​ແທກ​ປະ​ສິດ​ທິ​ພາບ​ເປັນ​ຂະ​ບວນ​ການ​ຊ​້​ໍາ​ທີ່​ປະ​ກອບ​ມີ​ຂັ້ນ​ຕອນ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​:

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

ພາກສ່ວນຕໍ່ໄປອະທິບາຍຂັ້ນຕອນທີ່ໄດ້ປະຕິບັດໃນລະຫວ່າງຂະບວນການ benchmarking ກຸ່ມການທົດສອບ.

ເຄື່ອງມື

ເຄື່ອງ​ມື​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​ໄດ້​ຖືກ​ນໍາ​ໃຊ້​ເພື່ອ​ນໍາ​ໃຊ້​ຢ່າງ​ວ່ອງ​ໄວ​ການ​ຕັ້ງ​ຄ່າ​ພື້ນ​ຖານ​, ສ້າງ​ການ​ໂຫຼດ​, ແລະ​ວັດ​ແທກ​ປະ​ສິດ​ທິ​ພາບ​:

• Banzai Cloud Pipeline ສໍາລັບການຈັດກຸ່ມ EKS ຈາກ Amazon c Prometheus (ເພື່ອເກັບກໍາ Kafka ແລະ metrics ໂຄງສ້າງພື້ນຖານ) ແລະ ກຣາຟານາ (ເພື່ອສະແດງພາບການວັດແທກເຫຼົ່ານີ້). ພວກເຮົາໄດ້ເອົາປະໂຫຍດ ປະສົມປະສານ в ທໍ່ນ້ໍາ ການບໍລິການທີ່ສະຫນອງການຕິດຕາມກວດກາຂອງສະຫະພັນ, ການເກັບກໍາຂໍ້ມູນຈາກສູນກາງ, ການສະແກນຄວາມສ່ຽງ, ການຟື້ນຟູໄພພິບັດ, ຄວາມປອດໄພລະດັບວິສາຫະກິດແລະອື່ນໆ.
• Sangrenel — ເຄື່ອງ​ມື​ສໍາ​ລັບ​ການ​ທົດ​ສອບ​ການ​ໂຫຼດ​ກຸ່ມ Kafka​.
• ແຜງໜ້າປັດ Grafana ສຳລັບການເບິ່ງເຫັນຕົວວັດແທກ ແລະໂຄງສ້າງພື້ນຖານຂອງ Kafka: Kubernetes Kafka, Node Exporter.
• Supertubes CLI ສໍາລັບວິທີທີ່ງ່າຍທີ່ສຸດທີ່ຈະຕັ້ງກຸ່ມ Kafka ໃນ Kubernetes. Zookeeper, Kafka operator, Envoy ແລະອົງປະກອບອື່ນໆຈໍານວນຫຼາຍໄດ້ຖືກຕິດຕັ້ງແລະກໍາຫນົດຄ່າຢ່າງຖືກຕ້ອງເພື່ອດໍາເນີນການກຸ່ມ Kafka ທີ່ພ້ອມທີ່ຈະຜະລິດຢູ່ໃນ Kubernetes.
  • ສຳ ລັບຕິດຕັ້ງ supertubes CLI ໃຊ້ຄໍາແນະນໍາທີ່ສະຫນອງໃຫ້ ທີ່ນີ້.

ກຸ່ມ EKS

ກະກຽມກຸ່ມ EKS ທີ່ມີຂໍ້ສະເພາະຂອງຜູ້ອອກແຮງງານ c5.4xlarge ໃນເຂດທີ່ມີທີ່ແຕກຕ່າງກັນສໍາລັບຝັກທີ່ມີນາຍຫນ້າ Kafka, ເຊັ່ນດຽວກັນກັບ nodes ທີ່ອຸທິດຕົນສໍາລັບເຄື່ອງກໍາເນີດການໂຫຼດແລະໂຄງສ້າງພື້ນຖານການຕິດຕາມ.

banzai cluster create -f https://raw.githubusercontent.com/banzaicloud/kafka-operator/master/docs/benchmarks/infrastructure/cluster_eks_202001.json

ເມື່ອກຸ່ມ EKS ເຮັດວຽກແລ້ວ, ໃຫ້ເປີດໃຊ້ງານປະສົມປະສານຂອງມັນ ບໍລິການຕິດຕາມ — ນາງ​ຈະ​ນຳ​ໃຊ້ Prometheus ແລະ Grafana ເປັນ​ກຸ່ມ.

ອົງປະກອບຂອງລະບົບ Kafka

ຕິດຕັ້ງອົງປະກອບລະບົບ Kafka (Zookeeper, kafka-operator) ໃນ EKS ໂດຍໃຊ້ supertubes CLI:

supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>

ກຸ່ມ Kafka

ໂດຍຄ່າເລີ່ມຕົ້ນ, EKS ໃຊ້ປະລິມານ EBS ຂອງປະເພດ gp2, ດັ່ງນັ້ນທ່ານຈໍາເປັນຕ້ອງສ້າງຊັ້ນເກັບຮັກສາແຍກຕ່າງຫາກໂດຍອີງໃສ່ປະລິມານ io1 ສໍາລັບກຸ່ມ Kafka:

kubectl create -f - <<EOF
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: kubernetes.io/aws-ebs
parameters:
  type: io1
  iopsPerGB: "50"
  fsType: ext4
volumeBindingMode: WaitForFirstConsumer
EOF

ກໍານົດພາລາມິເຕີສໍາລັບນາຍຫນ້າ min.insync.replicas=3 ແລະ ນຳ ໃຊ້ພອດນາຍ ໜ້າ ໃນ nodes ໃນສາມເຂດການມີຢູ່ທີ່ແຕກຕ່າງກັນ:

supertubes cluster create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f https://raw.githubusercontent.com/banzaicloud/kafka-operator/master/docs/benchmarks/infrastructure/kafka_202001_3brokers.yaml --wait --timeout 600

ຫົວຂໍ້

ພວກເຮົາໄດ້ແລ່ນສາມຕົວຢ່າງເຄື່ອງກໍາເນີດການໂຫຼດໃນຂະຫນານ. ແຕ່ລະຄົນຂຽນໃສ່ຫົວຂໍ້ຂອງຕົນເອງ, ນັ້ນແມ່ນ, ພວກເຮົາຕ້ອງການສາມຫົວຂໍ້ທັງຫມົດ:

supertubes cluster topic create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f -<<EOF
apiVersion: kafka.banzaicloud.io/v1alpha1
kind: KafkaTopic
metadata:
  name: perftest1
spec:
  name: perftest1
  partitions: 12
  replicationFactor: 3
  retention.ms: '28800000'
  cleanup.policy: delete
EOF

supertubes cluster topic create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f -<<EOF
apiVersion: kafka.banzaicloud.io/v1alpha1
kind: KafkaTopic
metadata:
    name: perftest2
spec:
  name: perftest2
  partitions: 12
  replicationFactor: 3
  retention.ms: '28800000'
  cleanup.policy: delete
EOF

supertubes cluster topic create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f -<<EOF
apiVersion: kafka.banzaicloud.io/v1alpha1
kind: KafkaTopic
metadata:
  name: perftest3
spec:
  name: perftest3
  partitions: 12
  replicationFactor: 3
  retention.ms: '28800000'
  cleanup.policy: delete
EOF

ສໍາລັບແຕ່ລະຫົວຂໍ້, ປັດໄຈການຈໍາລອງແມ່ນ 3 - ມູນຄ່າຕໍາ່ສຸດທີ່ແນະນໍາສໍາລັບລະບົບການຜະລິດທີ່ມີຢູ່ສູງ.

Load Generation Tool

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

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  labels:
    app: loadtest
  name: perf-load1
  namespace: kafka
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: loadtest
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: loadtest
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: nodepool.banzaicloud.io/name
                operator: In
                values:
                - loadgen
      containers:
      - args:
        - -brokers=kafka-0:29092,kafka-1:29092,kafka-2:29092,kafka-3:29092
        - -topic=perftest1
        - -required-acks=all
        - -message-size=512
        - -workers=20
        image: banzaicloud/perfload:0.1.0-blog
        imagePullPolicy: Always
        name: sangrenel
        resources:
          limits:
            cpu: 2
            memory: 1Gi
          requests:
            cpu: 2
            memory: 1Gi
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30

ບາງຈຸດທີ່ຄວນສັງເກດ:

• ເຄື່ອງກໍາເນີດການໂຫຼດສ້າງຂໍ້ຄວາມທີ່ມີຄວາມຍາວ 512 ໄບຕ໌ແລະເຜີຍແຜ່ໃຫ້ເຂົາເຈົ້າກັບ Kafka ໃນຊຸດຂອງ 500 ຂໍ້ຄວາມ.
• ການນໍາໃຊ້ການໂຕ້ຖຽງ -required-acks=all ການພິມເຜີຍແຜ່ແມ່ນຖືວ່າປະສົບຜົນສໍາເລັດເມື່ອການຄັດລອກຂໍ້ຄວາມທີ່ synchronized ທັງຫມົດໄດ້ຮັບແລະຢືນຢັນໂດຍນາຍຫນ້າ Kafka. ນີ້ຫມາຍຄວາມວ່າໃນດັດຊະນີພວກເຮົາບໍ່ພຽງແຕ່ວັດແທກຄວາມໄວຂອງຜູ້ນໍາທີ່ໄດ້ຮັບຂໍ້ຄວາມ, ແຕ່ຍັງຜູ້ຕິດຕາມຂອງເຂົາເຈົ້າ replicating ຂໍ້ຄວາມ. ຈຸດປະສົງຂອງການທົດສອບນີ້ບໍ່ແມ່ນເພື່ອປະເມີນຄວາມໄວການອ່ານຂອງຜູ້ບໍລິໂພກ (ຜູ້ບໍລິໂພກ) ບໍ່ດົນມານີ້ໄດ້ຮັບຂໍ້ຄວາມທີ່ຍັງຄົງຢູ່ໃນ cache ຂອງຫນ້າ OS, ແລະການປຽບທຽບກັບຄວາມໄວການອ່ານຂອງຂໍ້ຄວາມທີ່ເກັບໄວ້ໃນແຜ່ນ.
• ເຄື່ອງຈັກບັນຈຸ 20 ຄົນເຮັດວຽກຂະຫນານ (-workers=20). ພະນັກງານແຕ່ລະຄົນມີຜູ້ຜະລິດ 5 ຄົນທີ່ແບ່ງປັນການເຊື່ອມຕໍ່ຂອງພະນັກງານກັບກຸ່ມ Kafka. ດັ່ງນັ້ນ, ແຕ່ລະຜູ້ຜະລິດມີຜູ້ຜະລິດ 100 ຄົນ, ແລະພວກເຂົາທັງຫມົດສົ່ງຂໍ້ຄວາມໄປຫາກຸ່ມ Kafka.

ການຕິດຕາມສຸຂະພາບຂອງກຸ່ມ

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

• ເຄື່ອງກໍາເນີດການໂຫຼດຂຽນສະຖິຕິມາດຕະຖານກ່ຽວກັບຈໍານວນຂໍ້ຄວາມທີ່ຖືກເຜີຍແຜ່ແລະອັດຕາຄວາມຜິດພາດ. ອັດຕາຄວາມຜິດພາດຄວນຢູ່ຄືກັນ 0,00%.
• ການຄວບຄຸມລ່ອງເຮືອ, deployed by kafka-operator, ສະຫນອງ dashboard ບ່ອນທີ່ພວກເຮົາຍັງສາມາດຕິດຕາມກວດກາສະຖານະຂອງ cluster ໄດ້. ເພື່ອເບິ່ງແຜງນີ້, ເຮັດ:

  supertubes cluster cruisecontrol show -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file>

• ລະດັບ ISR (ຈໍານວນຂອງ "in-sync" replicas) shrink ແລະການຂະຫຍາຍແມ່ນເທົ່າກັບ 0.

ຜົນໄດ້ຮັບການວັດແທກ

3 ນາຍຫນ້າ, ຂະຫນາດຂໍ້ຄວາມ - 512 bytes

ດ້ວຍການແບ່ງສ່ວນແບ່ງອອກເທົ່າທຽມກັນໃນທົ່ວສາມນາຍຫນ້າ, ພວກເຮົາສາມາດບັນລຸການປະຕິບັດ ~ 500 Mb/s (ປະມານ 990 ພັນຂໍ້ຄວາມຕໍ່ວິນາທີ):

ການບໍລິໂພກຄວາມຊົງຈໍາຂອງເຄື່ອງ virtual JVM ບໍ່ເກີນ 2 GB:

ການປ້ອນຂໍ້ມູນຂອງດິສກ໌ໄດ້ເຖິງການສົ່ງຜ່ານຂໍ້ I/O ສູງສຸດໃນທັງສາມຕົວຢ່າງທີ່ນາຍໜ້າກຳລັງແລ່ນ:

ຈາກຂໍ້ມູນການນໍາໃຊ້ຫນ່ວຍຄວາມຈໍາໂດຍ nodes, ມັນປະຕິບັດຕາມວ່າລະບົບ buffering ແລະ caching ໄດ້ ~ 10-15 GB:

3 ນາຍຫນ້າ, ຂະຫນາດຂໍ້ຄວາມ - 100 bytes

ໃນຂະນະທີ່ຂະຫນາດຂໍ້ຄວາມຫຼຸດລົງ, ອັດຕາການສົ່ງຜ່ານຫຼຸດລົງປະມານ 15-20%: ເວລາທີ່ໃຊ້ໃນການປຸງແຕ່ງແຕ່ລະຂໍ້ຄວາມມີຜົນກະທົບຕໍ່ມັນ. ນອກຈາກນັ້ນ, ການໂຫຼດຂອງໂປເຊດເຊີໄດ້ເພີ່ມຂຶ້ນເກືອບສອງເທົ່າ.

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

4 ນາຍຫນ້າ, ຂະຫນາດຂໍ້ຄວາມ - 512 bytes

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

ການບໍລິໂພກຫນ່ວຍຄວາມຈໍາຂອງເຄື່ອງ JVM ຍັງຄົງຢູ່ຂ້າງລຸ່ມນີ້ 2 GB:

ການເຮັດວຽກຂອງນາຍຫນ້າທີ່ມີໄດໄດ້ຮັບຜົນກະທົບຈາກຄວາມບໍ່ສົມດຸນຂອງພາທິຊັນ:

ການຄົ້ນພົບ

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

ພວກເຮົາອອກແບບ Supertubes ເພື່ອນຳໃຊ້ກຸ່ມກຸ່ມໄດ້ໄວ ແລະງ່າຍດາຍ, ກຳນົດຄ່າມັນ, ເພີ່ມ/ລຶບນາຍໜ້າ ແລະຫົວຂໍ້ອອກ, ຕອບສະໜອງຕໍ່ການແຈ້ງເຕືອນ ແລະຮັບປະກັນວ່າ Kafka ໂດຍທົ່ວໄປແລ້ວຈະເຮັດວຽກຢ່າງຖືກຕ້ອງໃນ Kubernetes. ເປົ້າຫມາຍຂອງພວກເຮົາແມ່ນເພື່ອຊ່ວຍໃຫ້ທ່ານສຸມໃສ່ວຽກງານຕົ້ນຕໍ ("ສ້າງ" ແລະ "ບໍລິໂພກ" ຂໍ້ຄວາມ Kafka), ແລະອອກຈາກການເຮັດວຽກຫນັກທັງຫມົດໃຫ້ກັບ Supertubes ແລະຜູ້ປະກອບການ Kafka.

ຖ້າທ່ານສົນໃຈໃນເຕັກໂນໂລຢີ Banzai Cloud ແລະໂຄງການ Open Source, ລົງທະບຽນກັບບໍລິສັດທີ່ GitHub, LinkedIn ຫຼື Twitter.

PS ຈາກນັກແປ

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

• «ເລື່ອງຫນຶ່ງກັບຜູ້ປະຕິບັດການ Redis ໃນ K8s ແລະການທົບທວນຄືນຂະຫນາດນ້ອຍຂອງຜົນປະໂຫຍດສໍາລັບການວິເຄາະຂໍ້ມູນຈາກຖານຂໍ້ມູນນີ້"
• «ການເຄື່ອນຍ້າຍຂອງ RabbitMQ ໄປ Kubernetes ແບບບໍ່ຕິດຂັດ"
• «zetcd ຈາກ CoreOS: ການປ່ຽນ ZooKeeper ດ້ວຍ...ບ່ອນເກັບຂໍ້ມູນ ແລະ ອື່ນໆ".

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