تحديد الحجم المناسب لمجموعة كافكا في Kubernetes

ملحوظة perev. : في هذه المقالة ، يشارك Banzai Cloud مثالًا على استخدام أدواته الخاصة لتسهيل تشغيل Kafka داخل Kubernetes. توضح هذه التعليمات كيف يمكنك تحديد الحجم الأمثل للبنية التحتية وتكوين كافكا نفسها لتحقيق الإنتاجية المطلوبة.



أباتشي كافكا هي منصة تدفق موزعة لإنشاء أنظمة بث موثوقة وقابلة للتطوير وعالية الأداء في الوقت الفعلي. يمكن توسيع ميزاته المثيرة للإعجاب مع Kubernetes. للقيام بذلك ، قمنا بتطوير مشغل Kafka مفتوح المصدر وأداة تسمى Supertubes. إنها تسمح لك بتشغيل 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 لتلبية متطلبات عرض النطاق الترددي. يتم تحديد أقصى أداء لكل وسيط من خلال أداء مكونات البنية التحتية في جوهرها ، مثل الذاكرة والمعالج وسرعة القرص وعرض النطاق الترددي للشبكة وما إلى ذلك.

من الناحية المثالية ، يجب أن يكون تكوين الوسيط بحيث يتم استخدام جميع عناصر البنية التحتية إلى أقصى حد من قدراتها. ومع ذلك ، في الحياة الواقعية ، هذا الإعداد معقد للغاية. من المرجح أن يقوم المستخدمون بتكوين الوسطاء بطريقة تزيد من استخدام مكون أو اثنين (القرص أو الذاكرة أو المعالج). بشكل عام ، يظهر الوسيط أقصى أداء عندما يسمح لك تكوينه باستخدام أبطأ مكون "بالكامل". حتى نتمكن من الحصول على فكرة تقريبية عن الحمل الذي يمكن أن يتعامل معه وسيط واحد.

نظريًا ، يمكننا أيضًا تقدير عدد الوسطاء المطلوبين للعمل مع حمولة معينة. ومع ذلك ، من الناحية العملية ، هناك العديد من خيارات التكوين على مستويات مختلفة بحيث يكون من الصعب جدًا (إن لم يكن من المستحيل) تقييم الأداء المحتمل لتكوين معين. بعبارة أخرى ، من الصعب جدًا التخطيط للتهيئة ، بدءًا من أداء معين.

بالنسبة لمستخدمي Supertubes ، نستخدم عادةً النهج التالي: ابدأ ببعض التكوين (بنية أساسية + إعدادات) ، ثم قم بقياس أدائها ، واضبط إعدادات الوسيط ، وكرر العملية مرة أخرى. يحدث هذا حتى يتم استخدام إمكانات أبطأ مكون للبنية التحتية بشكل كامل.

بهذه الطريقة ، نحصل على فكرة أوضح عن عدد الوسطاء الذين تحتاجهم المجموعة للتعامل مع حمل معين (يعتمد عدد الوسطاء أيضًا على عوامل أخرى ، مثل الحد الأدنى لعدد النسخ المتماثلة للرسالة لضمان الاستقرار ، وعدد قادة الأقسام ، وما إلى ذلك). بالإضافة إلى ذلك ، لدينا فكرة عن التحجيم الرأسي لمكون البنية التحتية المطلوب.

ستناقش هذه المقالة الخطوات التي نتخذها "للضغط على كل شيء" من أبطأ المكونات في التكوينات الأولية وقياس صبيب مجموعة كافكا. يتطلب التكوين المرن للغاية وجود ثلاثة وسطاء عاملين على الأقل (min.insync.replicas=3) متباعدة في ثلاث مناطق مختلفة لإمكانية الوصول. لتكوين البنية الأساسية Kubernetes وتوسيع نطاقها ومراقبتها ، نستخدم منصة إدارة الحاويات السحابية المختلطة الخاصة بنا - Pipeline . وهو يدعم على الأجهزة (المعدنية العارية ، VMware) وخمسة أنواع من الغيوم (Alibaba و AWS و Azure و Google و Oracle) ، بالإضافة إلى أي مجموعة منها.

أفكار حول البنية التحتية وتكوين مجموعة كافكا


