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

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

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

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

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

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

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

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

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

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

הגדלת קלאסטרים של משימה יחידה

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

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

• ‫HDFS: המידרוג האוטומטי לא מיועד לשינוי גודל של HDFS באשכול, כי:

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

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

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

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

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

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

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

הפעלת שינוי גודל אוטומטי

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

1. יצירת מדיניות של שינוי גודל אוטומטי

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

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

יצירת מדיניות של שינוי גודל אוטומטי

מסוףGoogle Cloud

כדי ליצור מדיניות של שינוי גודל אוטומטי, בוחרים באפשרות CREATE POLICY (יצירת מדיניות) בדף Autoscaling policies (מדיניות של שינוי גודל אוטומטי) של Managed Service for Apache Spark באמצעות מסוף Google Cloud . בדף Create policy (יצירת מדיניות), אפשר לבחור בחלונית המלצות למדיניות כדי לאכלס את השדות של מדיניות שינוי הגודל האוטומטי עבור סוג העבודה הספציפי או יעד שינוי גודל.

‫CLI של gcloud

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

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

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 מהטרמינל המקומי או מ-Cloud Shell כדי ליצור את מדיניות שינוי הגודל האוטומטי. מזינים שם למדיניות. השם הזה יהפוך לid של המדיניות, ותוכלו להשתמש בו בפקודות gcloud מאוחרות יותר כדי להפנות למדיניות. משתמשים בדגל --source כדי לציין את הנתיב המקומי ואת שם הקובץ של קובץ ה-YAML של מדיניות שינוי הגודל האוטומטי לייבוא.

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

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

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

יצירת אשכול עם שינוי גודל אוטומטי

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

מסוףGoogle Cloud

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

1. פותחים את הדף Managed Service for Apache Spark Create cluster.
2. בקטע Define your cluster, בקטע Choose worker scaling mode, בוחרים באפשרות Autoscaling, ואז בוחרים את המדיניות בשדה Policy.

‫CLI של gcloud

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

‫

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

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

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

מסוףGoogle Cloud

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

‫CLI של gcloud

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

‫

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 gcloud dataproc autoscaling-policies \
    describe policy-name \
    --region=region

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

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

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

מסוףGoogle Cloud

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

‫CLI של gcloud

כדי להשבית את שינוי הגודל האוטומטי באשכול, מריצים את הפקודה gcloud מהטרמינל המקומי או מ-Cloud Shell.

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).

איך מתבצעת התאמת גודל אוטומטית

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

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

   אם המשאב בהמתנה הוא > 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 מוערך בנפרד עבור הזיכרון והליבות, ונבחר מספר העובדים הגדול יותר שמתקבל. בגרסאות קודמות של תמונות, המערכת להתאמה אוטומטית של נפח האחסון עוקבת רק אחרי הזיכרון של 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. בהתאם לשינוי המשוער שנדרש במספר העובדים, התכונה 'שינוי גודל אוטומטי' משתמשת בפונקציה scaleUpFactor או scaleDownFactor כדי לחשב את השינוי בפועל במספר העובדים:

   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
   

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

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

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

   או

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

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

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

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

   2. מספר העובדים הפעילים ב-YARN ('עובדים פעילים') בתוספת השינוי במספר הכולל של העובדים שמומלץ על ידי הכלי לשינוי גודל אוטומטי (Δworkers) גדול או שווה ל-DECOMMISSIONING עובדים ב-YARN ('עובדים שיצאו משימוש'), כמו שמוצג בנוסחה הבאה:

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

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

   דוגמה לביטול של הקטנת הקיבולת מופיעה במאמר מתי מתבצע ביטול של פעולת הקטנת קיבולת על ידי שינוי גודל אוטומטי?.

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

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

הימנעות מהרחבת מספר העובדים הראשיים

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

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

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

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

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

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

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

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

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

בחירת פסק זמן להוצאה משירות בצורה מסודרת

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

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

אם תהליך לא מסתיים במסגרת הזמן שמוגדר להוצאה משימוש מסודרת, צומת העובד נסגר בכוח, וזה עלול לגרום לאובדן נתונים או לשיבוש בשירות. כדי להימנע מהאפשרות הזו, צריך להגדיר את הזמן הקצוב לתפוגה של השבתה הדרגתית לערך ארוך יותר מהזמן של העבודה הכי ארוכה שהאשכול יעבד. לדוגמה, אם אתם צופים שהעבודה הכי ארוכה תימשך שעה, צריך להגדיר את הזמן הקצוב לתפוגה לשעה לפחות (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. ערך של 1.0 ב-scaleUpFactor מציין שהתאמה אוטומטית לעומס תתבצע כך שהמשאב בהמתנה או הזמין יהיה 0 (ניצול מושלם).

הגדרה scaleDownFactor

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

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

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

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

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

הגדרת scaleUpMinWorkerFraction ו-scaleDownMinWorkerFraction

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

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

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

מומלץ מאוד להגדיר ערך גבוה יותר של scaleDownMinWorkerFractionthresholds באשכולות גדולים (מעל 100 צמתים) כדי להימנע מפעולות קנה מידה קטנות ולא נחוצות.

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

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

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

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

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

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

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

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

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

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

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

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

יומנים ומדדים של התאמה אוטומטית לעומס

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

Cloud Monitoring

אפשר להשתמש ב-Cloud Monitoring כדי:

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

Cloud Logging

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

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

‫2) בוחרים באפשרות dataproc.googleapis.com/autoscaler.

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

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

רקע: התאמה אוטומטית לעומס (autoscaling) עם Apache Hadoop ו-Apache Spark

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

מדדים של Hadoop YARN

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

הערה: המונח 'משאב' ב-YARN יכול להיות זיכרון YARN או ליבת YARN.

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

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

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

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

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

התאמה אוטומטית לעומס (autoscaling) ומיפוי וצמצום ב-Hadoop

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

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

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

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

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

‫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. אל תשתמשו בצמצום הדרגתי של כמות השרתים (התאמה אוטומטית לעומס gracefulDecommissionTimeout) עם משימות Spark Streaming. במקום זאת, כדי להסיר עובדים בצורה בטוחה באמצעות שינוי גודל אוטומטי, מגדירים יצירת נקודות ביקורת כדי להבטיח עמידות בפני תקלות.

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

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

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

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

שליטה בהתאמה אוטומטית של קנה המידה באמצעות חלוקה למחיצות ועיבוד מקבילי

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

• השירות המנוהל של 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 לשינוי גודל אוטומטי

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

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

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

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

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

שאלות נפוצות

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

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

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

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

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

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

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

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

קבלת תמיכה ב-Managed Service for Apache Spark

מה ההבדל בין Managed Service for Apache Spark לבין שינוי גודל אוטומטי ב-Dataflow?

התאמה אוטומטית לעומס (autoscaling) אופקית ב-Dataflow והתאמה אוטומטית לעומס (autoscaling) אנכית ב-Dataflow Prime

האם צוות הפיתוח של 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, כמו 'תוקף ההרשאה של המשימה פג'.

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

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

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

הערות:

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

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

• ‫T1: המידרוג האוטומטי מתחיל פעולת צמצום הדרגתי של כמות השרתים כדי לצמצם את מספר ה-workers באשכול בכמחצית.

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

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

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

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

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

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

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

• T9: אין פעולות פעילות בשעה T9. על סמך מדיניות ההתאמה האוטומטית של גודל המשאבים ומדדי YARN, כלי ההתאמה האוטומטית של גודל המשאבים ממליץ על פעולת הגדלה.