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

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

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

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

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

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

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

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

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

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

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

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

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

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

‫CLI של gcloud

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

בדוגמה הבאה של YAML מוגדרת מדיניות לאשכולות רגילים של Managed Service for Apache Spark, עם כל השדות הנדרשים. הוא גם מספק את הערכים minInstances ו-maxInstances לעובדים הראשיים, את הערך maxInstances לעובדים המשניים (שניתנים להפסקת פעולה), ומציין ערך של 4 דקות ל-cooldownPeriod (ערך ברירת המחדל הוא 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 מוגדרת מדיניות לאשכולות Standard של 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

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

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

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

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

   או

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

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

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
      

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

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

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

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

הגדרה scaleUpFactor

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

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

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

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

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

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

• השירות המנוהל של 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.

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

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

הערות:

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

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

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

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

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

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

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

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

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

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

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