بالنسبة إلى الأمثلة أدناه ، اخترنا AWS كموفر الخدمة السحابية و EKS كتوزيع Kubernetes. يمكن تنفيذ تكوين مماثل باستخدام PKE ، وهو توزيع Kubernetes من Banzai Cloud ، معتمد من قبل CNCF.

القرص


تقدم أمازون أنواعًا مختلفة من مجلدات EBS . SSDs هي أساس gp2 و io1 ، ومع ذلك ، لضمان الإنتاجية العالية ، تستهلك gp2 القروض المتراكمة (أرصدة I / O) ، لذلك فضلنا نوع io1 ، الذي يوفر إنتاجية عالية مستقرة.

أنواع المثيل


يعتمد أداء كافكا بشكل كبير على ذاكرة التخزين المؤقت للصفحات لنظام التشغيل ، لذلك نحتاج إلى أمثلة ذات ذاكرة كافية للوسطاء (JVMs) وذاكرة التخزين المؤقت للصفحة. يعد المثيل c5.2xlarge بداية جيدة ، حيث يحتوي على ذاكرة 16 جيجا بايت ومحسن للعمل مع EBS . عيبه هو أنه قادر على توفير أقصى أداء لمدة لا تزيد عن 30 دقيقة كل 24 ساعة. إذا كان عبء العمل الخاص بك يتطلب الحد الأقصى من الأداء على مدى فترة زمنية أطول ، فراجع أنواع المثيلات الأخرى. لقد فعلنا ذلك تمامًا ، وتوقفنا عند c5.4xlarge . يوفر أقصى إنتاجية 593.75 ميجابت / ثانية.. أقصى إنتاجية لوحدة تخزين EBS io1 أعلى من مثيل c5.4x تكبير ، لذا فإن أبطأ عنصر للبنية التحتية هو على الأرجح صبيب الإدخال / الإخراج لهذا النوع من المثيلات (والذي يجب تأكيده أيضًا من خلال نتائج اختبارات التحميل لدينا).

شبكة الاتصال


يجب أن يكون النطاق الترددي للشبكة كبيرًا جدًا مقارنة بأداء مثيل VM والقرص ، وإلا تصبح الشبكة اختناقًا. في حالتنا ، تدعم واجهة الشبكة c5.4xlarge سرعات تصل إلى 10 جيجابت / ثانية ، وهو أعلى بكثير من عرض النطاق الترددي لمثيل I / O لـ VM.

نشر الوسيط


يجب نشر الوسطاء (المخطط لهم في Kubernetes) إلى العقد المخصصة لتجنب المنافسة مع العمليات الأخرى على موارد المعالج والذاكرة والشبكة والقرص.

نسخة جافا


الخيار المنطقي هو Java 11 ، لأنه متوافق مع Docker بمعنى أن JVM تحدد المعالجات والذاكرة المتاحة بشكل صحيح للحاوية التي يعمل فيها الوسيط. مع العلم أن حدود المعالج مهمة ، يقوم JVM داخليًا وشفافًا بتعيين عدد خيوط GC وخيوط مترجم JIT. استخدمنا صورة كافكا banzaicloud/kafka:2.13-2.4.0تتضمن كافكا 2.4.0 (سكالا 2.13) في جافا 11.

إذا كنت ترغب في معرفة المزيد عن Java / JVM على Kubernetes ، فراجع منشوراتنا التالية:


إعدادات ذاكرة الوسيط


هناك جانبان رئيسيان لضبط ذاكرة الوسيط: إعدادات JVM و Kubernetes pod. يجب أن يكون حد الذاكرة الذي تم تعيينه للجراب أكبر من الحد الأقصى لحجم كومة الذاكرة المؤقتة بحيث يكون لـ JVM مساحة كافية لمساحة Java الوصفية في ذاكرته وذاكرة التخزين المؤقت لصفحة نظام التشغيل التي يستخدمها Kafka بنشاط. في اختباراتنا ، قمنا بتشغيل وسطاء Kafka مع المعلمات -Xmx4G -Xms2G، وكان الحد الأقصى لذاكرة الجراب 10 Gi. يرجى ملاحظة أن إعدادات الذاكرة لJVM يمكن الحصول تلقائيا باستخدام -XX:MaxRAMPercentageو -X:MinRAMPercentage، استنادا إلى حدود الذاكرة لجراب.

إعدادات معالج الوسيط


