הכירו את ארכיטקטורת התוכנה נטולת persistency

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

מקור: Pexels

מאת טל צור ויפים קולודיזנר, ארכיטקטורה, חברת NICE

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

פתרונות יקרים לתחזוקה

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

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

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

חוזרים לנקודת ההתחלה הרצויה

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

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

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

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

התאוששות חכמה מניבה תוצאות מיידיות

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

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

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

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

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

הכתבה בחסות NICE

אנו גאים להיות חברת תוכנה ישראלית העומדת בחזית הטכנולוגיה והחדשנות, ומובילה בתחומי ה- Analytics, ה- Cloud וה-Big Data . מוצרי החברה מספקים פתרונות בתחומי ניהול ואופטימיזציה של מרכזי שירות לקוחות ובתחומי מעקב וניטור של תנועות הון חשודות והלבנות הון, ונמצאים בשימוש של יותר מ-25,000 ארגונים, במעל 150 מדינות (לרבות 80 מתוך 100 החברות הגדולות הנכללות ברשימת ה - Fortune 100). לפרטים נוספים לחצו כאן

כתב אורח

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

הגב

6 Comments on "הכירו את ארכיטקטורת התוכנה נטולת persistency"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 
Sort by:   newest | oldest | most voted
מי אני, מה אני?
Guest
מי אני, מה אני?

בהצלחה, לכל הלקוחות שלכם עם המוצר שהם מקבלים….

tata
Guest

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

Tal Tsur
Guest

במערכות גדולות ומורכבות, הצוות המפתח לא תמיד יכול לראות את התמונה המלאה, ולמעשה לא באמת ניתן לצפות לכך.
הגישה העיצובית שמתוארת, מעניקה כיוון חשיבה שונה עבור הצוות המפתח. כאן עיקר כוחה. היא מכוונת למימוש במערכות קיימות שעוברות שכתוב (ההמלצה במקרים כאלה, היא למשל להתחיל באזורים “עצמאיים” תחת אחריות צוות אחד) וכמובן גם במימוש במערכות חדשות. וכל זאת בלי לעשות יותר מדי רעד וזעזועים במערכת הגדולה בתוכה חיים. שיהיה בהצלחה!

ZzZ
Guest

It’s a show about nothing…

מפתח
Guest

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

גלעד
Guest

אין לי מושג מה קראתי כרגע…

wpDiscuz

תגיות לכתבה: