תמלול הפרק (לחצו לפתיחה)
קפקא פרק 2: הישויות במערכת וזרימת המידע
היי, אני אורן מהייטקיסטים בדרכים. ברוכים הבאים להרצאה השנייה על קפקא. דיברנו בהרצאה הקודמת על מה זה בדיוק קפקא, על הצורך של לינקדאין ומה הביא אותם לפתח אותה. דיברנו ב-High Level על Messaging Systems בכללי ועל Pub-Sub, הדיזיין הארכיטקטוני שעל בסיסו קפקא בנויה. אם הנושאים האלה לא יושבים לכם טוב, אני ממליץ להקשיב שוב להרצאה הקודמת ואז לחזור לכאן.
היום נדבר על הישויות העיקריות בקפקא ונכיר אותן:
1. Producer & Consumer (פרודוסר וקונסיומר)
Producer (פרודוסר): זה השם שקפקא בחרה במקום "Publisher". אלו הרכיבים שמפרסמים ושולחים הודעות לטופיקים.
Consumer (קונסיומר): השם המקביל ל-"Subscriber". אלו הרכיבים שקוראים את ההודעות.
חשוב לציין: רכיב מסוים (כמו מיקרו-סרוויס) יכול להיות גם פרודוסר עבור אינטראקציה אחת (לשלוח הודעה) ובו-זמנית להיות קונסיומר עבור אינטראקציה אחרת (לקרוא מטופיק אחר).
2. Broker & Cluster (ברוקר וקלאסטר)
Broker (ברוקר): יחידת העבודה של קפקא (במערכות אחרות זה נקרא Node). זהו קוד שרץ על שרת, יש לו גישה ל-File System והוא מנהל את הטופיקים שהוא אחראי עליהם.
Cluster (קלאסטר): קבוצה של ברוקרים. גודל הקלאסטר נקבע לפי מספר הברוקרים, לא לפי מספר המכונות הפיזיות. לדוגמה: 2 שרתים שעל כל אחד 4 ברוקרים נחשבים כקלאסטר של 8, בדיוק כמו 8 שרתים עם ברוקר אחד על כל אחד.
3. ZooKeeper (זוקיפר)
כדי שהמערכת תעמוד בעומס ותהיה בריאה, צריך רכיב שיפקח עליה (Monitoring), יחלק עומסים וידע מה מצב ה-Health בכל רגע. לרכיב הזה קוראים ZooKeeper.
למה השם הזה? ZooKeeper הוא שומר בגן חיות. לינקדאין בחרו בשם הזה כי הוא "שומר על החיות", כשהחיות הן הברוקרים שלנו.
זהו מוצר של אפאצ'י שנמצא גם במערכות כמו Redis ו-Hadoop, ויש לו השפעה עצומה על היכולת של קפקא לעבוד בקנה מידה עצום.
4. Controller (קונטרולר)
בתוך הקלאסטר יש היררכיה. הברוקר שנמצא במקום הגבוה ביותר נקרא Controller.
שלושת התפקידים העיקריים שלו:
ניהול רשימת מלאי של הברוקרים הפנויים בקלאסטר.
רישום המשימות (הוא יודע איזו משימה ניתנה לכל ברוקר).
ניהול הסטטוס והתקדמות המשימות.
5. Replication Factor (רפליקיישן פקטור)
מונח קריטי שמתייחס לכמות העותקים של טופיק מסוים. הערך הזה נקבע לכל טופיק בנפרד:
פקטור 1: המידע קיים רק פעם אחת. אם השרת ייפול – המידע אבוד.
פקטור 10: המידע קיים ב-10 ברוקרים שונים. הסיכוי לאבד מידע כזה הוא אפסי.
המלצה: לטופיק קריטי נגדיר פקטור גבוה, ולטופיק זניח (שבו אפשר להרשות לעצמנו לאבד מידע) נשאיר את הדיפולט שהוא 1.
איך הודעה מגיעה מהפרודוסר לברוקר? (The Flow)
הפרודוסר מחליט לייצר הודעה לפי הלוגיקה שלו ושולח אותה לקלאסטר.
הקונטרולר מקבל את המשימה, בוחן את הברוקרים הפנויים וממנה אחד מהם להיות ה-Leader (האחראי על המשימה).
הלידר בוחר שני ברוקרים או יותר שישמשו כ-Followers (עוקבים) ונותן להם את המשימה.
מתבצע תהליך של הסכמה ביניהם שנקרא Quorum (קוורום/מניין).
ברגע שיש הסכמה, הלידר מודיע לקונטרולר: "הצלחנו, המשימה מבוצעת".
הערה פוליטית: אם הלידר לא מצליח להגיע להסכמה עם הפולוורס (כמו שביבי לא מצליח להרכיב ממשלה), הוא חוזר לקונטרולר ואומר: "לא הצלחתי, תבחר מישהו אחר".
Gossip Protocol (פרוטוקול רכילות)
הרכיבים צריכים לתקשר ביניהם ולהתעדכן במצב המערכת. בקפקא זה נקרא "גוסיפ".
מה מעבירים ב"רכילות" הזאת?
מידע על ברוקרים שעולים או יורדים.
שינויי קונפיגורציה בזמן ריצה.
בחירת לידר למשימות.
עדכוני בריאות (Health) דרך הודעות Heartbeats ("אני חי") שנשלחות כל כמה מילי-שניות.
את כל ה"רכילות" הזאת מנהל ה-ZooKeeper (שיש לו קלאסטר משלו שנקרא Ensemble, אבל נגיע לזה בהמשך).
סיכום ההרצאה:
דיברנו היום על מה כוללת מערכת קפקא:
Producers: מייצרי ההודעות.
Consumers: קוראי ההודעות שנרשמים לטופיקים.
Kafka Cluster: קבוצת ברוקרים, בראשם הקונטרולר.
ZooKeeper: מספק את המטה-דאטה שמאפשר לברוקרים לנהל "גוסיפ" ולתפקד כמו שצריך.
תודה שהקשבתם ונתראה בהרצאה הבאה!