بشكل عام ، يمكنك زيادة الإنتاجية عن طريق زيادة التوافق عن طريق زيادة عدد الخيوط التي يستخدمها كافكا. كلما زاد عدد المعالجات المتاحة لكافكا ، كان ذلك أفضل. في اختبارنا ، بدأنا بحد أقصى 6 معالجات ورفعنا (تكرارًا) عددهم تدريجيًا إلى 15. بالإضافة إلى ذلك ، قمنا بتعيين num.network.threads=12إعدادات الوسيط لزيادة عدد التدفقات التي تتلقى البيانات من الشبكة وإرسالها. بعد أن اكتشفوا على الفور أن وسطاء المتابعين لا يمكنهم تلقي نسخ متماثلة بسرعة كافية ، فقد رفعوا num.replica.fetchersإلى 4 لزيادة سرعة نسخ وسطاء المتابعين للرسائل من القادة.

أداة توليد الحمل


تأكد من أن إمكانات مولد الحمل المحدد لا تنفد قبل أن تصل كتلة كافكا (التي يعمل مقياس الأداء الخاص بها) إلى أقصى حمولة لها. بمعنى آخر ، من الضروري إجراء تقييم أولي لقدرات أداة توليد الحمل ، بالإضافة إلى تحديد أنواع المثيلات لها بعدد كاف من المعالجات والذاكرة. في هذه الحالة ، ستنتج أداتنا حملاً أكثر مما يمكن أن تهضمه مجموعة كافكا. بعد العديد من التجارب ، استقرنا على ثلاث نسخ من c5.4xlarge ، تم إطلاق المولد في كل منها.

المرجعية


قياس الأداء هو عملية تكرارية تتضمن الخطوات التالية:

  • إعداد البنية التحتية (مجموعة EKS ، مجموعة كافكا ، أداة توليد الحمل ، وكذلك بروميثيوس وجرافانا) ؛
  • توليد الحمل لفترة معينة لتصفية الانحرافات العشوائية في مؤشرات الأداء المجمعة ؛
  • تحسين البنية التحتية وتكوين الوسيط بناءً على مؤشرات الأداء الملحوظة ؛
  • تكرار العملية حتى الوصول إلى المستوى المطلوب من عرض النطاق الترددي لكافكا. في نفس الوقت ، يجب أن يكون مستنسخًا بشكل ثابت ويظهر الحد الأدنى من اختلافات عرض النطاق الترددي.

يصف القسم التالي الخطوات التي تم تنفيذها أثناء مجموعة اختبار قياس الأداء.

أدوات


تم استخدام الأدوات التالية لنشر التكوين الأساسي وتوليد الحمل وقياس الأداء بسرعة:

  • Banzai Cloud Pipeline EKS Amazon c Prometheus ( Kafka ) Grafana ( ). Pipeline , , , , , .
  • Sangrenel — Kafka.
  • Grafana Kafka : Kubernetes Kafka, Node Exporter.
  • سوبرتوبس CLI عن أسهل طريقة لتكوين كتلة كافكا في Kubernetes. يتم تثبيت Zookeeper ومشغل Kafka و Envoy والعديد من المكونات الأخرى وتكوينها بشكل صحيح لبدء مجموعة Kafka الجاهزة للإنتاج في Kubernetes.
    • لتثبيت SuperTubes CLI ، استخدم التعليمات الواردة هنا .



مجموعة EKS


قم بإعداد مجموعة EKS مع عقد عمل مخصصة c5.4x بحجم كبير في مناطق توفر مختلفة للقرون مع وسطاء 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 باستخدام الأنابيب الفائقة CLI:

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

مجموعة كافكا


افتراضيًا ، تستخدم EKS وحدات تخزين gp2 EBS ، لذلك تحتاج إلى إنشاء فئة تخزين منفصلة استنادًا إلى وحدات تخزين 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. , , , , . (consumers) , , , .
  • 20 worker' (-workers=20). worker 5 producer', worker' Kafka. 100 producer', Kafka.

مراقبة الكتلة


