🥇การกำหนดขนาดที่เหมาะสมสำหรับคลัสเตอร์ Kafka ใน Kubernetes

บันทึก. แปล: ในบทความนี้ Banzai Cloud แบ่งปันตัวอย่างวิธีการใช้เครื่องมือแบบกำหนดเองเพื่อทำให้ Kafka ใช้งานได้ง่ายขึ้นภายใน Kubernetes คำแนะนำต่อไปนี้แสดงให้เห็นว่าคุณสามารถกำหนดขนาดโครงสร้างพื้นฐานที่เหมาะสมที่สุดและกำหนดค่า Kafka เองเพื่อให้ได้ปริมาณงานที่ต้องการได้อย่างไร

Apache Kafka เป็นแพลตฟอร์มสตรีมมิ่งแบบกระจายสำหรับการสร้างระบบสตรีมมิ่งแบบเรียลไทม์ที่เชื่อถือได้ ปรับขนาดได้ และมีประสิทธิภาพสูง ความสามารถที่น่าประทับใจสามารถขยายได้โดยใช้ Kubernetes เพื่อสิ่งนี้เราได้พัฒนา โอเพ่นซอร์สโอเปอเรเตอร์ Kafka และเครื่องมือที่เรียกว่า ซุปเปอร์ทูบส์. ช่วยให้คุณสามารถรัน Kafka บน Kubernetes และใช้ฟีเจอร์ต่างๆ ของมันได้ เช่น การปรับแต่งการกำหนดค่าโบรกเกอร์อย่างละเอียด การปรับขนาดตามหน่วยเมตริกพร้อมการปรับสมดุลใหม่ การรับรู้ของแร็ค “แบบนุ่มนวล” (สง่า) การเปิดตัวการอัปเดต ฯลฯ

ลองใช้ Supertubes ในคลัสเตอร์ของคุณ:
curl https://getsupertubes.sh | sh и supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>
หรือติดต่อ เอกสาร. คุณยังสามารถอ่านเกี่ยวกับความสามารถบางอย่างของ Kafka ซึ่งทำงานอัตโนมัติโดยใช้ Supertubes และตัวดำเนินการ Kafka เราได้เขียนเกี่ยวกับพวกเขาแล้วในบล็อก:

ไม่นะ! อีกหนึ่งตัวดำเนินการ Kafka สำหรับ Kubernetes;

ตรวจสอบและใช้งาน Kafka ตามตัวชี้วัด Prometheus;

การรับรู้ของ Kafka บน Kubernetes;

ใช้ Apache Kafka บน Istio - เกณฑ์มาตรฐาน;

ผู้ใช้รับรองความถูกต้องและเข้าถึงคลัสเตอร์ควบคุมด้วยตัวดำเนินการ Kafka;

การอัปเกรดแบบต่อเนื่องของ Kafka และการกำหนดค่าแบบไดนามิกบน Kubernetes;

ตัวกรองโปรโตคอลทูตสำหรับ Kafka แบบตาข่าย.

เมื่อคุณตัดสินใจที่จะปรับใช้คลัสเตอร์ Kafka บน Kubernetes คุณอาจต้องเผชิญกับความท้าทายในการกำหนดขนาดที่เหมาะสมที่สุดของโครงสร้างพื้นฐานพื้นฐาน และความจำเป็นในการปรับแต่งการกำหนดค่า Kafka ของคุณอย่างละเอียดเพื่อให้ตรงตามข้อกำหนดปริมาณการประมวลผล ประสิทธิภาพสูงสุดของแต่ละโบรกเกอร์จะพิจารณาจากประสิทธิภาพของส่วนประกอบโครงสร้างพื้นฐาน เช่น หน่วยความจำ โปรเซสเซอร์ ความเร็วดิสก์ แบนด์วิดท์เครือข่าย ฯลฯ

ตามหลักการแล้ว การกำหนดค่านายหน้าควรเป็นเช่นนั้นเพื่อให้องค์ประกอบโครงสร้างพื้นฐานทั้งหมดถูกใช้อย่างเต็มความสามารถ อย่างไรก็ตาม ในชีวิตจริง การตั้งค่านี้ค่อนข้างซับซ้อน มีแนวโน้มว่าผู้ใช้จะกำหนดค่าโบรกเกอร์เพื่อเพิ่มการใช้ส่วนประกอบหนึ่งหรือสองอย่างให้สูงสุด (ดิสก์ หน่วยความจำ หรือโปรเซสเซอร์) โดยทั่วไปแล้ว โบรกเกอร์จะแสดงประสิทธิภาพสูงสุดเมื่อการกำหนดค่าอนุญาตให้ใช้ส่วนประกอบที่ช้าที่สุดได้เต็มประสิทธิภาพ ด้วยวิธีนี้เราจะได้แนวคิดคร่าวๆ เกี่ยวกับภาระที่โบรกเกอร์รายหนึ่งสามารถจัดการได้

ตามทฤษฎีแล้ว เรายังสามารถประมาณจำนวนนายหน้าที่ต้องจัดการภาระงานที่กำหนดได้ อย่างไรก็ตาม ในทางปฏิบัติมีตัวเลือกการกำหนดค่ามากมายในระดับที่แตกต่างกัน ซึ่งเป็นเรื่องยากมาก (หากเป็นไปไม่ได้) ในการประเมินประสิทธิภาพที่เป็นไปได้ของการกำหนดค่าเฉพาะ กล่าวอีกนัยหนึ่ง การวางแผนการกำหนดค่าตามประสิทธิภาพที่กำหนดเป็นเรื่องยากมาก

สำหรับผู้ใช้ Supertubes เรามักจะใช้วิธีการต่อไปนี้: เราเริ่มต้นด้วยการกำหนดค่าบางอย่าง (โครงสร้างพื้นฐาน + การตั้งค่า) จากนั้นวัดประสิทธิภาพ ปรับการตั้งค่าโบรกเกอร์ และทำซ้ำขั้นตอนอีกครั้ง สิ่งนี้จะเกิดขึ้นจนกว่าองค์ประกอบที่ช้าที่สุดของโครงสร้างพื้นฐานจะถูกนำมาใช้อย่างเต็มที่

ด้วยวิธีนี้ เราจึงเข้าใจได้ชัดเจนว่าคลัสเตอร์ต้องใช้ตัวรับจำนวนเท่าใดในการจัดการกับภาระงานบางอย่าง (จำนวนตัวรับส่งยังขึ้นอยู่กับปัจจัยอื่นๆ เช่น จำนวนแบบจำลองข้อความขั้นต่ำเพื่อให้แน่ใจว่ามีความยืดหยุ่น จำนวนพาร์ติชัน ผู้นำ ฯลฯ) นอกจากนี้ เรายังได้รับข้อมูลเชิงลึกว่าองค์ประกอบโครงสร้างพื้นฐานใดบ้างที่ต้องปรับขนาดตามแนวตั้ง

บทความนี้จะพูดถึงขั้นตอนที่เราดำเนินการเพื่อให้ได้ประโยชน์สูงสุดจากส่วนประกอบที่ช้าที่สุดในการกำหนดค่าเริ่มต้น และการวัดปริมาณงานของคลัสเตอร์ Kafka การกำหนดค่าที่มีความยืดหยุ่นสูงจำเป็นต้องมีโบรกเกอร์ที่ทำงานอยู่อย่างน้อยสามราย (min.insync.replicas=3) กระจายอยู่ในโซนการเข้าถึงที่แตกต่างกันสามโซน ในการกำหนดค่า ปรับขนาด และตรวจสอบโครงสร้างพื้นฐาน Kubernetes เราใช้แพลตฟอร์มการจัดการคอนเทนเนอร์ของเราเองสำหรับไฮบริดคลาวด์ - ท่อ. รองรับระบบภายในองค์กร (bare metal, VMware) และคลาวด์ห้าประเภท (Alibaba, AWS, Azure, Google, Oracle) รวมถึงการผสมผสานระหว่างทั้งสองประเภท

ความคิดเกี่ยวกับโครงสร้างพื้นฐานและการกำหนดค่าคลัสเตอร์ Kafka

สำหรับตัวอย่างด้านล่าง เราเลือก AWS เป็นผู้ให้บริการระบบคลาวด์และ EKS เป็นการกระจาย Kubernetes คุณสามารถใช้งานการกำหนดค่าที่คล้ายกันได้ พีเค - การกระจาย Kubernetes จาก Banzai Cloud รับรองโดย CNCF

