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

היי הבר!

אנו מזכירים לך כי בעקבות הספר על קפקא פרסמנו עבודה מעניינת לא פחות על הספרייה API של Kafka Streams.

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

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

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

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

למה חשבנו שהגיע הזמן לשנות את הדרך שבה אנחנו עובדים עם מצב משותף

היינו צריכים לשמור על מצבם של אובייקטים שונים בהתבסס על דיווחי סוכן (לדוגמה: האם האתר היה מותקף)? לפני המעבר ל-Kafka Streams, לעתים קרובות הסתמכנו על מסד נתונים מרכזי אחד (+ שירות API) לניהול המדינה. לגישה זו יש חסרונות: מצבים אינטנסיביים לדייט שמירה על עקביות וסנכרון הופכת לאתגר אמיתי. מסד הנתונים עשוי להפוך לצוואר בקבוק או להגיע אליו מצב Race וסובלים מאי-חיזוי.

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

הכירו את Kafka Streams, מה שמקל על יצירת מיקרו-שירותי מדינה משותפים

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

כל אחד משירותי המיקרו הממלכתיים שיצרנו נבנה על גבי מופע של Kafka Streams עם טופולוגיה פשוטה למדי. הוא כלל 1) מקור 2) מעבד עם מאגר מפתח-ערך מתמשך 3) כיור:

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

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

איור 3: זרימת משימות חדשה לדוגמה עבור תרחיש עם שירותי מיקרו משותפים: 1) הסוכן יוצר הודעה שמגיעה לנושא המקור של קפקא; 2) שירות מיקרו עם מצב משותף (באמצעות Kafka Streams) מעבד אותו וכותב את המצב המחושב לנושא קפקא הסופי; לאחר מכן 3) הצרכנים מקבלים את המצב החדש

היי, החנות המובנית הזו עם ערך מפתח היא למעשה שימושית מאוד!

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

אפשרות מס' 1: השתמש במאגר מפתח-ערך לחישובים

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

איור 4: אנו פותחים גישה למאגר מפתח-ערך עבור שיטת העיבוד של המעבד (לאחר מכן, כל סקריפט שעובד עם מצב משותף חייב ליישם את השיטה doProcess)

אפשרות מס' 2: יצירת API של CRUD על גבי Kafka Streams

לאחר שיצרנו את זרימת המשימות הבסיסית שלנו, התחלנו לנסות לכתוב RESTful CRUD API עבור שירותי המיקרו-מצב המשותפים שלנו. רצינו להיות מסוגלים לאחזר את המצב של חלק מהאובייקטים או כולם, כמו גם להגדיר או להסיר את המצב של אובייקט (שימושי לתמיכה בקצה האחורי).

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

איור 5: שימוש במאגר המפתח-ערך המובנה כדי לקבל את המצב המחושב מראש של אובייקט

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

איור 6: אתה יכול להגדיר את המצב של אובייקט באמצעות מפיק קפקא

סיבוך קטן: לקפקא יש מחיצות רבות

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

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

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

איור 7: באמצעות מטא-נתונים של זרם, אנו קובעים מאיזה מופע לבצע שאילתה על מצב האובייקט הרצוי; נעשה שימוש בגישה דומה עם ה-API של GET ALL

ממצאים עיקריים

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

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

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

מקור: www.habr.com