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.

יתירות כשל

אם אתם לא צריכים בידוד אזורי, כדאי לכם לנצל את היכולת של Pub/Sub להעביר הודעות ביעילות בין כמה אזורים כדי להשיג יכולות מעבר לגיבוי (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 לא זמין בארצות הברית.

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

מעבר לגיבוי אוטומטי ויתירות בשליטת הלקוח

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

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

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

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

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

חוסן אזורי

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

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

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

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

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

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

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

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

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

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

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

1. תמיד צריך להירשם לאזור הגיבוי. במקרה כזה, המנוי שומר על חיבור גם לאזור הראשי וגם לאזור הגיבוי בכל רגע. אפשר להשתמש באותם אזורים גם לשרת הראשי וגם לשרת הגיבוי, גם לבעלי תוכן דיגיטלי וגם למנויים. במקרה כזה, המנוי יקבל הודעות רק דרך אזור הגיבוי אם הלייבל עבר לגיבוי.
2. אפשר לזהות ידנית את המנויים ולהעביר אותם לאזור החלופי באמצעות הגדרה. אם מזהים הפסקת שירות, אפשר לבצע מעבר לגיבוי באזור הגיבוי ואז לחזור לאזור הראשי כשההפסקה מסתיימת.
3. מעבר לגיבוי במקרה של שגיאות אצל המנוי. אם הבקשות של המנויים מחזירות שגיאות, זה יכול להעיד על כך שצריך לבצע מעבר לגיבוי (failover) לאזור הגיבוי. שימו לב: ספריות הלקוח של 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. עלייה גדולה במספר הבקשות היוצאות עלולה לגרום לעומס יתר על המעבד (CPU), הזיכרון או קיבולת הרשת של בעל האתר. אם יש עומס יתר על השרת, הוא לא יכול לעבד בקשות או תגובות לפרסום לפני פסק הזמן. כך נוצרות עוד יותר בקשות פרסום, ובסופו של דבר מגיעים לזמן הקצוב הכולל לתפוגה. הגבלת התהליך של בעל התוכן הדיגיטלי מגבילה את מספר ההודעות או הבייטים שיכולים להיות בהמתנה בלי לקבל תגובה מהבקשה לפרסום. הגבלת מספר הבקשות באופן הזה מאפשרת לשמור על רמת ניצול המשאבים ברמה שניתנת לניהול, גם במהלך עליות חדות. בהתאם לאופן הפעולה של בעל התוכן הדיגיטלי, יכול להיות שתאפש ל-RPC של פרסום עוקב להמתין לקיבולת על ידי מתן אפשרות לפרסום לחסום בקשות נוספות. לחלופין, אפשר להגדיר את בקרה על זרימת נתונים כך שתחזיר שגיאה כשהקיבולת מגיעה למקסימום, וכך להודיע למי שמתקשר לשירות על כך. אתם מגדירים איך ספריית הלקוח של בעל התוכן הדיגיטלי מגיבה כשמוגדרת התנהגות של חריגה מהמגבלה.

מנויים לקידום מכירות

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

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

שימוש בגרסה האזורית של מדדי ה-backlog במקום בגרסאות הגלובליות

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

• subscription/num_unacked_messages_by_region
• subscription/oldest_unacked_message_age_by_region

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

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

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

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

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

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

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