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

23 באפריל 2012


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


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


אם נוסיף על כך את נטיית השיווק לשלב מאפייני Social באתרים ולייצר קמפיינים משולבי Offline ו – Online (כדוגמת קמפיין המסלולים של ישראכרט), אנחנו יכולים לגלות שגם האתר התמים של אתמול הופך לפוטנציאל לבעיות ביצועים. והרי אף אחד מאיתנו לא רוצה להגיע לעמוד הראשון בעיתון ב Ynet, TheMarker ו – BizPortal… (יכול שאתם רוצים אבל לא בנסיבות הללו).


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


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


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


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



יש! יש לנו צורך עסקי. מה עושים?
קודם כל מזל טוב!


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


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


עדיין חושבים שזה בלתי אפשרי? אינסטגרם עשו זה ב – 160 קמ"ש…


Mike Krieger, Instagram at the Airbnb tech talk, on Scaling Instagram



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



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

  2. מהם התהליכים העסקיים במערכת ומה רמת אינטסיביות השימוש בכל אחד מהם? ברב המערכות ישנם תהליכים עסקיים שקורים פעמים ספורות וכאלו שאחראים ל – 99% מהפעולות במערכת (לדוגמה במערכת לניהול משכנתאות, פתיחת תיק משכנתא מתבצעת פעם אחת ואילו הגבייה מתבצעת מדי חודש בחודשו). מניסיוני ההתפלגות קיצונית בהרבה מפארטו (80/20).

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


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



  1. זיהוי והגדרת הסף הקריטי לכל רכיב במערכת: הדרך הטובה ביותר היא בניית בדיקת עומסים לכל רכיב קריטי שתוודא לפני מסירה של כל גרסה שהרכיב יכול להתמודד עם העומסים הרלוונטים. אזהרה! אם המערכת לא מורכבת מסדרה של רכיבים בדידים, היכולת לבצע בדיקת עומסים אפקטיבית היא כמעט ובלתי אפשרית. אם אין לכם אפשרות לבנות בדיקת עומסים אפקטיבית, תדרשו לנטר בזהירות את צריכת המשאבים של המערכת ולזהות מאפיינים כמו תעבורת רשת, צריכת I/O, CPU וזיכרון ולזהות מתאם ביניהם לבין הפעילות במערכת (לדוגמה אם כל משתמש מחייב 0.5MB RAM, כנראה ששרת של 2GB יוכל לתמוך לכל היותר ב – 4,000  משתמשים).

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

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


עשיתם את זה? שברתם את מחסום הביצועים? ישמתם מערכת ניטור שאפשרה לכם לזהות ולהתגבר על הבעיות הקרבות? רוצים לשתף אותנו? אתם יותר ממוזמנים…


נהנית מהפוסט? רישום לבלוג הפתוח למנהל הפיתוח יבטיח לכם עדכונים חדשים ישירות לדוא"ל!


ממשיכים לפתח,
משה קפלן


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


נ"ב אם נתקלתם בבעיית SEO באתר מבוסס AJAX (כולל שימוש ב – Widgets של ספקים חיצוניים), אני אשמח אם תיצרו איתי קשר.


הוסף תגובה
facebook linkedin twitter email

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *