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

  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 GiB של 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

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

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

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

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

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

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

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

כשמעדכנים אשכול קיים, הכללים הבאים חלים:

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

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

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

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

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

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

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

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

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

מגדילים את הרזולוציה של האשכול ל-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 ברוקרים = 23.33 GiB לכל ברוקר, הפחתה של 10.2%

    הפעולה נכשלת כי הממוצעים האלה גבוהים מ-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%.

הערכת גודל הדיסק הנדרש

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

כשברוקר מקבל הודעה, הוא כותב את ההודעה לקובץ מקומי של פלח. כשקובץ הפלח מגיע לגודל או לגיל מקסימליים, הוא נסגר (או "מתגלגל") ומועבר לאחסון מרוחק. הגודל המקסימלי של קובץ פלח מוגדר בהגדרה log.roll.bytes, והגיל המקסימלי מוגדר בהגדרה log.segment.ms.

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

כברירת מחדל, הגודל המקסימלי של קובץ פלח הוא 230 MiB. במקרה של אשכולות עם ניצול בינוני, אפשר להניח שצריך 250 MiB לכל מחיצה, כדי לספק מרחב אחסון נוסף בזמן העברת פלח מגולגל. בהתבסס על ההנחה הזו, גודל הדיסק המינימלי לכל ברוקר הוא:

250 MiB * partition count * replication factor / broker count

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

חשוב מאוד לשמור על קיבולת דיסק לא מנוצלת בכל ברוקר. ההתנהגות של ברוקר ללא קיבולת דיסק לא ניתנת לחיזוי, ויכולה לגרום לאובדן נתונים וגם לחוסר יציבות של האשכול. ניטור השימוש בדיסק (disk/used_bytes ) כנגד גודל הדיסק הכולל הזמין (disk/limit אם ניצול הדיסק עולה על 80% מגודל הדיסק הכולל הזמין, הגדר גודל דיסק גדול יותר. מידע נוסף זמין במאמר בנושא מעקב אחרי קיבולת האשכול.

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