מדוע התור של Azure Service Bus מאבד הודעות בעומסי שיא
בעומס שיא, התור Azure Service Bus מתנהג אחרת מאשר בסביבת בדיקה: העומק גדל מהר יותר מקצב צריכת ההודעות על ידי הצרכנים, ואובדן ההודעות לא מתגלה מיד. תחילה זה עיכוב בעיבוד, אחר כך עלייה במספר ניסיונות המסירה, ולבסוף תור מת.
הסיבה כמעט אף פעם אינה הברוקר עצמו — מצטברים מגבלות המנוי, היעדר הגבלת מקבילות אצל הצרכן וזמן חיים קצר מדי של ההודעה.
לאחר מכן מופעל אפקט מפל: ההודעה לא מאושרת בזמן, הנעילה פגה, הברוקר מספק אותה שוב, והמטפל מפעיל את אותה פעולה בפעם השנייה. מסירה חוזרת הופכת לכפילויות של חיובים, בעוד התורן מטפל בתקלה ידנית. חלק מההודעות עוברות לתור המת, חלקן פגות תוקף — ואין כבר דרך לשחזר אותן.
המחיר של כשל אינו רק השבתת החלפת ההודעות. כל תקלה מנותחת ידנית: להעלות מדדים, להצליב מזהים, למצוא את השלב שבו אבדה ההודעה, למסור אותה שוב בלי לשכפל את הפעולה. אם ההרשאות לתור ניתנות באופן רחב, נוסף סיכון: כל שירות יכול לקרוא ולמחוק הודעות של אחרים.
לכן אנו מתחילים לא מהגדרות, אלא מניתוח הזרימה: היכן ההודעה עלולה ללכת לאיבוד, אילו חזרות בטוחות, מה מגביל את הצרכן בעומס שיא, ובאיזה סימן התורן מבין שהגיע הזמן להתערב. להלן כיצד זה נסגר.
מה נותנת אפיק מנוהל: עמידות ונראות
אפיק מנוהל Azure Service Bus מסיר סוג שלם של כשלי אינטגרציה בזכות אישורי מסירה וניסיונות חוזרים עם השהיה הולכת וגדלה. ההודעה עוזבת את התור רק לאחר עיבוד מוצלח, ובמקרה של מיצוי הניסיונות היא עוברת לתור ההודעות שלא נמסרו עם קוד סיבה.
כפילויות נחסמות באמצעות מפתח אידמפוטנטיות בצד הצרכן — הפעלה חוזרת לאחר כשל אינה יוצרת הזמנות וחיובים כפולים.
הנראות נבנית על מדדי האפיק עצמו: אורך התור, גיל ההודעה הוותיקה ביותר, מספר הניסיונות החוזרים, שיעור הפעלת מפסק הקריסה. מזהה מקצה לקצה מקשר בין הרשומה באפיק לעיבוד בשירות, ולכן התקלה מנותחת לפי יומן רישום ולא לפי לוגים מפוזרים של אפליקציות. התראה מוגדרת על גידול בתור ההודעות שלא נמסרו — התורן לומד על הבעיה לפני שהעסק מבחין בה.
הגישה מופרדת לפי תפקידים: שולחים רק כותבים, צרכנים רק קוראים, וטיפול בהודעות שלא נמסרו — תפקיד נפרד לתורן. מפתחות מאוחסנים במאגר סודות ומתחלפים, ומחרוזות חיבור ישירות בקונפיגורציה של השירותים לא נשארות.
פרופיל העומס מורץ לפני הפרודקשן: זרימת שיא, כשל של צרכן אחד, עיכוב ממושך בעיבוד. לאחר הרצה כזו, זמן ההתאוששות מכשל נמדד בדקות, שיעור ההודעות שאבדו עבור שליחות מאושרות הוא אפס, והיקף הניתוחים הידניים יורד ליחידות בשבוע.
מצבי מסירה וטופולוגיות תורים
הטופולוגיה של התור קובעת לא רק את מסלול ההודעה, אלא גם כיצד המערכת תתנהג בעת כשל. מצב מסירה שנבחר באופן שגוי מתגלה רק תחת עומס: כפילויות הזמנות, אירוע שאבד, תור פריקה שנתקע. להלן האפשרויות שביניהן בוחרים בפועל בעת תכנון ההחלפה.
אפשרויות החלפה והמגבלות שלהן
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| תור "נקודה לנקודה" | מפיק אחד — צרכן אחד: פקודות, משימות עיבוד | צרכנים מתחרים אינם שומרים על סדר לפי מפתח עסקי |
| נושא עם מספר מנויים | אירוע צריך לעבור באופן עצמאי למספר מערכות | כל מנוי שומר עותק משלו, הנפח גדל ליניארית עם מספר הצרכנים |
| הפעלות (סשנים) | סדר קפדני במסגרת מפתח: הזמנה אחת, חשבונית אחת | הפעלה מעובדת על ידי צרכן אחד — מקביליות נמוכה יותר |
| ביטול כפילויות | המקור חוזר על שליחה בעת כשל שלו | חלון שמירת המפתח מוגבל, ויש לציין את המפתח במפורש |
| העברה אוטומטית | פריקת תור הקלט וניתוב לפי מאפיין | השרשרת מסתירה את נתיב ההודעה, ומסבכת ניתוח תקלות |
ניתן לשלב מצבים: הפעלות מעל מנויים נותנות סדר לפי מפתח וצרכנים בלתי תלויים, וביטול כפילויות יחד עם העברה אוטומטית סוגר מסירה חוזרת בממשק בין שירותים. חשוב שכל שילוב משנה גם את פרופיל העומס — מספר המטפלים בו-זמנית, זמן החיים של ההודעה, וסף המעבר לתור ההודעות שלא נמסרו.
אנו מתעדים את הטופולוגיה הנבחרת בסכימת ההחלפה ובהגדרות, כדי שההתנהגות בעת כשל תהיה צפויה. בפלטפורמת Azure Service Bus מצבים אלו מוגדרים באופן הצהרתי, ולכן הסכימה נשארת ניתנת לשחזור בין סביבות.
הטמעה: משלב הביקורת ועד למסירה לתפעול
לפני שינויים בסביבת העבודה, אנו מתעדים את מצב החלפת ההודעות הנוכחי: מי מפרסם, מי קורא, היכן הודעות הולכות לאיבוד או מעובדות פעמיים. ביקורת אינטגרציה מספקת מפת זרימות ורשימת צווארי בקבוק, ולכן כל שלב עוקב נשען על נתונים מאומתים ולא על הנחות.
- ביקורת אינטגרציה. מנתחים מפרסמים ומנויים, נושאים ותורים של Azure Service Bus, חזרות בצד הלקוח ואזורים ללא הגנה מפני כפילויות. בפלט — סכימת זרימות עם זמן עיבוד ונפח הודעות שעברו לעיבוד מושהה.
- תכנון סכימה. מפרשים את העומס לפי תורים ומנויים, קובעים כללי מסירה חוזרת, זמן חיים של ההודעה וסינון כפילויות.
- הגדרת תורים והרשאות. יוצרים ישויות, מגדירים הפרדת הרשאות בין שירותים לאנשים: כל אחד מקבל בדיוק את הפעולות שהוא צריך.
- בדיקת עומס. מריצים זרימת שיא ותרחישי כשל: מנוי לא זמין, עיבוד איטי, גידול בתור. בודקים אם המערכת מתאוששת בעצמה ותוך כמה זמן.
- נהלי תפעול. מתארים ספי הפעלה, פעולות התורן, סדר הוצאה של הודעות מהעיבוד המושהה וכללי שינוי הגדרות.
- מסירה לתמיכה. עורכים סקירה של הסכימה עם הצוות שלכם, מוסרים תיעוד ונשארים בקשר בתקופת השינויים הראשונים.
מדיניות גישה, תפקידים ונהלים: מה מועבר
בסיום, הלקוח מקבל לא "תור מוגדר", אלא ערכה שלמה שלפיה ניתן לתפעל את השירות, להעביר אותו לצוות אחר ולעבור ביקורת אבטחה. עבור Azure Service Bus זה חשוב במיוחד: הגישה כאן ניתנת ברמת מרחב השמות וישויות בודדות, וללא נהלים מפורשים ההרשאות מתפזרות תוך חודשיים. להלן סט מינימלי של ארטיפקטים שאנו מוסרים יחד עם האפיק הפעיל.
- מדיניות גישה — מדיניות נפרדת לשליחה, קבלה וניהול עבור כל שירות במקום מפתח כללי אחד לכל הסביבה.
- תפקידים ומפתחות — קישור שירותים באמצעות זהויות מנוהלות, היכן שנתמך; היכן שלא — מפתח עם ציון הבעלים, מועד החלפה ונוהל ביטול.
- הפרדת הרשאות — מטריצה "שירות → תור או נושא → פעולות מותרות", שממנה רואים מי יכול לכתוב או לקרוא ולאן.
- סכימת זרימות הודעות — שולחים, מנויים, כללי סינון, טיפול בחזרות ותור הודעות שלא נמסרו.
- תיאור ישויות — תורים, נושאים, מנויים, זמן חיים של הודעות, הגנה מפני כפילויות, מצב הפעלות: הכל עם נימוק לערכים שנבחרו.
- תיעוד — טופולוגיה, כללי שמות, רשימת בעלי שירותים והוראות לחיבור צרכן חדש.
- נהלי תחזוקה — תדירות החלפת מפתחות, נוהל הוצאת שירות מהרשאה, טיפול בהודעות שהצטברו ולא נמסרו וספי התראות.
חבילה כזו מסירה את הבעיה העיקרית בתפעול — כשהאפיק עובד, אבל אף אחד לא יודע אילו הרשאות ניתנו למי ומה לעשות בעת כשל. תארו את המשימה שלכם — נחזור עם הערכה ותוכנית עבודה.
מקרה בוחן: זרימת הזמנות בעומס שיא
לפני השינויים, כל זרימת ההזמנות עברה דרך תור אחד Azure Service Bus: היו שני מנויים, ומחרוזת חיבור עם הרשאות גם לשליחה וגם לקריאה ניתנה בקונפיגורציה משותפת. בעומס שיא אחד המנויים קרס, ההודעות חזרו לתור ועובדו מחדש — לקוחות קיבלו שתי הזמנות זהות, והמהנדס התורן טיפל בכפילויות ידנית. ההתאוששות מכשל כזה ארכה עד 40 דקות, ולא היה דרך להבין את הסיבה: איש לא אסף מדדי תורים.
מה בדיוק שינו
- הפרדנו זרימות: הזמנות בעדיפות, אנליטיקה ברקע והתראות עברו לתורים נפרדים עם מנויים ומגבלות משלהם.
- הפעלנו ביטול כפילויות לפי מזהה הזמנה ומספר מוגבל של ניסיונות חוזרים עם העברה לתור הודעות שלא נמסרו.
- החלפנו את מחרוזת החיבור במתן הרשאות לפי תפקידים: לכל שירות רק הפעולות שהוא צריך.
- הגדרנו התראות על אורך התור, גיל ההודעה הוותיקה ביותר ושיעור הרשומות בתור ההודעות שלא נמסרו.
מה הראו המדדים
שיעור הכפילויות ירד מ-1.4% ל-0.02% — עיבוד חוזר הפסיק להיות תרחיש שגרתי. זמן ההתאוששות לאחר קריסת מנוי הצטמצם מ-40 דקות ל-4: הודעות נשארות בתור עד שהשירות חוזר.
בעומס שיא התור מתרוקן תוך דקות ספורות, גיל ההודעה הוותיקה ביותר אינו חורג מסף ההתראה, והזמנות הדורשות התערבות ידנית נמדדות ביחידות ביום במקום במאות.
במה שונה Service Bus מתור מאולתר?
תור מאולתר הוא בדרך כלל טבלה במסד נתונים וסקר רקע לפי לוח זמנים. כל עוד יש צרכן אחד והזרימה קטנה, הסכימה מחזיקה, אבל עם מטפל שני מופיעים מרוצים על רשומה, עיבוד כפול ורשומות "תקועות" שאיש אינו מחזיר לעבודה.
אפיק מנוהל, לדוגמה Azure Service Bus, סוגר את המסירה בעצמו: אישור עיבוד, חזרה אוטומטית בעת כשל, תור נפרד להודעות שלא טופלו, סדר והגנה מפני כפילויות. עליכם נשארת האידמפוטנטיות של המטפל עצמו — אף ברוקר לא יחליף אותה.
עומס התפעול מתחלק אחרת: תור מאולתר אתם מתחזקים במלואו — ניקוי הצטברויות, מיגרציות סכימה, גיבוי, תורנות. באפיק זה בצד הספק, ועומק התור, מספר החזרות והודעות מתות נראים במדדים, והגישה לנושאים מוקצית לפי תפקידים דרך ספרייה.
גם למגבלות יש מקום: שירות משותף קובע תקרות לגודל ההודעה, מספר המנויים ואזור הפריסה. הבחירה מרוכזת בטבלה.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| תור במסד הנתונים שלך | צרכן אחד, זרימה נמוכה, הכל בסביבה אחת | אין ערובות מסירה, חזרה ידנית, מרוצים על רשומה |
| ברוקר על השרתים שלך | דרישות למיקום נתונים, כללים לא סטנדרטיים | עמידות לתקלות ותורנות כולם עליכם |
| אפיק מנוהל | מספר צרכנים, נדרשות חזרות, סדר, טיפול בהודעות שלא נמסרו | מגבלות שירות משותף, תלות בפלטפורמה |
ספקות טכניים לפני תחילת העבודה
לפני תחילת העבודה על תורים ב-Azure Service Bus, לקוחות והמהנדסים שלהם מעלים פחות או יותר את אותה קבוצת שאלות: כיצד לעבור ללא עצירת שירותים, מה לעשות עם צרכנים ומפיקים שכבר נכתבו, מי יקבל גישה ומה יראה התורן ברגע הכשל. להלן תשובות קצרות, כדי שיישארו פחות נעלמות עד להערכה.
האם ניתן להעביר תורים ללא עצירת שירותים?
כן, מיגרציית תורים מתבצעת במסלול מקביל: מקימים מרחב שמות חדש לצד הקיים, מפעילים העברת הודעות מהישן לחדש, מעבירים צרכנים אחד אחד ומחזיקים את המסלול הקודם לנסיגה לפרק זמן מוסכם.
האפליקציה אינה נעצרת — הודעות שלא עובדו ממתינות להעברה בתור, ומסירה חוזרת נחסמת על ידי הגדרת מספר הניסיונות וחלון הנעילה.
האם יהיה צורך לכתוב מחדש קוד עבור ספרייה אחרת?
תאימות נקבעת לפי פרוטוקול החלפת ההודעות, ולא לפי גרסת הספרייה באפליקציה. בפועל משתנים מחרוזת החיבור, הגדרות הניסיונות החוזרים וסימן סיום ההפעלה — לוגיקת העיבוד נשארת כשהייתה. תכנון כתיבה מחדש מלאה קיים רק במקומות שבהם משתמשים כעת בעטיפות מאולתרות מעל תורים.
כיצד ניתנות הרשאות והיכן מאוחסנים המפתחות?
הרשאות ניתנות דרך מודל תפקידים עם הפרדת הרשאות לשליחה, קריאה וניהול, בנפרד עבור מרחב השמות ועבור תור מסוים. ההרשאות ניתנות לחשבונות שירות, ולא לאנשים: עובד עוזב — הגישה לתורים אינה משתנה. סודות מאוחסנים במאגר סודות ומוזרקים לסביבת ההרצה, ואין אותם במאגר הקוד ובקונפיגורציות.
מה רואה התורן ומתי מופעלת ההתראה?
הניטור מבוסס על ארבעה אותות: אורך התור, גיל ההודעה הוותיקה ביותר, שיעור ההודעות שלא עובדו בתור וגידול במספר המסירות החוזרות. עבור כל אחד מגדירים סף וזמן החזקה, כדי שלא יעירו את התורן בגלל פרץ קצר. להתראות מצורפות הוראות טיפול: היכן להסתכל, מה להפעיל מחדש, ובאיזה מקרה להתקשר למפתח.
נדון במשימה עבור התורים שלכם
הערכה עבור תורים כמעט ולעולם אינה מסתכמת ב"תקימו לנו Azure Service Bus": היקף העבודה נקבע לפי פרופיל העומס ודרישות המסירה. ככל שהנתונים הראשוניים מדויקים יותר, כך יש פחות הנחות בתוכנית — ופחות תיקונים לאחר ההרצות הראשונות תחת תעבורה אמיתית.
להלן מה שכדאי לצרף לתיאור המשימה. חלק מהנתונים כבר קיימים בניטור, וחלקם די להעריך לפי סדר גודל:
- סכימת זרימות: מי מפרסם הודעות, מי קורא אותן, כמה תורים ומנויים דרושים, מה עובר לעיבוד מושהה;
- פרופיל עומס: עוצמה ממוצעת ושיאית, מקצב יומי ושבועי, השהיית מסירה מותרת בשעות שיא;
- דרישות מסירה: האם חזרות מותרות, האם נדרש סדר עיבוד קפדני, אחרי כמה ניסיונות כושלים ההודעה עוברת לתור הודעות שלא טופלו;
- מודל גישה: אילו שירותים וצוותים פונים לאילו ישויות, האם דרושות הרשאות נפרדות לשליחה ולקריאה;
- מצב תגובה: לאן מגיעות ההתראות, מי צופה בהן בשעות שאינן עבודה, אילו ספים נחשבים לחירום;
- מצב קיים ומגבלות: האם יש כבר תורים פרוסים, כמה הודעות הצטברו, האם מתוכננת העברה מברוקר אחר, כיצד מופצות קונפיגורציות.
לאחר מכן אנו מצליבים את הנתונים עם מגבלות הפלטפורמה וחוזרים עם הערכת עבודה, הרכב שלבים ולוחות זמנים. אם אין נתונים מסוימים — כתבו זאת: נסביר כיצד להשיג אותם או במה להחליף, כדי לא לעכב את ההתחלה.