איך לעבור ממיליון משתמשים ל-50 מיליון ולהשאר בחיים

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

scale getty images

קרדיט תמונה: Getty Images Israel

מאת שרון וייס ,CTO ב-90min 

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

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

1. חשיבת Scale

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

2. להתעקש על פיתוח In-House עם האנשים הטובים ביותר בתחומם

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

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

3. דגש על Micro Services

בכתיבת התוכנה יש לשאוף כמה שיותר לשימוש ב-Micro Services. אפליקציה או פלטפורמה מונוליטית אחת גדולה לעולם לא תחזיק מעמד ב-Scale גבוה.

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

כאשר כותבים חלקים/ שירותים קטנים ומודולריים שיודעים לתקשר בינהם במהירות וביעילות – קל יותר לכל המערכת לעבוד נכון וקל יותר לזהות, לתקן וליעל את השירותים הפחות יעילים.

4. קוד פתוח אבל באחריות

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

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

small big getty images

קרדיט צלם\תמונה: Compassionate Eye Foundation/David Leahy, Getty Images Israel

5. שימוש בארכיטקטורות ללא שרת (Serverless)

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

6. ארכיטקטורת MULTI CDN והגשת דפים יעודיים

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

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

בצד המוצר והתוכנה אנו שואפים להגיש את אותה כתבה או עמוד מותאמים לפלטפורמת הקצה ולמדינת הקצה. עמודים קלים יותר ומהירים למשתמשים בעלי רשת איטית או יקרה יותר ועמודים עשירים ומלאים בטעינה ראשונית במקומות בהם ניתן. שימוש ב-Facebook Instant Articles או תמיכה ב-AMP או כתיבה משלנו של עמודים היברידיים באפליקציות המובייל, נותנים למשתמשים את החוויה הטובה והמהירה ביותר בכל מדינה ופלטפורמה. כך ניתן לתמוך בעשרות מיליונים ועדיין לתת חוויה מהירה לכל אחד בכל פלטפורמה, מכשיר או רשת.

7. שימוש ב-Auto Scale

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

היכולת להתמודד עם Peaks פתאומיים (ויש המון כאלה) של מאות אלפי ומיליוני משתמשים שמגיעים בו זמנית, להרים שרתים באופן אוטומטי מבלי לספוג נפילה לפני, וכמובן היכולת להוריד את הכמות בזמן רגיעה הביאה – את הפלטפורמה שלנו למצב של אפס נפילות בזמני שיא של שימוש ואת תקציב התשתיות שלנו לנמוך ב-40% ממה שהיה צריך להיות אם היינו היום עם עשרות המיליונים שיש לנו אבל במערך התשתית הקודם, הידני.

8. איסוף מידע, ניטור וזיהוי בעיות

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

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

הכתבה בחסות 90min

לאתר 90min מבית Minute Media כ-55 מיליון משתמשים, עם יותר מ-110 מיליון מבקרים באמצעות הרשתות החברתיות בכל חודש, כ- 70% מהם מתחת לגיל 25. בימים אלה מגייס הסטארט-אפ הישראלי אנשי צוות נוספים למרכז הפיתוח שלו, שיצטרפו ליותר מ-70 העובדים שכבר מאיישים את משרדי החברה בתל אביב. חושבים שאתם יכולים להיות חלק מההצלחה? לחצו כאן!

כתב אורח

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

הגב

7 Comments on "איך לעבור ממיליון משתמשים ל-50 מיליון ולהשאר בחיים"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 
Sort by:   newest | oldest | most voted
ישי
Guest

מקצועי ..רואים שהניסיון מדבר..

יואב
Guest

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

יואב
Guest

וכמובן, תודה על השיתוף !

מישו
Guest

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

יאיר
Guest

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

מיקי
Guest

האוטו סקיילנג שלנו נמצא באמזון – לא המצאנו כלום

מיקי
Guest

ברור לך שהמושג AUTOSCALING הוא מהעולם של אמזון לפני זה קראו לזה AUTOMATIC LOAD BALANCING

wpDiscuz

תגיות לכתבה: