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

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

אז אחרי האזהרות, הגיע הזמן לצלול פנימה

מה הקשר בין תורת האילוצים לארכיטקטורת מערכות תוכנה?
על פי תורת האילוצים מעטפת הביצועים של מערכת נקבעת  על ידיד סט של אילוצים שחוסם אותה לבצע את הדברים טוב יותר. אבל, לא כל האילוצים שווים, ובכל נקודת זמן רק אחד מהאילוצים באמת אפקטיבי וחוסם את המערכת מלהשיג את היעדים שלה. לדוגמה, אם אנשי המכירות שלכם לא יכולים למכור את המערכת לארגונים עם מעל 20,000 משתמשים בגלל בעיית ביצועים במערכת, תצטרכו לטפל בסוגיה זו. בהנחה שלאחר השיפור קיבולת המערכת תעלה ל - 40,000 משתמשים,  יתכן שתגלו שארגונים עם מעל ל - 25,000 משתמשים נדרשים לתמיכה ברגולציה ייחודית. כמובן שבמצב זה תדרשו לתמוך ברגולציה הנ"ל, וכל תוספת נוספת לקיבולת המשתמשים למערכת לא תהיה אפקטיבית ולא תגרום לעליה במכירות.
לכן תכנון הארכיטקטורה שלכם צריך להבנות על האילוצים שלכם. בשלב הראשון המטרה תהיה להביא מוצר עובד לשוק באמצעים מוגבלים על מנת שהוא יעמוד בדרישות ה - POC (רמז, מומלץ להגדיר מה הן מראש). אם ה - POC לא דורש תמיכה מיידית במספר משתמשים גבוה, התמקדות בנושא בתחילת הפיתוח, עשויה לפגוע בהסרת האילוץ הראשון בחיי החברה: עמידה ב - POC וביצוע ולידציה עסקית למוצר.

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

כמה טיפים מרכזים לארכיטקטורה בריאה יותר:

טיפ 1: שמרו על פשטות
מחבר הנסיך הקטן Antoine de Saint-Exupery ניסח את זה בצורה הטובה ביותר: "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away". לכן אם לוקח לכם יותר מחמש דקות להסביר את הארכיטקטורה שאפיינתם, אז כנראה שאתם צריכים לקחת אותה לסיבוב נוסף על שולחן השרטוטים. רק אחרי שתורידו את כל ההכנות למזגן, תוכלו להרגיש שהוצאתם מתחת לידיכם עבודה מושלמת.

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

1. אין (כמעט) דבר יותר נורא משאילתא שמבצעת Join בין 5 טבלאות מלאות נתונים.
2. אם יש לכם 5 טבלאות עם מפתח ותיאור בלבד, לא רצוי להפוך אותם לטבלה אחת (למרות שלכאורה מבחינה מבנית הן זהות לחלוטין), וזאת מכיוון שאת המחיר תשלמו בזמן האמת.
3. בסיסי נתונים לא אוהבים קבצים, וקבצים גדולים בפרט. לכן הימנעו מלשמור תמונות או Serialization של המחלקה בתוך שדה יעודי.
4. ריבוי שאילתות מסובכות יגרמו בסופו של דבר לתקיעת המערכת (ככלל, עדיף מספר שאילתות פשוטות מאשר שאילתא מסובכת אחת שאתם מניחים שבסיס הנתונים יצליח להתמודד איתה).
5. ריבוי/חוסר באינדקסים עשוי לגרום לאתגרים מעניינים בעת עדכון, הוספה ושליפת נתונים.

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

טיפ 3: אולי אתם לא באמת צריכים בסיס נתונים
אחת הטכנולוגיות האהובות ע"י מהנדסי תוכנה היא ORM: Object-relational mapping. טכנולוגיה זו מאפשרת למפות ישירות ובאופן אוטומטי בין מבנה הנתונים בזיכרון (Classes) לבין הדיסק (בד"כ בסיס הנתונים). היכולת כמעט באופן אוטומטי לבצע Persistency לדיסק מאפשרת לחסוך זמן רב בפיתוח ולעיתים אף להפטר מהנטל של ה - DBA. כפי שהבנתם בפסקה הקודמת, הכיוון הזה עלול להיות מסוכן, כיוון שמבנה הטבלאות שלכם בבסיס הנתונים יהיה דומה באופן מחשיד למבנה המחלקות שלכם, וזה כאמור לא בהכרח רעיון חיובי.
אבל, אם המטרה שלכם היא אך ורק לשמור את המידע בדיסק ולשלוף אותו באותה צורה הרי ORM יהיה פתרון מצוין. מצד שני במקרה שכזה שימוש בבסיס נתונים לא יהיה בריא. איך יוצאים מהפלונטר? הבשורה החיובית היא שיתכן שאתם כלל לא צריכים את בסיס הנתונים. במקרה כזה הפתרון הנכון ביותר יהיה לבצע Serialize למידע והפיכתו לקובץ בפורמט JSON לדוגמה ושמירתו על הדיסק. מכיוון ששמירה על הדיסק ישירות היא לא בהכרח סימפטית, פתרון שמירת מידע ממשפחת ה - NoSQL יבוא לעזרתכם. מוצרים אלו שומרים את הנתונים לפי מבנה של Key/Value Store, כאשר ה - Key במקרה זה יכול להיות המפתח המזהה של רשומת המידע, והערך יהיה ה - Serialization של הנתונים.

טיפ 4: בחרו טכנולוגיה
הטכנולוגיה המתאימה ביותר לפיתוח היא הטכנולוגיה שאתם מכירים טוב ושקבוצת הפיתוח שלכם מרגישה איתה בנוח (כמובן בתנאי שאתם לא הולכים לפתח את הפייסבוק החדש ב - PowerBuilder). כל עוד הטכנולוגיה היא סבירה ונמצאת בשימוש ע"י קבוצות מקבילות (בארץ ו/או בחו"ל), סביר מאוד שתצליחו לעמוד ביעדי הפיתוח. בעתיד כאשר תזהו צורך להתייעל בעלויות רישוי התוכנה ו/או להפחית את מספר השרתים תוכלו להתמקד באותם רכיבים במערכת שאחראים למרב העלות (בדיוק על פי עקרונות תורת האילוצים). סביר להניח, שבמקרים כאלו תגלו שאחוז קטן מאוד משורות הקוד אחראי לרב הוצאות המערכת. טיפול נקודתי בקוד זה יאפשר לכם לעשות קפיצת מדרגה. מניסיון העבר, במרב המקרים מדובר על שינוי של פחות מאחוז מקוד המערכת שעשוי לגרום לירידה של למעלה מ - 90% מהעלויות וזמן הריצה.

טיפ 5: התכוננו ל - Scale Out
מערכות התוכנה המודרניות חייבות לתמוך בריבוי משתמשים וריבוי תהליכים. למעשה גם השרת הפשוט ביותר שתקנו היום מכיל בתוכו מספר מעבדים (הקרויים בשם העממי Cores). לכן אם הארכיטקטורה שלכם בנויה על תהליכים שרצים לאורך זמן ארוך בצורה טורית ואי אפשר למקבל אותם, אתם צריכים לבחון ולראות האם אפשר לשנות את התהליך. זאת מכיוון שאורך זמן הריצה של התהליכים יהיה על פי רב ביחס ישר למספר המשתמשים וגודל המידע שמאוחסן במערכת. לכן ככל שהמידע והשימוש במערכת יגדל, התוצאה תהיה התמשכות התהליכים, אי הבאת נתונים בזמן ו/או פגיעה בתהליכים אחרים.

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

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

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

טיפ 8: הפרידו בין Offline ו - Online
אחד המאפיינים החשובים במערכות כיום הינו הצורך לתת זמינות של כמעט 100% לרכיבים שאוספים מידע מהמשתמשים או מגישים אותו (לדוגמה הגשת פרסומות או הצגת עמוד השער באתר חדשות גדול, או ביצוע פעולת החיוב בכרטיס האשראי), לבין תהליכים שאפשר להתפשר על זמינותם (לדוגמה קליטת פרסומות חדשות למערכת, עדכון ידיעות או בדיקת הונאות במקרה של סכומים קטנים). במקרים כאלו רצוי מאוד להפריד את המערכת לשני חלקים:

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

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

טיפ 9: רכשו חיסון כנגד וירוס ה - NIH
מחלת ה - Not Invented Here (או בעברית "המצאת הגלגל מחדש") היא אחת מהמחלות הקשות ביותר שחברת תוכנה יכולה לחלות בה. אם אתם לא מסוגלים להשתמש במוצרי מדף קיימים או בקוד שמצאתם באינטרנט אלא חייבים לשנות הכול ולפתח הכול מאפס, יש סיכוי טוב שתתקשו להגיע ליעד. התסמונת הזאת קטלנית במיוחד במקרים שבהם אנחנו מתעקשים לפתח Cache או בסיסי נתונים ייעודיים. רכיבים אלו הינם רכיבים רגישים מאוד, והיכולת שלנו לייצר אי אחידות במידע או נעילות במקומות לא רצויים יכולה לגרום נזק גדול יותר למערכת מאשר אי השימוש בהם (אלא אם אתם פייסבוק ומחזיקים אלפי שרתי MySQL וצריכים פתרון NoSQL). לכן המלצתי, אם אתם צריכים לעשות שימוש ב - Cache ואחסון מידע, השתמשו בהם כשצריך ועל בסיס מוצרי מדף (לשם הבהרה, גם קוד פתוח זה מוצר מדף).

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

מסכימים? לא מסכימים? יש לכם טיפ מנצח? אשמח אם תשתפו את כולנו

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

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

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