סקירה כללית של פרויקט המכסה

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

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

הערה למשתמשי ה-CLI של gcloud: לפעמים פרויקט המכסה נקרא פרויקט החיוב. הסיבה לכך היא שהדגל billing_project מקבל עדיפות על פני המאפיין billing/quota_project בהגדרות האישיות של ה-CLI של gcloud.

איך נקבע פרויקט המכסה

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

ממשקי API מבוססי-משאבים

ב-Cloud APIs שמבוססים על משאבים, הפרויקט שמספק מכסה לקריאה ל-API הוא גם הפרויקט שמכיל את המשאב שאליו מתבצעת הגישה. לדוגמה, כשיוצרים מכונה של Compute Engine, צריך לציין את הפרויקט של המכונה החדשה. המופע החדש יופיע בפרויקט. בהמשך, אם תבצעו פעולות במכונת ה-Compute Engine, הפרויקט שמכיל את המכונה יספק את המכסה לבקשה. זה נכון בין אם משתמשים ב-Google Cloud CLI, ב-REST API או בספריות לקוח.

אי אפשר לשנות את פרויקט המכסה שמשמש בקשה ל-API שמבוסס על משאבים. הבקשה תמיד משתמשת בפרויקט שמכיל את המשאב שהבקשה פועלת עליו.

ממשקי API מבוססי-לקוח

אם ה-API לא מבוסס על משאבים, הוא מבוסס על לקוחות. לדוגמה, Cloud Translation API הוא API נפוץ שמבוסס על לקוח.

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

  • צוין בבקשה: הפרויקט לצורכי מכסה שצוין בבקשה. (כשמשתמשים בספריות לקוח, אפשר גם להשתמש במשתני סביבה בבקשות).

  • מפתח API: אם משתמשים במפתח API כדי לספק פרטי כניסה לבקשה, הפרויקט שמשויך למפתח ה-API משמש כפרויקט המכסה.

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

  • חשבון שירות: אם החשבון הראשי של הקריאה ל-API הוא חשבון שירות, כולל באמצעות התחזות, הפרויקט שמשויך לחשבון השירות משמש כפרויקט המכסה.

  • איחוד שירותי אימות הזהות של כוח עבודה: אם חשבון המשתמש של ה-API הוא משתמש באיחוד שירותי אימות הזהות של כוח עבודה, הפרויקט של המשתמש במאגרי כוח העבודה משמש כפרויקט המכסה.

אם אף אחת מהבדיקות הקודמות לא מניבה פרויקט מכסה, הבקשה נכשלת.

מידע על פרויקט משותף ב-CLI של gcloud לממשקי API מבוססי-לקוח

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

איך מזהים את פרויקט המכסה הנוכחי לממשקי API שמבוססים על לקוחות

השיטה לזיהוי הפרויקט שמוגדרת בו המכסה תלויה באופן ההגדרה של הפרויקט:

  • אם שיטת API מוגדרת לשימוש ב-API שמבוסס על משאבים, פרויקט הלקוח משתמש בפרויקט המשאבים כפרויקט המכסה.

  • אם יש חריגה בפרויקט של משתמש, משתמשים בפקודה gcloud [command] --log-http כדי להדפיס יומן ולבדוק את פרויקט המכסה שמופיע בשדה x-goog-user-project.

  • אם נעשה שימוש במפתח API לאימות, משתמשים בפקודה gcloud [command] --log-http כדי להדפיס יומן ולבדוק את פרויקט המכסה שמופיע בשדה x-goog-api-key.

במקרים אחרים, פרויקט המכסה לא מופיע בכותרות HTTP.

איך קובעים אם API מבוסס על משאבים או על לקוחות

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

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