אופטימיזציה של הביצועים והעלויות של הסביבה

‫Managed Airflow (דור 3) | Managed Airflow (דור 2) | Managed Airflow (דור 1 מדור קודם)

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

מידע על תהליך האופטימיזציה

שינויים בפרמטרים של הסביבה יכולים להשפיע על היבטים רבים בביצועים שלה. מומלץ לבצע אופטימיזציה של הסביבה שלכם באיטרציות:

  1. מתחילים עם הגדרות קבועות מראש של סביבה.
  2. מריצים את ה-DAG.
  3. מעקב אחרי ביצועי הסביבה.
  4. משנים את הפרמטרים של הביצועים וההיקף של הסביבה, ואז חוזרים על השלב הקודם.

התחלה עם הגדרות קבועות מראש של סביבה

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

מומלץ להתחיל עם אחת מההגדרות הקבועות מראש, על סמך ההערכות הבאות:

  • המספר הכולל של DAG שתכננתם לפרוס בסביבה
  • מספר מקסימלי של הפעלות DAG בו-זמניות
  • מספר מקסימלי של משימות בו-זמניות

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

הגדרה קבועה מראש מומלצת סך כל תרשימי ה-DAG מספר מקסימלי של הפעלות DAG בו-זמניות מספר מקסימלי של משימות בו-זמניות
קטן 50 15 18
בינוני 250 60 100
גדול 1000 250 400

לדוגמה, סביבה צריכה להריץ 40 קובצי DAG. כל ה-DAGs צריכים לפעול באותו הזמן, וכל אחד מהם צריך לכלול משימה פעילה אחת. במקרה כזה, הסביבה תשתמש בהגדרה קבועה מראש של Medium, כי המספר המקסימלי של הרצות DAG מקבילות ומשימות חורג מהאומדנים המומלצים להגדרה קבועה מראש של Small.

הפעלת תרשימי DAG

אחרי שיוצרים את הסביבה, מעלים אליה את קובצי ה-DAG. מריצים את ה-DAG וצופים בביצועים של הסביבה.

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

מעקב אחר ביצועי הסביבה

בקטע הזה נתמקד בהיבטים הנפוצים ביותר של קיבולת וביצועים ב-Managed Airflow. מומלץ לפעול לפי השלבים במדריך הזה, כי קודם כל מוסבר על השיקולים הנפוצים ביותר שמשפיעים על הביצועים.

מעבר ללוח הבקרה של Monitoring

אפשר לעקוב אחרי מדדי הביצועים של הסביבה בלוח הבקרה של המעקב של הסביבה.

כדי לעבור אל לוח הבקרה של המעקב בסביבה שלכם:

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

    מעבר אל Environments

  2. לוחצים על שם הסביבה.

  3. עוברים לכרטיסייה מעקב.

מעקב אחרי מדדי המעבד (CPU) והזיכרון של מתזמן המשימות

מדדי ה-CPU והזיכרון של מתזמן Airflow עוזרים לכם לבדוק אם הביצועים של המתזמן הם צוואר בקבוק בביצועים הכוללים של Airflow.

גרפים של מתזמני Ariflow
איור 1. גרפים של מתזמני Airflow (לחצו כדי להגדיל)

במרכז השליטה Monitoring, בקטע Schedulers, אפשר לראות את הגרפים של מתזמני Airflow בסביבה שלכם:

  • סה"כ שימוש במעבד של מתזמני המשימות
  • סך השימוש בזיכרון של מתזמני הפעולות

משנים בהתאם לתצפיות:

מעקב אחרי זמן הניתוח הכולל של כל קובצי ה-DAG

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

תרשים של זמן הניתוח הכולל של DAG
איור 2. גרף של זמן הניתוח של DAG (לחצו כדי להגדיל)

בקטע DAG Statistics (נתונים סטטיסטיים של DAG) בלוח הבקרה Monitoring (מעקב), בוחנים את הגרפים של זמן הניתוח הכולל של DAG.

אם המספר הזה גבוה מ-10 שניות בערך, יכול להיות שהמתזמנים עמוסים מדי בניתוח של DAG ולא יכולים להריץ DAG בצורה יעילה. תדירות ברירת המחדל של ניתוח DAG ב-Airflow היא 30 שניות. אם זמן הניתוח של DAG חורג מהסף הזה, מחזורי הניתוח מתחילים לחפוף, מה שגורם לניצול מלא של קיבולת המתזמן.

בהתאם לתצפיות שלכם, יכול להיות שתרצו:

מעקב אחרי הוצאות של פודים של worker

הוצאה של Pod יכולה לקרות כש-Pod מסוים באשכול של הסביבה מגיע למגבלות המשאבים שלו.

תרשים של הוצאת pods של Worker
איור 3. תרשים שמציג את הפינויים של פודים של עובדים (לחיצה להגדלה)

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

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

בקטע Workers בלוח הבקרה Monitoring, בודקים את התרשימים Worker Pods evictions בסביבה שלכם.

בתרשים Total workers memory usage מוצגת תמונה כוללת של הסביבה. יכול להיות שעובד יחיד עדיין יחרוג ממגבלת הזיכרון, גם אם ניצול הזיכרון תקין ברמת הסביבה.

בהתאם לתצפיות שלכם, יכול להיות שתרצו:

מעקב אחרי עובדים פעילים

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

גרפים של עובדים פעילים ומשימות בהמתנה
איור 4. גרפים של עובדים פעילים ומשימות בהמתנה (לחיצה להגדלה)

במרכז הבקרה 'מעקב', בקטע Workers, אפשר לראות גרפים של מספר העובדים הפעילים ומספר המשימות בתור:

  • עובדים פעילים
  • משימות ב-Airflow

משנים בהתאם לתצפיות:

מעקב אחר השימוש במעבד (CPU) ובזיכרון של העובדים

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

תרשימים של מעבד (CPU) וזיכרון של עובדים
איור 5. תרשימים של מעבד וזיכרון של עובדים (לחיצה להגדלה) )

בלוח הבקרה Monitoring, בקטע Workers, אפשר לראות תרשימים של השימוש במעבד ובזיכרון על ידי עובדי Airflow:

  • סה"כ השימוש במעבד על ידי העובדים
  • סך השימוש בזיכרון של העובדים

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

משנים בהתאם לתצפיות:

מעקב אחרי משימות שפועלות ומשימות בתור

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

תרשים שמציג משימות שפועלות ומשימות שנמצאות בתור
איור 6. תרשים שמציג משימות שפועלות ומשימות שנמצאות בתור (לחיצה להגדלה) (click to enlarge)

בקטע Workers בלוח הבקרה Monitoring, בודקים את התרשים Airflow tasks של הסביבה.

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

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

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

כדי לפתור את שתי הבעיות:

מעקב אחרי השימוש במעבד (CPU) ובזיכרון של מסד הנתונים

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

גרפים של מעבד (CPU) וזיכרון של מסד נתונים
איור 7. תרשימים של מעבד וזיכרון של מסד נתונים (אפשר ללחוץ כדי להגדיל)

בלוח הבקרה Monitoring, בקטע SQL Database, בודקים את הגרפים של השימוש במעבד ובשימוש בזיכרון במסד הנתונים של Airflow:

  • שימוש במעבד של מסד הנתונים
  • השימוש בזיכרון של מסד הנתונים

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

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

מעקב אחרי זמן האחזור של תזמון המשימות

אם זמן האחזור בין המשימות חורג מהרמות הצפויות (לדוגמה, 20 שניות או יותר), יכול להיות שהסביבה לא יכולה להתמודד עם עומס המשימות שנוצר על ידי הפעלות DAG.

גרף של זמן האחזור של המשימה (ממשק המשתמש של Airflow)
איור 8. גרף של זמן האחזור של המשימה, ממשק המשתמש של Airflow (לחיצה להגדלה) )

אפשר לראות את תרשים השהייה בתזמון המשימות בממשק המשתמש של Airflow בסביבה שלכם.

בדוגמה הזו, העיכובים (2.5 ו-3.5 שניות) נמצאים בטווח המקובל, אבל חביון גבוה משמעותית עשוי להעיד על:

מעקב אחרי המעבד (CPU) והזיכרון של שרת האינטרנט

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

תרשימים של מעבד (CPU) וזיכרון של שרת אינטרנט
איור 9. תרשימים של מעבד וזיכרון של שרת אינטרנט (לחצו כדי להגדיל)

בקטע Web server בלוח הבקרה Monitoring, בודקים את הגרפים של שרת האינטרנט של Airflow:

  • שימוש במעבד בשרת האינטרנט
  • שימוש בזיכרון של שרת האינטרנט

על סמך התצפיות שלך:

שינוי הפרמטרים של היקף וביצועים בסביבה

שינוי מספר המתזמנים

שינוי מספר המתזמנים משפר את הקיבולת של המתזמן ואת העמידות של התזמון ב-Airflow.

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

אם אתם צריכים לתזמן ולנתח DAG מהר יותר:

TODO: C2: Airflow 2 options Dag processor and scheduler together -- one section C3: Airflow 2 options + Airflow 3 options for scheduler; Airflow 2 options + Airflow 3 options for DAG processor; -- two sections

דוגמאות:

המסוף

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

gcloud

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

בדוגמה הבאה, מספר המתזמנים מוגדר כשניים:

gcloud composer environments update example-environment \
    --scheduler-count=2

Terraform

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

בדוגמה הבאה, מספר המתזמנים מוגדר כשניים:

resource "google_composer_environment" "example-environment" {

  # Other environment parameters

  config {
    workloads_config {
      scheduler {
        count = 2
      }
    }
  }
}

שינוי המעבד והזיכרון של מתזמני הפעולות

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

המסוף

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

gcloud

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

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

gcloud composer environments update example-environment \
  --scheduler-cpu=0.5 \
  --scheduler-memory=4

Terraform

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

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

resource "google_composer_environment" "example-environment" {

  # Other environment parameters

  config {
    workloads_config {
      scheduler {
        cpu = "0.5"
        memory_gb = "4"
      }
    }
  }
}

שינוי המספר המקסימלי של עובדים

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

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

דוגמאות:

המסוף

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

gcloud

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

בדוגמה הבאה, המספר המקסימלי של העובדים מוגדר ל-6:

gcloud composer environments update example-environment \
    --max-workers=6

Terraform

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

בדוגמה הבאה, המספר המקסימלי של מתזמנים מוגדר ל-6:

resource "google_composer_environment" "example-environment" {

  # Other environment parameters

  config {
    workloads_config {
      worker {
        max_count = "6"
      }
    }
  }
}

שינוי המעבד והזיכרון של העובד

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

  • הגדלת הזיכרון של העובדים מאפשרת להם לטפל ביותר משימות בו-זמנית או לטפל במשימות שדורשות הרבה זיכרון. יכול להיות שהיא תפתור את הבעיה של הוצאת פודים של עובדים.

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

  • הגדלת המעבד (CPU) של ה-worker מאפשרת ל-workers לטפל ביותר משימות בו-זמנית, ובמקרים מסוימים לקצר את הזמן שנדרש לעיבוד המשימות האלה.

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

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

המסוף

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

gcloud

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

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

gcloud composer environments update example-environment \
  --worker-memory=4 \
  --worker-cpu=2

Terraform

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

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

resource "google_composer_environment" "example-environment" {

  # Other environment parameters

  config {
    workloads_config {
      worker {
        cpu = "2"
        memory_gb = "4"
      }
    }
  }
}

שינוי המעבד והזיכרון של שרת האינטרנט

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

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

המסוף

פועלים לפי השלבים שבקטע התאמת הפרמטרים של שרת האינטרנט כדי להגדיר את המעבד (CPU) והזיכרון של שרת האינטרנט.

gcloud

פועלים לפי השלבים שבקטע התאמת הפרמטרים של שרת האינטרנט כדי להגדיר את המעבד (CPU) והזיכרון של שרת האינטרנט.

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

gcloud composer environments update example-environment \
    --web-server-cpu=2 \
    --web-server-memory=4

Terraform

פועלים לפי השלבים שבקטע התאמת הפרמטרים של שרת האינטרנט כדי להגדיר את המעבד (CPU) והזיכרון של שרת האינטרנט.

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

resource "google_composer_environment" "example-environment" {

  # Other environment parameters

  config {
    workloads_config {
      web_server {
        cpu = "2"
        memory_gb = "4"
      }
    }
  }
}

שינוי גודל הסביבה

שינוי הגודל של הסביבה משנה את הקיבולת של רכיבי ה-backend של Managed Airflow, כמו מסד הנתונים של Airflow והתור של Airflow.

  • אם מדדי השימוש במסד הנתונים מצביעים על חוסר ניצול משמעותי, כדאי לשקול לשנות את גודל הסביבה לגודל קטן יותר (לדוגמה, מ'גדול' ל'בינוני' או מ'בינוני' ל'קטן').

  • אם אתם רואים שימוש גבוה במסד הנתונים של Airflow, כדאי להגדיל את גודל הסביבה.

המסוף

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

gcloud

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

בדוגמה הבאה משנים את גודל הסביבה ל-Medium.

gcloud composer environments update example-environment \
    --environment-size=medium

Terraform

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

בדוגמה הבאה משנים את גודל הסביבה ל-Medium.

resource "google_composer_environment" "example-environment" {

  # Other environment parameters

  config {
    environment_size = "medium"
  }
}

שינוי המרווח של רשימת הספרייה ב-DAG

הגדלת המרווח בין רישומי הספרייה של DAG מפחיתה את העומס על מתזמן המשימות שקשור לגילוי של DAG חדשים בדלי של הסביבה.

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

כדי לשנות את הפרמטר הזה, צריך להגדיר ערך חדש לאפשרות ההגדרה הבאה ב-Airflow:

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

שינוי מרווח הזמן של ניתוח קובץ ה-DAG

הגדלת מרווח הזמן לניתוח קובץ ה-DAG מצמצמת את העומס על מתזמן המשימות שמשויך לניתוח הרציף של קובצי DAG בתיקיית ה-DAG.

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

