Committed Use Discounts ב-GCP: מדוע ההנחה לא מיושמת
עומס יציב לאורך כל שעות היממה, ההתחייבויות נרשמו, אבל בפירוט החשבון אין שורה עם הנחה עבור התחייבות ארוכת טווח. Committed Use Discounts ב-GCP אינן נפרסות על התשתית באופן אוטומטי: ההנחה משויכת לפרויקט, לאזור, למשפחת מכונות ולסוג משאב בנפרד.
אם כל הפרמטרים תואמים לצריכה בפועל — ההנחה מיושמת; אם אפילו אחד מהם אינו תואם — היא לא מוצאת את האובייקט.
אי-ההתאמה בדרך כלל נראית תמימה. ההתחייבות נרשמה עבור פרויקט אחד, אבל עומסי העבודה חיים בשניים-שלושה — לאחר פיצול התשתית חלק עבר לפרויקט נפרד. או שהאזור בהתחייבות הוא אחד, והמופעים התפזרו בין אזורים לאזור סמוך. או שהחליפו משפחת מכונות בעת עדכון, וההתחייבות נשארה על הסדרה הקודמת.
לכן הדבר הראשון שאנחנו עושים הוא הפקת פרופיל צריכה ל-30–60 ימים בחתך של פרויקטים, אזורים וסדרות מכונות. הוא מראה היכן העומס באמת יציב וכמה ממנו מחזיק מעמד בלילה ובסופי שבוע.
הזמנת משאבים לפי ערכי שיא היא הטעות הנפוצה השנייה: הקיבולת ששולמה עומדת ללא שימוש חצי מהזמן, והתועלת נשחקת.
בנפרד אנחנו בודקים אם ההתחייבויות אינן חופפות זו לזו ואם הן אינן מתנגשות עם סקיילינג אוטומטי: את מה שעולה לפי לוח זמנים לא כדאי לקחת בהתחייבות ארוכת טווח.
בהמשך נפרט איך סוגרים את זה: איך להתאים התחייבויות לצריכה בפועל, איזה פרופיל צריכה להיחשב יציב ומה כדאי להחזיק לפי דרישה ולא בהתחייבות.
מה נותן מודל מנוהל של הזמנת משאבים
התחייבות להזמנת משאבים היא לא הנחה, אלא קיבוע של חלק הבסיס בעומס לטווח ארוך: אתם מצהירים מראש כמה משאבים אתם מחזיקים באופן קבוע, ומשלמים עליהם בתעריף מופחת. כל מה שמעל הבסיס — שיאים, ניסויים, תנודות עונתיות — נשאר לפי דרישה. קונטור כזה מוגדר ב-Google Cloud והופך את חשבון הענן מהגרלה למדד מנוהל.
להלן צ'ק-ליסט שלפיו אנחנו בודקים שהמודל באמת עובד, ולא רק מופעל:
- חלק הכיסוי על ידי התחייבויות מתיישר. מחזיקים 60–75% מהבסיס היציב תחת התחייבות, את השאר — לפי דרישה: בסטייה מעל 85% כל ירידה בעומס הופכת לתשלום יתר.
- הוצאות התשתית מפסיקות לגדול. החשבון הופך לפונקציה של מספר השירותים, ולא של שיאים אקראיים — הסטייה מחודש לחודש נשמרת באחוזים בודדים.
- עומס צפוי מופרד מעומס שיא. בסיסי נתונים, מטמון, תורים ומשימות רקע עוברים תחת התחייבות, והרצות חד-פעמיות נשארות גמישות.
- נעלם סוג התקלות בגלל מחסור במכסות בשיא. ההזמנה משויכת למשפחת מכונות ולאזור, ומכונה חדשה ברגע הגידול עולה בלי להמתין להקצאת משאבים.
- עלות הבעלות נחשבת באופק. אפקט ההזמנה נראה לא בחשבון הראשון, אלא ברבעון: משווים «התחייבות פלוס לפי דרישה» מול צריכה נטו.
כל סעיף אנחנו מצליבים עם פרופיל העומס בפועל לאורך כמה חודשים — אחרת ההתחייבות או לא מנוצלת מספיק, או מונעת צמיחה.
מצבי הזמנה: השוואת אפשרויות ומגבלות
מצב ההזמנה קובע לא רק את גודל ההנחה, אלא גם את מחיר הטעות בעת שינוי קונפיגורציה. ב-Google Cloud הנחות עבור התחייבות (committed use discounts) הן משאביות — מקובע נפח ליבות וזיכרון במשפחת מכונות ובאזור מסוימים — או כספיות, כאשר מקבעים רמת צריכה לפי שירותים. הראשונות נותנות הנחה מקסימלית, אבל משויכות בצורה נוקשה יותר לסוג המשאב.
התחייבויות לא מכסות תוספות עבור אימג'ים, רישיונות ותעבורת רשת — הם מחויבים כרגיל. להלן ארבע חלופות אמיתיות: מתי כל אחת מתאימה ובמה היא מגבילה.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| התחייבות על משאבי מחשוב | פרופיל עומס יציב: שכבת ווב, עובדים, עיבוד זרימה | תקופה של שנה ומעלה, הצמדה לאזור ולמשפחת מכונות, זמן השבתה מחויב |
| התחייבות על זיכרון ואחסון | בסיסי נתונים, מטמונים, אנליטיקה שבהם צוואר הבקבוק הוא זיכרון | ההנחה נמוכה יותר, רשימת השירותים המכוסים מצומצמת יותר, אין העברה בין אזורים |
| התחייבות על בסיס וסקיילינג אוטומטי | שיאים בלתי צפויים: עונתיות, השקות קמפיינים | הנחה רק על המינימום המוזמן, שיאים מחויבים בתעריף רגיל |
| ללא הזמנה | שירותים חדשים, פרויקטים קצרים, בדיקת השערות | המחיר הגבוה ביותר והיעדר הבטחת זמינות משאבים |
סכימה עובדת היא התחייבות על בסיס צפוי פלוס סקיילינג אוטומטי בשיאים: ההנחה עובדת היכן שהצריכה יציבה, והגמישות נשמרת בשאר. מגבלה שנודע עליה באיחור: התחייבות לא ניתנת להעברה בין פרויקטים ומשפחות מכונות, ולכן הרכב המשאבים מקבעים לפי הצריכה בפועל, ולא לפי תחזית.
סדר היישום: מאינוונטריזציה ועד מסירת נהלים
יישום התחייבויות ב-GCP הוא לא רכישת הנחה, אלא תכנון סכימת כיסוי על נתונים אמיתיים. אם מדלגים על אינונטריזציה, ההתחייבות תקבע פרופיל עומס שגוי: ההתחייבות נרכשה, אבל חלק מההזמנה לא מנוצל. לכן אנחנו הולכים ברצף הנדסי קפדני.
- אינוונטריזציה של הצריכה — מייצאים היסטוריה של כמה תקופות ומפרקים אותה לפי פרויקטים, אזורים ומשפחות מכונות, תוך הפרדה בין בסיס יציב לעומס שיא.
- ניתוח אנומליות — מאתרים הרצות חד-פעמיות, סביבות זמניות, משאבים נשכחים וכל מה שמעוות את הפרופיל; מסמנים ומחריגים מהחישוב, אחרת הבסיס מנופח.
- תכנון סכימת כיסוי — קובעים איזה חלק מהבסיס לכסות בהתחייבויות, ומה להשאיר בתעריפים גמישים, כדי לשמור על מרחב תמרון בעת שינוי ארכיטקטורה.
- הגדרת התחייבויות — בוחרים סוג, תקופה והצמדה, מקבעים את הקונפיגורציה בקוד התשתית ולא ידנית בקונסולה, כדי שאפשר יהיה לשחזר את הסכימה ולבצע שחזור לאחור.
- בדיקת השערות על נתונים — מצליבים את החישוב עם הצריכה בפועל והעומס בתקופה הראשונה: היכן שההתחייבות לא מנוצלת מספיק או מכסה יותר מדי, מתקנים לפני שמופעל סף אי-ההפיכות.
- מסירת נהלים — מוסרים כללים לבחינה מחדש של הכיסוי, ספי התראות על תת-ניצול וסדר פעולה בעת שינוי פרופיל עומס.
בתוצאה, לצוות אין הגדרה חד-פעמית, אלא תהליך מנוהל: כאשר העומס משתנה, הסכימה מחושבת מחדש לפי הנהלים, ולא נבנית מאפס.
סט הגדרות, סכימות ונהלים בסיום העבודה
לאחר מסירת העבודה נשאר לכם לא מצגת, אלא קונטור עובד במאגר ובבוויקי: לפיו מהנדס חדש יבין את ההתחייבויות בערב אחד, ולא בשבוע של שאלות. המסמכים נמצאים לצד קונפיגורציות התשתית ומתעדכנים באותו סדר סקירה כמו הקוד.
- מפת פרויקטים — טבלה «פרויקט / בעלים / פרופיל עומס / סוג התחייבות מתאים (אזוריות למשאבי מחשוב, גמישות להוצאה כוללת) / תאריך סיום / אחראי על הארכה».
- סכימת חלוקת התחייבויות — איזה חלק מעומס הבסיס מכוסה בהתחייבויות, איזה נשאר לפי דרישה, והיכן מרוכז הסיכון לתת-ניצול בירידת צריכה.
- מדיניות גישה — תפקידים ואישורים: מי רשאי לרשום, להאריך ולבטל התחייבויות, מי מאשר שינוי נפח, ומה נרשם בלוג.
- נוהל בחינה מחדש — צ'ק-ליסט עם תדירות: הצלבת הצריכה בפועל עם התוכנית, בדיקת דריפט של פרופיל העומס, כניסה לחלון ההארכה מראש כדי לא לאבד את ההנחה.
- הוראות למשמרת תורנית — מה לבדוק בדוחות ההוצאה, אילו סטיות להיחשב לאות, למי להסלים ובאיזה מועד.
- דוח כיסוי — חלק העומס תחת התחייבויות, מועדי תפוגה לכל בלוק ורשימת כשלים שהוסרו: היעדר קנסות על תת-ניצול ואובדן ההנחה בזמן השבתה.
כל זה נמסר עם סיור במאגר ודיון בצד שלכם — כדי שנוהל הבחינה מחדש יעבוד בלעדינו.
מקרה בוחן: ייצבנו את פרופיל הצריכה והסרנו קפיצות בעומס
הלקוח — מחלקת מוצר עם צי קבוע של מכונות וירטואליות לשירותים ומשימות כבדות אפיזודיות ב-Google Cloud. התחייבויות צריכה (Committed Use Discounts) נרשמו לשבועות שיא, ולא לפרופיל בפועל: חלק מהמשאבים עמדו ללא שימוש, וחלק חויבו במחירים ללא הנחה. את חלק הכיסוי אף אחד לא חישב — ההחלטות התקבלו לפי תחושות מהחשבון.
מה הראו המדידות
בחודש המדידות הראשון: 43% מהצריכה כוסו בהתחייבויות, והצריכה היומית נעה כמעט פי ארבעה — מהמינימום הלילי ועד לשיא היומי. התנגשות במכסות במהלך הרבעון הניבה 6 אירועים, שלושה מהם טופלו ידנית. הסיבה אחת: תוכנית הקיבולת חיה בנפרד מהאופן שבו העומס מתנהג במהלך היממה.
פירקנו את היסטוריית הצריכה לחלק בסיסי ומשתנה: את הבסיס קיבענו בהתחייבויות, את השיאים העברנו לסקיילינג אוטומטי, ולשעות צפויות הוספנו לוח זמנים. התראות על התקרבות למכסות הוגדרו לפי מגמה, ולא לפי כשל בפועל.
מה השתנה
אחרי רבעון חלק הכיסוי — 88%: ההנחה עובדת על החלק הקבוע, ולא על חתך אקראי. פיזור הצריכה היומית הצטמצם מפי ארבעה לפי אחד וחצי, ואירועים בגלל התנגשות במכסות — אפס. הבחינה מחדש הבאה של ההתחייבויות תתבסס כבר על נתונים, ולא על שבוע שיא.
התחייבות על משאבים או סקיילינג אוטומטי?
התחייבות וסקיילינג אוטומטי פותרים משימות שונות — משווים ביניהם רק בדוחות. התחייבות מקבעת תעריף עבור משאב לטווח ארוך: ב-Google Cloud אלו committed use discounts עם הנחה של עד 55% מהעלות השעתית. סקיילינג אוטומטי מנהל את מספר המופעים הפעילים לפי העומס הנוכחי. הקונפליקט כאן כלכלי: ההנחה מחושבת מהצריכה בפועל, ובמעומס צף הכיסוי הופך לתשלום יתר.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| התחייבות | עומס בסיס יציב: שירותי מערכת, בסיסי נתונים, תורים | אי אפשר להקטין בתוך התקופה; בירידת צריכה חלק מהתשלום יורד לטמיון |
| סקיילינג אוטומטי | קפיצות, עונתיות, משימות באצווה, סביבות פיתוח | תעריף ללא הנחה, החשבון גדל ביחס לעומס |
| היברידי | קיים עומס בסיס יציב וחלק משתנה | נדרשים ניטור צריכה ובחינה תקופתית של הכיסוי |
התחייבות נלקחת עבור עומס הבסיס — שירותי מערכת, בסיסי נתונים, המינימום של מאגר שנשמר מסביב לשעון. סקיילינג אוטומטי משאירים לעומס גלי: משימות באצווה, תנודות עונתיות, סביבות פיתוח.
סכימה היברידית מחושבת לפי אחוזונים, ולא לפי ממוצע: את הכיסוי לוקחים לפי האחוזון התחתון של הצריכה בחלון התצפית — בדרך כלל 60–70% מהחציון, ואז השיאים נשארים על סקיילינג אוטומטי.
בחינה מחדש של הכיסוי היא הרגע המסוכן ביותר: אי אפשר להקטין התחייבות בתוך התקופה. קודם מציגים התחייבויות חדשות תחת הפרופיל שהשתנה, ממתינים לקליטתן, ורק אחר כך מוותרים על הישנות. השירותים לא מופעלים מחדש — משתנה התמחור, ואין השבתה.
ספקות טכניים: מה מבררים לפני תחילת העבודה
לפני תחילת העבודה הספקות של המהנדסים הם כמעט תמיד אותם ספקות: מה יקרה בירידת צריכה, האם אפשר לשנות הרכב משאבים, איך לחלק התחייבויות בין צוותים. להלן תשובות ענייניות.
מה יקרה אם הצריכה תירד?
ההתחייבות מקבעת נפח צריכה מינימלי לתקופה ואינה מחושבת מחדש אוטומטית — תת-ניצול נסגר לפי תעריף ההתחייבות. לכן אנחנו מחשבים קו בסיס לפי מדדים היסטוריים לתקופה ארוכה, ולוקחים התחייבויות רק על החלק היציב של העומס.
האם אפשר לשנות הרכב משאבים בתוך התחייבות?
סוג ההתחייבות משויך למשפחת מכונות ולאזור, וגרסאות גמישות מאפשרות החלפה בתוך הקבוצה. אנחנו בוחרים סוג עם חופש ההחלפה המרבי ורושמים קבוצות משאבים שונות בהתחייבויות נפרדות — כך שינוי קונפיגורציה לא מאפס את הכיסוי.
איך לחלק התחייבויות בין צוותים?
ב-Google Cloud התחייבויות משויכות לחשבון משותף, ולא לצוות נפרד, ולכן את החלק של כל צוות מחשבים לפי תגיות על המשאבים. אנחנו מגדירים תיוג כך שהצוות יראה את הצריכה והכיסוי שלו, וההארכה תוכרע לפי מספרים.
מתי בוחנים מחדש את התנאים?
ככל שהתקופה ארוכה יותר, ההנחה גבוהה יותר והחופש קטן יותר — זה הסיכון העיקרי של התחייבויות. לכן בתוכנית אנחנו מכניסים נקודת בחינה מחדש ומקבעים מראש מדדים שיהוו עילה לשינוי הסכימה: ירידה בקו הבסיס, מעבר של חלק מהעומס, החלפת פלטפורמה.
נדון במשימה ונחזור עם הערכה ותוכנית
כדי לחזור לא עם שיקולים כלליים, אלא עם סכימת כיסוי ולוחות זמנים קונקרטיים, אנחנו צריכים חתך של הצריכה בפועל והמגבלות שלכם. אספו את מה שכבר קיים בבילינג ובמערכות הנה"ח — לא תצטרכו להכין דבר במיוחד, מספיק להעביר את הנתונים בכל צורה נוחה: ייצוא, גישה לקריאה או טבלה.
- פירוט חודשי של הצריכה ל-6–12 חודשים לפי שירותים, אזורים ופרויקטים — ממנו רואים את רמת הבסיס שאפשר לכסות בהתחייבויות, ואת השיאים החד-פעמיים שאסור לכסות.
- פירוט לפי משפחות משאבים: ליבות מחשוב, זיכרון, מאיצים, אחסון, תעבורת רשת — ההנחה עבור התחייבות בכל תחום מחושבת בנפרד.
- התחייבויות נוכחיות: מה כבר נרשם, לאיזו תקופה, באיזה אזור, כמה נותר ומה חלק הצריכה שמכוסה בהן בפועל.
- פרופיל עומס: תנודות יומיות ושבועיות, רמת צריכה מינימלית, תוכניות גידול ותנודות עונתיות.
- מפת סביבות ודרישות לעמידות בתקלות: אילו שירותים ישרוד מעבר לסוג משאב אחר, ואילו משויכים בקשיחות לקונפיגורציה.
- מגבלות ארגוניות: מכסות, אישורים, מועדי תכנון תקציב ומי שמקבל החלטה על התחייבויות.
תארו את המשימה והעבירו את הנתונים האלה — הצעד הבא הוא שלנו. נחזור עם הערכה, סכימת כיסוי לפי משפחות משאבים, חישוב חלק הצריכה המכוסה ותוכנית עבודה עם שלבים, כדי שאפשר יהיה לקבל החלטה לפי מספרים, ולא לפי תחושות.