אופטימיזציה של עלות תשתית ענן: AWS, GCP, Azure

מדוע אופטימיזציה של עלויות ענן אינה מניבה תוצאה

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

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

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

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

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

אפקט מדיד: מהירות פריסה, כשלים, זמן השבתה

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

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

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

מצבי ניהול הוצאות: השוואת גישות

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

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

סדר העבודה: ביקורת, תרשים, כוונון, בדיקה

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

1. ביקורת תשתית — אוספים מפת משאבים: מכונות, דיסקים ותמונות מצב, מאזני עומס, רישומי אימג'ים, בסיסי נתונים ותורים. משווים את הרשימה למטריקות צריכה של כמה חודשים: כך רואים צמתים לא מנוצלים ומשאבים שנשכחו אחרי ניסויים.
2. תרשים תשתית — גרף תלויות: מי מחליף תעבורה עם מי, היכן נמצאים המטמון והאחסון המשותפים, ואילו שירותים משכפלים זה את זה. בלי התרשים הזה, כיבוי של «מיותר» שובר את הסביבה הסמוכה.
3. תוכנית שינויים — מסדרים את השינויים לפי יחס אפקט-סיכון: תחילה מה שנותן נפח בלי להשפיע על הפרודקשן, אחר כך כל מה שדורש חלון תחזוקה.
4. מצבי תעריף ואחסון — בסיס יציב עובר להזמנה מראש, חלק משתנה נשאר לפי צריכה בפועל; נתונים קרים עוברים למחלקות אחסון זולות.
5. כוונון מגבלות — מכסות לצוותים ולסביבות, ספי התאמה אוטומטית עם הגנה מפני התרחבות יתר, כללי lifecycle: N האימג'ים ותמונות המצב האחרונים נשמרים, השאר נמחקים.
6. בדיקה תחת עומס — פרופיל תעבורה אמיתי: ההתאמה פועלת בזמן, המגבלות אינן חותכות שיאים, ועמידות בפני כשלים נשמרת ביציאת צומת. בנוסף, התראות על סטייה של ההוצאות מהדינמיקה המתוכננת.
7. מסירה לתחזוקה — דשבורדים, נוהל שינויים, תיעוד והדרכת הצוות. הלקוח רואה על מה הוא משלם ומחזיק את המצב בעצמו.

מדיניות גישה, תרשימים ונוהלי תחזוקה

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

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

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

מקרה בוחן: ניתוח תשתית, מטריקות לפני ואחרי

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

מה הראו המדידות

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

מה שינו ומה התקבל

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

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

תוצאת ההטמעה: שיעור הזמן הלא מנוצל ירד מ-38% ל-9%, עומס העבודה של המכונות עלה ל-62–68%, פריסת גרסה התקצרה מ-40 ל-9 דקות, ושיעור הכשלים בפריסה — מ-6% ל-0.3%. עומס המוצר גדל פי 2.4 עם אותה כמות יחידות מחשוב.

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

מה לעשות אם התשתית כבר פרוסה וגדלה

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

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

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

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

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

ספקות טכניים: שאלות נפוצות של מהנדסים

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

מי אחראי לנתונים שלנו?

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

ואם את התשתית לא פרסתם אתם ואין תיאור?

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

כמה זמן זה לוקח והאם ניתן להחזיר כפי שהיה?

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

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

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

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

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

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