סקירה כללית של הארכיטקטורה של Pub/Sub

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

הערכת הביצועים של שירות העברת הודעות

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

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

מדרגיות

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

• מספר הנושאים

• מספר בעלי האתרים

• מספר המינויים

• מספר המנויים

• מספר ההודעות

• גודל ההודעות

• שיעור ההודעות (throughput) שפורסמו או נצרכו

• גודל העומס בכל מינוי נתון

זמינות

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

זמן אחזור

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

1. משך הזמן שעובר עד לאישור קבלת הודעה שפורסמה.

2. משך הזמן שנדרש כדי להעביר הודעה שפורסמה למנוי.

ארכיטקטורה בסיסית של Pub/Sub

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

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

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

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

מישור הבקרה

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

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

מישור הנתונים – מחזור החיים של הודעה

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

1. בעל תוכן דיגיטלי שולח הודעה.

2. ההודעה נכתבת לאחסון.

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

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

5. האפליקציות הרשומות שולחות אישור ל-Pub/Sub שהן עיבדו את ההודעה.

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

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

בכל אשכול, ההודעה נכתבת ל-M דיסקים עצמאיים (כאשר M הוא מספר אי-זוגי). כדי שהנתונים ייחשבו כנתונים קבועים באשכול, הם צריכים להיות ב-⌈M/2⌉ דיסקים. בסך הכול, כל הודעה שמתפרסמת נכתבת לפחות ל-⌈M/2⌉ דיסקים עצמאיים ב-⌈N/2⌉ אשכולות לפני שהיא נחשבת כנתונים קבועים, ובסופו של דבר היא משוכפלת ל-N*M דיסקים.

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

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

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

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

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

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

שמירה על פעילות של Pub/Sub

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

סביבות

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

השקה

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

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

2. לבנות גרסה חדשה של כל השרתים.

3. פורסים את השרתים החדשים בסביבות הבדיקה וההכנה.

4. מריצים את השרתים בסביבת הבדיקה ובסביבת הביניים במשך כמה ימים.

5. אם אין בעיות מוכרות, משחררים את השרתים ל-Canary, קבוצת משנה של סביבת הייצור שכוללת כמות קטנה של תנועת לקוחות.

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

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

מעקב

כדי ש-Pub/Sub יפעל בצורה תקינה, צריך לזהות ולפתור בעיות באופן אוטומטי לפני שהן נראות למשתמשי הקצה. כדי לעשות את זה, צריך לבצע מעקב מקיף של המערכת. צוות Site Reliability Engineering (SRE) מתחזק קבוצה של מדדים לרמת השירות (SLI), מדדים מוגדרים היטב שמתארים את התנהגות המערכת. המדדים יכולים לכלול את 'משך הזמן שנדרש להשלמת בקשת CreateSubscription' או את 'שיעור השגיאות שנוצרות על ידי בקשות Publish'. המדדים האלה נמדדים במגוון דרכים. חלק מהם פנימיים לחלוטין ל-Forwarders ולנתבים שלנו. לדוגמה, הם מודדים כמה זמן לוקח לכתוב הודעות לדיסק.

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

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

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

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

המדדים שהכי מעניינים את המשתמשים בשירות מוצגים דרך Google Cloud Monitoring.

אמצעי בקרה

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

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

סיכום

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

מילון מונחים

מונח	תיאור
אשכול	קיבוץ לוגי של מכונות שבדרך כלל חולקות את אותו דומיין כשל (למשל, רשת מקומית משותפת וחשמל משותף).
מישור הבקרה	השכבה של Pub/Sub שמטפלת בהקצאה של בעלי תוכן דיגיטלי ומנויים לשרתים במישור הנתונים.
מישור הנתונים	השכבה של Pub/Sub שמטפלת בהעברת הודעות בין אפליקציות לשליחת הודעות לבין אפליקציות רשומות.
תוכנת Forwarder	שרת במישור הנתונים.
גישה גלובלית לנתונים	לקוחות של מפרסמים ומנויים ב-Pub/Sub לא יודעים את המיקום של הנתונים. השירות מבצע את כל הניתוב והאחסון בהתאם למדיניות בנושא הגבלת מיקום.
ניתן להרחבה אופקית	היכולת של שירות לטפל בצורה חלקה בעומס גדול יותר על ידי הגדלת מספר המופעים של רכיבי השירות.
הודעה	הנתונים שמועברים דרך Pub/Sub.
המרחק ברשת	מדד של זמן האחזור בחיבור בין שתי נקודות.
prober	משימה שפועלת כלקוח ומבצעת באופן צפוי פעולה אחת או יותר בשרתי Pub/Sub.
פרסום מקור ההודעה	קבוצת הודעות שהתקבלו ואוחסנו על ידי מעביר לפרסום, וקבוצת מזהים של הודעות שאושרו על ידי כל המינויים המצורפים.
שירות publish/subscribe‏ (Pub/Sub)	שירות העברת הודעות שיש בו הפרדה בין מי ששולח הודעות לבין מי שמקבל הודעות
אפליקציה לשליחת הודעות	לקוח של Pub/Sub שיוצר הודעות ושולח (מפרסם) אותן בנושא ספציפי.
נתב	שרת במישור הבקרה.
אילוצים בתכנון המסלול	רשימת כללים שמציינת אילו מעבירים נתונים נתבים צריכים לשלוח ללקוחות כנקודות קצה אפשריות להתחברות, ואילו לא.
הסכם רמת שירות (SLA)	רשימה של יעדי זמינות (SLO) שמגדירים את ערבויות הביצועים של המערכת ללקוחות, ומתארים את ההשלכות אם היעדים לא יושגו.
מדד רמת שירות (SLI)	מדד מוגדר היטב שמתאר את התנהגות המערכת.
יעדים למדידת רמת השירות (SLO)	יעד ספציפי למדד רמת שירות.
אפליקציה רשומה	לקוח של Pub/Sub שמקבל הודעות במינוי ספציפי.
מינוי	ישות בעלת שם שמייצגת עניין בקבלת כל ההודעות בנושא מסוים.
התחייבות לנקודת סנכרון	השעה שבה נוצר מינוי, שבה כל ההודעות שמתפרסמות לאחר מכן יישלחו למנויים.
נושא	ישות בעלת שם שמייצגת פיד של הודעות.