أثناء اختبار الإجهاد لمجموعة كافكا ، قمنا أيضًا بمراقبة صحتها للتأكد من عدم إعادة تشغيل الكبسولة ، والنسخ المتماثلة غير المتزامنة ، والحد الأقصى من الإنتاجية مع الحد الأدنى من التقلبات:

  • يكتب مولد الحمل إحصائيات قياسية حول عدد الرسائل المنشورة ومستوى الأخطاء. يجب أن تظل النسبة المئوية للأخطاء في القيمة 0,00%.
  • يوفر نظام تثبيت السرعة ، الذي يتم نشره بواسطة مشغل kafka ، لوحة تحكم يمكننا من خلالها مراقبة حالة الكتلة. لعرض هذه اللوحة ، قم بما يلي:

    supertubes cluster cruisecontrol show -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file>
  • مستوى ISR (عدد النسخ المتماثلة في المزامنة) للتقلص والتوسع هو 0.

نتائج القياس


3 وسطاء ، حجم الرسالة - 512 بايت


من خلال الأقسام الموزعة بالتساوي عبر ثلاثة وسطاء ، تمكنا من تحقيق أداء ~ 500 ميجا بايت / ثانية (حوالي 990 ألف رسالة في الثانية) :







لم يتجاوز استهلاك ذاكرة الجهاز الظاهري JVM 2 جيجا بايت:







وصل النطاق الترددي للقرص إلى الحد الأقصى لعرض النطاق الترددي للإدخال / الإخراج العقدة في جميع الحالات الثلاث التي عمل عليها الوسطاء:







من البيانات على استخدام الذاكرة من قبل العقد ، يتبع ذلك أن التخزين المؤقت للنظام والتخزين المؤقت استغرق ~ 10-15 جيجابايت:







3 وسطاء ، حجم الرسالة - 100 بايت


مع انخفاض حجم الرسالة ، ينخفض ​​معدل النقل بحوالي 15-20٪: يتأثر الوقت المنقضي في معالجة كل رسالة. بالإضافة إلى ذلك ، تضاعف حمل المعالج تقريبًا.







نظرًا لأن عقد الوسيط لا تزال تحتوي على نواة غير مستخدمة ، يمكنك تحسين الأداء عن طريق تغيير تكوين Kafka. هذه ليست مهمة سهلة ، لذلك ، لزيادة الإنتاجية ، من الأفضل العمل مع الرسائل الأكبر.

4 وسطاء ، حجم الرسالة - 512 بايت


يمكنك بسهولة زيادة أداء مجموعة Kafka ببساطة عن طريق إضافة وسطاء جدد والحفاظ على توازن الأقسام (وهذا يضمن توزيعًا متساويًا للحمل بين الوسطاء). في حالتنا ، بعد إضافة وسيط ، زاد معدل نقل الكتلة إلى ~ 580 ميجابايت / ثانية (~ 1.1 مليون رسالة في الثانية) . تبين أن النمو كان أصغر من المتوقع: ويرجع ذلك أساسًا إلى عدم توازن الأقسام (لا يعمل جميع الوسطاء في ذروة الفرص).









لا يزال استهلاك الذاكرة بواسطة آلة JVM أقل من 2 غيغابايت:









أثر اختلال التوازن على تشغيل الوسطاء بمحركات الأقراص:









الموجودات


يمكن توسيع النهج التكراري المذكور أعلاه ليشمل سيناريوهات أكثر تعقيدًا ، بما في ذلك مئات المستهلكين ، وإعادة التقسيم ، والتحديثات الدورية ، وإعادة تشغيل الحافظة ، إلخ. كل هذا يسمح لنا بتقييم حدود قدرات مجموعة كافكا في ظروف مختلفة ، وتحديد الاختناقات في عملها وإيجاد طرق للتعامل معها.

لقد طورنا Supertubes لنشر مجموعة بسرعة وسهولة ، وتهيئتها ، وإضافة / إزالة الوسطاء والموضوعات ، والرد على التنبيهات ، وضمان عمل كافكا بشكل صحيح في Kubernetes ككل. هدفنا هو المساعدة في التركيز على المهمة الرئيسية ("توليد" و "استهلاك" رسائل كافكا) ، وتوفير كل العمل الشاق لمشغل Supertubes و Kafka.

إذا كنت مهتما في مجال تكنولوجيا انج الغيمة والمشاريع المفتوحة المصدر، والاشتراك في الشركة على جيثب ، ينكدين أو تويتر .

ملاحظة من المترجم


اقرأ أيضا في مدونتنا:


All Articles