How ShareChat engineers rebuilt a low-latency ML feature store on ScyllaDB after an initial scalability failure — and what they learned along the way הביקוש לחנויות תכונות למידה מכונה עם עיכוב נמוך גבוה יותר מאי פעם, אבל למעשה יישום אחד בקנה מידה הוא עדיין אתגר.זה הפך ברור כאשר מהנדסים של ShareChat איוון Burmistrov ואנדרי Manakov לקחו את שלב P99 CONF 23 כדי לשתף כיצד הם נבנו חנות תכונות ML עם עיכוב נמוך המבוסס על ScyllaDB. זהו סיפור של "שיעורים לומדים", מבט על הערך של אופטימיזציה ללא הרף של הביצועים - עם כמה ניסיונות הנדסיים חשובים. יישום המערכת המקורי היה רחוק מתחת לדרישות המגמה של החברה.המטרה הסופית הייתה לתמוך במיליארד תכונות לשנייה, אך המערכת נכשלה תחת עומס של מיליון בלבד.עם פתרון בעיות חכם, הצוות הוציא את זה.בואו נסתכל איך המהנדסים שלהם הצליחו להסתובב מהכישלון הראשוני כדי לעמוד במטרת הביצועים הגבוהה שלהם מבלי להגדיל את מסד הנתונים הבסיסי. ShareChat: פלטפורמת המדיה החברתית המובילה בהודו כדי להבין את היקף האתגר, חשוב לדעת קצת על ShareChat, פלטפורמת המדיה החברתית המובילה בהודו.באפליקציית ShareChat, משתמשים לגלות ולהשתמש בתוכן ביותר מ-15 שפות שונות, כולל קטעי וידאו, תמונות, שירים ועוד. בין שתי היישומים, הם משרתים בסיס משתמשים גדל במהירות שיש לו כבר מעל 325 מיליון משתמשים פעילים בחודש. תגיות קשורות ShareChat הסיפור מתמקד במערכת שמאחורי חנויות התכונות של ML עבור אפליקציית הווידאו הקצרה Moj.היא מציעה זרמים מותאמים אישית לחלוטין לכ-20 מיליון משתמשים פעילים מדי יום, 100 מיליון משתמשים פעילים בחודש.זרמים משרתים 8,000 בקשות לשנייה, ויש בממוצע 2,000 מועמדים לתוכן ממוקמים על כל בקשה (לדוגמה, כדי למצוא את 10 הפריטים הטובים ביותר להמליץ). איוון ברמסטרוב, מהנדס התוכנה הראשי של ShareChat, הסביר: אנו מחושבים תכונות עבור "יחידות" שונות. הפוסט הוא ישות אחת, המשתמש הוא אחר וכן הלאה. מנקודת המבט של החישוב, הם דומים למדי. עם זאת, ההבדל החשוב הוא במספר התכונות שאנחנו צריכים לקחת עבור כל סוג של ישות. כאשר משתמש מבקש זרימה, אנו לקחת תכונות משתמש עבור המשתמש היחיד. עם זאת, כדי להגדיר את כל הפוסטים, אנחנו צריכים לקחת תכונות עבור כל מועמד (פוסט) להיות מדורג, כך שההרמה הכוללת על המערכת שנוצרה על ידי תכונות הפוסט היא הרבה יותר גדולה מאשר זו שנוצרה על ידי תכונות משתמש. ההבדל הזה משחק תפקיד חשוב בסיפור שלנו. אנו מחושבים תכונות עבור "יחידות" שונות. הפוסט הוא ישות אחת, המשתמש הוא אחר וכן הלאה. מנקודת המבט של החישוב, הם דומים למדי. עם זאת, ההבדל החשוב הוא במספר התכונות שאנחנו צריכים לקחת עבור כל סוג של ישות. כאשר משתמש מבקש זרימה, אנו לקחת תכונות משתמש עבור המשתמש היחיד. עם זאת, כדי להגדיר את כל הפוסטים, אנחנו צריכים לקחת תכונות עבור כל מועמד (פוסט) להיות מדורג, כך שההרמה הכוללת על המערכת שנוצרה על ידי תכונות הפוסט היא הרבה יותר גדולה מאשר זו שנוצרה על ידי תכונות משתמש. ההבדל הזה משחק תפקיד חשוב בסיפור שלנו. מדוע ארכיטקטורת החנות המקורית לא הצליחה להגדיל בהתחלה התמקדו בעיקר בבניית חנות תכונות המשתמשים בזמן אמת, כי בשלב זה היו תכונות המשתמש החשובות ביותר.הצוות החל לבנות את חנות התכונות עם המטרה הזאת בחשבון.אבל אז השתנו העדיפויות והפונקציונליות הפכו גם לתשומת לב.השינוי הזה קרה משום שהצוות החל לבנות מערכת דירוג חדשה לחלוטין עם שני הבדלים עיקריים לעומת קודמו: תכונות פוסט קרובות בזמן אמת היו חשובות יותר מספר הפוסטים לדרג גדל ממאות אלפי איוואן הסביר: "כאשר הלכנו לבדוק את המערכת החדשה, היא נכשלה באופן מצער.עם כמיליון תווים לשנייה, המערכת הפכה לא מגיבה, עיכובים עברו דרך הגג וכן הלאה". בסופו של דבר, הבעיה נובעת מאיך ארכיטקטורה המערכת השתמשה בקופסאות נתונים מוקדמות בשם צלחות. לדוגמה, הם יכולים לצבור את מספר האהובים על פוסט בדקה נתונה או טווח זמן אחר. הנה מבט ברמה גבוהה על ארכיטקטורת המערכת. ישנם כמה נושאים בזמן אמת עם נתונים גלויים (אוהבים, קליקים, וכו '). עבודה Flink אוסף אותם לתוך צלחות וכותב אותם ScyllaDB. ואז יש שירות תכונה אשר מבקש צלחות מ ScyllaDB, אוסף אותם ומחזיר תוצאות לשירות הזנת. התכנית המקורית של מסד הנתונים והגדרת התכשיטים הובילו לבעיות בקנה מידה.בהתחלה, לכל ישות הייתה מחלקה משלה, עם שורות של סימן זמן ושם התכונה שהורדו בעמדות קבוצתיות. צלחות נחשב עבור חלקים של דקה אחת, 30 דקות, יום אחד.לרצות שעה אחת, יום אחד, שבעה ימים או 30 ימים נדרש להשיג סביב 70 צלחות לכל תכונה בממוצע. למד עוד בקורס זה מודל נתונים NoSQL Masterclass אם אתה עושה את המתמטיקה, זה הופך להיות ברור למה זה נכשל.המערכת צריכה לטפל בסביבות 22 מיליארד שורות לשנייה. אופטימיזציות חנות תכונות מוקדמות: מודל נתונים ושינויים בצלחת בשלב זה, הצוות נכנס למשימה של אופטימיזציה. התוכנית המקורית של מסד הנתונים עדכנה כדי לאחסן את כל שורות התכונות ביחד, הסריריאליזציה כפופרים של פרוטוקול עבור תווי זמן נתון. מכיוון שהארכיטקטורה כבר השתמשה ב- Apache Flink, המעבר לתוכנית החדשה הייתה קלה למדי, הודות ליכולות המתקדמות של Flink בבניית צינורות נתונים. הצוות גם אופטימיז את הגדרת הצלחות, הוסיף צלחות נוספות במשך חמש דקות, שלוש שעות וחמש ימים לצלחות של דקה אחת, 30 דקות ושל יום אחד. כדי להתמודד עם יותר שורות / שניות בצד הנתונים, הם שינו את אסטרטגיית הדחיסה של ScyllaDB מ- incremental ל- leveled. אפשרות זו מתאימה טוב יותר לדפוסי השאילתות שלהם, שמירה על שורות רלוונטיות ביחד והפחתת קריאת I/O. התוצאה: קיבולת ScyllaDB הוכפלה ביעילות. למד עוד על אסטרטגיות קמפיין הדרך הקלה ביותר להתאים את העומס הנותר הייתה להגדיל את ScyllaDB 4x. עם זאת, קבוצות גדולות יותר / גדולות יותר יגדילו את העלויות וזה פשוט לא היה בתקציב שלהם. שיפור מיקום קח של תכונה חנות כדי להפחית את עומס מסד הנתונים אחת הדרכים הפוטנציאליות להפחית את העומס על ScyllaDB הייתה לשפר את שיעור ההיט המקומי של ה-Cache, כך שהצוות החליט לחקור כיצד ניתן היה להשיג זאת. הבחירה הברורה הייתה להשתמש בגישה קבועה ל-Hashing, טכניקה ידועה להנחיה של בקשה לתמונה מסוימת מהלקוח בהתבסס על מידע מסוים על הבקשה. מאז הצוות השתמש ב-NGINX Ingress בהגדרת Kubernetes שלהם, השימוש ביכולות של NGINX ל-Hashing עקבי נשמע כמו בחירה טבעית. קצת.הגדרה פשוטה זו לא עבדה.במיוחד: החלק התחתון של הלקוח הוביל לתיקון מחדש עצום של מפתחות – עד 100% במקרה הגרוע ביותר. מכיוון שהמפתחות של המפרקים ניתן לשנות בטבעת חיתוך, לא ניתן היה להשתמש בסצינות בחיים האמיתיים עם מיקוד אוטומטי. היה קשה לספק ערך hash עבור בקשה כי Ingress אינה תומכת בפתרון הברור ביותר: כותרת gRPC. האטנטיות סבלה התדרדרות חמורה, ולא היה ברור מה גרם לאטנטיות הצוואר. כדי לתמוך במחלקה של pods, הצוות שינה את הגישה שלהם. הם יצרו פונקציה hash בשני שלבים: תחילה hashing ישות, ולאחר מכן הוספת מקדמה אקראית.זה הפצה את ישות על פני מספר הרצוי של pods. בתיאוריה, גישה זו יכולה לגרום להתנגשות כאשר ישות מפותחת אותו pod כמה פעמים. אינגרס לא תומכת בשימוש בכותרת gRPC כמשתנה, אבל הצוות מצא פתרון: באמצעות כתיבת מחדש של מסלול וסיפקת המפתח החישוי הנדרש במסלול עצמו. למרבה הצער, זיהוי הגורם להדרגה באיטיות היה לוקח זמן רב, כמו גם שיפור תצפיות. כדי לעמוד במועד המועד, הצוות חילק את השירות Feature ל-27 שירותים שונים והחל באופן ידני את כל היצורים ביניהם על הלקוח.זה לא היה הגישה האלגנטית ביותר, אבל, זה היה פשוט ומעשי – וזה השיג תוצאות נהדרות. עם זאת, גישה זו של חלוקת ההפצה של "בית הספר הישן" עדיין לא הייתה העיצוב האידיאלי. שמירה על 27 הפעלות הייתה משעממת ולא יעילה. בנוסף, שיעור ההצלחה של הקאש לא היה יציב, והרחבה הייתה מוגבלת על ידי צורך לשמור על מספר מינימום גבוה של פודים בכל הפצה. השלב הבא של אופטימיזציות: Hashing עקבי, Feature Service מוכן לסיבוב נוסף של אופטימיזציה, הצוות בדק מחדש את גישת ההשקה הקבועה באמצעות sidecar, הנקרא Envoy Proxy, המותקף עם שירות התכונה. Envoy Proxy סיפק תצפיות טובות יותר שהסייעו לזהות את בעיה זנב האטנטיות. הבעיה: דפוסי בקשה שונים לשירות התכונה גרמו לעיכוב עצום על שכבת gRPC והקשה. לאחר מכן, הקבוצה אופטימלית את השירות Feature. הוצאנו את ספריית הקאשינג (FastCache מ-VictoriaMetrics) ושימשנו כתיבת מניות ומחיקה טובה יותר כדי להפחית את התנגדות המוטקס ב-100x. gprc-go ו-buffer pool מיושמים בין חיבורים שונים כדי למנוע מחלוקת במהלך paralelism גבוה. השתמש באוסף אובייקטים ופרמטרים של אוסף פסולת מותאם (GC) כדי להפחית את שיעורי ההפצה ואת מחזורי GC. בעוד ש-Envoy Proxy עוסק ב-15% מהתנועה בהוכחת המושג שלהם, התוצאות היו מבטיחות: שיעור ההצלחה של 98% ב-Cache, שהפחית את עומס הטעינה של ScyllaDB ל-7.4 מיליון שורות בשנייה. שיעורים שלמדו מהפיתוח חנות תכונות ביצועים גבוהים הנה מה שהטיול הזה נראה מנקודת מבט של לוח זמנים: לסיום, אנדרי סיכם את השיעורים העיקריים של הצוות למד מהפרויקט הזה (עד כה): למרות שהצוות של ShareChat שינה באופן דרמטי את עיצוב המערכת שלהם, ScyllaDB, Apache Flink ו- VictoriaMetrics המשיכו לעבוד היטב. כל אופטימיזציה קשה יותר מהקודמת - ויש לה פחות השפעה. פתרונות פשוטים ומעשיים (כגון חלוקת חנות התכונות ל-27 יישומים) באמת עובדים. הפתרון המספק את הביצועים הטובים ביותר אינו תמיד ידידותי למשתמש. לדוגמה, התוכנית המוקדמת שלהם מספקת ביצועים טובים, אך קשה לשמור ולהבין. בסופו של דבר, הם כתבו כמה כלים סביב זה כדי להפוך את זה קל יותר לעבוד עם. כל מערכת היא ייחודית.לפעמים ייתכן שתצטרך לפרוץ ספרייה ברירת המחדל ולהתאים אותה למערכת הספציפית שלך כדי להשיג את הביצועים הטובים ביותר.