ดิสก์

อเมซอนมีข้อเสนอต่างๆ ประเภทวอลุ่ม EBS. ที่แกนกลาง gp2 и io1 อย่างไรก็ตาม มีไดรฟ์ SSD เพื่อให้แน่ใจว่ามีปริมาณงานสูง gp2 ใช้เครดิตสะสม (เครดิต I/O)ดังนั้นเราจึงชอบประเภทนั้นมากกว่า io1ซึ่งให้ปริมาณงานสูงสม่ำเสมอ

ประเภทอินสแตนซ์

ประสิทธิภาพของ Kafka ขึ้นอยู่กับแคชเพจของระบบปฏิบัติการเป็นอย่างมาก ดังนั้นเราจึงต้องการอินสแตนซ์ที่มีหน่วยความจำเพียงพอสำหรับโบรกเกอร์ (JVM) และแคชเพจ ตัวอย่าง c5.2xlarge - เริ่มต้นได้ดีเนื่องจากมีหน่วยความจำ 16 GB และ ปรับให้เหมาะกับการทำงานกับ EBS. ข้อเสียคือสามารถให้ประสิทธิภาพสูงสุดได้เพียงไม่เกิน 30 นาทีทุกๆ 24 ชั่วโมง หากปริมาณงานของคุณต้องการประสิทธิภาพสูงสุดในช่วงเวลาที่ยาวนานขึ้น คุณอาจต้องการพิจารณาอินสแตนซ์ประเภทอื่น นั่นคือสิ่งที่เราทำโดยหยุดที่ c5.4xlarge. มันให้ปริมาณงานสูงสุดใน 593,75 เมกะไบต์/วินาที. ปริมาณงานสูงสุดของไดรฟ์ข้อมูล EBS io1 สูงกว่าตัวอย่าง c5.4xlargeดังนั้นองค์ประกอบที่ช้าที่สุดของโครงสร้างพื้นฐานจึงน่าจะเป็นปริมาณงาน I/O ของอินสแตนซ์ประเภทนี้ (ซึ่งการทดสอบโหลดของเราควรยืนยันด้วย)

เครือข่าย

อัตราการส่งข้อมูลของเครือข่ายต้องมีขนาดใหญ่เพียงพอเมื่อเทียบกับประสิทธิภาพของอินสแตนซ์และดิสก์ VM ไม่เช่นนั้นเครือข่ายจะกลายเป็นปัญหาคอขวด ในกรณีของเราคืออินเทอร์เฟซเครือข่าย c5.4xlarge รองรับความเร็วสูงสุด 10 Gb/s ซึ่งสูงกว่าปริมาณการประมวลผล I/O ของอินสแตนซ์ VM อย่างมาก

การปรับใช้นายหน้า

ควรปรับใช้โบรกเกอร์ (ตามกำหนดเวลาใน Kubernetes) กับโหนดเฉพาะเพื่อหลีกเลี่ยงการแข่งขันกับกระบวนการอื่นๆ สำหรับทรัพยากร CPU หน่วยความจำ เครือข่าย และดิสก์

เวอร์ชันจาวา

ตัวเลือกเชิงตรรกะคือ Java 11 เนื่องจากเข้ากันได้กับ Docker ในแง่ที่ว่า JVM กำหนดโปรเซสเซอร์และหน่วยความจำที่พร้อมใช้งานสำหรับคอนเทนเนอร์ที่โบรกเกอร์กำลังทำงานได้อย่างถูกต้อง เมื่อรู้ว่าขีดจำกัดของ CPU นั้นสำคัญ JVM จะตั้งค่าจำนวนเธรด GC และเธรด JIT ภายในและโปร่งใส เราใช้อิมเมจคาฟคา banzaicloud/kafka:2.13-2.4.0ซึ่งรวมถึง Kafka เวอร์ชัน 2.4.0 (Scala 2.13) บน Java 11

หากคุณต้องการเรียนรู้เพิ่มเติมเกี่ยวกับ Java/JVM บน Kubernetes โปรดดูโพสต์ต่อไปนี้:

เหตุใดแอปพลิเคชัน Java ของฉันจึง OOMKilled;

วิธีปรับขนาดคอนเทนเนอร์ให้ถูกต้องสำหรับแอปพลิเคชัน Java 10.

