מכסות ומגבלות

במאמר הזה מוסבר על מכסות ומגבלות המערכת של Dataflow.

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

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

מערכת המכסות ב-Cloud:

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

בדרך כלל, המכסות ב- Google Cloud הן ברמת הפרויקט. כלומר, השימוש במשאב מסוים בפרויקט כלשהו לא משפיע על המכסה שלכם בפרויקטים אחרים. ברמת הפרויקט ב- Google Cloud , המכסות משותפות לכל האפליקציות וכתובות ה-IP.

לסקירה כללית על מכסות ב-Cloud

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

למשאבי Dataflow יש גם מגבלות מערכת. שאי אפשר לשנות.

לשירות מנוהל של Dataflow יש את המכסות והמגבלות הבאות:

  • כל Google Cloud פרויקט יכול לשלוח עד 3,000,000 בקשות בדקה.
  • כל משימת Dataflow יכולה להשתמש בעד 2,000 מכונות של Compute Engine. אם לא מציינים אזור של worker, כל משימת סטרימינג באמצעות Streaming Engine או משימת אצווה באמצעות ארגון נתונים של Dataflow מבוסס-שירות יכולה להשתמש ב-4,000 מכונות לכל היותר של Compute Engine.
  • בכל פרויקט אפשר להריץ כברירת מחדל עד 25 משימות Dataflow בו-זמנית. Google Cloud
  • לכל עובד של Dataflow יש מגבלה מקסימלית על מספר היומנים שהוא יכול להפיק במרווח זמן מסוים. הגבול המדויק מופיע במסמכי התיעוד בנושא רישום ביומן.
  • אם תפעילו את האפשרות להגדרת מכסות ברמת הארגון, כל ארגון יוכל להריץ לכל היותר 125 משימות Dataflow בו-זמנית כברירת מחדל.
  • כל משתמש יכול לשלוח עד 15,000 בקשות מעקב בדקה.
  • כל משתמש יכול לשלוח עד 60 בקשות ליצירת משימות בדקה.
  • כל משתמש יכול לשלוח עד 60 בקשות לתבניות משרות בדקה.
  • כל משתמש יכול לשלוח עד 60 בקשות לעדכון משרה בדקה.
  • לכל Google Cloud פרויקט מוקצים משבצות ערבוב בכל אזור:
    • ‫asia-east1: 48 משבצות
    • ‫asia-northeast1: ‏ 24 משבצות
    • ‫asia-northeast3: ‏ 32 משבצות
    • ‫asia-south1: ‏ 64 משבצות
    • ‫asia-southeast1: 64 משבצות
    • ‫australia-southeast1: 24 משבצות
    • ‫europe-west1: 640 משבצות
    • ‫europe-west2: 32 משבצות
    • ‫europe-west3: ‏ 40 חריצים
    • ‫europe-west4: 640 משבצות
    • ‫northamerica-northeast1: 512 משבצות
    • ‫us-central1: 640 משבצות
    • ‫us-east1: 640 משבצות
    • ‫us-east4: ‏ 64 משבצות
    • ‫us-west1: 384 חריצים
    • ‫us-west2: 24 חריצים
    • ‫us-west3: 24 חריצים
    • אחרים: 16 משבצות
    16 משבצות מספיקות כדי לערבב בו-זמנית כ-10 TB של נתונים.
  • משימות אצווה של Dataflow יבוטלו אחרי 10 ימים.

מכסות ב-Compute Engine

כשמריצים את צינור הנתונים בשירות Dataflow,‏ Dataflow יוצר מכונות של Compute Engine כדי להריץ את קוד צינור הנתונים.

