צרת רבים – Dealing with Availability and Scalability
מאת ימי גליק | 6 תגובותלחברות הענק בתעשיית הדוט קום יש בעיות קשות באספקת שירות מהיר ורציף למליוני משתמשים בזמן אמת. הנפילות התכופות בטוויטר ואלה הפחות תכופות בפייסבוק הן דוגמיות של בעיה זו וההתמודדות איתה מתחלקת לשני תחומים שלובים: Scalability and Availability. ב- Scalability הכוונה ליכולת לשרת היטב כמות משתנה של משתמשים כשקצה יכולת המערכת נמצא הרבה מעבר למספר המשתמשים הנתון. Availability היא אמנות החזקת המערכת נגישה למשתמשים בתנאים של שיבוש פעילות. המשפט The bigger they are – the harder they fall נכון כפליים למערכות מידע ונפילה של שרת בודד (מתוך מאות) יכולה לגרום לתגובת שרשרת ולנפילתה של המערכת כולה. גרוע מכך, מרגע שנפלה המערכת קשה עד מאד להחזירה לפעילות מאחר והתוכנות/דפדפנים המחוברים לשירות מנסים שוב ושוב להתחבר למערכת ויוצרים עומס רב בהרבה מזה שנוצר בהתחברות הדרגתית טבעית.
המעניין בהתמודדותן של ענקיות האינטרנט הוא האופן החברתי בו הן ניגשות לנושא. בעוד שמידע עסקי נשמר בקנאות הרי שארכיטקטורת מערכת וסודות מקצועיים משותפים בחדווה גדולה. למשל המהפך שחוללה פייסבוק בפרדיגמה של "MySQL זה לקטנים", ארכיטקטורת המידע של לינקדאין, ארכיטקטורת המידע של Instagram ועוד ועוד. אז מה מריץ את אנשי הסיסטם לרוץ ולספר לחבר'ה?
אני מניח שהסיבה הראשונה תהיה בדיקה עצמית. ברגע שאתה משתף את עקרונות העבודה שלך אתה מאפשר למקצוענים להגיב, לבקר ולהציע. במצב בו הצעה טובה יכולה להוזיל משמעותית את הוצאות התחזוק של המערכת או לשפר את ביצועיה אין סיבה להחזיק את הקלפים קרוב לחזה. סיבה נוספת היא גיוס עובדים שהרי עכשיו כולם יודעים במה אתה משתמש ומומחים בכלים ובטכנולוגיות שבשירותך יכולים להציע עצמם. Insagram אפילו מסיימים שיתופי ידע כאלה בהצעה לעובדים להצטרף. הסיבה האחרונה העולה בדעתי נוגעת לכך ששיפור התשתיות וכלי העבודה הוא אינטרס משותף לכלל התעשיה ומיעוט הידע פוגע בכולם. גם אם "הסתדרת" לעת עתה, קפיצת המדרגה הבאה מעבר לפינה ואתה רוצה שהאפשרויות יהיו ידועות וזמינות ושכח אדם המתמחה בהן יהיה נפוץ.
יהיו אשר יהיו הסיבות האמיתיות זוהי מגמה חיובית המאפשרת לכולנו הצצה מתחת למכסה המנוע של ענקיות האינטרנט ולימוד הכלים שיאפשרו לנו לייצר שירותים גדולים ויציבים.
אני חושב שזה פשוט לא מסוכן עסקית לחשוף את הסודות האלה. העניין פה הוא לא מה יש אלא איך לבנות מערכות כאלה מתוחכמות. גם אם פייסבוק או טוויטר יסבירו לך מה הארכיטקטורה שלהם, עדיין תצטרך קבוצה גדולה של אנשים מאוד חכמים בשביל להרים ולתחזק את זה.
בקשר לסקלאביליות, אני חושב שההגדרה שלך קצת צרה. אני חושב שזה – בעיקר – ארכיטקטורה שבה כל גדילה ליניארית של כמות הקלט תצריך גדילה ליניארית במשאבים הנדרשים בשביל לייצר את הפלט הנדרש. מה שאתה מתאר הוא מערכת שרחוקה ממעטפת הביצועים שלה – היא יכולה להיות מאוד לא סקלאבילית (לדוגמה, נשענת על ביצועים של מחשב על אחד שברגע שהוא יגיע למקסימום תפוקה – אין יותר לאן לגדול)
במקרה של פייסבוק בו הם שכתבו חלקים גדולים ב- mysql זה אולי נכון. במקרים אחרים זה מממש אוצר של ידע.
לגבי ההגדרה של סקאלביליות אני מנסה לדבר לאנשים שלא מתכנתים בארלנג
ארלנג ? מה זה ארלנג ?
ימי,
במקרים רבים החברות מגלות טפח ומכסות טפחיים. תוכל לראות את זה בגוגל, פייסבוק ושחקניות רבות אחרות. הסיבה לכך שגילוי האינפורמציה משמש על פי רב לצורך גיוס כ"א איכותי.
כמובן שיש גם יוצאים מן הכלל כמו הוצאת מוצרים ל – Open Source כאשר לחברה אין משאבים מספיקים לתמוך בפיתוח היעודי והיא מעדיפה שיתוף של הקהילה או כאשר החברה גדולה מספיק והיא משתמשת בהצגת הטכנולוגיה שלה החוצה על מנת להרתיע שחקנים חדשים.
ממשיכים לפתח,
משה קפלן
[...] נצפו גם בהולנד והפיליפיניםפיתוחימי גליק כתב השבוע על ההתמודדות של מפתחים עם הצורך בזמינות (Availability) ויכולת גד…. לחברות הענק בתעשיית הדוט קום יש בעיות קשות באספקת [...]
אחת הדוגמאות הטובות היא הצורה שבא NETFLIX בחרו להתמודד עם השלב של אחרי הארכיטקטורה. לטעמי במערכות גדולות השלב הקשה הוא תכנון לשרידות, גידולל טיבעי הוא קשה במיוחד בגדלים עצומים אבל ההתמודדות עם נפילה ספורדית של שרת/ים קשה יותר. הפוסט הזה מציג את ה choas monkey של נטפליקס (http://techblog.netflix.com/2010/12/5-lessons-weve-learned-using-aws.html)