การตั้งค่าหน่วยความจำของนายหน้า

มีสองประเด็นสำคัญในการกำหนดค่าหน่วยความจำของนายหน้า: การตั้งค่าสำหรับ JVM และสำหรับพ็อด Kubernetes ขีดจำกัดหน่วยความจำที่ตั้งไว้สำหรับพ็อดต้องมากกว่าขนาดฮีปสูงสุดเพื่อให้ JVM มีพื้นที่สำหรับ Java metaspace ซึ่งอยู่ในหน่วยความจำของตัวเอง และสำหรับแคชเพจระบบปฏิบัติการที่ Kafka ใช้งานอยู่ ในการทดสอบของเรา เราได้เปิดตัวโบรกเกอร์ Kafka พร้อมพารามิเตอร์ -Xmx4G -Xms2Gและขีดจำกัดหน่วยความจำสำหรับพ็อดคือ 10 Gi. โปรดทราบว่าการตั้งค่าหน่วยความจำสำหรับ JVM สามารถรับได้โดยอัตโนมัติโดยใช้ -XX:MaxRAMPercentage и -X:MinRAMPercentageขึ้นอยู่กับขีดจำกัดหน่วยความจำสำหรับพ็อด

การตั้งค่าตัวประมวลผลนายหน้า

โดยทั่วไป คุณสามารถปรับปรุงประสิทธิภาพได้โดยการเพิ่มความเท่าเทียมโดยการเพิ่มจำนวนเธรดที่ Kafka ใช้ ยิ่งมีโปรเซสเซอร์สำหรับ Kafka มากเท่าไรก็ยิ่งดีเท่านั้น ในการทดสอบของเรา เราเริ่มต้นด้วยขีดจำกัดโปรเซสเซอร์ 6 ตัว และค่อยๆ (ผ่านการวนซ้ำ) เพิ่มจำนวนเป็น 15 ตัว นอกจากนี้ เรายังตั้งค่า num.network.threads=12 ในการตั้งค่าโบรกเกอร์เพื่อเพิ่มจำนวนเธรดที่รับข้อมูลจากเครือข่ายและส่งไป ทันทีที่พบว่านายหน้าผู้ติดตามไม่สามารถรับแบบจำลองได้เร็วเพียงพอ พวกเขาจึงลุกขึ้น num.replica.fetchers เป็น 4 เพื่อเพิ่มความเร็วที่นายหน้าผู้ติดตามจำลองข้อความจากผู้นำ

เครื่องมือสร้างโหลด

คุณควรตรวจสอบให้แน่ใจว่าตัวสร้างโหลดที่เลือกไว้ไม่หมดความจุก่อนที่คลัสเตอร์ Kafka (ซึ่งกำลังทำการวัดประสิทธิภาพ) จะถึงโหลดสูงสุด กล่าวอีกนัยหนึ่ง มีความจำเป็นต้องดำเนินการประเมินเบื้องต้นเกี่ยวกับความสามารถของเครื่องมือสร้างโหลด และเลือกประเภทอินสแตนซ์ด้วยจำนวนโปรเซสเซอร์และหน่วยความจำที่เพียงพอ ในกรณีนี้ เครื่องมือของเราจะสร้างภาระงานมากกว่าที่คลัสเตอร์ Kafka สามารถรองรับได้ หลังจากการทดลองหลายครั้ง เราก็ได้สำเนาสามชุด c5.4xlargeซึ่งแต่ละเครื่องมีเครื่องกำเนิดไฟฟ้าทำงานอยู่

การเปรียบเทียบ

การวัดประสิทธิภาพเป็นกระบวนการทำซ้ำซึ่งประกอบด้วยขั้นตอนต่อไปนี้:

การตั้งค่าโครงสร้างพื้นฐาน (คลัสเตอร์ EKS, คลัสเตอร์ Kafka, เครื่องมือสร้างโหลด รวมถึง Prometheus และ Grafana)
สร้างภาระในช่วงระยะเวลาหนึ่งเพื่อกรองการเบี่ยงเบนแบบสุ่มในตัวบ่งชี้ประสิทธิภาพที่รวบรวม
การปรับโครงสร้างพื้นฐานและการกำหนดค่าของโบรกเกอร์ตามตัวบ่งชี้ประสิทธิภาพที่สังเกตได้
ทำซ้ำขั้นตอนนี้จนกว่าจะได้ปริมาณงานคลัสเตอร์ Kafka ที่ต้องการ ในเวลาเดียวกัน จะต้องทำซ้ำได้อย่างสม่ำเสมอและแสดงให้เห็นถึงการเปลี่ยนแปลงในปริมาณงานที่น้อยที่สุด

