העיקרון הזה הוא חלק מעקרונות הקיימות בGoogle Cloud Well-Architected Framework. הוא כולל המלצות שיעזרו לכם לשפר את היעילות האנרגטית של משאבי האחסון ב- Google Cloudולצמצם את טביעת הרגל הפחמנית שלהם.
סקירה כללית של העקרונות
נתונים מאוחסנים הם לא משאב פסיבי. צריכת האנרגיה ופליטות הפחמן מתרחשות לאורך מחזור החיים של הנתונים. כל גיגה-בייט של נתונים מאוחסנים דורש תשתית פיזית שמקבלת חשמל באופן רציף, מקוררת ומנוהלת. כדי להשיג ארכיטקטורת ענן בת קיימא, צריך להתייחס לנתונים כאל נכס בעל ערך, אבל כזה שפוגע בסביבה, ולתת עדיפות למשילות מידע פרואקטיבית.
ההחלטות שלכם לגבי שמירת נתונים, איכות ומיקום יכולות לעזור לכם להפחית באופן משמעותי את העלויות של השימוש בענן ואת צריכת האנרגיה. צריך לצמצם את כמות הנתונים שמאוחסנים, לבצע אופטימיזציה של המיקום והאופן שבהם הנתונים מאוחסנים ולהטמיע אסטרטגיות אוטומטיות למחיקה ולארכוב. כשמצמצמים את העומס של הנתונים, משפרים את הביצועים של המערכת ומפחיתים באופן משמעותי את ההשפעה הסביבתית של הנתונים בטווח הארוך.
המלצות
כדי לייעל את מחזור החיים של הנתונים ואת משאבי האחסון שלכם לצורך קיימות, כדאי לעיין בהמלצות שבקטעים הבאים.
מתן עדיפות לנתונים בעלי ערך גבוה
נתונים מאוחסנים שלא נעשה בהם שימוש, שהם כפולים או שהם לא רלוונטיים ממשיכים לצרוך אנרגיה כדי להפעיל את התשתית הבסיסית. כדי לצמצם את טביעת הרגל הפחמנית שקשורה לאחסון, אפשר להשתמש בטכניקות הבאות.
זיהוי והסרה של כפילויות
כדאי ליצור מדיניות שתמנע שכפול מיותר של מערכי נתונים בכמה Google Cloud פרויקטים או שירותים. מומלץ להשתמש במאגרי נתונים מרכזיים כמו מערכי נתונים ב-BigQuery או קטגוריות ב-Cloud Storage כמקורות אמת יחידים, ולהעניק גישה מתאימה למאגרים האלה.
הסרת נתוני צל ונתונים לא גלויים
נתונים לא ידועים הם נתונים שהתועלת שלהם או הבעלים שלהם לא ידועים. נתוני צל הם עותקים לא מורשים של נתונים. סריקת מערכות האחסון ומציאת נתונים לא גלויים ונתוני צללים באמצעות פתרון לגילוי נתונים וקטלוג כמו Knowledge Catalog. חשוב לבדוק את הממצאים האלה באופן קבוע ולהטמיע תהליך לארכיון או למחיקה של נתונים לא גלויים ונתוני צל, לפי הצורך.
צמצום נפח הנתונים לעומסי עבודה של AI
שמירה רק של התכונות והנתונים המעובדים שנדרשים לאימון המודל ולהצגת התוצאות. במקרים שבהם אפשר, כדאי להשתמש בטכניקות כמו דגימת נתונים, צבירה ויצירת נתונים סינתטיים כדי לשפר את ביצועי המודל בלי להסתמך על מערכי נתונים עצומים של נתונים גולמיים.
שילוב של בדיקות איכות נתונים
כדי להטמיע צינורות לאימות נתונים ולניקוי נתונים באופן אוטומטי, אפשר להשתמש בשירותים כמו Managed Service for Apache Spark, Dataflow או Knowledge Catalog בזמן הטמעת הנתונים. נתונים באיכות נמוכה גורמים לבזבוז של שטח אחסון. הם גם מובילים לצריכת אנרגיה מיותרת כשהנתונים משמשים מאוחר יותר לניתוח או לאימון AI.
בדיקת צפיפות הערך של הנתונים
כדאי לבדוק מדי פעם מערכי נתונים גדולים כמו יומנים וזרמי נתונים של IoT. צריך להחליט אם אפשר לסכם, לצבור או לדגום את הנתונים כדי לשמור על צפיפות המידע הנדרשת ולצמצם את נפח האחסון הפיזי.
בחינה ביקורתית של הצורך בגיבויים
צריך להעריך את הצורך בגיבוי של נתונים שאפשר ליצור מחדש במאמץ מינימלי. דוגמאות לנתונים כאלה כוללות תוצאות ביניים של ETL, מטמון זמני ונתוני אימון שנגזרים ממקור יציב וקבוע. כדאי לשמור גיבויים רק של נתונים שהם ייחודיים או יקרים ליצירה מחדש.
אופטימיזציה של ניהול מחזור החיים של האחסון
אוטומציה של מחזור החיים של האחסון, כך שכשהשימוש בנתונים יורד, הנתונים מועברים לסוג אחסון חסכוני באנרגיה או מוצאים משימוש, בהתאם לצורך. אפשר להשתמש בטכניקות הבאות.
בחירת סוג אחסון מתאים ב-Cloud Storage
אפשר להשתמש בניהול מחזור החיים של אובייקטים כדי להפוך את המעבר של נתונים ב-Cloud Storage לסוגי אחסון (storage class) עם פליטת פחמן נמוכה יותר לאוטומטי, על סמך תדירות הגישה.
- מומלץ להשתמש ב-Standard Storage רק למערכי נתונים שנמצאים בשימוש פעיל, כמו מודלים עדכניים של ייצור.
- העברת נתונים כמו מערכי נתונים ישנים לאימון AI או גיבויים שניגשים אליהם בתדירות נמוכה יותר אל Nearline Storage או Coldline Storage.
- לשמירה לטווח ארוך, מומלץ להשתמש ב-Archive Storage, שמותאם ליעילות אנרגטית בקנה מידה גדול.
הטמעה של כללי מדיניות מחמירים בנושא מחזור החיים של הנתונים
הגדרת מדיניות ברורה ואוטומטית של אורך החיים (TTL) של נתונים לא חיוניים, כמו קובצי יומן, פריטי מידע זמניים של מודלים ותוצאות ביניים לא עדכניות. שימוש בכללים של מחזור החיים כדי למחוק אוטומטית נתונים כאלה אחרי תקופה מוגדרת.
הוספת תגים למשאבי הרשאה
חובה להשתמש בתגים ובתוויות עקביים של משאבים בכל דלי Cloud Storage, מערכי הנתונים ב-BigQuery ודיסקים קשיחים. צריך ליצור תגים שמציינים את בעלי הנתונים, את מטרת הנתונים ואת תקופת השמירה. אפשר להשתמש באילוצים של Organization Policy Service כדי לוודא שתגים נדרשים, כמו תקופת השמירה, מוחלים על משאבים. התגים מאפשרים לאוטומט את ניהול מחזור החיים, ליצור דוחות מפורטים של FinOps ולהפיק דוחות על פליטת פחמן.
בחירת הגודל המתאים לביטול ההקצאה של אחסון לחישוב
מומלץ לבדוק באופן קבוע דיסקים מתמידים שמצורפים למכונות של Compute Engine, ולוודא שההקצאה שלהם לא מוגזמת. משתמשים בתמונות מצב רק כשצריך לגבות את הנתונים. מחיקת תמונות מצב ישנות שלא בשימוש. במסדי נתונים, כדאי להשתמש במדיניות שמירת נתונים כדי להקטין את הגודל של הדיסקים הבסיסיים לאחסון מתמיד.
אופטימיזציה של פורמט האחסון
לצורך אחסון שמשמש לעומסי עבודה של ניתוח נתונים, מומלץ להשתמש בפורמטים דחוסים של עמודות כמו Parquet או Avro שעברו אופטימיזציה, במקום בפורמטים מבוססי-שורות כמו JSON או CSV. אחסון עמודות מפחית באופן משמעותי את דרישות השטח הפיזי בדיסק ומשפר את יעילות הקריאה. האופטימיזציה הזו עוזרת לצמצם את צריכת האנרגיה של פעולות החישוב והקלט/פלט המשויכות.
אופטימיזציה של אזוריות ותנועת נתונים
המיקום הפיזי של הנתונים והתנועה שלהם משפיעים על צריכת משאבי הרשת ועל האנרגיה שנדרשת לאחסון. כדי לבצע אופטימיזציה של אזוריות הנתונים, אפשר להשתמש בשיטות הבאות.
בחירת אזורי אחסון דלי-פחמן
בהתאם לדרישות התאימות שלכם, כדאי לאחסן נתונים ב Google Cloud אזורים שבהם נעשה שימוש באחוז גבוה יותר של אנרגיה נטולת פחמן (CFE) או שבהם שיעור פליטת הפחמן ברשת נמוך יותר. כדי להגביל את היצירה של מאגרי אחסון באזורים עם פליטת פחמן גבוהה, משתמשים במגבלת מדיניות הארגון מיקומי משאבים. מידע על נתוני CFE ועל עוצמת פליטת הפחמן Google Cloud באזורים זמין במאמר בנושא אנרגיה נטולת פחמן Google Cloud באזורים.
צמצום השכפול
שכפול נתונים בין אזורים צריך להתבצע רק כדי לעמוד בדרישות חובה של התאוששות מאסון (DR) או זמינות גבוהה (HA). פעולות שכפול בין אזורים ובכמה אזורים מגדילות באופן משמעותי את עלות האנרגיה ואת טביעת הרגל הפחמנית של הנתונים.
אופטימיזציה של מיקומים לעיבוד נתונים
כדי להפחית את צריכת האנרגיה בהעברת נתונים ברשת, כדאי לפרוס עומסי עבודה שדורשים הרבה משאבי מחשוב, כמו אימון AI ועיבוד ב-BigQuery, באותו אזור שבו נמצא מקור הנתונים.
אופטימיזציה של העברת נתונים עבור השותפים והלקוחות
כדי להעביר כמויות גדולות של נתונים בין שירותי ענן, מיקומים וספקים, מומלץ לעודד את השותפים והלקוחות שלכם להשתמש ב-Storage Transfer Service או בממשקי API לשיתוף נתונים. כדאי להימנע מהעברה של כמויות גדולות של נתונים. במערכי נתונים ציבוריים, מומלץ להשתמש בקטגוריות Requester Pays כדי להעביר את העלויות של העברת הנתונים והעיבוד, ואת ההשפעה הסביבתית, למשתמשי הקצה.