קבע את הגודל המתאים לאשכול קפקא ב-Kubernetes

הערה. תרגום: במאמר זה, Banzai Cloud חולק דוגמה כיצד ניתן להשתמש בכלים המותאמים אישית שלו כדי להפוך את קפקא לקל יותר לשימוש בתוך Kubernetes. ההוראות הבאות ממחישות כיצד תוכל לקבוע את הגודל האופטימלי של התשתית שלך ולהגדיר את קפקא עצמה כדי להשיג את התפוקה הנדרשת.

Apache Kafka היא פלטפורמת סטרימינג מבוזרת ליצירת מערכות סטרימינג בזמן אמת אמינות, ניתנות להרחבה ובעלות ביצועים גבוהים. ניתן להרחיב את היכולות המרשימות שלו באמצעות Kubernetes. בשביל זה פיתחנו מפעיל קוד פתוח של קפקא וכלי שנקרא צינורות על. הם מאפשרים לך להפעיל את קפקא ב-Kubernetes ולהשתמש בתכונות השונות שלו, כמו כוונון עדין של תצורת הברוקר, קנה מידה מבוסס מדדים עם איזון מחדש, מודעות rack, "רך" (מְעוּדָן) הפקת עדכונים וכו'.

נסה את Supertubes באשכול שלך:

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

או ליצור קשר תיעוד. ניתן גם לקרוא על חלק מהיכולות של קפקא, שהעבודה איתה אוטומטית באמצעות Supertubes ואופרטור קפקא. כבר כתבנו עליהם בבלוג:

• אוי לא! עוד מפעיל קפקא עבור Kubernetes;
• לפקח ולהפעיל את קפקא על בסיס מדדי פרומתאוס;
• מודעות מתלה קפקא ב-Kubernetes;
• הפעלת אפאצ'י קפקא על איסטיו - רף;
• אימות משתמש וגישה לאשכולות עם מפעיל קפקא;
• שדרוג מתגלגל של קפקא ותצורה דינמית ב-Kubernetes;
• מסנן פרוטוקול שליח לקפקא, מרושת.

כאשר תחליט לפרוס אשכול קפקא ב-Kubernetes, סביר להניח שתעמוד בפני האתגר של קביעת הגודל האופטימלי של התשתית הבסיסית והצורך לכוונן עדין את תצורת קפקא שלך כדי לעמוד בדרישות התפוקה. הביצועים המקסימליים של כל ברוקר נקבעים על פי הביצועים של רכיבי התשתית הבסיסיים, כגון זיכרון, מעבד, מהירות דיסק, רוחב פס רשת וכו'.

באופן אידיאלי, תצורת המתווך צריכה להיות כזו שכל רכיבי התשתית ישמשו את היכולות המקסימליות שלהם. עם זאת, בחיים האמיתיים הגדרה זו מורכבת למדי. סביר יותר שמשתמשים יגדירו מתווכים כדי למקסם את השימוש ברכיב אחד או שניים (דיסק, זיכרון או מעבד). באופן כללי, ברוקר מציג ביצועים מקסימליים כאשר התצורה שלו מאפשרת להשתמש ברכיב האיטי ביותר במלואו. כך נוכל לקבל מושג גס על העומס שברוקר אחד יכול להתמודד איתו.

תיאורטית, אנו יכולים גם להעריך את מספר המתווכים הנדרשים לטיפול בעומס נתון. עם זאת, בפועל יש כל כך הרבה אפשרויות תצורה ברמות שונות שקשה מאוד (אם לא בלתי אפשרי) להעריך את הביצועים הפוטנציאליים של תצורה מסוימת. במילים אחרות, קשה מאוד לתכנן תצורה המבוססת על ביצועים מסוימים.

עבור משתמשי Supertubes, אנחנו בדרך כלל נוקטים בגישה הבאה: אנחנו מתחילים עם תצורה כלשהי (תשתית + הגדרות), ואז מודדים את הביצועים שלה, מתקנים את הגדרות הברוקר וחוזרים על התהליך שוב. זה קורה עד שהרכיב האיטי ביותר של התשתית מנוצל במלואו.

