מכסות ומגבלות ב-Pub/Sub

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

בשירותים רבים יש מגבלות נוספות שלא קשורות למערכת המכסות. מדובר במגבלות קבועות, כמו גודל מקסימלי להודעות או מספר משאבי Pub/Sub שאפשר ליצור בפרויקט, ואי אפשר להגדיל או להקטין אותן.

נקודה חשובה: במסמך הזה מופיע מידע על מכסות ומגבלות משאבים ב-Pub/Sub. אפשר לבקש להגדיל את המכסות, אבל אי אפשר להתאים את המכסות. מידע נוסף זמין במאמר בנושא סקירה כללית על מכסות ב-Cloud.

הצגה וניהול של מכסות

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

• הקטנת המגבלות במכסות
• איך מתחילים תהליך להגשת בקשה להגדלת המכסות

מידע נוסף על מעקב אחרי השימוש במכסות וקבלת התראות זמין במאמר מעקב.

שיוך של ניצול המכסה

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

בכל שאר המכסות, השימוש מחויב בפרויקט שמשויך לפרטי הכניסה שצוינו בבקשה. השימוש במכסה לא מחויב בפרויקט שמכיל את המשאב המבוקש.

לדוגמה: אם חשבון שירות בפרויקט א' שולח בקשת פרסום כדי לפרסם בנושא בפרויקט ב', המכסה מחויבת לפרויקט א'. במקרים מסוימים, יכול להיות שתרצו שהשימוש במכסה יחויב בפרויקט אחר. אפשר להשתמש בפרמטר המערכת X-Goog-User-Project כדי לשנות את הפרויקט לשיוך מכסת השימוש. מידע נוסף על X-Goog-User-Project זמין במאמר בנושא פרמטרים של המערכת.

אתם יכולים להשתמש ב-CLI של gcloud כדי להגדיר את הפרויקט לשיוך מכסה לבקשה ספציפית. ה-CLI של gcloud שולח את כותרת הבקשה X-Goog-User-Project.

צריך להיות לכם תפקיד roles/serviceusage.serviceUsageConsumer או תפקיד בהתאמה אישית עם ההרשאה serviceusage.services.use בפרויקט שבו אתם רוצים להשתמש לשיוך מכסות.

בדוגמה הבאה מוצגות הפעולות שצריך לבצע כדי לקבל רשימה של מינויים בפרויקט RESOURCE_PROJECT, תוך חיוב של מכסת הפעולות של האדמין בפרויקט QUOTA_PROJECT. מריצים את הפקודה הבאה בטרמינל של Google Cloud CLI:

gcloud pubsub subscriptions list --project=
RESOURCE_PROJECT --billing-project=
QUOTA_PROJECT

מחליפים את QUOTA_PROJECT במזהה הפרויקט שרוצים לחייב בו את המכסה. Google Cloud

שימו לב: ב-Pub/Sub, הפרויקט שמחויב הוא תמיד הפרויקט שמכיל את המשאב. אפשר לשנות את הפרויקט רק לצורך שיוך מכסות.

מכסות Pub/Sub

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

המכסות האזוריות מחולקות ל-3 סוגים:

• אזורים גדולים: europe-west1, ‏ europe-west4, ‏ us-central1, us-east1, ‏ us-east4, ‏ us-west1, ‏ us-west2
• אזורים בינוניים: asia-east1, asia-northeast1, asia-southeast1, europe-west2, europe-west3
• אזורים קטנים: כל האזורים האחרים

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

הערה: בכל מכסות התפוקה, השימוש נמדד ביחידות של 1KB.

