השירות המנוהל ל-Apache Kafka הוא Google Cloud שירות שעוזר לכם להפעיל אשכולות מאובטחים וניתנים להרחבה של Apache Kafka בקוד פתוח. בדף הזה מובאת סקירה כללית של הפעולות שהשירות מבצע באופן אוטומטי כדי לפשט את התהליך. מידע נוסף על Apache Kafka זמין באתר של Apache Kafka.
שינוי גודל והתאמה פשוטים
כדי לשנות את הגודל או את קנה המידה של אשכול בשירות מנוהל ל-Apache Kafka, צריך רק להגדיר את המספר הכולל של ליבות ה-vCPU ואת גודל ה-RAM של האשכול. הניהול של הברוקרים, כולל אחסון, מתבצע באופן אוטומטי לחלוטין. כדי לעמוד בדרישות של הלקוחות, אתם יכולים לעקוב אחרי השימוש ב-vCPU ובמשאבים אחרים, ולהגדיל או להקטין את המכסות בהתאם.
כשמגדירים את מספר ליבות ה-vCPU ואת גודל ה-RAM, השירות מבצע באופן אוטומטי שינוי גודל של הברוקר והקצאת משאבים. אם הגדלת גודל האשכול מחייבת ברוקר חדש, השירות יכול לבצע איזון מחדש של המחיצות בין הברוקרים באופן אוטומטי.
הקצאת הרשאות למתווך
כשמגדירים את הגודל הכולל של vCPU ו-RAM עבור האשכול, השירות מקצה ברוקרים חדשים ומשנה את גודל הברוקרים הקיימים. בדרך כלל, כשמגדירים אשכול, הגודל הכולל של המעבדים הווירטואליים ושל ה-RAM מתחלק באופן שווה בין כל הברוקרים. כלומר, מותר להשתמש במספרים חלקיים של vCPU לכל ברוקר, אבל נדרש מינימום של vCPU אחד לכל ברוקר. כל האשכולות מפוזרים על פני שלושה אזורים. המשמעות היא שנדרשים לפחות 3 vCPU ו-3 GiB של RAM לכל אשכול.
ככל שמגדילים את גודל האשכול, מתבצעת הרחבה אנכית של הברוקרים עד 15 vCPU לכל ברוקר. אחרי שמגיעים למגבלה הזו, השירות יוצר ברוקרים חדשים. כשמקטינים את גודל האשכול, המתווכים הקיימים מצטמצמים למעבד וירטואלי יחיד, אבל לא נמחקים.
הגודל המקסימלי של הברוקר עשוי להשתנות בכל שלב. הגבלנו את מספר המתווכים כדי לשמור על קנה מידה לינארי של תפוקת המתווך בהתאם למספר ליבות ה-vCPU.
אלגוריתם שינוי קנה מידה
מספר הברוקרים נקבע לפי הקיבולת הכוללת של המעבדים הווירטואליים או הזיכרון של האשכול. יחס הגידול הוא ברוקר אחד לכל 15 ליבות וירטואליות או 120 גיביבייט (GiB) של משאבים, לפי מה שיוביל למספר גדול יותר של ברוקרים. יחס ה-vCPU לזיכרון (vCPU:GiB) צריך להיות בין 1:1 ל-1:8. הברוקרים מחולקים באופן שווה בין 3 האזורים, עם הבדל מקסימלי של אחד.
לדוגמה, אם מגדירים אשכול עם 70 vCPU ו-130 GiB RAM, יחד עם מקדם שכפול של 3, החישוב הבא קובע את מספר הברוקרים:
חישוב מספר הברוקרים שנדרשים כדי להסביר את המעבדים הווירטואליים:
ceiling(70 vCPUs / 15 vCPUs)= 5 ברוקריםכדי לחשב את מספר הברוקרים שנדרש כדי להסביר את הזיכרון:
ceiling(130 GiB / 120 GiB)= 2 ברוקרים
בתרחיש הזה, לאשכול יש 5 ברוקרים, כי מספר הברוקרים נקבע לפי מספר ה-vCPU. לשניים מתוך שלושת האזורים מוקצים 2 ברוקרים, ולאזור האחרון מוקצה ברוקר אחד.
ניהול האחסון
ניהול האחסון מתבצע באופן אוטומטי. ברוב המקרים, אתם אחראים להגדיר את משך השמירה של נושאים ספציפיים כדי לשלוט בעלויות או כדי לעמוד בדרישות של מדיניות שמירת הנתונים שלכם. אין צורך להקצות ולנהל דיסקים קשיחים קבועים.
השירות מסתמך על אחסון בשכבות (KIP-405). אחסון בשכבות משלב בין נפחי דיסק קשיח שהוקצו מראש ומצורפים לברוקרים לבין אחסון אובייקטים כמעט בלתי מוגבל.
השירות מקצה לפחות 100 GiB של דיסקים קשיחים קבועים מסוג SSD לכל vCPU כדי לאזן בין ביצועים, זמינות ועלות. תחויבו על 100GiB לכל vCPU, למרות שהגודל בפועל של הדיסק לכל ברוקר עשוי להיות גדול יותר. גודל הדיסק לכל ברוקר אף פעם לא קטן, גם אם מתבצעת הקטנה של גודל האשכול.
כל מנהיג מחיצה מאחסן הודעות בזיכרון זמני בקבצי פלחים בדיסקים הקבועים האלה. אחרי שקטע מסוים מסתיים, הוא מועבר לאחסון אובייקטים קבוע שמגובה על ידי Cloud Storage אזורי. הגודל של קובצי הפלחים האלה מוגדר על ידי ההגדרות log.roll.ms ו-log.segment.bytes.
הפרטים האלה מועילים להבנה, אבל נפח האחסון מנוהל על ידי השירות. ההגדרות הספציפיות, כמו נפח הדיסק הקשיח לכל vCPU, הן פרטי הטמעה שעשויים להשתנות. אין לכם גישה ישירה לקטגוריות של Cloud Storage שמשמשות לאחסון מתמיד.
איזון מחדש
כדי שהברוקרים החדשים יועילו לשמירה על הביצועים, צריך להעביר חלק מהתנועה מהברוקרים הקיימים למכונות החדשות. כדי להקל על התהליך, אפשר להפעיל איזון מחדש אוטומטי.
אם מפעילים את האיזון מחדש האוטומטי, כשמוסיפים ברוקר חדש, השירות מאזן מחדש באופן אוטומטי את המחיצות מהברוקרים הקיימים. מודל האחסון בשכבות מוודא שצריך להעתיק כמות קטנה יחסית של נתונים למתווכים חדשים, וכך מקצר את משך האיזון מחדש.
אלגוריתם האיזון מחדש מבוסס על מספר המחיצות. הוא לא מתייחס לתנועה בפועל שמוצגת בכל מחיצה.
רשת גמישה
השירות מאפשר גישה מאובטחת לאשכול מכל VPC. הגישה הזו כוללת גישה ממספר רשתות VPC, פרויקטים ואזורים.
כדי להגדיר את הרשת עבור אשכול, צריך לספק את קבוצת רשתות המשנה שדרכן אפשר לגשת לאשכול. השירות מקצה כתובות IP פרטיות לשרתי האתחול ולברוקרים בכל רשת משנה. הוא גם מגדיר Cloud DNS פרטי בענן עם כתובות URL לכל כתובת IP. לשרתי האתחול יש איזון עומסים, ולכן יש כתובת URL אחת לאתחול לכל אשכול. כתובות ה-URL זהות בכל ה-VPC, כך שהגדרות הלקוח יכולות להיות עקביות בכל הסביבות.
רמת הגמישות הזו מתאפשרת בזכות Private Service Connect (PSC). לכל כתובת IP שהוקצתה לאשכול נדרשת נקודת קצה של PSC. נקודות הקצה מוקצות באופן אוטומטי.
אשכולות מאובטחים
השירות מציע את התכונות הבאות לאבטחת האשכולות: אימות, הרשאה, הצפנה, תיקון ובידוד משאבים. בנוסף, הוא אוסר על חיבורים ועל אחסון לא מאומתים ולא מוצפנים.
אימות
השירות תומך בשתי שיטות אימות: שכבת אימות ואבטחה פשוטה (SASL) ו-TLS בו-זמני (mTLS). אימות mTLS זמין באשכולות שנוצרו אחרי 24 ביוני 2025. כל החיבורים לאשכולות מנוהלים מאומתים באמצעות חשבון משתמש שהוא זהות IAM באמצעות SASL או אישור לקוח באמצעות mTLS. כשמשתמשים ב-SASL, אפשר להשתמש בחשבונות של אנשים, חשבונות שירות וחשבונות מאוחדים כחשבונות משתמשים.
השירות לא תומך בפרוטוקולים אחרים, כולל SASL/GSSAPI, SASL/SCRAM-SHA-256 ו-SASL/SCRAM-SHA-512. בנוסף, השירות לא מאפשר חיבורים לא מאומתים.
הרשאה
השירות משתמש בגישה רב-שכבתית להרשאות. IAM שולט בפעולות ניהול אשכולות כמו יצירה, עדכון ומחיקה של משאבים. ההרשאה של חשבונות משתמש מאומתים תלויה בשיטה שבה נעשה שימוש:
SASL: חשבונות משתמשים שמשתמשים ב-IAM מקבלים הרשאה באמצעותGoogle Cloud קישורי תפקידים ב-IAM או באמצעות רשימות ACL של Kafka באשכול. מידע נוסף זמין במאמר בנושא הגדרת אימות SASL.
mTLS: יש אישור ל-Principals שמאומתים באמצעות mTLS דרך רשימות ACL של Kafka. מידע נוסף זמין במאמר בנושא הגדרת אימות mTLS.
אפשר לנהל את רשימות בקרת הגישה (ACL) של Kafka באמצעות Google Cloud כלים או כלים של צד שלישי ל-Kafka. מידע נוסף על הגדרת IAM ורשימות ACL של Kafka זמין במאמר בקרת גישה באמצעות IAM ורשימות ACL של Kafka.
הצפנה
נדרשת הצפנה. כל החיבורים לאשכולות חייבים להשתמש ב-TLS. אישורי ה-TLS שמוצגים על ידי הברוקרים חתומים על ידי רשות האישורים הציבורית. הנתונים המאוחסנים תמיד מוצפנים. בוחרים אם להשתמש במפתחות הצפנה בניהול Google או במפתחות הצפנה בניהול הלקוח (CMEK) להצפנה של נתונים באחסון.
תיקון
צוות השירות עוקב אחרי נקודות חולשה באבטחה שמתגלות בקוד הפתוח. כשהשירות מזהה פגיעויות, הוא מתקן את האשכולות באופן אוטומטי.
בידוד משאבים
תכונת אבטחה נוספת של השירות היא בידוד משאבים. השירות המנוהל פורס אשכולות בפרויקטים של דיירים ב-VPC פרטי שלא ניתן לגשת אליו באמצעות כתובות IP ציבוריות. לכל אחד מהפרויקטים שלכם יש פרויקט ייעודי לדייר, עם חשבון סוכן שירות ייעודי. כך אפשר להגביל את היקף הגישה שניתנת לשירות.
מאגר סכימות
כדי לפשט את התיאום בין הבעלים של השירות המנוהל לבין הצרכנים, שירות מנוהל ל-Apache Kafka כולל API של מאגר סכימות. מאגר נתונים שמוגדר על ידי השירות משמש כמאגר של סכימות שמשותפות בין אפליקציות.
השירות מטמיע את Confluent Schema Registry API בארכיטקטורת REST, שעוזר בשילוב עם אפליקציות קיימות של Kafka. יש תמיכה בפורמטים של סכימות Apache Avro ו-Protocol Buffer (Protobuf). אין תמיכה ב-JSON.
בנוסף, שירות מנוהל ל-Apache Kafka מציע API וערכת כלים לניהול של מאגרי סכימות וסכימות. ערכת הכלים כוללת את מסוףGoogle Cloud , ה-CLI של gcloud וספריות לקוח.
מידע נוסף על מאגר סכימות זמין במאמר סקירה כללית על מאגר סכימות.
שילוב נתונים עם Kafka Connect
השירות המנוהל ל-Apache Kafka מפשט את שילוב הנתונים באמצעות Kafka Connect. Kafka Connect מציע כמה תוספי מחברים מובנים שמתארחים באשכולות Connect. המחברים האלה משמשים להעברה, לגיבוי, להתאוששות מאסון, לזמינות גבוהה ולאינטגרציה של נתונים. המחברים האלה מאפשרים לכם לחבר את האשכולות שלכם בשירות המנוהל ל-Apache Kafka למערכות שונות, כולל פריסות אחרות של Kafka ושירותים כמו BigQuery, Cloud Storage ו-Pub/Sub. Google Cloud Kafka Connect מספק שילוב נתונים מהימן וניתן להרחבה עם תקורה תפעולית נמוכה וניטור ורישום משולבים.
מידע נוסף על Kafka Connect זמין במאמר סקירה כללית של Kafka Connect.
אשכולות עם זמינות גבוהה
מטרת השירות היא לספק אשכולות אזוריים לאפליקציות קריטיות. באופן ספציפי, השירות מגן עליכם מפני כשלים באזורים או בברוקרים ספציפיים.
כדי להשיג זאת, כל האשכולות מוקצים בתצורה של שלוש אזורים עם מודעות למיקום המתלים. ההגדרה של נושא ברירת המחדל דורשת לפחות שלוש רפליקות. המודעות למיקום בארון השרתים מבטיחה שההעתקים ייווצרו באזורים שונים. מספר העותקים המינימלי שמוגדר כברירת מחדל הוא שניים. המשמעות היא שהאשכול יכול לעמוד בפני אובדן מלא של אזור או של ברוקר.
אם מתרחש כשל בברוקר בגלל תוכנה, חומרה או רשת, הוא מוחלף באופן אוטומטי. כשהשירות מזהה כשל בברוקר, הוא מפעיל אותו מחדש באופן אוטומטי, במכונה אחרת אם צריך. אחרי שהברוקר זמין, Apache Kafka משלב את הברוקר באשכול. יכול להיות שאי אפשר יהיה ליצור ברוקר חדש אם תהיה כשל באזור שלם. עם זאת, האשכול ימשיך לפעול כל עוד שני האזורים האחרים יישארו זמינים.
בנוסף לתכונות הספציפיות האלה, יש רשימה הולכת וגדלה של כלים ותהליכים פנימיים ששומרים באופן יזום על תקינות השירות, על קוד Apache Kafka ועל העדכונים. גיבויים של נתונים ומטא נתונים מתבצעים בכמה רמות, כך שהשירות יכול להתאושש מטעות אנוש ומכשלים בתוכנה.
השירות לא מספק הגנה מפני כשלים אזוריים או כשלים בשני אזורים. לאפליקציות שדורשות רמת הגנה כזו, מומלץ להפעיל שני אשכולות אזוריים נפרדים. אפשר לסנכרן את הנתונים בין שני אשכולות באמצעות כלים כמו MirrorMaker 2.0 מ-Kafka Connect.
כלים לסגנון הניהול שלכם
מטרת השירות היא להציע לכם ערכה מלאה של כלים לניהול אשכולות ולפתרון בעיות. היא כוללת כלים לניהול, למעקב ולרישום ביומן.
השירות המנוהל ל-Apache Kafka נחשף כ-Google Cloud API. כלומר, אתם יכולים לנהל אשכולות ומשאבים באשכולות באמצעות ממשקי API ל-REST ול-gRPC. יש כמה לקוחות וממשקים שזמינים לממשקי ה-API האלה, כולל
- ספקי Terraform אם אתם מעדיפים את הגישה של תשתית כקוד.
- ממשק משתמש במסוף Google Cloud לעבודה אינטראקטיבית בדפדפן.
- ה-CLI של gcloud לעבודה אינטראקטיבית במעטפת.
- ספריות משתמש ב-Java, Python, Go ושפות אחרות לפיתוח מותאם אישית ולסקריפטים.
לצורך מעקב ופתרון בעיות, השירות מייצא מדדים ל-Cloud Monitoring. חלק מהמדדים זמינים בממשק המשתמש של השירות. סט מלא זמין ב-Cloud Monitoring לעבודה אינטראקטיבית, להגדרת התראות ולייצוא למערכות אחרות.
השירות גם מייצא יומני תיווך ל-Cloud Logging. אפשר לחפש אותם, ואפשר להשתמש בהם כדי ליצור מדדים מבוססי-יומנים והתראות.
שדרוגים ותיקוני באגים
אשכולות של שירות מנוהל ל-Apache Kafka פועלים בגרסה 3.7.1 של Apache Kafka. השירות מתקן באופן אוטומטי פרצות אבטחה קריטיות.
העדכונים לתשתית הבסיסית, כולל מערכת ההפעלה ושכבות התיאום, מתבצעים באופן רציף ואוטומטי. העדכון של הברוקרים מתבצע באמצעות הפעלה מחדש מתגלגלת, ללא זמן השבתה של האשכול.
השירות לא משדרג אוטומטית את קוד Apache Kafka שפועל בברוקרים לגרסאות משניות חדשות.
עלות שקופה
מודל התמחור של השירות המנוהל ל-Apache Kafka דומה לחיובים שמופיעים כשמריצים את Apache Kafka בעצמכם ב-Compute Engine. אתם משלמים על המשאבים שאתם מקצים – vCPU, RAM ואחסון מקומי – ועל המשאבים שאתם צורכים – אחסון קבוע והעברת נתונים. העלות של אחסון קבוע ושל vCPU גבוהה יותר בשירות מנוהל ל-Apache Kafka בהשוואה להגדרת מערכת דומה באופן עצמאי. לעומת זאת, מחירי העברת הנתונים והאחסון המקומי דומים בשירות המנוהל ל-Apache Kafka וב-Kafka בניהול עצמי. מידע נוסף על תמחור זמין במאמר בנושא תמחור של שירות מנוהל ל-Apache Kafka.
תואם כי אנחנו מפעילים את Apache Kafka
לבסוף, השירות המנוהל ל-Apache Kafka מפעיל את אותה תוכנת קוד פתוח שאולי כבר מופעלת בסביבה שלכם. לא צריך לשנות את קוד האפליקציה כדי להעביר אותה לשירות.
מגבלות
יש לשירות המנוהל ל-Apache Kafka את המגבלות הבאות:
לכל אשכול צריכים להיות משאבים שווים בכל אחד משלושת האזורים. לא ניתן להשתמש באשכולות של שירות מנוהל ל-Apache Kafka עם אזור אחד או שני אזורים.
אי אפשר לבחור את האזורים כשיוצרים את האשכול.
אי אפשר להגדיר את נפח האחסון המקומי באשכול.
השירות המנוהל ל-Apache Kafka פועל במצב KRaft. אין תמיכה במצב Zookeeper.
אין תמיכה בממשקי JMX API למדדים.
אין תמיכה בדחיסת נושאים באמצעות
zstd. הערכים הנתמכים שלcompression.typeכוללים אתlz4,gzip,snappyו-uncompressed.אפשר לשנות את ההגדרות של הברוקרים בכל שלב באמצעות מצב העדכון
read-only, אבל השינויים האלה ייכנסו לתוקף רק אחרי שהברוקרים יופעלו מחדש. ההפעלה מחדש מתבצעת מדי פעם כחלק מתהליכי התחזוקה והשדרוג של Google, אבל אין לוחות זמנים קבועים או דרך להפעיל אותה באופן ידני. לכן אין לכם שליטה על המועד שבו השינויים האלה ייכנסו לתוקף. דוגמאות להגדרות שלread-onlyכוללות אתauto.create.topics.enableו-background.threads. עדכונים של הגדרות עם מצב העדכוןcluster-wide, כמוmessage.max.bytes, לא מחייבים הפעלה מחדש ונכנסים לתוקף באופן מיידי.חלק מפרמטרים ההגדרה של הברוקר מנוהלים על ידי השירות ולא ניתן לעדכן אותם. ההגדרות האלה כוללות את
broker.idוהגדרות שקשורות לאחסון, כמוremote.log.storage.system.enable.
מה השלב הבא?
- יוצרים אשכול של שירות מנוהל ל-Apache Kafka.
- שליחה וקבלה של הודעות באמצעות אשכול של שירות מנוהל ל-Apache Kafka.
- מומלץ לעיין בהגבלות על שירות מנוהל ל-Apache Kafka.
- מידע נוסף על התמחור של שירות מנוהל ל-Apache Kafka