פיתוח צ'אט חי לסטרימים: ארכיטקטורה ומימוש

מדוע צ'אט חי נשבר בעומסי שיא

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

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

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

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

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

השפעות מדידות: השהיה, מסירה, זמן השבתה

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

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

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

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

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

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

אפשרויות מימוש של צ'אט חי: השוואת מצבים

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

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

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

שלבי הטמעה: מניתוח עומס ועד מסירה

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

1. ניתוח עומס. מחשבים את המקביליות בשיא: כמה צופים מחזיקים את הצ'אט פתוח בו-זמנית, כמה הודעות בשנייה מגיעות בשיא השידור, איזה חלק מהקהל כותב ולא רק קורא. לפי המספרים האלה נבחרים סוג הפתרון ומרווח היכולת.
2. סכמת אינטגרציה. קובעים היכן נשמר מצב השיחה וכיצד הצ'אט קשור לנגן, להזדהות, למודרציה ולהתראות. בנפרד מתעדים את ההתנהגות בעת דגרדציה — מה רואה הצופה אם חלק מהשירותים אינם זמינים.
3. מימוש ליבת המסירה. בונים ערוץ מסירה עם שמירה על סדר, שליחה חוזרת בעת ניתוק החיבור ושחזור ההיסטוריה לאחר התחברות מחדש — השיחה לא מתפרקת לרסיסים.
4. בדיקה תחת עומס. מריצים תרחישים דרך k6 בפרופיל שנלקח משידורים אמיתיים: השהיית מסירה, שיעור ההודעות שאבדו, זמן השחזור לאחר ניתוק, עבודת המודרציה בזמן התפרצות.
5. נוהל. מתארים מגבלות על משתמש וקצב הודעות, כללי חסימה, סכמות דגרדציה וסדר הפעולות של הכונן באירוע.
6. מסירה. מוסרים קוד מקור, תיעוד, הרשאות ומאמנים את הצוות שלכם; מלווים את המהדורות הראשונות עד שהתפעול הופך לשגרתי.

מה אתם מקבלים לידיים: סכמות, מדיניות, נהלים

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

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

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

מקרה בוחן: גידול פי חמישה במספר הצופים בו-זמנית

לפני העבודה מחדש

בשידור Fanzone הצ'אט החי נתקל בתקרה: בשיא הצופים בו-זמנית התגובות הגיעו בהשהיה של כמה שניות ונותקו מהרגע בשידור. כ-3% מההודעות לא הגיעו לקהל, ואחרי תקלת צומת הצ'אט הועלה ידנית — עשרות דקות בלי מודרציה ובלי היסטוריה. תלונות נותחו בדוח נפרד כבר לאחר השידור: לא היה במה להגיב להפרה בזמן אמת.

מה שינו

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

מדדים לאחר

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

מה לעשות אם הפתרון כבר פרוס ועובד

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

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

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

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

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

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

ספקות טכניים: אבטחה, מודרציה, קנה מידה

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

מי וכיצד מקבל גישה להיסטוריית ההודעות?

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

מה יקרה בגידול פי כמה בעומס?

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

האם אפשר לבטל החלטת מודרטור שגויה?

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

נדון במשימה: מה לשלוח להערכה ותוכנית

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

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

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