המידע הוא ליבת הפעילות של אלפי שירותים בלינקדאין.
שירותים אלו לעיתים קרובות מבקשים להירשם כמנויים לנתונים ששירותים אחרים מפרסמים, כך שיוכלו לעבד את כלל המידע – ולא רק את העדכונים האחרונים. אך מאחר שתקלות הן בלתי נמנעות, חשוב לאפשר לשירותים אלו גם לבצע עיבוד מחדש (reprocessing), לתקן באגים ולוודא שהמערכת פועלת כראוי.
כדי לענות על הצורך הזה, פיתחנו לפני כ-15 שנה את Kafka – תשתית מרכזית להפצת נתונים בסביבת Pub/Sub. Kafka הפך לעמוד התווך של תשתית המידע שלנו, ומאז תומך באירועי משתמש, לוגים, ניטור, מעקב, תקשורת בין אפליקציות, עיבוד בזמן כמעט-אמת, יבוא/יצוא ל־Data Lake, יישומי AI ואפילו שכפול של בסיסי נתונים.
עם הזמן, ככל שלינקדאין התפתחה והשתמשה במערכות בקנה מידה גדול יותר, Kafka הפך למורכב יותר להפעלה ולתחזוקה. לכן עברנו לשלב הבא: Northguard – מערכת אחסון לוגים חדשה, שמעניקה יכולות סקיילביליות ואופרביליות גבוהות יותר.
למה נדרש פתרון חדש
בשנת 2010, ללינקדאין היו כ-90 מיליון משתמשים. כיום, אנחנו משרתים מעל 1.2 מיליארד. הצמיחה המהירה הזו יצרה אתגרים משמעותיים:
-
סקיילביליות – העלייה במספר המשתמשים והשירותים גררה עומסים כבדים, עלייה בכמות המטאדאטה, ומספר עצום של מכונות שנדרשו לניהול.
-
אופרביליות – התפעול הפך מורכב יותר עם למעלה מ־100 קלאסטרים ונדרשה מערכת שלמה לניהול האשכולות.
-
זמינות – התלות ב־partitions כאבן בניין מרכזית הגבילה את היכולת לשכפל מידע בצורה גמישה.
-
עקביות – במקרים רבים נאלצנו לוותר על עקביות כדי לשפר זמינות.
-
עמידות – הבטחות העמידות שסיפק Kafka לא הספיקו עבור אפליקציות קריטיות.
לכן היינו זקוקים למערכת שמתמודדת עם כל אלו, תומכת בהפעלה אוטומטית ככל האפשר, מספקת זמני תגובה קצרים, אמינות גבוהה, עלות נמוכה, גמישות חומרתית, יכולת בדיקה, עקביות חזקה וממשק פשוט למפתחים.
Northguard – סקיילביליות מהיסוד
Northguard היא מערכת אחסון לוגים שתוכננה מראש לגדול ביעילות ולהיות קלה לתפעול. היא מפזרת את המידע והמטאדאטה באופן מבוזר, תוך שמירה על מינימום מצב גלובלי.
המערכת מורכבת מקלאסטר של "ברוקרים", שכל אחד מהם מתקשר עם לקוחות (producers/consumers) וגם עם שאר הברוקרים בקלאסטר.
מודל הנתונים
-
רשומות (Records): היחידה הבסיסית של מידע – מפתח, ערך ו-Headers.
-
מקטעים (Segments): רצף של רשומות. כל מקטע יכול להיות פעיל (נכתבים אליו נתונים) או סגור (בלתי ניתן לשינוי).
-
טווחים (Ranges): רצף מקטעים המהווים יחד לוג אחד על תחום מפתחות מוגדר.
-
נושאים (Topics): קבוצת טווחים שמכסים את כלל המפתחות. טווחים יכולים להתפצל ולהתמזג בהתאם לצורך.
מדיניות אחסון וגמישות
כל Topic מנוהל בהתאם למדיניות אחסון מוגדרת הכוללת:
-
תקופת שימור.
-
אילוצים שמכתיבים היכן יישמרו העתקים (replicas) של המידע.
האילוצים מבוססים על "תכונות" (attributes) שהוגדרו על הברוקרים, המייצגות פרטים כמו rack, data center ועוד. כך ניתן לנהל שיבוץ מודע-מיקום בצורה גמישה, מבלי לקודד את המידע במערכת עצמה.
Log Striping – איזון עומסים מובנה
Northguard מתמודדת עם בעיית חוסר איזון המשאבים ע"י "רצועות לוגים" – שבירת הלוגים ליחידות קטנות יותר, מה שמאפשר פיזור עומסים טבעי על פני הקלאסטר.
במערכות ישנות, כמו Kafka, כל לוג מועתק בשלמותו, מה שמייצר עומס בלתי אחיד. ב-Northguard, כל מקטע חדש משובץ בצורה אורגנית לברוקר אחר. כאשר ברוקר חדש מתווסף – הוא מתחיל לקבל מקטעים חדשים ללא צורך בהעברת נתונים ישנים.
Xinfra – שכבת Pub/Sub וירטואלית
על גבי Northguard נבנתה Xinfra – שכבת Pub/Sub המאפשרת תמיכה בשירותים שדורשים ממשק דמוי Kafka, תוך שמירה על היכולות החדשות של Northguard.
סיכום
Northguard מסמנת את הדור הבא של תשתיות המידע בלינקדאין – תשתית שמסוגלת להתמודד עם קצבים של עשרות טריליוני רשומות ביום, בעשרות פטה-בייטים, על פני מאות אלפי נושאים. בזכות אדריכלות מודרנית, מבוזרת ואינטליגנטית, אנחנו ממשיכים לאפשר לכל השירותים בלינקדאין לצמוח, להתפתח ולחדש – מבלי להתפשר על אמינות, ביצועים או גמישות.
המקור: חברת Linkedin בכתובת הבאה.