שיטות עבודה מומלצות להגדלת עומסי עבודה מבוססי קפקא

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

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

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

הבדלים עיקריים ממערכות תור אחרות

להלן ההבדלים של אפאצ'י קפקא ממערכות כמו ActiveMQ, ZeroMQ ו-VerneMQ:

אחסון מתמיד

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

חלוקה

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

קבוצות צרכנים

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

• פעילות משתמשים הנצרכת על ידי צוותי ML כדי לגלות פעילות חשודה
• צוות ההמלצות לבניית המלצות
• צוות הפרסומות ליצירת מודעות רלוונטיות

שיטות מומלצות ליוצר ה-Kafka

גודל הצטברות וזמן השהייה

על ידי קביעת batch.size ו־linger.ms, ניתן להגביר את כמות המידע שיועבר על ידי יוצר ה־Kafka. batch.size הוא הגודל המרבי של הצטברות המידע בבתי נתונים. ה־Kafka ינסה לצבור את המידע לפני שהוא שולח אותו ליוצרים.

linger.ms קובע את הזמן המרבי במילישניות שהיוצר ימתין להוספת הודעות נוספות לבתי הנתונים לצורך עיבוד.

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

דחיסה

דרך נוספת להגברת כוח המעבר היא לאפשר דחיסה דרך התצורה compression.type. היוצר יכול לדחוס נתונים באמצעות gzip, snappy, או lz4 לפני שליחתם לשרתים. לנתונים הגדולים, תצורה זו עוזרת בהפחתת עלות הדחיסה עם יעילות הרשת. זה גם חוסך רוחב פס ומגביר את כוח המעבר של המערכת. בנוסף, על ידי הגדרת הסריאלייזר המתאים וסריאלייזר המפתח, ניתן לוודא כי הנתונים מוסרים בפורמט שתואם לצרכנים שלך.

ניסיונות מחדש ואי-ידמות

כדי להבטיח את אמינות מייצר ה-Kafka, עליך להפעיל ניסיונות מחדש ואי-ידמות. על ידי תצורת retries, היוצר יכול לשלוח מחדש באופן אוטומטי כל קבוצת נתונים שלא קיבלה ack מהשרת בתוך מספר נסיונות מסוים.

אישורים

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

• 0 – המהיר ביותר, אך לא קיימת הבטחת משלוח ההודעה.
• 1 – ההודעה מאושרת לאחר שהיא נכתבת לשרת הראשי, מספק אמינות בסיסית.
• מלאה – ההודעה נחשבת להגיעה רק כאשר כל השעות מזוהות אותה, מבטיח עמידות גבוהה.

התאמת תצורה בהתאם לעומס העבודה

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

המלצות טובות לצרכני קפקא

קבוצות צרכנים

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

אישור אוף-סט

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

• אוטו.אופסט.איפוס – מגדיר מה לעשות כאשר צרכן מתחיל לצרוך נושא ללא היסטוריית אופסטים מחוייבת (למשל, נושא חדש או צרכן שנכנס לקבוצה לראשונה). האפשרויות כוללות earliest (קריאה מההתחלה), latest (קריאה מהסוף) או none (לזרוק שגיאה). בחר "earliest" לרוב המקרים כדי למנוע איבוד נתונים כאשר צרכן חדש נכנס לקבוצה.מבקר כיצד צרכן מתחיל לצרוך נתונים, מבטיח התנהגות תקנית כאשר צרכן מתאחד שוב או מתווסף לקבוצה.
• enable.auto.commit – מסייע להגדיר לקבוע אוטומטית אופסטים באופן תדיר. מספק שליטה לניהול אישורי אופסט, מאפשר שליטה יותר על עיבוד הנתונים.
• auto.commit.interval.ms – מרוייה במילישניות שבה האופסטים מתאפסים באופן אוטומטי אם enable.auto.commit מוגדר ל- true. שנה על פי זמן העיבוד של היישום שלך כדי למנוע אובדן מידע עקב כשל בלתי צפוי.

גודל השליפה ומספר הרשומות המרבי לפני שליפה

הגדרה זו עוזרת לשלוט במספר הרשומות שמשובצות בכל בקשה, ניתן להגדיר את fetch.min.bytes ואת max.poll.records. הגדלת הערך הזה עשויה לסייע לשיפור תפוקת היישומים שלך תוך כדי צריכת מעבד נמוכה והפחתת מספר השיחות הנעשות אל הברוקרים.

• fetch.min.bytes – המספר המינימלי של בתים לשליפה מהברוקר בבקשה יחידה. הגדר ערך קטן כדי למנוע שיחות לרשת בלתי נחוצות, אך לא מדי קטן כדי למנוע שיחות רבות ביותר. הערך עוזר לאופטימיזציה של אפקטיביות הרשת על ידי מניעת בקשות קטנות, תדירות.
• fetch.max.bytes – המקסימום מספר הבתים למשיכה מטורף בבקשת סקירה יחידה. התאם בהתאם לזיכרון הזמין כדי למנוע עומס יתר על העובדים הצרכניים. זה יפחית את כמות הנתונים שמשגירים בסקירה יחידה, וימנע בעיות זיכרון.
• max.poll.interval.ms – הזמן המרבי להמתין לבקשת סקירה להחזיר נתונים לפני שהזמן יגמר. קבע זמן קצבי כדי למנוע תקיפות/עכבות של הצרכנים אם אין נתונים זמינים. זה יסייע למנוע מצבים בהם הצרכנים תקועים ממתינים להודעות לאורך זמן רב מדי. (לפעמים, גלילי k8s עשויים לאתחל אם הבדיקות של החיוניות נפגעות).

הקצאת חלוקה

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

כאן כמה שיקולים חשובים לפני שמשתמשים ב־Kafka:

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

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