Alibaba Group מינפה בהצלחה את טכנולוגיות מחשוב הענן של החברה, את הבינה המלאכותית (AI) וכן את טכנולוגיית IoT במהלך יום הרווקים הסיני שנערך ב-11.11.2018 בהיקף של 30 מיליארד דולר (רווח גולמי). במהלך יום הקניות קיבולת המחשוב האלסטית של שירותי הענן הנמצאים ברשות Alibaba, הכילה למעלה מ-10 מיליון ליבות מעבדים, השווה לקיבולת של 10 מרכזי נתונים גדולים. זהו שיא חדש שנקבע עבור מחשוב בזמני שיא.
לפרטים נוספים אודות טכנולוגיות סודיות אשר נמצאות מאחורי יום הרווקים הסיני, הנך מוזמן לקחת חלק באירוע "Alibaba Cloud's InternetChamp Day" אשר יתקיים ב-22 בינואר
בין השנים 2009 ל-2016 השתתפתי ב-8 הכנות טכניות עבור פסטיבל הקניות של יום הרווקים, או כמו שהוא נקרא בסין, Double 11. במהלך השנים השקענו מספר חודשים בתכנון קפדני של כל פסטיבל, כולל ניטור והתראות, תכנון קיבולת וניהול תלות. התמודדנו עם מתודולוגיות מגוונות. כיום, אם ישאלו אותי כיצד להתכונן ל-Double 11 או לאירועים שיווקיים אחרים, אציין שיטות פשוטות למדי הכוללות תכנון קיבולת, הגבלת תעבורת נתונים ושנמוך.
:שלושה שלבים לתכנון קיבולת
השלב הראשון התרחש בחלק המוקדם של התהליך, כאשר בזמן זה בחנו את הקיבולת על פי הציפיות. קבענו את הקיבולת בהתאם לעומס, לזמן התגובה של המערכת ולמגוון גורמי ביצועים. בשלב זה שאלתי מנהל בחברה "כיצד אוכל לדעת אם הקיבולת של שרת מספיקה, ובאיזו רמה של תעבורת נתונים הוא מסוגל לתמוך?" בתשובתו, המנהל ציין מספר אמפירי: כל שרת תומך במיליון paravirtual machines) PV).
אז, עקומת תעבורת הנתונים הכילה 3 נקודות שיא מדי יום: 09:00-10:00 בבוקר, 14:00 או 15:00 עד 17:00 אחה"צ, ו-20:00 עד 22:00 בערב. מדוע מיליון? זהו מספר אמפירי שיש לו בסיס מדעי. קיוינו שניתן יהיה לתמוך בתעבורת הנתונים המקוונת גם כאשר חצי מהשרתים מנוטרלים, וכן שניתן יהיה לתמוך בתעבורת הנתונים בשעות השיא כאשר כל השרתים פעילים. למעשה, מחשב יחיד יכול לתמוך ב-3.2 מיליון PV, וזה היה המספר האמפירי בזמן זה.
כמובן שהערך האמפירי התאים לתקופה ההיא, משום שארכיטקטורת המערכת היתה פשוטה. ניתן להבין כי כל המודולים והעיבוד הלוגי של Taobao.com(מקבוצת עליבאבא) רוכזו במערכת אחת, ולכן תקופות השיא השתנו כתלות במודול. פתרנו זאת באמצעות קביעת קדימות (preemption) או תזמון של המעבד הפנימי של השרת ברמת מערכת ההפעלה.
השלב השני היה קיום בדיקת עומס. המערכות מבוזרות, ולכן נתקלנו בבעיות. כעת היו לנו שני יעדים: הראשון היה ביצוע בדיקת עומס לפני שחרור המערכת לשימוש, כדי לוודא שזמן התגובה והעומס עומדים בדרישות השימוש; שנית, לבחון בצורה מדוייקת כמה שרתים יש להפעיל בהתאם לתוצאות בדיקת העומס. את היעד השני היה קשה לדמות.
?מה ניתן לעשות לשם כך
תחילה, ביצענו בדיקות עומס ישירות. בשלב זה לא נראה שיש היגיון בהחלטה; אף חברה, כולל Alibaba, מעולם לא ביצעה בדיקות עומס מקוונות בצורה ישירה. כתבנו כלי שחילץ את יומני היום הקודם והפעיל אותם ישירות ובצורה מקוונת. לדוגמה, קביעת ערך מוגדר מראש בזמן התגובה ובעומס, ובדיקת ה-QPS כאשר הערך הופעל.
שנית, פיצלנו את תעבורת הנתונים. הארכיטקטורה הכוללת של Alibaba מאוחדת ומבוססת על סדרה של תוכנות ביניים. לדוגמה, כיוון עומס ויחס בתוכנה, העברת תעבורת הנתונים המקוונת לשרת בהתאם למשקלה, וכן העברה מתמשכת של תעבורת הנתונים בצד היישומים המקוונים והשרת לשרת אחד גרמו להגדלת משקלו, העומס ו-QPS שלו. התהליך כולו תועד.
ישנם שני תרחישים: הדמיה והפעלה חוזרת של היומן. שיטה נוספת היא שימוש בתעבורת נתונים אמיתית, אשר מתבצעת באופן אוטומטי לצורך הפקת נתונים מדי יום. לאחר היישום, תעבורת נתונים זו החליפה את התהליך שביצע בדיקות עומס ביצועים במצב לא מקוון. כך יכולנו לקבל מדי יום מדדי ביצועים נפרדים לכל מערכת. ניתן היה להציג מדדי ביצועים להכנסת פרוייקטים לשימוש וכן דרישות שגרתיות בצורה ישירה.
תעבורת הנתונים בשרת, המתייחסת למוצרים, גבוהה ב-Double 11, ונדרשים יותר שרתים שקשורים במוצרים. בדומה לכך, יותר שרתים שקשורים בחנויות נדרשו עבור Double 12. ביצועי תעבורת נתונים זו שונים מאלה של התעבורה הרגילה. כמו כן, לא יהיה מדויק לחשב את תעבורת הנתונים בהתבסס על תרחיש שכולל קיבולת רגילה.
בשנת 2013, לאחר הטמעה של מוצר בדיקת עומס end-to-end, חל שינוי מהותי. הביצועים בשנת 2013 ו-2014 היו מצויינים. זו היתה התחלה של עידן חדש. בשיווק וקידום מכירות ישנו שיא, כאשר לפניו תעבורת הנתונים נמוכה מאוד ולאחריו תעבורת הנתונים גדלה באופן פתאומי. מדובר בדרך יעילה במיוחד להתמודדות עם מצב זה.
.Alibaba Cloud -מאת: ג'יאנג ג'יאנגווי, מהנדס ראשי ב
Alibaba Group מינפה בהצלחה את טכנולוגיות מחשוב הענן של החברה, את הבינה המלאכותית (AI) וכן את טכנולוגיית IoT במהלך יום הרווקים הסיני שנערך ב-11.11.2018 בהיקף של 30 מיליארד דולר (רווח גולמי). במהלך יום הקניות קיבולת המחשוב האלסטית של שירותי הענן הנמצאים ברשות Alibaba, הכילה למעלה מ-10 מיליון ליבות מעבדים, השווה לקיבולת של 10 מרכזי נתונים גדולים. זהו שיא חדש שנקבע עבור מחשוב בזמני שיא.
לפרטים נוספים אודות טכנולוגיות סודיות אשר נמצאות מאחורי יום הרווקים הסיני, הנך מוזמן לקחת חלק באירוע "Alibaba Cloud's InternetChamp Day" אשר יתקיים ב-22 בינואר
בין השנים 2009 ל-2016 השתתפתי ב-8 הכנות טכניות עבור פסטיבל הקניות של יום הרווקים, או כמו שהוא נקרא בסין, Double 11. במהלך השנים השקענו מספר חודשים בתכנון קפדני של כל פסטיבל, כולל ניטור והתראות, תכנון קיבולת וניהול תלות. התמודדנו עם מתודולוגיות מגוונות. כיום, אם ישאלו אותי כיצד להתכונן ל-Double 11 או לאירועים שיווקיים אחרים, אציין שיטות פשוטות למדי הכוללות תכנון קיבולת, הגבלת תעבורת נתונים ושנמוך.
:שלושה שלבים לתכנון קיבולת
השלב הראשון התרחש בחלק המוקדם של התהליך, כאשר בזמן זה בחנו את הקיבולת על פי הציפיות. קבענו את הקיבולת בהתאם לעומס, לזמן התגובה של המערכת ולמגוון גורמי ביצועים. בשלב זה שאלתי מנהל בחברה "כיצד אוכל לדעת אם הקיבולת של שרת מספיקה, ובאיזו רמה של תעבורת נתונים הוא מסוגל לתמוך?" בתשובתו, המנהל ציין מספר אמפירי: כל שרת תומך במיליון paravirtual machines) PV).
אז, עקומת תעבורת הנתונים הכילה 3 נקודות שיא מדי יום: 09:00-10:00 בבוקר, 14:00 או 15:00 עד 17:00 אחה"צ, ו-20:00 עד 22:00 בערב. מדוע מיליון? זהו מספר אמפירי שיש לו בסיס מדעי. קיוינו שניתן יהיה לתמוך בתעבורת הנתונים המקוונת גם כאשר חצי מהשרתים מנוטרלים, וכן שניתן יהיה לתמוך בתעבורת הנתונים בשעות השיא כאשר כל השרתים פעילים. למעשה, מחשב יחיד יכול לתמוך ב-3.2 מיליון PV, וזה היה המספר האמפירי בזמן זה.
כמובן שהערך האמפירי התאים לתקופה ההיא, משום שארכיטקטורת המערכת היתה פשוטה. ניתן להבין כי כל המודולים והעיבוד הלוגי של Taobao.com(מקבוצת עליבאבא) רוכזו במערכת אחת, ולכן תקופות השיא השתנו כתלות במודול. פתרנו זאת באמצעות קביעת קדימות (preemption) או תזמון של המעבד הפנימי של השרת ברמת מערכת ההפעלה.
השלב השני היה קיום בדיקת עומס. המערכות מבוזרות, ולכן נתקלנו בבעיות. כעת היו לנו שני יעדים: הראשון היה ביצוע בדיקת עומס לפני שחרור המערכת לשימוש, כדי לוודא שזמן התגובה והעומס עומדים בדרישות השימוש; שנית, לבחון בצורה מדוייקת כמה שרתים יש להפעיל בהתאם לתוצאות בדיקת העומס. את היעד השני היה קשה לדמות.
?מה ניתן לעשות לשם כך
תחילה, ביצענו בדיקות עומס ישירות. בשלב זה לא נראה שיש היגיון בהחלטה; אף חברה, כולל Alibaba, מעולם לא ביצעה בדיקות עומס מקוונות בצורה ישירה. כתבנו כלי שחילץ את יומני היום הקודם והפעיל אותם ישירות ובצורה מקוונת. לדוגמה, קביעת ערך מוגדר מראש בזמן התגובה ובעומס, ובדיקת ה-QPS כאשר הערך הופעל.
שנית, פיצלנו את תעבורת הנתונים. הארכיטקטורה הכוללת של Alibaba מאוחדת ומבוססת על סדרה של תוכנות ביניים. לדוגמה, כיוון עומס ויחס בתוכנה, העברת תעבורת הנתונים המקוונת לשרת בהתאם למשקלה, וכן העברה מתמשכת של תעבורת הנתונים בצד היישומים המקוונים והשרת לשרת אחד גרמו להגדלת משקלו, העומס ו-QPS שלו. התהליך כולו תועד.
ישנם שני תרחישים: הדמיה והפעלה חוזרת של היומן. שיטה נוספת היא שימוש בתעבורת נתונים אמיתית, אשר מתבצעת באופן אוטומטי לצורך הפקת נתונים מדי יום. לאחר היישום, תעבורת נתונים זו החליפה את התהליך שביצע בדיקות עומס ביצועים במצב לא מקוון. כך יכולנו לקבל מדי יום מדדי ביצועים נפרדים לכל מערכת. ניתן היה להציג מדדי ביצועים להכנסת פרוייקטים לשימוש וכן דרישות שגרתיות בצורה ישירה.
תעבורת הנתונים בשרת, המתייחסת למוצרים, גבוהה ב-Double 11, ונדרשים יותר שרתים שקשורים במוצרים. בדומה לכך, יותר שרתים שקשורים בחנויות נדרשו עבור Double 12. ביצועי תעבורת נתונים זו שונים מאלה של התעבורה הרגילה. כמו כן, לא יהיה מדויק לחשב את תעבורת הנתונים בהתבסס על תרחיש שכולל קיבולת רגילה.
בשנת 2013, לאחר הטמעה של מוצר בדיקת עומס end-to-end, חל שינוי מהותי. הביצועים בשנת 2013 ו-2014 היו מצויינים. זו היתה התחלה של עידן חדש. בשיווק וקידום מכירות ישנו שיא, כאשר לפניו תעבורת הנתונים נמוכה מאוד ולאחריו תעבורת הנתונים גדלה באופן פתאומי. מדובר בדרך יעילה במיוחד להתמודדות עם מצב זה.
.Alibaba Cloud -מאת: ג'יאנג ג'יאנגווי, מהנדס ראשי ב
לפרטים נוספים ויצירת קשר עם נציג אורקל
הודעתך לא התקבלה - נסה שוב מאוחר יותר