התאמה אוטומטית לעומס באשכולות

המטרה: להבין איך מגדירים ומשתמשים בהתאמה אוטומטית לעומס ב-Managed Service for Apache Spark, כדי לשנות באופן אוטומטי ודינמי את מספר מכונות ה-Worker הווירטואליות באשכולות של Managed Service for Apache Spark בהתאם לדרישות של עומסי העבודה.

מה זה התאמה לעומס (autoscaling)

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

AutoscalingPolicies API של Dataproc מספק מנגנון לאוטומציה של ניהול המשאבים באשכול, ומאפשר התאמה אוטומטית לעומס של ה-worker VM באשכול. Autoscaling Policy היא הגדרה שניתן לעשות בה שימוש חוזר, שמתארת איך ה-workers באשכול שמשתמשים במדיניות ההתאמה האוטומטית לעומס צריכים לשנות את קנה המידה. היא מגדירה את גבולות ההתאמה לעומס, את התדירות ואת האגרסיביות, כדי לספק שליטה פרטנית במשאבי האשכול לאורך כל משך החיים שלו.

• ההתאמה לעומס (autoscaling) ב-Managed Service for Apache Spark משנה את הגודל של צומתי העובדים באשכול, ולא של צומתי המאסטר באשכול.
• ההתאמה לעומס (autoscaling) ב-Managed Service for Apache Spark תומכת בהתאמה לעומס אופקית (שינוי מספר הצמתים) ולא בהתאמה לעומס אנכית (שינוי סוגי המכונות).

מתי כדאי להשתמש בהתאמה אוטומטית לעומס (autoscaling)

שימוש בהתאמה אוטומטית לעומס (Automatic scaling):

באשכולות שמאחסנים נתונים בשירותים חיצוניים, כמו Cloud Storage או BigQuery

באשכולות שמעבדים הרבה משימות

כדי להגדיל את קנה המידה של אשכולות עם משימה אחת

עם מצב גמישות משופרת למשימות באצווה של Spark

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

• ‫HDFS: התאמה אוטומטית לעומס לא מיועדת להתאמה לעומס של HDFS באשכול, כי:

  1. השימוש ב-HDFS הוא לא אות להתאמה אוטומטית לעומס (autoscaling).
  2. נתוני HDFS מתארחים רק ב-primary workers. מספר ה-primary workers צריך להספיק כדי לארח את כל נתוני ה-HDFS.
  3. הוצאה משימוש של צומתי נתונים של HDFS יכולה לעכב את הסרת העובדים. צומתי נתונים מעתיקים בלוקים של HDFS לצומתי נתונים אחרים לפני ש-worker מוסר. התהליך הזה יכול להימשך כמה שעות, בהתאם לגודל הנתונים ולגורם השכפול.

• תוויות צומת YARN: התאמה אוטומטית לעומס לא תומכת בתוויות צומת YARN, וגם לא במאפיין dataproc:am.primary_only בגלל YARN-9088. ‫YARN מדווח באופן שגוי על מדדי אשכולות כשמשתמשים בתוויות של צמתים.

• Spark Structured Streaming: התאמה אוטומטית לעומס לא תומכת ב-Spark Structured Streaming (ראו התאמה אוטומטית לעומס ו-Spark Structured Streaming).

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

  משתמשים בתהליכי עבודה של Managed Service for Apache Spark כדי לתזמן קבוצת משימות באשכול ייעודי, ואז מוחקים את האשכול כשהמשימות מסתיימות. לתזמור מתקדם יותר, השתמשו ב-Cloud Composer, שמבוסס על Apache Airflow.

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

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

הפעלת התאמה אוטומטית לעומס (autoscaling)

כדי להפעיל התאמה אוטומטית לעומס (automatic scaling) באשכול:

1. יצירת מדיניות התאמה אוטומטית לעומס (autoscaling).

2. אחת משתי האפשרויות:

   1. ליצור אשכול עם התאמה אוטומטית לעומס (automatic scaling), או
   2. הפעלת התאמה אוטומטית לעומס באשכול קיים.

יצירת מדיניות התאמה אוטומטית לעומס

מסוףGoogle Cloud

כדי ליצור מדיניות התאמה אוטומטית לעומס במסוף Google Cloud :

1. בתפריט הניווט של מסוף Google Cloud , בקטע Infrastructure, נכנסים לדף Autoscaling policies של Managed Service for Apache Spark.

   מעבר אל Autoscaling policies

2. לוחצים על Create policy כדי לפתוח את הדף Create policy.
3. אופציונלי: בוחרים חלונית של המלצות למדיניות כדי לאכלס את שדות המדיניות של התאמה אוטומטית לעומס, לסוג ספציפי של משימה או ליעד התאמה לעומס.
4. מזינים את השם של מדיניות ההתאמה האוטומטית לעומס (Autoscaling policy name), בוחרים אזור (Region) וסוג אשכול (Cluster type), מגדירים את השדות YARN configuration,‏ Cooldown duration ו-Worker configuration, ולוחצים על Submit.

‫CLI של gcloud

אפשר להשתמש בפקודה gcloud dataproc autoscaling-policies import כדי ליצור מדיניות התאמה אוטומטית לעומס. היא קוראת קובץ YAML מקומי שמגדיר מדיניות התאמה אוטומטית לעומס. הפורמט והתוכן של הקובץ צריכים להתאים לאובייקטים ולשדות של ההגדרות האישיות שמוגדרים על ידי ה-API בארכיטקטורת REST של autoscalingPolicies.

