למה העברנו את תשתית הזמן האמת של Cliqer אל מחוץ ל-Cloudflare (ולמה אנחנו עדיין מעריצים)

ב-24 בספטמבר 2026 בשעה 18:42 UTC העברנו כל חיבור חי של Cliqer מ-Cloudflare Workers ו-Durable Objects אל שרתים ייעודיים משלנו. ניסינו את ה-edge, והפעם הוא אכזב אותנו. אם אתם משתמשים ב-Cliqer, שום דבר באופן העבודה שלכם לא משתנה. מה שמשתנה הוא מה שקורה מתחת לפני השטח: החדרים שלכם כבר לא מופעלים מחדש מסיבות שאף אחד לא יודע להסביר.

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

מה ניסינו לבנות

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

Durable Objects נראו כמו ההתאמה המושלמת. כל חדר מקבל אובייקט חד-הליכי שמחזיק את ה-sockets שלו ואת האחסון שלו, ורץ על הרשת של Cloudflare. אין שרתים לנהל, אין סקיילינג לתכנן. עד סוף מאי כל החדרים רצו עליהם, והגשר של Cliqer v1 מהדור הקודם הצטרף ביוני.

מה השתבש

הפעלות מחדש שלא הצלחנו להסביר

Durable Object יכול להיות מופעל מחדש על ידי הפלטפורמה בכל רגע, וכשהוא מופעל מחדש, כל WebSocket שהוא מחזיק נסגר. בחלון לוגים אחד של 24 שעות בדקנו זאת במפורש: אף socket לא שרד הפעלה מחדש. אף לא אחד.

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

• 21 הפעלות מחדש ב-5 ימים לאובייקט בליסבון שהחזיק את כל החדרים, 4 מהן בשעה אחת. בלי חריגת זיכרון, בלי מגבלת CPU, קומץ שגיאות פנימיות של הפלטפורמה, ובלי פריסה מצדנו.
• העברנו אותו. Durable Objects נשארים במקום שבו הם נוצרו לראשונה, כך שהעברה פירושה ליצור אותו מחדש ולקוות שינחת במקום טוב יותר. הניסיון הראשון נחת במדריד, הבא באמסטרדם.
• באמסטרדם ההפעלות מחדש המשיכו להגיע, כל 2 עד 16 שעות, בממוצע בערך כל 8.7 שעות.
• בספטמבר, האובייקט ששירת את חדרי הדור הקודם עדיין הופעל מחדש 2 עד 5 פעמים ביום, בלי שום טריגר. ב-8 בספטמבר בשעה 18:53 כל חיבור של הדור הקודם נסגר באותה מילישנייה. בלי פריסה, בלי תקלה בדף הסטטוס.

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

אחסון שחרג מזמן ההמתנה ואיפס את החדר

בין 7 ל-10 בספטמבר ראינו את הודעת השגיאה "Durable Object storage operation exceeded timeout which caused object to be reset" 8 פעמים ב-4 אובייקטים. ניסיון חיבור מחדש אחד המתין 44.5 שניות לפני שנכשל. קריאה מהאחסון שאמורה להימשך מילישניות הפילה איתה את כל החדר.

כל פריסה הפעילה מחדש כל חדר

זה מתועד, וזה הוגן: פרסום גרסה חדשה של Worker מפעיל מחדש את ה-Durable Objects שלו, והפעלה מחדש שלהם סוגרת את החיבורים שלהם. בין 19 ל-21 באוגוסט, 44% מהחיבורים מחדש בחדרים חיים של לקוחות הגיעו בגלים מסונכרנים, ושלוש מהגרסאות שלנו ביום אחד ניתקו כל חדר, אחת מהן באמצע שידור.

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

התנהגות עדינה שעקצה אותנו בשידורים חיים

• שקט של 16 דקות. ב-4 באוגוסט, 43 sockets נשארו מחוברים בזמן שאפס הודעות נמסרו לחדר כלשהו. ה-edge המשיך לענות ל-heartbeats בשם החדר, כך שאף לקוח לא ידע שמשהו לא בסדר ואף אחד לא התחבר מחדש. זה נבע מתכונה של הפלטפורמה שאימצנו זה עתה, בשילוב עם הניהול הפנימי שלנו. ביטלנו אותה באותו שבוע.
• מנחי רפאים. אין ערובה שאירועי סגירה יגיעו לאובייקט רדום, כך שמנחה שכבר עזב יכול היה להיראות מחובר במשך שעות.
• URL שמור במטמון שנתקע לארבע שעות. באוגוסט, שכבת מטמון מול ה-Worker שלנו נתקעה על ה-URL היחיד שאפליקציית הדסקטופ בודקת בהפעלה. האפליקציה לא הצליחה לעלות. אותו URL עם פרמטר זבל ענה תוך שנייה.

מה בנינו כדי להתמודד

במהלך ארבעת החודשים האלה בנינו כ-18 מנגנונים נפרדים כדי להסתיר מכם את הפלטפורמה: heartbeats מהירים יותר, סריקות לאיתור מנחי רפאים, רישומים שנבנים מחדש מהאחסון בכל התעוררות, זהויות ששורדות הפעלה מחדש כדי שהאפליקציות שלכם יוכלו להמשיך, Worker נפרד ל-sockets, מסווג פריסות שמכסה 161 קבצים, הגרלות מיקום חוזרות, watchdog לממסר, חלוקה ל-shards לפי חדר ופנקס מושבים חוצה shards שנלווה אליה.

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

להיות הוגנים

לא כל חיבור שנפל בחודשים האלה היה באשמת Cloudflare. בדקנו:

• 86% מהחיבורים מחדש הבודדים היו מכשירים יחידים שנותקו על ידי הרשת שלהם עצמם: פרוקסי ארגוניים, Wi-Fi באולמות, חומות אש שלא אוהבות חיבורים ארוכים. בגלל זה השקנו תמיכה ברשתות ארגוניות באפליקציית הדסקטופ באוגוסט.
• חלק מהגלים היו הפריסות שלנו, וכמה נגרמו מכלי הדיבאג שלנו.
• מעולם לא פתחנו קריאת תמיכה בנוגע להפעלות מחדש. זה עלינו.

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

מה מריץ את החדרים שלכם עכשיו

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

מה נעלם:

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

מה שחשוב לנו לומר בכנות:

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

וגם מהר יותר

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

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

השינוי הגדול ביותר הוא זה שמרגישים ראשון. חיבור זמן אמת שעמד במצב סרק בפלטפורמה הישנה לקח כ-1.2 שניות להיפתח בזמן שהתעורר. בשרת שלנו הוא נפתח תוך כ-0.14 שניות, בכל פעם. מנטר הזמינות העצמאי שלנו, שבודק את cliqer.io כל דקה מצפון אמריקה, מספר את אותו סיפור: כ-750 ms לבדיקה לפני המעבר, כ-380 ms אחריו.

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

מה Cloudflare עדיין עושה בשבילנו

הרבה, ובשמחה:

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

אם משהו נופל, ספרו לנו

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