המדריך הזה מספק הסבר ותמונה כוללת של תכונות האמינות של Pub/Sub.
למה Pub/Sub?
כמודל להעברת הודעות, מודל פרסום/מינוי נועד להפריד בין יוצרי ההודעות לבין צרכני ההודעות. במקום שהיצרנים ישלחו בקשות ישירות לצרכנים עם הנתונים, הם מפרסמים את הנתונים האלה בשירות Pub/Sub כמו Pub/Sub. השירות מעביר את ההודעות האלה באופן אסינכרוני לצרכנים המעוניינים שנרשמו.
כתוצאה מכך, השירות מטפל בכל המורכבות של מציאת צרכנים שמתעניינים בנתונים. השירות גם מנהל את הקצב שבו הצרכנים מקבלים את הנתונים, על סמך הקיבולת שלהם. ההפרדה הזו מאפשרת ליצרני הנתונים לכתוב הודעות בקנה מידה גדול עם זמן אחזור קצר, בלי קשר להתנהגות של הצרכנים.
שירות Pub/Sub מאפשר להעביר הודעות בצורה אמינה ועם יכולת התאמה גבוהה לעומס. השירות מטפל בחלק גדול מהפעולות האלה באופן אוטומטי, אבל אתם יכולים לשלוט בהיבטים שונים של המפרסמים והמנויים שיכולים להשפיע על הזמינות והביצועים. בהמשך המדריך הזה מפורטים כמה פרטים על ההיבטים האלה.
בידוד
כברירת מחדל, Pub/Sub הוא שירות גלובלי: נושאים ומינויים לא קשורים באופן מהותי לאזורים ספציפיים, והודעות זורמות בתוך שירות Pub/Sub בין אזורים לפי הצורך. כשמשתמשים בנקודת קצה גלובלית, pubsub.googleapis.com, בעלי תוכן דיגיטלי ומנויים מתחברים לאזור הקרוב ביותר ברשת שבו פועל Pub/Sub. כשמשתמשים בנקודות קצה אזוריות, כמו pubsub.us-central1.rep.googleapis.com, או בנקודות קצה מבוססות-מיקום, כמו us-central1-pubsub.googleapis.com, בעלי התוכן הדיגיטלי והמנויים מתחברים ל-Pub/Sub באזור שצוין. כשמפעילים בעלי תוכן דיגיטלי או מנויים מחוץ ל- Google Cloud, מומלץ להשתמש בנקודות קצה אזוריות או מקומיות כדי להבטיח שההודעות יועברו בין האזורים הצפויים באופן עקבי.
בידוד אזורי
כדי לצמצם את התשתית שפעולות הפרסום וההרשמה תלויות בה מחוץ לאזור אחד, ולוודא שכל הנתונים נשארים מבודדים באותו אזור, פועלים לפי השלבים הבאים:
יוצרים נושא לכל אזור.
מרחב השמות של Pub/Sub הוא גלובלי ואי אפשר לקשר נושאים ומינויים לאזור ספציפי, אבל המטא-נתונים של כל המשאבים משוכפלים למאגרי נתונים מקומיים באזור. לכן, אחרי שיוצרים משאב, ההגדרות שלו זמינות גם אם יש בעיה באזור אחר. שימו לב: יכול להיות שעדכונים בהגדרות של הנושא או המינוי לא יופצו באופן מיידי במקרה של הפסקה זמנית בפעילות.
הימנעו משימוש בנקודות קצה גלובליות.
במקום זאת, השתמשו בנקודות קצה אזוריות כשהן זמינות, ובנקודות קצה מבוססות-מיקום כשהן לא זמינות. נקודות קצה אזוריות מציעות בידוד אזורי טוב יותר, אבל הן עדיין לא זמינות בכל האזורים.
משתמשים במדיניות אחסון הודעות ומגדירים את
enforceInTransitלערךTrue.כשמפעילים את האפשרות אכיפה בזמן העברה, הנתונים אף פעם לא יוצאים מהאזור, וכל הלקוחות שמתחברים לנושא באזור מסוים מגדירים את מדיניות אחסון ההודעות לאותו אזור.
כשמגדירים נושאים בצורה כזו, אפשר להיות בטוחים שכל פעולות הפרסום וההרשמה כותבות וקוראות נתונים רק בתוך האזור. אם יש כשלים בפרסום, במינוי או ב-Pub/Sub באזור מסוים, העברת ההודעות נפסקת באותו אזור. העברת ההודעות בנושאים ובמינויים באזורים אחרים לא מושפעת.
אם אתם צריכים שגם הפעולות הניהוליות ומרחב השמות של הנושאים והמינויים יהיו מבודדים אזורית, כדאי להשתמש בשירות מנוהל ל-Apache Kafka.
יתירות כשל
אם אתם לא צריכים בידוד אזורי, אתם יכולים לנצל את היכולת של Pub/Sub להעביר הודעות ביעילות בין כמה אזורים, כדי להשיג יכולות של יתירות כשל במספר אזורים. בהמשך הסעיף הזה נסביר איך ליצור נושאים ומינויים, ואיך להציב מפרסמים ומנויים כדי לתמוך בסוגים שונים של יתירות כשל ויתירות נתונים.
סמנטיקה של יתירות כשל כברירת מחדל
נניח שיש נושא אחד ומינוי אחד. אתרי החדשות נמצאים באזורים בארצות הברית ובאוסטרליה, והמנויים נמצאים באזורים באירופה ובאוסטרליה. Google Cloud אם לכל המנויים יש מספיק קיבולת לקבלת הודעות, זרימת ההודעות נראית כך:
האות P מייצגת אפליקציות לשליחת הודעות, והאות S מייצגת אפליקציות רשומות. המשושה הכחול מייצג את שירות Pub/Sub. הגלילים מייצגים את המקומות שבהם ההודעות מאוחסנות (ההודעות תמיד נשמרות בכמה אזורים באזור שבו הן מתפרסמות). אם יש אפליקציות רשומות זמינות, Pub/Sub מעדיף לשלוח הודעות באותו אזור שבו הן פורסמו. אחרת, הוא שולח את ההודעות לאזור הקרוב ביותר ברשת עם מנויים שיש להם קיבולת. לכן, כמו שמוצג בתמונה הקודמת, הודעות שפורסמו בארצות הברית נשלחות למנויים באירופה, והודעות שפורסמו באוסטרליה נשארות באוסטרליה.
בקטעים הבאים מוסבר מה קורה בתרחישי כשל שונים.
מנויים באירופה לא זמינים
נניח שהמנויים באירופה נדחו או קרסו לעיתים קרובות, ולא הצליחו לשמור על החיבור ל-Pub/Sub. אם זה יקרה, השירות יתחיל להעביר הודעות למנויים באוסטרליה:
האפשרות להירשם לא זמינה באירופה ובאוסטרליה
אם כל האפליקציות הרשומות לא זמינות, ההודעות נשמרות ב-Pub/Sub עד לסיום משך הזמן שהוגדר לשמירת ההודעות.
כשהמנויים מתחברים מחדש, ההודעות נשלחות, אלא אם ההפסקה נמשכת יותר ממשך הזמן שהוגדר לשמירת ההודעות. כברירת מחדל, שמירת ההודעות במינוי מוגדרת ל-7 ימים. אפשר גם להגדיר שמירת הודעות בנושא למשך עד 31 ימים. אל תבחרו משך זמן לשמירת הודעות שקצר יותר מההפסקה המקסימלית שאתם צופים או מוכנים לסבול.
Pub/Sub לא זמין באירופה
למרות שזה נדיר, יכול להיות שתרצו לטפל גם במקרים שבהם Pub/Sub עצמו לא זמין. חוסר זמינות של Pub/Sub מתבטא בתקופות ממושכות של שגיאות לא צפויות בבקשות פרסום או הרשמה, או בחוסר יכולת להעביר הודעות שפורסמו למנויים. לדוגמה, אם Pub/Sub לא פועל באזור באירופה, התרחיש נראה דומה מאוד למצב שבו המנויים לא פועלים:
שימו לב שבמקרה כזה, המנויים באירופה לא עוברים לגיבוי באזור אחר, גם אם משתמשים בנקודת הקצה הגלובלית. ב-Pub/Sub אין מעבר אוטומטי למצב כשל, וזה מכוון. נניח שהמנויים עצמם גורמים לבעיה בלתי צפויה ב-Pub/Sub, שמובילה לחוסר זמינות. בעיה כזו נחשבת להפסקה משמעותית בשירות. עם זאת, היקף ההשפעה של ההפסקה יכול להיות מוגבל לאזור שאליו המנויים התחברו. אם השירות היה מאפשר להם לעבור לאזור אחר, המנויים היו יכולים לגרום לחוסר זמינות גם שם, וכתוצאה מכך לגרום לכשל מדורג בכל השירות.
בעלי תוכן דיגיטלי באוסטרליה לא זמינים
אם בעלי האפליקציות המפרסמות באזור מסוים לא זמינים, ההודעות שכבר פורסמו עדיין נמסרות לאפליקציות הרשומות הקרובות ביותר:
בסופו של דבר, כל ההודעות נצרכות ומאושרות על ידי המנויים. כששולחים הודעות, Pub/Sub מנסה לצמצם את המרחק ברשת. לכן, המנויים באזור באוסטרליה יכולים להפסיק לקבל הודעות אם למנויים באירופה יש מספיק קיבולת כדי לטפל בכל ההודעות שפורסמו בארצות הברית.
Pub/Sub לא זמין בארצות הברית
Pub/Sub כותב הודעות באופן סינכרוני לכמה אזורים בתוך אזור. לכן, הפסקה זמנית בשירות באזור מסוים לא מספיקה כדי למנוע את מסירת ההודעות, אלא רק אם כל האזור לא זמין. אם שירות Pub/Sub לא זמין באזור שבו אפליקציות מפרסמות שולחות הודעות, יכול להיות שההודעות באזור הזה לא יימסרו עד שהשירות ישוחזר במלואו:
בסופו של דבר ההודעה עדיין נמסרת (בהנחה שתקופת שמירת ההודעות לא חלפה), בעיכוב של משך זמן ההפסקה. שימו לב: בדומה למנויים, גם בעלי התוכן הדיגיטלי בארצות הברית לא עוברים לאזור אחר כשהשירות נכשל. ההתנהגות הזו עוזרת למנוע את הסבירות לכשלים מדורגים באזורים שונים, שנגרמים בגלל בעיה בבעל התוכן הדיגיטלי או במינוי.
יתירות כשל ויתירות בשליטת הלקוח
יכול להיות שסמנטיקת ברירת המחדל של יתירות כשל ב-Pub/Sub לא תבטיח באופן מלא שהודעות תמיד יוכלו לעבור מבעלי התוכן הדיגיטלי למנויים, אם יש הפסקה בשירות בכל שלב בתהליך. הפסקות בשירות יכולות להתרחש בכמה מקומות שונים, כולל בלקוחות, בשירות שבו פועלים בעלי האפליקציות או המנויים, ברשת, או אפילו ב-Pub/Sub עצמו (במקרים נדירים). אם אתם רוצים שהשירותים שלכם יהיו עמידים בפני הפסקות כאלה, אתם צריכים להטמיע יתירות משלכם. בדרך כלל, היתירויות האלה כוללות שימוש במספר מופעים של לקוחות מפרסמים ומנויים, כאשר כל אחד מהם משתמש בנקודת קצה שונה של מיקום.
יכול להיות שתרצו עמידות בשני היקפי השפעה שונים: אזורי או תחום. אלה אפשרויות ההגדרה של כל אחד מהם.
עמידות ברמת האזור (zone)
ל-Pub/Sub יש שכפול מובנה בין אזורים. לא צריך לבצע פעולות מיוחדות כדי להתמודד עם הפסקות בשירות באזור יחיד שמשפיעות על השירות עצמו. עם זאת, כדי שהלקוחות או הרשת יהיו עמידים בפני הפסקות, מומלץ להפעיל בעלי תוכן דיגיטלי ומנויים עם קיבולת מספקת בכמה אזורים בתוך האזור. אם אזור אחד מושבת, הלקוחות באזור השני יכולים לקבל את התנועה ולעבד את ההודעות. מומלץ לא לפרסם שינויים בלקוחות האלה בו-זמנית, כדי שאם תהיה תקלה, האזורים האחרים שלא הושפעו יוכלו להמשיך לעבד הודעות.
עמידות אזורית
כדי שהמערכת תהיה עמידה בפני כשלים אזוריים, צריך להגדיר יתירות נוספת בבעלי התוכן הדיגיטלי ובמנויים. אפשר להפעיל בעלי תוכן דיגיטלי ומנויים בכמה אזורים כדי להתמודד עם האפשרות של הפסקות בשירות אצל הלקוחות האלה או ברשת.
אם אתם רוצים להיות עמידים בפני כשלים פוטנציאליים ב-Pub/Sub באזור מסוים, אתם צריכים להכין מנגנון יתירות כשל כדי להתמודד עם הפסקה כזו. הגישות האפשריות הן פשרה בין זמן האחזור של מסירת ההודעות מקצה לקצה לבין העלות.
כדי לצמצם את זמן האחזור במקרים שבהם העלות לא מהווה שיקול, האסטרטגיה הטובה ביותר היא תמיד לפרסם ולהירשם בו-זמנית באזורים שונים. קודם כול, בוחרים את מספר האזורים שבהם רוצים יתירות. בשלב הבא, למרות שזה לא הכרחי, אתם יכולים להגדיר נושא ומינוי לכל אחד מהאזורים האלה.
כל בעל תוכן דיגיטלי יוצר לקוחות כמספר האזורים (אחד לכל אזור) ומשתמש בנקודת קצה שונה למיקום כדי לוודא שההודעות מופנות לאזורים נפרדים. אם משתמשים בנושאים נפרדים, כל לקוח שמפרסם צריך לפרסם בנושא המתאים לכל אזור. לכל הודעה, בעל התוכן הדיגיטלי קורא לפרסום בכל לקוח. בגלל הפרסומים המיותרים, אין צורך לנסות שוב לפרסם אם אחד מהם נכשל.
באופן דומה, כל מנוי יוצר את אותו מספר של לקוחות מנויים – אחד לכל אזור – ומשתמש בנקודת קצה מבוססת-מיקום כדי להתחבר לאזור אחר. אם משתמשים במינויים שונים לכל אזור, כל לקוח מנוי צריך להשתמש במינוי המתאים. שימו לב שהאזורים שבהם משתמשים המפרסמים והמנויים לא בהכרח צריכים להיות זהים. האפליקציות הרשומות מקבלות הודעות משלושת המינויים ומעבדות אותן.
להגדרה הזו יש כמה תכונות ודרישות עיקריות:
- הפסקה בשירות באזור אחד לא משפיעה על עיבוד ההודעות שכבר פורסמו, וגם לא על אלה שפורסמו במהלך ההפסקה בשירות. מכיוון שההודעות פורסמו בכמה אזורים, הן עדיין זמינות באזורים אחרים במקרה שאחד מהאזורים מושבת. במהלך ההפסקה, קריאות הפרסום נכשלות באזור המושפע, אבל מצליחות באזורים האחרים.
- הזמן שלוקח לעבד את ההודעות לא מושפע כל עוד אחד מהאזורים שדרכם ההודעות עוברות זמין.
- עיבוד ההודעות חייב להיות אידמפוטנטי. כל הודעה נשלחת כמה פעמים, ולכן עיבוד ההודעות צריך להיות עמיד בפני כפילויות. במקרה של הפסקה זמנית בשירות באזור מסוים, יכול להיות שחלק מהעותקים הכפולים יגיעו הרבה אחרי שההודעה נמסרה בפעם הראשונה. סביר להניח שהכפילויות האלה הגיעו מאזור אחר שלא הייתה בו הפסקה זמנית בשירות.
הפעלה עם יתירות כזו מספקת את העמידות הגבוהה ביותר לכל סוג של הפסקות זמניות בשירות. ההגדרה הזו מועדפת לשירותים פנימיים של Google שמסתמכים על Pub/Sub ודורשים את הזמינות הגבוהה ביותר. עם זאת, בהגדרה הזו עלות שליחת ההודעות מוכפלת במספר האזורים שבהם משתמשים. בנוסף, יש עלות נוספת לשימוש ברשת בין אזורים, להודעות שצריך להעביר בין אזורים.
גישה אחרת ליתירות היא לבצע מעבר לגיבוי בעת כשל רק כשבקשות נכשלות או כשהודעות לא זורמות מהמפרסמים למנויים כצפוי. בתרחיש הזה, יש לכם אזור ראשי שאליו אתם מפנים את המפרסמים והמנויים שלכם דרך נקודות קצה (endpoints) של מיקום. כמו קודם, לא חייבים לבחור באותו אזור. בנוסף, יש לכם אזור חלופי לבעלי תוכן דיגיטלי ולמנויים, שמשמש כשהאזור הראשי לא זמין.
בעלי התוכן הדיגיטלי מפרסמים רק באזור הראשי (דרך נקודת הקצה מבוססת-המיקום) כשהבקשות נשלחות בהצלחה. בכל פעם שנקבע שהאזור מושבת, בעלי התוכן הדיגיטלי מתחילים לפרסם באזור החלופי. יש שתי דרכים לקבוע שהאזור מושבת ולעבור למצב של מעבר לגיבוי בעת כשל. אפשר לעשות את זה בתהליך ידני, וההגדרות מתעדכנות באופן דינמי אצל בעלי האפליקציות. בעלי התוכן הדיגיטלי יכולים גם לעדכן את ההגדרות בעצמם אם שיעור השגיאות בבקשות הפרסום גבוה מספיק.
המנויים חייבים תמיד להתחבר לאזור הראשי דרך נקודת הקצה של המיקום. אתם יכולים להחליט שהמנוי יוכל להשתמש באזור החלופי באמצעות אחד או יותר מהטריגרים הבאים:
- תמיד להירשם לאזור הגיבוי. במקרה כזה, המנוי שומר על חיבור לאזור הראשי ולאזור החלופי בכל שלב. אפשר להשתמש באותם אזורים כראשיים וכחלופיים גם לבעלי התוכן הדיגיטלי וגם למנויים. במקרה כזה, המנוי צריך לקבל הודעות דרך אזור הגיבוי רק אם המוציא לאור נכשל.
- לזהות באופן ידני את המנויים ולהעביר אותם לאזור החלופי באמצעות הגדרה. אם אתם מזהים הפסקה, אתם יכולים לעבור לאזור הגיבוי ואז לחזור לאזור הראשי כשההפסקה מסתיימת.
- מעבר למצב של יתירות במקרה של שגיאות במנוי. אם בקשות המנוי מחזירות שגיאות, אתם יכולים להשתמש בזה כאינדיקציה לכך שצריך לעבור לאזור הגיבוי. שימו לב שספריות הלקוח של Pub/Sub מנסות שוב לשלוח בקשות משיכה בסטרימינג באופן פנימי, במקרה של שגיאות זמניות, כך שיכול להיות שלא תוכלו לזהות שיש תקופות ארוכות של שגיאות לא צפויות. בנוסף, שיעור השגיאות של משיכת הנתונים בסטרימינג צפוי להיות 100%, גם במהלך פעולה רגילה.
- מעבר למצב גיבוי אם המנוי לא מקבל הודעות במשך זמן ארוך מהצפוי. בהנחה שההודעות מתפרסמות באופן עקבי, המנויים תמיד יכולים לקבל הודעות. אם עובר הרבה זמן בלי שהם מקבלים הודעות, יכול להיות שיש בעיה בצד של המינוי ב-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 הבאות של הפרסום להמתין לקיבולת, על ידי כך שתאפשרו לפרסום לחסום בקשות נוספות. לחלופין, אתם יכולים להחזיר שגיאה למבצעי הקריאות לשירות שלכם באמצעות בקרת זרימה, כשהקיבולת מגיעה למקסימום. אתם יכולים להגדיר איך ספריית הלקוח של בעל התוכן הדיגיטלי תגיב כשהיא חורגת מהמגבלה.
מנויים לכוונון עדין
יכול להיות שיהיה צורך גם בכוונון של המנוי כדי לוודא שהוא פועל בצורה מהימנה. בדומה לבעלי תוכן דיגיטלי, אתם יכולים לשנות את הגדרות בקרת הזרימה של המנויים כדי לוודא שהם לא יקבלו יותר מדי הודעות. ספריית הלקוח של המנוי משתמשת במשיכה בסטרימינג, שבה הלקוח פותח סטרימינג קבוע לשרת והשרת שולח הודעות כשהן זמינות. אם יש עלייה גדולה במספר ההודעות שפורסמו, יכול להיות שהמנוי יקבל יותר הודעות ממה שהוא יכול לעבד. כאשר בקרת הזרימה מופעלת, מספר ההודעות שלא אושרו ועדיין ממתינות ללקוח מוגבל. כך מצמצמים את מספר ההודעות שמטופלות בו-זמנית, ומפזרים את העיבוד שלהן על פני פרק זמן ארוך יותר. פיזור העומס מאפשר למנויים לא לחרוג ממגבלות המשאבים שמשפיעות על עיבוד ההודעות, מה שעלול לגרום לאפקט דומינו שיוביל לחוסר יכולת לעבד הודעות בכלל.
בקרת זרימה לבדה מספיקה אם אתם מצפים רק לעליות חדות בכמות הנתונים לעיבוד, שבסופו של דבר יורדות. אם התנועה גדלה באופן כללי לאורך זמן בגלל שימוש רב יותר, בקרת הזרימה מגינה על המנויים. עם זאת, זה עלול לגרום להצטברות של הודעות שלא נמסרו לפני שמשך שמירת ההודעות חלף. במקרים כאלה, כדאי גם להגדיר התאמה אוטומטית לעומס (autoscaling) כדי להפעיל יותר מנויים בתגובה למספר הולך וגדל של הודעות שלא אושרו. הדרך שבה מגדירים את זה תלויה בפלטפורמת המחשוב שבה משתמשים המנויים. לדוגמה, באמצעות הכלי להתאמה לעומס (autoscaler) של Compute Engine, אתם יכולים לשנות את קנה המידה על סמך מדדים כמו מספר ההודעות שלא נמסרו. השימוש בשילוב של התאמה אוטומטית לעומס ובקרת זרימה מאפשר לוודא שהמנויים שלכם עמידים בפני עליות חדות אחרות לטווח קצר בקצב העברת ההודעות, ובפני צמיחה לטווח ארוך שדורשת יותר כוח מחשוב. חשוב לפעול לפי השיטות המומלצות לשימוש במדדי Pub/Sub כאות לשינוי קנה מידה.
שימוש בגרסה האזורית של מדדי צבר ההזמנות במקום בגרסאות הגלובליות
כשאתם עוקבים אחרי צבר המשימות של המינוי, מגדירים מדיניות התראות או מתאימים אוטומטית לעומס את האפליקציות הרשומות, Pub/Sub מציע שתי גרסאות לכל מדד של צבר המשימות. חשוב להשתמש בגרסאות עם הסיומת by_region:
אם אתם רוצים שהמעקב, ההתראות וההתאמה האוטומטית לעומס יהיו עמידים בפני הפסקות שירות באזור אחד, אל תשתמשו בגרסאות הגלובליות של המדדים האלה (subscription/num_undelivered_messages ו-subscription/oldest_unacked_message_age). כדי לחשב את הגרסאות הגלובליות של המדדים האלה, צריך לחשב את צבר המשימות בכל האזורים שידוע שיש בהם הודעות. לכן, אם אזור אחד לא זמין, נוצר פער בנתונים. לעומת זאת, הגרסאות של המדדים ב-by_region מחשבות את צבר המשימות ומדווחות עליו לפי אזור. אם אי אפשר לחשב את הצבר באזור מסוים, המדד עדיין ידווח על ערכים באזורים האחרים.
שימוש בתמונת מצב ובחיפוש לפריסות בטוחות
אובדן הודעות הוא בדרך כלל אירוע קטסטרופלי. ב-Pub/Sub יש אפשרות של לפחות מסירה אחת לכל ההודעות שפורסמו. עם זאת, העיבוד הנכון של ההודעות האלה תלוי בהתנהגות של המנויים. אם ההודעות אושרו בהצלחה, Pub/Sub לא שולח אותן מחדש. לכן, אם יש באג בקוד של מנוי חדש שפרסתם, שמאשר הודעות בלי לעבד אותן כמו שצריך, יכול להיות שהמנוי יגרום לאובדן הודעות. ב-Pub/Sub יש את התכונה תמונת מצב וחיפוש, שעוזרת לוודא שכל הודעה מעובדת בצורה נכונה, גם אם יש באגים במנוי.
התבנית של כל פריסת מנוי צריכה להיות:
משך הזמן שצריך להמתין לפני שבודקים אם המינוי החדש פועל משתנה בהתאם לתרחיש לדוגמה. הדרך היחידה לצאת מרצף השלבים היא כשמנוי נחשב לפעיל, ובשלב הזה אפשר למחוק את קובץ ה-snapshot.
השימוש בתמונת מצב ובחיפוש לא נועד להחליף את השיטות המומלצות להרצת תוכנה בסביבה שאינה סביבת ייצור, ואת הפריסה ההדרגתית בסביבת הייצור. הם מספקים רמת הגנה נוספת כדי להבטיח עיבוד אמין של הנתונים. החיסרון הוא שחיפוש בתמונת המצב עלול לגרום למסירה כפולה של הודעות שהמנוי עיבד בהצלחה. עם זאת, מכיוון שב-Pub/Sub יש סמנטיקה של מסירה לפחות פעם אחת כברירת מחדל, המנויים שלכם כבר עמידים בפני מסירה חוזרת של הודעות.