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

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

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

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

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

קצת היסטוריה

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

באותן שנים, מערכת הבורסה עבדה על חומרה גבוהה - שרתי HP Superdome 9000 אמינים במיוחד (הבנויים על PA-RISC), שבה לגמרי הכל שוכפל: תת-מערכות קלט/פלט, רשת, RAM (למעשה, היה מערך RAID של RAM), מעבדים (ניתנים להחלפה חמה). ניתן היה לשנות כל רכיב שרת מבלי לעצור את המכונה. הסתמכנו על המכשירים האלה וחשבנו שהם כמעט בטוחים לכישלון. מערכת ההפעלה הייתה מערכת HP UX דמוית Unix.

אבל מאז 2010 בערך, צצה תופעה שנקראת מסחר בתדר גבוה (HFT), או מסחר בתדר גבוה - במילים פשוטות, רובוטים בבורסה. תוך 2,5 שנים בלבד, העומס על השרתים שלנו גדל פי 140.

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

החל

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

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

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

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

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

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

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

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

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

מכיוון שהקוד היה חוט יחיד, נעשה שימוש בסכימה קלאסית עם מזלגות תהליך כדי לשרת לקוחות רבים. עם זאת, היה מאוד יקר לחלק את כל מסד הנתונים, ולכן נעשה שימוש בתהליכי שירות קלים שאספו מנות מסשנים של TCP והעבירו אותן לתור אחד (SystemV Message Queue). Gateway and Trade Engine עבדו רק עם התור הזה, ולקחו משם עסקאות לביצוע. לא ניתן עוד לשלוח לו תגובה, כי לא היה ברור באיזה תהליך שירות צריך לקרוא אותו. אז נקטנו בטריק: כל תהליך מזולג יצר לעצמו תור תגובות, וכאשר הגיעה בקשה לתור הנכנס, מיד נוספה לו תגית לתור התגובות.

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

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

שדרוגים ראשונים

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

השפעת המסחר בתדירות גבוהה

הגרסה לעיל של הארכיטקטורה הייתה קיימת עד 2010. בינתיים, כבר לא היינו מרוצים מהביצועים של שרתי HP Superdome. בנוסף, ארכיטקטורת PA-RISC כמעט מתה; הספק לא הציע עדכונים משמעותיים. כתוצאה מכך, התחלנו לעבור מ-HP UX/PA RISC ל-Linux/x86. המעבר החל בהתאמת שרתי גישה.

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

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

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

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

סבב חדש של אבולוציה

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

אדום - עבודה עם תור בליבה רגילה, ירוק - עבודה בליבה בזמן אמת.

אבל השגת זמן אחזור נמוך בשרתים רגילים אינה כל כך קלה:

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

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

כשעברנו משרתי PA-RISC ל-x86, למעשה לא היינו צריכים לשנות הרבה את קוד המערכת, רק התאמנו והגדרנו אותו מחדש. במקביל, תיקנו מספר באגים. לדוגמה, ההשלכות של העובדה ש-PA RISC הייתה מערכת Big endian, ו-x86 הייתה מערכת Little endian, עלו במהירות: לדוגמה, הנתונים נקראו בצורה שגויה. הבאג המסובך יותר היה ש-PA RISC משתמש בו עקבי באופן עקבי (עקבי ברצף) גישה לזיכרון, בעוד ש-x86 יכול לסדר מחדש את פעולות הקריאה, כך שקוד שהיה תקף לחלוטין בפלטפורמה אחת נשבר בפלטפורמה אחרת.

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

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

אפוס מילואים לוהט

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

בנוסף, היו דרישות נוספות:

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

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

כתוצאה מכך, הגענו לתכנית הבאה:

• השרת הראשי קיים אינטראקציה ישירה עם שרתי ה-gateway.
• כל העסקאות שהתקבלו בשרת הראשי שוכפלו באופן מיידי לשרת הגיבוי דרך ערוץ נפרד. הבורר (הנגיד) תיאם את המעבר אם התעוררו בעיות כלשהן.

  

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

התוכנית עבדה כדלקמן.

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

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

המשך.

מקור: www.habr.com