ส่วนถัดไปจะอธิบายขั้นตอนที่ดำเนินการระหว่างกระบวนการเปรียบเทียบคลัสเตอร์ทดสอบ

เครื่องมือ

เครื่องมือต่อไปนี้ใช้เพื่อปรับใช้การกำหนดค่าพื้นฐาน สร้างโหลด และวัดประสิทธิภาพอย่างรวดเร็ว:

ไปป์ไลน์คลาวด์บันไซ สำหรับการจัดระเบียบคลัสเตอร์ EKS จาก Amazon c โพร (เพื่อรวบรวมตัวชี้วัด Kafka และโครงสร้างพื้นฐาน) และ กราฟาน่า (เพื่อให้เห็นภาพเมตริกเหล่านี้) เราก็เอาเปรียบ แบบบูรณาการ в ท่อ บริการที่ให้การตรวจสอบแบบรวมศูนย์ การรวบรวมบันทึกแบบรวมศูนย์ การสแกนช่องโหว่ การกู้คืนระบบ การรักษาความปลอดภัยระดับองค์กร และอื่นๆ อีกมากมาย
แซงเกรเนล — เครื่องมือสำหรับการทดสอบโหลดคลัสเตอร์ Kafka
แดชบอร์ด Grafana สำหรับการแสดงภาพตัวชี้วัดและโครงสร้างพื้นฐานของ Kafka: คูเบอร์เนเทส คาฟคา, ผู้ส่งออกโหนด.
Supertubes CLI สำหรับวิธีที่ง่ายที่สุดในการตั้งค่าคลัสเตอร์ Kafka บน Kubernetes Zookeeper, ผู้ปฏิบัติงาน Kafka, Envoy และส่วนประกอบอื่นๆ ได้รับการติดตั้งและกำหนดค่าอย่างเหมาะสมเพื่อรันคลัสเตอร์ Kafka ที่พร้อมใช้งานจริงบน Kubernetes
- เพื่อทำการติดตั้ง ซุปเปอร์ทูบส์ CLI ใช้คำแนะนำที่ให้ไว้ ที่นี่.

คลัสเตอร์ EKS

เตรียมคลัสเตอร์ EKS ด้วยโหนดผู้ปฏิบัติงานเฉพาะ c5.4xlarge ในโซนความพร้อมใช้งานต่างๆ สำหรับพ็อดที่มีโบรกเกอร์ Kafka รวมถึงโหนดเฉพาะสำหรับตัวสร้างโหลดและโครงสร้างพื้นฐานการตรวจสอบ

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

เมื่อคลัสเตอร์ EKS เริ่มทำงานแล้ว ให้เปิดใช้งานการรวมเข้าด้วยกัน บริการตรวจสอบ — เธอจะปรับใช้ Prometheus และ Grafana ลงในคลัสเตอร์

ส่วนประกอบของระบบคาฟคา

ติดตั้งส่วนประกอบของระบบ Kafka (Zookeeper, kafka-operator) ใน EKS โดยใช้ supertubes CLI:

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

คลัสเตอร์คาฟคา

ตามค่าเริ่มต้น 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 และปรับใช้พ็อดนายหน้าบนโหนดในโซนความพร้อมใช้งานที่แตกต่างกันสามโซน:

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 ซึ่งเป็นค่าขั้นต่ำที่แนะนำสำหรับระบบที่ใช้งานจริงที่มีความพร้อมใช้งานสูง

เครื่องมือสร้างโหลด

