במסמך הזה מוסבר איך לצמצם את העלויות של סביבותGoogle Cloud אזוריות ורב-אזוריות, ושל העברות בין Google Cloud אזורים. המסמך הזה שימושי אם אתם מתכננים לבצע אחד מסוגי המעברים האלה, או אם אתם בודקים את האפשרות לעשות זאת בעתיד ורוצים לדעת איך זה ייראה.
המסמך הזה הוא חלק מסדרה של כמה מאמרים בנושא מעבר אלGoogle Cloud:
- העברה אל Google Cloud: איך מתחילים
- מעבר אל Google Cloud: הערכה וגילוי של עומסי העבודה
- מעבר אל Google Cloud: תכנון ובניית הבסיס
- מעבר אל Google Cloud: העברת מערכי נתונים גדולים
- העברה אל Google Cloud: פריסת עומסי העבודה
- העברה אל Google Cloud: מעבר מפריסות ידניות לפריסות אוטומטיות שמבוססות על קונטיינרים
- מעבר אל Google Cloud: אופטימיזציה של הסביבה
- מעבר ל- Google Cloud: שיטות מומלצות לאימות של תוכנית העברה
- מעבר אל Google Cloud: צמצום העלויות (המסמך הזה)
במסמך הזה מוסבר על הנושאים הבאים:
- הערכת העלויות הנוכחיות והצפי לצמיחה שלGoogle Cloud הנוכחות שלכם.
- הגדרת הדרישות והיעדים שלכם לצמצום העלויות.
- הטמעה של תהליכי ניהול עלויות והפחתת עלויות.
- אימוץ של Cloud FinOps Framework.
ההנחה היא שקראתם את המאמר מעבר אל Google Cloud: אופטימיזציה של הסביבה ואתם מכירים את התוכן שלו. במסמך הזה מוסבר איך לתכנן ולהטמיע לולאת אופטימיזציה (תהליך אופטימיזציה מתמשך) אחרי מעבר ל-Google Cloud. ברוב המקרים, השלבים האלה רלוונטיים גם לצמצום העלויות.
הערכת העלויות
כדי להבין באופן מקיף את צריכת המשאבים שלכם ולזהות הזדמנויות פוטנציאליות לצמיחה, חשוב להעריך את העלויות הנוכחיות והצפויות של סביבות Google Cloud.
כדי להעריך את העלויות הנוכחיות והצפויות, אפשר:
- הערכת העלות של סביבות Google Cloud הנוכחיות.
- הערכת העלות של העברות עתידיות בין Google Cloud אזורים.
- תחזית הצמיחה של Google Cloud הפעילות שלכם.
הערכת העלות של הסביבות הנוכחיות
כדי להבין באופן מקיף את העלויות של הסביבות שלכם, כדאי לשים לב לנקודות הבאות:
- Google Cloud מודל החיוב. Google Cloud משתמש במודל שקוף ויעיל לחיוב על שימוש במשאבים. כדי להבין באופן מלא איך המודל פועל ואיך מתבצע החיוב על צריכת משאבים, מומלץ לקרוא על Google Cloud מודל החיוב ועל תמחור המוצרים. Google Cloud
- חיוב ב-Cloud. כדי להעריך את העלויות הנוכחיות והצפויות של הסביבות, מומלץ להשתמש בחיוב ב-Cloud, אוסף של כלים שעוזרים לעקוב אחרי ההוצאות הנוכחיות והצפויות ב-Google Cloud , לשלם את החשבון ולבצע אופטימיזציה של העלויות. לדוגמה, אפשר ליצור תקציבים והתראות תקציב.
- הנחות. Google Cloud הנחות תמורת התחייבות לשימוש (CUD) מוצעות בתמורה להתחייבות להשתמש בכמות מינימלית של משאבים בפרק זמן מסוים. כדי להעריך את העלות של הסביבות הנוכחיות, מומלץ לאסוף מידע על הנחות על שימוש בהתחייבות שרכשתם, ועל המוצרים, השירותים והמשאבים שההנחות חלות עליהם.
- טביעת רגל פחמנית. Google Cloud תומך במדידה ודיווח של טביעת הרגל הפחמנית של הסביבות הנוכחיות שלכם. המידע הזה שימושי ליצירת נתון בסיסי שאפשר להשוות אליו את טביעת הרגל הפחמנית שלכם, כדי לצמצם אותה במסגרת המאמצים שלכם להוזלת העלויות.
מידע נוסף על הגדרת משאבים לניהול הרשאות גישה ועלויות זמין במאמר מדריך בנושא ארגון משאבים וניהול הרשאות גישה בחיוב ב-Cloud.
הערכת העלות של העברות עתידיות בין אזורים
אם אתם שוקלים לבצע העברה בין Google Cloud אזורים, מומלץ לבדוק איך ההעברה הזו עשויה להשפיע על העלויות שלכם. כדי להעריך כמה תעלה העברה בין אזורים, כדאי להביא בחשבון את הפרטים הבאים:
- המחיר של משאבי Google Cloud באזור היעד. כשמעבירים עומסי עבודה, נתונים ותהליכים ביןGoogle Cloud אזורים, סביר להניח שתצטרכו להקצות משאבים באזור היעד. אתם יכולים להשתמש בGoogle Cloud מחשבון התמחור כדי להעריך כמה יעלה הקצאת משאבים חדשים והעברת נתונים לאזור חדש של Google Cloud .
- העלות של משאבים ב-Google Cloud בכמה אזורים. כדי לעמוד בדרישות האמינות שלכם, יכול להיות שתצטרכו להשתמש במשאבים בכמה אזורים. מומלץ לבדוק איך המשאבים האלה עשויים להשפיע על המיגרציה ועל העלויות שלה. לדוגמה, אתם משתמשים בקטגוריות של Cloud Storage שפועלות במספר אזורים או בשני אזורים, ואחת מהקטגוריות האלה נמצאת באותו אזור כמו אזור היעד של ההעברה. במקרה כזה, יכול להיות שלא תצטרכו להעביר נתונים בקטגוריות האלה כי Cloud Storage מטפל בשכפול הנתונים בשבילכם.
- תנועת הנתונים היוצאת מהרשת. בנוסף לעלות של הקצאת משאבים ותחזוקה שלהם, העברת נתונים מאזור אחד לאזור אחר עשויה להיות כרוכה בעלויות של תעבורת נתונים יוצאת (egress) ברשת. Google Cloud מומלץ לבדוק את העלויות המשוערות האלה כדי להימנע מחיובים לא צפויים.
- הזמן, ההדרכה ועלויות נוספות. העלות של העברה בין אזורים כוללת יותר מהעלויות שקשורות להקצאת משאבים ולהעברת נתונים. יש גם עלויות נלוות, כמו הזמן וההדרכה שנדרשים לצוותים שלכם כדי לתכנן את ההעברה ולהשלים אותה. כשמעריכים את עלויות ההעברה, מומלץ לקחת בחשבון גם את העלויות הנלוות.
בנוסף להמלצות האלה, Google Cloud מציעה את Google Cloud תוכנית ההערכה וההעברה המהירה. במסגרת התוכנית הזו, תקבלו הערכות חינם של עלויות ההעברה, והדרכה לאורך כל תהליך ההעברה בעזרת שירותים מקצועיים ושותפים של Google CloudGoogle.
תחזית הצמיחה של Google Cloud הפעילות שלכם
במסגרת התחזוקה השוטפת של הסביבות, מומלץ לעקוב באופן רציף אחרי העלויות של הסביבות. סוג כזה של מעקב מספק את המידע שדרוש לכם כדי ליצור תהליכים של ניהול עלויות. המעקב הזה גם מאפשר לכם להתעדכן בעלויות הנוכחיות של הסביבות ובתחזית לטווח הקצר.
בנוסף לתחזוקה שוטפת של הסביבות, מומלץ גם לגבש אסטרטגיית צמיחה לטווח ארוך. אסטרטגיה כזו מאפשרת לכם לתכנן טוב יותר את התקציבים ואת המשאבים שנדרשים כדי להרחיב את הנוכחות שלכם באופן אורגני בהתאם לצרכים העסקיים שלכם. Google Cloudכדי לפתח אסטרטגיית צמיחה לטווח ארוך, כדאי לשקול את הדברים הבאים:
- דרישות עסקיות. בודקים אם הסביבות עדיין תואמות לדרישות העסקיות שהן נועדו לתמוך בהן. לדוגמה, אם אתם צופים עלייה בביקוש בתחומים מסוימים בעסק, כדאי לבדוק את האפשרויות להרחבת הסביבות שתומכות בתחומים האלה.
- מגמות ותבניות. כדאי להשתמש ב-Google Cloud Observability כדי להעריך את נתוני המעקב, הרישום בפנקס והפרופילים של הביצועים שמשויכים לעומסי העבודה, לנתונים ולתהליכים שלכם. בעזרת הניתוח הזה תוכלו לגלות מגמות, להסיק דפוסי ביקוש ותנועה ולקבל תובנות שימושיות לגבי המגמות האלה.
- צמיחה רציפה. להעריך את מידת הצמיחה שהסביבות הנוכחיות יכולות לתמוך בה, ובאיזה שלב תצטרכו לתכנן, להקצות ולהגדיר סביבות נוספות. לדוגמה, אם העלויות של הרחבת סביבה קיימת גבוהות מהיתרונות שצומחים מההרחבה הזו, כדאי לשקול הקצאת סביבה חדשה במקום זאת. כשמעריכים את מידת הצמיחה שהסביבות הנוכחיות יכולות לתמוך בה, חשוב לקחת בחשבון את ההשפעה של הצמיחה הזו על טביעת הרגל הפחמנית של הסביבות. מידע נוסף זמין במאמר בנושא טביעת רגל פחמנית.
הגדרת הדרישות והיעדים שלכם לצמצום העלויות
אחרי שמשערים את הצמיחה של Google Cloud הנוכחות שלכם, מומלץ להגדיר את הדברים הבאים:
- הדרישות להפחתת עלויות. דרישה מבטאת צורך בשיפור, ולא בהכרח צריכה להיות ניתנת למדידה. הגדרת הדרישות האלה מאפשרת לכם לציין את התחומים שבהם אתם רוצים למקד את המאמצים שלכם להפחתת העלויות.
- יעדים של צמצום עלויות. יעד הוא מאפיין מדיד שעשוי לתרום לדרישה אחת או יותר. הגדרת יעדים מדידים מאפשרת למדוד את המאמצים שלכם לצמצום העלויות, ולבצע הערכה מתמשכת של המצב הנוכחי ביחס ליעדים האלה.
מידע נוסף על הדרישות והיעדים ועל ההגדרה שלהם זמין במאמר הגדרת הדרישות והיעדים לאופטימיזציה.
כדי להגדיר את הדרישות להפחתת העלויות, מומלץ להתחיל בהגדרה של סוגי העלויות שצריך לשפר בסביבות שלכם. לדוגמה, דרישה להפחתת עלויות יכולה להיות הפחתת העלות של שירותי מחשוב.
אחרי שקובעים את הדרישות להפחתת העלויות ומוודאים שהן ריאליות, מגדירים יעדים מדידים להפחתת העלויות לכל דרישה. קבוצת היעדים שרלוונטית לדרישה מסוימת צריכה לאפשר לכם להגדיר באופן מלא את כל המאפיינים של הדרישה הזו, ולמדוד את ההתקדמות שלכם לעמידה בדרישה. לדוגמה, נניח שאתם צריכים להפחית את העלות של שירותי מחשוב. כדי לעמוד בדרישה הזו, אפשר להגדיר יעד של צמצום העלויות של מופעי Compute Engine ב-5%.
אחרי שקובעים את הדרישות והיעדים להפחתת העלויות, מומלץ להסתמך על הנתונים שנאספו במהלך שלב הערכת העלויות כדי לבדוק את ההיתכנות של כל דרישה. לדוגמה, אפשר להשתמש בנתוני ההערכה כדי לבדוק אם אפשר להשיג את היעד הקודם של צמצום העלויות של מופעי Compute Engine ב-5%. כלומר, להשתמש בנתוני ההערכה כדי להבין אם אפשר להשיג את היעד הזה באמצעות שינויים קטנים בסביבות ובתהליכים, או שצריך לשנות את העיצוב שלהם באופן משמעותי.
הטמעה של תהליכי ניהול עלויות והפחתת עלויות
במהלך שלב הערכת העלויות, אספתם מידע על ההוצאות הנוכחיות וההוצאות לטווח הקצר. לאחר מכן, הגדרתם את הדרישות והיעדים שלכם להפחתת עלויות, ושרטטתם את הדרך להפחתת העלויות. שתי הפעילויות האלה נחוצות כדי לפתח אסטרטגיות ארוכות טווח להפחתת העלויות, ולהרחבת הנוכחות שלכם בשוק והעסק שאתם מנהלים. Google Cloudעם זאת, הפעילויות האלה לבדן לא מספיקות כדי להטמיע את התכונה. כדי להטמיע את האסטרטגיות האלה, צריך גם תהליכים של ניהול עלויות וצמצום עלויות.
מומלץ לבצע את התהליכים האלה של ניהול עלויות והפחתת עלויות לפי הסדר הבא:
- מעקב אחרי העלויות.
- שליטה בהקצאת משאבים.
- להפחית את העלויות.
מעקב אחרי העלויות
כדי לשמור על שליטה בעלויות, חשוב לעקוב באופן רציף אחרי החיוב ומגמות העלויות בסביבות שלכם. מומלץ לבצע את הפעולות הבאות:
- כדאי לעיין בדוחות החיוב באופן קבוע. בחיוב ב-Cloud יש דוחות מובנים על עלויות השימוש, פרטים על החשבוניות ודפי החשבון, פירוט עלויות וטבלאות תמחור. כדי להבין את העלויות בצורה מקיפה ועדכנית, מומלץ לעיין בדוחות החיוב האלה באופן קבוע. אם אתם צריכים לקבל תובנות נוספות מעבר למה שמספקים הדוחות המובנים של החיוב ב-Cloud, אתם יכולים לייצא את נתוני החיוב ל-BigQuery כדי לבצע ניתוח נוסף.
- הגדרת תוויות ותגים. תוויות ותגים הם צמדי מפתח/ערך שאפשר לצרף למשאבים ב- Google Cloud. אתם יכולים להשתמש בצמדי מפתח/ערך האלה כדי להטמיע דוחות משלכם למעקב אחרי עלויות ולניתוח שלהן, בנוסף למה שמופיע בחיוב ב-Cloud. לדוגמה, אפשר לפרק את העלויות לפי תווית, או לבצע החזרים כספיים, ביקורות וניתוחים אחרים של הקצאת עלויות לפי תגים. מידע נוסף על ההבדלים בין תוויות לתגים זמין במאמר תגים ותוויות.
- הגדרת התראות לגבי תקציב הגדרת תקציבים והתראות על תקציבים יכולה לעזור לכם לעקוב אחרי העלויות בפועל ולהשוות אותן לעלויות המתוכננות. כדי למנוע עלויות לא צפויות, מומלץ להגדיר תקציב והתראות תקציב כדי שיהיה לכם מספיק זמן לפעול במהירות.
שליטה בהקצאת משאבים
Google Cloud תומך בכלים שונים להקצאת משאבים, כמו Google Cloud מסוף, Google Cloud SDK, Cloud APIs וספקי Terraform, מודולים ומשאבים. המשתמשים בארגון יכולים להשתמש בכלים האלה כדי להקצות משאבים בסביבות שלכם. הקצאת משאבים נוספים Google Cloud או שינוי גודל של משאבים קיימים עשויים לגרום לשינויים בהוצאות. מידע נוסף מפורט בתמחור של כל משאב.
כדי להימנע מהוצאות בלתי צפויות ובלתי מבוקרות, מומלץ לתכנן וליישם תהליכים לבקרה על הקצאת משאבים. כדי ליישם את התהליכים האלה, כדאי לשקול את הדברים הבאים:
- אימוץ תשתית כקוד. ניהול התשתית כקוד מאפשר לכם לנהל את ההקצאה וההגדרה של משאביGoogle Cloud כמו קוד אפליקציה. אתם יכולים גם להשתמש בתהליכי האינטגרציה הרציפה, הפריסה הרציפה והביקורת הקיימים שלכם. לדוגמה, אתם יכולים לנהל את התשתית שלכם כקוד באמצעות Terraform, וגם לאכוף את התאימות למדיניות כחלק מצינור האינטגרציה הרציפה שלכם.
- בדיקת השינויים לפני שמחילים אותם. כדי להימנע משינויים לא צפויים בהוצאות, מומלץ להטמיע תהליכים לבדיקת שינויים בסביבות לפני שמחילים אותם, בלי קשר לכלי שבו משתמשים להקצאת משאבים ולשינוי גודלם. Google Cloud לדוגמה, אם אתם משתמשים בתשתית כקוד, אתם יכולים להוסיף שלב של בדיקה אנושית לפני שמחילים שינוי משמעותי כלשהו על Google Cloudהמשאבים שתומכים בסביבות שלכם.
תיעוד של הסביבות וזיהוי של סטיות. כשמבצעים הקצאת משאבים ומגדירים את הסביבות שלכם, מומלץ לתעד את הפרטים הבאים לגבי כל סביבה: Google Cloud
- מאפייני הסביבה.
- המשאבים Google Cloud שאתם מקצים ומגדירים בסביבה הזו.
- המצב המועדף של כל אחד מהמשאבים האלה.
תיעוד המאפיינים של הסביבות מקל על ביצוע ביקורת על המצב הנוכחי של הסביבות. בנוסף, בעזרת התיעוד תוכלו לתכנן וליישם תהליכים לזיהוי סטיות מהמצב המועדף, ולנקוט פעולות מתקנות בהקדם האפשרי. לדוגמה, אתם יכולים להשתמש במאגר משאבי ענן כדי לנתח את כל הנכסים שלכם בפרויקטים ובשירותים שונים. Google Cloud לאחר מכן תוכלו להשוות את הניתוח הזה למצב המועדף של כל סביבה, להוציא משימוש באופן יזום משאבים לא מנוהלים ולהחזיר משאבים מנוהלים למצב המועדף שלהם.
הגדרת כללי מדיניות ארגוניים. כדי להגדיר אמצעי בקרה והגבלות על אופן השימוש במשאבים של הארגון, וכדי למנוע שימוש לרעה שעלול להוביל לחיובים לא מכוונים, אפשר להשתמש בשירות של מדיניות הארגון כדי לאכוף אילוצים. לדוגמה, אתם יכולים להגביל את השימוש במוצרי Google Cloudמסוימים, או להגביל את היצירה של משאבים מסוימים. מידע נוסף על האילוצים ש- Google Cloud תומך בהם זמין במאמר אילוצים של מדיניות הארגון.
הגדרת מכסות. Google Cloud משתמשת במכסות כדי להגביל את כמות השימוש במשאב משותף של Google Cloud . כדי להגביל את השימוש במשאבים מסוימים, אתם יכולים להגדיר מגבלות משלכם במכסות עד למכסה המקסימלית. לדוגמה, אתם יכולים למנוע יצירה של מופעים של Compute Engine מעבר למספר מסוים על ידי הגבלת מספר המופעים של Compute Engine שיכולים להתקיים באזור מסוים.
שימוש בשיטות למתן גישה עם הרשאות מינימליות. כדי למנוע בעיות של הסלמת הרשאות (privilege escalation) שבהן משתמשים במשאבים שלכם מעלים את רמת ההרשאות שלהם ועוקפים את הבדיקות, מומלץ להעניק למשתמשים ולחשבונות שירות את כמות ההרשאות המינימלית. Google Cloud לדוגמה, אפשר לתת למשתמשים ולחשבונות שירות את ההרשאות המינימליות שנדרשות באמצעות IAM.
צמצום העלויות
מעקב אחרי העלויות של הסביבות והטמעה של תהליכים לשליטה בהקצאת משאבים עוזרים לכם:
- שליטה בעלויות הנוכחיות והצפויות של הסביבות.
- הימנעות מעלויות בלתי צפויות ובלתי נשלטות.
- מספקים בסיס עלויות שבו אפשר להשתמש כדי לנסות לצמצם עלויות.
במסמך הזה, צמצום עלויות מתייחס לתכנון ולהטמעה של תהליכים ומנגנונים שמטרתם לעזור לכם להשיג את היעדים שלכם לצמצום עלויות. אתם יכולים לתכנן את התהליכים האלה כך שיהיו ריאקטיביים (כלומר, יפעלו כתוצאה מפעולה אחרת או משינוי סטטוס), או פרואקטיביים (כלומר, יפעלו מתוך ציפייה לפעולות אחרות או לשינויי סטטוס). לרוב, ההמלצות בקטע הזה רלוונטיות לתהליכים תגובתיים ופרואקטיביים. בנוסף, תהליכים רבים להפחתת עלויות יכולים להיות גם וגם.
כדי לתכנן וליישם תהליכים לצמצום עלויות, כדאי לשקול את ההמלצות הבאות:
- הערכת הנחות על שימוש. Google Cloud מציעה כמה אפשרויות לצמצום העלויות על סמך דפוסי השימוש במשאבי Google Cloud. לדוגמה, אתם יכולים לקבל גישה למחירים מוזלים בתמורה להתחייבות להשתמש בכמות מינימלית של משאבים בפרק זמן מסוים באמצעות הנחות תמורת התחייבות לשימוש. חלק מהשירותים Google Cloud מציעים הנחות על משאבים שבהם אתם משתמשים למשך פרק זמן מסוים או ברמה מסוימת. לדוגמה, ב-Compute Engine יש הנחות על שימוש קבוע על משאבים שנעשה בהם שימוש למשך יותר מתקופה מסוימת של מחזור החיוב.
- הוצאה משימוש של משאבים לא נחוצים. הדרישות העסקיות משתנות עם הזמן, ולכן גם הסביבות שתומכות בדרישות האלה משתנות. כחלק מההתפתחות הזו, יכול להיות שבסביבות שלכם יהיו משאבים מיותרים, או משאבים שניתנים להרחבה לרמות לא נחוצות. כדי לצמצם את עלויות השימוש שמשויכות למשאבים לא נחוצים, מומלץ להעריך את ההשפעה של כל משאב לא נחוץ על העלויות, ולבדוק איך הוצאה משימוש של המשאבים האלה עשויה להשפיע על הסביבות שלכם. לדוגמה, אתם יכולים להציג וליישם המלצות לגבי משאבים לא פעילים והמלצות לגבי מכונות וירטואליות לא פעילות כדי לזהות משאבים ומכונות וירטואליות ב-Compute Engine שלא נמצאים בשימוש, ובסופו של דבר להוציא אותם משימוש.
- התאמת גודל של משאבים שהוקצו להם יותר מדי משאבים. כדי להימנע משימוש חלקי במשאב שהקציתם והגדרתם, מומלץ לבדוק את הסביבות שלכם כדי להעריך אם יש משאבים שצריך לשנות את הגודל שלהם.Google Cloud התאמת המשאבים עשויה להוביל לצמצום עלויות. לדוגמה, אתם יכולים להשתמש בנתונים ש-Google Cloud Observability מספק כדי להעריך את כמות השימוש במשאב מסוים, ולבדוק אם יש מקום להתאמת הגודל של המשאבים האלה. דוגמה נוספת לשינוי גודל המשאבים היא יישום המלצות לגבי סוג המכונה עבור מופעים של Compute Engine.
- הגדרת שינוי גודל אוטומטי הרבה Google Cloud שירותים תומכים בהגדלה אוטומטית של המשאבים בהתאם לביקוש. התאמה אוטומטית לעומס (autoscaling) עוזרת לכם לצמצם עלויות על ידי שינוי גודל Google Cloud המשאבים בהתאם לביקוש הנוכחי. לדוגמה, ב-Compute Engine יש שינוי גודל אוטומטי שמאפשר להוסיף או להסיר מכונות באופן אוטומטי מקבוצות של מכונות מנוהלות בהתאם לעומס.
- מעבר לשירותים מנוהלים. כדי לעזור לכם להפחית את העלויות התפעוליות ולמנוע עבודת פרך, כדאי לשקול מעבר משירותים בניהול עצמי לשירותים שמנוהלים על ידי Google. ל-Google יש עשרות שנות ניסיון בהפעלת מערכות מבוזרות בקנה מידה עולמי, והיא מעמידה את הניסיון הזה לרשות לקוחותGoogle Cloud שמשתמשים בשירותים מנוהלים Google Cloud. לדוגמה, אם אתם מפעילים אשכול Kubernetes בניהול עצמי ב-Compute Engine, כדאי לשקול מעבר ל-Google Kubernetes Engine (GKE). מעבר ל-GKE יכול לפנות משאבים שצוותי התפעול יכולים להפנות למאמצים אחרים, כמו שיפור היעילות של הסביבות והפחתת העלויות שלהן.
- לזהות דפוסים. בנוסף לתכונות של התאמה אוטומטית לעומס ש-Google Cloud מציע, אפשר גם להעריך את הנתונים ש-Google Cloud Observability מספק כדי להסיק דפוסי שימוש ותנועה שיעזרו לכם לבנות מודלים של דרישות משאבים. יצירת המודלים האלה יכולה לעזור לכם לתכנן ולהטמיע תהליכים יזומים להפחתת עלויות, שמבוססים על התובנות שמתקבלות מהמודלים. לדוגמה, יכול להיות שתגלו שחלק מהסביבות שלכם נהנות מביקוש גבוה רק בתקופות מסוימות ביום או בשבוע. לכן, אתם יכולים להגדיל את הקיבולת של הסביבות האלה מראש לקראת התקופות האלה, ולהקטין אותה כשאין בהן צורך.
- תזמון יעיל של עומסי עבודה בעדיפות נמוכה. בדרך כלל, לא כל עומס העבודה שפועל בסביבות שלכם הוא בעדיפות גבוהה וקריטי לעסק. כדי להפחית עלויות, אפשר לנצל את העובדה שעומסי העבודה האלה לא קריטיים. לדוגמה, אתם יכולים להשבית את עומסי העבודה האלה ואת המשאבים שקשורים אליהם כשאין בהם צורך. לחלופין, אפשר להריץ אותם בסביבות זמן ריצה משתלמות יותר, כמו מכונות וירטואליות מסוג Spot, במקום להריץ אותם ב-Compute Engine או ב-GKE.
- ניהול מחזור החיים של הנתונים. הנתונים שמאוחסנים בסביבות שלכם יכולים להצטבר לכמויות משמעותיות בפרקי זמן קצרים. כדי לעזור לכם לצמצם את העלויות, מומלץ לתכנן ולהטמיע תהליכים לניהול אוטומטי של מחזור החיים של הנתונים, בדיוק כמו שאתם עושים עם משאביGoogle Cloud . לדוגמה, אתם יכולים לתכנן וליישם תהליכים למחיקת נתונים לא נחוצים. אפשר גם ליצור נתונים מצטברים מנתונים מפורטים יותר ולהעביר רק את הנתונים המצטברים לאחסון לטווח ארוך. אפשר גם להעביר נתונים שאתם צריכים בתדירות נמוכה יותר למערכות זולות יותר שמיועדות לגישה לא תדירה. בנוסף, חלק Google Cloud מהשירותים תומכים בניהול אוטומטי של מחזור החיים של אובייקטים. לדוגמה, ב-Cloud Storage יש ניהול מחזור חיים של אובייקטים שמאפשר לבצע באופן אוטומטי פעולות ניהול אופייניות של מחזור החיים של אובייקטים, וסיווג אוטומטי שמאפשר להעביר באופן אוטומטי אובייקטים לסוגי אחסון (storage class) מתאימים על סמך תדירות הגישה לכל אובייקט.
- הפחתת העלויות של שירותים ספציפיים Google Cloud .Google Cloud מספק הנחיות להפחתת העלויות ולאופטימיזציה שלהן כשמשתמשים בשירותים ספציפיים Google Cloud כמו Compute Engine, GKE ו-Cloud Storage. מידע נוסף על אופטימיזציה של עלויות של מוצרים ספציפיים זמין במאמר Google Cloud Well-Architected Framework: הוזלת העלויות. Google Cloud
ההמלצות הקודמות רלוונטיות לכל מקרה, בלי קשר לאופן שבוGoogle Cloud המשאבים שלכם מפוזרים בין אזורים ותחומים. כדי ללמוד איך להפחית את העלויות של סביבות חד-אזוריות ורב-אזוריות, כדאי להמשיך לקרוא את המאמר הזה.
צמצום העלויות של סביבות עם אזור יחיד
בסביבות של אזור יחיד,המשאבים מפוזרים בדרך כלל בכמה תחומים באותו אזור בלבד. Google Cloud חלוקת המשאבים בין כמה אזורים באזור מסוים עוזרת לצמצם את ההשפעות של הפסקות זמניות בשירות בתחום, וכך למזער את ההשפעה של ההפסקות האלה על העסק שלכם. לדוגמה, אם מריצים עומס עבודה במכונה ב-Compute Engine, ויש הפסקת חשמל בתחום שמשפיעה על התחום שבו הקציתם את המכונה הזו, יכול להיות שעומס העבודה יושפע מההפסקה. אם יש לכם כמה עותקים של עומס העבודה הזה שפועלים במכונות של Compute Engine באזורים שונים, הסיכוי שעומס העבודה ייפגע בגלל הפסקת חשמל אזורית נמוך יותר. בדרך כלל, שכפול משאבים בכמה אזורים עולה יותר מאשר הקצאת משאבים באזור אחד, אבל הוא עשוי לשפר את המהימנות.
מידע נוסף זמין במאמר העברה בין אזורים: תכנון סביבות עמידות באזור יחיד ב- Google Cloud Google Cloud.
כשמתכננים סביבות של אזור יחיד, מומלץ להעריך את דרישות המהימנות של עומסי העבודה, התהליכים והנתונים. ההערכה הזו יכולה לעזור לכם להחליט אילו משאבים של Google Cloud צריך לשכפל ולהפיץ בכמה אזורים באזור מסוים, ואילו משאבים יכולים לעמוד בהפסקות חשמל אזוריות ולהיות בסדר באזור יחיד. לדוגמה, אפשר לשקול פריסה אזורית לעומסי עבודה של אצווה לא קריטיים לעסק, ורפליקציה והפצה מרובות אזורים לעומסי עבודה, תהליכים ונתונים קריטיים יותר.
הפחתת העלויות של סביבות מרובות אזורים
בסביבות מרובות אזורים, Google Cloud המשאבים בדרך כלל מפוזרים בין כמה אזורים. פיזור משאבים בכמה אזורים עוזר לצמצם את ההשפעה של הפסקות חשמל אזוריות. לדוגמה, אם אתם משתמשים בקטגוריה ב-Cloud Storage שמוגדרת למספר אזורים, הנתונים שלכם משוכפלים בכמה אזורים, והזמינות שלהם גבוהה יותר בהשוואה לקטגוריות אזוריות.
בנוסף להמלצות שבקטע הזה, כדאי לעיין גם בהמלצות שמפורטות במאמר הוזלת העלויות של סביבות באזור יחיד, כי הן רלוונטיות גם לסביבות במספר אזורים.
כדי להפחית את העלויות של סביבות מרובות אזורים, כדאי לשקול את האפשרויות הבאות:
משאבים במספר אזורים. בכמה מוצרים של Google Cloud יש תמיכה בשכפול משאבים ובהפצתם בכמה אזורים כדי לשפר את האמינות של הסביבות שלכם. לדוגמה, שירות Cloud Storage תומך בקטגוריות של מספר אזורים ושל שני אזורים כדי ליצור רפליקה של הנתונים שלכם בכמה אזורים. בדרך כלל, שכפול ופריסה של משאבים באזורים שונים עולים יותר מאשר הקצאת משאבים באזור אחד. לדוגמה, Google Cloud החיובים על קטגוריות של Cloud Storage בשני אזורים ובכמה אזורים כוללים מחירים שונים בהשוואה לקטגוריות באזור יחיד, וחיובים על רפליקציה בין אזורים.
כדי לצמצם את עלויות המוצרים, מומלץ להשתמש בשכפול ובהפצה של נתונים בכמה אזורים רק כשצריך לעמוד בדרישות האמינות של עומסי העבודה, הנתונים והתהליכים. לדוגמה, קבעתם שהנתונים שצריך לאחסן בקטגוריה של Cloud Storage ספציפית לא צריכים להיות מפוזרים בכמה אזורים כדי לצמצם את ההשפעות של הפסקת חשמל אזורית. כדי לחסוך בעלויות של הנתונים האלה, אפשר להקצות קטגוריה באזור יחיד לאחסון הנתונים במקום להקצות קטגוריה בשני אזורים או במספר אזורים. דוגמה נוספת לחיסכון בעלויות היא אם יש לכם עומס עבודה לא קריטי לעסק שלא צריך את רמת האמינות הגבוהה שמתקבלת מפריסה בכמה אזורים. אפשר לפרוס את עומס העבודה הזה באזור יחיד או אפילו באזור יחיד.
מחירים ספציפיים לאזור. אפשר להקצות Google Cloudמשאבים בכמה אזורים. המחירים של המשאבים האלה משתנים בהתאם לאזור. לדוגמה, המחירים של מכונות וירטואליות ב-Compute Engine שונים מאזור לאזור. יכול להיות שתוכלו לפרוס חלק מעומסי העבודה, הנתונים והתהליכים שלכם באזור שבו הם הכי זולים, אם המשאבים האלה עומדים בדרישות הבאות:
- עומסי העבודה, הנתונים והתהליכים האלה יכולים להתמודד עם זמן האחזור הנוסף שנוצר כשמקצים משאבים שהם תלויים בהם באזורים אחרים.
- עומסי העבודה, הנתונים והתהליכים האלה לא כפופים לדרישות רגולטוריות שמחייבות הקצאה של המשאבים האלה באזורים מסוימים.
לפני שמנסים להפחית את העלויות על ידי הקצאת משאבים באזורים אחרים, כדאי לבדוק אם העלות של תעבורת הנתונים ברשת בין האזורים מבטלת את ההפחתה בעלויות של שימוש בתמחור ספציפי לאזור.
עלויות של תעבורת נתונים יוצאת (egress) ברשת. Google Cloud חיובים על תעבורת נתונים ברשת בין אזורים כתעבורת נתונים יוצאת. כדי לצמצם את העלויות, מומלץ למזער את תעבורת הרשת בין האזורים על ידי ריכוז משאבים קרובים שצריכים להחליף נתונים באותו אזור. Google Cloud לדוגמה, עומס העבודה שפרסתם במכונה של Compute Engine צריך גישה לנתונים שמאוחסנים בקטגוריה של Cloud Storage. כדי להימנע מתנועה בין אזורים, אפשר להקצות את המכונה הווירטואלית של Compute Engine באזור שבו הקטגוריה משכפלת נתונים.
צמצום העלויות של העברות בין Google Cloud אזורים
העברת הסביבות והמשאבים שלכם בין אזורים עוזרת לכם להרחיב את הסביבות למספר אזורים, וגם לעמוד בדרישות הרגולטוריות שמחייבות מיקום משאבים מקומי. Google Cloud
מידע נוסף על העברה בין אזורים זמין במאמר העברה בין אזורים Google Cloud : תחילת העבודה
בנוסף להמלצות שבסעיף הזה, כדאי לעיין בהמלצות שמפורטות במאמר הפחתת העלויות של סביבות מרובות אזורים, כי הן רלוונטיות גם להפחתת העלויות של העברות ביןGoogle Cloud אזורים.
כדי לצמצם את העלויות של העברה בין Google Cloud אזורים, כדאי לשקול את האפשרויות הבאות:
- שכפול נתונים. כשבוחנים את האפשרויות להעברת נתונים מאזור אחד לאזור אחר, מומלץ לשקול גם העברה בניהול עצמי וגם את תכונות השכפול שנתמכות בכמה מוצרים של Google Cloud. לדוגמה, אתם צריכים להעביר נתונים שמאוחסנים בקטגוריה אזורית של Cloud Storage בין אזורים. אתם יכולים להעריך ולהשוות את העלויות של העברת הנתונים האלה לקטגוריה אחרת של אזור יחיד באזור היעד לעומת העלויות של העברת הנתונים האלה לקטגוריה של מספר אזורים, ושל שכפול הנתונים באזורים שונים באמצעות Cloud Storage.
- אסטרטגיה להעברת נתונים. כשמעריכים אסטרטגיה להעברת נתונים כדי להעביר נתונים בין אזורים, מומלץ לשקול את האסטרטגיות שמאפשרות לצמצם את עלויות ההעברה. Google Cloud לדוגמה, יכול להיות שעומסי העבודה יתחילו לכתוב נתונים גם לאזור המקור וגם לאזור היעד להעברה, אם תבחרו באסטרטגיה Y (כתיבה וקריאה). בשיטה הזו, תצטרכו להעביר רק נתונים היסטוריים במהלך המעבר.
מידע נוסף על העברת נתונים בין Google Cloud אזורים זמין במאמר בנושא העברה אל Google Cloud: העברת מערכי נתונים גדולים. המסמך הזה עוסק בהעברת נתונים מספקי ענן אחרים ומסביבות מקומיות אל Google Cloud אבל הוא רלוונטי גם להעברת נתונים בין אזורים.
אימוץ Cloud FinOps Framework
ההנחיות במסמך הזה נועדו לעזור לכם לתכנן וליישם מנגנונים ותהליכים למעקב אחרי העלויות ולניהול שלהן, ולצמצם את חוסר היעילות בהוצאות. ההנחיות מיועדות לשימוש הדרגתי כדי להשתלט על ההוצאות בענן.
כשתהיו מוכנים, תוכלו לאמץ את Cloud FinOps Framework. אימוץ המסגרת הזו הוא שינוי טרנספורמטיבי שמשלב טכנולוגיה, פיננסים ועסקים כדי לפתח אחריותיות פיננסית ולהאיץ את מימוש הערך העסקי.
מידע נוסף על Cloud FinOps Framework זמין במאמר תחילת העבודה עם FinOps ב- Google Cloud.
המאמרים הבאים
- איפה אפשר לקבל עזרה בתהליך ההעברה?
- מומלץ להשתתף בקורס ההדרכה של Google Skills בנושא מעבר אל Google Cloud.
- לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.
שותפים ביצירת התוכן
מחבר: Marco Ferrari | Cloud Solutions Architect