הדוגמה הבאה ב-YAML מגדירה מדיניות לאשכולות רגילים של Managed Service for Apache Spark, עם כל השדות הנדרשים. הוא גם מספק את הערכים של minInstances ו-maxInstances ל-primary workers, את הערך של maxInstances ל-secondary workers, ומציין cooldownPeriod של 4 דקות (ברירת המחדל היא 2 דקות). השדה workerConfig מגדיר את ה-primary workers. בדוגמה הזו, הערכים של minInstances ו-maxInstances זהים כדי למנוע את שינוי קנה המידה של ה-primary workers.

workerConfig:
  minInstances: 10
  maxInstances: 10
secondaryWorkerConfig:
  maxInstances: 50
basicAlgorithm:
  cooldownPeriod: 4m
  yarnConfig:
    scaleUpFactor: 0.05
    scaleDownFactor: 1.0
    gracefulDecommissionTimeout: 1h

בדוגמה הבאה ב-YAML מוגדרת מדיניות לאשכולות רגילים של Managed Service for Apache Spark, עם כל השדות הנדרשים והאופציונליים של מדיניות ההתאמה לעומס.

clusterType: STANDARD
workerConfig:
  minInstances: 10
  maxInstances: 10
  weight: 1
secondaryWorkerConfig:
  minInstances: 0
  maxInstances: 100
  weight: 1
basicAlgorithm:
  cooldownPeriod: 2m
  yarnConfig:
    scaleUpFactor: 0.05
    scaleDownFactor: 1.0
    scaleUpMinWorkerFraction: 0.0
    scaleDownMinWorkerFraction: 0.0
    gracefulDecommissionTimeout: 1h

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

באשכולות עם אפס קנה מידה, אל תכללו את workerConfig.

clusterType: ZERO_SCALE
secondaryWorkerConfig:
  minInstances: 0
  maxInstances: 100
  weight: 1
basicAlgorithm:
  cooldownPeriod: 2m
  yarnConfig:
    scaleUpFactor: 0.05
    scaleDownFactor: 1.0
    scaleUpMinWorkerFraction: 0.0
    scaleDownMinWorkerFraction: 0.0
    gracefulDecommissionTimeout: 1h

מריצים את הפקודה הבאה של gcloud מטרמינל מקומי כדי ליצור את מדיניות ההתאמה האוטומטית לעומס. נותנים שם למדיניות. השם הזה יהפוך למדיניות id, ואפשר יהיה להשתמש בו בפקודות gcloud הבאות כדי להפנות למדיניות. משתמשים בדגל --source כדי לציין את הנתיב המקומי ואת שם הקובץ של קובץ ה-YAML של מדיניות ההתאמה האוטומטית לעומס שרוצים לייבא.

gcloud dataproc autoscaling-policies import policy-name \
    --source=filepath/filename.yaml \
    --region=region

‫API בארכיטקטורת REST

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

יצירת אשכול עם התאמה לעומס (autoscaling)

אחרי שיוצרים מדיניות התאמה אוטומטית לעומס (autoscaling), יוצרים אשכול שישתמש במדיניות ההתאמה האוטומטית לעומס. האשכול צריך להיות באותו אזור שבו נמצאת מדיניות ההתאמה האוטומטית לעומס.

מסוףGoogle Cloud

כדי להחיל מדיניות התאמה אוטומטית לעומס על אשכול חדש:

1. בתפריט הניווט של מסוף Google Cloud , בקטע Infrastructure, נכנסים לדף Clusters של Managed Service for Apache Spark.

   כניסה לדף Clusters

2. לוחצים על Create cluster ובוחרים באפשרות Cluster on Compute Engine כדי לפתוח את הדף Create a cluster.
3. בקטע Define your cluster shape (או Define your cluster), בקטע Worker configuration > Choose worker scaling mode, בוחרים באפשרות Autoscaling ואז בוחרים את המדיניות בשדה Policy (או מרחיבים את Additional configuration, לוחצים על Edit לצד Autoscaling, בוחרים באפשרות Autoscaling based on policy ובוחרים את המדיניות בשדה Policy).

‫CLI של gcloud

מריצים את הפקודה הבאה של gcloud ממסוף מקומי כדי ליצור אשכול עם התאמה אוטומטית לעומס. נותנים שם לאשכול ומשתמשים בדגל --autoscaling-policy כדי לציין את policy ID (שם המדיניות שציינתם כשיצרתם את המדיניות) או את המדיניות resource URI (resource name) (ראו את השדות id ו-name של AutoscalingPolicy).

gcloud dataproc clusters create cluster-name \
    --autoscaling-policy=policy id or resource URI \
    --region=region

כדי לקבל את שם המשאב המלא (או ה-URI) של מדיניות, אפשר להריץ את הפקודה הבאה של gcloud :

gcloud dataproc autoscaling-policies \
    describe policy-id \
    --region=region

‫API בארכיטקטורת REST

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

כדי לראות את AutoscalingConfig.policyUri (שם המשאב של המדיניות), מריצים את הפקודה הבאה של gcloud :

gcloud dataproc autoscaling-policies \
    describe policy-name \
    --region=region

הפעלת התאמה אוטומטית לעומס באשכול קיים

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

מסוףGoogle Cloud

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

‫CLI של gcloud

