Pub/Sub: מבוא למהימנות

במדריך הזה מוסברות התכונות של Pub/Sub שמשפרות את המהימנות.

למה Pub/Sub?

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

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

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

בידוד

כברירת מחדל, Pub/Sub הוא שירות גלובלי: נושאים ומינויים לא קשורים באופן מובנה לאזורים ספציפיים, וההודעות זורמות בתוך שירות Pub/Sub בין אזורים כשצריך. כשמשתמשים בנקודת הקצה הגלובלית,‏ pubsub.googleapis.com, מפרסמים ומנויים מתחברים לאזור הקרוב ביותר ברשת שבו פועל Pub/Sub. כשמשתמשים בנקודות קצה אזוריות, כמו us-central1-pubsub.googleapis.com, או בנקודות קצה מבוססות-מיקום, כמו pubsub.us-central1.rep.googleapis.com, בעלי תוכן דיגיטלי ומנויים מתחברים ל-Pub/Sub באזור שצוין. כשמפעילים מפרסמים או מנויים מחוץ ל- Google Cloud, מומלץ להשתמש בנקודות קצה אזוריות או בנקודות קצה לפי מיקום, כדי להבטיח שההודעות יועברו באופן עקבי בין האזורים הרצויים.

בידוד אזורי

כדי לצמצם את התשתית שעליה מסתמכות פעולות פרסום והרשמה מחוץ לאזור יחיד, וכדי לוודא שכל הנתונים יישארו מבודדים באזור הזה, פועלים לפי השלבים הבאים:

1. יוצרים נושא לכל אזור.

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

2. לא מומלץ להשתמש בנקודות קצה גלובליות.

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

3. משתמשים במדיניות אחסון הודעות ומגדירים את enforceInTransit לערך True.

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

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

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

מעבר לגיבוי (Failover)

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

סמנטיקה של מעבר לגיבוי (failover) שמוגדרת כברירת מחדל

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

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

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

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

המנויים באירופה לא זמינים

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

איור 2. לא ניתן להציג נתונים של מנויים באירופה.

לא ניתן להירשם כמנויים באירופה ובאוסטרליה

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

איור 3. לא זמין למנויים באירופה ובאוסטרליה.

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

‫Pub/Sub לא זמין באירופה

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

איור 4. ‫Pub/Sub לא זמין באירופה.

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

האפשרות הזו לא זמינה לבעלי אתרים באוסטרליה

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

איור 5. בעלי אתרים באוסטרליה לא זמינים.

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

‫Pub/Sub לא זמין בארצות הברית

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

איור 6. ‫Pub/Sub לא זמין בארצות הברית.

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

מעבר לגיבוי (failover) ויתירות בשליטת הלקוח

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

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

חוסן אזורי

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

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

עמידות אזורית

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

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

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

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

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

להגדרה הזו יש כמה תכונות ודרישות מרכזיות:

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

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

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

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

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

1. תמיד נרשמים לאזור הגיבוי. במקרה כזה, המנוי שומר על חיבור גם לאזור הראשי וגם לאזור הגיבוי בכל רגע. אפשר להשתמש באותם אזורים גם לשרת הראשי וגם לשרת הגיבוי, גם לבעלי תוכן דיגיטלי וגם למנויים. במקרה כזה, המנוי צריך לקבל הודעות רק דרך אזור הגיבוי אם הלייבל עבר לגיבוי.
2. אפשר לזהות ידנית את המנויים ולהעביר אותם לאזור החלופי באמצעות הגדרה. אם מזהים הפסקת שירות, אפשר לבצע מעבר לגיבוי באזור הגיבוי ואז לחזור לאזור הראשי כשההפסקה מסתיימת.
3. מעבר לגיבוי במקרה של שגיאות אצל המנוי. אם הבקשות של המנויים מחזירות שגיאות, אפשר להשתמש בזה כאינדיקציה לכך שצריך לבצע מעבר לגיבוי באזור הגיבוי. חשוב לציין שספריות הלקוח של Pub/Sub מנסות לשלוח מחדש בקשות משיכה של נתונים בסטרימינג באופן פנימי במקרה של שגיאות זמניות, כך שיכול להיות שלא תוכלו לזהות שגיאות לא צפויות שמתרחשות לאורך תקופות ארוכות. בנוסף, שיעור השגיאות של משיכת נתונים בסטרימינג צפוי להיות 100%, גם במהלך פעולה רגילה.
4. מעבר לגיבוי אם המנוי לא מקבל הודעות במשך זמן ארוך באופן לא צפוי. בהנחה שההודעות מתפרסמות באופן עקבי, המנויים יכולים לקבל הודעות תמיד. אם הם לא מקבלים הודעות במשך תקופה ארוכה, יכול להיות שיש בעיה בצד המינוי ב-Pub/Sub באזור הראשי. הבעיה נפתרת על ידי מעבר לגיבוי באזור החלופי.

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

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

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

כוונון עדין של בעלי תוכן דיגיטלי

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

יכולות להיות סיבות שונות לכך שהפרסום ייכשל, כולל סיבות זמניות כמו חוסר זמינות של הרשת או סיבות שמחייבות התערבות של המשתמש כמו שינויים בהרשאות. ספריית הלקוח של Pub/Sub מנסה שוב לבצע פעולות שנתקלו בשגיאות זמניות באמצעות הפרמטרים שצוינו בהגדרות הניסיון החוזר. ההגדרות האלה קובעות את ההתנהגות של השהיה מעריכית לפני ניסיון חוזר (exponential backoff) בניסיונות חוזרים של פרסום RPC שנכשלים מסיבות זמניות. הגדרות ברירת המחדל בדרך כלל מתאימות לרוב התרחישים, אבל יש מצבים שבהם כדאי לשנות את הערכים האלה.

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

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

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

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

מנויים לכוונון עדין

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

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

שימוש בתמונת מצב ובחיפוש לפריסות בטוחות

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

התבנית של כל פריסת מנוי חייבת להיות כזו:

איור 7. דפוס לפריסת מנויים.

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

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