מכסה	מגבלת מכסה שמוגדרת כברירת מחדל	תיאור
התפוקה של בעל התוכן הדיגיטלי לפי אזור	‫‎240,000,000 kB לדקה (‎4 GB/s) באזורים גדולים ‫48,000,000 קילו-בייט לדקה (800 מגה-בייט לשנייה) באזורים בינוניים ‫12,000,000 קילו-בייט לדקה (200MB/s) באזורים קטנים	pubsub.googleapis.com/regionalpublisher השימוש במכסה מבוסס על הגודל של PubsubMessages שפורסמו: ‫PubsubMessage (REST) ‫PubsubMessage (RPC) אפשר לכלול כמה הודעות בבקשת פרסום אחת, ואין חיוב נוסף על מכסה לכל הודעה. הגודל של ההודעה, כפי שמחושב למטרות שימוש במכסה, כולל גם את השדה message_id שנוצר אוטומטית.
קצב העברת נתונים של מנויי שליפה בכל אזור	‫‎240,000,000 kB לדקה (‎4 GB/s) באזורים גדולים ‫48,000,000 קילו-בייט לדקה (800 מגה-בייט לשנייה) באזורים בינוניים ‫24,000,000 קילו-בייט לדקה (400MB/s) באזורים קטנים	pubsub.googleapis.com/regionalsubscriber השימוש במכסה מבוסס על הגודל של PubsubMessages שמוחזרים: ‫PubsubMessage (REST) ‫PubsubMessage (RPC) הגודל של ההודעה, כפי שמחושב למטרות שימוש במכסה, כולל גם את השדה message_id שנוצר אוטומטית.
קצב העברת הנתונים של מאשרים בכל אזור	‫‎240,000,000 kB לדקה (‎4 GB/s) באזורים גדולים ‫48,000,000 קילו-בייט לדקה (800 מגה-בייט לשנייה) באזורים בינוניים ‫24,000,000 קילו-בייט לדקה (400MB/s) באזורים קטנים	pubsub.googleapis.com/regionalacknowledger השימוש במכסה מבוסס על הגודל של בקשות Acknowledge ו-ModifyAckDeadline: ‫AcknowledgeRequest (RPC) ‫ModifyAckDeadlineRequest (RPC)
קצב העברת הנתונים של הרשמות ל-Push לכל אזור	‫26,400,000KB לדקה (440MB/s) באזורים גדולים ‫8,400,000 קילו-בייט לדקה (140MB/s) באזורים בינוניים ‫2,400,000 קילו-בייט לדקה (40MB/s) באזורים קטנים	pubsub.googleapis.com/regionalpushsubscriber בבקשות למשלוח בדחיפה שנשלחות לנקודת הקצה של הדחיפה, השימוש במכסה מבוסס על הגודל של PubsubMessage שנשלחים לנקודת הקצה של הדחיפה.
מינויים ל-BigQuery throughput per region	‫‎240,000,000 kB לדקה (‎4 GB/s) באזורים גדולים ‫48,000,000 קילו-בייט לדקה (800 מגה-בייט לשנייה) באזורים בינוניים ‫12,000,000 קילו-בייט לדקה (200MB/s) באזורים קטנים	pubsub.googleapis.com/regionalpushbigquerysubscriber בבקשות שנשלחות ל-BigQuery, השימוש במכסה מבוסס על הגודל של PubsubMessages שנשלח ל-BigQuery.
מינויים ל-Cloud Storage throughput per region	‫‎240,000,000 kB לדקה (‎4 GB/s) באזורים גדולים ‫48,000,000 קילו-בייט לדקה (800 מגה-בייט לשנייה) באזורים בינוניים ‫12,000,000 קילו-בייט לדקה (200MB/s) באזורים קטנים	pubsub.googleapis.com/regionalpushcloudstoragesubscriber בבקשות שנשלחות ל-Cloud Storage, השימוש במכסה מבוסס על הגודל של PubsubMessage שנשלח ל-Cloud Storage.
מינויים ל-Bigtable (גרסת Preview) throughput per region	‫‎240,000,000 kB לדקה (‎4 GB/s) באזורים גדולים ‫48,000,000 קילו-בייט לדקה (800 מגה-בייט לשנייה) באזורים בינוניים ‫12,000,000 קילו-בייט לדקה (200MB/s) באזורים קטנים	pubsub.googleapis.com/regionalpushbigtablesubscriber בבקשות שנשלחות ל-Bigtable, השימוש במכסה מבוסס על הגודל של PubsubMessage שנשלח ל-Bigtable.
התפוקה של מנויים ב-StreamingPull לכל אזור	‫‎240,000,000 kB לדקה (‎4 GB/s) באזורים גדולים ‫48,000,000 קילו-בייט לדקה (800 מגה-בייט לשנייה) באזורים בינוניים ‫24,000,000 קילו-בייט לדקה (400MB/s) באזורים קטנים	pubsub.googleapis.com/regionalstreamingpullsubscriber השימוש במכסה מבוסס על הגודל של הזרם PubsubMessage שמוזרם למנוי: ‫PubsubMessage (REST) ‫PubsubMessage (RPC) ספריות לקוח משתמשות בפעולות StreamingPull כשאפשר.
מספר החיבורים הפתוחים של StreamingPull לכל אזור	‫72,000 חיבורים פתוחים בו-זמנית באזורים גדולים ‫48,000 חיבורים פתוחים בו-זמנית באזורים בגודל בינוני ‫24,000 חיבורים פתוחים בו-זמנית באזורים קטנים	pubsub.googleapis.com/regionalstreamingpullconnections מספר החיבורים הפתוחים של StreamingPull בכל זמן נתון. ראו StreamingPull. אזהרה: אם שיעור הבקשות שנכשלו לפתיחת חיבורי StreamingPull גבוה, יכול להיות שתגיעו למכסה הזו.
פעולות של אדמין	‫6,000 לדקה (100 פעולות בשנייה)	pubsub.googleapis.com/administrator כל פעולת אדמין מחויבת ביחידה אחת מתוך המכסה הזו. פעולות של אדמינים כוללות את השיטות הבאות של RPC: IAMPolicy: GetIamPolicy, SetIamPolicy, TestIamPermissions Publisher: CreateTopic, DeleteTopic, DetachSubscription, GetTopic, ListTopics, ListTopicSnapshots, ListTopicSubscriptions, UpdateTopic SchemaService: CommitSchema, CreateSchema, DeleteSchema, DeleteSchemaRevision, GetSchema, ListSchemaRevisions, ListSchemas, RollbackSchema, ValidateMessage, ValidateSchema Subscriber: CreateSnapshot, CreateSubscription, DeleteSnapshot, DeleteSubscription, GetSnapshot, GetSubscription, ListSnapshots, ListSubscriptions, ModifyPushConfig, Seek, UpdateSnapshot, UpdateSubscription הערה: כמעט בכל המקרים, אין צורך להגדיל את המכסה של פעולות האדמין. בדרך כלל, בקשות כאלה לא מאושרות. מידע נוסף זמין במאמר בנושא שימוש מוגזם בפעולות של אדמינים.
מספר ההודעות שנצרכו מהמינויים עם העברה חד-פעמית בדיוק שמופעלת לכל אזור	‫1,000,000 הודעות לדקה באזור us-central1 ‫700,000 הודעות לדקה באזור us-east1 ‫300,000 הודעות לדקה באזור us-west1 ‫180,000 הודעות לדקה באזורים אחרים	pubsub.googleapis.com/exactlyoncedeliveredmessagecount השימוש במכסה מבוסס על מספר PubsubMessages שהמנוי צרך: ‫PubsubMessage (REST) ‫PubsubMessage (RPC)
מספר ההודעות שאושרה קבלתן או שהמועד האחרון שלהן הוארך, כשמשתמשים במינויים עם העברה של כל הודעה בדיוק פעם אחת שמופעלת לכל אזור	‫10,000,000 הודעות לדקה באזור us-central1 ‫7,000,000 הודעות לדקה באזור us-east1 ‫3,000,000 הודעות לדקה באזור us-west1 ‫1,800,000 הודעות לדקה באזורים אחרים	pubsub.googleapis.com/exactlyonceackcount השימוש במכסת המשאבים מבוסס על מספר מזהי האישור בבקשות Acknowledge ו-ModifyAckDeadline: ‫AcknowledgeRequest (RPC) ‫ModifyAckDeadlineRequest (RPC)