המכסה של Compute Engine מוגדרת לכל אזור. בודקים את המכסה של Compute Engine בפרויקט ומבקשים את השינויים הבאים אם צריך:

  • ‫CPU: באזורים הבאים, סוגי המכונות שמוגדרים כברירת מחדל ל-Dataflow הם n1-standard-1 לעיבוד באצווה, n1-standard-2 לעבודות שמשתמשות ב-Streaming Engine,‏ n1-standard-4 לעבודות סטרימינג שלא משתמשות ב-Streaming Engine ו-n1-standard-2 לעבודות שמשתמשות בתזמון גמיש של משאבים (FlexRS). ‫FlexRS משתמש ב-90% מכונות Preemptible VM וב-10% מכונות רגילות.
    • asia-east1
    • asia-east2
    • asia-northeast1
    • asia-northeast2
    • asia-northeast3
    • asia-south1
    • asia-south2
    • asia-southeast1
    • asia-southeast2
    • australia-southeast1
    • australia-southeast2
    • europe-central2
    • europe-north1
    • europe-west1
    • europe-west2
    • europe-west3
    • europe-west4
    • europe-west5
    • europe-west6
    • northamerica-northeast1
    • northamerica-northeast2
    • southamerica-east1
    • us-central1
    • us-central2
    • us-east1
    • us-east4
    • us-west1
    • us-west2
    • us-west3
    • us-west4

    באזורים אחרים, סוגי המכונות שמוגדרים כברירת מחדל הם e2-standard-2 לעיבוד באצווה, e2-standard-2 לעבודות שמשתמשות ב-Streaming Engine,‏ e2-standard-4 לעבודות סטרימינג שלא משתמשות ב-Streaming Engine ו-e2-standard-2 לעבודות שמשתמשות ב-FlexRS.

    ‫Compute Engine מחשב את מספר המעבדים על ידי סיכום של ספירת המעבדים הכוללת של כל מופע. לדוגמה, הפעלת 10 מופעים של n1-standard-4 נחשבת ל-40 ליבות CPU. במאמר סוגי מכונות ב-Compute Engine מפורט מיפוי של סוגי מכונות למספר ליבות ה-CPU.

  • כתובות IP בשימוש: מספר כתובות ה-IP בשימוש בפרויקט צריך להיות מספיק כדי להכיל את מספר המכונות הרצוי. כדי להשתמש ב-10 מכונות Compute Engine, תצטרכו 10 כתובות IP בשימוש.
  • דיסק אחסון מתמיד:‏ Dataflow מצרף דיסק אחסון מתמיד לכל מופע.
    • גודל ברירת המחדל של הדיסק הוא 250GB עבור אצוות ו-400GB עבור צינורות סטרימינג. ל-10 מופעים, כברירת מחדל צריך 2,500GB של דיסק מתמיד למשימת אצווה.
    • גודל ברירת המחדל של הדיסק הוא 25 GB עבור צינורות (pipelines) של אצווה ארגון נתונים של Dataflow.
    • גודל ברירת המחדל של הדיסק הוא 30 GB לצינורות סטרימינג של Streaming Engine.
    • שירות Dataflow מוגבל כרגע ל-15 דיסקים קבועים לכל worker instance כשמריצים משימת סטרימינג. כל דיסק אחסון מתמיד הוא מקומי למכונה וירטואלית ספציפית של Compute Engine. הקצאת המשאבים המינימלית היא יחס של 1:1 בין העובדים לדיסקים.
    • השימוש ב-Compute Engine מבוסס על המספר הממוצע של העובדים, ואילו השימוש ב-Persistent Disk מבוסס על הערך המדויק של --maxNumWorkers. דיסקים של אחסון מתמיד מוקצים מחדש כך שלכל worker יש מספר שווה של דיסקים מצורפים.
  • קבוצות מופעי מכונה מנוהלים (MIG) אזוריות:‏ Dataflow פורס את מופעי Compute Engine שלכם כקבוצת מופעי מכונה מנוהלים אזורית. תצטרכו לוודא שיש לכם את המכסה הבאה שקשורה לכך:
    • קבוצת מופעים אחת לכל משימת Dataflow
    • תבנית מכונה אחת לכל משימת Dataflow
    • קבוצת מופעי מכונה מנוהלים אזורית אחת לכל משימת Dataflow
  • אם קבוצות של מופעים מנוהלים חסרות למשימת סטרימינג במשך יותר מ-7 ימים, המשימה מבוטלת.
  • אם קבוצות של מופעים מנוהלים חסרות לעבודת אצווה במשך יותר משעה, העבודה מבוטלת.