מריצים את הפקודה הבאה של gcloud מטרמינל מקומי כדי להפעיל מדיניות התאמה אוטומטית לעומס (automatic scaling) באשכול קיים. מציינים את שם האשכול ומשתמשים בדגל --autoscaling-policy כדי לציין את policy ID (שם המדיניות שציינתם כשיצרתם את המדיניות) או את המדיניות resource URI (resource name) (ראו את השדות id ו-name של AutoscalingPolicy).

gcloud dataproc clusters update cluster-name \
    --autoscaling-policy=policy id or resource URI \
    --region=region

כדי לקבל את שם המשאב המלא (או ה-URI) של מדיניות, אפשר להריץ את הפקודה הבאה של gcloud :

gcloud dataproc autoscaling-policies \
    describe policy-id \
    --region=region

‫API בארכיטקטורת REST

כדי להפעיל מדיניות התאמה אוטומטית לעומס באשכול קיים, מגדירים את AutoscalingConfig.policyUri של המדיניות ב-updateMask של בקשת clusters.patch.

כדי לראות את AutoscalingConfig.policyUri (שם המשאב של המדיניות), מריצים את הפקודה הבאה של gcloud :

gcloud dataproc autoscaling-policies \
    describe policy-name \
    --region=region

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

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

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

מסוףGoogle Cloud

אי אפשר להשבית את ההתאמה האוטומטית לעומס באשכול במסוף Google Cloud .

‫CLI של gcloud

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

gcloud dataproc clusters update cluster-name --disable-autoscaling \
    --region=region

‫API בארכיטקטורת REST

כדי להשבית את ההתאמה האוטומטית לעומס באשכול, מגדירים את AutoscalingConfig.policyUri למחרוזת ריקה ומגדירים את update_mask=config.autoscaling_config.policy_uri בבקשת clusters.patch.

• אי אפשר למחוק מדיניות שנמצאת בשימוש באשכול אחד או יותר (ראו autoscalingPolicies.delete).

איך פועלת התאמה אוטומטית לעומס (autoscaling)

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

1. הערך של מדד המשאבים בהמתנה של YARN (זיכרון בהמתנה או ליבות בהמתנה) קובע אם להגדיל או להקטין את קנה המידה. ערך שגדול מ-0 מציין שמשימות YARN ממתינות למשאבים, ויכול להיות שצריך להגדיל את המשאבים. הערך 0 מציין של-YARN יש מספיק משאבים, כך שלא נדרש צמצום אנכי בהתאם לעומס (scale down) או שינויים אחרים.

   אם המשאב בהמתנה גדול מ-0:

   $estimated\_worker\_count =$

   \[ \Biggl \lceil AVERAGE\ during\ cooldown\ period\Big(\frac{Pending + Available + Allocated + Reserved}{Resource\ per\ worker}\Big)\Biggr \rceil \]

   אם המשאב בהמתנה הוא 0:

   $estimated\_worker\_count =$

   \[ \Biggl \lceil AVERAGE\ during\ cooldown\ period\Big(\frac{Allocated + Reserved}{Resource\ per\ worker}\Big)\Biggr \rceil \]

   כברירת מחדל, החל מגרסה 2.2 של Managed Service for Apache Spark, המידרוג האוטומטי עוקב אחרי הזיכרון והליבות של YARN, כך ש-estimated_worker_count נבדק בנפרד לזיכרון ולליבות, ונבחר מספר ה-workers הגדול יותר שמתקבל. בגרסאות קודמות של התמונה, המידרוג האוטומטי עוקב רק אחרי הזיכרון של YARN, אלא אם מפעילים התאמה אוטומטית לעומס שמבוססת על ליבות כדי לעקוב גם אחרי הזיכרון וגם אחרי הליבות של YARN.

   $estimated\_worker\_count =$

   \[ max(estimated\_worker\_count\_by\_memory,\ estimated\_worker\_count\_by\_cores) \]

   \[ estimated\ \Delta worker = estimated\_worker\_count - current\_worker\_count \]

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

2. בהתאם לשינוי המשוער שנדרש במספר ה-workers, המערכת משתמשת בscaleUpFactor או בscaleDownFactor כדי לחשב את השינוי בפועל במספר ה-workers:

   if estimated Δworkers > 0:
     actual Δworkers = ROUND_UP(estimated Δworkers * scaleUpFactor)
     # examples:
     # ROUND_UP(estimated Δworkers=5 * scaleUpFactor=0.5) = 3
     # ROUND_UP(estimated Δworkers=0.8 * scaleUpFactor=0.5) = 1
   else:
     actual Δworkers = ROUND_DOWN(estimated Δworkers * scaleDownFactor)
     # examples:
     # ROUND_DOWN(estimated Δworkers=-5 * scaleDownFactor=0.5) = -2
     # ROUND_DOWN(estimated Δworkers=-0.8 * scaleDownFactor=0.5) = 0
     # ROUND_DOWN(estimated Δworkers=-1.5 * scaleDownFactor=0.5) = 0
   

   אם הערך של scaleUpFactor או scaleDownFactor הוא 1.0, ההתאמה האוטומטית לעומס תתבצע כך שהמשאב בהמתנה או המשאב הזמין יהיה 0 (ניצול מושלם).

3. אחרי שמחושב השינוי במספר ה-workers, הערך של scaleUpMinWorkerFraction ושל scaleDownMinWorkerFraction משמש כסף לקביעה אם ההתאמה האוטומטית לעומס תשנה את קנה המידה של האשכול. שבר קטן מציין שההתאמה האוטומטית לעומס צריכה להתבצע גם אם הערך של Δworkers קטן. שבר גדול יותר פירושו שההתאמה לעומס צריכה להתרחש רק כאשר Δworkers גדול.

   IF (Δworkers >  scaleUpMinWorkerFraction * current_worker_count) then scale up
   

   או

   IF (abs(Δworkers) >  scaleDownMinWorkerFraction * current_worker_count),
   THEN scale down.
   