בדרך זו, אנו מקבלים מושג ברור יותר כמה מתווכים צריך אשכול כדי להתמודד עם עומס מסוים (מספר המתווכים תלוי גם בגורמים אחרים, כגון המספר המינימלי של העתקי הודעות כדי להבטיח גמישות, מספר המחיצות מנהיגים וכו'). בנוסף, אנו מקבלים תובנה לגבי אילו רכיבי תשתית דורשים קנה מידה אנכי.

מאמר זה ידבר על הצעדים שאנו נוקטים כדי להפיק את המרב מהרכיבים האיטיים ביותר בתצורות ראשוניות ולמדוד את התפוקה של אשכול קפקא. תצורה עמידה ביותר דורשת לפחות שלושה מתווכים פועלים (min.insync.replicas=3), המופץ על פני שלושה אזורי נגישות שונים. כדי להגדיר, להרחיב ולנטר את תשתית Kubernetes, אנו משתמשים בפלטפורמת ניהול קונטיינרים משלנו עבור עננים היברידיים - צינור. הוא תומך במקום (מתכת חשופה, VMware) ובחמישה סוגים של עננים (Alibaba, AWS, Azure, Google, Oracle), כמו גם כל שילוב ביניהם.

מחשבות על תשתית ותצורת אשכולות קפקא

עבור הדוגמאות שלהלן, בחרנו ב-AWS כספקית הענן וב-EKS כהפצת Kubernetes. ניתן ליישם תצורה דומה באמצעות P.K.E. - הפצת Kubernetes מבית Banzai Cloud, מאושר על ידי CNCF.

דיסק

אמזון מציעה מגוון סוגי נפח EBS. בבסיס gp2 и io1 עם זאת, ישנם כונני SSD כדי להבטיח תפוקה גבוהה gp2 צורך זיכויים שנצברו (קרדיט I/O), אז העדפנו את הסוג io1, שמציע תפוקה גבוהה עקבית.

סוגי מופעים

הביצועים של קפקא תלויים מאוד במטמון העמודים של מערכת ההפעלה, כך שאנו זקוקים למופעים עם מספיק זיכרון עבור המתווכים (JVM) ומטמון העמודים. למשל c5.2x להגדיל - התחלה טובה, מכיוון שיש לו 16 ג'יגה-בייט של זיכרון ו מותאם לעבודה עם EBS. החיסרון שלו הוא שהוא מסוגל לספק ביצועים מקסימליים רק לא יותר מ-30 דקות כל 24 שעות. אם עומס העבודה שלך דורש ביצועי שיא לאורך תקופה ארוכה יותר, מומלץ לשקול סוגי מופעים אחרים. זה בדיוק מה שעשינו, נעצרנו c5.4x להגדיל. זה מספק תפוקה מקסימלית פנימה 593,75 Mb/s. תפוקה מקסימלית של נפח EBS io1 גבוה מהמופע c5.4x להגדיל, כך שהרכיב האיטי ביותר של התשתית עשוי להיות תפוקת ה-I/O מסוג זה (שגם בדיקות העומס שלנו אמורות לאשר).

רשת

תפוקת הרשת חייבת להיות גדולה מספיק בהשוואה לביצועים של מופע ה-VM והדיסק, אחרת הרשת הופכת לצוואר בקבוק. במקרה שלנו, ממשק הרשת c5.4x להגדיל תומך במהירויות של עד 10 Gb/s, שהוא גבוה משמעותית מתפוקת ה-I/O של מופע VM.

פריסת ברוקר

יש לפרוס ברוקרים (מתוזמנים ב-Kubernetes) לצמתים ייעודיים כדי להימנע מתחרות עם תהליכים אחרים עבור משאבי מעבד, זיכרון, רשת ודיסקים.

גרסת Java

הבחירה ההגיונית היא Java 11 מכיוון שהיא תואמת ל-Docker במובן זה שה-JVM קובע בצורה נכונה את המעבדים והזיכרון הזמינים לקונטיינר בו פועל הברוקר. בידיעה שמגבלות ה-CPU חשובות, ה-JVM מגדיר באופן פנימי ושקוף את מספר השרשורים של GC ו-JIT. השתמשנו בתמונה של קפקא banzaicloud/kafka:2.13-2.4.0, הכולל את גרסה 2.4.0 של Kafka (Scala 2.13) ב-Java 11.

אם תרצה ללמוד עוד על Java/JVM ב-Kubernetes, עיין בפוסטים הבאים שלנו:

• מדוע אפליקציית Java שלי היא OOMKilled;
• כיצד להתאים את הגודל הנכון של מיכלים עבור יישומי Java 10.

הגדרות זיכרון ברוקר

ישנם שני היבטים מרכזיים להגדרת זיכרון המתווך: הגדרות עבור ה-JVM ועבור הפוד Kubernetes. מגבלת הזיכרון שהוגדרה עבור פוד חייבת להיות גדולה מגודל הערימה המקסימלית כדי של-JVM יהיה מקום למטא-ספייס של Java השוכן בזיכרון שלו ולמטמון דפי מערכת ההפעלה שבו קפקא משתמש באופן פעיל. בבדיקות שלנו השקנו ברוקרים של קפקא עם פרמטרים -Xmx4G -Xms2G, ומגבלת הזיכרון עבור הפוד הייתה 10 Gi. שימו לב שניתן להשיג הגדרות זיכרון עבור JVM באופן אוטומטי באמצעות -XX:MaxRAMPercentage и -X:MinRAMPercentage, בהתבסס על מגבלת הזיכרון עבור הפוד.

הגדרות מעבד ברוקר

באופן כללי, אתה יכול לשפר את הביצועים על ידי הגדלת המקביליות על ידי הגדלת מספר השרשורים שבהם משתמש קפקא. ככל שיותר מעבדים זמינים עבור קפקא, כך ייטב. בבדיקה שלנו התחלנו עם מגבלה של 6 מעבדים ובהדרגה (באמצעות איטרציות) העלינו את מספרם ל-15. בנוסף, קבענו num.network.threads=12 בהגדרות הברוקר כדי להגדיל את מספר השרשורים שמקבלים נתונים מהרשת ושולחים אותם. מיד גילו שהברוקרים העוקבים לא יכולים לקבל העתקים מספיק מהר, הם העלו num.replica.fetchers ל-4 כדי להגביר את המהירות שבה ברוקרים עוקבים משכפלים הודעות ממנהיגים.

כלי ליצירת עומסים

עליך לוודא שגנרטור העומס הנבחר לא יגמר מהקיבולת לפני שאשכול קפקא (שנמצא למבחן) יגיע לעומס המרבי שלו. במילים אחרות, יש צורך לבצע הערכה ראשונית של היכולות של כלי יצירת העומס, וגם לבחור עבורו סוגי מופעים עם מספר מספיק של מעבדים וזיכרון. במקרה זה, הכלי שלנו יפיק יותר עומס ממה שאשכול קפקא יכול לעמוד בו. לאחר ניסויים רבים, הסתפקנו בשלושה עותקים c5.4x להגדיל, שלכל אחד מהם היה גנרטור פועל.

Benchmarking

מדידת ביצועים היא תהליך איטרטיבי הכולל את השלבים הבאים:

• הקמת תשתית (אשכול EKS, אשכול קפקא, כלי ליצירת עומסים וכן פרומתאוס וגרפאנה);
• יצירת עומס לתקופה מסוימת כדי לסנן סטיות אקראיות במחווני הביצועים שנאספו;
• התאמת התשתית והתצורה של הברוקר בהתבסס על מדדי ביצועים נצפים;
• חזרה על התהליך עד להשגת הרמה הנדרשת של תפוקת אשכול קפקא. יחד עם זאת, עליה להיות ניתנת לשחזור באופן עקבי ולהפגין שינויים מינימליים בתפוקה.

הסעיף הבא מתאר את השלבים שבוצעו במהלך תהליך השוואת אשכול הבדיקה.

כלי עבודה

הכלים הבאים שימשו לפריסה מהירה של תצורת בסיס, יצירת עומסים ומדידת ביצועים:

• Banzai Cloud Pipeline לארגון אשכול EKS מאמזון ג פרומתאוס (לאסוף מדדי קפקא ותשתיות) ו גרפנה (כדי לדמיין את המדדים הללו). ניצלנו מְשׁוּלָב в צינור שירותים המספקים ניטור מאוחד, איסוף יומנים מרכזי, סריקת פגיעות, התאוששות מאסון, אבטחה ברמה ארגונית ועוד ועוד.
• סנגרנל - כלי לבדיקת עומס של אשכול קפקא.
• לוחות מחוונים של Grafana להמחשת מדדי קפקא ותשתית: קוברנטס קפקא, יצואנית צומת.
• Supertubes CLI לדרך הקלה ביותר להגדיר אשכול קפקא ב-Kubernetes. Zookeeper, מפעיל Kafka, Envoy ורכיבים רבים אחרים מותקנים ומוגדרים כראוי להפעיל אשכול קפקא מוכן לייצור ב-Kubernetes.
  • להתקנה supertubes CLI השתמש בהוראות שסופקו כאן.

אשכול EKS

הכן אשכול EKS עם צמתי עובדים ייעודיים c5.4x להגדיל באזורי זמינות שונים לתרמילים עם מתווכים של קפקא, כמו גם צמתים ייעודיים למחולל העומסים ותשתית הניטור.

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

לאחר שאשכול ה-EKS פועל, הפעל את המשולב שלו שירות ניטור - היא תפרוס את פרומתאוס וגראפנה לאשכול.

רכיבי מערכת קפקא

התקן את רכיבי מערכת קפקא (Zookeeper, קפקא-מפעיל) ב-EKS באמצעות supertubes CLI:

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

אשכול קפקא

כברירת מחדל, EKS משתמש בנפחי EBS מסוג gp2, אז עליך ליצור מחלקת אחסון נפרדת המבוססת על נפחים io1 עבור אשכול קפקא:

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 בתים ומפרסם אותן לקפקא בקבוצות של 500 הודעות.
• שימוש בטיעון -required-acks=all הפרסום נחשב מוצלח כאשר כל ההעתקים המסונכרנים של ההודעה מתקבלים ומאושרים על ידי מתווכים של קפקא. המשמעות היא שבמדד המדדים מדדנו לא רק את המהירות של מנהיגים שמקבלים הודעות, אלא גם העוקבים שלהם משכפלים הודעות. מטרת בדיקה זו אינה להעריך את מהירות הקריאה של הצרכן (צרכנים) לאחרונה קיבלו הודעות שעדיין נשארו בקובץ השמור של דפי מערכת ההפעלה, והשוואתה למהירות הקריאה של הודעות המאוחסנות בדיסק.
• מחולל העומסים מפעיל 20 עובדים במקביל (-workers=20). כל עובד מכיל 5 מפיקים החולקים את הקשר של העובד לאשכול קפקא. כתוצאה מכך, לכל מחולל יש 100 מפיקים, וכולם שולחים הודעות לאשכול קפקא.

ניטור תקינות האשכול

במהלך בדיקת עומס של אשכול קפקא, ניטרנו גם על תקינותו כדי לוודא שלא היו הפעלה מחדש של הפוד, אין העתקים לא מסונכרנים ותפוקה מקסימלית עם תנודות מינימליות:

• מחולל העומס כותב סטטיסטיקות סטנדרטיות לגבי מספר ההודעות שפורסמו ושיעור השגיאות. שיעור השגיאות צריך להישאר זהה 0,00%.
• בקרת שיוט, שנפרס על ידי kafka-operator, מספק לוח מחוונים שבו נוכל גם לנטר את מצב האשכול. כדי לצפות בלוח זה בצע:

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

• רמת ISR (מספר העתקים "מסונכרנים") כיווץ והתרחבות שווים ל-0.

תוצאות מדידה

3 מתווכים, גודל הודעה - 512 בתים

עם מחיצות מפוזרות באופן שווה על פני שלושה מתווכים, הצלחנו להשיג ביצועים ~500 Mb/s (כ-990 אלף הודעות בשנייה):

צריכת הזיכרון של המכונה הוירטואלית JVM לא עלתה על 2 GB:

תפוקת הדיסק הגיעה לתפוקה המקסימלית של צומת קלט/פלט בכל שלושת המופעים שבהם הברוקרים פעלו:

מהנתונים על שימוש בזיכרון על ידי צמתים, עולה כי אחסון מערכת ואחסון במטמון לקח ~10-15 GB:

3 מתווכים, גודל הודעה - 100 בתים

ככל שגודל ההודעה פוחת, התפוקה יורדת בכ-15-20%: הזמן המושקע בעיבוד כל הודעה משפיע עליה. בנוסף, עומס המעבד כמעט הוכפל.

מכיוון שלצמתי ברוקר עדיין יש ליבות שאינן בשימוש, ניתן לשפר את הביצועים על ידי שינוי תצורת קפקא. זו משימה לא פשוטה, ולכן כדי להגדיל את התפוקה עדיף לעבוד עם מסרים גדולים יותר.

4 מתווכים, גודל הודעה - 512 בתים

אתה יכול בקלות להגדיל את הביצועים של אשכול קפקא פשוט על ידי הוספת מתווכים חדשים ושמירה על איזון מחיצות (זה מבטיח שהעומס יתחלק באופן שווה בין המתווכים). במקרה שלנו, לאחר הוספת מתווך, תפוקת האשכול גדלה ל ~580 Mb/s (~1,1 מיליון הודעות בשנייה). הצמיחה התבררה כפחותה מהצפוי: זה מוסבר בעיקר בחוסר האיזון של המחיצות (לא כל הברוקרים עובדים בשיא היכולות שלהם).

צריכת הזיכרון של מכונת ה-JVM נותרה מתחת ל-2 GB:

עבודתם של מתווכים עם כוננים הושפעה מחוסר האיזון של המחיצות:

ממצאים

ניתן להרחיב את הגישה האיטרטיבית שהוצגה לעיל כדי לכסות תרחישים מורכבים יותר הכוללים מאות צרכנים, חלוקה מחדש, עדכונים מתגלגלים, הפעלה מחדש של הפוד וכו'. כל זה מאפשר לנו להעריך את גבולות היכולות של אשכול קפקא בתנאים שונים, לזהות צווארי בקבוק בהפעלתו ולמצוא דרכים להילחם בהם.

תכננו את Supertubes כדי לפרוס קלסטר במהירות ובקלות, להגדיר אותו, להוסיף/להסיר מתווכים ונושאים, להגיב להתראות ולהבטיח שקפקא בכלל עובד כראוי ב-Kubernetes. המטרה שלנו היא לעזור לכם להתרכז במשימה העיקרית ("ליצור" ו"לצרוך" הודעות קפקא), ולהשאיר את כל העבודה הקשה לסופרטיובס ולמפעיל קפקא.

אם אתה מעוניין בטכנולוגיות Banzai Cloud ופרויקטים של קוד פתוח, הירשם לחברה בכתובת GitHub, לינקדין או טויטר.

נ.ב מהמתרגם

קרא גם בבלוג שלנו:

• «סיפור אחד עם מפעיל Redis ב-K8s ומיני סקירה של כלי עזר לניתוח נתונים ממסד נתונים זה";
• «העברה חלקה של RabbitMQ ל-Kubernetes";
• «zetcd מ-CoreOS: החלפת ZooKeeper באחסון...etcd".

מקור: www.habr.com