תומר לב, ארכיטקט דאטה ומנכ"ל DATASITE 

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

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

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

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

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

כיצד מזהים את הבעיות ומה ניתן לעשות?

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

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

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