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

מדוע הארכיטקטורה של בורסת קריפטו נשברת בעומסי שיא

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

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

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

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

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

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

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

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

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

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

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

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

אפשרויות ארכיטקטורה של בורסת קריפטו: ליבה אחת, אשכול, היברידי

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

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

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

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

שלבי ההטמעה: מביקורת עומס ועד מסירה לתפעול

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

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

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

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

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

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

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

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

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

מה שינו בליבה

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

מיתוג ללא עצירת המסחר

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

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

במה נבדלת ליבת המסחר ממודול הסליקה ומה לשנות ראשון?

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

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

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

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

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

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

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

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

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

היכן נשמרים המפתחות וכיצד מנוהל יומן הפעולות?

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

האם ניתן לבצע מיגרציה ללא עצירת המסחר?

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

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

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

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

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