יחידות מכסת נתונים

השימוש במכסת התפוקה נמדד ביחידות של 1KB. ‫1 kB הוא 1,000 בייטים. לדוגמה, ב-PublishRequest עם 105 הודעות של 50 בייט כל אחת, גודל נתוני המשתמש הוא 105 * 50 bytes = 5250 bytes, ולכן השימוש במכסת הנפח הוא max(1kB, ceil(5250 bytes/1000)) = 6kB.

מגבלות על משאבים

הערה: אי אפשר לבקש להגדיל את המגבלות הבאות.

משאב	מגבלות
פרויקט	‫10,000 נושאים ‫10,000 מינויים מצורפים או מנותקים ‫5,000 תמונות מצב ‫10,000 סכימות
נושא	‫10,000 מינויים מצורפים ‫5,000 תמונות מצורפות אם שמירת הודעות בנושא מוגדרת, אפשר לשמור הודעות שפורסמו בנושא באחסון קבוע למשך עד 31 ימים ממועד הפרסום.
מינוי	כברירת מחדל, הודעות שלא אושרו נשמרות באחסון קבוע למשך 7 ימים ממועד הפרסום. אין הגבלה על מספר ההודעות שנשמרות. אם המנויים לא משתמשים במינוי, הוא יפוג. תקופת התפוגה שמוגדרת כברירת מחדל היא 31 ימים.
סכימה	גודל הסכימה (השדה definition): 300KB גרסאות לכל סכימה: 20
פרסום בקשה	‫10MB (גודל כולל) 1,000 הודעות
הודעה	גודל ההודעה (השדה data): 10MB מאפיינים לכל הודעה: 100 גודל מפתח המאפיין: 256 בייטים גודל ערך המאפיין: 1,024 בייטים
סטרימינג של נתונים	‫10MBps לכל סטרימינג פתוח
תגובה של בקשת משיכה אונרית	מספר ההודעות המקסימלי בתשובת Pull: ‏ 1,000 הגודל המקסימלי של תשובת Pull: ‏ 10MB
שליפה/הזרמה של הודעות	יכול להיות שהשירות יגביל את המספר הכולל של הודעות StreamingPull ממתינות לכל חיבור. אם נתקלים במגבלות כאלה, צריך להגדיל את קצב האישור של ההודעות ואת מספר החיבורים שבהם משתמשים.
אישור בקשות ושינוי של זמן האחזור לאישור	‫512KB (גודל כולל)
סידור המקשים	אם להודעות יש מפתחות סדר, התפוקה המקסימלית של המוציא לאור היא 1 MBps לכל מפתח סדר.
אובייקטים בקטגוריה של Cloud Storage	כשמשתמשים בנושאים של ייבוא מ-Cloud Storage, המגבלה על מספר האובייקטים בקטגוריה היא 50 מיליון.

