תכנון הגודל של אשכול שירות מנוהל ל-Apache Kafka

במאמר הזה מוסבר איך להעריך את הקיבולת שדרושה לאשכול של שירות מנוהל ל-Apache Kafka, ואיך לשנות את הגודל של אשכול קיים.

כשיוצרים אשכול של שירות מנוהל ל-Apache Kafka, בוחרים את הפרמטרים הבאים לגודל האשכול:

  • ‫vCPUs: מספר המעבדים הווירטואליים באשכול. מספר ה-vCPU המינימלי הוא 3.

  • ‫Memory: כמות הזיכרון לכל vCPU. צריך להקצות בין 1 ל-8 GiB לכל vCPU.

אפשר לעדכן את הערכים האלה אחרי שיוצרים את האשכול.

בחירת הגודל ההתחלתי של האשכול

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

  • קצב העברת נתונים לכתיבה: הקצב הכולל שבו היצרנים שולחים נתונים לאשכול, ביחידות של MBps.
  • קצב העברת נתונים לקריאה: הקצב הכולל שבו צרכנים קוראים נתונים מהאשכול, ביחידות של MBps.

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

  1. מחשבים את רוחב הפס הכולל של הכתיבה, כולל שכפול.

    Total write bandwidth = produce rate * replicas

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

  2. חישוב רוחב הפס הכולל לקריאה, כולל שכפול.

    Total read bandwidth = consume rate + produce rate * ( replicas - 1)

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

  3. חישוב קצב העברת הנתונים שווה הערך לכתיבה.

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

    Write-equivalent rate = (total write bandwidth) + (total read bandwidth / 4)

  4. קובעים את יעד ניצול ה-vCPU. הערך הזה מייצג את השימוש הממוצע ב-vCPU כאחוז מקיבולת ה-vCPU. השימוש בפועל עשוי לעלות או לרדת לאורך זמן.

    • כנקודת התחלה, מומלץ להגדיר יעד ניצול של 50%.
    • אם אתם יודעים מהם דפוסי התנועה הצפויים, הגדירו את יעד הניצול כך שיהיה שווה ליחס בין רוחב הפס הממוצע ששווה לכתיבה לבין רוחב הפס המקסימלי שצריך להקצות.

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

  5. חישוב מספר המעבדים הווירטואליים.

    vCPU count = ceiling (write-equivalent rate / 20 MBps / utilization)

    הקיבולת המשוערת של vCPU יחיד באזור יחיד היא 20 MBps. לכן, אם המעבדים הווירטואליים פעלו בשימוש של 100%, תצטרכו (write-equivalent rate / 20) מעבדים וירטואליים. כדי לקבל את המספר בפועל, מחלקים את הערך הזה בשיעור הניצול של היעד ומעגלים כלפי מעלה.

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

  6. מעריכים את הזיכרון הנדרש. מומלץ להשתמש ב-4 GB של RAM לכל vCPU.

    Memory = vCPU count * 4 GiB

כדי לקבל את התוצאות המדויקות ביותר לגבי גודל המכונה, מומלץ לבצע את הבדיקה עם עומס העבודה האמיתי שלכם. עוקבים אחרי השימוש במשאבים של האשכול ומגדילים את הקיבולת שלו אם צריך.

דוגמה לחישוב הגודל

נניח שעומס העבודה כולל קצב כתיבה של 50 MBps וקצב קריאה של 100 MBps, עם 3 רפליקות וניצול יעד של 50% של vCPU.

  1. Total write bandwidth = 50 MBps * 3 replicas = 150 MBps
  2. Total read traffic = 100 MBps + 50 MBps * (3 - 1) = 200 MBps
  3. Write-equivalent rate = 150 MBps + (200 MBps / 4) = 200 MBps
  4. Target utilization = 0.5
  5. Number of vCPUs = ceiling (200 MBps / 20 MBps / 0.5) = 20 vCPUs
  6. Memory = 20 vCPUs * 4 GiB = 80 GiB

ברוקרים

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

number of brokers = max(3, ceiling(vCPUs / 15))

לדוגמה, קלאסטר עם 75 מעבדי vCPU מתחיל עם 5 ברוקרים.

אם משנים את מספר המעבדים הווירטואליים, הם מחולקים בין הברוקרים הקיימים, עד למקסימום של 15 מעבדים וירטואליים לכל ברוקר. אם מגדילים את גודל האשכול מעבר ל-15 מעבדי vCPU לכל ברוקר, המערכת מקצה ברוקר חדש. אחרי הקצאה של ברוקר חדש, אפשר להקטין את המידה שלו ל-1 vCPU, אבל אי אפשר למחוק אותו.

מגבלות על העתקים של מחיצות

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

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