เราเปิดตัวตัวสร้างโหลดสามชุด (แต่ละชุดเขียนในหัวข้อแยกกัน) สำหรับพ็อดตัวสร้างโหลด คุณต้องตั้งค่าความสัมพันธ์ของโหนดเพื่อให้จัดกำหนดการไว้บนโหนดที่จัดสรรไว้เท่านั้น:

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 การเผยแพร่จะถือว่าประสบความสำเร็จเมื่อได้รับและยืนยันการจำลองข้อความที่ซิงโครไนซ์ทั้งหมดโดยโบรกเกอร์ Kafka ซึ่งหมายความว่าในเกณฑ์มาตรฐาน เราไม่เพียงแต่วัดความเร็วของผู้นำที่ได้รับข้อความเท่านั้น แต่ยังรวมถึงผู้ติดตามของพวกเขาที่จำลองข้อความอีกด้วย จุดประสงค์ของการทดสอบนี้ไม่ใช่เพื่อประเมินความเร็วในการอ่านของผู้บริโภค (ผู้บริโภค) เพิ่งได้รับข้อความที่ยังคงอยู่ในแคชเพจ OS และการเปรียบเทียบกับความเร็วในการอ่านข้อความที่เก็บไว้ในดิสก์
ตัวสร้างโหลดรันคนงาน 20 คนแบบขนาน (-workers=20). ผู้ปฏิบัติงานแต่ละคนประกอบด้วยผู้ผลิต 5 รายที่แชร์การเชื่อมต่อของผู้ปฏิบัติงานกับคลัสเตอร์ Kafka เป็นผลให้แต่ละเครื่องกำเนิดมีผู้ผลิต 100 ราย และทั้งหมดส่งข้อความไปยังคลัสเตอร์ Kafka

การตรวจสอบความสมบูรณ์ของคลัสเตอร์

ในระหว่างการทดสอบโหลดของคลัสเตอร์ Kafka เรายังตรวจสอบความสมบูรณ์เพื่อให้แน่ใจว่าไม่มีการรีสตาร์ทพ็อด ไม่มีการจำลองที่ไม่ซิงค์กัน และปริมาณงานสูงสุดที่มีความผันผวนน้อยที่สุด:

ตัวสร้างโหลดจะเขียนสถิติมาตรฐานเกี่ยวกับจำนวนข้อความที่เผยแพร่และอัตราข้อผิดพลาด อัตราข้อผิดพลาดควรคงเดิม 0,00%.
การควบคุมเรือซึ่งใช้งานโดยผู้ดำเนินการ kafka มีแดชบอร์ดที่เราสามารถตรวจสอบสถานะของคลัสเตอร์ได้ หากต้องการดูแผงนี้ ให้ทำดังนี้
```
supertubes cluster cruisecontrol show -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file>
```
ระดับไอเอสอาร์ (จำนวนเรพลิกา "ที่ซิงค์") การหดตัวและการขยายตัวเท่ากับ 0

ผลการวัด

3 โบรกเกอร์ ขนาดข้อความ 512 ไบต์

ด้วยพาร์ติชั่นที่กระจายอย่างเท่าเทียมกันระหว่างสามโบรกเกอร์ เราจึงสามารถบรรลุประสิทธิภาพได้ ~500 Mb/s (ประมาณ 990 ข้อความต่อวินาที):

ปริมาณการใช้หน่วยความจำของเครื่องเสมือน JVM ไม่เกิน 2 GB:

ปริมาณงานของดิสก์ถึงปริมาณงานของโหนด I/O สูงสุดในทั้งสามอินสแตนซ์ที่นายหน้ากำลังทำงานอยู่:

จากข้อมูลการใช้หน่วยความจำตามโหนด พบว่าการบัฟเฟอร์ของระบบและการแคชใช้เวลาประมาณ ~10-15 GB:

3 โบรกเกอร์ ขนาดข้อความ 100 ไบต์

เมื่อขนาดข้อความลดลง ปริมาณงานจะลดลงประมาณ 15-20%: เวลาที่ใช้ในการประมวลผลแต่ละข้อความจะส่งผลต่อข้อความ นอกจากนี้โหลดของโปรเซสเซอร์ยังเพิ่มขึ้นเกือบสองเท่า

เนื่องจากโหนดโบรกเกอร์ยังคงมีคอร์ที่ไม่ได้ใช้ คุณจึงสามารถปรับปรุงประสิทธิภาพได้โดยการเปลี่ยนการกำหนดค่า Kafka นี่ไม่ใช่งานง่าย ดังนั้นเพื่อเพิ่มปริมาณงาน ควรทำงานกับข้อความที่ใหญ่ขึ้นจะดีกว่า