4. אם מספר ה-workers לשינוי קנה המידה גדול מספיק כדי להפעיל את שינוי קנה המידה, ההתאמה האוטומטית לעומס משתמשת בגבולות של minInstances maxInstances של workerConfig ו-secondaryWorkerConfig ו-weight (היחס בין ה-workers הראשיים למשניים) כדי לקבוע איך לפצל את מספר ה-workers בין קבוצות המכונות של ה-workers הראשיים והמשניים. התוצאה של החישובים האלה היא השינוי הסופי של ההתאמה האוטומטית לעומס באשכול לתקופת ההתאמה לעומס.

5. בקשות להקטנה של התאמה אוטומטית לעומס (Autoscaling) יבוטלו באשכולות שנוצרו עם גרסאות אימג' 2.0.57+, ‏ 2.1.5+‎ וגרסאות אימג' מאוחרות יותר, אם:

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

   2. מספר ה-YARN workers הפעילים ("active workers") בתוספת השינוי במספר הכולל של ה-workers שהומלצו על ידי ה-autoscaler‏ (Δworkers) שווה ל-DECOMMISSIONING YARN workers או גדול ממנו ("decommissioning workers"), כפי שמוצג בנוסחה הבאה:

      IF (active workers + Δworkers ≥ active workers + decommissioning workers)
      THEN cancel the scaledown operation
      

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

   דוגמה לביטול של הקטנת התאמה לעומס (scale down) מופיעה בקטע מתי ההתאמה האוטומטית לעומס מבטלת פעולה של הקטנת התאמה לעומס?.

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

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

הימנעות מהתאמה לעומס (scaling) של ה-primary workers

‫Primary workers מריצים צומתי נתונים של HDFS, ו-secondary workers מיועדים רק למחשוב. השימוש ב-workers משניים מאפשר להגדיל את משאבי המחשוב ביעילות בלי להקצות נפח אחסון, וכך יכולות ההתאמה לעומס מהירות יותר. ב-HDFS Namenodes יכולים להיות כמה מרוצי תהליכים שגורמים להשחתה של HDFS, כך שהוצאה משימוש נתקעת ללא הגבלת זמן. כדי למנוע את הבעיה הזו, אל תשנו את קנה המידה של ה-primary workers. לדוגמה: none workerConfig: minInstances: 10 maxInstances: 10 secondaryWorkerConfig: minInstances: 0 maxInstances: 100

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

1. מגדירים את --num-workers=10 כך שיתאים לגודל של קבוצת ה-primary worker במדיניות ההתאמה האוטומטית לעומס.
2. מגדירים את --secondary-worker-type=non-preemptible כדי להגדיר ש-workers משניים לא יהיו ניתנים להפסקה לפני הזמן. (אלא אם רוצים להשתמש במכונות וירטואליות זמניות).
3. העתקת הגדרת החומרה מ-primary workers ל-secondary workers. לדוגמה, מגדירים את --secondary-worker-boot-disk-size=1000GB כך שיתאים ל---worker-boot-disk-size=1000GB.

שימוש במצב גמישות משופרת למשימות באצווה של Spark

כדאי להשתמש במצב גמישות משופרת (EFM) עם התאמה אוטומטית לעומס כדי:

‫ מאפשרים צמצום מהיר יותר של האשכול בזמן שהמשימות פועלות

מניעת שיבושים במשימות שפועלות בגלל צמצום אנכי של האשכול

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

כשהתכונה EFM מופעלת, צריך להגדיר את זמן הקצוב לתפוגה של צמצום הדרגתי של כמות השרתים במדיניות ההתאמה לעומס ל-0s. מדיניות ההתאמה לעומס (autoscaling) צריכה להתאים לעומס רק את ה-workers המשניים.

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

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

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

אם תהליך לא מסתיים במסגרת הזמן שצוינה לצמצום הדרגתי של כמות השרתים, הצומת העובד מושבת באופן מאולץ, מה שעלול לגרום לאובדן נתונים או לשיבוש בשירות. כדי למנוע את המצב הזה, הגדירו את זמן הקצוב לתפוגה של צמצום הדרגתי של כמות השרתים לערך ארוך יותר מהמשימה הארוכה ביותר שהאשכול יעבד. לדוגמה, אם אתם צופים שהמשימה הכי ארוכה תימשך שעה, הגדירו את הזמן הקצוב לתפוגה לשעה אחת לפחות (1h).

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

ההגדרה scaleUpFactor

scaleUpFactor קובע את מידת האגרסיביות של המידרוג האוטומטי באשכול. צריך לציין מספר בין 0.0 ל-1.0 כדי להגדיר את הערך החלקי של משאב בהמתנה של YARN שגורם להוספת צומת.

לדוגמה, אם יש 100 קונטיינרים בהמתנה שכל אחד מהם מבקש 512MB, אז יש 50GB של זיכרון YARN בהמתנה. אם הערך של scaleUpFactor הוא 0.5, ההתאמה האוטומטית לעומס תוסיף מספיק צמתים כדי להוסיף 25GB של זיכרון YARN. באופן דומה, אם הוא 0.1, המידרוג האוטומטי יוסיף מספיק צמתים ל-5GB. שימו לב שהערכים האלה תואמים לזיכרון של YARN, ולא לזיכרון הכולל שזמין פיזית במכונה וירטואלית.

