Load אינו אויב - Spikes כן

אחרי שדיברנו על Timeouts ועל Retries, קל לחשוב שהאויב המרכזי של מערכות הוא עומס.

יותר מדי בקשות. יותר מדי משתמשים. יותר מדי עבודה.

אבל זו טעות נפוצה.

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

עומס קבוע הוא מצב שניתן לתכנן אליו

עומס יציב, גם אם הוא גבוה:

• ניתן למדידה
• ניתן לחיזוי
• וניתן לאופטימיזציה

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

• לכוונן תורים
• להקצות משאבים
• ולהתאים קצבים

גם אם היא קרובה לגבול - ההתנהגות שלה צפויה.

Spikes שוברים הנחות

Spike הוא שינוי חד:

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

הבעיה אינה הכמות - אלא הקצב.

Spikes פוגעים בדיוק בנקודות שבהן המערכת נשענת על הנחות:

• שתורים יתרוקנו
• ש-Latency יישאר בטווח סביר
• ש-Timeouts “יספיקו”

וברגע שההנחות נשברות - כל המנגנונים שדיברנו עליהם מתחילים להגיב בצורה לא ליניארית.

Burstiness: למה ממוצעים שוב משקרים

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

גם אם הממוצע נראה סביר - המערכת חווה רגעים קיצוניים.

ברגע של burst:

• תורים מתמלאים בבת אחת
• Latency קופץ
• Timeouts מופעלים
• Retries נכנסים לפעולה

והכול קורה לפני שהמערכת “מבינה” שמשהו השתנה.

למה “יש לנו מספיק capacity” לא מספיק

זה אחד המשפטים המסוכנים בפרודקשן.

Capacity נמדדת בדרך כלל:

• בממוצע
• בתנאים רגועים
• ובהנחה של קצבים יציבים

אבל spike אינו בודק capacity - הוא בודק זמני תגובה תחת לחץ.

אם המערכת אינה מסוגלת:

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

ה-capacity התאורטי לא יציל אותה.

המשל

אפשר לחשוב על מסעדה.

אם מגיעים 100 אנשים לאורך ערב - המערכת עובדת.

אם 100 אנשים נכנסים בבת אחת - גם מסעדה גדולה תקרוס.

המטבח לא השתנה. הקצב כן.

Load כבעיה דינמית, לא סטטית

מערכת בוגרת אינה שואלת: “בכמה בקשות אנחנו יכולים לטפל?”

אלא:

• כמה מהר אנחנו יכולים להגיב לשינוי
• איך אנחנו סופגים גלים
• ואיפה אנחנו בולמים לחץ

Load אינו מספר. הוא התנהגות לאורך זמן.

מבט קדימה

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

היכולת לומר: לא עכשיו.

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