כיצד פועל החיפוש של Yandex.Market ומה קורה אם אחד השרתים נכשל

שלום, שמי יבגני. אני עובד בתשתית החיפוש של Yandex.Market. אני רוצה לספר לקהילת הבר על המטבח הפנימי של השוק – ויש לי הרבה מה לספר. קודם כל, איך פועל חיפוש השוק, תהליכים וארכיטקטורה. איך אנחנו מתמודדים עם מצבי חירום: מה קורה אם שרת אחד נופל? מה אם יש 100 שרתים כאלה?

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

קצת עלינו: איזו בעיה אנחנו פותרים

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

אנו מעבדים את כל בקשות החיפוש: מהאתרים market.yandex.ru, beru.ru, שירות Supercheck, Yandex.Advisor, יישומים ניידים. אנו כוללים גם הצעות מוצרים בתוצאות החיפוש ב-yandex.ru.

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

מה זה מה: ארכיטקטורת שוק

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

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

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

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

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

ארכיטקטורת חיפוש שוק

אנחנו חיים בעולם של מיקרו-שירותים: כל בקשה נכנסת market.yandex.ru גורם לשאילתות משנה רבות, ועשרות שירותים מעורבים בעיבוד שלהן. התרשים מציג רק כמה:

סכמת עיבוד בקשות פשוטה

לכל שירות יש דבר נפלא - מאזן משלו עם שם ייחודי:

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

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

FQDN יחיד עבור כל מרכזי הנתונים מאפשר לשירות A להתפשט לחלוטין ממיקומים. בקשתו לשירות ב' תטופל תמיד. היוצא מן הכלל הוא המקרה כאשר השירות ממוקם בכל מרכזי הנתונים.

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

התמודדות עם הבלתי צפוי: איזון שירותי חיפוש וחוסן

תארו לעצמכם שיש קריסה: אתם צריכים למצוא חתול עם צפצוף, אבל השרת קורס. או 100 שרתים. איך לצאת? האם באמת נשאיר את המשתמש בלי חתול?

המצב מפחיד, אבל אנחנו מוכנים לזה. אני אגיד לך לפי הסדר.

תשתית החיפוש ממוקמת במספר מרכזי נתונים:

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

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

מאזן אחד הוא לפחות שלושה שרתים פיזיים. יתירות זו נועדה לאמינות. מאזנים פועלים על HAProx.

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

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

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

תכונה נוספת של HAProxy: Agent-Check מאפשר לך לטעון את כל השרתים באופן שווה. לשם כך, HAProxy מתחברת לכל השרתים, והם מחזירים את משקלם בהתאם לעומס הנוכחי מ-1 ל-100. המשקל מחושב לפי מספר הבקשות בתור לעיבוד והעומס על המעבד.

עכשיו לגבי מציאת החתול. תוצאות החיפוש בבקשות כמו: /search?text=engry+cat. כדי שהחיפוש יהיה מהיר, כל אינדקס החתול חייב להתאים ל-RAM. אפילו קריאה מה-SSD אינה מהירה מספיק.

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

אבל זה תמיד קורה: כל פתרון, אפילו טוב, מעורר בעיות אחרות.

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

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

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

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

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

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

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

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

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

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

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

שאילתות חיפוש בתוך האשכול נראות כך: /shard1?text=כועס+חתול. בנוסף, שאילתות משנה של הטופס מתבצעות כל הזמן בין כל השרתים בתוך האשכול פעם בשנייה: /סטָטוּס.

בקשה /סטָטוּס מזהה מצב שבו השרת אינו זמין.

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

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

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

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

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

משהו נורא קרה: שרת אחד לא זמין

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

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

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

כאשר השרת הופך זמין, הוא מתחיל להגיב /ping. ברגע שמתחילות להגיע תגובות רגילות לפינגים משרתים מתים, מאזנים מתחילים לשלוח לשם תעבורת משתמשים. פעולת האשכול משוחזרת, מהירה.

גרוע מכך: שרתים רבים אינם זמינים

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

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

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

איך אנחנו עושים את זה: פרסום מהדורות

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

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

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

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

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

כל הטוב מגיע למשתמש: בדיקות A/B

לא תמיד ברור אם שינויים בשירות יביאו יתרונות אמיתיים. כדי למדוד את התועלת של שינויים, אנשים הגיעו לבדיקות A/B. אני אספר לך קצת על איך זה עובד בחיפוש Yandex.Market.

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

If (cgi.experiments.market_new_functionality) {
// enable new functionality
}

פונקציונליות חדשה מתגלגלת לייצור.

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

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

כתוצאה מכך, השירות מוסיף אוטומטית ארגומנט market_new_functionality=1 ל-15% מהמשתמשים. זה גם מחשב אוטומטית את המדדים שנבחרו. לאחר השלמת הניסוי, האנליסטים מסתכלים על התוצאות ומסיקים מסקנות. על סמך הממצאים, מתקבלת החלטה להתגלגל לייצור או לשכלול.

היד המיומנת של השוק: בדיקה בייצור

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

יש פתרון: ניתן להשתמש בדגלים בפרמטרים של CGI לא רק לבדיקת A/B, אלא גם לבדיקת פונקציונליות חדשה.

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

תרשים זרימת השירות מוצג להלן:

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

בהקשה עצור תוכל להגדיר שני סוגי ערכים:

1) ביטויים מותנים. החל כאשר אחד הערכים נכון. לדוגמה:

{
	"condition":"IS_DC1",
	"value":"3",
}, 
{
	"condition": "CLUSTER==2 and IS_BERU", 
	"value": "4!" 
}

הערך "3" יוחל כאשר הבקשה תעובד במיקום DC1. והערך הוא "4" כאשר הבקשה מעובדת באשכול השני עבור האתר beru.ru.

2) ערכים ללא תנאי. החל כברירת מחדל אם אף אחד מהתנאים לא מתקיים. לדוגמה:

ערך, ערך!

אם ערך מסתיים בסימן קריאה, הוא מקבל עדיפות גבוהה יותר.

מנתח פרמטר CGI מנתח את כתובת האתר. לאחר מכן מחיל את הערכים מה-Stop Tap.

ערכים עם סדרי העדיפויות הבאים מיושמים:

1. עם עדיפות מוגברת מה-Stop Tap (סימן קריאה).
2. הערך מהבקשה.
3. ערך ברירת מחדל מ- Stop tap.
4. ערך ברירת מחדל בקוד.

ישנם דגלים רבים שמצוינים בערכים מותנים - הם מספיקים לכל התרחישים המוכרים לנו:

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

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

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

לשירות הזה יש גם חסרונות: המפתחים אוהבים אותו מאוד ולעתים קרובות מנסים לדחוף את כל השינויים ל-Stop Tap. אנחנו מנסים להילחם בשימוש לרעה.

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

עם זאת, Stop Tap אינו מתאים לבדיקה במהלך הפיתוח. יש אשכול נפרד למפתחים שנקרא "אשכול הצללים".

בדיקה סודית: Shadow Cluster

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

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

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

ממצאים

אז איך בנינו את חיפוש השוק?

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

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

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

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

מקור: www.habr.com