איך אילפנו ב-CIAN טרה-בייט של יומנים

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

מאיפה התחלנו?

במהלך השנים האחרונות, העומס על cian.ru גדל מהר מאוד, ועד לרבעון השלישי של 2018, תעבורת המשאבים הגיעה ל-11.2 מיליון משתמשים ייחודיים בחודש. באותה תקופה, ברגעים קריטיים איבדנו עד 40% מהיומנים, וזו הסיבה שלא יכולנו לטפל במהירות בתקלות והשקענו זמן ומאמץ רב בפתרונן. לעתים קרובות גם לא הצלחנו למצוא את הגורם לבעיה, והיא הייתה חוזרת על עצמה לאחר זמן מה. זה היה גיהנום והיה צריך לעשות משהו בנידון.

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

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

אתגרי הצמיחה המהירה

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

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

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

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

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

מנגנון סיבוב חדש וצמתים חמים-חמים

התחלנו את המרת האשכולות על ידי עדכון גרסת ElasticSearch מ-5.5.2 ל-6.4.3. שוב, אשכול גרסה 5 שלנו מת, והחלטנו לכבות אותו ולעדכן אותו לחלוטין - עדיין אין לוגים. אז עשינו את המעבר הזה תוך כמה שעות בלבד.

השינוי בקנה מידה גדול ביותר בשלב זה היה יישום אפאצ'י קפקא בשלושה צמתים עם רכז כמאגר ביניים. מתווך ההודעות הציל אותנו מאיבוד יומנים במהלך בעיות עם ElasticSearch. במקביל, הוספנו 2 צמתים לאשכול ועברנו לארכיטקטורה חמה-חמה עם שלושה צמתים "חמים" הממוקמים ב-racks שונים במרכז הנתונים. הפנינו אליהם יומנים באמצעות מסיכה שאסור לאבד בשום פנים ואופן - nginx, כמו גם יומני שגיאות של יישומים. יומנים קלים נשלחו לצמתים הנותרים - איתור באגים, אזהרה וכו', ולאחר 24 שעות הועברו יומנים "חשובים" מצמתים "חמים".

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

אופטימיזציה של אשכול

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

לדוגמה, עבור תצורת הסיבוב:

сurator-elk-rollover.yaml

---
actions:
  1:
    action: rollover
    options:
      name: "nginx_write"
      conditions:
        max_docs: 100000000
  2:
    action: rollover
    options:
      name: "python_error_write"
      conditions:
        max_docs: 10000000

אם לא היה כינוי גלגול, אירעה שגיאה:

ERROR     alias "nginx_write" not found.
ERROR     Failed to complete action: rollover.  <type 'exceptions.ValueError'>: Unable to perform index rollover with alias "nginx_write".

השארנו את הפתרון לבעיה הזו לאיטרציה הבאה והתייחסנו לסוגיה נוספת: עברנו ללוגיקת ה-pull של Logstash, שמעבדת לוגים נכנסים (הסרת מידע מיותר והעשרה). שמנו אותו ב-docker, אותו אנו משיקים דרך docker-compose, והצבנו שם גם logstash-exporter, ששולח מדדים ל-Prometheus לניטור תפעולי של זרם היומן. כך נתנו לעצמנו את ההזדמנות לשנות בצורה חלקה את מספר מופעי ה-logstash האחראים לעיבוד כל סוג של יומן.

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

יחד עם זאת, קנה המידה ושינוי ההגדרות של מופעי logstash באשכול היה מסובך בשל העובדה שמדובר ב-docer-compose מקומי, וכל הפעולות בוצעו באופן ידני (כדי להוסיף קצוות חדשים, היה צורך לעבור באופן ידני על כל את השרתים ולעשות docker-compose up -d בכל מקום).

חלוקה מחדש של יומנים

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

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

• עבור צמתים "חמים": E3-1270 v6 / 960Gb SSD / 32 Gb x 3 x 2 (3 עבור Hot1 ו-3 עבור Hot2).
• עבור צמתים "חמים": E3-1230 v6 / 4Tb SSD / 32 Gb x 4.

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

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

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

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

תוכניות לעתיד

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

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

כעת אנו מתכוננים לעדכן את ElasticSearch לגרסה 7. עם זאת, לשם כך נצטרך לעדכן את המיפוי של אינדקסים רבים ב- ElasticSearch, מכיוון שהם עברו מגרסה 5.5 והוכרזו כמי שהוצאו משימוש בגרסה 6 (הם פשוט לא קיימים בגרסה 7) 7). המשמעות היא שבמהלך תהליך העדכון בהחלט יהיה סוג של כוח עליון, שישאיר אותנו ללא יומנים בזמן שהבעיה תיפתר. מגרסה XNUMX, אנחנו הכי מצפים ל-Kibana עם ממשק משופר ומסננים חדשים. 

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

מקור: www.habr.com