אמאזון נפלה. אז מה?

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

cc-by-formatc1. flickr

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

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

  1. הקטנות שמתחת לרדאר: חברות אלו לא מגלגלות מספיק כסף והנזק בהשקעה באתר גיבוי מול התשואה שהן היו יכולות לשאת בהשקעה בתכונות חדשות או שווקים חדשים בטל בשישים. לגבי החברות הללו עומד כלל שאמר לי יזם לפני כשנתיים “טוב לי להיות באמזון, כי כשמשהו יקרה, עוד 10 יותר גדולים ממני יפלו, ידברו עליהם, כולם יהיו מושבתים ואני לא אהיה חריג…” אם זה מזכיר לכם את האמירה שאף מנהל מחשוב לא פוטר כי הוא קנה IBM אתם יותר מצודקים.
  2. הקטנות שגדלו: הדירקטוריון וההנהלה בחברות אלו יצטרכו לשבת כמה דקות בזמן הקרוב ולחשוב לאיזו קבוצה הן משתייכות? האם הן יכולות להשיג תשואה טובה ע”י השקעה ביכולות נוספות? או שצמצום הסיכון של השבתה חשוב יותר כי הן רוצות לשחק בליגה של הגדולים.
  3. הגדולות שהתעוררו מאוחר מדי: החברות הללו מגלגלות הרבה מאוד כסף באינטרנט. המחיר הכלכלי הישיר ו/או העקיף של כמה שעות השבתה לחברות אלו גבוה משמעותית מעלות הקמת מערך גיבוי מסודר שידע להתמודד עם כשל במערכות התשתית. לשחקניות הללו האירוע השבוע יהווה קריאת השכמה. בשבועות ובחודשים הקרובים נראה פעולות נחושות של החברות הללו לסגירת הפער.
  4. הגדולות שבאו מוכנות לחגיגה: החברות הללו הפנימו את עקרונות הפיתוח לענן והיו מוכנות לכשל במערכות התשתית. Netflix לדוגמה, מבססת חלקים גדולים מתשתית הפצת המדיה שלה על אמזון, ודיווחה שלקוחותיה לא נפגעו מהאירועים.

כמה שאלות ותשובות על מה שקרה באמזון השבוע

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

כיצד בנויה מערכת התשתית של אמזון?

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

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

מה קרה באמזון השבוע?

מספר חברות אינטרנט שמתבססות על שירותי המחשוב של אמזון קרסו למספר שעות ביום חמישי האחרון (החל מ 10:41 ועד 19:25 שעון ישראל), ואמזון דיווחה על בעיות באחד מה – AZ שלה כתוצאה מכשל תקשורת שפגע קשות בהתקני האחסון שלה שמקבילים להתקני SAN ברשתות ארגוניות. כל החברות שדיווחו על בעיות ביססו את המערכות שלהן על האזור הגיאוגרפי של החוף המזרחי הכולל ארבעה AZ, וככל הנראה הן גם רכזו את השרתים שלהם ב – AZ ספציפי.

קור המידע המרכזי שאני מתבסס עליו הוא ה – Amazon AWS Service Health Dashboard, זאת מכיוון שהדרך הטובה ביותר להבין מה קרה באמזון היא פשוט לקרוא את הדיווחים של החברה עצמה. בכל מקרה אם תעיינו מדיווחים של אמזון, תגלו שהם מבטיחים לפרסם דיווח פוסט מורטום מפורט. עד אז אני אציג את העובדות ואת ההערכה שלי למה שקרה שמה.

אזהרה! ההסבר מיועד למי שבילה מספר שעות באולם המחשב ולא רק בביקור היכרות, והוא מובא בעירבון מוגבל:

  1. כלל התקלות המדווחות הן מהאיזור של החוף המזרחי. השבתות מדווחות ממערכות ה – EBS (דיסקי ה – SAN וה – Boot from Lan) וה – RDS (בסיסי הנתונים המנוהלים), הודעות שגיאה התקבלו גם משירותי ה – Elastic MapReduce ה – CloudWatch (מערכת הניטור) וה – Elastic Beanstalk (מערכת הקונפיגורציה האוטומטית).
  2. דיווחים אלו תואמים את הדיווח של אמזון שמקור התקלה הוא התקני האחסון: שני השירותים המושבתים תלויים מיידית בזמינות אחסון והקצאות אחסון חדשות, בעוד שאר השירותים נפגעים פחות מזמינות נמוכה של אחסון מרכזי.
  3. אם נחקור מעט יותר בדיווחי אמזון נגלה שמקור התקלה בהתקן האחסון הוא תקלת תקשורת שגרמה לבעיות בתהליך הרפליקציה (Disk Mirroring). לכאורה אין קשר בין השניים, אבל השוואה לתקלת ייצור שהייתה באחת מחברות האינטרנט הגדולות בישראל לפני כשנה וחצי יכולה ללמד את הסיבה:
    1. על מנת לשמור על זמינות המידע, אנו מחזיקים דיסקים שמשוכפלים לדיסקים אחרים, למקרה שאחד הדיסקים יפגע (בד”כ מדובר על שני התקני אחסון מרכזי שמגבים אחד את השני).
    2. תהליך ההעתקה מבוצע ע”י יצירת קבצי דלתא. קבצים אלו מועתקים מדיסק הראשי לדיסק הגיבוי.
    3. בשגרה העתקת הקבצים מתבצעת מיידית ואלו נמחקים מהדיסק הראשי.
    4. במקרה של נתק, הדיסק הראשי (בד”כ התקן האחסון המרכזי) צובר את קבצי הדלתא על מנת שהוא יכול להשלים את הפערים בדיסק הגיבוי כאשר נתק התקשורת יסתיים.
    5. במקרה שהנתק נמשך זמן רב מדי, התקן האחסון המרכזי צורך את כל נפח האחסון הנותר במכונה ע”י קבצי הדלתא ולבסוף גורם לקריסתה כאשר לא נותר מקום במכונה.
  4. דיווחי המהנדסים של אמזון על הצורך בהכנסת דיסקים נוספים למכונות והמתנה עד לסיום הרפליקציה תואמים גם הם את ההשערה כי זה המקרה שקרה גם כאן: על מנת להעלות את המכונה לאחר הקריסה נדרשים דיסקים נוספים, ובנוסף כל עוד תקלת התקשורת לא נפתרה נדרש גם שטח נוסף לצבירת קבצי הדלתא. ניתן גם להבין מתהליך זה מדוע הנפגעים הראשונים היו לקוחות שנדרשו לדיסקים חדשים.
  5. לסיכום ניתן ללמוד מהתהליך שקרה שני דברים: 1) כיצד גם פתרון HA יכולים לגרום לנפילות (ואפילו חמורות), ו – 2) כיצד ההיסטוריה חוזרת על עצמה גם בשחקניות ענן וגם בשחקניות מסורתיות יותר. נותר לי לקוות ששתי השחקניות לא עשו שימוש באותם התקני אחסון, כיוון שאז זה יהפוך מחוסר מזל לסיפור עצוב.

למה היו טענות שהייתה זליגה לכל ה – AZ?

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

האם הענן לא אמור לפתור את כל הבעיות הללו? הרי הבטיחו לנו שענן זה הפתרון לכל בעיות התשתית!

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

בשורה התחתונה: אז מה צריך לעשות?

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

  1. הכנת תוכנית פעולה: גם אם אין לכם כוונה להשקיע שקל בהתאוששות של ספקית ענן, אתם צריכים תוכנית ליום פקודה: איך מודיעים למשתמשים על ההשבתה ואיך מעדכנים אותם כשהאתר או חלקו למטה. ערוצים כמו Twitter, Facebook או אפילו אתר סטטי עם שקופית תקלה יעשו את העבודה.
  2. בדיקת הניירת המשפטית והביטוח: אם אתם גובים כספים מלקוחותיכם, הבטיחו כי החוזה בינכם מונע אפשרות שיתבעו אתכם בגין השבתה מעין זו. אם אתם לא בטוחים שאתם מוגנים לחלוטין, זה הזמן להרים טלפון לסוכן הביטוח ולבדוק את האפשרויות.
  3. ניטור מערכות: ודאו שאתם יודעים לפני המשתמשים שלכם שהבעיות החלו כדי שתוכלו להפעיל את תוכנית הפעולה שהכנתם.
  4. שיפור מוכנות: הכינו את כל אחד מרכיבי המערכת שלכם לנפילה, הפרידו את מערכות ה – Online שלכם ומערכות ה – Offline ומינעו השפעה של נפילה של רכיב אחד על רכיבים אחרים.
  5. הקמת מערך גיבוי בתוך אזור גיאוגרפי יחיד: בצורה זו תוכלו להתאושש מנפילה של שרת או עומס חריג ע”י הרמת שרתים נוספים ושימוש בכלי איזון עומסים.
  6. הקמת מערך גיבוי בין אזורים גיאוגרפיים על בסיס אותו ספק: במקרה הזה תצטרכו להתמודד עם עבודה מעל תווך WAN עם כל האתגרים הטמונים בכך.
  7. הקמת  מערך גיבוי על בסיס ספקיות ענן שונות: במקרה הזה תצטרכו להתמודד עם אוסף של API ושירותים שאינם תואמים בין הספקיות השונות עם האתגר הטמון בכך.

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

הפוסט פורסם במקור בבלוג של משה קפלן

 

משה קפלן

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

הגב

1 תגובה על "אמאזון נפלה. אז מה?"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 

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

סידור לפי:   חדש | ישן | הכי מדורגים
משה קפלן
Guest

למתעניינים בהשתלשלות המלאה וברשימת הנפגעים: http://newenterprise.allthingsd.com/20110421/amazons-cloud-crashed-overnight-and-brought-several-other-companies-down-too/

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

wpDiscuz

תגיות לכתבה: