הגדרת Apache Kafka (KRaft, Schema Registry, TLS) עבור DevOps

הגדרת Apache Kafka: היכן הקלאסטר מאבד נתונים

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

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

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

קטגוריה נפרדת — קיבולת. זיכרון למטמון העמודים, גודל הסגמנט, משך הנשמרות ונפח האחסון קשורים זה לזה: במגבלות שגויות הצומת עובר למצב קריאה בלבד או מוחק סגמנטים לפני שקבוצות מפגרות קראו אותם. האפליקציה לא מקבלת שגיאה — היא просто סופרת פחות אירועים כעבור יממה.

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

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

ביצועים ועמידות בתקלות בעומסי שיא

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

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

עבור טופיקים קריטיים acks=all ו-min.insync.replicas לא מאפשרים לאשר כתיבה לפני שכמה עותקים קיבלו אותה — שיעור ההודעות שאבדו יורד לאפס גם במקרה של כשל ברוקר ברגע הכתיבה.

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

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

מצבי עבודה: צומת אחד, קלאסטר עצמאי, שירות מנוהל

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

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

את הטופולוגיה מקבעים לפני הגדרת TLS ו-Schema Registry: ממנה תלויים שמות המאזינים, סכמת הכתובות של הלקוחות וסדר החלפת התעודות. מעבר מצומת אחד לקלאסטר נעשה באמצעות יצירה מחדש של טופיקים עם גורם השכפול הנדרש והעברת קונסיומרים עם קיבוע אופסטים — בלי לאבד את הזרימה.

איך מתבצעת ההטמעה: מביקורת ועד מסירה לתפעול

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

1. ביקורת קלאסטר. מתעדים את המצב בפועל: מספר צמתים, פריסת מחיצות, גורם שכפול, עותקים מפגרים, משכי נשמרות והרשאות נוכחיות. בפלט — מפת צווארי בקבוק ורשימת פרמטרים לשינוי.
2. סכמת מחיצות וטופיקים. מתכננים מודל לפרופיל הזרימות: מפתח חלוקה, מרווח מחיצות לצמיחה, טופיקים נפרדים לנתונים עם דרישות שונות לסדר ולאובדן מותר.
3. הגדרת צמתים וגישה. מקימים קונטור: הצפנת תעבורה, אימות, הרשאות ברמת טופיקים וקבוצות צרכנים, מכסות, מגבלות על גודל הודעה. מצב העבודה נבחר כך שיסיר שכבת תיאום מיותרת.
4. רישום סכמות ותאימות. מקבעים חוזי פורמטים וכלל תאימות, כדי שגרסה חדשה של מפיק לא תשבור צרכנים שכבר עובדים. אי-התאמה נחסמת בכניסה, לא באנליטיקה.
5. בדיקה תחת עומס. מריצים פרופיל קרוב לפרודקשן: זרימת שיא, השהיות, נפילת צומת, התאוששות עותקים. הספים שבהם הקלאסטר תקין מוטמעים בניטור ובהתראות.
6. מסירה לתפעול. מוסרים נהלים, לוחות זמנים וכללי תגובה, מלמדים את צוות התורנות, ועוברים יחד על מיתוג תרגולי. התמיכה ממשיכה לפי נהלים מתועדים.

תצורות, סכמות ונהלים שנשארים אצלך

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

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

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

מקרה בוחן: כשלים פעם ביום במקום זרימה יציבה

קונטור התחלתי

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

מה שינו

את המטא-נתונים העברנו לקונצנזוס המובנה KRaft — מתאם נפרד הוסר יחד עם עוד נקודת כשל. עבור הטופיקים קבענו גורם שכפול 3 וקוורום של 2 עותקים סינכרוניים: כתיבה נחשבת מאושרת רק כששני עותקים לפחות קיבלו אותה.

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

מדדים לפני ואחרי

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

מה לעשות אם קלאסטר Kafka כבר פרוס

קלאסטר Apache Kafka פעיל כמעט אף פעם לא צריך להרכיב מחדש — ברוב המקרים די בבדיקה ובתוכנית מדורגת. תחילה מתעדים את המצב: מספר הברוקרים, גורם השכפול של הטופיקים, הערך של min.insync.replicas, האופסטים המצטברים של קבוצות הצרכנים ושעות השיא של הכתיבה. המספרים האלה קובעים מה אפשר לשנות במערכת חיה ומה דורש חלון נפרד.

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

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

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

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

שאלות טכניות נפוצות בנושא תפעול קלאסטר

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

איך להגביל גישה לקלאסטר עבור לקוחות חיצוניים?

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

מה קורה בנפילת צומת?

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

איך מתבצע עדכון מתוכנן ותמיכה בקלאסטר?

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

נדון במשימה: נחזור עם הערכה ותוכנית עבודה

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

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

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