הגדרת בדיקות עומס לתשתית באמצעות k6 במפתח סופי

בדיקות עומס עם k6: היכן הפרודקשן נשבר

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

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

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

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

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

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

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

מה נותן תרחיש הרצה לפני שחרור

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

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

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

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

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

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

פרופילי עומס: קבוע, מדורג, שיא

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

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

פרופיל שיא מדמה פרץ חד: מבצע מכירות, תפוצת דיוור, פתיחת הרשמה — בודקים אם המערכת תשרוד את הקפיצה וכמה מהר תחזור לשגרה אחריה.

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

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

כיצד אנו מיישמים בדיקות עומס k6

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

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

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

1. ביקורת ארכיטקטורה ונקודות כשל. מנתחים את תרשים השירותים, התורים, המגבלות והאינטגרציות החיצוניות. מתעדים מה בדיוק בודקים ואילו מדדים נלקחים.
2. יעדי עומס. מתאמים פרופיל: תעבורה שיאית, משך, התנהגות בעת כשלים. זהו הבסיס לקריטריוני קבלה, ולא "צריך לעמוד בזה" מופשט.
3. הגדרת תרחישים. מתארים נתיבי משתמש כתרחישים עם פרופילי עומס שונים — גידול הדרגתי, מדרגות, שיא חד. את הפרמטרים מוציאים לקונפיגורציה, כדי לשנותם ללא עריכת קוד.
4. הכנת סביבה ונתונים. פורסים סביבה הקרובה לפרודקשן, מכינים נתוני בדיקה ובידוד ממשתמשים אמיתיים. אחרת המדידות מציגות לא את כוח המערכת, אלא את התנהגותה על מסד נתונים ריק.
5. הרצה ובדיקת תוצאות. לוקחים מדדים של זמן תגובה, שיעור שגיאות ותפוקה, ומשווים ליעדים. מאתרים צווארי בקבוק — שאילתות איטיות, חוסר במשאבים, הגדרות שגויות.
6. תיקון והרצה חוזרת. לאחר התיקונים חוזרים על אותם תרחישים ומשווים למדידות קודמות. כך רואים מה בדיוק הביא לאפקט ומה לא.
7. העברה לצוות. מוסרים תרחישים, קונפיגורציות, נוהל הרצה וניתוח תוצאות. המהנדסים שלכם מריצים את הבדיקות בעצמם בהמשך — לפני שחרורים ואחרי שינויים.

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

תרחישים, ספים ודוחות: מה נשאר אצלכם

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

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

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

מקרה בוחן: כיצד השירות הפסיק ליפול תחת עומס שיא

מה היה לפני

השירות — אזור אישי עם תשלום והיסטוריית הזמנות — עבד ביציבות בעומס בינוני ונפל באופן צפוי ברגעי מבצעים. התסמינים חזרו על עצמם: זמן התגובה לביצוע הזמנה עלה מ-400 מ"ש ל-6-8 שניות, שיעור שגיאות 5xx עלה ל-12-15%, וחלק מהסלים אבדו בשלב אישור התשלום.

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

מה שינו

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

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

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

מה התוצאה

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

ניתוח עומס דומה עשינו עבור שירות משלוחים על k6: שם, לאחר העברת פעולות כבדות מחוץ לבקשה, זמן התגובה בשיא ירד מ-5 שניות ל-600 מ"ש, ושיעור השגיאות — מ-9% לשברי אחוז.

במה שונה הרצת תרחיש מניטור

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

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

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

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

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

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

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

שאלות שנשאלות לפני ההתחלה

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

כיצד מופרדות הסביבות כך שהבדיקות לא יפריעו זו לזו ולפיתוח?

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

יש לנו כבר תרחישים בכלי אחר — האם נצטרך לכתוב אותם מחדש?

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

מה יקרה עם ההרשאות והנתונים שתקבלו?

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

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

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

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

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

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

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