Kafka ו־Redpanda: ארכיטקטורה, תאימות ופשרות תפעוליות

מבוא

Apache Kafka ו־Redpanda הן מערכות מבוזרות להזרמת אירועים, בעלות מימושים ובחירות תפעוליות שונות. Kafka פועלת ב־JVM; ‏Redpanda משתמשת ב־C++ וב־Seastar. תאימות לפרוטוקול Kafka אינה הופכת את ההתנהגות, התכונות או העלויות שלהן לזהות.

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

1. סקירת הארכיטקטורה

Apache Kafka

Kafka היא מערכת הודעות מבוזרת המבוססת על יומן ופועלת ב־JVM. רכיבי הליבה שלה הם:

ברוקרים שומרים ומספקים רשומות. בחרו מספר ברוקרים, שכפול ופיזור בין תחומי כשל לפי העומס ודרישות הזמינות, ולא לפי טווח אוניברסלי של 3–12 צמתים.
מניין המטא־נתונים KRaft מחליף את ארכיטקטורת ZooKeeper הישנה. Kafka 4.x אינה תומכת עוד במצב ZooKeeper; אשכול ישן המבוסס עליו חייב לעבור במסלול ההסבה המתועד לפני שדרוג. גם KRaft דורש בקרים מוגדרים ומתופעלים.
נושאים ומחיצות — הנתונים מאורגנים בנושאים המחולקים למחיצות לצורך מקביליות. המחיצות משוכפלות בין ברוקרים לצורך עמידות בתקלות.
יצרנים וצרכנים — יצרנים מפרסמים רשומות בנושאים; צרכנים קוראים אותן באמצעות קבוצות צרכנים ומעקב אחר היסטים.
Kafka Connect — מסגרת לשילוב Kafka עם מערכות חיצוניות, כמו מסדי נתונים, S3,‏ Elasticsearch ועוד.
Kafka Streams היא ספרייה ליישומים. ksqlDB היא מסד SQL לזרמים של Confluent, רכיב נפרד ולא עוד ספריית לקוח של Apache Kafka.

Redpanda

הברוקר של Redpanda ממומש ב־C++ באמצעות Seastar וחושף ממשקים של פרוטוקול Kafka. מוצרי Console ו־Connect שסביבו הם רכיבים נפרדים; שפת הברוקר אינה מתארת כל מוצר בחבילה.

ללא JVM בברוקר: הברוקר הטבעי של Redpanda אינו זקוק לכוונון ערימה או אוסף זבל של JVM. עדיין דרוש תכנון קיבולת מעבד, זיכרון, אחסון ורשת, ויכולים להתרחש זינוקי השהיה מסיבות אחרות.
Raft משולב: Redpanda משתמשת בקבוצות Raft לשכפול מחיצות ובקבוצת בקרים למטא־נתוני האשכול; היא אינה משתמשת במימוש KRaft של Kafka או באשכול ZooKeeper.
תהליכון לכל ליבה: Seastar מקצה עבודה לליבות ומשתמשת בהעברת הודעות ביניהן. הדבר מצמצם חלק מתיאום המצב המשותף, אך אינו מוכיח פעולה ללא נעילות בכל מקום או התרחבות ליניארית לכל עומס.
תאימות לפרוטוקול Kafka: לקוחות רבים דורשים מעט שינויים ביישום או אינם דורשים אותם, בכפוף לחריגים מתועדים. בדקו גרסאות לקוח מדויקות, APIs, עסקאות, אימות ומכסות במקום להניח שלא יידרש שינוי.
ממשקים נפרדים: הברוקר כולל Schema Registry ו־HTTP Proxy בשם Pandaproxy. ‏Redpanda Console היא יישום רשת נפרד המתחבר לאשכול; היא אינה שם נוסף ל־APIs האלה של הברוקר.

2. השוואת ביצועים

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

השהיה

Kafka: ההשהיה מקצה לקצה תלויה באצוות הלקוח, באישורי קבלה, בעומס הברוקר, באחסון, ברשת ובהתנהגות JVM. טווחי המילישניות במקור אינם מדידות מבוססות ולכן אינם מוצגים כערכים טיפוסיים.
Redpanda: הימנעות מאיסוף זבל של JVM מסירה את מקור ההשהיה המסוים הזה, לא את כל השהיית הזנב. אין כאן טענה ל־p99 נמוך מ־10 מילישניות או ליתרון פי עשרה; בדקו את האחוזון הדרוש בעומס מייצג.

תפוקה

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

השהיית זנב ויכולת חיזוי

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

3. מורכבות תפעולית

תפעול Kafka

Kafka 4.x משתמשת ב־KRaft ללא שירות ZooKeeper נפרד. מניין הבקרים, האחסון, הרשת, השדרוגים והשחזור מתקלות נותרים באחריות התפעול.
יש לתכנן ערימת JVM, איסוף זבל, מטמון דפים ומשאבי מערכת הפעלה לפי גרסאות Kafka ו־Java שנבחרו. הוראה קבועה לערימה של 6–8GB אינה מתאימה לכל ברוקר.
מיקום מחיצות והקצאתן מחדש דורשים תוכנית תפעולית. הבחירה בכלים המובנים או באוטומציה נוספת תלויה בהפצה, בעומס ובמודל התמיכה.
הוסיפו שירותי Connect, עיבוד זרמים או ניהול סכימות רק כשהיישום דורש אותם; הם אינם כולם חלקים הכרחיים בכל פריסת Kafka.
בחרו מערך ניטור למדדי ברוקר, JVM, לקוחות ואחסון. Prometheus,‏ Grafana ומייצאי JMX הם אפשרויות, לא שילוב מחייב.

תפעול Redpanda

הברוקר הטבעי חוסך פריסת JVM ו־ZooKeeper, אך עדיין תלוי במערכת ההפעלה, באחסון וברשת. Console ו־Connect נפרסים בנפרד כשנדרש.
Redpanda כוללת מנגנוני איזון מחיצות. איזון מתמשך הוא תכונת Enterprise בתיעוד הרישוי שנבדק; יש להבחין בינו לבין איזון בהוספת צומת.
הברוקר משלב Schema Registry ו־HTTP Proxy, ויכול לחסוך שירותים נפרדים לתפקידים האלה. אמתו דרישות API ותאימות סכימות לפני החלפת מימוש אחר.
Redpanda Console מציעה תצוגות נושאים, קבוצות צרכנים וסכימות לאחר פריסה ותצורה נפרדות. בדקו בקרת גישה ורישוי במקום לחשוף ממשק ניהול כברירת מחדל.
Redpanda מספקת כלים לפריסה ב־Kubernetes. השוו מחלקות אחסון, דרישות משאבים, מדיניות רשת, שדרוגים ושחזור בסביבה שלכם; כלים ל־Kubernetes לבדם אינם מוכיחים תקורה נמוכה יותר או תפעול פשוט יותר.

4. תכנון פריסה, לא התקנה שבוצעה

תכנון Apache Kafka במצב KRaft

בדיקת גרסה: Kafka 4.0 ומעלה דורשת Java 17 או חדשה יותר עבור ברוקרים, Connect וכלים; יש לבדוק את המהדורה המסוימת שנבחרה. תכננו יתירות ברוקרים ובקרים לפי דרישות עמידות בכשל. לא נוצרו כאן אשכול, נושא או תיקיית אחסון.

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

בדיקת תצורה למהדורת Kafka שנבחרה:

בדקו תפקידי ברוקרים ובקרים, מזהי צמתים, מאזינים ותצורת מניין.
בחרו תיקיות יומנים, מספר מחיצות ושכפול לפי יעדי קיבולת ושחזור.
בחרו מגבלות שמירה ומקטעים לפי מחזור חיי הנתונים המאושר.
קבעו מספר תהליכונים וזיכרון לפי מדידות ולא לפי קבועים שהועתקו.
אין לכלול zookeeper.connect בתצורת KRaft של Kafka 4.x.

תכנון Redpanda

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

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

פריסה ב־Kubernetes של Redpanda

רשימת בדיקה ל־Kubernetes — ללא פעולת Helm או kubectl:
• קבעו גרסאות תואמות של Operator או תרשים, של ברוקר ושל Console.
• בדקו אחסון מתמיד, תזמון, מגבלות משאבים וטיפול בהפרעות.
• הגבילו חשיפה לרשת והגדירו אימות, הרשאות ו־TLS.
• הפרידו תצורת ברוקר ותצורת Console ובדקו תכונות התלויות במהדורה.
• הגדירו נהלי שחזור, שדרוג וחזרה לאחור לפני שינוי מורשה במעבדה או בייצור.

5. המערכת האקולוגית ושילובים

המערכת האקולוגית של Kafka

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

Kafka Connect: מסגרת מחברים למערכות חיצוניות. מספר המחברים אינו מבטיח תאימות או איכות; אמתו רישיון, גרסאות נתמכות וסמנטיקת מסירה של המחבר המסוים.
Kafka Streams: ספרייה לעיבוד זרמים המשובצת ביישום; היישום עדיין דורש פריסה, משאבים ותכנון מצב ושחזור.
ksqlDB: ממשק SQL לעיבוד זרמים על Kafka.
מעבדי זרמים חיצוניים: כשנדרש שילוב Flink או Spark, יש לאמת בנפרד את מחבר הפרויקט, את גרסת לקוח Kafka ואת סמנטיקת נקודות הביקורת וההיסטים.
Confluent Platform: הפצת מוצרים נפרדת סביב Kafka. בדקו זמינות רכיבים, גרסאות, רישוי ותמיכה במקום לייחס את כל שירותי הענן המנוהלים לפלטפורמה באירוח עצמי.
Strimzi: מפעיל Kafka עבור Kubernetes בקוד פתוח.

המערכת האקולוגית של Redpanda

לקוחות: Redpanda מתעדת לקוחות Kafka שאומתו וחריגי תאימות. לדוגמה, משתמש SASL אחד אינו יכול להחזיק גם אישורי SCRAM-SHA-256 וגם SCRAM-SHA-512, ומכסת request_percentage אינה נתמכת. בדקו את חוזה היישום המדויק.
Kafka Connect: עובדים יכולים להשתמש ב־Redpanda כברוקר תואם Kafka, אך יש לבדוק APIs של המחבר והסדרי תמיכה. Redpanda Connect היא מסגרת אחרת, לא פשוט עובד נוסף של Kafka Connect.
Schema Registry מובנה: סכימות Avro,‏ JSON Schema ו־Protobuf מנוהלות באופן טבעי.
HTTP Proxy בשם Pandaproxy: תומך בייצור ובצריכת הודעות דרך HTTP; הוא אינו מספק יצירה, קריאה, עדכון ומחיקה של נושאים ושל ACL דרך הפרוקסי הזה. הוא אינו חלופה זהה לכל פרוקסי REST של Kafka.
Redpanda Connect: מסגרת הצהרתית לצינורות נתונים הנפרסת בנפרד. בדקו רישוי מחברים והתנהגות מסירה מקצה לקצה עבור הקלטים והפלטים שנבחרו.
Redpanda Cloud: קיימות אפשרויות פריסה מנוהלות. יש לבדוק זמינות עדכנית של ספק, אזור, סוג פריסה ותכונות עבור המסלול המתוכנן.

6. אבטחה

אבטחת Kafka

TLS יכול להגן על התעבורה כשהוא מוגדר ואימות התעודות נאכף; הפעלתו אינה מחליפה הרשאות.
Kafka תומכת במנגנוני SASL ובהם PLAIN,‏ SCRAM,‏ GSSAPI ו־OAUTHBEARER. בחרו מנגנון נתמך המוגדר באופן מאובטח; אסור ש־PLAIN יחשוף אישורי גישה בחיבור שאינו מוצפן.
הרשאות המבוססות על ACL
תכננו הצפנת אחסון וגיבויים, גישה למפתחות והחלפתם בנפרד מאבטחת התעבורה; TLS של Kafka אינו מצפין בעצמו מידע במנוחה.
הגדירו דרישות ביקורת ואמתו מה ההפצה או השירות שנבחרו מתעדים, מי יכול לקרוא את הרשומות ולכמה זמן הן נשמרות. אין להניח ששם מוצר מוכיח כיסוי ביקורת.

אבטחת Redpanda