נקודת התחלה טובה היא 0.05 למשימות MapReduce ולמשימות Spark עם הקצאה דינמית מופעלת. למשימות Spark עם מספר קבוע של מבצעים ולמשימות Tez, משתמשים ב-1.0. אם הערך של scaleUpFactor הוא 1.0, ההתאמה האוטומטית לעומס תתבצע כך שהמשאב בהמתנה או המשאב הזמין יהיה 0 (ניצול מושלם).

ההגדרה scaleDownFactor

scaleDownFactor קובע את מידת האגרסיביות של ההתאמה האוטומטית לצמצום אשכול. צריך לציין מספר בין 0.0 ל-1.0 כדי להגדיר את ערך השבר של המשאב הזמין של YARN שגורם להסרת הצומת.

ברוב האשכולות עם כמה משימות שצריך להגדיל ולהקטין לעיתים קרובות, כדאי להשאיר את הערך הזה על 1.0. כתוצאה מהצמצום ההדרגתי של כמות השרתים, פעולות של צמצום אנכי בהתאם לעומס (scale down) איטיות משמעותית מפעולות של הרחבה אנכית בהתאם לעומס (scale up). ההגדרה scaleDownFactor=1.0 קובעת קצב אגרסיבי של צמצום אנכי בהתאם לעומס, שממזער את מספר פעולות הצמצום האנכי שנדרשות כדי להגיע לגודל האשכול המתאים.

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

כדי למנוע צמצום אנכי של האשכול, למשל כשמשתמשים באשכולות זמניים או באשכולות של משימה אחת, מגדירים את הערך הזה כ-0.0.

הערה: אם מגדירים את scaleUpFactor וגם את scaleDownFactor ל-0, האשכול לא ישתנה.

ההגדרות scaleUpMinWorkerFraction ו-scaleDownMinWorkerFraction

הפרמטרים scaleUpMinWorkerFraction ו-scaleDownMinWorkerFraction משמשים עם scaleUpFactor או scaleDownFactor, וערכי ברירת המחדל שלהם הם 0.0. הם מייצגים את ערכי הסף שבהם המידרוג האוטומטי ירחיב אנכית או יצמצם אנכית את האשכול: העלייה או הירידה המינימלית בערך השבר של גודל האשכול, שנדרשת כדי להנפיק בקשה להרחבה אנכית או לצמצום אנכית.

דוגמאות: המידרוג האוטומטי לא ישלח בקשת עדכון להוספת 5 workers לאשכול של 100 צמתים, אלא אם הערך של scaleUpMinWorkerFraction קטן מ-0.05 (5%) או שווה לו. אם הערך הוא 0.1, המידרוג האוטומטי לא ישלח בקשה להגדלת האשכול. באופן דומה, אם הערך של scaleDownMinWorkerFraction הוא 0.05, המידרוג האוטומטי לא ישלח בקשה לצמצום אנכי בהתאם לעומס (scale down) אלא אם צריך להסיר לפחות 5 צמתים.

ערך ברירת המחדל 0.0 מציין שאין סף.

מומלץ מאוד להגדיר ערכי סף גבוהים יותר של scaleDownMinWorkerFraction באשכולות גדולים (יותר מ-100 צמתים) כדי להימנע מפעולות קטנות ומיותרות של שינוי קנה מידה.

בחירת תקופת צינון

הערך של cooldownPeriod מגדיר את משך הזמן שבו המידרוג האוטומטי לא ישלח בקשות לשינוי הגודל של האשכול. אתם יכולים להשתמש בו כדי להגביל את התדירות שבה ה-autoscaler משנה את גודל האשכול.

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

אם עומס העבודה שלכם רגיש לשינויים בגודל האשכול, תוכלו להגדיל את תקופת הצינון. לדוגמה, אם אתם מריצים משימת עיבוד ברצף (batch processing), אתם יכולים להגדיר תקופת צינון של 10 דקות או יותר. כדאי לנסות תקופות צינון שונות כדי למצוא את הערך שהכי מתאים לעומס העבודה שלכם.

גבולות של ספירת עובדים ומשקלי קבוצות

לכל קבוצת עובדים יש minInstances ו-maxInstances שמגדירים מגבלה קשיחה על הגודל של כל קבוצה.

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

הערה: אם מעדכנים את minInstances או את maxInstances במדיניות של התאמה אוטומטית לעומס, כך שגודל האשכול חורג מהגבולות, המידרוג האוטומטי לא יגדיל או יקטין מיד את הגודל לגבולות החדשים. במקום זאת, המידרוג האוטומטי פשוט לא יבצע מידרוג של האשכול מעבר לגבולות. מידע נוסף זמין בכתובת https://issuetracker.google.com/160640545.

זהירות: אם מגדירים את minInstances = maxInstances, האשכול לא ישתנה.

שימוש בהתאמה אוטומטית לעומס (scaling) שמבוססת על ליבות

באפליקציות שדורשות שימוש אינטנסיבי במעבד (CPU), מומלץ להשתמש ב-Dominant Resource Calculator להקצאת משאבים. זו הגדרת ברירת המחדל של YARN החל מגרסת אימג' 2.2 של Managed Service for Apache Spark. בגרסאות קודמות של Image, השירות המנוהל ל-Apache Spark מגדיר את YARN להשתמש במדדי זיכרון להקצאת משאבים, אלא אם מגדירים את המאפיין הבא כשיוצרים אשכול כדי להגדיר את YARN להשתמש ב-Dominant Resource Calculator:

