אבולוציה של הארכיטקטורה של מערכת המסחר והסליקה של הבורסה במוסקבה. חלק 2

זהו המשך לסיפור ארוך על הדרך הקוצנית שלנו ליצירת מערכת עוצמתית ועומסת גבוהה המבטיחה את פעולת הבורסה. החלק הראשון כאן: habr.com/en/post/444300

טעות מסתורית

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

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

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

הגורם לשגיאה לא נמצא.

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

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

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

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

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

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

במהלך הניתוח הבא של המצב, עלתה תיאוריה לפיה הבעיה יכולה להיות קשורה למערכת ההפעלה. כתבנו תוכנית פשוטה שקוראת לפונקציה בלולאה אינסופית fesetround, זוכר את המצב הנוכחי ובודק אותו דרך שינה, וזה נעשה בשרשורים מתחרים רבים. לאחר שבחרנו את הפרמטרים לשינה ומספר השרשורים, התחלנו לשחזר בעקביות את כשל הסיביות לאחר כ-5 דקות של הפעלת הכלי. עם זאת, תמיכת Red Hat לא הצליחה לשחזר אותו. בדיקה של השרתים האחרים שלנו הראתה שרק אלה עם מעבדים מסוימים רגישים לשגיאה. במקביל, מעבר לקרנל חדש פתר את הבעיה. בסופו של דבר, פשוט החלפנו את מערכת ההפעלה, והגורם האמיתי לבאג נותר לא ברור.

ופתאום בשנה שעברה התפרסם מאמר ב-Habré "איך מצאתי באג במעבדי Intel Skylake" המצב המתואר בו היה דומה מאוד לשלנו, אך המחבר לקח את החקירה הלאה והעלה תיאוריה שהשגיאה הייתה במיקרוקוד. וכאשר ליבות לינוקס מתעדכנות, היצרנים מעדכנים גם את המיקרוקוד.

פיתוח נוסף של המערכת

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

העקרונות הבאים היוו את הבסיס לשיפורים הבאים במערכת ההזמנות:

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

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

רשת

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

במצבים כאלה, ניתן להשתמש בקרת עדיפות תהליכית דינמית, אך הדבר ידרוש שימוש בקריאות מערכת עתירות משאבים. כתוצאה מכך, עברנו לשרשור אחד באמצעות epoll קלאסי, זה הגביר מאוד את המהירות והפחית את זמן עיבוד העסקאות. נפטרנו גם מתהליכי תקשורת נפרדים ברשת ומתקשורת דרך SystemV, צמצמנו משמעותית את מספר שיחות המערכת והתחלנו לשלוט בסדר העדיפויות של הפעולות. בתת-מערכת ה-I/O בלבד, ניתן היה לחסוך כ-8-17 מיקרו-שניות, תלוי בתרחיש. סכימת חוט יחיד זו הייתה בשימוש ללא שינוי מאז; שרשור epoll אחד עם שוליים מספיק כדי לטפל בכל החיבורים.

עיבוד עסקה

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

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

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

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

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

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

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

כך הגענו למערכת ASTS+.

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

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

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

כל התור מעובד בצורה זו.

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

כתוצאה מכך, השגנו ביצועים של כ-8 מיליון עסקאות בשנייה. וממש חודשיים לאחר מכן статье לגבי LMAX Disruptor ראינו תיאור של מעגל עם אותה פונקציונליות.

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

מערכת ניהול סיכוני חליפין

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

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

בעת בחירת מערכת חדשה, היינו צריכים לפתור מיד את בעיית האינטראקציה. בעת בחירת אפיק נתונים, היה צורך להבטיח ריצוד יציב והשהייה מינימלית. רשת InfiniBand RDMA הייתה המתאימה ביותר לכך: זמן העיבוד הממוצע קטן פי 4 מאשר ברשתות 10 G Ethernet. אבל מה שבאמת כבש אותנו היה ההבדל באחוזונים - 99 ו-99,9.

כמובן של-InfiniBand יש אתגרים שלה. ראשית, API אחר - ibverbs במקום sockets. שנית, אין כמעט פתרונות העברת הודעות בקוד פתוח. ניסינו ליצור אב טיפוס משלנו, אבל התברר שזה היה מאוד קשה, אז בחרנו בפתרון מסחרי - Confinity Low Latency Messaging (לשעבר IBM MQ LLM).

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

לפתרונות המכונים Ultra Low Latency יש מצב הזמנה מחדש: ניתן לארגן עסקאות משני מקורות לפי הסדר הנדרש עם הקבלה; זה מיושם באמצעות ערוץ נפרד להחלפת מידע על ההזמנה. אבל אנחנו עדיין לא משתמשים במצב הזה: זה מסבך את כל התהליך, ובמספר פתרונות הוא לא נתמך כלל. בנוסף, לכל עסקה יהיה צורך להקצות חותמות זמן מתאימות, ובתכנית שלנו קשה מאוד ליישם את המנגנון הזה בצורה נכונה. לכן, השתמשנו בסכימה הקלאסית עם מתווך הודעות, כלומר עם שדר שמפיץ הודעות בין Risk Engine.

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

שִׁכפוּל

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

עבודה עם מרכז נתונים לגיבוי

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

תוצאות של

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

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

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

קראנו לגרסה הנוכחית של הפלטפורמה שלנו Rebus - כקיצור של שני החידושים הבולטים ביותר בארכיטקטורה, Risk Engine ו-BUS.

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

מה שהשגנו בסופו של דבר:

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

ביצועי השיא עלו מ-50 אלף ל-180 אלף עסקאות בשנייה. עלייה נוספת נבלמת על ידי הזרם היחיד של התאמת הזמנות.

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

לבסוף, אני יכול לתת כמה עצות למי שמסיים מערכות ארגוניות:

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

מקור: www.habr.com