תשעה עקרונות לארכיטקטורה טובה יותר

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

צילום: flickr, cc-by, Robert Scoble

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

האם הארכיטקטורה באמת קובעת?

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

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

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

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

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

ובכל זאת?

צילום: flickr, cc-by, DigitalAlan

העולם העסקי והטכנולוגי מאיצים כל הזמן. אם בעבר התרגלנו שזמן החדירה של טכנולוגיה לשוק ארך עשרות שנים (לטלפון לקח כ-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: אולי אתם לא באמת צריכים בסיס נתונים

צילום: flickr, cc-by, swanksalot

אחת הטכנולוגיות האהובות ע”י מהנדסי תוכנה היא 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% לרכיבים שאוספים מידע מהמשתמשים או מגישים אותו (לדוגמה הגשת פרסומות או הצגת עמוד השער באתר חדשות גדול, או ביצוע פעולת החיוב בכרטיס האשראי), לבין תהליכים שאפשר להתפשר על זמינותם (לדוגמה קליטת פרסומות חדשות למערכת, עדכון ידיעות או בדיקת הונאות במקרה של סכומים קטנים). במקרים כאלו רצוי מאוד להפריד את המערכת לשני חלקים:

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

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

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

טיפ 9: רכשו חיסון כנגד וירוס ה-NIH

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

השורה התחתונה

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

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

הפוסט פורסם לראשונה בבלוג הפתוח למנהל הפיתוח

Avatar

משה קפלן

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

הגב

10 תגובות על "תשעה עקרונות לארכיטקטורה טובה יותר"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 

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

סידור לפי:   חדש | ישן | הכי מדורגים
יוסי
Guest

“עדיף מספר שאילתות פשוטות מאשר שאילתא מסובכת אחת” – להפך.
אחד החלקים היקרים ביותר בעבודה עם מסד נתונים (שהוא לא embedded) הוא העברת הנתונים הלוך וחזור בין שרת האפליקציה לשרת ה-DB.
בניית שאילתא אחת שמביאה בדיוק את הנתונים שאתה צריך היא האפשרות הטובה יותר, אבל בהחלט צריך לוודא שהשאילתא בנויה נכון כך שהיא אינה משכפלת מידע וכן רצה על אינדקסים.
כשמדובר בDB מודרני, קרוב לודאי שהמערכת תבצע אופטימזציה טובה יותר לפירוק השאילתא מהתוכניתן.

משה קפלן
Guest
שלום יוסי, אני שמח שהעלת את הנושא. אתה בהחלט מאשש את ההמלצה שלי. לזמן והעברת הנתונים בין השרת לבין בסיס הנתונים אין כמעט משמעות במערכות מודרניות שבהן יש ריבוי שרתי אפליקציה והתהליכים מבוצעים במקביל. ההנחה ש “ה – Database כבר יסתדר עם זה” היא בעייתית מאוד ונגמרת פעמים רבות בבעיות ביצועים בצוואר הבקבוק הראשי של המערכת שלהם (וזה כמעט תמיד בסיס הנתונים). בכל מקרה לנושא פירוק השאילתא ע”י תוכניתן, בדיוק בזה עוסק טיפ מספר 1: תחזיקו אצלכם מישהו בפיתוח שידע לעזור לאלו שפחות מכירים בסיסי נתונים. לצערי הטיפ הזה נכתב בדם כמו שאומרים בצה”ל ואני יכול להציג מספר דוגמאות שחור… Read more »
יוסי
Guest
משה, סביר מאוד שיש לי יותר ניסיון בפיתוח מערכות מסוג זה מאשר לך, ובזמן שאני מסכים שחשוב שבנאדם שמבין מסדי נתונים יעבור על הסכמה ועל השאילתות, אני מבטיח לך שהדוגמאות שיש לך הן דוגמאות של תכנון גרוע. עושה רושם שאתה מרגיש יותר בנוח עם כתיבת קוד בשפת תכנות פרוצדורלית מאשר עם SQL, ולכן נראה לך שזה יותר פשוט ויותר יעיל, אבל זה פשוט לא נכון כשמדובר בהבאת נתונים (להבדיל מביצוע לוגיקות כבדות). הטענה שהעברת הנתונים היא זניחה היא מגוכחת. כמות ה low-level קוד שמתבצע היא עצומה, וconnections שיכלו לשתחרר נשארים תפוסים. אם אתה רוצה הוכחה, נסה את הדבר הבא –… Read more »
משה קפלן
Guest

שלום יוסי,

אני ממליץ שתעבור על הטיפ עוד פעם. הטיפ לא דיבר כלל על שליפה של טבלאות שלמות ועיבוד שלהן בזיכרון (מה שמאוד לא מומלץ), אלא על שאילתות מסובכות (ולמהנדסי תוכנה יש נטייה לעשות אותם) הכוללות ריבוי Joins, מקוננות שלא לצורך וכו’.

בכל מקרה, נהניתי ללמוד מהניסיון שלך, אני מקווה שלמדת משהו מהניסיון המועט שלי :-)

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

יוסי
Guest
כמו שכתבתי, הדוגמאות לא באו לייצג מקרים אמיתיים, אלא להראות בבדיקת ביצועים שהלוך-חזור בין ה DB לבין שרת האפליקציה הוא יקר. אם המתכנת צריך לבחור בין שאילתה של 5 joins שמחזירה בעיקר את נתוני הטבלה האחרונה (ללא הכפלת נתונים), לבין חמש שאילתות נפרדות לחמש טבלאות נפרדות, שכל אחת מהן מחזירה מידע שמיועד להיות פרמטר לשאילתא הבאה, הגירסא עם חמש הjoins תיתן ביצועים טובים בהרבה, וגם תחסוך קוד מיותר (והזדמנות לבאגים). ברור שבכל מקרה, הקשרים בין הטבלאות צריכים להיות דרך אינדקסים, אחרת הביצועים יהיו רכים בשתי השיטות. רוב מסדי הנתונים ייצרו אינדקס על foriegn key באופן אוטומטי, כך שתכנון טוב של… Read more »
משה קפלן
Guest

שלום יוסי,

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

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

נ”ב לשם גילוי נאות: ייעצתי ואני מייעץ למספר חברות על ארכיטקטורה של בסיס הנתונים (כולל לוגיקה ופיזיקה והשתלבות במערכת) ויש לי 16 שנה של ניסיון עם “היצורים” הללו אתה יכול להניח שאני מרגיש די בנוח עם SQL.

דן
Guest

פוסט מצויין.
כמו גם הפוסטים הקודמים.

תודה.
דן

משה קפלן
Guest

תודה דן!

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

רותם
Guest

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

למרות זאת כול מקרה צריך לבדוק לגופו של עניין בעזרת SQL EXECUTION PLAN או CLIENT STATISTICS שיעזרו לבחור את הפתרון הנכון.

ממשיכים להתווכח :-)
רותם

משה קפלן
Guest

היי רותם,

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

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

wpDiscuz

תגיות לכתבה: