זמינות גבוהה של סטרימינג

כברירת מחדל, משימות של Dataflow לעיבוד נתונים בזמן אמת מריצות חלק ממשאבי ה-Backend שלהן בתחום (zone) יחיד של Compute Engine, ולכן המשימות האלה חשופות לאובדן נתונים במהלך הפסקת חשמל אזורית. זמינות גבוהה בסטרימינג הופכת משימה של Streaming Engine למשאב אזורי על ידי שכפול מצב הבק-אנד בכמה אזורים באזור. כשמפעילים זמינות גבוהה של סטרימינג, כשל באזור אחד לא גורם להשבתת משימת הסטרימינג.

תמיכה ומגבלות

לזמינות גבוהה של סטרימינג יש את הדרישות והמגבלות הבאות:

  • נדרש Streaming Engine: המשימה חייבת להיות פייפליין זורם שמשתמש ב-Streaming Engine.
  • נדרשת הצבה אזורית של העובדים: העובדים ב-Compute Engine צריכים להשתמש במיקום אזורי. אם למשימה יש וורקרים רק באזור ספציפי והאזור הזה לא זמין, המשימה לא יכולה לעבד נתונים כי הוורקרים שלה לא זמינים, למרות שהמצב של הקצה העורפי משוכפל. לכן, Dataflow דוחה משימות שמציינות אזור מסוים של עובד (כמו --workerZone,‏ --worker_zone או --zone) כשהזמינות הגבוהה של הסטרימינג מופעלת.
  • הגדרה רק בזמן יצירת המשימה: אפשר להפעיל זמינות גבוהה של סטרימינג רק כשמתחילים משימה חדשה. אי אפשר להפעיל או להשבית את הזמינות הגבוהה של סטרימינג כשמבצעים עדכון צינור עיבוד נתונים במקום. כדי לשנות את ההגדרה הזו בצינור עיבוד נתונים פעיל, צריך לבצע עדכון אוטומטי של עצירה והחלפה, או לעצור או לרוקן את צינור עיבוד הנתונים ולהתחיל משימה חדשה בלי הדגל --update.
  • השהיה נוספת של סימן המים: כשמפעילים זמינות גבוהה של סטרימינג, סימן המים של המשימה מתקדם רק אחרי שהנתונים מעובדים ומשוכפלים בין אזורים. מכיוון שהסימן הגלוי ממתין לשכפול בין אזורים, יכול להיות שתבחי בפיגור של כמה שניות נוספות בסימן הגלוי.
  • נדרש חיוב מבוסס-משאבים: עבודות של סטרימינג בזמינות גבוהה תמיד משתמשות בחיוב מבוסס-משאבים, ולא בחיוב מבוסס-נתונים שעברו עיבוד. למרות שהחיוב על עבודות מבוסס על משאבים, אין חיובים נוספים על סטרימינג של זמינות גבוהה במהלך תקופת התצוגה המקדימה. מידע נוסף זמין בתמחור.

הפעלת זמינות גבוהה של סטרימינג

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

Java 

--dataflowServiceOptions=requires_high_availability

Python 

--dataflow_service_options=requires_high_availability

המשך 

--dataflow_service_options=requires_high_availability

gcloud

כשמריצים תבנית באמצעות הפקודה gcloud dataflow jobs run או תבנית Flex באמצעות הפקודה gcloud dataflow flex-template run, צריך לכלול את הדגלים --enable-streaming-engine ו---additional-experiments:

--enable-streaming-engine \
--additional-experiments=requires_high_availability

לדוגמה, כדי להריץ תבנית Flex עם זמינות גבוהה של סטרימינג:

gcloud dataflow flex-template run JOB_NAME \
    --project=PROJECT_ID \
    --template-file-gcs-location=TEMPLATE_LOCATION \
    --region=REGION \
    --parameters=KEY_1=VALUE_1,KEY_2=VALUE_2 \
    --enable-streaming-engine \
    --additional-experiments=requires_high_availability

מחליפים את הערכים הבאים:

  • ‫JOB_NAME: השם של משימת Dataflow
  • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud
  • ‫TEMPLATE_LOCATION: הנתיב ב-Cloud Storage לקובץ המפרט של FlexTemplate
  • ‫REGION: האזור שבו המשימה פועלת
  • ‫KEY_1=VALUE_1, KEY_2=VALUE_2: זוגות של פרמטרים של מפתח וערך לתבנית Flex

המסוף

כדי להפעיל זמינות גבוהה של סטרימינג כשמריצים תבנית או תבנית Flex במסוף Google Cloud :

  1. נכנסים לדף Jobs של Dataflow במסוף Google Cloud .

    כניסה לדף Jobs

  2. לוחצים על Create job from template.

  3. בתפריט Dataflow template, בוחרים את התבנית שרוצים להריץ.

  4. מרחיבים את הקטע פרמטרים אופציונליים.

  5. בשדה Additional experiments (ניסויים נוספים), מזינים את הערך requires_high_availability.

  6. לוחצים על הפעלת המשימה.

REST

משתמשים בשדה additionalExperiments באובייקט RuntimeEnvironment או באובייקט FlexTemplateRuntimeEnvironment כשמפעילים תבנית Flex:

{
  "additionalExperiments": ["requires_high_availability"]
}

התנהגות במקרה של יתירות כשל

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

מקורות ו-sinks

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

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

מעקב אחר זמינות גבוהה

אפשר לעקוב אחרי סטטוס הזמינות הגבוהה של העבודה ב-Cloud Monitoring באמצעות המדד dataflow.googleapis.com/job/high_availability_mode. המדד הבוליאני הזה כולל תווית status שהערך שלה הוא true לסטטוס הנוכחי של המשימה, ו-false לסטטוסים האחרים. התווית status יכולה לקבל את הערכים הבאים:

  • ‫Disabled: לא מופעלת זמינות גבוהה של סטרימינג למשימה הזו.
  • ‫Highly Available: זמינות גבוהה של סטרימינג מופעלת ומצב ה-backend משוכפל בין אזורים.
  • ‫Establishing High Availability: מצב הקצה העורפי לא משוכפל באופן זמני (לדוגמה, אחרי כשל באזור), אבל נוצרת רפליקה משנית חדשה.

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

תמחור

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

בזמינות לכלל המשתמשים (GA), השימוש ברפליקציה מחויב באותו תעריף כמו השימוש במצב הראשי. השימוש במצב נמדד כחלק מיחידות המחשוב של Streaming Engine.

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