העברה מ-Kafka ל-Pub/Sub

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

סקירה כללית של Pub/Sub

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

‫Pub/Sub פועל בכל Google Cloud האזורים. שירות Pub/Sub מפנה את התנועה של בעלי התוכן הדיגיטלי אל מרכז הנתונים הקרוב ביותר Google Cloud שבו מותר לאחסן נתונים, כפי שמוגדר במדיניות בנושא הגבלת מיקום המשאבים.

אפשר לשלב את Pub/Sub עם הרבה Google Cloud שירותים, כמו Dataflow,‏ Cloud Storage ו-Cloud Run. אפשר להגדיר את השירותים האלה כמקורות נתונים שיכולים לפרסם הודעות ב-Pub/Sub, או כיעדים לנתונים שיכולים לקבל הודעות מ-Pub/Sub.

סקירה כללית על Kafka

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

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

הסבר על ההבדלים בין Kafka לבין Pub/Sub

הדיאגרמה הבאה מציגה את ההבדלים באסטרטגיית ההרחבה בין Kafka לבין Pub/Sub:

אסטרטגיית שינוי גודל עם מחיצות ל-Kafka וללא מחיצות ל-Pub/Sub.

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

השוואת תכונות

בטבלה הבאה מוצגת השוואה בין התכונות של Apache Kafka לבין התכונות של Pub/Sub:

‫Apache Kafka Pub/Sub
סדר ההודעות כן, בתוך מחיצות כן בנושאים
ביטול כפילויות בהודעות כן כן באמצעות Dataflow
הרשמות ל-Push לא כן
תור הודעות ללא מוצא
(תור הודעות שלא ניתן לעבד)		 החל מגרסה 2.0 כן
טרנזקציות כן לא
אחסון הודעות ההגבלה היחידה היא נפח האחסון הזמין במחשב 31 ימים.
נושא יכול לשמור הודעות שפורסמו, כולל הודעות שאושרה קבלתן, למשך 31 ימים לכל היותר. אפשר להגדיר את זה באמצעות המאפיין `message_retention_duration` של הנושא.
הפעלה חוזרת של הודעות כן כן
רשות מוניציפאלית אפשר לשכפל אשכול מקומי באמצעות MirrorMaker שירות גלובלי מבוזר עם מיקומי אחסון הודעות שניתנים להגדרה
רישום ביומן ומעקב נהלו את הכל בעצמכם אוטומטי באמצעות Cloud Logging ו-Cloud Monitoring
עיבוד זרמי נתונים (stream processing) כן, עם KSQL כן, באמצעות Dataflow

הסבר על אחסון והפעלה מחדש של הודעות Pub/Sub

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

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

מנגנון מובנה למניעת כשלים עם נושאים להודעות ללא מוצא

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

ביטול כפילויות של הודעות ב-Pub/Sub באמצעות Dataflow

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

סדר ההודעות ב-Pub/Sub

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

הסבר על האחריות בניהול עצמי לעומת שירות מנוהל

בטבלה הבאה מוצגת השוואה בין התכונות שמארחות את עצמן באמצעות Kafka לבין התכונות שמנוהלות על ידי Google באמצעות Pub/Sub:

Apache Kafka Pub/Sub
זמינות פריסה ידנית של Kafka במיקומים נוספים פריסה בכל Google Cloud האזורים כדי להבטיח זמינות גבוהה וזמן אחזור נמוך
תוכנית התאוששות מאסון (DR) עיצוב ותחזוקה של גיבוי ושכפול משלכם מנוהל על ידי Google
ניהול התשתיות פריסה והפעלה ידניות של מכונות וירטואליות (VM) או מכונות. חובה לשמור על עקביות בניהול הגרסאות ובתיקוני האבטחה. מנוהל על ידי Google
תכנון קיבולת תכנון ידני מראש של צורכי האחסון והמחשוב מנוהל על ידי Google
תמיכה ללא צוות תמיכה זמין מסביב לשעון

מגבלות הגודל של הודעות Pub/Sub ופתרונות עקיפים

