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

‫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
גדול במיוחד 3000 750 2250

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

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

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

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

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

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

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

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

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

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

    מעבר אל Environments

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

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

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

מעבדי Airflow DAG מעבדים קובצי DAG והופכים אותם לאובייקטים של DAG. ב-Managed Airflow (דור 3), מעבדי DAG פועלים כרכיבי סביבה נפרדים, ואפשר להגדיר את הקצאת המשאבים שלהם בנפרד מהמתזמנים.

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

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

במרכז השליטה Monitoring, בקטע DAG Processors, מעיינים בתרשימים של מעבדי ה-DAG בסביבה שלכם:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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) והזיכרון הם לכל מתזמן בסביבה שלכם. לדוגמה, אם בסביבה שלכם יש שני מתזמנים, הקיבולת הכוללת היא כפולה מהמספר שצוין של 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"
      }
    }
  }
}

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

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

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

דוגמאות:

המסוף

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

gcloud

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

בדוגמה הבאה, מספר המעבדים של DAG מוגדר לשניים:

gcloud composer environments update example-environment \
    --dag-processor-count=2

Terraform

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

בדוגמה הבאה, מספר המעבדים של DAG מוגדר לשניים:

resource "google_composer_environment" "example-environment" {

  # Other environment parameters

  config {
    workloads_config {
      dag_processor {
        count = 2
      }
    }
  }
}

שינוי המעבד (CPU) והזיכרון של מעבדי DAG

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

המסוף

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

gcloud

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

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

gcloud composer environments update example-environment \
  --dag-processor-cpu=0.5 \
  --dag-processor-memory=2

Terraform

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

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

resource "google_composer_environment" "example-environment" {

  # Other environment parameters

  config {
    workloads_config {
      dag_processor {
        cpu = "0.5"
        memory_gb = "2"
      }
    }
  }
}

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

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

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

דוגמאות:

המסוף

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

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 לטפל ביותר משימות בו-זמנית, ובמקרים מסוימים לקצר את הזמן שנדרש לעיבוד המשימות האלה.

שינוי של 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) והזיכרון של שרת האינטרנט

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

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

המסוף

פועלים לפי השלבים שבקטע התאמת הפרמטרים של שרת האינטרנט כדי להגדיר את המעבד (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 חדשים בקטגוריה של הסביבה.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

לדוגמה, בסביבת 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 משימות בו-זמניות.

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

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

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

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

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

שינוי של מספר ההרצות המקבילות של DAG

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

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

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

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

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

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

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

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