ב-Google Maps Platform יש מגוון אפשרויות לשליטה בצריכה ולוודא שהשימוש תואם לתקציב. האפשרויות כוללות:
- כדי להפסיק את החיובים, אתם יכולים להגביל את מספר אירועי החיוב שהאפליקציה מפעילה.
- קבלת התראות כשהשימוש מתקרב למגבלות ספציפיות של תקציב או של מכסת בקשות API.
- פיתוח אפליקציות בצורה חסכונית יותר.
בטבלה הבאה מפורטות האפשרויות שלכם.
| הפסקת החיובים | אני רוצה לקבל עדכונים | פיתוח בעלות נמוכה יותר |
מכסות
המכסות מגבילות את כמות השימוש בשירות של הפלטפורמה של מפות Google בפרויקט ב-Google Cloud. המכסות נועדו לשמור על הוגנות ולצמצם עליות חדות בשימוש במשאבים ובזמינות שלהם. לסקירה כללית על מכסות ב-Cloud
הפעולות הבאות נכללות במכסה:
- בקשות שהושלמו בהצלחה
- בקשות שגורמות לשגיאות בחיבור לשרת
הפריטים הבאים לא נכללים במכסה:
- בקשות שהאימות שלהן נכשל
אתם יכולים להגדיר התראות על הגעה למכסה כדי לקבל הודעה כשהשימוש ב-API מתקרב למגבלה. מידע נוסף זמין במאמר הגדרת התראות על הגעה למכסה ומעקב אחרי מכסות.
מגבלות המכסות עוזרות לכם לשלוט בשימוש ב-API ולמנוע חיובים לא צפויים, על ידי הגבלת מספר הבקשות שהפרויקט יכול לשלוח. אפשר להגדיל או להקטין את מכסות ברירת המחדל על ידי שליחת בקשה לשינוי. איך רואים ומנהלים את המכסות?
המכסה קובעת את השימוש המקסימלי ב-API בפרויקט, ולכן היא גם קובעת את הסכום המקסימלי שאפשר לחייב אתכם על השימוש ב-API הזה. הקטנת המכסה מקטינה את התקרה הזו. הגדלת המכסה מאפשרת לפרויקט לשלוח יותר בקשות לחיוב לפני שה-API מפסיק להגיב. הגדלת המכסה לא מגבילה את ההוצאות ולא מגינה עליכם מפני חיובים לא צפויים.
לדוגמה, נניח שיש באג בקוד של חלוקת הדפים, שגורם לשליחת בקשות לדף התוצאות הבא בלי תנאי עצירה. עם מכסה של 10,000 בקשות ביום, ה-API דוחה את הבקשות של הלולאה אחרי 10,000 הבקשות הראשונות. אם תגדילו את המכסה ל-100,000 בקשות ביום, אותה לולאה תוכל לבצע פי 10 בקשות לחיוב לפני שה-API ידחה אותן.
המכסה גם מגבילה את העלות של תנועה לא רצויה, כמו בקשות מסורקים אוטומטיים או ממישהו אחר שמשתמש במפתח ה-API שלכם, אבל היא לא ההגנה העיקרית מפני התנועה הזו. כדי לחסום תנועה לא רצויה, הגבילו את מפתחות ה-API לאפליקציות שלכם ולממשקי ה-API שבהם הן משתמשות. השתמשו במכסות כרשת ביטחון.
בקשו להגדיל את המכסה רק כשהאפליקציה צריכה קיבולת גדולה יותר בשביל תנועה צפויה, כמו השקת מוצר או שיא עונתי.
הגדרת מגבלות מכסה
כדי להגביל את השימוש ב-API, אפשר להקטין את המכסה היומית שלו. כשהפרויקט מגיע למגבלה, הבקשות לאותו API נכשלות בשאר היום. המגבלה חלה שוב בכל יום, כי המכסות היומיות מתאפסות בחצות לפי שעון החוף המערבי של ארה"ב. חשוב להגדיר מגבלה גבוהה מספיק לתנועה הרגילה באפליקציה. לדוגמה, אם האפליקציה בדרך כלל מבצעת כ-2,000 בקשות ביום ועד 3,000 בקשות בימים עמוסים, מגבלה של 4,000 בקשות ביום תכסה את הימים העמוסים ביותר ותעצור לולאה אינסופית ב-4,000 בקשות.
כדי לשנות מגבלה, פותחים את הדף Quotas במסוף Cloud, בוחרים את ה-API ועורכים את המכסה. איך רואים ומנהלים את המכסות?
כדי לא לחרוג ממכסת השימוש החינמי החודשית של מק"ט, מחלקים את מכסת השימוש החינמי ב-31 (מספר הימים המקסימלי בחודש) ומעגלים כלפי מטה. מגדירים את התוצאה כמגבלה היומית של המכסה שסופרת את החיובים של המק"ט. לדוגמה, אם למק"ט יש מכסת שימוש חינמי של 1,000 אירועים לחיוב בחודש, מחלקים 1,000 ב-31 ומקבלים בערך 32.3. מגבלה יומית של 32 שומרת על שימוש של 992 או פחות בכל חודש. מכסות השימוש בחינם יכולות להשתנות, לכן חשוב לבדוק את המכסה הנוכחית של כל מק"ט לפני שמגדירים מגבלה.
לפני שמגדירים מגבלה יומית, צריך לבדוק איך המק"ט מחויב:
- יחידת חיוב: בחלק מהמקט"ים החיוב הוא לפי רכיב או לפי טעינת מפה, ולא לפי בקשה. לדוגמה, בקשות של
computeRouteMatrixמחויבות לפי רכיב, שהוא מספר נקודות המוצא כפול מספר היעדים. בקשה עם 5 נקודות מוצא ו-10 יעדים תחויב על 50 רכיבים. אם תגדירו מגבלה של 32 בקשות ביום, האפליקציה עדיין תוכל להשתמש ב-1,600 רכיבים ביום. במק"טים האלה, צריך להקטין את המכסה היומית שסופרת את אותה יחידה, למשל רכיבים ליום, ולא בקשות ליום. - אין מכסה תואמת: לחלק מהיחידות לחיוב, כמו סשנים, אין מכסה תואמת. מכסת הבקשות עדיין מגבילה את השימוש, כי כל סשן כולל לפחות בקשה אחת, אבל היא יכולה לחסום את התנועה לפני שתגיעו למכסת השימוש בחינם.
- יותר ממק"ט אחד לכל API: אם בקשות ל-API יכולות להפעיל יותר ממק"ט אחד, צריך לבסס את המגבלה על המק"ט עם מכסת השימוש הנמוכה ביותר בחינם.
- יותר מממשק API אחד לכל מק"ט: אם יותר מממשק API אחד בפרויקט מחויב לאותו מק"ט, צריך לפצל את המגבלה היומית בין ממשקי ה-API האלה.
משנים את המכסה לפי הצורך.
כדאי לבדוק ולהתאים באופן קבוע את מכסות ה-API כדי לייעל את השימוש והעלויות, תוך שמירה על איזון בין מניעת הוצאות מוגזמות לבין הבטחת תפקוד תקין של האפליקציה.
- עוקבים אחרי דפוסי השימוש ב-API במסוף Google Cloud. מגדירים מכסות שתואמות לתקציב כדי למנוע הוצאות מיותרות.
- מוודאים שהמכסות יכולות לעמוד בתקופות שיא של שימוש.
- כדי למנוע שיבושים, בצעו שינויים הדרגתיים ובדקו את האפליקציה ביסודיות אחרי כל שינוי.
תקציבים והתראות
אם יש לכם תקציב ספציפי לשימוש ב-Google Maps Platform, אתם יכולים ליצור תקציבים והתראות בחיוב ב-Cloud כדי להימנע מ"הפתעות" בחשבון.
אתם יכולים להגדיר התראות לגבי התקציב כדי לקבל עדכון כשההוצאות מגיעות לאחוז מסוים מסך התקציב, וכך לראות את המגמות של עלויות השימוש לאורך זמן.
איך יוצרים, עורכים או מוחקים התראות תקציב
ניהול עלויות אסטרטגי
כדי לנהל תקציב בצורה יעילה, כדאי להשתמש באפשרויות חינמיות או זולות יותר כשאפשר. בקטע הזה נסקור אסטרטגיות שונות לצמצום העלויות.
שימוש ב-Maps Static API כשאפשר
התרחישים הבאים מתאימים למפות סטטיות, שתומכות בתצוגות פשוטות של מפות שצריכות רק סמן אחד:
- אתם מתחילים עם אב טיפוס שעדיין אין לו הרבה תכונות.
- אין לכם מפות בהתאמה אישית.
- אתם משתמשים בסמן אחד לכל היותר.
- אתם לא צריכים לתמוך באינטראקציה של משתמשים באמצעות מפות דינמיות או תצוגת Street View דינמית.
טעינה מדורגת באמצעות תמונות ממוזערות
תמונות ממוזערות (תמונות קטנות של מפות) הן שימוש טוב ב-Maps Static API. הפריטים האלה מחויבים בתעריף נמוך יותר מאשר טעינות של מפות דינמיות, וכשהמשתמשים לוחצים עליהם הם יכולים לעבור לגרסה דינמית של מפות Google. כך אתם משלמים רק על טעינות של מפות דינמיות למשתמשים שהביעו עניין.
שימוש בקטגוריות תמחור זולות יותר
Google מספקת מספר שונה של אירועי שימוש בחינם לכל קטגוריית תמחור. אתם יכולים לבצע אופטימיזציה של האפליקציה כדי להשתמש ביכולות בקטגוריות Essentials או Pro, שבהן יש לכם יותר אירועי שימוש חודשיים בחינם. מידע נוסף על קטגוריות תמחור
איחוד של כמה מפות
אם יש לכם הטמעה שמוצגות בה כמה מפות, פעלו לפי ההנחיות הבאות:
- טוענים מפות רק כשצריך, כדי לצמצם את השימוש במשאבים מיותרים.
- שימוש חוזר במפה אחת על ידי עדכון של אזור התצוגה, מרחק התצוגה והסמנים לפי הצורך.
- השתמשו ב פתרון Store Locator Plus אם אתם מציגים כמה מפות כדי להראות את מיקומי החנויות.
- השתמשו במפה אחת לכל מסך בממשק המשתמש, כי בדרך כלל המשתמשים מבצעים פעולות רק במפה אחת בכל פעם.
שמירת תוכן במטמון כשהדבר מותר
ברוב המוצרים של Google Maps Platform אסור לשמור תוכן במטמון. עם זאת, יש כמה חריגים שמאפשרים לשמור את התוצאות במטמון למשך עד 30 יום. לפרטים נוספים על התנאים של Google Maps Platform