capacity-scheduler:yarn.scheduler.capacity.resource-calculator=org.apache.hadoop.yarn.util.resource.DominantResourceCalculator

מדדים ויומנים של התאמה לעומס (autoscaling)

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

Cloud Monitoring

אתם יכולים להשתמש ב-Cloud Monitoring כדי:

• לצפות במדדים שמשמשים להתאמה אוטומטית לעומס
• לראות את מספר מנהלי הצמתים באשכול
• להבין למה בוצעה או לא בוצעה התאמה אוטומטית לעומס (autoscaling) של האשכול

Cloud Logging

אתם יכולים להשתמש ב-Cloud Logging כדי לצפות ביומנים של Managed Service for Apache Spark Autoscaler.

‫1) מאתרים את היומנים של האשכול.

‫2) לוחצים על dataproc.googleapis.com/autoscaler.

‫3) מרחיבים את הודעות היומן כדי לראות את השדה status. היומנים הם בפורמט JSON, פורמט קריא למכונה.

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

רקע: התאמה אוטומטית לעומס (automatic scaling) באמצעות Apache Hadoop ו-Apache Spark

בקטעים הבאים מוסבר איך פועלת ההתאמה האוטומטית לעומס (או לא פועלת) עם Hadoop YARN ו-Hadoop Mapreduce, ועם Apache Spark,‏ Spark Streaming ו-Spark Structured Streaming.

מדדי Hadoop YARN

אפשר להגדיר התאמה אוטומטית לעומס (automatic scaling) לכל מנוע הרצה שמבוסס על YARN.

הערה: "משאב" של YARN יכול להיות זיכרון YARN או ליבת YARN.

התאמה אוטומטית לעומס מתמקדת במדדים הבאים של Hadoop YARN:

1. ‫Allocated resource מתייחס למשאב הכולל של YARN שנצרך על ידי קונטיינרים שפועלים בכל האשכול. אם יש 6 קונטיינרים פעילים שיכולים להשתמש בעד יחידה אחת של משאב, יש 6 משאבים שהוקצו.

2. ‫Available resource הוא משאב YARN באשכול שלא נמצא בשימוש על ידי קונטיינרים שהוקצו. אם יש 10 יחידות של משאבים בכל Node Manager ו-6 מהם מוקצים, יש 4 משאבים זמינים. אם יש באשכול משאבים זמינים (שלא בשימוש), יכול להיות שההתאמה האוטומטית לעומס תסיר מהאשכול את ה-workers.

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

אתם יכולים לראות את המדדים האלה ב-Cloud Monitoring. כברירת מחדל, הזיכרון של YARN יהיה 0.8 * סך הזיכרון באשכול, והזיכרון שנותר שמור לשימוש של דימונים אחרים ומערכת ההפעלה, כמו מטמון הדפים. אפשר לשנות את ערך ברירת המחדל באמצעות הגדרת התצורה "yarn.nodemanager.resource.memory-mb" של YARN (ראו Apache Hadoop YARN,‏ HDFS,‏ Spark ומאפיינים קשורים).

התאמה לעומס (autoscaling) ו-Hadoop MapReduce

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

כש-mapreduce.job.reduce.slowstart.completedmaps מסתיימים (95% כברירת מחדל ב-Managed Service for Apache Spark), ‏MapReduce מוסיף לתור בקשות לקונטיינרים לכל ה-reducers, וכתוצאה מכך יש עלייה חדה נוספת בזיכרון בהמתנה.

אם משימות ה-map וה-reduce לא נמשכות כמה דקות או יותר, אל תגדירו ערך גבוה להתאמה אוטומטית לעומס (scaleUpFactor). הוספת עובדים לאשכול נמשכת לפחות דקה וחצי, לכן חשוב לוודא שיש מספיק עבודה בהמתנה כדי להעסיק את העובד החדש למשך כמה דקות. נקודת התחלה טובה היא להגדיר את scaleUpFactor ל-0.05 (5%) או ל-0.1 (10%) מהזיכרון בהמתנה.

התאמה אוטומטית לעומס ו-Spark

‫Spark מוסיף שכבת תזמון נוספת מעל YARN. באופן ספציפי, ההקצאה הדינמית של Spark Core שולחת בקשות ל-YARN למאגרים כדי להריץ את מנהלי הביצוע של Spark, ואז מתזמנת משימות של Spark בשרשורים במנהלי הביצוע האלה. באשכולות של Managed Service for Apache Spark, ההקצאה הדינמית מופעלת כברירת מחדל, כך שרכיבי ה-executor מתווספים ומוסרים לפי הצורך.

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

‫Spark מתחיל ממספר קטן של מבצעים – 2 באשכולות עם התאמה אוטומטית לעומס – וממשיך להכפיל את מספר המבצעים כל עוד יש משימות בצבר המשימות. כך אפשר להחליק את הזיכרון בהמתנה (פחות קפיצות בזיכרון בהמתנה). מומלץ להגדיר את scaleUpFactor של ההתאמה האוטומטית לעומס למספר גדול, כמו 1.0 (100%), בשביל משימות Spark.

השבתת ההקצאה הדינמית של Spark

