איך לבנות מערכת מחשוב ענן ולחזור הביתה בשלום

19 בנובמבר 2010


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



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


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


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


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


איך עושים את זה?




  1. Scale Out: הרעיון העומד בבסיס תפיסה זו הוא ששרת חזק פי 4 עולה פי 16. לכן כאשר נרצה לתמוך בפי 4 משתמשים נרצה לעשות זאת באמצעות 4 שרתים זולים ולא באמצעות שרת גדול יותר.


  2. Sharding: מידע הוא בד"כ צוואר הבקבוק במערכות תוכנה, וזאת מכיוון שאפיון קלאסי של מערכות מרכז את כלל המידע בנקודה אחת (יש כאלו שקוראים לזה בסיס נתונים או Database). אם זה המצב אצלכם, בחרו במה שהגדולים כבר עשו לפניכם: בצעו Sharding לבסיס הנתונים שלכם, ללא תלות אם מדובר ב – MySQL או SQL Server.


  3. In Memory Databases: שימוש בזיכרון מהיר פי 5-10 משימוש בדיסק. לכן אם אתם יכולים לבצע פעולות בזיכרון כמו צבירה של צפיות במודעה ולרדת לדיסק רק פעם בכמה שניות, זאת יכולה להיות אסטרטגיה מצויינת. זהו פתרון מצויין גם במקרה שאתם יכולים להתמודד עם אובדן של מספר שולי של טרנזאקציות. במקרה שאתם לא יכולים להתמודד עם כזה אובדן, שימוש ברפליקציה של הזיכרון בין שרתים שונים יכולה לתת את המענה הרצוי.

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


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


ומה אם אני מומחה מיקרוסופט?
בוודאי שמעתם כבר שכולם מפתחים ב – Open Source. גוגל עושה שימוש אגרסיבי ב – Python, פייסבוק עושה שימוש ב – PHP וטויטר בכלל דוגלת ב – Ruby.
כמו שכתבתי לפני כן, ההמלצה שלי היא להתחיל עם מה שאתם מכירים. יש כיום ספקי מחשוב ענן רבים שמספקים פתרונות של Windows+.Net. כאשר תגדלו, תוכלו להחליף את אותם מנגנונים שמהווים 20% מהקוד שלכם ומייצרים 80% מעלויות המחשוב שלכם לפתרונות חלופיים כדוגמת Erlang ל – Push ו – LAMP ל – Web ולשמור על עלויות סבירות.


ומה עם איזה טיפ של אלופים?




  1. CDN: הוציאו את התוכן הסטטי של האתר (תמונות, עמודי HTML וסרטונים) ו – Streaming Media לספק CDN. המהלך הזה יקטין את תעבורת הרשת, ניצולת השרתים וישפר את חווית המשתמש של האתר שלכם.


  2. משתמשים חכמים: הפכו את האפליקציה שלכם לבעלת מודעות לבעיות ברשת ונצלו אותה להתגבר על נפילות. אם השתמשתם ב – Gmail וקיבלתם הודעת Loading… במקום עמוד 404, אתם בודאי יודעים למה אני מתכוון (ואם לא, גגלו על JQuery)


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


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


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


  6. NoSQL: התחילו עם בסיס נתונים סטנדרטי (SQL בעברית). כאשר תתחילו לספוג עומסים בבסיס הנתונים, זהו מה מהנתונים מתאים לאחסון לצרכי OLTP בתצורה של Key-Value וישמו עבורו פתרון NoSQL.

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




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


  2. גדרו את ההוצאות ונהלו את צווארי הבקבוק שלכם.


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


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


  5. הקשיבו למשתמשים שלכם. הם אלו שהולכים לשלם על הגידול שלכם בצורה ישירה או עקיפה. דאגו שהם יהיו מרוצים.

השורה התחתונה
עבודה לפי כללים אלו יכולה לאפשר לכם להגיע לרף מילארד המשתמשים שאתם מצפים לו. עכשיו כל מה שנותר זה להפשיל שרוולים ולהתחיל לעבוד.


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


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


ממשיכים לפתח,
משה קפלן Follow MosheKaplan on Twitter


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

כתיבת תגובה

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

8 תגובות

  1. עדי23 בנובמבר 2010 ב 9:11

    שלום משה,

    פוסט מצויין, נהנתי מאוד מההרצאה שלך בכנס.

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

    הגב
  2. Moshe Kaplan23 בנובמבר 2010 ב 12:02

    שלום עדי,

    קודם כל תודה והערה מצויינת,

    אני מודה שלפעמים עדיף לוותר על טכנולוגיות שאתה רגיל אליהן (כנראה שלא מומלץ לפתח את המערכת הבאה שלך ב – VB6 או Assembly רק בגלל שאתם חיים אותן כל יום).

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

    עד אז ממשיכים לפתח,
    משה קפלן

    הגב
  3. מיקרו הון26 בנובמבר 2010 ב 15:35

    שרתי הענן הם צורך של מיקרוסופט ליצור עוד כסף חינם
    שלא צורך ללקוחות

    הגב
  4. Moshe Kaplan27 בנובמבר 2010 ב 0:50

    שלום מיקרו הון,

    צר לי לאכזב אותך, אבל:
    1. מיקרוסופט לא היו הראשונים שהציעו שירותי ענן. הם גם רחוקים מלהיות השניים.
    2. שירותי הענן היוו בהתחלה איום על המודל העסקי של מיקרוסופט (הלחם והחמאה של החברה הם פלטפורמות ה – Windows וחבילת ה – Office ).
    3. המטרה של (כמעט) כל השחקנים בתעשייה היא להרוויח (תתפלא אבל גם השחקנים שעומדים מאחורי הקוד הפתוח לא עושים את זה לשם שמיים). אגב גם אדיסון שעומד מאחורי היכולת שלך להאיר את הבית בלילה לא עשה את זה מטעמי אלטרואיזם, וטוב שכך.
    4. שירותי הענן צומחים מתוך הצורך של הלקוחות. זאת הדרך היחידה של עסק קטן לקבל מוצר מתקדם במחיר שפוי. לדוגמה עסק קטן יכול (עד 50 משתמשים) יכול לקבל שירות דוא"ל בחינם, בעוד בעבר הוא היה צריך לקנות שרת, להתקין עליו תוכנה (זולה או לא), להחזיק איש סיסטם בחצי משרה ולטפל בהשבתה פעם בחודש. מה הרווח של הספק בזה? אם לא צריך להחזיק תמיכה במאות אלפי התקנות שונות על פלטפורמות שונות ומשונות שפזורות בשטח, לנהל גבייה ותמחור בצורה מסובכת, אפשר לחתוך את ההוצאות בצורה חדה ולתת פתרון במחיר אטרקטיבי.

    אבל כמו שאומרים זה השנייקל שלי 🙂

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

    הגב
  5. מיקי16 באפריל 2011 ב 17:31

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

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

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

    הגב
  6. Moshe Kaplan16 באפריל 2011 ב 18:24

    שלום מיקי,

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

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

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

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

    הגב
  7. לילי4 באוגוסט 2012 ב 19:09

    היי, מה הן העליות העדכניות של שדה ענן של מיקרוסופט?

    הגב
  8. Moshe Kaplan4 באוגוסט 2012 ב 22:43

    שלום לילי,

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

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

    הגב