גישה לנתוני Kafka בשירות המנוהל של Google Cloud ל-Apache Kafka

אם אתם צריכים להעביר נתונים מנושא של Apache Kafka בקוד פתוח אל שירות מנוהל ל-Apache Kafka, אתם יכולים לעשות זאת באמצעות תבנית Dataflow. אפשר להשתמש במסוף Google Cloud , ב-API בארכיטקטורת REST או ב-Google Cloud CLI. ההודעות בנושא Kafka צריכות להתפרסם באמצעות סכימה וקידוד של AVRO או JSON.

במאמר הזה מוסבר איך להגדיר את התבנית Kafka to Kafka Dataflow באמצעות מסוף Google Cloud .

Google Cloud מוצרים בשימוש

תבנית Kafka to Kafka Dataflow משתמשת במוצרים הבאים שחלים עליהם חיובים Google Cloud . אתם יכולים להשתמש במחשבון התמחור כדי ליצור הערכת עלויות בהתאם לשימוש החזוי.

  • ‫Dataflow: ‏ Dataflow הוא שירות מנוהל במלואו לעיבוד נתונים. התבנית Kafka to Kafka Dataflow משתמשת ב-Dataflow כדי ליצור צינור שקורא נתונים מנושא Kafka חיצוני וכותב אותם לנושא של שירות מנוהל ל-Apache Kafka. התכונות של Dataflow להתאמה אוטומטית לעומס ולתיקון עצמי מבטיחות שצינור הנתונים יפעל בצורה אמינה ויעילה.
  • ‫Cloud Storage: שירות לאחסון אובייקטים. הוא משמש רק אם משתמשים באימות TLS למקור Kafka חיצוני. אתם מאחסנים את קובצי Keystore ו-Truststore שמכילים אישורי TLS ב-Cloud Storage, וצינור הנתונים של Dataflow ניגש אליהם מ-Cloud Storage.
  • ‫Secret Manager: ‏ Secret Manager הוא שירות לניהול סודות ופרטי כניסה.נעשה שימוש במוצר רק אם בוחרים באימות TLS או SASL_PLAIN למקור Kafka חיצוני. הוא שומר את פרטי האימות שלכם, כמו שמות משתמשים, סיסמאות ותעודות. פרטי הכניסה האלה משמשים להתחברות מאובטחת לאשכול Kafka החיצוני.

בנוסף, הפתרון משתמש גם בשירות מנוהל ל-Apache Kafka.

  • שירות מנוהל של Google Cloud ל-Apache Kafka: שירות Google Cloud שעוזר להפעיל את Apache Kafka. בפתרון הזה, השירות המנוהל ל-Apache Kafka משמש כיעד לנתונים שלכם. אתם מזרימים נתונים מנושא Kafka חיצוני לנושא באשכול של השירות המנוהל ל-Apache Kafka. מידע נוסף על התמחור של שירות מנוהל ל-Apache Kafka זמין במדריך התמחור.

לפני שמתחילים

לפני שמפעילים את תבנית Kafka to Kafka Dataflow, צריך לוודא שביצעתם את הפעולות הבאות:

  1. יוצרים אשכול ונושא בשירות מנוהל ל-Apache Kafka.

    אחת הדרכים ליצור אשכול ונושא היא לפעול לפי ההוראות שבמדריך למתחילים של שירות מנוהל ל-Apache Kafka.

    אם הנושא מכיל רשומות Avro, אפשר לעיין במאמר ציון פורמט ההודעה כדי לראות מהן דרישות המשאבים הנוספות.

  2. מפעילים את ממשקי ה-API הבאים: Google Cloud

    • Dataflow

    • ‫Secret Manager (רק אם אתם משתמשים באימות SASL_PLAIN או TLS למקור Kafka החיצוני)

    • ‫Cloud Storage (רק אם משתמשים באימות TLS למקור Kafka חיצוני)

    gcloud services enable dataflow.googleapis.com \
secretmanager.googleapis.com storage.googleapis.com

הכנת משאבי האימות של SASL_PLAIN

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

  1. במסוף Google Cloud , עוברים אל Secret Manager.

    מעבר אל Secret Manager

  2. יוצרים שני סודות: אחד לשם המשתמש שלכם ב-Kafka ואחד לסיסמה שלכם ב-Kafka.

    לכל סוד, צריך לציין שם תיאורי כמו kafka-username ו-kafka-password.

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

הכנת משאבי האימות של TLS

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

  1. במסוף Google Cloud , עוברים אל Secret Manager.

    מעבר אל Secret Manager

  2. מוודאים שקובץ מאגר המפתחות (בפורמט JKS) מכיל את אישור ה-TLS והמפתח הפרטי שנדרשים לאימות הלקוח באשכול Kafka.

  3. מוודאים שקובץ Truststore (בפורמט JKS) מכיל את האישורים המהימנים שנדרשים לאימות הזהות של ברוקר Kafka.

  4. מעלים את קובצי Keystore ו-Truststore ל-Cloud Storage.

    מידע נוסף על העלאת קבצים ל-Cloud Storage זמין במאמר העלאת אובייקטים ממערכת קבצים.

  5. יוצרים שלושה סודות להגדרת TLS:

    • סיסמת Truststore: מאחסנת את הסיסמה שמשמשת לגישה לקובץ Truststore.

    • סיסמת Keystore: הסיסמה שמשמשת לגישה לקובץ Keystore.

    • סיסמה של מפתח פרטי: מאחסן את הסיסמה שמשמשת לגישה למפתח הפרטי בקובץ מאגר המפתחות.

    לכל סוד צריך לתת שם תיאורי.

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

מקצים את התפקיד Managed Kafka client לחשבון השירות של העובד (worker) ב-Dataflow

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

כדי לאפשר גישה למשאבי Kafka, צריך להקצות את התפקיד roles/managedkafka.client לחשבון השירות של העובד (worker) של Dataflow. התפקיד הזה כולל את managedkafka.clusters.connect ההרשאה שנדרשת ליצירת חיבורים.

מידע נוסף על חשבון השירות של העובד זמין במאמר אבטחה והרשאות של צינורות ב-Google Cloud.

כדי להעניק את התפקיד Managed Kafka client לחשבון השירות של Dataflow:

המסוף

  1. נכנסים לדף IAM במסוף Google Cloud .
    כניסה לדף IAM
  2. מוודאים שהפרויקט מוגדר כפרויקט הצרכן שאליו יתבצעו גישות של לקוח השירות המנוהל ל-Apache Kafka.
  3. לוחצים על הענקת גישה.
  4. בדף החדש, בשדה Add Principals, מזינים את כתובת האימייל של חשבון השירות של עובד Dataflow שבו אתם משתמשים.
  5. בקטע Assign roles (הקצאת תפקידים), בוחרים בתפקיד Managed Kafka client (לקוח מנוהל של Kafka).
  6. לוחצים על Save.

‫CLI של gcloud

  1. במסוף Google Cloud , מפעילים את Cloud Shell.

    הפעלת Cloud Shell

    בחלק התחתון של Google Cloud המסוף יתחיל סשן של Cloud Shell ותופיע הודעה של שורת הפקודה. Cloud Shell היא סביבת מעטפת שבה ה-CLI של Google Cloud מותקן ומוגדרים ערכים לפרויקט הקיים. הסשן יופעל תוך כמה שניות.

  2. מריצים את הפקודה gcloud projects add-iam-policy-binding:

    gcloud projects add-iam-policy-binding PROJECT_ID \
  --member serviceAccount:SERVICE_ACCOUNT_EMAIL \
  --role roles/managedkafka.client

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫PROJECT_ID הוא מזהה הפרויקט.

    • ‫SERVICE_ACCOUNT_EMAIL היא כתובת האימייל של חשבון השירות של העובד (worker) ב-Dataflow.

הפעלת תבנית Kafka ל-Kafka Dataflow

אפשר להפעיל את התבנית Kafka to Kafka Dataflow מדף פרטי האשכול במסוף.

  1. נכנסים לדף Cluster במסוף Google Cloud .

    כניסה לדף Clusters

    מוצגת רשימה של האשכולות שיצרתם בפרויקט.

  2. כדי לראות את דף הפרטים של האשכול, לוחצים על שם האשכול.
  3. בדף הפרטים של האשכול, לוחצים על ייבוא נתונים.

    ייפתח הדף Create a Dataflow job using template "Kafka to Kafka" (יצירת משימת Dataflow באמצעות התבנית Kafka to Kafka).

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

מזינים שם של משרה

בשדה Job name (שם המשימה), מזינים שם למשימת Dataflow.

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

בחירת נקודת קצה אזורית לצינור

בשדה Regional endpoint, מגדירים את נקודת הקצה האזורית למיקום של אשכול Kafka כדי לצמצם את העמלות על העברת נתונים בין אזורים.

העובדים של Dataflow יכולים לפעול באופן עצמאי מאזור האשכול של Kafka. עם זאת, אם מפעילים עובדים מחוץ לאזור של אשכול Kafka, נושאים בעלויות של תעבורת נתונים יוצאת בין אזורים.

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

הגדרת המקור

  1. בשדה מקור, בוחרים באפשרות Kafka בניהול עצמי או חיצוני.

  2. בשדה Kafka bootstrap server (שרת אתחול של Kafka), מזינים את הכתובת של שרת האתחול של אשכול Kafka חיצוני.

  3. בשדה Source Kafka Bootstrap server and topic (שרת ונושא של Kafka במקור), מזינים את כתובת השרת והנושא של Kafka החיצוני.

  4. בקטע Kafka source authentication mode (מצב אימות של מקור Kafka), בוחרים את מצב האימות מבין האפשרויות שמופיעות. ב-Kafka חיצוני, יש שלוש אפשרויות:

    • SASL_PLAIN

    • TLS

    • ללא