אם אתם מריצים משימות Spark נפרדות שלא נהנות מההקצאה הדינמית של Spark, אתם יכולים להשבית את ההקצאה הדינמית של Spark על ידי הגדרת spark.dynamicAllocation.enabled=false והגדרת spark.executor.instances. אתם עדיין יכולים להשתמש בהתאמה אוטומטית לעומס כדי להגדיל ולהקטין את האשכולות בזמן שהמשימות הנפרדות של Spark פועלות.

משימות Spark עם נתונים שנשמרו במטמון

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

התאמה אוטומטית לעומס (Autoscaling) ו-Spark Streaming

1. ל-Spark Streaming יש גרסה משלו של הקצאה דינמית שמשתמשת באותות ספציפיים לסטרימינג כדי להוסיף ולהסיר מנהלי משימות. לכן, צריך להגדיר את spark.streaming.dynamicAllocation.enabled=true ולהשבית את ההקצאה הדינמית של Spark Core על ידי הגדרת spark.dynamicAllocation.enabled=false.

2. אל תשתמשו בצמצום הדרגתי של כמות השרתים (התאמה לעומס (autoscaling) gracefulDecommissionTimeout) עם משימות Spark Streaming. במקום זאת, כדי להסיר בבטחה עובדים באמצעות התאמה לעומס, מגדירים נקודות ביקורת לעמידות בפני תקלות.

לחלופין, כדי להשתמש ב-Spark Streaming בלי התאמה אוטומטית לעומס:

1. משביתים את ההקצאה הדינמית של Spark Core‏ (spark.dynamicAllocation.enabled=false), וגם
2. מגדירים את מספר ה-executors‏ (spark.executor.instances) של המשימה. מאפייני אשכול

התאמה לעומס (autoscaling) ו-Spark Structured Streaming

התאמה אוטומטית לעומס לא תואמת ל-Spark Structured Streaming, כי ב-Spark Structured Streaming אין תמיכה בהקצאה דינמית (ראו SPARK-24815: Structured Streaming should support dynamic allocation).

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

בדרך כלל, המקביליות מוגדרת או נקבעת על ידי משאבי האשכול (לדוגמה, מספר הבלוקים של HDFS נשלט על ידי מספר המשימות), אבל בהתאמה אוטומטית לעומס (automatic scaling) ההפך הוא הנכון: ההתאמה אוטומטית לעומס (automatic scaling) מגדירה את מספר ה-workers בהתאם למקביליות של המשימה. ההנחיות הבאות יעזרו לכם להגדיר את מקביליות המשימות:

• ב-Managed Service for Apache Spark, מספר ברירת המחדל של משימות MapReduce reduce מוגדר על סמך הגודל הראשוני של האשכול, אבל אתם יכולים להגדיר את mapreduce.job.reduces כדי להגביר את המקביליות של שלב ה-reduce.
• ההקבלה של Spark SQL ו-Dataframe נקבעת על ידי spark.sql.shuffle.partitions, שמוגדר כברירת מחדל ל-200.
• פונקציות ה-RDD של Spark מוגדרות כברירת מחדל ל-spark.default.parallelism, שמוגדר למספר הליבות בצומתי העובדים כשהמשימה מתחילה. עם זאת, כל פונקציות ה-RDD שיוצרות ערבובים מקבלות פרמטר למספר המחיצות, שמבטל את spark.default.parallelism.

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

הגדרות ברירת המחדל של המאפיינים Spark ו-Hadoop להתאמה לעומס (autoscaling)

לאשכולות עם התאמה אוטומטית לעומס יש ערכי ברירת מחדל של מאפייני אשכול, שעוזרים למנוע כשלים במשימות כשמסירים את ה-primary workers או כשמפקיעים את ה-secondary workers. אפשר לשנות את ערכי ברירת המחדל האלה כשיוצרים אשכול עם התאמה לעומס (ראו מאפייני אשכול).

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

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

yarn:yarn.resourcemanager.am.max-attempts=10
mapred:mapreduce.map.maxattempts=10
mapred:mapreduce.reduce.maxattempts=10
spark:spark.task.maxFailures=10
spark:spark.stage.maxConsecutiveAttempts=10

ברירות המחדל לאיפוס מוני הניסיונות החוזרים (שימושי למשימות Spark Streaming שפועלות לאורך זמן):

spark:spark.yarn.am.attemptFailuresValidityInterval=1h
spark:spark.yarn.executor.failuresValidityInterval=1h

כברירת מחדל, מנגנון ההקצאה הדינמית של Spark מתחיל מגודל קטן:

spark:spark.executor.instances=2

הערה: למרות שייתכן שיופיעו כשלים באחזור של shuffle כשמסירים את ה-primary workers או כשמבצעים הפקעה של ה-secondary workers, אל תגדילו את מספר הניסיונות החוזרים של אחזור ה-shuffle מעבר לערכי ברירת המחדל שלהם (spark.shuffle.io.maxRetries=3; spark.shuffle.io.retryWaitMs=5000 (5 שניות) למשך זמן כולל של 10 שניות לניסיונות חוזרים). הסיבה: קובצי ה-shuffle אבדו, ולכן ניסיונות חוזרים נוספים רק יבזבזו זמן.

שאלות נפוצות

בקטע הזה מופיעות שאלות ותשובות נפוצות בנושא התאמה אוטומטית לעומס.

האם אפשר להפעיל התאמה לעומס (auto-scaling) באשכולות עם זמינות גבוהה ובאשכולות עם צומת יחיד?

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

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

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

במקום לשנות ידנית את הגודל של אשכול עם התאמה אוטומטית לעומס, כדאי:

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

