הגדרת Reserved VM Instances עבור Azure: הפחתת עלויות עד 72%

מדוע ללא Reserved VM Instances Azure עלויות הענן גדלות

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

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

Reserved VM Instances Azure עוסק במשהו אחר: הנחה של עד 72% בתמורה להתחייבות למשפחת גדלים, אזור ותקופה. אתם מקבעים מראש כמה כוח מחשוב ובאיזו תקופה אתם לוקחים, והספק מחשב אותו בזול יותר.

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

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

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

מה נותנת ההזמנה מראש: אפקט מדיד

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

חלק השעות המכוסות

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

תחזית הוצאות על תשתית

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

החלפה וביטול של הזמנות מראש

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

צפיות של מכסות המינוי

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

מצבי הזמנה מראש ב-Azure: השוואת אפשרויות

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

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

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

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

שלבי יישום: מביקורת עומס ועד מסירת נהלים

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

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

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

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

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

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

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

תצורות, תוכניות ונהלים לאחר היישום

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

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

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

פרקטיקה: פרופיל צריכה לפני ואחרי הזמנה מראש

לפני: בסיס יציב ונפילות בשיאים

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

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

אחרי: שכבת בסיס תחת התחייבות, שיאים — לפי בפועל

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

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

במה הזמנה מראש שונה מתוכנית חיסכון ומה לבחור

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

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

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

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

התנגדויות טכניות: מה חשוב לבדוק מראש

Reserved VM Instances ב-Azure מכסים הנחה על משאבי מחשוב בתמורה להתחייבות למשפחת מכונות, אזור ותקופה. לכן התנגדויות טכניות נוגעות לא לגודל ההנחה, אלא לגמישות: מה יקרה אם פרופיל העומס ישתנה. להלן ספקות שאנו מסירים לפני הקנייה, ולא אחריה.

כיצד ההזמנה מראש מתחלקת בין מינויים וסביבות?

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

כיצד לדעת שההזמנה מראש עומדת ללא שימוש?

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

נדון במשימה: מה נדרש לחישוב הזמנה מראש

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

בסיכום אנו חוזרים עם הערכה, תוכנית עבודה להזמנה מראש וחישוב לאיזו תקופה ולאילו משפחות מכונות ההזמנה מראש של Reserved VM Instances ב-Azure משתלמת.

מה להכין לשיחה:

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

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