ניהול העלויות של יומן הביקורת Data Access

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

כשפועלים לפי השיטות המומלצות לאימות ב-Bigtable, רוב הפעילות ביומן הביקורת של גישה לנתונים נוצרת על ידי חשבונות שירות. חשבון שירות הוא חשבון שאפליקציה משתמשת בו כדי לבצע אימות וקריאות ל-API לשירותים כמו Bigtable. Google Cloudהשלב הכי חשוב לצמצום נפח היומנים הוא ניהול היומנים של חשבונות השירות. אפשר גם להגביל את היומנים באמצעות קריטריונים אחרים.

אפשר להפעיל את יומני הביקורת של גישה לנתונים ב-Bigtable באחת מהדרכים הבאות:

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

זיהוי חשבונות שירות

קודם כול, צריך לזהות את חשבונות השירות שלא צריך יומנים עבורם. רשימת חשבונות השירות שלא מועילים ושלא צריך לרשום ביומן תלויה באפליקציה ובצרכים העסקיים שלכם.כדי לקבל רשימה של חשבונות שירות שיש להם הרשאות ל-Cloud Bigtable API (Data API), אתם יכולים לחפש מדיניות IAM בארגון שלכם. אפשר גם לראות אותם בדף IAM Permissions במסוף Google Cloud , בכרטיסייה Principals.

הגדרת הגבלות על יומנים

בשלב הבא, מגדירים את ההגבלות על היומנים. יש שתי דרכים לנהל את נפח היומנים של Bigtable על ידי הגבלת היומנים של חשבון השירות. אתם יכולים להחריג חשבונות שירות באמצעות הגדרת ביקורת, או להסיר יומנים של חשבונות שירות באמצעות מסננים להסרת יומנים. לכל שיטה, אפשר להשתמש ב-Cloud Logging API או במסוף Google Cloud .

החרגת חשבונות שירות באמצעות הגדרת ביקורת

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

החרגה של חשבונות שירות באמצעות מסנני החרגה

מסנני החרגה מאפשרים לכם לציין יומנים שיוחרגו מההטמעה בדלי היומנים. בגישה הזו, היומנים מושלכים אחרי שהם נוצרו, ולכן הם עדיין יוצרים עומס עיבוד על רכיבי שירות Bigtable שמשרתים את הנתונים שלכם. בגלל העומס הזה, מומלץ להשתמש במקום זאת בהגדרת ביקורת. מידע נוסף על הגדרת מסננים באמצעות המסוףGoogle Cloud ו-API זמין במאמר יצירת מאגר.

הערכת העלויות של יומני הביקורת Data Access

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

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

ממוצע הבקשות לשנייה זמן השמירה של היומן עלות חודשית משוערת
1,000 30 ‫1,197 $
1,000 90 1,246 $
10,000 30 12,195$
10,000 90 12,684$
100,000 30 $122,177
100,000 90 $124,621

חישוב העלויות

מתחילים עם ההנחות הבאות:

  • מספר השניות בחודש ממוצע הוא בערך 2,628,000.
  • הגודל הממוצע של ביקורת הוא בערך 1kb.
  • לא מחויבים על 50 הגיגה-בייט הראשונים של יומני ביקורת שמועברים מדי חודש, ואחרי שעוברים את הכמות הזו, מחויבים ב-0.50 $לגיגה-בייט.
  • האחסון הוא בחינם למשך 30 יום. לאחר מכן, תשלמו $0.01/GiB על האחסון.

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

חישוב נפח היומן החודשי

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

  1. אוספים את המספר הממוצע של בקשות לשנייה שהאפליקציה שולחת ל-Bigtable במהלך חודש.
    • אם אתם משתמשים במדדים בצד הלקוח, אתם יכולים להשתמש בהם כדי לקבוע את ממוצע השאילתות לשנייה (QPS) בחודש האחרון.
    • אם אתם מעדיפים להשתמש בדף התובנות לגבי המערכת בGoogle Cloud מסוף של המופע, תוכלו להיעזר בו כדי לקבוע את הערכים הממוצעים של בקשות קריאה ובקשות כתיבה לשנייה במהלך החודש האחרון, ואז לחבר את שני הערכים האלה.
  2. כדי לקבל את מספר הבקשות הממוצע בחודש, מכפילים את מספר הבקשות בשנייה ב-2,628,000.
  3. מחלקים את המספר הזה ב-10e6, או ב-1,000,000. התוצאה היא נפח היומן החודשי המשוער ב-GB שאולי תייצרו בכל חודש.
  4. מכפילים את נפח היומן החודשי ב-GB ב-0 .93 כדי לקבל את נפח היומן החודשי המשוער ב-GiB.

חישוב עלויות ההטמעה

  1. מפחיתים 50GiB מנפח היומן החודשי ב-GiB שחישבתם. ‫50 ה-GiB הראשונים הם בחינם.
  2. כדי לקבל את העלויות המשוערות של ההעלאה החודשית, מכפילים את השארית ב-0.50$.

חישוב עלויות האחסון

  1. אם אתם מתכננים לתת ליומנים לפוג אחרי 30 יום, העלות שלכם לאחסון היא 0.00$.
  2. אם מאחסנים את היומנים למשך יותר מ-30 ימים, אפשר להעריך את עלויות האחסון על ידי הכפלת נפח היומנים החודשי ב-0.01$. העלויות האלה מתחילות להצטבר אחרי החודש הראשון.

דוגמה מפורטת

‫5,000 בקשות בשנייה, היומנים נשמרים למשך 90 יום

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

  • מכפילים את 5,000 ב-2,628,000 ומקבלים 13,140,000,000 בקשות לחודש.
  • מחלקים את המספר 13,140,000,000 ב-10e6 כדי לקבל נפח יומן של כ-13,140GB בחודש.
  • כדי להמיר את המספר הזה ל-GiB, מכפילים אותו ב-0 .93 ומקבלים 12,220.
  • מפחיתים 50GB מנפח היומן החודשי ומקבלים 12,170GB.
  • מכפילים ב-0.50 $כדי לקבל 6,085 $בעלויות ההטמעה.
  • במהלך החודש הראשון שבו קיימים היומנים, עלות האחסון היא 0$.
  • במהלך החודש השני, עלות אחסון היומנים היא 12,170 כפול 0.01$, כלומר כ-122$.
  • בכל חודש אחרי החודש השני, עלות האחסון החודשית תהיה כפולה, כלומר 244$.
  • אחרי החודש השני, העלות המשוערת של יומני בקרת הרשאות הגישה לנתונים תהיה בערך 6,329 $לחודש.

המשוואה תיראה כך: (((((5,000 rps * 2,628,000 sec)/1,000,000) * .93) - 50 GiB) * $0.50) + $122 = $6,207.

בדוגמה הזו, העלויות החודשיות של רישום ביומן של גישה לנתונים הן בערך 25,316 ש"ח לחודש.

המאמרים הבאים