גם Kafka וגם Pub/Sub מפגינים ביצועים טובים כשמטפלים בכמויות גדולות של הודעות קטנות. ב-Kafka אין מגבלה קשיחה על גודל ההודעה, ואפשר להגדיר את הגודל המותר של ההודעה. לעומת זאת, ב-Pub/Sub יש מגבלה של 10MB על גודל ההודעה. אפשר לשלוח מטען ייעודי (payload) גדול יותר באופן עקיף, על ידי אחסון האובייקט קודם ב-Cloud Storage, כמו שמוצג בתרשים הבא:

המוציא לאור מאחסן אובייקט ב-Cloud Storage.

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

השוואת עלויות בין Kafka ל-Pub/Sub

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

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

תכנון ארכיטקטורה לאמינות

‫Pub/Sub הוא שירות גלובלי מנוהל שפועל בכל Google Cloud האזורים. נושאים ב-Pub/Sub הם גלובליים, כלומר הם גלויים ונגישים מכל Google Cloud מיקום. עם זאת, כל הודעה מאוחסנת באזור אחד Google Cloud , הקרוב ביותר לבעל האתר ומותר על פי מדיניות מיקום המשאבים. לכן, יכול להיות שיהיו הודעות בנושא מסוים שייאוחסנו באזורים שונים ב- Google Cloud. ‫Pub/Sub עמיד להפסקות זמניות באזורים. במהלך הפסקת שירות אזורית, יכול להיות שלא תהיה גישה להודעות שמאוחסנות באזור מסוים עד שהשירות ישוחזר. בהתאם לדרישות הזמינות שלכם, אתם יכולים להשתמש בנקודות קצה (endpoints) של שירותים לפי מיקום כדי להטמיע מדיניות מעבר לגיבוי במקרה של הפסקת חשמל אזורית.

אבטחה ואימות

‫Apache Kafka תומך בכמה מנגנוני אימות, כולל אימות שמבוסס על אישורי לקוח, Kerberos, ‏ LDAP ושם משתמש וסיסמה. לצורך הרשאה, Kafka תומך בשימוש ברשימות של בקרת גישה (ACL) כדי לקבוע לאילו נושאים יש גישה לאפליקציות לקוח יוצרות ולאפליקציות לקוח צרכניות.

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

תכנון ההעברה ל-Pub/Sub

כל העברה ל- Google Cloud מתחילה בהערכת עומסי העבודה ובבניית הבסיס.

העברה בשלבים באמצעות Pub/Sub Kafka Connector

מחבר Pub/Sub Kafka מאפשר להעביר את התשתית של Kafka ל-Pub/Sub בשלבים.

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

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

שלב ראשון בהעברה.

בתרשים שלמעלה, המנויים הנוכחיים ממשיכים לקבל הודעות מ-Kafka, ואתם מעדכנים את המנויים אחד אחד כדי לקבל הודעות מ-Pub/Sub במקום זאת.

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

בתרשים הבא מוצגת ההגדרה אחרי שכל המנויים מקבלים הודעות מ-Pub/Sub:

השלב השני של ההעברה.

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

מעקב אחרי Pub/Sub

במהלך ההעברה מ-Kafka ל-Pub/Sub ואחריה, חשוב לעקוב אחרי האפליקציות. ‫Pub/Sub מייצא מדדים באמצעות Cloud Monitoring, שיכול לעזור לכם לקבל תובנות לגבי הביצועים, זמן הפעולה התקינה והתקינות הכללית של האפליקציות שלכם. לדוגמה, אתם יכולים לעקוב אחרי מספר ההודעות שלא נמסרו כדי לוודא שהמנויים שלכם מקבלים את כל ההודעות. כדי לעקוב אחרי הודעות שלא נמסרו, יוצרים התראות כשהחותמת של ההודעה הכי ישנה שלא אושרה חורגת מסף מסוים. אפשר גם לעקוב אחרי תקינות שירות Pub/Sub עצמו באמצעות מעקב אחרי מדד מספר בקשות השליחה ובדיקת קודי התגובה.

המאמרים הבאים