לצורך אימות מקור SASL_PLAIN Kafka

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

אם בוחרים באפשרות SASL_PLAIN לאימות מקור Kafka, ממלאים את השדות הנוספים הבאים.

  1. בשדה Secret version ID for Kafka SASL/PLAIN username (מזהה גרסת הסוד לשם המשתמש של Kafka SASL/PLAIN), מזינים את מזהה הגרסה של שם המשתמש.

  2. בשדה Secret version ID for Kafka SASL/PLAIN password (מזהה גרסת הסוד לסיסמת Kafka SASL/PLAIN), מזינים את מזהה הגרסה של הסיסמה.

לאימות מקור TLS Kafka

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

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

  1. בקטע מיקום של Keystore, מזינים את הנתיב ב-Cloud Storage לקובץ Java Keystore ‏ (JKS). הקובץ הזה מכיל את אישור ה-TLS ואת המפתח הפרטי שנדרשים לאימות צינור הנתונים מול אשכול Kafka. לדוגמה: gs://your-bucket/keystore.jks

  2. בשדה Truststore file location (מיקום קובץ מאגר האישורים), מזינים את הנתיב ב-Cloud Storage לקובץ מאגר האישורים (JKS) של Java. הקובץ הזה מכיל את האישורים המהימנים שמשמשים לאימות הזהות של ברוקר Kafka.

  3. בקטע Secret Version ID for Truststore password (מזהה גרסת הסוד לסיסמת Truststore), מציינים את מזהה הסוד ב-Secret Manager שבו מאוחסנת הסיסמה לגישה לקובץ Truststore JKS.

  4. בשדה Secret Version ID of Keystore password (מזהה גרסת הסוד של סיסמת מאגר המפתחות), מציינים את מזהה הסוד ב-Secret Manager שבו מאוחסנת הסיסמה לגישה לקובץ ה-JKS.

  5. בשדה Secret Version ID of private key password (מזהה גרסת הסוד של הסיסמה למפתח פרטי), אם למפתח הפרטי שלכם ב-Keystore יש סיסמה נפרדת, מזינים את מזהה הסוד של Secret Manager שמכיל את הסיסמה הזו.

ביצוע Commit של אופסטים ל-Kafka

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

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

  1. מפעילים את האפשרות Commit offsets to Kafka.

  2. מציינים מזהה של קבוצת משתמשים פרטיים. זהו שם שמזהה את צינור הנתונים שלכם ב-Kafka.

  3. בקטע Default Kafka start offset (היסט התחלה של Kafka שמוגדר כברירת מחדל), בוחרים באחת מהאפשרויות הבאות:

    • המוקדם ביותר: מעבד הודעות מתחילת הנושא ב-Kafka.

    • האחרונה: עיבוד ההודעות מתחיל מההודעה החדשה ביותר.

הגדרת יעד

  1. בקטע 'יעד', בוחרים באפשרות שירות מנוהל ל-Apache Kafka.

  2. בשדה Kafka cluster (אשכול Kafka), בוחרים אשכול שכבר יצרתם.

  3. אפשר לבחור נושא קיים או ליצור נושא חדש.

  4. בקטע Kafka destination autheticaton method (שיטת אימות של יעד Kafka), בוחרים באפשרות Application Default Credentials (פרטי כניסה שמוגדרים כברירת מחדל לאפליקציה).

הגדרת הצפנה

כברירת מחדל, כל הנתונים במצב מנוחה ובזמן ההעברה מוצפנים על ידיGoogle-owned and Google-managed encryption key. אם יש לכם מפתחות הצפנה בניהול הלקוח (CMEK), אתם יכולים לבחור מפתחות משלכם. מידע נוסף על הגדרת CMEK זמין במאמר הגדרת הצפנת הודעות.

הגדרה של רשתות

צריך לציין את הרשת ואת רשת המשנה של האשכול בתבנית Dataflow. בקטע Optional parameters (פרמטרים אופציונליים) בתבנית אפשר להגדיר את הרשת של העובדים ב-Dataflow.

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

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

מידע נוסף על הגדרת רשתות עם צינור Dataflow זמין במאמרים הבאים:

אם נתקלתם בבעיות בהגדרת הרשת של Dataflow, כדאי לעיין במדריך לפתרון בעיות ברשת של Dataflow.

הגדרת פרמטרים אופציונליים של Dataflow

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

מעקב

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

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

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

    מידע נוסף זמין במאמר בנושא מעקב אחרי קצב העברת הנתונים ב-Dataflow.

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

    מידע נוסף זמין במאמר מעקב אחרי עדכניות הנתונים ב-Dataflow.

  • Backlog: כמות הבייטים שממתינים לעיבוד. המידע הזה משמש לקבלת החלטות לגבי התאמה אוטומטית לעומס.

מידע נוסף על מעקב ב-Dataflow זמין במסמכי התיעוד בנושא מעקב ב-Dataflow.

פתרון בעיות

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

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

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