ניתוק המדיניות ושינוי ידני של גודל האשכול לגודל הרצוי.

האם צוות הפיתוח של Managed Service for Apache Spark יכול לאפס את סטטוס האשכול מ-ERROR בחזרה ל-RUNNING?

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

‫Managed Service for Apache Spark מגדיר את הסטטוס של אשכול ל-ERROR אם הוא לא מצליח לקבוע את הסטטוס של האשכול אחרי פעולה שנכשלה. אשכולות ב-ERROR לא מותאמים אוטומטית לעומס. היא מופיעה בדרך כלל מהסיבות הבאות:

• שגיאות שמוחזרות מ-Compute Engine API, בדרך כלל במהלך הפסקות זמניות בשירות של Compute Engine.

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

• שגיאות ב-Dataproc Control API, כמו "Task lease expired".

מוחקים ויוצרים מחדש אשכולות שהסטטוס שלהם הוא ERROR.

מתי ההתאמה האוטומטית לעומס מבטלת פעולה של הקטנת קנה המידה?

התרשים הבא ממחיש מתי ההתאמה האוטומטית לעומס (automatic scaling) תבטל פעולה של הקטנת קנה המידה (ראו גם איך פועלת ההתאמה האוטומטית לעומס (automatic scaling)).

הערות:

• באשכול מופעלת התאמה אוטומטית לעומס (scaling) שמבוססת רק על מדדי הזיכרון של YARN.
• ‫T1-T9 מייצגים את מרווחי הזמן של תקופת הצינון שבהם ה-autoscaler מעריך את מספר ה-workers (תזמון האירועים פושט).
• העמודות המצטברות מייצגות את מספר ה-YARN workers הפעילים, בתהליך הוצאה משימוש וכאלה שכבר הוצאו משימוש באשכול.
• מספר ה-workers המומלץ של ה-autoscaler (קו שחור) מבוסס על מדדי הזיכרון של YARN, מספר ה-workers הפעילים של YARN והגדרות המדיניות של ה-autoscaling (ראו איך פועל ה-autoscaling).
• האזור עם הרקע האדום מציין את התקופה שבה פועלת פעולת ההקטנה.
• האזור עם הרקע הצהוב מציין את התקופה שבה פעולת ההקטנה מתבטלת.
• האזור עם הרקע הירוק מציין את התקופה של פעולת ההרחבה.

הפעולות הבאות מתרחשות בזמנים הבאים:

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

• T2: המידרוג האוטומטי ממשיך לעקוב אחרי המדדים של האשכול. ההמלצה לצמצום לא משתנה, ופעולת הצמצום נמשכת. חלק מה-workers הוצאו משימוש, ואחרים נמצאים בתהליך הוצאה משימוש (Managed Service for Apache Spark ימחק את ה-workers שהוצאו משימוש).

• T3: הכלי להתאמה אוטומטית של קנה המידה מחשב שאפשר לצמצם עוד יותר את מספר ה-workers, אולי כי התפנה עוד זיכרון YARN. עם זאת, מכיוון שמספר ה-workers הפעילים בתוספת השינוי המומלץ במספר ה-workers לא שווה למספר ה-workers הפעילים בתוספת ה-workers שהוצאו משימוש או גדול ממנו, הקריטריונים לביטול של הקטנת ההתאמה לא מתקיימים, וה-autoscaler לא מבטל את פעולת הקטנת ההתאמה.

• T4: ‏YARN מדווח על עלייה בזיכרון בהמתנה. עם זאת, המידרוג האוטומטי לא משנה את ההמלצה שלו לגבי מספר ה-workers. כמו ב-T3, הקריטריונים לביטול הקטנת ההתאמה לא מתקיימים, והמידרוג האוטומטי לא מבטל את פעולת הקטנת ההתאמה.

• T5: הזיכרון הממתין של YARN גדל, והשינוי במספר ה-workers שמומלץ על ידי ה-autoscaler גדל. עם זאת, מכיוון שמספר ה-workers הפעילים בתוספת השינוי המומלץ במספר ה-workers קטן ממספר ה-workers הפעילים בתוספת ה-workers שיוצאים משימוש, הקריטריונים לביטול עדיין לא מתקיימים ופעולת ההקטנה לא מבוטלת.

• T6: הזיכרון הממתין של YARN גדל עוד יותר. מספר ה-workers הפעילים, בתוספת השינוי במספר ה-workers שהומלץ על ידי ה-autoscaler, גדול עכשיו ממספר ה-workers הפעילים וה-workers שהוצאו משימוש. הקריטריונים לביטול מתקיימים, והמידרוג האוטומטי מבטל את פעולת ההקטנה.

• ‫T7: המידרוג האוטומטי ממתין לסיום הביטול של פעולת ההקטנה. במהלך המרווח הזה, המידרוג האוטומטי לא מעריך את מספר ה-workers ולא ממליץ על שינוי.

• ‫T8: הסתיימה הפעולה של ביטול הקטנת קנה המידה. העובדים שמוצאים משימוש מתווספים לאשכול והופכים לפעילים. המידרוג האוטומטי מזהה שהביטול של פעולת ההקטנה הושלם, וממתין לתקופת ההערכה הבאה (T9) כדי לחשב את מספר ה-workers המומלץ.

• ‫T9: אין פעולות פעילות בזמן T9. בהתאם למדיניות של ה-autoscaler ולמדדי YARN, ה-autoscaler ממליץ על פעולת הרחבה.