4 โบรกเกอร์ ขนาดข้อความ 512 ไบต์

คุณสามารถเพิ่มประสิทธิภาพของคลัสเตอร์ Kafka ได้อย่างง่ายดายเพียงเพิ่มโบรกเกอร์ใหม่และรักษาสมดุลของพาร์ติชัน (เพื่อให้แน่ใจว่าโหลดจะกระจายระหว่างโบรกเกอร์เท่าๆ กัน) ในกรณีของเรา หลังจากเพิ่มนายหน้าแล้ว ปริมาณงานของคลัสเตอร์ก็เพิ่มขึ้นเป็น ~580 Mb/s (~1,1 ล้านข้อความต่อวินาที). การเติบโตน้อยกว่าที่คาดไว้: สาเหตุหลักมาจากความไม่สมดุลของพาร์ติชัน (โบรกเกอร์บางรายอาจไม่ทำงานที่ขีดความสามารถสูงสุด)

ปริมาณการใช้หน่วยความจำของเครื่อง JVM ยังคงต่ำกว่า 2 GB:

งานของโบรกเกอร์ที่มีไดรฟ์ได้รับผลกระทบจากความไม่สมดุลของพาร์ติชัน:

ผลการวิจัย

วิธีการทำซ้ำที่นำเสนอข้างต้นสามารถขยายได้เพื่อให้ครอบคลุมสถานการณ์ที่ซับซ้อนมากขึ้นซึ่งเกี่ยวข้องกับผู้บริโภคหลายร้อยราย การแบ่งพาร์ติชัน การอัปเดตทีละส่วน การรีสตาร์ทพ็อด ฯลฯ ทั้งหมดนี้ช่วยให้เราประเมินขีดจำกัดความสามารถของคลัสเตอร์ Kafka ได้ในสภาวะต่างๆ ระบุปัญหาคอขวดในการทำงาน และค้นหาวิธีต่อสู้กับปัญหาเหล่านี้

เราออกแบบ Supertubes เพื่อให้ปรับใช้คลัสเตอร์ได้อย่างรวดเร็วและง่ายดาย กำหนดค่า เพิ่ม/ลบโบรกเกอร์และหัวข้อ ตอบสนองต่อการแจ้งเตือน และตรวจสอบให้แน่ใจว่า Kafka โดยทั่วไปทำงานได้อย่างถูกต้องบน Kubernetes เป้าหมายของเราคือการช่วยให้คุณมุ่งความสนใจไปที่งานหลัก (“สร้าง” และ “บริโภค” ข้อความของ Kafka) และปล่อยให้งานหนักทั้งหมดเป็นหน้าที่ของ Supertubes และผู้ปฏิบัติงานของ Kafka

หากคุณสนใจเทคโนโลยี Banzai Cloud และโครงการ Open Source สามารถสมัครสมาชิกบริษัทได้ที่ GitHub, LinkedIn หรือ Twitter.

ปล.จากผู้แปล

อ่านเพิ่มเติมในบล็อกของเรา:

ที่มา: will.com

การกำหนดขนาดที่เหมาะสมสำหรับคลัสเตอร์ Kafka ใน Kubernetes

ความคิดเกี่ยวกับโครงสร้างพื้นฐานและการกำหนดค่าคลัสเตอร์ Kafka

ดิสก์

ประเภทอินสแตนซ์

เครือข่าย

การปรับใช้นายหน้า

เวอร์ชันจาวา

การตั้งค่าหน่วยความจำของนายหน้า

การตั้งค่าตัวประมวลผลนายหน้า

เครื่องมือสร้างโหลด

การเปรียบเทียบ

เครื่องมือ

คลัสเตอร์ EKS

ส่วนประกอบของระบบคาฟคา

คลัสเตอร์คาฟคา

หัวข้อ

เครื่องมือสร้างโหลด

การตรวจสอบความสมบูรณ์ของคลัสเตอร์

ผลการวัด

3 โบรกเกอร์ ขนาดข้อความ 512 ไบต์

3 โบรกเกอร์ ขนาดข้อความ 100 ไบต์

4 โบรกเกอร์ ขนาดข้อความ 512 ไบต์

ผลการวิจัย

ปล.จากผู้แปล

เพิ่มความคิดเห็น ยกเลิกการตอบ