כדי לשנות את הפרמטר הזה, צריך להגדיר ערך חדש לאפשרות ההגדרה הבאה ב-Airflow:

קטע מפתח ערך הערות
scheduler min_file_process_interval ערך חדש לפרק הזמן של ניתוח ה-DAG ערך ברירת המחדל, בשניות, הוא 30.

בו-זמניות (concurrency) של עובדים

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

  • מספר העובדים המינימלי ב-Airflow
  • הפרמטר [celery]worker_concurrency

ערכי ברירת המחדל שסופקו על ידי Managed Airflow הם אופטימליים לרוב תרחישי השימוש, אבל יכול להיות שהסביבה שלכם תרוויח מהתאמות מותאמות אישית.

שיקולי ביצועים לגבי בו-זמניות של עובדים

הפרמטר [celery]worker_concurrency מגדיר את מספר המשימות ש-worker יחיד יכול לקחת מתור המשימות. מהירות ביצוע המשימות תלויה בכמה גורמים, כמו המעבד (CPU) של העובד, הזיכרון וסוג העבודה עצמה.

התאמה אוטומטית לעומס (autoscaling) של קובצי שירות

‫Managed Service for Apache Airflow מנטר את תור המשימות ויוצר עובדים נוספים כדי לבצע את המשימות שממתינות. הגדרה של [celery]worker_concurrency לערך גבוה פירושה שכל worker יכול לקבל הרבה משימות, ולכן בנסיבות מסוימות התור לא יתמלא אף פעם, וההתאמה האוטומטית לעומס לא תופעל.

לדוגמה, בסביבת Managed Service for Apache Airflow עם שני עובדי Airflow, אם [celery]worker_concurrency מוגדר ל-100 ויש 200 משימות בתור, כל עובד יבחר 100 משימות. הפעולה הזו משאירה את התור ריק ולא מפעילה שינוי גודל אוטומטי. אם המשימות האלה נמשכות זמן רב, יכול להיות שיהיו בעיות בביצועים.

אבל אם המשימות קטנות ומהירות לביצוע, ערך גבוה בהגדרה [celery]worker_concurrency עלול להוביל להרחבה מהירה מדי. לדוגמה, אם בסביבה הזו יש 300 משימות בתור,‏ Managed Service for Apache Airflow יתחיל ליצור עובדים חדשים. אבל אם 200 המשימות הראשונות מסתיימות לפני שהעובדים החדשים מוכנים, עובד קיים יכול לבצע אותן. התוצאה הסופית היא שהתאמה אוטומטית לעומס יוצרת עובדים חדשים, אבל אין להם משימות.

ההתאמה של [celery]worker_concurrency למקרים מיוחדים צריכה להתבסס על זמני הביצוע המקסימליים של המשימות ומספרי התורים:

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

שינוי מספר העובדים בו-זמנית

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

לדוגמה, Worker עם 0.5 CPU יכול בדרך כלל לטפל ב-6 משימות בו-זמניות, וסביבה עם שלושה Workers כאלה יכולה לטפל בעד 18 משימות בו-זמניות.

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

  • כדאי להקטין את הפרמטר הזה אם מתקבלות הודעות על הוצאת pods; כך יצטמצם מספר המשימות שכל worker מנסה לעבד. אפשרות נוספת היא להגדיל את הזיכרון של העובד.

כברירת מחדל, בו-זמניות (concurrency) של worker מוגדרת על סמך מספר המופעים של משימות מקבילות קלות משקל ש-worker יכול להכיל. כלומר, הערך שלו תלוי במגבלות של משאבי העובדים. ערך המקבילות של העובדים לא תלוי במספר העובדים בסביבה שלכם.

כדי לשנות את הפרמטר הזה, צריך להגדיר ערך חדש לאפשרות ההגדרה הבאה ב-Airflow:

קטע מפתח ערך
celery worker_concurrency ערך חדש של מספר העובדים המקבילים

שינוי של מקביליות DAG

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

כדי לשנות את הפרמטר הזה, צריך להגדיר ערך חדש לאפשרות ההגדרה הבאה ב-Airflow:

קטע מפתח ערך הערות
core max_active_tasks_per_dag ערך חדש של מקבילות DAG ערך ברירת המחדל הוא 16

הגדלת מספר ההרצות הפעילות המקסימלי לכל DAG

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

כדי לשנות את הפרמטר הזה, צריך להגדיר ערך חדש לאפשרות ההגדרה הבאה ב-Airflow:

קטע מפתח ערך הערות
core max_active_runs_per_dag ערך חדש למספר הריצות הפעילות המקסימלי לכל DAG ערך ברירת המחדל הוא 25

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