פיתוח ספר הפקודות: היכן נשברת ליבת הבורסה
ספר הפקודות אינו טבלה במסך התצוגה, אלא ספר הזמנות שהליבה מרכיבה מחדש בכל אירוע: הצבה, ביטול, ביצוע חלקי. כל עוד הזרימה אחידה, הפער אינו מורגש, ומרווח העומס נראה עודף.
הכול נשבר בדקות הראשונות של השיא: תור הפקודות הנכנסות גדל מהר יותר מקצב הפירוק של הליבה, ומכאן והלאה נכנס לתוקף אפקט מצטבר.
השהיית התגובה של הליבה גדלה בכל שנייה של עומס יתר, חלק מהפקודות נושרות בגלל פסק זמן בצד הלקוח, ועושי שוק מפסיקים לראות עומק מעודכן ומסירים את הציטוטים. מבחינה פורמלית עדיין יש לבורסה תפוקה, אך היא מתבזבזת על חישוב מחדש של מצבים מיושנים ולא על עסקאות חדשות.
הגרוע מכל הוא הפער בין מצב ספר ההזמנות לבין מה שמציג מסך התצוגה: המשתמש רואה מחיר שכבר אינו קיים, העסקה אינה עוברת, ואת ההתאמה יש לבצע ידנית לפי יומן האירועים. בפלטפורמות מתקנים זאת בעצירת מסחר במכשיר — וזו כבר אינה אובדן הנדסי אלא אובדן מוניטין.
יציבות הליבה נשענת על שלושה דברים: מה קורה במסלול החם של עיבוד הפקודה, כיצד בנויים התור ולחץ חוזר בעומס יתר, ובאיזו מהירות מצב ספר ההזמנות משוחזר מצילום ומיומן. בהמשך נפרט כיצד סוגרים זאת בפיתוח ספר הפקודות — ממודל הנתונים ועד לבדיקה בפרופיל עומס שיא.
מה נותנת הליבה המחודשת: אפקטים מדידים
ליבת ההתאמה המחודשת נמדדת לא במילים כלליות, אלא בגדלים שנמדדים בעמדת העומס לפני ואחרי. משווים תפוקה בפקודות ליחידת זמן, התנהגות התור תחת שיא וזמן התאוששות לאחר כשל צומת — הלקוח רואה את האפקטים בדוח, ולא בהצהרות.
עיבוד פרצי פקודות בשיא
התפוקה עלתה פי כמה: במקום שבו הליבה הקודמת נתקלה בתקרה וזרקה פקודות, הסכימה החדשה מחזיקה שיא גבוה פי כמה. הקבלה והאימות מתבצעים במקביל, בעוד ההתאמה נותרת סדרתית בהחלט — ספר ההזמנות לא "מתפרק" תחת עומס. הבסיס לגישה המוכרת מארכיטקטורת LMAX הותאם לדרישות הפלטפורמה.
התור חדל להיות צוואר בקבוק: המסלול החם של ההתאמה הופרד מהתיעוד ומהפצת העדכונים למנויים. פרץ שיא אינו מעלה עוד את ההשהיה לשאר המשתתפים, ומחלקת הכשל "הפקודה התקבלה אך לא נכנסה לספר" בוטלה ככזו.
חיזוי זמן התגובה ושקיפות מצב ספר ההזמנות
זמן התגובה תחת שיא חדל להיות הגרלה — הפער בין הערך האופייני לערך הגרוע התכווץ לכמה סדרי גודל. מצב ספר ההזמנות בכל רגע נתון משוחזר לפי יומן האירועים, ולכן השוואת הצילום להיסטוריה אורכת דקות ולא שעות של פירוק ידני.
יציבות ליבת ההתאמה נותנת אפקט שאינו מצטמצם לספרה אחת: ההשבתה של הפלטפורמה לאחר כשל צומת מתקצרת לעשרות שניות, ולרוב המשתתפים אין זמן להבחין בנתק. נוהל השחזור מתורגל ונבדק בתרגילים, ולא נכתב ברגע התקלה.
אפשרויות לבניית ליבת התאמת הפקודות: השוואה
הבחירה בליבת ההתאמה קובעת את גבולות ההרחבה ואת סט סוגי המסחר הזמינים. אם המנוע בשלב ההתחלה יודע רק פקודות לימיט ומרקט, אז מכרז פתיחה, פקודות סטופ או לידרברג לא ניתן "להשלים" בהמשך בלי לכתוב מחדש. לכן את האפשרות בוחרים לא לפי מהירות המהדורה הראשונה, אלא לפי מצבי המסחר שהפלטפורמה מתכננת לקיים.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| ליבה עצמאית של הפלטפורמה | כללי מסחר לא סטנדרטיים, סוגי פקודות משלכם, דרישות השהיה קפדניות | היקף העבודה גדול יותר, נדרש צוות לתחזוקה שוטפת |
| התאמת פתרון מוכן | סט כללים סטנדרטי, יציאה מהירה, רשימת מכשירים מוגבלת | מצבים חדשים מוגבלים ליכולות הספק, חלק מהלוגיקה בשירותים חיצוניים |
| מודול בתוך פלטפורמה קיימת | הפלטפורמה כבר פועלת, מתווסף סוג מכשירים חדש | עוברות בירושה מגבלות הליבה של הפלטפורמה וסכמת פיזור העומס שלה |
ליבה עצמאית של הפלטפורמה
סדר ביצוע דטרמיניסטי, יומן פעולות וצילומי מצב תקופתיים מאפשרים התאוששות לאחר כשל בחישוב מחדש ולא בהשוואה לייצואים. את ההרחבה פותרים בפיצול לפי מכשירים: זוגות פעילים עוברים לצמתים נפרדים, ואת הסנכרון של המצב ביניהם אתם מתכננים.
התאמת מנוע מוכן לכללי המסחר שלכם
מנוע מוכן מכסה את הסט הסטנדרטי: פקודות לימיט, מרקט, סטופ ואייסברג, וכמה מצבי סליקה. את הלא-סטנדרטי — מכרזים, עדיפות בתוך רמת מחיר, כללי ביטול משלכם — מממשים בעטיפה סביב המנוע, וכאן חשוב לבדוק מראש שהיא אינה מתנגשת עם סדר הביצוע הפנימי.
שלבי העבודה: מביקורת עומס ועד העלאה לפרודקשן
את העבודה מבצעים באיטרציות: קודם מודדים, אחר כך משנים, ואחר כך בודקים על העתק של מתאר הייצור. סדר כזה מאפשר העלאה לפרודקשן בלי לעצור את המסחר — הבורסה ממשיכה לקבל פקודות בזמן שאנחנו מכינים את המעבר ושומרים על תוכנית חזרה לסכימה הקודמת.
- ביקורת עומס. מסירים פרופיל: כמה פקודות בשנייה מגיעות בשיא, מה שיעור הביטולים, כיצד מפוזרים המכשירים לפי פעילות ובאילו פעולות גדלה השהיית התגובה. בלי המספרים האלה כל תיקון בליבת הביצוע הופך לניחוש.
- סכמת זרימות הפקודות. מפרקים את המסלול מהקבלה ועד האישור: השער, בדיקת ההרשאות והיתרות, ההצבה בתור, ההתאמה, פרסום שינויי ספר הפקודות, נטילת הצילום. מתעדים היכן הזרימה נחסמת ומה קורה בעת ניתוק החיבור.
- כללי ביצוע הפקודות. משווים סוגי פקודות, עדיפות מחיר וזמן, ביצוע חלקי, התנהגות בעת מחסור בנזילות, מכרזי פתיחה וסגירה. כל כלל נבדק על תרחישי נגד, ולא רק על "המסלול המאושר".
- הגדרת תורים ועדיפויות. מפרידים בין מה שאסור לאבד (עסקאות, ביטולים) לבין מה שאפשר לאחד לחבילות (עדכוני ספר הפקודות). מגדירים buffering כדי ששיא לא יהפוך לכשל.
- בדיקות עומס. משחזרים תרחישי שיא על העתק: סופרים את שיעור הכשלים, זמן התגובה בכל מקטע, ההתנהגות בעת פיגור של הצרכן. מריצים סדרה עם מרווח עומס.
- מעבר ותצפית. מעבירים בשלבים: חלק מהזרימה עוברת לפי הסכימה החדשה, והמדדים מושווים לישנים. בהמשך מסירים את המגבלות ומקיימים תצפית תורנית עם חזרה לאחור מוכנה.
מה בודקים בכל שלב
- ספירת הנתונים: פרופיל העומס תואם למדדים בפועל במתאר הייצור.
- שלמות סכמת הזרימות: אף פקודה אינה הולכת לאיבוד בעת תקלה בכל מקטע.
- נכונות כללי הביצוע: מחירים, נפחים ועדיפויות תואמים לציפיות.
- יציבות התורים: השיא אינו מוביל לכשל, והצרכנים מדביקים בלי לאבד נתונים.
- מוכנות לחזרה לאחור: החזרה לסכימה הקודמת אורכת דקות ואינה דורשת עצירת מסחר.
ארטיפקטים ותיעוד: מה נשאר אצל הלקוח
מה נשאר אצל הלקוח לאחר המסירה — לא רק שירות עובד, אלא גם סט מסמכים שלפיהם צוות התפעול יוכל להוביל אותו בלעדינו. ספר הפקודות נמצא בתנועה מתמדת: זרימת פקודות, התאמה, פרסום עומקים — וכל התערבות בלי הבנה של הקשרים האלה נגמרת בחוסר סנכרון או בתור תקוע. לכן אנחנו מעבירים:
- סכמת זרימות הפקודות — המסלול מהקבלה ועד הביצוע והפרסום: היכן נמצא ה-buffering, היכן נקודת תיעוד המצב, כיצד המערכת מתנהגת בעת כשל של צומת בודד.
- קונפיגורציית הליבה ופרמטרי הביצוע — כל הערכים מוציאים לקבצים, ולצידם תיאור ההשפעה של כל פרמטר על התפוקה וזמן התגובה.
- מדיניות גישה ותפקידים — מי משנה את פרמטרי ההתאמה, מי רואה את המדדים, מי מוציא עדכונים; ההרשאות מופרדות כך שעבודה שגרתית אינה דורשת הרשאות מורחבות.
- תיעוד הליבה — מבנה התורים, כללי הביצוע והביטול, ההתנהגות בעת סגירה חלקית של נפח.
- יומני בדיקות עומס — פרופילי עומס ותוצאות ההרצות, כדי לחזור על הבדיקה לאחר כל שינוי ולהשוות למצב ההתחלתי.
- נוהל תחזוקה — עבודות מתוכננות, שינוי סכמת הנתונים, עדכון בלי לעצור את המסחר.
נהלים והוראות למשמרת התורנית
סט נפרד — למי שנכנס למשמרת, כולל משמרת לילה. בו פעולות שלב-אחר-שלב למצבים אופייניים: גידול בתור, פער בספר הפקודות בין צמתים, כשל בערוץ האספקה, אתחול מתוכנן. לכל מקרה מצוין הסימן שלפיו התורן מבחין בין התנהגות תקינה להידרדרות, סדר הפעולות והרגע שבו יש להעביר את המשימה למהנדסים. כך המשמרת אינה פועלת באקראי, וההחלטה מתקבלת לפי מסמך ולא לפי הזיכרון של אדם מסוים.
מקרה בוחן: תפוקת הפלטפורמה לפני ואחרי
מה קדם לשינוי
מקרה הבוחן הזה של פלטפורמת מסחר החל בליבה מונוליטית: ספר הפקודות והיתרות של המשתתפים חושבו באותה טרנזקציה עם כתיבה לבסיס נתונים רלציוני, וההתאמה של הפקודות רצה בתהליכון אחד. בעומסים מתוכננים זה עבד, אך בפרצי חדשות התור של הפקודות גדל מהר יותר מקצב הפירוק של הליבה.
מדידות ב-pre-prod אישרו את ההשערה: מעל 1 200 פקודות בשנייה זמן התגובה בשיא התארך לשנייה וחצי, ושיעור הפקודות הנדחות הגיע ל-9%. לאחר האתחול השוו את מחזור העסקאות ידנית — השחזור ארך עשרות דקות.
המסלול החם והתיעוד הופרדו. ספר הפקודות חי בזיכרון, ההתאמה של הפקודות מתבצעת סדרתית בליבת ההתאמה, והעסקאות ושינויי היתרות נרשמות ביומן "כתיבה בלבד" ומוקרנות באופן א-סינכרוני לבסיס הנתונים.
הרפליקה מאמצת את היומן מהרשומה המאושרת האחרונה, ולכן לאחר כשל הפלטפורמה חוזרת לפעילות בלי השוואה ידנית.
תפוקה לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| תפוקה יציבה | 1 200 פקודות בשנייה | 9 000+ פקודות בשנייה |
| זמן תגובה בעומס שיא | עד 1,5 שנייה | שברירי שנייה |
| שיעור הפקודות הנדחות בשיא | כ-9% | פחות מ-0,1% |
| התאוששות לאחר כשל | עשרות דקות, ידנית | עד דקה, אוטומטית |
כיצד בודקים את יציבות ספר הפקודות תחת עומס
את יציבות ספר הפקודות בודקים בניסוי עם זרימה משוחזרת, ולא בניסיון חד-פעמי "להציף יותר פקודות".
אנחנו מקימים מתאר בדיקה לצד מתאר הייצור, מקליטים זרימה אמיתית של אירועים ומריצים אותה שוב בקצב נשלט — יומן האירועים ב-Kafka נותן את אותו רצף פקודות בדיוק, ולכן המדידה מושווית לאמת מידה ולא למצב הרוח הקודם.
התרחישים נבדלים בנקודה שבה המערכת נשברת, ולכן כל אחד מורץ בנפרד, ואחר כך במצב משולב.
רק חזרתיות מאפשרת להבחין בין הידרדרות אמיתית של הליבה לבין ירידה חד-פעמית. אנחנו מריצים את אותו פרופיל כמה פעמים ובודקים אם השהיות הזנב ואורך התור נשמרים בין ההרצות: אם לאחר הסרת הפרץ המדדים אינם חוזרים לרמה ההתחלתית, זה סחיפה ולא חריגה אקראית.
את שלמות ספר ההזמנות בודקים בהשוואה — צילום ועוד זרימת השינויים צריכים לתת את אותו מצב כמו באמת המידה, בכל כשל ובכל חיבור מחדש. בסיום נשאר סט תרחישים וערכי סף שלפיהם מהדורה מתקבלת או נדחית בלי ויכוח על השאלה אם העמסנו מספיק את העמדה.
ספקות טכניים: יציבות, כשלים, השלמות
הספקות ההנדסיים בשלב הזה הם בדרך כלל אותם ספקות: כמה מהליבה יהיה צריך לכתוב מחדש, כיצד מעבירים פקודות חיות, מה יקרה בעת כשל צומת ומה יישאר אצל צוות הלקוח לאחר המסירה. להלן תשובות לגופן של הדברים.
האם נדרש שיפוץ מלא של הליבה או שמספיק להשלים?
מסתכלים על האינווריאנטים: אם הליבה אינה מאבדת פקודות בעת אתחול ומחזיקה נכון שינויים מקבילים, משאירים אותה ומחליפים את שכבת ההתאמה ופרסום הנתונים. שיפוץ מלא מוצדק כשהלוגיקה מעורבת בייתרות ובסליקות — ואז תיקון של חלק אחד שובר את החלקים שלידו.
כיצד מעבירים פקודות פתוחות?
הספר ויומן האירועים נלקחים בנקודה מסונכרנת, כדי שאף פקודה לא תעבור פעמיים. לפני המעבר עוצרים את קבלת הפקודות החדשות, ואחר כך מזרימים את הצילום לליבה החדשה ומשווים לפי מספר ונפח הפוזיציות.
מהי ההתנהגות בעת כשל צומת?
את ההתאמה מוביל הצומת הראשי, הצומת המשני מקבל את זרימת השינויים ובאובדן הראשי ממשיך מאותה נקודה ביומן. הלקוח רואה ניתוק חיבור ולא פקודות שנעלמו: לאחר חיבור מחדש מגיע צילום מעודכן ודלתא.
כיצד הליבה מתקיימת לאחר המסירה?
אנחנו מעבירים קונפיגורציה, סכמת נתונים ותיאור האינווריאנטים יחד עם הרצת תרחישי העומס — צוות הלקוח משחזר כל מצב של הליבה ויודע אילו בדיקות חייבות לעבור לפני העלאה.
מה כלול בתמיכה לאחר המסירה?
מפרקים תקלות לפי היומן והמדדים, מבצעים תיקונים והרחבות: סוג פקודה חדש, ערוץ נוסף של נתוני שוק. המסירה אינה סוגרת את העבודה — הגישה למי שתכננו את הליבה נשארת.
נדון במשימה: מהיכן להתחיל ומה להכין
לפני השיחה כדאי לאסוף עובדות על ספר הפקודות הנוכחי — לפיהם אנחנו מחשבים את פרופיל העומס ומוצאים את צוואר הבקבוק: ליבת ההתאמה, הפצת העדכונים או שכבת אחסון ספר ההזמנות. כך הדיון במשימה מתנהל ברמת המספרים והמדדים, ולא ברמת משאלות כלליות.
מה כדאי להכין לקראת ההתחלה:
- מדדי עומס נוכחיים: ערכי שיא וממוצעים לפי מספר פקודות בשנייה, עומק ספר הפקודות, מספר החיבורים הפעילים ונפח נתוני השוק.
- סכמת המתאר: היכן יושבים צומתי ההתאמה, כיצד נשמר ספר ההזמנות, כיצד משוכפלים השינויים וכיצד מופרדות זרימות הקריאה והכתיבה.
- כללי המסחר: סוגי פקודות, מצבי מכרזים ועצירות, עדיפות לפי מחיר וזמן, לוגיקת הביטול והביצוע החלקי.
- תקלות בחודשים האחרונים: פערים בין ספר הפקודות למחזור העסקאות, השהיות בהפצה, השבתות וכיצד טופלו.
- פרופיל השיאים הצפוי: פי כמה מתוכנן הגידול בפקודות ובחיבורים, ואילו אירועים יוצרים פרץ.
- מגבלות פריסה והרשאות: היכן מותר להריץ, מה הדרישות לבידוד צמתים ולתיעוד פעולות.
לאחר השיחה נחזור עם הערכה של פרופיל העומס, תוכנית עבודה לליבה וקריטריוני קבלה: אילו השהיות ואיזה סדר עיבוד נחשבים לנורמה עבור פרופיל היעד.