בחלק הקודם, עמדנו על האתגרים בהיבט הפיזי ודרכי ההתמודדות עימם, כאשר המערכת שלנו נדרשת להתרחב ולגדול. בחלק זה נעבור על האתגרים מההיבט החומרתי (Hardware), כאשר יש צורך בגידול של המערכת.
כאשר אנו נדרשים להגדיל את התפוקה של המערכת שלנו, אזי מההיבט החומרתי, זה אומר שנדרש ליותר כוח עיבוד (CPU) , זיכרון נדיף (RAM) ושטח אחסון (Storage) -בכדי לתמוך בדרישות החדשות של המערכת שלנו, כגון תמיכה ביותר משתמשים בו זמנית, שיפור ביצועי המערכת השלנו ואחסון יותר מידע על החומרה.
האתגרים מההיבט החומרתי
נקודות הדורשות זמן וכוח אדם מיומן:
• צורך בביצוע ניתוח מהי החומרה הנדרשת — תהליך זה כולל שיתוף פעולה בין צוותי הפיתוח לצוותי מערכות המידע: יש צורך בניתוח מעמיק מול ארכיטקטורת התוכנה אל מול החומרה שהיא מותקנת עליה, במידה וארכיטקטורת התוכנה תומכת בריבוי מעבדים, אזי נוכל להגדיל את כמות הליבות ובכך להגדיל את כוח העיבוד. לפעולות אלו ישנה תקורה חומרתית וכספית, וככל שנגדיל את מספר המעבדים/ליבות בשרת מסוים, ככה המחיר שלו יעלה בצורה אקספונציאלית עד לתקורה חומרתית של אזור ה-256 מעבדים לשרת.
לדוגמא: שרת עם 128 מעבדים יעלה לנו לא מעט, שרת עם 256 מעבדים יעלה כבר פי כמה מונים, ושרת עם 512 מעבדים שכמעט ולא זמין לשוק המסחרי, יהיה בעל עלויות גבוהות מאוד.
לכן, ניתן לראות שגם אם מערכת התוכנה שלנו תומכת בריבוי מעבדים, היא עדיין תהיה מוגבלת בגידול שלה על גבי שרת אחד עקב חסם גידול חומרתי.
• הכנת מפרט חומרתי נדרש — במידה ויש צורך להגדיל את משאבי החומרה שלנו, אנו נצטרך להכין מפרט מדויק של כמות המעבדים, הזיכרון הנדיף ושטח האחסון אשר נצטרך להתקין. לעיתים, השרת הנוכחי שלנו לא תומך בהגדלת משאבים לכמות שאנו נדרשים אליה, אנו נצטרך לקנות שרת חדש - דבר שלרוב קשה לבצע.
• הכנת תקציב — יש צורך לבצע הצעת רכש בכדי לבדוק מה עלויות החומרה עבור הגדלת המשאבים הנדרשת.
• אישור תקציב — יש צורך לחכות לאישור התקציב, הזמן של אישור התקציב תלוי בגבוה ההוצאות, במידה ואנו בתחום ההוצאות הגידול העתידיות השנתיים התקציב יאושר די מהר, במידה ואנו נדרשים להצעת רכש לא מתוכננת, אישור התקציב עלול לקחת כמה שבועות.
• הזמנת החומרה — הזמנת החומרה היא שלב שיכול לקחת זמן די ארוך, במידה ואין את החומרה שאנו צריכים במלאי. ישנם מצבים שנצטרך לחכות חודשים עד שהיצרן יסיים לייצור אותם, ולעיתים ההזמנה יכולה להתעכב במכס עקב סיבות שונות, כמו חוסר באישור ממשרד התקשורת של החומרה.
• הרכבה והתקנת החומרה – זהו החלק שבו יש צורך באנשי IT שמכירים את החומרה ואת הארכיטקטורה הנדרשת בכדי להתקין את החומרה החדשה בצורה נכונה. לעיתים לתהליך זה יהיה צורך באנשי ה-IT של יצרן החומרה, אשר יצטרכו להגיע לאתר ולהתקין את החומרה החדשה. במידה ויש לנו חומרות מיצרנים שונים, הסיבוכיות עולה מכיוון שיש צורך לתאם מול כמה יצרן וחברות שונות את התקנת החומרה החדשה, לכן, תהליך זה עלול לקחת כמה שבועות וחודשים עד לסיום התקנת החומרה בצורה מוצלחת.
• עדכון תוכנה ובדיקות תקינות –כאשר מתקינים חומרה חדשה, מומלץ ורצוי לבצע עדכוני תוכנה של החומרה, דבר זה נחוץ כדי לעלות את רמת האבטחה של החומרה. צורך נוסף הוא בדיקות התקינות של החומרה בכדי לוודא שהחומרה שקיבלנו והתקנו תואמת למוצר שהזמנו. שלב זה יכול להיות עניין של ימים, במידה ואנו מכירים את החומרה וכבר יש לאנשי ה-IT כלים וניסיון בהתקנה של חומרה מסוג זה.
נקודות כשל קריטיות
• בעיית תאימות תוכנתית — אתגר נוסף הוא שבמידה ונתקין את המערכת שלנו על חומרה חדשה, יתכן שהתוכנה לא תעבוד תקין מכיוון שהיא הייתה מותאמת לעבוד בארכיטקטורה שלX86 או x64, וקוד המקור לא תומך בשניהם. לכן, עלולה להיות בעיית תאימות תוכנתית.
• בדיקות אבטחת מידע של החומרה –אחת החולשות שקיימות היום בשוק, הוא חולשה בשרשרת הייצור של החומרה, מכיוון שהחומרה מורכבת ממספר יצרנים שונים, והמוצר עובר שרשרת ייצור. ישנם מצבים שאחת החוליות בשרשרת הייצור ערכה שינוי בתוכנה/חומרה בזמן שהמוצר היה בדרך אלינו, ולכן יש חשש שהוא עלול להיות מזוהם בתוכנות זדוניות. לנושא זה קיימים מספר פתרונות.
כיום אין פתרון שנותן מענה כולל לכל החומרות, ולכן התקנת חומרה חדשה למעשה מעלה את שטח ההתקפה של המערכת שלנו ועלולה לסכן את אבטחת המידע של הארגון.
• הגדרת החומרה ((Configuration – לאחר התקנת החומרה, יש צורך להגדיר את ההגדרות שלה. רצוי לא להשתמש בהגדרות ברירת המחדל של החומרה, אלא להגדיר את החומרה לצרכים של המוצר.
• התקנת המערכת הקיימת על החומרה החדשה –זהו שלב שעלול להיות נקודת כשל קריטית, במידה ולא ערכנו בדיקת היתכנות שהתוכנה שלנו תצליח לעבוד על החומרה החדשה, אנו עלולים למצוא את עצמנו במצב בעייתי, מכיוון שכל השלבים שהושקעו בהתקנת החומרה החדשה יורדים לטמיון. או שאנו נצטרך להשקיע משאבים להתאים את התוכנה לחומרה החדשה, או שנצטרך להזמין חומרה חדשה, שתי החלופות שמים את הארגון בסיכון.
דרכים להתמודד עם האתגרים
• תכנון מראש – כך ניתן להפחית את זמני התגובה ולצמצם נקודות כשל קריטיות. כאשר נתכנן מראש את המערכת שתהיה בעלת יכולות גידול עצמאית ובלתי תלויה בחומרה ספציפית, אנו נפחית את זמן התהליך של תמיכה בגידול משתמשים. כמובן שקשה לתכנן מראש ויש לעשות איזון בין זמן התכנון לתמורה בפועל - הרי אם נתכנן בצורה יותר מידי מקיפה, אנו יכולים למצוא את עצמנו במשך חודשים ושנים רק בשלב התכנון, ומהצד השני, במידה ולא נתכנן בכלל, אזי ככל הנראה המערכת שלנו תתקשה בגידול בצורה קלה ומהירה.
• פיתוח ושימוש בשפת פיתוח אגנוסטית לחומרה– במידה ואנו בוחרים בשפת תכנות שקוד המקור שלה יכול לרוץ על חומרות שונות מבלי צורך לשנות את קוד המקור, זה יעזור להתגבר על בעיית תאימות של המערכת שלנו לחומרה חדשה. בשפה כמו JAVA לדוגמא, אין צורך לשנות את קוד המקור (במידה ונצטרך להריץ את התוכנה על ארכיטקטורתX86 או x64). גם שפת GO מאפשרת להריץ את אותו קוד מקור על ארכיטקטורות חומרה שונות (יש לציין שJAVA אומנם אגנוסטית לארכיטקטורת החומרה, אך במידה ולא כתבנו קוד בצורה נכונה, יכול להיות שהקוד לא יעבוד תקין על Linux OS. במידה ובקוד המקור שנכתב בWindows כתבנו למשל את נתיב הקובץ בצורה שמערכת ההפעלה וינדוס עובדות ולא כמו שמערכת ההפעלה לינוקס עובדת, במקום להשתמש ב-" File.separator" השתמשנו ב "\\", ולכן קוד זה לא יעבוד על מערכת לינוקס מכיוון שנתיב מפריד בין ספריות הוא “/” .
• כתיבת מערכת מכוונת תהליכים Microservices – במידה ויש לנו אפשרות לתכנן או להסב מערכת קיימת לארכיטקטורת Microservices, זה יכול להוות פתרון. ארכיטקטורה זו תומכת בגידול אופקי (Horizontal scale), דבר המתמודד עם בעיית הגידול האנכית (Vertical scale) שבה קיימת תקורה של גידול אשר מתבססת על הגדלת משאבים על שרת בודד, שיטה שבה ראינו שיש מגבלות ועליות גבוהות, לעומת גידול אופקית שעלות הגידול היא לינארית.
• שימוש בשירות IAAS בענן ציבורי – דבר זה יחסוך לנו זמנים וכוח אדם הנדרשים כאשר יש צורך להגדיל את החומרה. בשירות מסוג זה, נוכל להרים מהר שרת מסוג מסוים, ואנו נצטרך לדאוג להתקין את מערכת ההפעלה - וזה נותן מענה כמעט מלא לכל הנקודות הדורשות זמן וכוח אדם מיומן.
בחלק זה, עמדנו על האתגרים ודרכי ההתמודדות מההיבט החומרתי שנצטרך להתמודד איתם כאשר אנו רוצים שהמערכת תתרחב. כמו שניתן להבין, יש לא מעט אתגרים מההיבט החומרתי, ושימוש בענן ציבורי כIaaS יכול להיות פתרון שיכול לתת מענה להרבה אתגרים, רק יש לקחת בחשבון שהוא טומן בחובו אתגרים אחרים, כגון הגנה על פרטיות התוכנה והמידע השמור של המערכת בענן הציבורי. אתגרים אלו ניתנים להתמודדות יחסית בצורה הרבה יותר קלה, מאשר להתמודד עם אתגרים של שרתים במתחם הפרטי שאנו צריכים להתקין ולתחזק.
הגדלת משאבי החומרה על מערכת במתחם הפרטי (On-Premise) זהו תהליך שיכול לקחת חודשים, יש לו תקורה חומרתית , קיימות נקודות כשל קריטיות וזה מגדיל את שטח ההתקפה של המערכת שלנו. בנוסף, יש רף מסוים לכמות המעבדים, הזיכרון ושטח האחסון הנדרשים שנוכל להקצות למשאבי המערכת.
בחלק הבא נעמוד על האתגרים מההיבט התוכנתי, מה הם האתגרים ודרכי ההתמודדות עם אתגרים אלו.
בשאר החלקים נמשיך לעמוד על האתגרים שכרוכים במעבר לענן ובחלקים האחרונים נעבור על הטכנולוגיות החדשות שיעזרו לנו לבנות מוצר שיש לו יכולת גידול מהירה ורחבה.
מאת: ניר מקמל, ארכיטקט תוכנה למערכות מבוזרות מתקדמות
רוצים להתעדכן בתכנים נוספים בנושאי ענן וטכנולוגיות מתקדמות? הירשמו עכשיו לניוזלטר שלנו ותמיד תישארו בעניינים > להרשמה
בחלק הקודם, עמדנו על האתגרים בהיבט הפיזי ודרכי ההתמודדות עימם, כאשר המערכת שלנו נדרשת להתרחב ולגדול. בחלק זה נעבור על האתגרים מההיבט החומרתי (Hardware), כאשר יש צורך בגידול של המערכת.
כאשר אנו נדרשים להגדיל את התפוקה של המערכת שלנו, אזי מההיבט החומרתי, זה אומר שנדרש ליותר כוח עיבוד (CPU) , זיכרון נדיף (RAM) ושטח אחסון (Storage) -בכדי לתמוך בדרישות החדשות של המערכת שלנו, כגון תמיכה ביותר משתמשים בו זמנית, שיפור ביצועי המערכת השלנו ואחסון יותר מידע על החומרה.
האתגרים מההיבט החומרתי
נקודות הדורשות זמן וכוח אדם מיומן:
• צורך בביצוע ניתוח מהי החומרה הנדרשת — תהליך זה כולל שיתוף פעולה בין צוותי הפיתוח לצוותי מערכות המידע: יש צורך בניתוח מעמיק מול ארכיטקטורת התוכנה אל מול החומרה שהיא מותקנת עליה, במידה וארכיטקטורת התוכנה תומכת בריבוי מעבדים, אזי נוכל להגדיל את כמות הליבות ובכך להגדיל את כוח העיבוד. לפעולות אלו ישנה תקורה חומרתית וכספית, וככל שנגדיל את מספר המעבדים/ליבות בשרת מסוים, ככה המחיר שלו יעלה בצורה אקספונציאלית עד לתקורה חומרתית של אזור ה-256 מעבדים לשרת.
לדוגמא: שרת עם 128 מעבדים יעלה לנו לא מעט, שרת עם 256 מעבדים יעלה כבר פי כמה מונים, ושרת עם 512 מעבדים שכמעט ולא זמין לשוק המסחרי, יהיה בעל עלויות גבוהות מאוד.
לכן, ניתן לראות שגם אם מערכת התוכנה שלנו תומכת בריבוי מעבדים, היא עדיין תהיה מוגבלת בגידול שלה על גבי שרת אחד עקב חסם גידול חומרתי.
• הכנת מפרט חומרתי נדרש — במידה ויש צורך להגדיל את משאבי החומרה שלנו, אנו נצטרך להכין מפרט מדויק של כמות המעבדים, הזיכרון הנדיף ושטח האחסון אשר נצטרך להתקין. לעיתים, השרת הנוכחי שלנו לא תומך בהגדלת משאבים לכמות שאנו נדרשים אליה, אנו נצטרך לקנות שרת חדש - דבר שלרוב קשה לבצע.
• הכנת תקציב — יש צורך לבצע הצעת רכש בכדי לבדוק מה עלויות החומרה עבור הגדלת המשאבים הנדרשת.
• אישור תקציב — יש צורך לחכות לאישור התקציב, הזמן של אישור התקציב תלוי בגבוה ההוצאות, במידה ואנו בתחום ההוצאות הגידול העתידיות השנתיים התקציב יאושר די מהר, במידה ואנו נדרשים להצעת רכש לא מתוכננת, אישור התקציב עלול לקחת כמה שבועות.
• הזמנת החומרה — הזמנת החומרה היא שלב שיכול לקחת זמן די ארוך, במידה ואין את החומרה שאנו צריכים במלאי. ישנם מצבים שנצטרך לחכות חודשים עד שהיצרן יסיים לייצור אותם, ולעיתים ההזמנה יכולה להתעכב במכס עקב סיבות שונות, כמו חוסר באישור ממשרד התקשורת של החומרה.
• הרכבה והתקנת החומרה – זהו החלק שבו יש צורך באנשי IT שמכירים את החומרה ואת הארכיטקטורה הנדרשת בכדי להתקין את החומרה החדשה בצורה נכונה. לעיתים לתהליך זה יהיה צורך באנשי ה-IT של יצרן החומרה, אשר יצטרכו להגיע לאתר ולהתקין את החומרה החדשה. במידה ויש לנו חומרות מיצרנים שונים, הסיבוכיות עולה מכיוון שיש צורך לתאם מול כמה יצרן וחברות שונות את התקנת החומרה החדשה, לכן, תהליך זה עלול לקחת כמה שבועות וחודשים עד לסיום התקנת החומרה בצורה מוצלחת.
• עדכון תוכנה ובדיקות תקינות –כאשר מתקינים חומרה חדשה, מומלץ ורצוי לבצע עדכוני תוכנה של החומרה, דבר זה נחוץ כדי לעלות את רמת האבטחה של החומרה. צורך נוסף הוא בדיקות התקינות של החומרה בכדי לוודא שהחומרה שקיבלנו והתקנו תואמת למוצר שהזמנו. שלב זה יכול להיות עניין של ימים, במידה ואנו מכירים את החומרה וכבר יש לאנשי ה-IT כלים וניסיון בהתקנה של חומרה מסוג זה.
נקודות כשל קריטיות
• בעיית תאימות תוכנתית — אתגר נוסף הוא שבמידה ונתקין את המערכת שלנו על חומרה חדשה, יתכן שהתוכנה לא תעבוד תקין מכיוון שהיא הייתה מותאמת לעבוד בארכיטקטורה שלX86 או x64, וקוד המקור לא תומך בשניהם. לכן, עלולה להיות בעיית תאימות תוכנתית.
• בדיקות אבטחת מידע של החומרה –אחת החולשות שקיימות היום בשוק, הוא חולשה בשרשרת הייצור של החומרה, מכיוון שהחומרה מורכבת ממספר יצרנים שונים, והמוצר עובר שרשרת ייצור. ישנם מצבים שאחת החוליות בשרשרת הייצור ערכה שינוי בתוכנה/חומרה בזמן שהמוצר היה בדרך אלינו, ולכן יש חשש שהוא עלול להיות מזוהם בתוכנות זדוניות. לנושא זה קיימים מספר פתרונות.
כיום אין פתרון שנותן מענה כולל לכל החומרות, ולכן התקנת חומרה חדשה למעשה מעלה את שטח ההתקפה של המערכת שלנו ועלולה לסכן את אבטחת המידע של הארגון.
• הגדרת החומרה ((Configuration – לאחר התקנת החומרה, יש צורך להגדיר את ההגדרות שלה. רצוי לא להשתמש בהגדרות ברירת המחדל של החומרה, אלא להגדיר את החומרה לצרכים של המוצר.
• התקנת המערכת הקיימת על החומרה החדשה –זהו שלב שעלול להיות נקודת כשל קריטית, במידה ולא ערכנו בדיקת היתכנות שהתוכנה שלנו תצליח לעבוד על החומרה החדשה, אנו עלולים למצוא את עצמנו במצב בעייתי, מכיוון שכל השלבים שהושקעו בהתקנת החומרה החדשה יורדים לטמיון. או שאנו נצטרך להשקיע משאבים להתאים את התוכנה לחומרה החדשה, או שנצטרך להזמין חומרה חדשה, שתי החלופות שמים את הארגון בסיכון.
דרכים להתמודד עם האתגרים
• תכנון מראש – כך ניתן להפחית את זמני התגובה ולצמצם נקודות כשל קריטיות. כאשר נתכנן מראש את המערכת שתהיה בעלת יכולות גידול עצמאית ובלתי תלויה בחומרה ספציפית, אנו נפחית את זמן התהליך של תמיכה בגידול משתמשים. כמובן שקשה לתכנן מראש ויש לעשות איזון בין זמן התכנון לתמורה בפועל - הרי אם נתכנן בצורה יותר מידי מקיפה, אנו יכולים למצוא את עצמנו במשך חודשים ושנים רק בשלב התכנון, ומהצד השני, במידה ולא נתכנן בכלל, אזי ככל הנראה המערכת שלנו תתקשה בגידול בצורה קלה ומהירה.
• פיתוח ושימוש בשפת פיתוח אגנוסטית לחומרה– במידה ואנו בוחרים בשפת תכנות שקוד המקור שלה יכול לרוץ על חומרות שונות מבלי צורך לשנות את קוד המקור, זה יעזור להתגבר על בעיית תאימות של המערכת שלנו לחומרה חדשה. בשפה כמו JAVA לדוגמא, אין צורך לשנות את קוד המקור (במידה ונצטרך להריץ את התוכנה על ארכיטקטורתX86 או x64). גם שפת GO מאפשרת להריץ את אותו קוד מקור על ארכיטקטורות חומרה שונות (יש לציין שJAVA אומנם אגנוסטית לארכיטקטורת החומרה, אך במידה ולא כתבנו קוד בצורה נכונה, יכול להיות שהקוד לא יעבוד תקין על Linux OS. במידה ובקוד המקור שנכתב בWindows כתבנו למשל את נתיב הקובץ בצורה שמערכת ההפעלה וינדוס עובדות ולא כמו שמערכת ההפעלה לינוקס עובדת, במקום להשתמש ב-" File.separator" השתמשנו ב "\\", ולכן קוד זה לא יעבוד על מערכת לינוקס מכיוון שנתיב מפריד בין ספריות הוא “/” .
• כתיבת מערכת מכוונת תהליכים Microservices – במידה ויש לנו אפשרות לתכנן או להסב מערכת קיימת לארכיטקטורת Microservices, זה יכול להוות פתרון. ארכיטקטורה זו תומכת בגידול אופקי (Horizontal scale), דבר המתמודד עם בעיית הגידול האנכית (Vertical scale) שבה קיימת תקורה של גידול אשר מתבססת על הגדלת משאבים על שרת בודד, שיטה שבה ראינו שיש מגבלות ועליות גבוהות, לעומת גידול אופקית שעלות הגידול היא לינארית.
• שימוש בשירות IAAS בענן ציבורי – דבר זה יחסוך לנו זמנים וכוח אדם הנדרשים כאשר יש צורך להגדיל את החומרה. בשירות מסוג זה, נוכל להרים מהר שרת מסוג מסוים, ואנו נצטרך לדאוג להתקין את מערכת ההפעלה - וזה נותן מענה כמעט מלא לכל הנקודות הדורשות זמן וכוח אדם מיומן.
בחלק זה, עמדנו על האתגרים ודרכי ההתמודדות מההיבט החומרתי שנצטרך להתמודד איתם כאשר אנו רוצים שהמערכת תתרחב. כמו שניתן להבין, יש לא מעט אתגרים מההיבט החומרתי, ושימוש בענן ציבורי כIaaS יכול להיות פתרון שיכול לתת מענה להרבה אתגרים, רק יש לקחת בחשבון שהוא טומן בחובו אתגרים אחרים, כגון הגנה על פרטיות התוכנה והמידע השמור של המערכת בענן הציבורי. אתגרים אלו ניתנים להתמודדות יחסית בצורה הרבה יותר קלה, מאשר להתמודד עם אתגרים של שרתים במתחם הפרטי שאנו צריכים להתקין ולתחזק.
הגדלת משאבי החומרה על מערכת במתחם הפרטי (On-Premise) זהו תהליך שיכול לקחת חודשים, יש לו תקורה חומרתית , קיימות נקודות כשל קריטיות וזה מגדיל את שטח ההתקפה של המערכת שלנו. בנוסף, יש רף מסוים לכמות המעבדים, הזיכרון ושטח האחסון הנדרשים שנוכל להקצות למשאבי המערכת.
בחלק הבא נעמוד על האתגרים מההיבט התוכנתי, מה הם האתגרים ודרכי ההתמודדות עם אתגרים אלו.
בשאר החלקים נמשיך לעמוד על האתגרים שכרוכים במעבר לענן ובחלקים האחרונים נעבור על הטכנולוגיות החדשות שיעזרו לנו לבנות מוצר שיש לו יכולת גידול מהירה ורחבה.
מאת: ניר מקמל, ארכיטקט תוכנה למערכות מבוזרות מתקדמות
רוצים להתעדכן בתכנים נוספים בנושאי ענן וטכנולוגיות מתקדמות? הירשמו עכשיו לניוזלטר שלנו ותמיד תישארו בעניינים > להרשמה
לפרטים נוספים ויצירת קשר עם נציג אורקל
הודעתך לא התקבלה - נסה שוב מאוחר יותר