התאמה לעומס (scaling)

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

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

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

שינוי קנה מידה אופקי

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

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

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

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

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

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

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

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

אפשר ליצור אשכול עם גורם לקביעת קנה מידה של צומת פי 2 באמצעות מסוףGoogle Cloud או ה-CLI של gcloud.

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

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

אשכולות קטנים

הגדלת הצומת פי 2 היא אופטימלית לעומסי עבודה גדולים יותר. אם אתם שוקלים לשנות את קנה המידה של הצמתים מסטנדרטי (בפקטור של אחד) לקנה מידה של פי 2, כדאי שתביאו בחשבון את ההשלכות על העלות. בעומס עבודה קטן יותר, כמו עומס עבודה שפועל באשכול עם צומת אחד, השימוש בהתאמה לעומס (scaling) של צומת פי 2 עולה פי 2. באופן דומה, שימוש בשינוי קנה מידה של צומת פי 2 לעומס עבודה שהופעל בעבר באשכול עם 3 צמתים מגדיל את העלויות ב-33%.

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

מגבלות

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

זמינות הצומת

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

עיכוב בזמן שהצמתים מאזנים מחדש

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

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

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

עלייה בזמן האחזור בגלל צמצום מהיר מדי בהתאם לעומס (scale down)

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

בעיות בעיצוב הסכימה

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

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

מגבלות על המהדורות

שכבת הזיכרון הפנימי וההתאמה האנכית זמינות רק לאשכולות SSD במהדורת Enterprise Plus.

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

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

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

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