תכנון הגודל של אשכול שירות מנוהל ל-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 ברוקרים.

אם משנים את מספר ה-vCPU, הם מחולקים בין הברוקרים הקיימים, עד למקסימום של 15 vCPU לכל ברוקר. אם מגדילים את גודל האשכול מעבר ל-15 מעבדי vCPU לכל ברוקר, המערכת מקצה ברוקר חדש. אחרי הקצאה של ברוקר חדש, אפשר להקטין את המידה שלו ל-1 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 vCPU / 5 ברוקרים = 15 vCPU לכל ברוקר

    • ‫‎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 vCPU / 5 ברוקרים = 15 vCPU לכל ברוקר

    • ‫‎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 brokers = 25 GiB per broker, a 3.8% reduction

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

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