אם אתם משתמשים במדדים של Pub/Sub כאות להגדרה אוטומטית של קנה המידה של צינור הנתונים, הנה כמה המלצות.
שימוש ביותר מאות אחד כדי להגדיל או להקטין את הקיבולת של צינור הנתונים באופן אוטומטי
אל תשתמשו רק במדדים של Pub/Sub כדי להגדיר קנה מידה אוטומטי לצינור עיבוד הנתונים. זה עלול להוביל לתרחישים שבהם יש נקודת כשל בודדת בהחלטות לגבי התאמה אוטומטית לעומס. במקום זאת, כדאי להשתמש בשילוב של אותות כדי להפעיל את ההתאמה האוטומטית לעומס. דוגמה לאות נוסף היא רמת השימוש במעבד של הלקוח. האות הזה יכול להצביע על כך שמשימות הלקוח מטפלות בעבודה, ועל כך שהגדלת המשאבים יכולה לאפשר למשימות הלקוח לטפל בעבודה נוספת. הנה כמה דוגמאות לאותות ממוצרי Cloud אחרים שבהם אפשר להשתמש בצינור:
Compute Engine תומך בהתאמה אוטומטית לעומס על סמך אותות כמו ניצול מעבד (CPU) ומדדים של מעקב. Compute Engine תומך גם בכמה מדדים ובכמה אותות כדי לשפר את המהימנות.
מידע נוסף על שינוי קנה מידה באמצעות מדדים של Monitoring זמין במאמר שינוי קנה מידה על סמך מדדים של Monitoring. מידע נוסף על שינוי גודל לפי ניצול יחידת העיבוד המרכזית (CPU) זמין במאמר שינוי גודל לפי ניצול יחידת העיבוד המרכזית (CPU).
התאמה אופקית של קבוצות Pod לעומס (HPA) ב-Google Kubernetes Engine תומכת בהתאמה אוטומטית לעומס על סמך שימוש במשאבים כמו שימוש במעבד (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 כדי למנוע עומס על המשימות אם הן מצטמצמות בטעות בגלל מדדים חסרים.