אופטימיזציה של עלויות ענן: היכן התקציב דולף מבלי לשים לב
חשבון הענן אינו גדל בקפיצה, אלא לאט לאט: במהלך החודש הוספנו כמה מופעים "לזמן מה", שכחנו למחוק דיסקים לאחר מיגרציה, השארנו סביבת בדיקה פעילה בסופי שבוע.
כל סעיף נראה תמים, אך בסך הכול הם יוצרים גידול מתמשך בחשבון הענן שאיש אינו עוקב אחריו — התשלום עובר, הנהלת החשבונות אינה שואלת שאלות, והתשתית מתכסה בשקט במשאבים שאינם בשימוש.
הסיבה הנפוצה ביותר — משאבים שאיש לא כיבה. מכונות וירטואליות למשימות שנסגרו לפני חודשים, כרכים ללא חיבור, תמונות מצב ישנות, מאזני עומס "זמניים" וכתובות שהוקצו לניסוי. בנפרד מדובר בשברירי אחוזים, ביחד — חלק ניכר מהחשבון.
הסיבה השנייה — מחלקות אחסון שגויות: נתונים חמים שניגשים אליהם פעם ברבעון נמצאים במחלקה יקרה, בעוד ארכיון וגיבויים — במקום שבו משלמים על כל בקשה.
השלישית — היעדר בקרה על הזמנות מראש: חלק מהעומס עובד באופן יציב מסביב לשעון, אך משולם לפי תעריף "לפי דרישה", אף שלגביו הגיוני לקחת התחייבות ארוכת טווח.
בנפרד יש להתייחס לתעבורה בין אזורים ולפניות חיצוניות לשירותים — לעתים רחוקות מחשבים אותן מראש, ובחשבון הן צצות כשורה מפתיעה. כאן עוזר לא ניקוי חד-פעמי, אלא בקרת תקציב סדירה: תיוג משאבים לפי צוותים ופרויקטים, התראות על חריגה מסף, וניתוח חודשי של סטיות מהתחזית.
מפרקים כיצד זה נסגר: ממלאי ותיוג ועד למדיניות מחזור חיים ובחינה מחדש של התחייבויות תעריפיות — ללא עצירת המוצר וללא סיכון לעמידות בכשלים.
מה מספקת תשתית ענן מנוהלת
תשתית מנוהלת נמדדת לא במספר השירותים המוגדרים, אלא במידת הצפיות של התנהגותה תחת עומס ובחשבון החודשי. הדבר הראשון שנראה לאחר הכנסת סדר הוא צמצום זמן ההשבתה: תצורה עמידה עם הפעלה מחדש אוטומטית של תהליכים שקרסו וחלוקת תעבורה בין אזורים מסירה נקודת כשל בודדת.
האפליקציה שורדת נפילה של צומת בודד ללא התערבות ידנית, והשחזור אורך דקות ולא שעות של השבתה עם בקשות שאבדו.
האפקט השני הוא הפחתת שיעור המשאבים שאינם בשימוש. רזרבות שהוקצו פעם "עם מרווח" ונשכחו מכרסמות בתקציב בלי להחזיר דבר בתמורה.
אנו מבצעים ספירת מלאי: משווים את העומס בפועל לקיבולת שהוקצתה, מעבירים סביבות בשימוש נדיר לסכמות אלסטיות, שבהן משאבים מופיעים לפי המשימה ומשוחררים לאחריה. היקף הקיבולת המושבתת מצטמצם פי כמה, ולא באחוזים.
השלישי הוא צפיות התשלומים. כאשר העומס והצריכה קשורים ישירות, החשבון מפסיק להיות הפתעה: ברור איזה חלק מההוצאות קבוע ואיזה תלוי בתעבורה ובעונתיות. מופיעים ספי התראות, שבהם גידול בצריכה נראה מראש ולא בדיעבד עם סגירת החודש.
בסך הכל זוהי יעילות התשתית: פחות השבתות, פחות נטל, תקציב מנוהל. ניתן לבדוק את האפקט לפי שלושה מדדים — זמן ההתאוששות לאחר תקלה, שיעור הקיבולת המושבתת וסטיית התשלומים בפועל מהמתוכנן. אם לפחות אחד מהם אינו נמדד, אין מה לייעל.
אפשרויות אופטימיזציה: השוואת גישות
אופטימיזציה של עלויות ענן לעיתים רחוקות נפתרת באמצעי אחד. בפועל בוחרים בין שלוש גישות — אופטימיזציה ידנית, מדיניות אוטומטית וליווי ייעודי של התשתית — והבחירה תלויה בהיקף, בבגרות התהליכים ובמי שאחראי על השינויים בפרודקשן.
| גישה | מתי מתאימה | מגבלות |
|---|---|---|
| אופטימיזציה ידנית | תשתית קטנה, שירותים בודדים, משימות חד-פעמיות: כיבוי אינסטנסים לא פעילים, העברת נתונים קרים למחלקת אחסון זולה | דורשת תשומת לב מתמדת של מהנדס, האפקט חד-פעמי — כעבור חודש ההוצאות חוזרות לרמה הקודמת |
| מדיניות אוטומטית | עומס יציב, תרחישים חוזרים: לוחות זמנים להפעלה/כיבוי של סביבות, כללי lifecycle לתמונות ולגיבויים, autoscale לפי מדדים | נדרשים מדדים ותגים תקינים; בלעדיהם הכללים מכבים את מה שצריך או לא נוגעים במיותר |
| ליווי ייעודי | תשתית גדלה, כמה צוותים, מחזור שחרורים סדיר | דורש העברת הרשאות גישה וחלק מהאחריות על התשתית |
מה נותנת כל גישה
אופטימיזציה ידנית טובה כהתחלה מהירה: היא מראה היכן ההוצאות דולפות ונותנת תוצאות ראשונות ללא שינויים בארכיטקטורה. אך ללא עיגון התוצאה בכללים היא אינה מתרחבת — התיקונים נעשים ידנית ונשכחים.
מדיניות אוטומטית מכסה תרחישים חוזרים: לוחות זמנים, מגבלות, כללי שמירה. הם פועלים ללא מעורבות אדם, אך דורשים כוונון מדויק — כלל שגוי עלול לכבות סביבת עבודה או למחוק תמונה נדרשת.
ליווי ייעודי של התשתית מחבר את שתי הגישות: מהנדסים מנהלים מרשם משאבים, מגדירים מדיניות לפי פרופיל עומס אמיתי ובוחנים אותה מחדש בעת שינויים. זה נותן אפקט יציב, ולא חיסכון חד-פעמי.
בפועל משלבים בין הגישות: תחילה ניתוח ידני, אחר כך אוטומציה של תרחישים חוזרים, ולבסוף ליווי מתמשך. נדון בתשתית שלכם — נחזור עם הערכה ותוכנית.
כיצד אנו מיישמים אופטימיזציה של עלויות ענן
העבודה מתנהלת בשלבים, ובכל שלב הלקוח רואה תוצאה לפני המעבר לשלב הבא. אנו מתחילים בסקר תשתית: אוספים את צריכת המשאבים בפועל, משווים אותה לקיבולות המוצהרות ומאתרים פערים — מופעים שאינם בשימוש, מגבלות מנופחות, דיסקים שאיש אינו מכבה. בסיום הסקר עומדת לרשות הלקוח מפת הוצאות עם פירוט לפי שירותים ותשובה ברורה מה בדיוק אוכל את התקציב.
- סקר תשתית. אנו אוספים מדדי צריכה על פני תקופה מייצגת, ומשווים אותם לתצורה ולתמחור. בפלט — רשימת משאבים עם סימון "נדרש / עודף / אינו בשימוש" והערכת פוטנציאל הצמצום.
- תרשים משאבים. בונים תרשים יעד: אילו קיבולות נשארות, מה עובר למחלקות קלות יותר, והיכן מופעל scaling אוטומטי בהתאם לעומס בפועל. התרשים מתואם עם צוות הפיתוח — האופטימיזציה אינה אמורה לשבור תרחישי שיא.
- הגדרת מדיניויות. מיישמים כללי מחזור חיים: כיבוי אוטומטי של סביבות שאינן בשימוש, תקופת שמירת גיבויים ולוגים, מגבלות על יצירת משאבים. המדיניויות מקובעות בתצורה, ולא בהסכמות בעל פה.
- בדיקת התוצאה. משווים את הצריכה לפני ואחרי באותם תרחישי עומס, ובודקים שזמן התגובה והזמינות לא נפגעו. את המדידות חוזרים כעבור חודש — כך רואים שהאפקט יציב ולא חד-פעמי.
- מסירת נהלים. מוסרים תיעוד: תרשים המשאבים, תיאורי המדיניויות, סדר הוספת שירותים חדשים ונקודות בקרת ההוצאות. צוות הלקוח ממשיך לנהל את התשתית בעצמו, ללא תלות בנו.
השלבים מתנהלים ברצף, אך הסקר ותרשים המשאבים חושפים לעיתים קרובות ניצחונות מהירים — אותם סוגרים מיד, בלי להמתין למחזור מלא. בהמשך נספר מה נותר ללקוח לאחר הפרויקט.
מה הלקוח מקבל בסיום העבודה
בסיום העבודה לא נשארת אצלכם מצגת, אלא תשתית עובדת וסט מסמכים שלפיהם ניתן לפתח אותה ולהעביר אותה לצוות אחר. כל מה שאנחנו משנים מתועד במאגר — המצב מתואר בקוד, ולא בזיכרון של מהנדס מסוים.
- תצורות משאבים: מותאמות לפרופיל העומס הרצוי, עם נימוק למחלקות שנבחרו ולעוצמות שהוקצו לתקופות שיא.
- תרשימי תשתית: טופולוגיה עדכנית עם זרימות נתונים בין שירותים, מאגרי נתונים ומערכות חיצוניות — ניתן לראות מה תלוי במה והיכן נקודות הכשל.
- מדיניות גישה: תפקידים והרשאות לפי עקרון המינימום ההכרחי, חשבונות נפרדים לשירותים, תיעוד פעולות.
- נהלי תפעול: כללי הרחבה, לוחות זמנים להפעלה וכיבוי של סביבות, סדר הוצאת משאבים משימוש.
- מדיניות שמירה ומחזור חיים: משך החיים של גיבויים, כללי ארכוב ומחיקה של נתונים מיושנים.
- תיעוד: תיאור הסביבות, הוראות פריסה וחזרה לאחור, רשימת האחראים לכל קו מתאר.
- דוח הוצאות: פירוט לפי כיוונים, היכן נצרך נפח מיותר ואילו פתרונות סגרו אותו.
- תוכנית אופטימיזציה להמשך: מה כדאי לשנות בשלב הבא ואיזו תועלת זה מביא.
סט כזה מסיר את התלות בקבלן: השינויים משוחזרים, חזרה לאחור אפשרית, ומהנדס חדש נכנס לפרויקט לפי מסמכים ולא לפי סיפורים. תארו את המשימה שלכם — נחזור עם הערכה ותוכנית עבודה.
מקרה בוחן: צמצום הוצאות הענן ללא פגיעה בביצועים
מה היה לפני
הגיע אלינו פרויקט על Kubernetes — שירות עם שיא עומס יומי ושפל בלילה. הקלאסטר גדל באופן ספונטני: לכל שירות חדש הוסיפו צומת, מגבלות משאבים כמעט לא הוגדרו בשום מקום, וסביבות הפיתוח והבדיקות פעלו מסביב לשעון.
לפי מדידות בפועל, שיעור המשאבים שאינם בשימוש עמד על 40-45%: יכולות שמורות עמדו ללא שימוש בשעות השפל, אך שולמו לפי מחירי שיא.
בעיה נפרדת — התגובה לאירועים. מהנדס תורן נודע על ירידה בביצועים מתלונות משתמשים, ולא מניטור: זמן הגילוי הממוצע של הבעיה עמד על כ-40 דקות, ועוד אותו זמן הלך לאיתור הגורם. הקלאסטר המשיך לגדול, וההוצאות גדלו ביחס למספר השירותים, ולא לעומס בפועל.
מה שינו
הפרדנו את עומסי העבודה לפי עדיפויות והקמנו מאגרי צמתים נפרדים לשירותים רגישים להשהיה ולמשימות רקע שניתן לקטוע. עבור מאגרי הרקע הפעלנו סקיילינג אוטומטי עד לאפס בשעות הלילה — צמתים מופיעים רק עבור המשימה ומשוחררים לאחר סיומה.
לכל השירותים הגדרנו בקשות ומגבלות לפי צריכה בפועל, ולא "לפי העין": זה הסיר את הקצאת היתר ואיפשר למתזמן לארוז פודים בצפיפות גבוהה יותר.
סביבות הפיתוח והבדיקות הועברו ללוח זמנים: הן עולות בבוקר ונעצרות בערב, ובסופי שבוע — כבויות לחלוטין. בניית האימג'ים הועברה לסוכנים עם מטמון, כדי לא להריץ בנייה מלאה מחדש על כל קומיט.
במקביל הגדרנו התראות לפי מדדים מרכזיים עם ספים המותאמים לנורמה של כל שירות, ולא למגבלות הכלליות של הקלאסטר.
מה היה בסוף
שיעור המשאבים שאינם בשימוש ירד מ-40-45% ל-12-15% — הוצאות החישוב הפסיקו לגדול יחד עם מספר השירותים. זמן הגילוי הממוצע של אירוע התקצר מ-40 דקות ל-3-5 דקות, והזמן עד לאיתור הסיבה — מ-40 ל-10 דקות: התורן רואה שירות ומדד ספציפיים, ולא גרף כללי של הקלאסטר.
הביצועים לא נפגעו: זמן התגובה לבקשות שיא נשאר בגבולות הקודמים, והשירותים הרגישים להשהיה קיבלו מאגרים ייעודיים והפסיקו להתחרות על משאבים עם משימות הרקע. החזרה לאחור של כל שינוי — דרך היסטוריית התצורות, ומצב הקלאסטר משוחזר תוך דקות.
במה שונה אופטימיזציה ידנית מאוטומטית?
אופטימיזציה ידנית היא פעולות חד-פעמיות של מהנדס: לעיין בדוח צריכת המשאבים, לאתר משאבים שאינם בשימוש, להקטין את סוג המכונה, למחוק דיסקים ותמונות סנאפשוט שנשכחו. היא מניבה אפקט מהיר כבר בהתחלה, כאשר בתשתית הצטבר "זבל" ברור.
אך יש לה תקרה: ברגע שהבעיות הבסיסיות טופלו, השגת שיפור נוסף דורשת תשומת לב מתמדת, ותשומת הלב של הצוות אינה אינסופית. ההוצאות meanwhile ממשיכות לגדול יחד עם המוצר — סביבות חדשות, עמדות בדיקה, קפיצות בעומס.
אופטימיזציה אוטומטית מעבירה את העבודה הזו לכללים ולבדיקות שגרתיות. תזמון עוצר סביבות לא פעילות בלילה ובסופי שבוע, מדיניות שמירה מגבילה את מספר הסנאפשוטים והבניות הישנות, סקיילינג אוטומטי מתאים את המשאבים לעומס בפועל, והתראות מופעלות כאשר הצריכה חורגת מהפרופיל הרגיל.
מהירות התגובה כאן נמדדת לא בימים עד לסקירה הבאה, אלא בדקות: המערכת מזהה אנומליה ומגיבה ללא מעורבות אדם.
ההבדל המרכזי הוא ביכולת ההרחבה. הגישה הידנית תלויה באופן ליניארי במספר השירותים והסביבות: ככל שיש יותר סביבות, כך נדרש יותר זמן לביקורת, וכך עולה הסיכוי להחמיץ משהו. האוטומציה מתרחבת אחרת — הוספת שירות חדש, והוא נכנס מיד תחת אותם כללים כמו האחרים.
גם הדרישות למומחיות משתנות: במקום ניתוח ידני מתמיד נדרש מערך כללים שהוגדר פעם אחת ומתוחזק, אשר הצוות בוחן מעת לעת.
בפועל, השילוב מנצח: אופטימיזציה ידנית מאתרת עתודות מבניות גדולות — שינוי ארכיטקטורה, ויתור על שירות מיותר, מעבר לסוג משאבים מתאים יותר. האוטומציה שומרת על התוצאה ומונעת מההוצאות לחזור לרמה הקודמת.
ללא אוטומציה, השיפורים הידניים "נאכלים" במהירות על ידי צמיחת התשתית, וללא ניתוח ידני האוטומציה מייעלת רק את מה שכבר מתואר בכללים.
ספקות טכניים נפוצים
אופטימיזציה של הוצאות ענן מתבצעת כמעט תמיד מעל מערכת פעילה, ולא במקומה. לכן הספקות של מנהלים טכניים הם אותם ספקות: האם לא נשבור את התאימות, האם לא נאבד שליטה על ההרשאות, והאם לא נצטרך לבנות מחדש את תהליכי הצוות. להלן תשובות ענייניות.
האם האופטימיזציה לא תשבור את התאימות עם הסטאק והסביבות הנוכחיים?
לא. אנחנו לא מחליפים פלטפורמה ולא כותבים מחדש את האפליקציה — אנחנו עובדים עם האופן שבו היא צורכת משאבים. השינויים נוגעים לקונפיגורציה: כללי סקיילינג אוטומטי, מגבלות ובקשות למשאבים, מדיניות שמירת נתונים וגיבויים, לוחות זמנים לעצירת סביבות שאינן בשימוש.
כל אלה נבדקים בסביבת ביניים, ההתנהגות מושווית לזו הנוכחית, ורק לאחר מכן השינויים עוברים לסביבת העבודה. התאימות לאינטגרציות קיימות נשמרת.
איך זה ישפיע על האבטחה וההרשאות?
הרשאות הגישה לא מתרחבות — להיפך, ביקורת חושפת בדרך כלל הרשאות מיותרות של חשבונות שירות ומפתחות שלא בוצעה להם רוטציה. אנחנו מביאים את התפקידים לעקרון ההרשאה המינימלית הנדרשת, מפעילים תיעוד פעולות ומגדירים התראות על צריכה חריגה. הצפנת האחסון וכללי הרשת נשארים כפי שהם או מתחזקים.
האם נצטרך לשנות את תהליכי הצוות?
מה שמשתנה הוא לא תהליך הפיתוח, אלא הנראות של ההוצאות. משאבים מקבלים תגיות לפי פרויקטים ובעלים, מופיע דיווח לפי צוותים, והחלטות על גודל הסביבות מתקבלות לפי נתונים בפועל ולא לפי הערכה.
המפתחים ממשיכים לעבוד במתכונת הרגילה — רק שסביבות זמניות נעצרות כעת לפי לוח זמנים, ולא ממשיכות להתקיים חודשים.
מה אם אחרי השינויים משהו ישתבש?
כל שינוי הוא הפיך: הקונפיגורציות מנוהלות בגרסאות, ולפני היישום מתועד המצב ההתחלתי. אם המדדים נפגעים, אנחנו מחזירים את הפרמטרים הקודמים בתוך חלון תחזוקה אחד. בנפרד אנחנו בודקים את ההתנהגות תחת עומס שיא, כדי שהחיסכון לא יושג על חשבון מרווח הביצועים.
אם נותרו ספקות לגבי הסביבה הספציפית שלכם — ננתח אותה בנפרד ונחזור עם הערכה ותוכנית.
בואו נדון במשימת אופטימיזציית עלויות הענן שלכם
כדי שהשיחה תהיה עניינית ולא "ספרו לי על הענן בכלל", כדאי לראות מיד את תמונת ההוצאות שלכם. שלחו ייצוא חיוב (billing) ל-2-3 חודשים עם פירוט לפי שירותים ופרויקטים, תרשים סביבות (prod, stage, dev) ותיאור קצר של מה פועל באופן קבוע ומה עולה לפי משימות. זה מספיק כדי לראות את מקורות הבזבוז העיקריים ולחזור עם הערכה ותוכנית עבודה.
מה כדאי להכין לדיון:
- ייצוא חשבוניות לפי פרויקטים ושירותים מהחודשים האחרונים — נראה את המגמה והאנומליות.
- רשימת סביבות וייעודן — היכן ה-prod, היכן קווי הבדיקה, מי משתמש בהן.
- רשימת משאבים הפועלים באופן קבוע: בסיסי נתונים, מטמונים (caches), תורים, מאזני עומס (load balancers).
- נוהל הפעלה ועצירה של סביבות זמניות — כיצד כיום עולים ומכבים את הסביבות.
- דרישות לזמינות ולשחזור — איזו השבתה מותרת לכל שירות.
- מגבלות: הצמדה לאתר, דרישות לאחסון נתונים, התחייבויות חוזיות.
- איש קשר של המהנדס שמנהל את התשתית — כדי לברר פרטים ישירות.
לאחר הניתוח אנו מראים היכן העלויות גדלות ללא תועלת: משאבים לא פעילים, מחלקות (classes) של מופעים (instances) מנופחות, דיסקים ותמונות (snapshots) שאינם בשימוש, היעדר מדיניות מחזור חיים. לאחר מכן נתאם תוכנית עבודה — מה משנים מיד, מה דורש בדיקה ב-stage, ובאיזה סדר, כדי לא לפגוע ב-prod.
תארו את המשימה וצרפו את מה שיש בהישג יד — נחזור עם הערכה ותוכנית.