שימוש בחשבון שירות למכסות גבוהות יותר

אם אתם משתמשים בכלי Google Cloud CLI עם חשבון משתמש רגיל (כלומר, לא חשבון שירות), הפעולות ב-Pub/Sub מוגבלות לקצב שמתאים לפעולות ידניות. אם חורגים מהמגבלה הזו, מופיעה השגיאה RESOURCE_EXHAUSTED. הפתרון הוא לוודא שאתם משתמשים בפרטי כניסה של חשבון שירות. אם רוצים להשתמש בפרטי כניסה מ-CLI של gcloud לאוטומציה, צריך להפעיל חשבון שירות לפעולות ב-Pub/Sub.

שימוש בנקודות קצה מבוססות-מיקום לניתוב בקשות

אם יש לכם מכסה נוספת באזורים מסוימים, אתם יכולים להפנות בקשות לאזורים האלה באמצעות נקודות קצה של Pub/Sub לפי מיקום. כשמפרסמים הודעות בנקודת קצה גלובלית, יכול להיות ששירות Pub/Sub ינתב תנועה לאזור שאין בו מכסה מספקת.

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

חוסר התאמה במכסות

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

• אם מפרסמים 10 הודעות בגודל 500 בייט בבקשות נפרדות, השימוש במכסת המפרסם יהיה 10,000 בייט. הסיבה לכך היא שהודעות שקטנות מ-1,000 בייט מעוגלות אוטומטית כלפי מעלה לתוספת הבאה של 1,000 בייט.

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

• ולהיפך. יכול להיות שהשימוש במכסת המנויים יהיה גדול יותר מהשימוש במכסת בעלי התוכן הדיגיטלי אם מפרסמים כמה הודעות בבקשת פרסום אחת או מקבלים את ההודעות בבקשות Pull נפרדות.