בקצרה
אתר מסחר מקוון (eCommerce) חדש, על תשתית חדשה, לפני עלייה לאוויר. אין היסטוריה, אין נתוני עבר, אין למה להשוות. בדיקת עומסים חשפה צוואר בקבוק שאף כלי ניטור לא היה מראה בזמן אמת: 40 גיגה־ביט לשנייה של תעבורה בין שרתי האפליקציה לשרת ה־Cache תקרת הרשת של המכונה.
שלושה שינויים, בסדר שהתברר כקריטי, הורידו את המספר ל־300 מגה־ביט. אותו קוד, אותה חומרה, פי 130 פחות תעבורה. וכל זה קרה לפני שגולש אמיתי אחד נכנס לאתר.
הסיפור מתחיל בשאלה שאין עליה תשובה
אני מניח שרובכם מכירים את הרגע שבו מנהל פרויקט שואל "האתר יחזיק?", ומישהו בחדר עונה "כן, כי בשנה שעברה זה עבד".
הפעם לא הייתה שנה שעברה.
ההקמה שאני מספר עליה כאן הייתה של אתר מסחר מקוון חדש לגמרי, על גבי תשתית חדשה לגמרי. לא מיגרציה, לא שדרוג הקמה מאפס. וזה, מסתבר, המקרה הקשה באמת. כי כשמעבירים אתר קיים יש לכם לפחות נקודת ייחוס אחת: אתם יודעים כמה תעבורה הוא מייצר, אתם יודעים אילו עמודים כבדים, אתם יודעים מה נשבר בעבר. יש היסטוריה, וההיסטוריה היא סוג של מדידה.
באתר חדש על תשתית חדשה אין שום דבר מזה. יש ארכיטקטורה על הנייר, יש שרתים שהוקמו לפני שבועיים, ויש הרבה מאוד הנחות שנשמעות סבירות אבל אף אחת מהן לא נבדקה ולו פעם אחת מול עומס אמיתי.
אז החלטנו לעשות את הדבר היחיד שאפשר לעשות במצב כזה: לא לנחש. להריץ בדיקת עומסים אמיתית על הסביבה, לפני שהאתר עולה לאוויר, ולגלות היכן הוא נשבר כשזה עדיין לא עולה דבר.
האתגר: כשאין למה להשוות, אין גם מה לנטר
וכאן נמצאת הנקודה החשובה ביותר במאמר הזה. אם תיקחו ממנו דבר אחד שיהיה זה.
ניטור עונה על השאלה "מה קורה עכשיו". בדיקת עומסים עונה על שאלה אחרת לגמרי: "מה ייכשל ראשון, ובאיזה מספר". באתר קיים אפשר להתחמק ולהסתמך על ניטור. באתר חדש אין אפילו את זה לוחות המחוונים שלכם מראים תשתית פנויה שאינה עושה דבר, וכל הגרפים ירוקים.
הסיבה שמצב זה מסוכן אינה אינטואיטיבית: עומס אינו מכפיל את הבעיות הוא משנה את סוגן. מערכת שרצה על 10% מהקיבולת מתנהגת אחרת מהותית מאותה מערכת על 90%. בעומס נמוך שורר שקט: תורים מתרוקנים מיד, אין תחרות על נעילות, ורוחב הפס בקושי מנוצל. בעומס גבוה כל אחד מהמנגנונים הללו מתחיל להתנגש בעצמו, ונפתחים ממדי כשל שפשוט לא היו קיימים קודם לכן.
לכן, גם צוות מנוסה שבנה ארכיטקטורה נכונה עלול לפספס לא בגלל טעות, אלא מפני שהמדידה היא הדבר היחיד שיכול לענות על השאלה. את זה לא מנחשים.
ההפתעה הראשונה: הבדיקה נחסמה
נתחיל דווקא בפרט שאיש אינו מתכנן מראש. ברגע שהעומס התחיל לזרום ה־WAF חסם אותו.
וזה הגיוני לחלוטין. עשרות אלפי בקשות בשנייה מכמה כתובות IP זה בדיוק מה שחומת אש אפליקטיבית (WAF) אמורה לעצור. זו אינה תקלה; זו הצלחה של ההגנה אלא שהיא קרתה ברגע הלא נכון.
מה שסייע לנו כאן הוא שאנחנו מנהלים את שכבת ה־WAF בעצמנו. לא היינו צריכים לפתוח קריאת שירות לספק חיצוני, לחכות לזמן תגובה ולתאם חלון לשינוי כלל. הגדרנו חריגה מסודרת זיהוי ייחודי לתעבורת הבדיקה ואימתנו בפועל שהיא אכן פועלת, ולא רק שהיא מוגדרת. הבדיקה חזרה לרוץ תוך דקות, בלי שאיבדנו את יום העבודה.
הלקח כאן אינו טכני אלא ארגוני: בדיקת עומסים אינה רק כלי שמייצר תעבורה היא מבחן לשרשרת השליטה שלכם בתשתית. כל רכיב בדרך שאין לכם עליו שליטה מיידית חומת אש, CDN, מאזן עומסים הוא נקודה שבה הבדיקה עלולה להיעצר ליום שלם. ואם זה מה שקורה בבדיקה מתוכננת, כדאי לחשוב מה יקרה כשתצטרכו לשנות כלל באמצע אירוע אמיתי.
הגילוי: המספר שלא הופיע על שום לוח מחוונים
כשהעומס סוף סוף זרם במלוא עוצמתו, המספר שקפץ לעין לא היה עומס המעבד ולא זמן התגובה של מסד הנתונים. שם דווקא הכול נראה סביר.
הבעיה הייתה במקום שכמעט איש אינו מסתכל עליו: התעבורה בין שרתי האפליקציה לשרת ה־Cache כ־40 גיגה־ביט לשנייה.
וכדי להבין מדוע זה חמור: אין מדובר ב"תעבורה גבוהה" גרידא זו תקרת המכונה. לכל מכונה יש גבול רוחב פס, ובסביבות ענן הגבול הזה נאכף על ידי התשתית עצמה. כשמגיעים אליו, חבילות (packets) מתחילות להיזרק עוד לפני שהן מגיעות למערכת ההפעלה. הזריקות הללו אינן מבחינות בין תעבורה כבדה לתעבורה קריטית גם שאילתות קטנות למסד הנתונים נפגעות, וכל אחת מהן עלולה להמתין לשליחה חוזרת ב־TCP. כמה עשרות עיכובים כאלה בעמוד אחד, והאתר מרגיש שבור לגולש בזמן שכל גרף מדווח שהמערכת "עומדת בעומס".
ומדוע בכלל נוצרת תעבורה כזאת מול Cache? כי Magento שומרת ב־Cache פריטים גדולים: קונפיגורציה, בלוקים של HTML, עמודים שלמים. כל טעינת עמוד מבצעת עשרות ומאות קריאות כאלה, וכשמכפילים במספר הבקשות בשנייה בעומס שיא מקבלים זרם נתונים שעובר על הרשת שוב ושוב. מצאנו שם מפתחות בודדים בגודל של מגה־בייטים, שנקראו אלפי פעמים בשנייה. מפתח אחד כזה מסביר לבדו חלק ניכר מהתעבורה.
נקודה שחשוב לומר במפורש
זוהי בעיה ארכיטקטונית, לא הגדרה שגויה. איש לא שכח דבר. זה בדיוק המקום שבו ארכיטקטורה תקינה לגמרי פוגשת תקרה פיזית ואין דרך לגלות זאת בלי לייצר את העומס בכוונה.
הניסיון הראשון: הפתרון ההגיוני שלא פתר
הצעד הראשון שלנו היה האינטואיטיבי: שדרוג Redis לגרסה 8, כדי לנצל את מנגנון ה־io-threads המשופר. הרעיון נכון כשלעצמו להוציא את עבודת שליחת התשובות הגדולות מה־thread המרכזי אל threads נפרדים שמטפלים בקלט־פלט.
וזה אכן עבד. המערכת התנהגה טוב יותר, בהפרש מורגש. אך היא נותרה על הקצה וכאן הגיע הלקח שהוביל לכל השאר: io-threads אינו מוריד בייט אחד מהרשת. הוא מייעל את אופן השליחה של אותה כמות נתונים בדיוק. אם צוואר הבקבוק שלכם הוא רוחב הפס, שדרוג גרסה קונה לכם מרווח נשימה לא פתרון.
כדאי גם לדעת: הרצת הפקודות עצמן ב־Redis מתבצעת גם בגרסה 8 ב־thread בודד. הוספת threads לא תועיל אם מה שמעמיס הוא פעולות כבדות על מבני נתונים גדולים. במקרים כאלה הפתרון הוא פיצול לכמה מכונות נפרדות, כל אחת עם ה־thread שלה ולא הגדלת מכונה אחת.
אז עצרנו, וניסחנו את השאלה מחדש. וזה, יותר מכל שינוי טכני, מה שפתר את הבעיה.
התפנית: להפסיק להאיץ ולהתחיל להפחית
עד לאותו רגע, כל החשיבה שלנו הייתה "איך מעבירים 40 גיגה־ביט טוב יותר". השאלה הנכונה הייתה אחרת לגמרי: למה בכלל צריך להעביר 40 גיגה־ביט?
התשובה הראשונה הייתה דחיסה. הפעלנו דחיסת נתונים בשכבת ה־Cache HTML ונתונים מובְנים נדחסים ביחס מצוין, בין פי 5 לפי 10. זו שורה בקובץ הגדרות, לא פרויקט פיתוח.
התוצאה: ירידה ל־4 גיגה־ביט לשנייה, והמערכת החזיקה. פי עשרה פחות תעבורה, על אותה חומרה בדיוק.
אבל מעניין יותר מהמספר הוא ההיגיון שמאחוריו. דחיסה אינה מקטינה את כמות העבודה במערכת היא מזיזה אותה. הרשת מתפנה, והמעבדים של שרתי האפליקציה משלמים את המחיר. במקרה שלנו זו בדיוק העסקה הנכונה, כי ל־PHP היה עודף קיבולת מחשובית בעוד הרשת הייתה חסומה לחלוטין.
וזה עיקרון שאפשר ליישם בכל מערכת: אופטימיזציה חכמה אינה "פחות עבודה" היא העברת העבודה למשאב שיש ממנו עודף. כדי לדעת לאיזה משאב, צריך למדוד את כולם בו־זמנית. מי שהסתכל רק על המעבד היה מגיע למסקנה הפוכה.
הרעיון שסגר את הפער: לא להעביר כלל
4 גיגה־ביט לשנייה הוא מצב שעובד, אך לא מצב נוח. אתר חדש צריך מרווח לגדול לתוכו, לא לרוץ ממקום שממנו הוא רק יתקרב לקיר.
אז לקחנו את אותה חשיבה צעד נוסף קדימה. אם דחיסה עונה על "להעביר פחות" למה לא להימנע מההעברה כליל?
Magento תומכת במנגנון שנקרא L2 Cache שכבת Cache דו־רמתית והוא אלגנטי להפליא: כל שרת אפליקציה מחזיק עותק מקומי של הנתונים בזיכרון שלו, ו־Redis נשאר המקור היחיד לאמת. לצד כל פריט נשמרת ב־Redis "טביעת אצבע" זעירה. בכל קריאה, השרת משווה את טביעת האצבע של העותק המקומי שלו לזו שב־Redis: אם הן זהות הוא משתמש בעותק המקומי, ועל הרשת עברו כמה עשרות בייטים במקום מגה־בייט. אם הן שונות או חסרות הוא שולף את הנתון המלא ומעדכן את העותק שלו.
שימו לב לעדינות של הדבר: מספר הפניות ל־Redis כמעט אינו משתנה. רק נפח הנתונים צולל. וכיוון שההשוואה מתבצעת בכל קריאה בודדת, אין כל סיכון להצגת נתון שאינו מעודכן רענון ה־Cache מגיע לכל השרתים בתוך בקשה אחת, בלי לגעת בכל שרת בנפרד.
הפעלנו זאת על חלק מסוגי ה־Cache לא על כולם, וזו בחירה מכוונת והתעבורה צנחה ל־300 מגה־ביט לשנייה.
התעבורה מול שכבת ה־Cache לפי שלבי הטיפול
| מצב | תעבורה | הערה |
|---|---|---|
| מצב פתיחה | 40 Gbps | תקרת רוחב הפס של המכונה. חבילות נזרקות ברמת התשתית. |
| שדרוג Redis 8 + io-threads | ~40 Gbps | התנהגות טובה יותר וזמני תגובה משופרים אפס הפחתה בנפח. |
| הפעלת דחיסה | 4 Gbps | פי 10 פחות. המערכת החזיקה את העומס המתוכנן. |
| הפעלת L2 Cache | 300 Mbps | פי 130 פחות ממצב הפתיחה. מרווח גדילה אמיתי לשנים קדימה. |
מה למדנו
סדר הפעולות שווה יותר מכל פעולה בודדת
שימו לב מה קרה בפועל. שדרוג הגרסה היה הצעד הראשון שלנו כי הוא נשמע כמו "טיפול בשורש" אבל אחרי שהפעלנו דחיסה, הפריטים הענקיים הפכו לפריטים בינוניים, כלומר הבעיה שה־io-threads אמור לפתור התכווצה מאליה. מי שמשדרג ראשון משלם כדי להעביר נתונים מיותרים בצורה יעילה יותר.
הכלל: קודם מפחיתים את כמות העבודה, אחר כך מייעלים את ביצועה. זה נכון לתעבורה, לשאילתות ולכל דבר אחר.
"יותר חומרה" הוא הפתרון היקר והפחות יעיל
אף אחד מהשינויים כאן לא היה הוספת שרתים. שלושה שינויים ברמת התצורה והארכיטקטורה הניבו שיפור של פי 130 שיפור שאין דרך לקנות בכסף אצל שום ספק ענן. ובמקרה הזה הדבר אף משמעותי יותר: מערכת שרצה על 300 מגה־ביט מתוך 40 גיגה־ביט אפשריים יכולה לספוג עומס שיא בלתי צפוי לגמרי. מערכת שרצה על 39 לא.
הזמן הנכון לבדוק הוא לפני שיש מה להפסיד
כל מה שתואר כאן קרה לפני שהאתר עלה לאוויר. אף גולש לא חווה שנייה של איטיות, אף הזמנה לא נפלה, ואיש לא נאלץ לתקן תחת לחץ באמצע אירוע. זה בדיוק הערך של בדיקת עומסים: היא מחליפה תקלה עתידית בשעות עבודה מתוכננות.
ומדדנו אחרי כל שינוי בנפרד. זו הסיבה שאנחנו יכולים לומר בביטחון מה תרם ומה כמעט לא תרם לממד שחיפשנו. בדיקה שמסתיימת ב"הצלחנו לייצר עומס והאתר החזיק" היא הזדמנות שהוחמצה הערך נמצא במחזוריות.
איך נראית בדיקת עומסים שכדאי לעשות
| מה | למה זה קריטי |
|---|---|
| סביבה מקבילה לייצור (Production) | בדיקה על סביבה מצומצמת תמדוד את המגבלות של הסביבה המצומצמת. נפח נתונים, מספר שרתים ותצורת רשת חייבים להיות דומים. |
| שליטה בשכבת ההגנה | WAF, CDN ומאזן עומסים יעצרו את הבדיקה. צריך יכולת להגדיר חריגה ולאמת בפועל שהיא פועלת. |
| תרחיש שדומה לגולש אמיתי | עומס על דף הבית לא ייגע בעגלה, בחיפוש או בסליקה. הכשלים האמיתיים מסתתרים דווקא שם. |
| מדידה בכל השכבות בו־זמנית | מעבד, זיכרון, דיסק, רשת, מסד נתונים, Cache. מי שלא הסתכל על גרף הרשת היה מפספס את כל הסיפור הזה. |
| בסיס מתועד להשוואה | באתר חדש זו גם ההזדמנות ליצור את הבסיס הראשון נקודת הייחוס לכל בדיקה עתידית. |
| עלייה מדורגת עד לכשל | המטרה אינה "לעבור". המטרה היא למצוא את המספר שבו המערכת נשברת, ולדעת אותו מראש. |
ומעל הכול, ובמיוחד בהקמה חדשה: הבדיקה צריכה להתבצע בזמן שעוד יש זמן לתקן. הערך שלה נמצא במרווח שהיא קונה לכם.
קול קורא: מחפשים חברות בדיקות עומסים לשיתופי פעולה
העבודה הזאת חידדה לנו דבר: בדיקת עומסים טובה היא מקצוע בפני עצמו. לתכנן תרחיש שמשקף גולשים אמיתיים, לייצר עומס בקנה מידה משמעותי ממקורות מרובים, ולנתח את התוצאות זהו תחום עומק, והוא שונה מתחום העומק שלנו.
אנחנו ב־SPD מביאים את הצד השני של המשוואה: שליטה מלאה בתשתית כולל שכבת ההגנה יכולת לזהות את צוואר הבקבוק האמיתי מתוך הנתונים, וניסיון מעשי בתיקונו ברמת מסד הנתונים, שכבת ה־Cache, הרשת והארכיטקטורה. השילוב בין בדיקה מקצועית לצוות שיודע לתרגם תוצאות לשינויים בפועל הוא מה שהופך דוח לשיפור מדיד.
אם אתם חברה שמבצעת בדיקות עומסים נשמח להכיר ולעבוד יחד. יש לנו לקוחות בסדר גודל שמצדיק בדיקות כאלה על בסיס קבוע, ואנחנו מעדיפים שותפים מקצועיים על פני אלתור. נכון גם בכיוון ההפוך: אם אתם עובדים עם לקוח שנתקל בתקרה תשתיתית ואין לכם את מי לשאול דברו איתנו.
03-6221258 · או דרך טופס יצירת הקשר באתר. כתבו "שיתוף פעולה בדיקות עומסים" ונחזור אליכם.
שאלות נפוצות
למה לבצע בדיקת עומסים לאתר שעוד לא עלה לאוויר? דווקא אז הדבר קריטי ביותר. באתר קיים יש היסטוריה שמשמשת נקודת ייחוס; בהקמה חדשה אין דבר רק הנחות. בנוסף, זהו החלון היחיד שבו כל תיקון הוא שינוי מתוכנן ולא טיפול בתקלה חיה.
למה לא פשוט להוסיף שרתים לפני העלייה לאוויר? כי זה מועיל רק אם צוואר הבקבוק נמצא בשרתי האפליקציה. במקרה שתואר כאן, הוספת שרתי אפליקציה הייתה מגדילה את התעבורה מול ה־Cache ומחמירה את המצב. ללא מדידה אין דרך לדעת באיזה כיוון להשקיע.
L2 Cache מתאים לכל אתר Magento? הוא מתאים במיוחד לפריסות מרובות שרתים שבהן התעבורה מול ה־Cache היא צוואר בקבוק. בשרת בודד היתרון קטן בהרבה, כי אין רשת לחסוך. יש גם ניואנסים בהגדרה ניהול נפח הזיכרון המקומי ובחירת סוגי ה־Cache להפעלה ולכן אין מומלץ להפעיל זאת ללא מדידה לפני ואחרי.
מי צריך להוביל בדיקת עומסים חברת הפיתוח או חברת האירוח? שתיהן, וזו בדיוק הנקודה. הבדיקה מייצרת עומס ברמת האפליקציה, אבל התשובות נמצאות בטלמטריה של התשתית. ללא שיתוף פעולה מתקבל דוח שאומר "היה איטי" מבלי לומר מדוע.
