קאפקא מול נאטס: השוואה לעיבוד הודעות

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

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

1. ארכיטקטורה ומורכבות

NATS

תשתית NATS כוללת שני רכיבים עיקריים:

גרעין NATS

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

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

JetStream

JetStream מביא יכולות מתמשכות לשיא של Core NATS. זה סייע לספק עמידות ונאמנות של הודעות. זה מאפשר להחזיק הודעות או אירועים (בדיסק או בזיכרון) ולנגן אותם מחדש. הודעות שהוחזקו יכולות להיות מנוגנות מחדש למנויים חדשים או מתאוששים. עם JetStream, משתמשים מקבלים תוספות:

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

JetStream מוסיף שכבת מורכבות ל-Core NATS. עם זאת, זה מביא את התכונה החשובה של תמיכה בשימושים של משלוח מובטח, מתמשכות ויכולת נגינה מחדש.

קאפקא

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

2. זמינות גבוהה וביצועים

נאטס

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

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

קפקה

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

קפקה שומרת על משהו שנקרא ISR (In Sync Replicas) לכל פרטית. אם המנהיג נכשל, אחד מ-ISR מתחיל לשמש כמנהיג. לניהול מטה-נתונים של האשף ולבחירת מנהיג, קפקה תלויה ב- Zookeeper (KRaft בגרסאות החדשות).

3. דפוסי הודעות

NATS

NATS משתמשת בהודעות מבוססות נושא. זה מאפשר לשירותים ולזרמים להשתמש בדפוסי Pub-Sub, Request-Reply ו-Queue Subscriber. נושאים ב-NATS יכולים להיות בנויים עם היררכיה וכרטיסיות. זרם NATS אחד יכול לאחסן נושאים מרובים והיישומים של הלקוח יכולים להשתמש במסנני צד השרת כדי לקבל רק את הנושאים המעניינים. החיבור ב-NATS הוא דו-כיווני ומאפשר ללקוחות לפרסם ולמנוי בו זמנית. NATS גם תומכת בתורים בדומה מאוד ל-RabbitMQ.

Kafka

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

4. ערבויות מסירה

NATS

NATS תומכת במגוון ערבויות מסירה. NATS לבדה יכולה לתמוך בערבות מסירה של "במקסימום פעם אחת". שרתי NATS עם JetStream מופעל יכולים לתמוך בשתי סוגי ערבויות נוספות. הם "לפחות פעם אחת" ו"פעם אחת בדיוק" ערבויות. NATS יכולה לשלוח 'ack' להודעות בודדות. אנא הפנה למדריך הרשמי של NATS עבור ה-'acks' השונים שהיא תומכת בהם. בהתבסס על סוג ה-'acks', NATS יכולה למסור מחדש הודעות.

Kafka

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

5. שמירת הודעות והתמדה

NATS

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

Kafka

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

6. שפות ופלטפורמה

NATS

שמונה-עשרה סוגי לקוחות ידועים. כל ארכיטקטורות התומכות ב-GOLANG יכולות לתמוך בשרתים של NATS.

קאפקא

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

שימושים

מקרה שימוש 1

דרישות

יש לנו פלטפורמת נתונים עם צינור סטרימינג. הפלטפורמה משתמשת במנוע Apache Flink עבור סטרימינג בזמן אמת וב-Apache Beam לכתיבת צינור האנליטיקה. להלן הדרישות המרכזיות:

1. עיבוד הודעות עם תפוקה גבוהה וזמן השהיה נמוך
2. תמיכה בניהול נקודות בדיקה ולחץ אחורי
3. טיפול בהודעות ב-MBs
4. עמידות הודעות ועקביות

השוואה

יתרונות קאפקאs:

• תפוקה גבוהה
• שימור נתונים עם מדיניות שימור ניתנת להגדרה ושכפול נתונים לעמידות בפני תקלות
• תמיכה לפחות בהבטחת מסירה אחת של הודעות
• קריאת הודעות מהאחרונה/מהראשונה/מ-offsets ספציפיים
• ‘acks’ בצד השרת למסירה מהימנה
• טיפול בזרמי נתונים עצומים ובגודל הודעות גדול
• תמיכה בנושא דחיסה

חסרונות קאפקא:

• שימוש גבוה במשאבים. השרת שלנו היה מקומי והיה מוגבל במשאבים
• קאפקה פועלת כמעט בזמן אמת

יתרונות NATS:

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

חסרונות NATS:

• אין מחברים ל-Flink/Beam ולכן, האינטגרציה הייתה קשה
• הפחתת ביצועים עם גודל ההודעה

ההחלטה הסופית

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

מקרה שימוש 2

דרישות

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

החלטה

למה NATS נבחרה:

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

למה לא נבחר קפקא:

• ברירת מחדל, הודעות נשמרות בדיסק
• שימוש במשאבים גבוה בהשוואה ל-NATS
• מאחר שזה דורש JVM, טביעת הזיכרון היא מאוד גבוהה

סיכום

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

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

תחומים מרכזיים שיש לקחת בחשבון לפני הבחירה בין קפקא ל-NATS:

1. ארכיטקטורה ומורכבות
2. זמינות וביצועים גבוהים
3. הבטחות אספקת הודעות

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

מצד שני, NATS קל משקל וקל לניהול. עיבוד הודעות באיחור נמוך הוא היכולת החתימתית של NATS.

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