ארכיטקטורה ויכולות של Tarantool Data Grid

ב-2017 זכינו בתחרות לפיתוח ליבת העסקאות של עסקי ההשקעות של אלפא-בנק והתחלנו לעבוד (ב-HighLoad++ 2018 עם דוח על ליבת עסקי ההשקעות מְבוּצָע ולדימיר דריינקין, ראש ליבת העסקאות של עסקי ההשקעות של בנק אלפא). מערכת זו הייתה אמורה לאסוף נתוני עסקאות ממקורות שונים בפורמטים שונים, להביא את הנתונים לצורה אחידה, לאחסן אותם ולספק להם גישה.

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

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

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

מַחבֵּר

Connector אחראי על התקשורת עם העולם החיצון; המשימה שלו היא לקבל את הבקשה, לנתח אותה, ואם זה מצליח, לשלוח את הנתונים לעיבוד למעבד הקלט. אנו תומכים בפורמטים של HTTP, SOAP, Kafka, FIX. הארכיטקטורה מאפשרת לך פשוט להוסיף תמיכה בפורמטים חדשים, עם תמיכה ב-IBM MQ בקרוב. אם ניתוח הבקשה נכשל, המחבר יחזיר שגיאה; אחרת, הוא יענה שהבקשה עובדה בהצלחה, גם אם אירעה שגיאה במהלך עיבודה הנוסף. זה נעשה במיוחד על מנת לעבוד עם מערכות שאינן יודעות לחזור על בקשות – או להיפך, לעשות זאת בהתמדה מדי. כדי לא לאבד נתונים, נעשה שימוש בתור תיקון: האובייקט נכנס אליו תחילה ורק לאחר עיבוד מוצלח מוסר ממנו. המנהל יכול לקבל התראות על אובייקטים שנותרו בתור התיקון, ולאחר ביטול שגיאת תוכנה או כשל חומרה, נסה שוב.

מעבד קלט

מעבד הקלט מסווג את הנתונים שהתקבלו לפי מאפיינים אופייניים וקורא למעבדים המתאימים. המטפלים הם קוד Lua שפועל בארגז חול, כך שהם לא יכולים להשפיע על תפקוד המערכת. בשלב זה ניתן לצמצם את הנתונים לצורה הנדרשת, ובמידת הצורך להפעיל מספר שרירותי של משימות שיכולות ליישם את ההיגיון הנדרש. לדוגמה, במוצר MDM (Master Data Management) הבנוי על Tarantool Data Grid, בעת הוספת משתמש חדש, על מנת לא להאט את עיבוד הבקשה, אנו משיקים את יצירת רשומה מוזהבת כמשימה נפרדת. ארגז החול תומך בבקשות לקריאה, שינוי והוספה של נתונים, מאפשר לבצע פונקציה כלשהי בכל התפקידים של סוג האחסון והצבירה של התוצאה (מפה/הקטנה).

ניתן לתאר מטפלים בקבצים:

sum.lua

local x, y = unpack(...)
return x + y

ואז, הכריז בתצורה:

functions:
  sum: { __file: sum.lua }

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

אחסון

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

{
    "name": "User",
    "type": "record",
    "logicalType": "Aggregate",
    "fields": [ 
        { "name": "id", "type": "string"}, 
        {"name": "first_name", "type": "string"}, 
        {"name": "last_name", "type": "string"} 
    ], 
    "indexes": ["id"] 
}

בהתבסס על תיאור זה, DDL (שפת הגדרת נתונים) נוצר אוטומטית עבור ה-Tarantula DBMS ו גרפית סכימה לגישה לנתונים.

נתמך שכפול נתונים אסינכרוני (יש תוכניות להוסיף אחד סינכרוני).

מעבד פלט

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

שינוי קנה מידה

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

מאפייני נתונים

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

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

משימות

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

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

לוגר

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

שירותים

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

השירות מתואר בקובץ התצורה:

services:
   sum:
      doc: "adds two numbers"
      function: sum
      return_type: int
      args:
         x: int
         y: int

ה-API של GraphQL נוצר באופן אוטומטי והשירות הופך זמין לקריאה:

query {
   sum(x: 1, y: 2) 
}

זה יקרא למטפל sumמה שיחזיר את התוצאה:

3

פרופיל שאילתות ומדדים

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

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

לפרוס

ניתן לפרוס את Tarantool Data Grid מחבילות RPM או מארכיון, באמצעות כלי עזר מההפצה או Ansible, יש גם תמיכה עבור Kubernetes (מפעיל Tarantool Kubernetes).

האפליקציה המיישמת את ההיגיון העסקי (קונפיגורציה, מטפלים) נטען לתוך אשכול ה-Tarantool Data Grid הפרוס בצורה של ארכיון דרך ממשק המשתמש או באמצעות סקריפט דרך ה-API שסופק על ידינו.

יסודות הפילוסופיה

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

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

1. רובוטים שאוספים מידע ממקורות פתוחים יהיו מקורות הנתונים שלנו. אתה יכול לפתור בעיה זו באמצעות פתרונות מוכנים או כתיבת קוד בכל שפה.
2. לאחר מכן, Tarantool Data Grid תקבל ותשמור את הנתונים. אם פורמט הנתונים ממקורות שונים שונה, אז אתה יכול לכתוב קוד ב-Lua שיבצע את ההמרה לפורמט בודד. בשלב העיבוד המקדים תוכל, למשל, לסנן הצעות כפולות או לעדכן בנוסף מידע על סוכנים הפועלים בשוק במסד הנתונים.
3. עכשיו כבר יש לך פתרון ניתן להרחבה באשכול שניתן למלא בנתונים ולבצע בחירות נתונים. לאחר מכן תוכלו ליישם פונקציונליות חדשה, למשל, לכתוב שירות שיעשה בקשה לנתונים וייתן את ההצעה הכי משתלמת ליום - זה ידרוש כמה שורות בקובץ התצורה וקצת קוד Lua.

מה הלאה?

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

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

מקור: www.habr.com