🥇 מחסנית Tarantool: ריסוק קצה אחורי של Lua בשלוש שורות

ב-Mail.ru Group יש לנו את Tarantool - זהו שרת יישומים ב-Lua, שמשמש גם כבסיס נתונים (או להיפך?). זה מהיר ומגניב, אבל היכולות של שרת אחד עדיין לא בלתי מוגבלות. קנה מידה אנכי הוא גם לא תרופת פלא, אז ל-Tarantool יש כלים לקנה מידה אופקי - מודול vshard [1]. זה מאפשר לך לפזר נתונים על פני מספר שרתים, אבל אתה צריך להתעסק עם זה כדי להגדיר אותם ולצרף את ההיגיון העסקי.

חדשות טובות: אספנו כמה תמונות גדולות (למשל [2], [3]) ויצרה מסגרת נוספת שתפשט משמעותית את הפתרון לבעיה זו.

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

ומה בדיוק הבעיה?

יש לנו טרנטולה, יש לנו ושרד - מה עוד אפשר לרצות?

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

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

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

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

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

תכונות עיקריות של מחסנית Tarantool:

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

שלום עולם!

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

$ tarantoolctl rocks install cartridge-cli
$ export PATH=$PWD/.rocks/bin/:$PATH

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

$ cartridge create --name myapp

וזה מה שאנחנו מקבלים:

myapp/
├── .git/
├── .gitignore
├── app/roles/custom.lua
├── deps.sh
├── init.lua
├── myapp-scm-1.rockspec
├── test
│   ├── helper
│   │   ├── integration.lua
│   │   └── unit.lua
│   ├── helper.lua
│   ├── integration/api_test.lua
│   └── unit/sample_test.lua
└── tmp/

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

$ tarantoolctl rocks make
$ ./init.lua --http-port 8080

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

פיתוח אפליקציות

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

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

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

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

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

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

ניהול טופולוגיה

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

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

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

חיים של תפקידים

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

function init()
function validate_config()
function apply_config()
function stop()

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

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

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

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

תפקידים יכולים לקיים אינטראקציה זה עם זה. אנחנו רגילים לכתוב קריאות לפונקציות ב-Lua, אבל יכול לקרות שלתהליך נתון אין את התפקיד שאנחנו צריכים. כדי להקל על שיחות דרך הרשת, אנו משתמשים במודול העזר rpc (remote procedure call), אשר בנוי על בסיס ה-netbox הסטנדרטי המובנה ב-Tarantool. זה יכול להיות שימושי אם, למשל, השער שלך רוצה לבקש ישירות מהמתזמן לעשות את העבודה כבר עכשיו, במקום לחכות יום.

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

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

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

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

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

כלי פריסה

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

$ cartridge pack rpm myapp -- упакует для нас ./myapp-0.1.0-1.rpm
$ sudo yum install ./myapp-0.1.0-1.rpm

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

$ sudo tee /etc/tarantool/conf.d/demo.yml <<CONFIG
myapp.router: {"advertise_uri": "localhost:3301", "http_port": 8080}
myapp.storage_A: {"advertise_uri": "localhost:3302", "http_enabled": False}
myapp.storage_B: {"advertise_uri": "localhost:3303", "http_enabled": False}
CONFIG

יש כאן ניואנס מעניין. במקום לציין רק את יציאת הפרוטוקול הבינארי, אנו מציינים את כל הכתובת הציבורית של התהליך כולל שם המארח. זה הכרחי כדי שצמתי האשכול ידעו להתחבר זה לזה. זה רעיון רע להשתמש ב-0.0.0.0 ככתובת advertise_uri; היא צריכה להיות כתובת IP חיצונית, לא חיבור socket. בלי זה שום דבר לא יעבוד, אז Cartridge פשוט לא יאפשר לך להפעיל צומת עם advert_uri הלא נכון.

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

$ sudo systemctl start myapp@router
$ sudo systemctl start myapp@storage_A
$ sudo systemctl start myapp@storage_B

בתצורה, ציינו את יציאת ה-HTTP בה Cartridge משרתת את ממשק האינטרנט - 8080. בואו נלך אליו ונסתכל:

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

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