איך להפסיק לדאוג ולהתחיל לחיות בלי מונוליט

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

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

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

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

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

אבל הזמן התקדם, ומספר הבקשות התקדם יחד איתו, ולפעמים ירה RPS מעבר ליכולות שלנו. עם כניסתן של מדינות חבר העמים לשוק, העומס על מעבד מסד הנתונים של המונוליט הראשון לא ירד מתחת ל-90%, וה-RPS נשאר ברמה של 2400. ואלו לא היו רק בוררים קטנים, אלא שאילתות נכבדות עם חבורה של בדיקות ו-JOINs שיכולות לפעול כמעט עבור מחצית מהנתונים על רקע IO גדול.

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

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

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

צליל של רעם

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

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

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

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

כתוצאה מכך, הגענו לתכנית שמתאימה היטב ל-Tarantool.

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

ארכיטקטורה. אפשרות 1. שירות משתמש

נכון לעכשיו, ישנם 24 רסיסים, שלכל אחד מהם יש 2 מופעים (אחד לכל DC), כולם במצב מאסטר-מאסטר.

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

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

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

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

מסד הנתונים של השירות מורכב מ-4 מאסטרים שלתוכם הסנכרון אוסף נתונים, וכל אחד ממאסטרי השכפול הללו מפיץ נתונים להעתקות לקריאה בלבד. לכל מאסטר יש כ-15 העתקים כאלה.

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

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

חפש ומצא!

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

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

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

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

בסופו של דבר התיישבנו ב-Tarantool.

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

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

היישום התחיל בצורה קשה

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

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

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

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

הפרד ומשול. מה הקטע עם לואה?

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

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

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

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

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

אחד השירותים הקריטיים ביותר הוא פרופיל המשתמש. כלומר, כל משתמשי Wildberries מאוחסנים ב-Tarantool, ויש כ-50 מיליון מהם. מערכת מפוצלת על ידי מזהה משתמש, המופצת על פני מספר DCs המחוברים לשירותי Go.
לפי RPS, Promoter היה פעם המנהיג, והגיע ל-6 בקשות. בשלב מסוים היו לנו 50-60 עותקים. כעת המוביל ב-RPS הוא פרופילי משתמשים, כ-12 אלף. שירות זה משתמש בפיצול מותאם אישית, מחולק לפי טווחים של מזהי משתמש. השירות משרת יותר מ-20 מכונות, אבל זה יותר מדי, אנחנו מתכננים לצמצם את המשאבים שהוקצו, כי הקיבולת של 4-5 מכונות מספיקה לו.

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

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

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

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

מסקנה

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

מה עוד לקרוא בנושא

• יצירת אפליקציה בעומס גבוה מאפס באמצעות Tarantool habr.com/ru/company/mailru/blog/510440
• בחירה מובילה מהימנה במחסנית Tarantool habr.com/ru/company/mailru/blog/513912
• ערוץ טלגרם Tarantool עם חדשות על המוצר t.me/tarantool_news
• דון ב-Tarantool בצ'אט הקהילתי t.me/tarantoolru

מקור: www.habr.com