המגבלה לכל ברוקר היא 4,000 עותקים משוכפלים של מחיצות. זו לא מגבלה קשיחה. אם אתם צריכים לטפל ביותר עותקים משוכפלים מהמספר הזה, כדאי להקצות עוד ברוקרים. כדי להגדיל את מספר הברוקרים, צריך להגדיל את גודל ה-vCPU של האשכול ב-גודל הברוקר המקסימלי. אחרי שיהיו לכם מספיק ברוקרים לטיפול במחיצות, תוכלו להגדיל את הגודל של הברוקרים כדי להתאים את התפוקה.

עדכון גודל האשכול

אחרי שיוצרים אשכול של שירות מנוהל ל-Apache Kafka, אפשר לשנות את מספר ליבות ה-vCPU ואת הזיכרון בהתאם לצרכים. כשמעדכנים אשכול קיים, הכללים הבאים חלים:

  • יחס ה-vCPU לזיכרון הכולל של האשכול חייב תמיד להיות בין 1:1 ל-1:8.

  • אם מצמצמים את הקיבולת, צריך להיות לפחות vCPU אחד ו-1 GiB של זיכרון לכל ברוקר קיים. מספר הברוקרים אף פעם לא יורד.

  • אם משדרגים את הקיבולת והשינוי גורם להוספה של ברוקרים חדשים, הממוצע של vCPU וזיכרון לכל ברוקר לא יכול להיות נמוך ב-10% מהממוצעים לפני העדכון.

    לדוגמה, אם מנסים להגדיל את הקיבולת של אשכול מ-45 ליבות וירטואליות (3 ברוקרים) ל-48 ליבות וירטואליות (4 ברוקרים), הפעולה תיכשל. הסיבה לכך היא שהממוצע של vCPU לכל ברוקר יורד מ-15 ל-12, כלומר ירידה של 20%, שחורגת מהמגבלה של 10%.

אם אתם צריכים להקטין את מספר ליבות ה-CPU ביותר מ-10%, מומלץ להקטין את המספר בכמה שלבים. אחרי כל עדכון, עוקבים אחרי ניצול המשאבים ומאזנים מחדש את המחיצות אם צריך.

עם זאת, אם אתם בטוחים שלברוקרים יהיה מספיק קיבולת אחרי העדכון, אתם יכולים להשבית את הבדיקה הזו. כדי להשבית את הבדיקה, מגדירים את הדגל allow_broker_downscale_on_cluster_upscale לערך true בפקודה gcloud managed-kafka clusters update. הסימן הזה מציין שאתם מוכנים לקחת את הסיכון הפוטנציאלי לפגיעה בביצועים.

כדי לעדכן אשכול, אפשר לעיין במאמר בנושא עדכון אשכול של שירות מנוהל ל-Apache Kafka.

דוגמאות לפעולות עדכון

בדוגמאות הבאות מתחילים עם אשכול שכולל 75 vCPU,‏ 130 GiB RAM ו-5 brokers.

דוגמה לפעולת הגדלה שנכשלה

מגדילים את הקיבולת של האשכול ל-80 vCPUs ול-140 GiB RAM.

  • השירות קובע אם נדרש מתווך חדש.

    • ‫ceiling (80 vCPUs / 15) = 6 brokers

    האשכול יגדל מ-5 ל-6 ברוקרים, ולכן מופעלת בדיקת הבטיחות של 10%.

  • הערכים הממוצעים הנוכחיים לכל ברוקר הם:

    • ‫75 vCPUs / 5 brokers = 15 vCPUs per broker

    • ‫‎130 GiB / 5 brokers = 26 GiB per broker

  • עם 6 ברוקרים, הממוצעים החדשים הם:

    • ‫80 vCPUs / 6 brokers = 13.33 vCPUs per broker, an 11.1% reduction

    • ‫‎140 GiB / 6 brokers = 23.33 GiB per broker, a 10.2% reduction

    הפעולה נכשלת כי הממוצעים האלה גבוהים מ-10%.

דוגמה לפעולת הגדלה מוצלחת

הגדלת הקיבולת של האשכול ל-85 vCPUs ול-150 GiB RAM.

  • השירות קובע אם נדרש מתווך חדש.

    • ‫ceiling (85 vCPUs / 15) = 6 brokers

    האשכול יגדל מ-5 ל-6 ברוקרים, ולכן מופעלת בדיקת הבטיחות של 10%.

  • הערכים הממוצעים הנוכחיים לכל ברוקר הם:

    • ‫75 vCPUs / 5 brokers = 15 vCPUs per broker

    • ‫‎130 GiB / 5 brokers = 26 GiB per broker

  • עם 6 ברוקרים, הממוצעים החדשים הם:

    • ‫85 vCPUs / 6 brokers = 14.17 vCPUs per broker, a 5.5% reduction

    • ‫150 GiB / 6 ברוקרים = 25 GiB לכל ברוקר, הפחתה של 3.8%

הפעולה הזו הצליחה כי ההפחתה הממוצעת ב-vCPU ובזיכרון לכל ברוקר היא במסגרת המגבלה של 10%.

המאמרים הבאים