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

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

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

בהקצאת צמתים ידנית, מספר הצמתים באשכול נשאר קבוע עד שמבצעים שינוי. כשהתכונה 'התאמה אוטומטית לעומס' מופעלת, Bigtable עוקב באופן רציף אחרי האשכול ומשנה אוטומטית את מספר הצמתים באשכול כשצריך. התאמה לעומס (autoscaling) פועלת באשכולות HDD ו-SSD, בכל האזורים של Bigtable.

אפשר להגדיר שינוי גודל אוטומטי במסוף Google Cloud , באמצעות gcloud או באמצעות ספריית הלקוח של Cloud Bigtable ל-Java.

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

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

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

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

• תנועה עם שיאים
• עומסי עבודה פתאומיים באצווה

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

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

אפשר להשתמש בשכבת הנתונים בזיכרון באשכולות במופעים של מהדורת Enterprise Plus. רמת השירות של Bigtable בזיכרון משתמשת בהתאמה אנכית לקיבולת העברת הנתונים, שמנוהלת באופן מלא, וכך מאפשרת לאשכולות להגיב כמעט באופן מיידי לעליות חדות בתעבורת הנתונים של קריאות נקודתיות. התאמה אנכית לעומס (vertical scaling) מתאימה כל צומת באופן אוטומטי כדי להתאים לדרישות של עומס העבודה, ומשתלבת עם התאמה אוטומטית לעומס (autoscaling) ב-Bigtable. מידע נוסף על מגבלות של הגדלת קיבולת אנכית ועל קיבולת התפוקה של שכבת הזיכרון זמין במאמר הסבר על ביצועים.

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

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

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

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

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

כל ממד של שינוי גודל יוצר מספר מומלץ של צמתים, ו-Bigtable משתמש באופן אוטומטי במספר הגבוה ביותר. לדוגמה, אם האשכול שלכם צריך 10 צמתים כדי לעמוד ביעד של ניצול נפח האחסון, אבל 12 צמתים כדי לעמוד ביעד של ניצול המעבד, Bigtable יגדיל את האשכול ל-12 צמתים.

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

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

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

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

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

פרמטרים של התאמה אוטומטית לעומס

כשיוצרים או עורכים אשכול ובוחרים באפשרות של שינוי גודל אוטומטי, מגדירים את הערכים של יעד ניצול המעבד, מספר הצמתים המינימלי ומספר הצמתים המקסימלי. אפשר להגדיר את יעד השימוש באחסון או להשאיר אותו כברירת המחדל, שהיא 50% (2.5TB ל-SSD ו-8TB ל-HDD).

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

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

קביעת יעד לניצול המעבד

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

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

קביעת יעד ניצול נפח האחסון

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

במקרה של שינוי גודל אוטומטי, ניצול נפח האחסון מוצג כמספר הבייטים של נפח האחסון לכל צומת, ולא כאחוז. יעד ניצול האחסון מוגדר לכל צומת, אבל הוא חל על כל האשכול. מגבלות הקיבולת של הצמתים הן 5TB לכל צומת לאחסון SSD ו-16TB לכל צומת לאחסון HDD.

בטבלה הבאה מוצגים סכומי היעד של אחוזים אופייניים של ניצול נפח האחסון. במסוף Google Cloud אפשר להזין את הערך בטרה-בייט לכל צומת, וב-gcloud CLI, ב-API ובספריות הלקוח של Cloud Bigtable אפשר להזין ערך מספרי בגיגה-בייט לכל צומת.

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

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

• מהדורת Enterprise: המגבלה היא 32 TB לכל צומת.
• מהדורת Enterprise Plus: המגבלה היא 32 TB לכל צומת או 64 TB לכל צומת, אם מופעלת הגדלת קיבולת של 2x.

לדוגמה, באשכול SSD, אם מגדירים יעד לניצול נפח האחסון של 2.5TB ‏ (50%) לכל צומת, והשימוש בגישה לא תדירה גבוה מספיק כדי להגדיל את נפח האחסון הנדרש עם אחסון מדורג מעל המגבלה, Bigtable מוסיף צמתים. זה קורה גם אם השימוש ב-SSD נשאר בטווח של 50% מהיעד.

הטבלה הבאה עוזרת להבין איך התאמה אוטומטית לעומס ממליצה על מספר צמתים על סמך השימוש ב-SSD והשימוש בגישה לא תדירה:

מידע נוסף על אחסון מדורג זמין במאמר סקירה כללית על אחסון מדורג.

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

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

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

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

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

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

אם הפעלתם אחסון מדורג, אתם צריכים לקחת בחשבון את מגבלת האחסון של 32 TB לכל צומת (Enterprise) או 64 TB (Enterprise Plus). גם אם השימוש ב-SSD נמוך, נפח גדול של נתונים ברמת הגישה הלא תדירה יכול להפעיל את שינוי הגודל של הצומת.

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

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

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

אחרי שהאשכול יופעל עם קנה מידה משתנה אוטומטית, עוקבים אחרי האשכול ומוודאים שהערך שבוחרים למספר המקסימלי של הצמתים גבוה לפחות כמו recommended number of nodes for CPU target ו-recommended number of nodes for storage target.

קביעת המספר המינימלי של צמתים

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

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

• יש לכם אירוע שיא של הרחבת עומס בקרוב, ואתם מצפים לעלייה זמנית בתנועה. אתם רוצים לוודא שיש לכם מספיק קיבולת.
• האפליקציה שלך שולחת תנועה עם עליות חדות. כשמוסיפים צמתים חדשים, Bigtable מבצע איזון מחדש באופן אוטומטי בצמתים החדשים. התהליך הזה יכול להימשך כמה דקות, ולכן ברוב המקרים עדיף לנקוט גישה שמרנית ולבחור ערך מינימלי גבוה יותר, כדי שהאשכול יוכל להתמודד עם העליות החדות בצורה חלקה.
• מגדילים את המספר המקסימלי של הצמתים. המספר המינימלי תמיד צריך להיות 10% או פחות ממספר הצמתים המקסימלי. לדוגמה, אם הגדרתם את הערך המקסימלי ל-30, אתם צריכים להגדיר את הערך המינימלי ל-3 לפחות.

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

שיפור ההגדרות

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

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

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

חשבון לשכפול

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

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

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

בקרת גישה

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

מעקב

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

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

• bigtable.googleapis.com/cluster/autoscaling/min_node_count
• bigtable.googleapis.com/cluster/autoscaling/max_node_count
• bigtable.googleapis.com/cluster/autoscaling/recommended_node_count_for_cpu
• bigtable.googleapis.com/cluster/autoscaling/recommended_node_count_for_storage
• רק ב-Enterprise Plus: ‏ bigtable.googleapis.com/memory_layer/request_unit_usage

רישום ביומן

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

Grew from 9 to 10 nodes to maintain CPU utilization at 60%.

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

1. מנווטים אל Logs Explorer:

   כניסה לדף Logs Explorer

   בוחרים את הפרויקט המתאים Google Cloud .

2. בשדה Query, מזינים את הטקסט הבא:

   resource.type="audited_resource" resource.labels.service="bigtableadmin.googleapis.com"
   resource.labels.method="AutoscaleCluster"
   

3. לוחצים על Run query.

   בחלונית Query results מוצגים היומנים מהשעה האחרונה.

מידע נוסף על צפייה ביומנים זמין במאמר בנושא Cloud Logging.

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

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