איך שרדנו את העלייה בעומס העבודה של x10 מרחוק ואילו מסקנות הסקנו

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

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

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

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

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

עבד במוכנות לחימה מלאה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ארגון ניטור של תקינות שירותי השותפים

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

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

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

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

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

לפעמים מתברר שכןצריך עוד זהב"(ג) לא עוזר

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

במקום העלייה הצפויה בביצועים, השרת פשוט "מת". זה מיד נטען ב-100% והגיב אפילו לאט יותר. בתחילה, היו לנו 2 ליבות ו-2 GB של זיכרון RAM. החלטנו לעשות מה שבדרך כלל עוזר - נתנו לשרת 8 ליבות ו-32 גיגה-בייט. הכל נעשה הרבה יותר גרוע (נספר לכם בדיוק איך ולמה בפוסט נפרד). 

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

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

חסר מדינה הוא המפתח לשינוי קנה מידה אופקי פשוט

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

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

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

7 עקרונות לצמיחה אינטנסיבית

למרות הזמינות של קיבולת נוספת, בתהליך הצמיחה דרכנו על כמה מגרפות. במהלך תקופה זו גדל מספר ההזמנות ביותר מפי 4. כעת אנו כבר מספקים יותר מ-17 הזמנות ביום ב-000 ערים ומתכננים להרחיב עוד יותר את הגיאוגרפיה - במחצית הראשונה של 62, השירות צפוי להיות מושק ברחבי רוסיה. על מנת להתמודד עם עומס העבודה ההולך וגובר, תוך התחשבות במהמורות שכבר מלאות, הפקנו לעצמנו 2020 עקרונות בסיסיים לעבודה בסביבה של צמיחה מתמדת:

1. ניהול אירוע. יצרנו לוח בג'ירה, שבו כל אירוע בא לידי ביטוי בצורת כרטיס. זה יעזור לך לתעדף ולהשלים משימות הקשורות לאירועים. אכן, בעצם, זה לא נורא לטעות – נורא לטעות פעמיים באותה הזדמנות. לאותם מקרים שבהם מקרים חוזרים לפני שניתן לתקן את הסיבה, יש להכין הנחיות לפעולה, כי בזמן עומס כבד חשוב להגיב במהירות הבזק.
2. ניטור נדרש עבור כל מרכיבי התשתית ללא יוצא מן הכלל. בזכותו הצלחנו לחזות את גדילת העומס ולבחור נכון את "צווארי הבקבוק" לתעדוף חיסול. סביר להניח, תחת עומס גבוה, כל מה שאפילו לא חשבת עליו ישבר או יתחיל להאט. לכן, עדיף ליצור התראות חדשות מיד לאחר תחילת האירועים הראשונים על מנת לעקוב ולצפות אותם.
3. התראות נכונות רק צריך עם עלייה חדה בעומס. ראשית, עליהם לדווח בדיוק מה נשבר. שנית, לא צריכות להיות הרבה התראות, כי שפע ההתראות הלא קריטיות מוביל להתעלמות מכל ההתראות באופן כללי.
4. בקשות חייבות להיות חסרות אזרחות. הקפדנו שלא יהיו חריגים לכלל זה. אתה צריך עצמאות מלאה מסביבת זמן הריצה. לשם כך, ניתן לאחסן נתונים משותפים במסד נתונים או, למשל, ישירות ב-S3. עדיף, פעל לפי הכללים. https://12factor.net. במהלך עלייה חדה בזמן, פשוט אין דרך לייעל את הקוד, ותצטרכו להתמודד עם העומס על ידי הגדלת משאבי מחשוב ישירה ושינוי קנה מידה אופקי.
5. מכסות וביצועים של שירותים חיצוניים. עם צמיחה מהירה, הבעיה עלולה להתעורר לא רק בתשתית שלך, אלא גם בשירות חיצוני. הדבר הכי מעצבן זה כשזה קורה לא בגלל כישלון, אלא בגלל הגעה למכסות או מגבלות. אז שירותים חיצוניים צריכים להתאים כמו אתה עצמך. 
6. הפרדת תהליכים ותורים. זה עוזר מאוד כאשר מתרחש תקע באחד השערים. לא היינו נתקלים בעיכובים בהעברת הנתונים אם התורים המלאים לשליחת SMS לא היו מפריעים לחילופי הודעות בין מערכות מידע. ויהיה קל יותר להגדיל את מספר העובדים אם יעבדו בנפרד.
7. מציאות פיננסית. כשיש גידול נפיץ בתזרימי הנתונים, אין זמן לחשוב על תעריפים ומנויים. אבל חייבים לזכור אותם, במיוחד אם אתם חברה קטנה. חשבון גדול יכול להיות מוגדר על ידי הבעלים של כל API, כמו גם ספק האירוח שלך. אז קרא בעיון את החוזים.

מסקנה

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

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

רק משתמשים רשומים יכולים להשתתף בסקר. להתחברבבקשה.

האם אי פעם הייתה לך האטה/ירידה בשירות עקב עלייה חדה בעומס עקב:

• 55,6%חוסר יכולת להוסיף במהירות משאבי מחשוב10

• 16,7%מגבלות תשתית של ספקי אירוח3

• 33,3%מגבלות API6 של צד שלישי

• 27,8%הפרות של עקרונות חסרי אזרחות יישומים שלהם5

• 88,9%קוד לא אופטימלי של שירותים משלו16

18 משתמשים הצביעו. 6 משתמשים נמנעו.

מקור: www.habr.com