Yandex Message Queue: היכן נשבר עיבוד אסינכרוני
תחת עומס, עיבוד אסינכרוני נשבר לא בתור, אלא לפניו. בזמן ששירות עיבוד ההזמנות קורא לשירותי תשלומים, מחסן ושליחת אימיילים בקריאות סינכרוניות, זמן התגובה מורכב מכל המשתתפים — האיטי מביניהם קובע את הזמן הכולל. בשעות שיא זרימת הבקשות גדלה פי כמה, הקריאות מתחילות ליפול בזמן המתנה, וההזמנה נעלמת באמצע השרשרת.
אחר כך מתחיל "מרדף" ידני: מפעיל בודק יומני פעולות, מחפש הזמנות בלי אישור ומזין אותן מחדש. ככל שהתעבורה גבוהה יותר, כך גדלים הפערים בין המערכות — חלק מהמשימות אבודות, חלקן עובדו פעמיים. כל איטרציה כזו היא שעות של זמן הנדסי ואמון לקוח שנפגע.
תור הודעות כמו Yandex Message Queue מנתק את הקשר הזה: השולח מפרסם משימה ומיד מחזיר תשובה ללקוח, והמקבלים מטפלים בה בקצב שלהם. מסירה אמינה של הודעות נשענת על אישורים — אם המעבד קרס, ההודעה שלא עובדה חוזרת לתור ולא נעלמת.
בנוסף אנחנו מגדירים ניסיונות חוזרים, עיבוד מושהה של הודעות כשל והגנה מפני כפילויות, כדי שניסיון חוזר לא ייצור הזמנה שנייה.
זמני המתנה של תעבורת שיא מפסיקים להיות אובדן הזמנות — הם הופכים לעיכוב של שניות. להלן נפרט כיצד סוגרים זאת בפועל.
מה נותנת הפרדת שירותים ואיך למדוד אותה
כאשר המעבד נקרא באופן סינכרוני, זמן התגובה של השירות שווה לזמן הצעד האיטי ביותר, והקריסה שלו הופכת לקריסה של השירות כולו. תור ב-Yandex Message Queue מציב ביניהם חוצץ, ומכאן כל אפקט של הפרדה נמדד במספרים.
חציצת שיאים
התור מקבל הודעות מהר יותר מכפי שהמעבד מסוגל לטפל בהן, ולכן פרץ גבוה פי כמה מהתעבורה הרגילה נבלם על ידי הצטברות ולא על ידי סירוב. שיעור המשימות שנדחו בגלל עומס יורד לאפס, ושירות הקלט שומר על זמן התגובה הקודם.
בידוד כשל של המעבד
שגיאה בצרכן כבר לא מפילה את הקליטה: ההודעות נשארות בתור, והשירות בכניסה ממשיך להגיב. זמן ההתאוששות מצטמצם להפעלה מחדש של המעבד — משימות שלא נמסרו אינן הולכות לאיבוד ולא דורשות שחזור ידני.
ניסיונות מסירה חוזרים
מספר הניסיונות וההשהיה ביניהם מוגדרים במפורש; לאחר מיצוי הניסיונות ההודעה עוברת לתור הודעות שלא טופלו. כשל בעיבוד של סוג הודעה אחד לא גורם להיעלמותן: שיעור המשימות שאבדו נראה במטריקות ונשאר בשליטה.
הרחבה בלתי תלויה של מעבדים
מספר הצרכנים משתנה בנפרד משירות הקלט: כאשר אורך התור גדל, המעבדים מתווספים, וכאשר הוא מתרוקן הם מוסרים. העיבוד מואץ ביחס ישר לעומס, ובמקביל שירות הקלט לא נבנה מחדש ולא משוחרר מחדש.
תורים סטנדרטיים ומסודרים: מה לבחור
מצב המסירה ב-Yandex Message Queue נבחר לא לפי הרגל, אלא לפי תרשים הזרימות. אם האירועים בלתי תלויים והצרכנים מטפלים בהם בכל סדר, אין צורך לכפות סדר: מעבדים מקבילים לוקחים כמה הודעות שהם מספיקים, והתפוקה גדלה עם מספרם — מספיק להוסיף צרכנים לקבוצה.
כאשר הסדר הוא חלק מהלוגיקה (מעברי סטטוס, חיובים על אותו אובייקט), יש צורך בתור מסודר. הוא שומר על הרצף בתוך קבוצת הודעות עם מפתח משותף, אך משלמים על כך בתפוקה: בתוך הקבוצה ההודעות נעות בקפדנות זו אחר זו, ומספר הקבוצות ומהירות העיבוד בכל אחת מוגבלים.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| תור סטנדרטי | אירועים בלתי תלויים: תפוצות, יומנים, משימות רקע, סדר העיבוד אינו חשוב | הסדר אינו מובטח, ייתכנו מסירות חוזרות — המעבד צריך להיות אידמפוטנטי |
| תור מסודר עם מפתח קבוצה | הסדר חשוב בתוך אובייקט: סטטוסים של הזמנה, פעולות על חשבון אחד | סדר רק בתוך הקבוצה, מגבלות על מספר הקבוצות ומהירות בכל אחת |
| תור מסודר עם זרם אחד | רצף קפדני בכל הזרם בנפח קטן | תפוקה נמוכה, המעבדים אינם מתרחבים אופקית |
הבחירה מתחילה בחישוב: כמה הודעות בשנייה, כמה מפתחות בלתי תלויים, מה יקרה בעיבוד חוזר. אם יש הרבה מפתחות והם לא חופפים, מצב מסודר נותן כמעט אותה תפוקה כמו סטנדרטי. אם המפתח אחד או שהחזרות לא מזיקות — לוקחים תור סטנדרטי ומוסיפים מעבדים.
שלבי ההגדרה: מתרשים הזרימות ועד קבלה
העבודה מתבצעת בשלבים קבועים, וכל אחד מסתיים בתוצר שאפשר לבדוק לפני המעבר לשלב הבא — תצורה, תרשים או פרוטוקול בדיקה. כשל בכל שלב נראה לפני שהוא נכנס למסלול הייצור.
- ביקורת חילופי נתונים. אוספים מפיקים וצרכנים של הודעות, דרכי ההעברה הנוכחיות, נפחים ופרופילי שיא. בנפרד מתעדים מקומות שבהם הודעות הולכות לאיבוד או מעובדות פעמיים.
- תרשים זרימות הודעות. מתכננים מסלולים: איזה אירוע הולך לאיזה תור, מה קורה בכשל של המעבד, היכן סדר המסירה חשוב. התרשים מאושר לפני תחילת ההגדרה.
- הגדרת תורים והרשאות. יוצרים תורי Yandex Message Queue לכל זרימה, מגדירים זמן נראות של הודעה, זמן שמירה ותור הודעות שלא נמסרו. גישות ניתנות לחשבונות שירות לפי הסט המינימלי הנדרש.
- בדיקה תחת עומס. מריצים פרופיל קרוב לשיא: בודקים גידול בעומק התור, שיעור עיבודים חוזרים והתנהגות המערכת כשאחד הצרכנים נעצר.
- נראות והתראות. מגדירים מטריקות של עומק תור, השהיית מסירה ומספר שגיאות, קובעים ספי התראה כדי לזהות ירידה בביצועים לפני תלונות משתמשים.
- מסירה לתפעול. מוסרים תצורה, נוהל תגובה לאירועים והוראות להוספת זרימות חדשות; במידת הצורך תורנים על המהדורות הראשונות.
תצורות, תרשימים ונוהלים: מה מוסרים לידיים
מוסרים לא צילומי מסך של הגדרות, אלא סט תוצרים עבור Yandex Message Queue: לפיו התור מורם בסביבה חדשה, והאירוע מנותח בלי טלפון למחבר. הכול נשמר במאגר לצד הקוד — שינויים עוברים סקירה ונכנסים לסביבה באותה דרך כמו שחרור השירות.
- תצורת תורים — תיאורי תורים ורישומים: סוג התור, תקופת שמירת הודעות, חלון אי-נראות, גודל אצווה, זמני המתנה. הערכים נגזרים מפרופיל העומס, ולא נקבעים בעין.
- תרשים זרימות נתונים — מפיק, צרכן, מסלול התוצאה, נקודות עיבוד חוזר. מסומנים מקומות שבהם הזרימה עשויה להיות משוכפלת, וכיצד הצרכן מתמודד עם זה.
- מדיניות גישה ותפקידים — אילו חשבונות שירות כותבים וקוראים, מה בדיוק מותר להם, היכן מפתחות עם תוקף מוגבל. ההרשאות מופרדות למינימום.
- טיפול בהודעות כשל — כללי ניסיונות חוזרים, סף המעבר לתור הודעות כשל, סדר הניתוח וההחזרה לזרימה לאחר תיקון.
- מטריקות והתראות — אותות על הצטברות תור, גידול בשיעור החזרות וכשל צרכן, עם ספים שבהם התורן מקבל התראה.
- נוהל תפעול — מה בודקת משמרת התורן, איך לערוך תצורה בלי לאבד הודעות, איך להחזיר שינוי לאחור ומה לעשות בכשל של צרכן.
ניתוח הטמעה: זרימת בקשות שיא בלי אובדן
מה היה לפני הבנייה מחדש
בקשות התקבלו על ידי שירות סינכרוני: הטופס העביר בקשה ישירות למעבד, והתשובה ללקוח הייתה תלויה בכך אם הוא הספיק לעבוד.
כשהזרימה הייתה יציבה, צוואר הבקבוק בעיבוד לא התגלה — אבל בימי מבצעים ותפוצות מספר הבקשות זינק פי כמה, המעבד לא הספיק, וחלק מהבקשות אבד עוד בכניסה: המשתמש ראה שגיאה ולא שלח שוב. בימי שיא שיעור הבקשות שאבדו הגיע ל-3–4%, וטיפלו בהן ידנית — הוציאו יומנים והשלימו את החסר.
מה נבנה מחדש
בין הקליטה לעיבוד הציבו תור מבוסס Yandex Cloud. הקולט רק מתעד את הבקשה ומאשר את הקליטה, והמעבדים לוקחים הודעות בקצב שלהם. אישור נשלח לתור רק לאחר סיום מוצלח: אם המעבד קרס, ההודעה תחזור ותעובד מחדש.
עבור בקשות שלא עוברות אחרי כמה ניסיונות, הוקם תור ניתוח נפרד, כדי שהודעה כשלה לא תחסום את האחרות. המעבדים מתרחבים לפי אורך התור, ומפתח הבקשה מגן מפני כפילויות.
מה נהיה
שיעור הבקשות שאבדו הגיע לאפס בטווח חלון המסירה החוזרת: הבקשה לא "נשרפת", גם אם השירות מופעל מחדש בדיוק בשיא. זרימת המשימות שהצטברה, שאותה נהגו לעבד במשך כמעט יום עבודה שלם, עוברת כעת בדקות.
התערבויות ידניות פחתו באופן ניכר — במקום משמרות לילה על השלמת חסרים נותרו הודעות בודדות מתור הניתוח.
מה לעשות אם החלפת נתונים בין שירותים כבר עובדת ישירות
קריאה ישירה לשירות עובדת כל עוד כשל של המקבל נראה מיד: המפיק מחזיק חיבור ומנסה שוב את הבקשה. אותה תכונה הופכת עומס יתר באזור אחד לכשל של השרשרת כולה. התור מנתק את הקשר: ההודעה נקלטת ונשמרת עד שהמקבל יהיה מוכן לעבד אותה.
אין צורך לעבור להחלפה אסינכרונית כולה בבת אחת. ב-Yandex Cloud מעבירים ראשונים אזורים שבהם אין צורך בתשובה באותה סשן: אירועים, התראות, ייצוא, חישוב מחדש של ספרים. בקשות שהממשק של המשתמש תלוי בהן נשארות ישירות.
| אזור | סכמה | בכשל של המקבל |
|---|---|---|
| אירועים, התראות, ייצוא | תור | ההודעה נשארת בתור עד להתאוששות |
| בקשות לממשק | קריאה ישירה | המפיק רואה שגיאה ומחזיר אותה למשתמש |
| חישוב מחדש באצווה, דוחות | תור | המשימה לא אבודה, לוחות הזמנים נדחים |
| פעולות עם עיבוד חד-פעמי | תור עם אישור | מסירה חוזרת נבלמת על ידי מפתח הפעולה |
שתי סכמות חיות במקביל הודות לניתוב לפי סוג הפעולה: המפיק מחליט לאן לשלוח את הקריאה, והפיצול מתואר בתצורה ולא מפוזר בקוד. עבור התור מוגדרים ניסיונות חוזרים, מסירה מושהית ותור הודעות שלא טופלו — קריאה ישירה לא נותנת זאת כלל.
נוח להתחיל משירות-מקבל אחד וקבוצת צרכנים אחת — אז רואים את עומק התור האמיתי ואת זמן העיבוד. החזרה לאחור זולה: מתג בצד המפיק מחזיר את הקריאה הישירה, והענף הישן עובד עד סוף תקופת המעבר.
מגבלות, מכסות ותקלות נפוצות בעיבוד אסינכרוני
התור אינו אינסופי: יש גבול למספר ההודעות ולנפח, ולכל הודעה יש זמן החזקה שאחריו היא נמחקת ללא תלות בשאלה אם הצרכן עיבד אותה. החזקה קצרה מדי — הודעות נעלמות באמצע המשימה, ואירועים לא מגיעים לצרכן. בזינוק עומס התור מגיע לגבול, הפרסום נדחה — נתונים הולכים לאיבוד עוד בכניסה.
הטעות השנייה — הסתמכות על מסירה חד-פעמית. Yandex Message Queue מחזיק בהבטחת "לפחות פעם אחת": בהפעלה מחדש של הצרכן או בחריגה מחלון הנראות ההודעה מגיעה שוב. בלי עיבוד אידמפוטנטי זה יוצר כפילויות פעולות — חיובים כפולים, מכתבים חוזרים, מונים שלא מסתדרים.
חלון הנראות הוא פשרה מרכזית: קצר יוצר כפילויות, ארוך — משימות תקועות שלא מעובדות מחדש במשך שעות. הגרוע ביותר הוא כשלא עוקבים אחרי התור: בקרת עומק וגיל ההודעה הוותיקה ביותר מראה שהצרכנים לא מספיקים או נופלים הרבה לפני תלונות משתמשים. ותור נפרד להודעות שלא טופלו אחרי כמה ניסיונות — אחרת הן נכנסות ללולאה או נעלמות בלי עקבות.
איך להבדיל בין הצפה בגלל זמן החזקה שגוי לבין מחסור רגיל בצרכנים?
השוו את זמן ההחזקה למשך העיבוד בפועל לפי מטריקות, והסתכלו על גיל ההודעה הוותיקה ביותר: אם הוא קטן והתור גדל — הצרכנים לא מספיקים, יש צורך במעבדים חדשים. אם הודעות נעלמות לפני שהספיקו לעבד אותן — זמן ההחזקה קצר מדי. לוקחים אותו עם מרווח למשך המשימה בשיא, ואת ה"זנבות" מעבירים לתור נפרד של הודעות שלא טופלו.
נדון במשימה: מאיפה מתחילים ומה צריך מכם
להגדרת המשימה אין צורך במסמך רב-כרכים — די בתיאור זרימות, דוגמאות הודעות ודרישות לאמינות. מהן כבר רואים איזה מצב תור מתאים, כמה צרכנים להחזיק והיכן נדרשים ניסיונות חוזרים.
- תיאור זרימות נתונים: מי מפרסם הודעות, מי קורא, מה נחשב לעיבוד מוצלח ולאן הולכת התוצאה.
- דוגמאות הודעות: מבנה הגוף, גודל, תדירות ושעות שיא — לפיהם מחשבים את תפוקת התור.
- דרישות לסדר: האם הרצף בתוך קבוצה חשוב או שהעיבוד בלתי תלוי.
- דרישות לאמינות: השהיית מסירה מותרת, מספר סביר של ניסיונות חוזרים וכללי ניתוח הודעות כשל.