אם אתם משתמשים במדדים של Pub/Sub כאות להגדרה אוטומטית של קנה הצינור, הנה כמה המלצות.
שימוש ביותר מאות אחד כדי לשנות את גודל הצינור באופן אוטומטי
אל תשתמשו רק במדדים של Pub/Sub כדי להגדיר קנה מידה אוטומטי לצינור עיבוד הנתונים. זה עלול להוביל לתרחישים שבהם יש נקודת כשל יחידה בהחלטות לגבי שינוי גודל אוטומטי. במקום זאת, כדאי להשתמש בשילוב של אותות כדי להפעיל את ההתאמה האוטומטית של גודל הקבוצה. דוגמה לאות נוסף היא רמת השימוש במעבד של הלקוח. האות הזה יכול להצביע על כך שמשימות הלקוח מטפלות בעבודה, ועל כך שהגדלת המשאבים יכולה לאפשר למשימות הלקוח לטפל בעבודה נוספת. הנה כמה דוגמאות לאותות ממוצרי Cloud אחרים שבהם אפשר להשתמש בצינור:
Compute Engine תומך בהתאמת קנה מידה אוטומטית על סמך אותות כמו ניצול CPU ומדדים של Monitoring. Compute Engine תומך גם בכמה מדדים ובכמה אותות כדי לשפר את המהימנות.
מידע נוסף על שינוי קנה מידה באמצעות מדדים של Monitoring זמין במאמר שינוי קנה מידה על סמך מדדים של Monitoring. מידע נוסף על שינוי גודל לפי ניצול יחידת העיבוד המרכזית (CPU) זמין במאמר שינוי גודל לפי ניצול יחידת העיבוד המרכזית (CPU).
התאמה אוטומטית לעומס (HPA) של Google Kubernetes Engine Pod תומכת בהתאמה אוטומטית לעומס על סמך שימוש במשאבים כמו שימוש ב-CPU ובזיכרון, מדדי Kubernetes בהתאמה אישית ומדדים חיצוניים כמו מדדי Monitoring ל-Pub/Sub. היא גם תומכת בכמה אותות.
מידע נוסף זמין במאמר בנושא התאמה אופקית של קבוצות Pod לעומס.
שימוש בגרסה האזורית של המדדים במקום בגרסאות הגלובליות
ב-Pub/Sub יש שתי גרסאות של כל מדד שמשמש בדרך כלל עם שינוי גודל אוטומטי. חשוב להשתמש בגרסאות עם הסיומת by_region:
אם רוצים שהשינוי האוטומטי של קנה המידה יהיה עמיד בפני הפסקות זמניות בשירות באזור מסוים, לא כדאי להשתמש בגרסאות הגלובליות של המדדים האלה. כדי לחשב את הגרסה הגלובלית של המדדים האלה, צריך לחשב את ה-backlog בכל האזורים שידוע שיש בהם הודעות. כלומר, אם אזור מסוים לא זמין, יהיה פער בנתונים. לעומת זאת, בגרסאות by_region של המדדים מחושב ומדווח על העומס לפי אזור. אם אי אפשר לחשב את העומס באזור מסוים, המדד עדיין יציג ערכים לאזורים אחרים.
לא מומלץ להשתמש במדדי קצב העברת הנתונים בצד המנוי כדי להגדיר קנה מידה אוטומטי של מנויים
אל תשתמשו במדדי קצב העברת נתונים בצד המנוי, כמו subscription/ack_message_count, כדי להגדיר קנה מידה אוטומטי של לקוחות מנויים. במקום זאת, כדאי להשתמש במדדים שמשקפים ישירות את הצטברות ההודעות שממתינות לעיבוד, כמו subscription/num_unacked_messages או subscription/oldest_unacked_message_age שצוינו קודם.
בעיות בשימוש במדדי קצב העברת נתונים בצד המנוי לצורך שינוי גודל אוטומטי
השימוש במדדים האלה עלול לגרום לבעיות כי הם מייצגים את נפח התנועה בין Pub/Sub לבין המנויים. הגדלת הקיבולת על סמך מדד כזה עלולה ליצור לולאה רפרנסיאלית שבה ירידה במספר ההודעות שנמסרו או אושרו מובילה להקטנת הקיבולת של הלקוחות. לדוגמה, זה יכול לקרות אם יש ירידה זמנית בתנועה או אם יש בעיה עם אחד מהמנויים שלכם.
אם מספר הלקוחות שלכם יצטמצם לאפס או קרוב לאפס, כל התנועה של המינויים הפעילים עלולה להיפסק, והמנויים לא יוכלו לעבד הודעות, גם אם יגיעו הודעות חדשות. הדבר עלול לגרום לפיגור משמעותי בהעברה ולהוביל למצב שלא ניתן לשחזר עבור לקוחות המינוי.
איך מתמודדים עם פערים במדדים
אל תניחו שאם אין מדדים, אין הודעות לעיבוד. לדוגמה, אם בתגובה למדדים חסרים, מצמצמים את משימות העיבוד לאפס, יכול להיות שהודעות שכבר נמצאות ב-backlog או שמתפרסמות במהלך הזמן הזה לא ייצרכו. הפעולה הזו מגדילה את זמן האחזור מקצה לקצה. כדי למזער את זמן האחזור, צריך להגדיר מספר מינימלי של משימות שגדול מאפס, כדי שתמיד תהיו מוכנים לטפל בהודעות שפורסמו, גם אם מדדי Pub/Sub האחרונים מצביעים על תור ריק.
התכונה 'שינוי גודל אוטומטי' ב-Compute Engine ו-HPA ב-Google Kubernetes Engine נועדו לשמור על מספר העותקים הנוכחי כשמדדים לא זמינים. ההגדרה הזו מספקת רשת ביטחון למקרה שאין מדדים זמינים.
אפשר גם להטמיע מנגנונים של בקרה על זרימת נתונים ב-Pub/Sub כדי למנוע עומס יתר על משימות אם הן מצטמצמות בטעות בגלל מדדים חסרים.