TLS ו־mTLS נתמכים בתצורה המתאימה לכל ממשק Redpanda; יש לאבטח נתיבי ברוקר, ניהול, מרשם ופרוקסי, ולא רק את מאזין Kafka.
SASL/SCRAM נתמך עבור לקוחות Kafka; מנגנונים ומגבלות אישורי גישה משתנים לפי ממשק וגרסה. המגבלה המתועדת של מנגנון SCRAM אחד למשתמש עדיין חלה.
RBAC ב־Enterprise מקבץ הרשאות באמצעות תפקידים. זהו מודל ניהול אחר, לא הוכחה להרשאות מפורטות מטבען יותר מ־ACL של Kafka.
רישום ביקורת מובנה בשכבה הארגונית
אמתו דרישות להצפנת אחסון ולניהול מפתחות בפריסה שנבחרה. רשימת תכונות Enterprise שנבדקה אינה מבססת את טענת המקור לתכונת TDE טבעית, ולכן הטענה אינה נשמרת.

7. עלות ורישוי

Apache Kafka: ברישיון Apache 2.0. רישיון תוכנה ללא תשלום אינו הופך תשתית או תפעול לחינמיים. חשבונות שירות מנוהל משתנים לפי ספק, סוג ברוקר, אזור, אחסון, תעבורה ומסלול; מחיר MSK האחיד שבמקור אינו אומדן כללי תקף.
Redpanda Community: רישיון BSL מאפשר גישה לקוד המקור, אך אינו רישיון קוד פתוח. למגבלה המתועדת על שירות מסחרי יש משמעות; בדקו את הרישיון עצמו עבור השימוש המתוכנן. עלויות תפעול נשארות גם ללא דמי רישיון תוכנה.
Redpanda Enterprise: התיעוד הנוכחי מציין את Redpanda Community License עבור Enterprise ומפתח רישיון נדרש לתכונות כגון RBAC, רישום ביקורת ואחסון בשכבות. אמתו תנאים וזכויות שימוש; מאמר זה אינו מפעיל ניסיון או הסכם.
Redpanda Cloud: ‏Serverless,‏ Dedicated ו־BYOC הן אפשרויות פריסה שונות. קבלו אומדן עדכני המתאים לעומס, הכולל אחסון, העברה, תשתית ותמיכה, במקום להניח מחיר יחיד המבוסס רק על תפוקה.

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

8. מתי לבחור Kafka ומתי Redpanda

שקלו Kafka כאשר:

המחברים וכלי התפעול הדרושים זמינים ונתמכים בהפצת Kafka שנבחרה.
כבר השקעתם ב־Confluent Platform או ב־Kafka Streams וב־ksqlDB
לצוות שלכם יש מומחיות תפעולית עמוקה ב־Kafka
למחברי Kafka Connect הדרושים יש גרסה, רישיון ומסלול תמיכה שאומתו.
אתם משתמשים בשירותים מנוהלים כמו Amazon MSK או Confluent Cloud

בחנו Redpanda כאשר:

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

טבלת השוואה מסכמת

מאפיין	Apache Kafka	Redpanda
שפה	Java ב־JVM	C++ עם Seastar
תלות לצורך תיאום	בקרי KRaft ב־4.x; ללא מצב ZooKeeper	קבוצות Raft משולבות
השהיית p99	תלוי בעומס; אין כאן מדידה	תלוי בעומס; אין כאן מדידה
תאימות ל־API של Kafka	כן, טבעית	פרוטוקול Kafka, עם חריגים מתועדים
מרשם סכימות	רכיב נפרד, אם נדרש	מובנה
פרוקסי REST	רכיב נפרד, אם נדרש	מובנה, Pandaproxy
ממשק רשת	כלים נפרדים לפי בחירת המפעיל	Redpanda Console: יישום נפרד
רישיון	Apache 2.0	BSL לקהילה; RCL לארגונים; יש לבדוק תנאים
תפעול Kubernetes	כלים כגון Strimzi; נדרשת בדיקה תפעולית	כלים רשמיים; נדרשת בדיקה תפעולית
הערכת המערכת האקולוגית	בדקו מחברים, לקוחות ותמיכה נדרשים	בדקו שילובים נדרשים וחריגים

סיכום

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

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