ממחקר שנערך לאחרונה על עלות השימוש בענן, עלה כי חברות משלמות בממוצע על שירותי ענן כ-35% יותר ממה שהן באמת צריכות. בעולם המודרני, מתבזבזים מעל 60 מיליארד דולר על שירותי ענן שאינם בשימוש.
לרוב בכניסה לעולם הענן יתבצעו החלטות מושכלות בנוגע לארכיטקטורה ועלויות, אך הבעיה היא, שללא ניהול ופיקוח מתמשך, תקציב הענן יכול לגדול למימדים שמבטלים את הכדאיות.
במאמר זה אשתף את מסקנותיי מתהליכי ייעול עלויות ענן שביצעתי לאחרונה ואסקור מספר דרכים וכלים להפחתה משמעותית של עלויות הענן (בסדרי גודל של 30-50%) - ללא פגיעה בביצועים. ההמלצות במאמר זה תקפות לכל ספקי הענן, אלא אם כן אציין אחרת.
לפני שמתחילים לחסוך צריך להבין את הרכב העלויות. בכל ענן ישנם כלים לניהול עלויות שמראים פילוחים שונים של עלויות לפי סוג שירות. כלים אלו יכולים לזהות אוטומטית שרתים שאינם בשימוש ולהמליץ להקטין או לכבות אותם.
● Multi-cloud
○ VMware CloudHealh
● Azure
○ Cost advisor
○ Cloudyn
● AWS
○ Trusted advisor
○ Cost management
● GCP
○ Cost management
בדר"כ שרתים מהווים את רוב עלויות הענן, ולכן נתחיל עם מספר אסטרטגיות לחיסכון בעלות שרתים. לאחר מכן, נראה כיצד ניתן לצמצם את ההצאות האחסון (Storage) והרשת (Network), ולבסוף נסקור מספר דרכים עסקיות לקבל הנחות משמעותיות על הוצאות הענן.
הנחה משוערת - 15% מעלות השרתים הכוללת
❏ לכבות שרתים שלא משתמשים בהם.
❏ Sizing - התאמת גודל השרת לכמות ועומס השימוש.
❏ הגבלת הרשאות משתמשים ליצירת שרתים חדשים.
כלים לניהול עלויות ענן יעזרו למצוא איזה שרתים כדאי לצמצם.
הנחה משוערת - 50% מעלות השרתים הפועלים לטווח ארוך
Reserved Instances (או בקיצור: RI) מאפשרים להקטין משמעותית את עלויות השרתים, בתנאי שמתחייבים לשלם עליהם לטווח של שנה או 3 שנים.
תכנית זו אינה מתאימה לשרתים זמניים שלא בטוח שנצטרך בעתיד. בדר"כ התחייבות לשנה תיתן כ-40% הנחה ואילו התחייבות לשלוש שנים תיתן כ-60% הנחה.
במידה ובכל זאת רוצים להפסיק להשתמש במכונה מהסוג שאליו התחייבתם, ישנן מספר דרכים לצאת מההתחייבות ל-RI:
❏ החלפת ההתחייבות לסוג מכונה אחרת.
❏ ביטול ה-RI ותשלום קנס יציאה.
מחישוב שעשיתי עבור Azure, משתלם יותר להתחייב ל-3 שנים עם 60% הנחה ולבטל לאחר שנה עם 12% קנס (מהיתרה), מאשר להתחייב לשנה ב 40% הנחה (לכל גודל שרת).
● https://azure.microsoft.com/en-us/pricing/details/virtual-machine-scale-sets
● https://aws.amazon.com/ec2/pricing/reserved-instances/pricing/
● https://cloud.google.com/compute/pricing
הנחה משוערת - 70% מעלות שרתים שאינם "Mission Critical"
שרתי Spot או Low Priority הם 70-90% יותר זולים משרתים רגילים באותו עוצמה! בנוסף, ההנחה כיום היא קבועה ולא לפי תהליך המכירה הפומבית שהיה נהוג בעבר.
הקטץ' הוא, ששרתים אלו נמצאים בעדיפות נמוכה ולכן קיים סיכוי שהם פתאום יסגרו ללא הודעה מוקדמת.
למזלנו, ישנם מספר דרכים להתמודד עם חוסר הוודאות הזאת:
❏ הרצת על שירותים שהם Stateless על Spot, שאינם עושים פעולות ארוכות או שפשוט אינם קריטיים. אם הם נסגרים, תמיד אפשר להרים מחדש (הדיסק לא נמחק).
❏ עבודה עם תורים: אם שרת נסגר, המשימה תישאר בתור ותחכה לשרת אחר.
❏ שימוש ב-Auto Scaling Rules שידאגו אוטומטית ל-Instance Count מסוים במידה ושרת הספוט ייסגר
❏ חברה ישראלית בשם Spotinst עוזרת להוזיל עלויות ע"י שימוש יעיל ב-Spot - יש להם דרך לזהות שרתי ספוט שעומדים ליפול, ולהחליף אותם בשרתי ספוט אחרים כמעט ללא Downtime
מבירור שעשיתי, נראה שהתמיכה שלהם ב-Azure עדיין חלקית (אין תמיכה מלאה ב-Azure k8s Service), אבל בעולם ה-AWS, התמיכה מלאה.
הנחה משוערת – 90% מעלות השרתים שפתוחים כל הזמן לזמני עומס
המערכות שלנו צריכות לעמוד בעומסים כבדים, אך אין סיבה להחזיק את כל השרתים עובדים גם בזמני רגיעה.
ארכיטקטורות Autoscaling דואגות לכך שמספר השרתים יעלה בצורה "אלסטית" בזמני עומס בלבד. ארכיטקטורת Serverless מפעילה "פונקציות" רק לפי הצורך של השרתים.
ארכיטקטורה נכונה היא אחד המרכיבים החשובים של ענן יעיל ואפקטיבי, אך היא מעבר ליריעה של מאמר זה. להמלצות ארכיטקטורה ב-Serverless וב-Cloud בכלל ראו: awesome-design-patterns
במערכות המנוהלות ע"י קוברנטיס, הקצאת המשאבים היא בדר"כ יותר יעילות וחסכוניות. פרוייקט הvirtual-kubelet יכול לחבר את קוברנטיס לפלטפורמות של Serverless Containers כמו AWS Fargate ו-Azure Container Instances
הנחה משוערת - 50% מעלות שרתי הסביבות הנמוכות
חלק נכבד מעלות השרתים יכול להיות בסביבות פיתוח, בדיקה, preprod וכו'.
ב- Azureיש הנחות על סביבות המוקצות למטרת Dev \ Test (לא מכיר תכנית מקבילה בעננים אחרים, אשמח לשמוע אם יש).
במקרים רבים, עובדים על סביבות Dev \ Test רק ביום ולכן ניתן לכבות את השרתים בלילות וסופי שבוע ובכך לחסוך מעל 50% מהמחיר. ישנם מספר כלים שיכולים לעזור עם האוטומציה של תהליך כיבוי והדלקת שרתים:
הנחה משוערת - 20% מעלויות האחסון
להלן 5 קטגוריות האחסון העיקריות בענן מסודרות מהזול ליקר (מהאיטי למהיר):
❏ Archive Storage - למשל AWS Glacier
❏ Object Storage- למשל S3 \ Blob
❏ File Storage - ספריות רשת שניתן למפות למספר שרתים
❏ Block storage - דיסקי SSD
❏ Database Storage - למשל SQL, Mongodb ועוד
גם בתוך כל קטגוריית אחסון, ישנן מספר רמות מחיר בהתאם למהירות ויתירות.
יש להפריד בין Raw Data, אותו כדאי לשמור בקטגוריית אחסון זולה ו-Metadata המשמש לשאילתות ואותו עדיף לשמור בקטגוריית אחסון יקרה.
Archive Storage היא צורת האחסון הזולה ביותר, אך היא אינה פרקטית לעבודה שוטפת עקב זמני השליפה האיטיים. מלבדArchive , צורת האחסון הזולה ביותר היא ה-Object Storage ולכן כדאי להעביר כל מה שניתן לאחסון מסוג זה.
כדאי להגדיר מדיניות "Storage Lifecycle" שמאפשרת להגדיר כללים להעברת קבצים ישנים בצורה אוטומטית לקטגוריות אחסון זולות יותר. (קיים ב AWS ונמצא ב-Preview ב-Azure)
הנחה משוערת - 20% מעלות התעבורה ברשת
תעבורת הרשת מורכבת תעבורה פנימית בתוך ה-Data Center ותעבורה חיצונית בין השרת והלקוחות.
לתעבורה פנימית אני ממליץ:
❏ לתת לתהליכים לפעול בתוך אותו אזור גיאוגרפי ככל שניתן
❏ שימוש בכתובות פנימיות בלבד
לתעבורה חיצונית אני נעזר ב-Clouflare שנותן את היתרונות הבאים:
❏ DDOS protection
❏ CDN - קבצים יורדים משרתי Cloudflare הקרובים למיקום הלקוח.
❏ כיווץ מסוג "Brotli" שעדיף על gzip.
❏ Cloudflare workers - שירות שיכול להריץ לוגיקה על requests בנקודות הקצה של Cloudflare לפני או במקום שהבקשה תגיע לרשת שלי
לספקי הענן והשותפים שלהם יש תוכניות רבות שיכולות לתת הנחות משמעותיות. לקוחות גדולים יכולים גם להתמקח ישירות עם ספקיות ענן על הנחות.
גם אם כל המערכת נמצאת על ענן אחד, לפעמים בתחומים ספציפיים כדאי להשתמש בשירותים חיצונים מתחרים כמו CDN , DNS או אפילו ענן אחר כדי להוזיל עלויות.
הנחה משוערת - 5-10% הנחה מהעלות הכוללת + ייעוץ
אין תחליף לייעוץ מארכיטקט ענן מנוסה. קיימות מספר חברות בארץ שהם שותפות של AWS \ Azure \ GCP , ועבודה איתן יכולה לתת מספר הטבות.
למשל :
❏ הנחות על העלות הכוללת של הענן
❏ תמיכה בתקלות
❏ יעוץ ארכיטקטוני
❏ כלים לניהול עלויות
❏ תנאי תשלום גמישים
● https://partner.microsoft.com/
● https://aws.amazon.com/partners/
● https://cloud.google.com/partners/
Startup programs
הנחה משוערת - קרדיט שיכול להגיע לעשרות אלפי דולרים ומעלה
לכל חברות הענן יש תוכניות שיכולות לתת הטבות לסטארטאפים.
ההטבות כוללות:
❏ קרדיט בענן
❏ שירותי ייעוץ
❏ קידום עסקי \ אקסלרטור
● https://startups.microsoft.com/en-us/
● https://aws.amazon.com/startups/
● https://cloud.google.com/developers/startups/
הנחה משוערת - שנה ראשונה חינם לשרתים קטנים
לכל ספקי הענן ישנן תכניות Free Tier. תוכניות אלה מאפשרות שימוש חינם בשירותים בדרגה הזולה ביותר למשך שנה או לפי מספר שימושים ובדר"כ אין הגבלה על מספר חשבונות ה free tier שאפשר לייצר.
● https://azure.microsoft.com/en-us/free
● https://aws.amazon.com/free/
● https://cloud.google.com/free/
* הנושאים המוזכרים לעיל משקפים את דעתי המקצועית בלבד. אין לי אפיליאציה לאף שירות שמוזכר בכתבה.
** גרסא באנגלית של כתבה זו התפרסמה ב Medium
מאת: דב אמיר
ארכיטקט ענן ומתכנת בחברת DataRails
https://twitter.com/turaaaa
https://github.com/DovAmir
ממחקר שנערך לאחרונה על עלות השימוש בענן, עלה כי חברות משלמות בממוצע על שירותי ענן כ-35% יותר ממה שהן באמת צריכות. בעולם המודרני, מתבזבזים מעל 60 מיליארד דולר על שירותי ענן שאינם בשימוש.
לרוב בכניסה לעולם הענן יתבצעו החלטות מושכלות בנוגע לארכיטקטורה ועלויות, אך הבעיה היא, שללא ניהול ופיקוח מתמשך, תקציב הענן יכול לגדול למימדים שמבטלים את הכדאיות.
במאמר זה אשתף את מסקנותיי מתהליכי ייעול עלויות ענן שביצעתי לאחרונה ואסקור מספר דרכים וכלים להפחתה משמעותית של עלויות הענן (בסדרי גודל של 30-50%) - ללא פגיעה בביצועים. ההמלצות במאמר זה תקפות לכל ספקי הענן, אלא אם כן אציין אחרת.
לפני שמתחילים לחסוך צריך להבין את הרכב העלויות. בכל ענן ישנם כלים לניהול עלויות שמראים פילוחים שונים של עלויות לפי סוג שירות. כלים אלו יכולים לזהות אוטומטית שרתים שאינם בשימוש ולהמליץ להקטין או לכבות אותם.
● Multi-cloud
○ VMware CloudHealh
● Azure
○ Cost advisor
○ Cloudyn
● AWS
○ Trusted advisor
○ Cost management
● GCP
○ Cost management
בדר"כ שרתים מהווים את רוב עלויות הענן, ולכן נתחיל עם מספר אסטרטגיות לחיסכון בעלות שרתים. לאחר מכן, נראה כיצד ניתן לצמצם את ההצאות האחסון (Storage) והרשת (Network), ולבסוף נסקור מספר דרכים עסקיות לקבל הנחות משמעותיות על הוצאות הענן.
הנחה משוערת - 15% מעלות השרתים הכוללת
❏ לכבות שרתים שלא משתמשים בהם.
❏ Sizing - התאמת גודל השרת לכמות ועומס השימוש.
❏ הגבלת הרשאות משתמשים ליצירת שרתים חדשים.
כלים לניהול עלויות ענן יעזרו למצוא איזה שרתים כדאי לצמצם.
הנחה משוערת - 50% מעלות השרתים הפועלים לטווח ארוך
Reserved Instances (או בקיצור: RI) מאפשרים להקטין משמעותית את עלויות השרתים, בתנאי שמתחייבים לשלם עליהם לטווח של שנה או 3 שנים.
תכנית זו אינה מתאימה לשרתים זמניים שלא בטוח שנצטרך בעתיד. בדר"כ התחייבות לשנה תיתן כ-40% הנחה ואילו התחייבות לשלוש שנים תיתן כ-60% הנחה.
במידה ובכל זאת רוצים להפסיק להשתמש במכונה מהסוג שאליו התחייבתם, ישנן מספר דרכים לצאת מההתחייבות ל-RI:
❏ החלפת ההתחייבות לסוג מכונה אחרת.
❏ ביטול ה-RI ותשלום קנס יציאה.
מחישוב שעשיתי עבור Azure, משתלם יותר להתחייב ל-3 שנים עם 60% הנחה ולבטל לאחר שנה עם 12% קנס (מהיתרה), מאשר להתחייב לשנה ב 40% הנחה (לכל גודל שרת).
● https://azure.microsoft.com/en-us/pricing/details/virtual-machine-scale-sets
● https://aws.amazon.com/ec2/pricing/reserved-instances/pricing/
● https://cloud.google.com/compute/pricing
הנחה משוערת - 70% מעלות שרתים שאינם "Mission Critical"
שרתי Spot או Low Priority הם 70-90% יותר זולים משרתים רגילים באותו עוצמה! בנוסף, ההנחה כיום היא קבועה ולא לפי תהליך המכירה הפומבית שהיה נהוג בעבר.
הקטץ' הוא, ששרתים אלו נמצאים בעדיפות נמוכה ולכן קיים סיכוי שהם פתאום יסגרו ללא הודעה מוקדמת.
למזלנו, ישנם מספר דרכים להתמודד עם חוסר הוודאות הזאת:
❏ הרצת על שירותים שהם Stateless על Spot, שאינם עושים פעולות ארוכות או שפשוט אינם קריטיים. אם הם נסגרים, תמיד אפשר להרים מחדש (הדיסק לא נמחק).
❏ עבודה עם תורים: אם שרת נסגר, המשימה תישאר בתור ותחכה לשרת אחר.
❏ שימוש ב-Auto Scaling Rules שידאגו אוטומטית ל-Instance Count מסוים במידה ושרת הספוט ייסגר
❏ חברה ישראלית בשם Spotinst עוזרת להוזיל עלויות ע"י שימוש יעיל ב-Spot - יש להם דרך לזהות שרתי ספוט שעומדים ליפול, ולהחליף אותם בשרתי ספוט אחרים כמעט ללא Downtime
מבירור שעשיתי, נראה שהתמיכה שלהם ב-Azure עדיין חלקית (אין תמיכה מלאה ב-Azure k8s Service), אבל בעולם ה-AWS, התמיכה מלאה.
הנחה משוערת – 90% מעלות השרתים שפתוחים כל הזמן לזמני עומס
המערכות שלנו צריכות לעמוד בעומסים כבדים, אך אין סיבה להחזיק את כל השרתים עובדים גם בזמני רגיעה.
ארכיטקטורות Autoscaling דואגות לכך שמספר השרתים יעלה בצורה "אלסטית" בזמני עומס בלבד. ארכיטקטורת Serverless מפעילה "פונקציות" רק לפי הצורך של השרתים.
ארכיטקטורה נכונה היא אחד המרכיבים החשובים של ענן יעיל ואפקטיבי, אך היא מעבר ליריעה של מאמר זה. להמלצות ארכיטקטורה ב-Serverless וב-Cloud בכלל ראו: awesome-design-patterns
במערכות המנוהלות ע"י קוברנטיס, הקצאת המשאבים היא בדר"כ יותר יעילות וחסכוניות. פרוייקט הvirtual-kubelet יכול לחבר את קוברנטיס לפלטפורמות של Serverless Containers כמו AWS Fargate ו-Azure Container Instances
הנחה משוערת - 50% מעלות שרתי הסביבות הנמוכות
חלק נכבד מעלות השרתים יכול להיות בסביבות פיתוח, בדיקה, preprod וכו'.
ב- Azureיש הנחות על סביבות המוקצות למטרת Dev \ Test (לא מכיר תכנית מקבילה בעננים אחרים, אשמח לשמוע אם יש).
במקרים רבים, עובדים על סביבות Dev \ Test רק ביום ולכן ניתן לכבות את השרתים בלילות וסופי שבוע ובכך לחסוך מעל 50% מהמחיר. ישנם מספר כלים שיכולים לעזור עם האוטומציה של תהליך כיבוי והדלקת שרתים:
הנחה משוערת - 20% מעלויות האחסון
להלן 5 קטגוריות האחסון העיקריות בענן מסודרות מהזול ליקר (מהאיטי למהיר):
❏ Archive Storage - למשל AWS Glacier
❏ Object Storage- למשל S3 \ Blob
❏ File Storage - ספריות רשת שניתן למפות למספר שרתים
❏ Block storage - דיסקי SSD
❏ Database Storage - למשל SQL, Mongodb ועוד
גם בתוך כל קטגוריית אחסון, ישנן מספר רמות מחיר בהתאם למהירות ויתירות.
יש להפריד בין Raw Data, אותו כדאי לשמור בקטגוריית אחסון זולה ו-Metadata המשמש לשאילתות ואותו עדיף לשמור בקטגוריית אחסון יקרה.
Archive Storage היא צורת האחסון הזולה ביותר, אך היא אינה פרקטית לעבודה שוטפת עקב זמני השליפה האיטיים. מלבדArchive , צורת האחסון הזולה ביותר היא ה-Object Storage ולכן כדאי להעביר כל מה שניתן לאחסון מסוג זה.
כדאי להגדיר מדיניות "Storage Lifecycle" שמאפשרת להגדיר כללים להעברת קבצים ישנים בצורה אוטומטית לקטגוריות אחסון זולות יותר. (קיים ב AWS ונמצא ב-Preview ב-Azure)
הנחה משוערת - 20% מעלות התעבורה ברשת
תעבורת הרשת מורכבת תעבורה פנימית בתוך ה-Data Center ותעבורה חיצונית בין השרת והלקוחות.
לתעבורה פנימית אני ממליץ:
❏ לתת לתהליכים לפעול בתוך אותו אזור גיאוגרפי ככל שניתן
❏ שימוש בכתובות פנימיות בלבד
לתעבורה חיצונית אני נעזר ב-Clouflare שנותן את היתרונות הבאים:
❏ DDOS protection
❏ CDN - קבצים יורדים משרתי Cloudflare הקרובים למיקום הלקוח.
❏ כיווץ מסוג "Brotli" שעדיף על gzip.
❏ Cloudflare workers - שירות שיכול להריץ לוגיקה על requests בנקודות הקצה של Cloudflare לפני או במקום שהבקשה תגיע לרשת שלי
לספקי הענן והשותפים שלהם יש תוכניות רבות שיכולות לתת הנחות משמעותיות. לקוחות גדולים יכולים גם להתמקח ישירות עם ספקיות ענן על הנחות.
גם אם כל המערכת נמצאת על ענן אחד, לפעמים בתחומים ספציפיים כדאי להשתמש בשירותים חיצונים מתחרים כמו CDN , DNS או אפילו ענן אחר כדי להוזיל עלויות.
הנחה משוערת - 5-10% הנחה מהעלות הכוללת + ייעוץ
אין תחליף לייעוץ מארכיטקט ענן מנוסה. קיימות מספר חברות בארץ שהם שותפות של AWS \ Azure \ GCP , ועבודה איתן יכולה לתת מספר הטבות.
למשל :
❏ הנחות על העלות הכוללת של הענן
❏ תמיכה בתקלות
❏ יעוץ ארכיטקטוני
❏ כלים לניהול עלויות
❏ תנאי תשלום גמישים
● https://partner.microsoft.com/
● https://aws.amazon.com/partners/
● https://cloud.google.com/partners/
Startup programs
הנחה משוערת - קרדיט שיכול להגיע לעשרות אלפי דולרים ומעלה
לכל חברות הענן יש תוכניות שיכולות לתת הטבות לסטארטאפים.
ההטבות כוללות:
❏ קרדיט בענן
❏ שירותי ייעוץ
❏ קידום עסקי \ אקסלרטור
● https://startups.microsoft.com/en-us/
● https://aws.amazon.com/startups/
● https://cloud.google.com/developers/startups/
הנחה משוערת - שנה ראשונה חינם לשרתים קטנים
לכל ספקי הענן ישנן תכניות Free Tier. תוכניות אלה מאפשרות שימוש חינם בשירותים בדרגה הזולה ביותר למשך שנה או לפי מספר שימושים ובדר"כ אין הגבלה על מספר חשבונות ה free tier שאפשר לייצר.
● https://azure.microsoft.com/en-us/free
● https://aws.amazon.com/free/
● https://cloud.google.com/free/
* הנושאים המוזכרים לעיל משקפים את דעתי המקצועית בלבד. אין לי אפיליאציה לאף שירות שמוזכר בכתבה.
** גרסא באנגלית של כתבה זו התפרסמה ב Medium
מאת: דב אמיר
ארכיטקט ענן ומתכנת בחברת DataRails
https://twitter.com/turaaaa
https://github.com/DovAmir
הודעתך לא התקבלה - נסה שוב מאוחר יותר
Oops! Something went wrong while submitting the form