ארכיטקטורה לאחסון ושיתוף תמונות ב-Badoo

ארטם דניסוב ( bo0rsh201, Badoo)

Badoo הוא אתר ההיכרויות הגדול בעולם. יש לנו כיום כ-330 מיליון משתמשים רשומים ברחבי העולם. אבל מה שהרבה יותר חשוב בהקשר של השיחה שלנו היום הוא שאנחנו מאחסנים כ-3 פטה-בייט של תמונות משתמש. כל יום המשתמשים שלנו מעלים כ-3,5 מיליון תמונות חדשות, ועומס הקריאה הוא בערך 80 אלף בקשות בשנייה. זה די הרבה עבור backend שלנו, ולפעמים יש קשיים עם זה.

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

עכשיו בואו נתחיל.

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

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

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

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

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

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

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

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

ככה זה היה אצלנו במשך זמן מה.

זה היה בסביבות 2009. הם העבירו מכוניות, העבירו...

ובשלב מסוים התחלנו לשים לב שלתוכנית הזו יש חסרונות מסוימים. מהם החסרונות?

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

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

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

והנקודה האחרונה היא המחיר.

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

ובסופו של דבר, הסתפקנו בשימוש במה שנקרא Storage Area Network.

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

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

שני פלוס.

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

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

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

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

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

וכאן הכל משחק לידיים שלנו.

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

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

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

מטמון עם LRU יפתור את כל הבעיות שלנו. מה אנחנו עושים?

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

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

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

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

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

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

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

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

Nginx פשוט כותב ל-RAMDisk access.log עבור כל בקשה, בו הוא מציין את הנתיב לתמונה שהיא שירתה כעת (נתיב יחסי, כמובן), ואיזו מחיצה היא הוגשה. הָהֵן. הוא עשוי לומר "תמונה 1" ואז או מאגר, או מטמון חם, או מטמון קר, או פרוקסי.

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

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

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

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

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

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

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

נניח שיש אשכול של עשרים מכונות אחסון ושלושה שרתי מטמון (כך זה קרה).

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

האפשרות הנפוצה ביותר היא Round Robin. או לעשות את זה בטעות?

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

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

יש דרך בנאלית. אנחנו לוקחים את ה-hash מה-URL או את ה-hash ממפתח ה-Sharding שלנו, שנמצא ב-URL, ומחלקים אותו במספר השרתים. יעבוד? רָצוֹן.

הָהֵן. יש לנו בקשה של 2%, למשל, עבור איזו "example_url" הוא תמיד ינחת על השרת עם האינדקס "XNUMX", והמטמון יסלק כל הזמן בצורה הטובה ביותר.

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

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

בואו נוסיף.

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

גם האופציה הזו לא מתאימה לנו.

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

כמו מה זה נראה?

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

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

מה קורה במצב זה במהלך חלוקה מחדש?

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

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

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

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

זה לגבי מערכת המטמון. בואו נסתכל על התוצאות.

נראה שאין כאן שום דבר מסובך. אבל שיטה זו של ניהול המטמון נתנה לנו שיעור טריק של כ-98%. הָהֵן. מתוך 80 אלף הבקשות הללו בשנייה, רק 1600 מגיעות לאחסון, וזה עומס נורמלי לחלוטין, הם סובלים אותו בשלווה, תמיד יש לנו רזרבה.

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

זֶה. הם ממוקמים פחות או יותר מקומית לכל אחד משווקי היעד שלנו.

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

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

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

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

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

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

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

וסביר להניח שלמאזין מתוחכם עשויה להיות שאלה: למה לא פשוט לשנות הכל ל-CDN? זה יהיה בערך אותו הדבר; כל CDNs המודרניים יכולים לעשות זאת. וישנן מספר סיבות.

הראשון הוא צילומים.

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

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

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

והנקודה העולה מהקודמת היא

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

איזו מסקנה זה מציע? במקרה שלנו, CDN אינו חלופה טובה במיוחד.

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

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

וב-CDN המודרניים יש כמעט כל מה שסיפרתי לכם עליו עכשיו. למעט פלוס או מינוס כמה תכונות.

מדובר במתן תמונות.

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

2013 חלפה.

שרתי מטמון נוספו, בעיות ביצועים נעלמו. הכל בסדר. מערך הנתונים הולך וגדל. נכון לשנת 2013, היו לנו כ-80 שרתים המחוברים לאחסון, וכ-40 שרתים מטמון בכל DC. מדובר ב-560 טרה-בייט של נתונים בכל DC, כלומר. בערך פטה-בייט בסך הכל.

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

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

ראשית, רשת שטח האחסון (SAN) עצמה, שעלולה להיכשל.

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

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

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

בסך הכל יש לנו שלוש נקודות כישלון.

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

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

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

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

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

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

רק הוספנו סעיף שני.

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

כאן אנחנו פשוט עושים תור אסינכרוני בקרבת מקום.

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

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

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

והוספנו דיסק שלישי, שהוא SSD קטן, וקרא לו חיץ.

איך זה עובד עכשיו.

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

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

ובכן, והכי חשוב: הפסקנו לאבד נתונים.

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

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

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

ועשינו את הגרסה השלישית (למעשה, השנייה למעשה) - גרסת ההזמנה. איך זה נראה?

זה מה שהיה -

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

ראשית, אנחנו מסירים SANs כי אנחנו רוצים להתנסות, אנחנו רוצים לנסות רק כוננים קשיחים מקומיים.

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

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

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

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

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

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

המשימה קצת יותר קשה.

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

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

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

במצבנו זה לא עובד לאט.

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

אז מה עוד יש לנו שזה ממש מגניב?

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

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

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

מכונית אחת מתקלקלת.

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

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

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

אילו מסקנות ניתן להסיק מתכנית היתירות הזו?

קיבלנו סובלנות לתקלות.

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

קיבלנו קצבת קריאה כפולה.

זהו בונוס טוב מאוד בנוסף לסובלנות תקלות.

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

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

והנה שוב מתעורר קונפליקט כלשהו.

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

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

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

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

אבל יש גם חסרונות.

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

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

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

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

תוצאות של

יש לנו משתמשים - עד 33 מיליון.

יש לנו שלוש נקודות נוכחות - פראג, מיאמי, הונג קונג.

הם מכילים שכבת מטמון, המורכבת ממכוניות עם דיסקים מקומיים מהירים (SSDs), שעליהם פועלות מכונות פשוטות מ-NGINX, דמוני ה-access.log וה-Python שלה, שמעבדות את כל זה ומנהלות את המטמון.

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

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

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

חלק מהמכונות הללו מחוברות ל-SAN.

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

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

עוד כמה טיפים מהקפטן, פשוטים מאוד.

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

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

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

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

קודם מדדנו את זה, אחר כך שיפרנו את זה.

נוסף. אנו מייעלים קריאה עם מטמון, כתיבה עם ריסוק, אבל זו נקודה ברורה.

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

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

הנקודה הבאה. לגבי שינוי גודל תוך כדי תנועה.

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

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

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

וגיבוי אסינכרוני מצטבר הוא טוב.

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

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

צור קשר

» bo0rsh201
» בלוג Badoo

דוח זה הוא תמליל של אחד הנאומים הטובים ביותר בכנס של מפתחי מערכות עומס גבוה HighLoad ++. נותר פחות מחודש עד לכנס HighLoad++ 2017.

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

השנה אנחנו ממשיכים לחקור את הנושא של ארכיטקטורות וקנה מידה:

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

אנו גם משתמשים בחלק מהחומרים הללו בקורס ההכשרה המקוון שלנו על פיתוח מערכות עומס גבוה HighLoad.Guide היא שרשרת של מכתבים, מאמרים, חומרים, סרטונים שנבחרו במיוחד. ספר הלימוד שלנו כבר מכיל יותר מ-30 חומרים ייחודיים. לְחַבֵּר!

מקור: www.habr.com