מכסות נוספות

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

  1. ‫Pub/Sub: אם אתם משתמשים ב-Pub/Sub, יכול להיות שתצטרכו מכסה נוספת. כשמתכננים את המכסה, חשוב לזכור שעיבוד של הודעה אחת מ-Pub/Sub כולל 3 פעולות. אם אתם משתמשים בחותמות זמן בהתאמה אישית, כדאי להכפיל את מספר הפעולות הצפוי, כי Dataflow ייצור מינוי נפרד כדי לעקוב אחרי חותמות זמן בהתאמה אישית.
  2. ‫BigQuery: אם אתם משתמשים ב-Streaming API ל-BigQuery, חלים מגבלות מכסה והגבלות אחרות.

חיפוש והגדלה של מכסות

כדי לבדוק את השימוש הנוכחי במכסה שספציפית ל-Dataflow:

  1. במסוף Google Cloud , נכנסים אל APIs & services.
    עוברים אל API & Services
  2. כדי לבדוק את ניצול המכסה הנוכחי של ערוצים אקראיים, בכרטיסייה Quotas, מוצאים את השורה Shuffle slots בטבלה ובעמודה Usage Chart לוחצים על Show usage chart.

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

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

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

שירות Dataflow גם מפעיל רכיבים שונים של Google Cloud, כמו BigQuery,‏ Cloud Storage,‏ Pub/Sub ו-Compute Engine. השירותים האלה (ושירותים אחרים של Google Cloud ) משתמשים במכסות כדי להגביל את המספר המקסימלי של משאבים שאפשר להשתמש בהם בפרויקט. כשמשתמשים ב-Dataflow, יכול להיות שיהיה צורך לשנות את הגדרות המכסה של השירותים האלה.

‫Dataflow Prime

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

מגבלות

בקטע הזה מתוארות מגבלות מעשיות של סביבת ייצור ב-Dataflow.

הגבלה סכום
המספר המקסימלי של עובדים לכל צינור. 2,000
הגודל המקסימלי של בקשה ליצירת משימה. יכול להיות שתיאורי צינורות עם הרבה שלבים ושמות ארוכים מאוד יגיעו למגבלה הזו. ‫10 MB
הגודל המקסימלי של בקשה להפעלת תבנית. ‫1 MB
המספר המקסימלי של רסיסי קלט צדדי. 20,000
הגודל המקסימלי של רכיב בודד (אלא אם חלים תנאים מחמירים יותר, למשל Streaming Engine). ‫2 GB
הגודל המקסימלי של מפתח בצינורות להעברת נתונים באצווה. ‫1.5 MB
המספר המקסימלי של רשומות ביומן בפרק זמן נתון, לכל עובד. ‫15,000 הודעות כל 30 שניות
המספר המקסימלי של מדדים מותאמים אישית לכל פרויקט. 100
משך הזמן שבו ההמלצות יישמרו. 30 ימים
מגבלות של מנוע סטרימינג סכום
הגודל המקסימלי בבייטים של הודעות Pub/Sub. ‫7 MB
הגודל המקסימלי של ערך של רכיב יחיד. ‫80 MB
הגודל המקסימלי של מקש גדול. מפתחות בגודל של יותר מ-64 KB גורמים לירידה בביצועים. ‫2 MB
הגודל המקסימלי של קלט צדדי. ‫80 MB
האורך המקסימלי של תגי מצב שמשמשים את TagValue ו-TagBag. ‫64 KB