מעקב שמאלי עבור יישומים ענן במכלאות

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

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

הצהרת הבעיה

I would like to demonstrate to you a case where we managed to avert a potential issue with an application that could have caused a major issue in a production environment. 

I was reviewing the performance report of the UAT infrastructure following the recent application change. It was a Spring Boot microservice with MariaDB as the backend, running behind Apache reverse proxy and AWS application load balancer. The new feature was successfully integrated, and all UAT test cases are passed. However, I noticed the performance charts in the MariaDB performance dashboard deviated from pre-deployment patterns.

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

ב-6 באוגוסט בשעה 14:13, האפליקציה הופעלה מחדש עם קובץ jar חדש של Spring Boot המכיל Tomcat משובץ.

בשעה 14:52, קצב עיבוד השאילתות עבור MariaDB עלה מ-0.1 ל-88 שאילתות לשנייה ואז ל-301 שאילתות לשנייה.

בנוסף, רמת ה-CPU של המערכת עלתה מ-1% ל-6%.

לבסוף, זמן ה-JVM שמשקלל באספקת הזבל של G1 בגיל צעיר קבלן הזבל עלה מ-0% ל-0.1% ונשאר ברמה זו.

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

פתרון הבעיה

זהו יישום Spring Boot המשתמש ב-JPA לשאילת MariaDB. היישום מתוכנן לרוץ על שני מכלים לשם הטיפוס המינימלי אך צפוי להתרחב עד עשרה. 

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

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

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

List<X> findAll = this.xRepository.findAll();

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

הבדיקה התבצעה רק באמצעות 2,000 רשומות במכונה אחת. אם הקוד היה עובר לייצור, שם ישנם כ-200,000 רשומות בעד 10 מכונות, זה היה יכול לגרום לצוות הרבה דאגה וחרדה באותו יום. 

היישום נבנה מחדש עם הוספת פעולת WHERE לשיטה.

List<X> findAll = this.xRepository.findAllByY(Y);

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

למידה וסיכום

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

יש שלוש הישגים עיקריים מהסיפור הזה.

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

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

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