תמלול הפרק (לחצו לפתיחה)
קפקא פרק 1: מבוא ועולם ה-Messaging
אהלן, ברוכים הבאים ל"הייטקיסטים בדרכים", אני אורן. הכנתי לכם סדרת הרצאות על הנושא החם שכולם מדברים עליו היום: Apache Kafka (אפאצ'י קפקא).
הסיכום הזה מיועד לכל מי שנוסע יום-יום בדרכים לעבודה ואומר לעצמו: "מתישהו אני אמצא זמן לשבת על טוטוריאל כדי להעמיק את הידע... אולי בערב כשהילדים יירדמו, אולי בסופ"ש". בינינו? זה פשוט לא קורה. לכן השתדלתי להנגיש את המידע שיהיה כמה שיותר נוח, אבל גם מעמיק ואיכותי.
מה זה בכלל קפקא?
קפקא מוגדרת כ-Messaging System – מערכת המאפשרת להעביר הודעות בין רכיבים שונים במערכת. היא מבוססת על עיקרון ארכיטקטוני שנקרא Pub-Sub (פאב-סאב). כדי להבין את קפקא, בואו נישר קו על המושג הזה.
Pub-Sub הוא קיצור של Publisher-Subscriber. לפי העיקרון הזה, רכיבים במערכת לא מתקשרים ישירות אחד עם השני, אלא משאירים הודעות ב"תיבות דואר" שנקראות Topics (טופיקים).
דוגמה להמחשה: דמיינו מערכת לייצור רכבים. הרכיב שמייצר את הרכבים הוא ה-Publisher. בכל פעם שהוא מסיים להכין רכב, הוא מפרסם הודעה בטופיק שנקרא "רכבים מוכנים".
כעת, כל רכיב שמתעניין ברכבים מוכנים (למשל, הרכיב שצובע את הרכבים) נרשם כ-Subscriber לטופיק הזה. הוא קורא את ההודעה ומבין שיש רכב חדש לצבוע.
בצורה הזאת, אין שום תקשורת ישירה בין היצרן לצבע – הם מנותקים זה מזה.
יתרונות וחסרונות של שיטת ה-Messaging
היתרון המרכזי: Decoupling (ניתוק תלות)
יש ניתוק מוחלט בין השולח למקבל. הם לא מכירים אחד את השני ולא צריכים לסכם ביניהם כלום. זה מאפשר לנו לשנות רכיב אחד במערכת בלי להשפיע על האחרים, כל עוד מבנה ההודעה בטופיק נשמר.
החיסרון המרכזי: ACK (Acknowledgment)
הקושי הוא ביכולת של השולח לדעת שההודעה באמת הגיעה ליעדה ונקראה. במודל של Client-Server יש קשר ישיר וקל לקבל אישור, אבל כשמשאירים הודעה בטופיק, זה מאתגר יותר לוודא שהיא הגיעה וטופלה.
חמישה אתגרים במערכות Messaging
כשאנחנו בונים מערכת כזו, אנחנו נתקלים בחמישה אתגרים מרכזיים:
Scale (סקייל): עמידה בעומס. ה"ברוקר" (השרת שמנהל את ההודעות) עלול להפוך לצוואר בקבוק.
גודל ההודעות: מכיוון שאין לנו תמיד שליטה על הפבלישרים, אנחנו צריכים לדעת לתכנן את המערכת כך שתתמודד עם הודעות של כמה קילובייטים בודדים ועד עשרות מגהבייטים.
Lazy Consumer (קונסיומר עצלן): הקונסיומרים חייבים לעמוד בקצב של הפבלישרים. אם נשלחות 1,000 הודעות ביום והקונסיומר קורא רק אחת, הטופיק יתמלא והמערכת עלולה לקרוס.
Fault Tolerance (עמידות לשגיאות): מה קורה אם הודעה הלכה לאיבוד בדרך או הפכה ל-Corrupted? האם המערכת יודעת להתמודד עם זה?
Throttling (ויסות): היכולת למנוע מפבלישר "להפציץ" את המערכת בכמות לא הגיונית של הודעות (למשל בגלל באג או ריסטארט שגורם לו לשלוח את כל הודעות היום בבת אחת).
הולדת קפקא בלינקדאין (LinkedIn)
בשנת 2010, המפתחים בלינקדאין חיפשו פתרון לכל האתגרים האלה. היו להם 1.4 טריליון הודעות ביום (!) וצורך לחבר המון סוגי דאטה-בייסים. שום פתרון קיים לא "החזיק מים".
למה קראו לזה קפקא?
השם נלקח מהסופר פרנץ קפקא. המילה "קפקאי" מתארת מצב סוריאליסטי, הזוי ובלתי הגיוני. לינקדאין בחרה בשם הזה כי היא מצאה פתרון למצב שהיה נראה להם סוריאליסטי ובלתי פתיר.
חמש הדרישות של לינקדאין מהפתרון החדש:
- טיפול בכמויות עצומות של מידע.
- Horizontal Scale-out: יכולת להוסיף עוד שרתים בקלות (במקום רק להגדיל שרת קיים) בצורה מובנית בתוך המערכת.
- אמינות ו-Fault Tolerance: מידע שנשלח חייב להגיע לקונסיומר ולא ללכת לאיבוד.
- ניתוק תלות מוחלט: הפבלישר והסבסקרייבר לא חייבים לדבר באותה שפה או להיות באותה רשת.
- ארכיטקטורת Pub-Sub מלאה על כל המשתמע מכך.
בסופו של דבר, לינקדאין פיתחה את קפקא שעומדת בכל הדרישות האלו. בהרצאה הבאה אנחנו נתחיל לצלול פנימה לתוך הארכיטקטורה.
תודה שהקשבתם ונתראה בהרצאה הבאה!