אַשׁרַאי:
במהלך גלים של השבתה אפית השבוע, המהנדסים של Foursquare נאבקו עם השרתים וארכיטקטורת מסדי הנתונים שלהם, וניסו נואשות להעביר נתונים מרסיסים כושלים כדי להחזיר את השירות לאינטרנט.
בנתיחה רשמית שלאחר המוות, מהנדס פורסקוור סיפר כיצדרסיס אחד עמוס מדיהוריד את כל השירות. מהנדסים הציגו רסיס חדש למערכת והחלו להעביר נתונים (שאף אחד מהם לא אבד במהלך התהליך), אך לא הצליחו להחזיר את Foursquare לאינטרנט. בסופו של דבר, הצוות הקדיש חמש שעות לאינדקס מחדש של הרסיס המקורי.
ובכל זאת, המהנדס הודה שלצוות אין מושג מדוע הרסיס נכשל מלכתחילה.
בכתבה מפורטת יותר, מסביר הורוביץ את התעלומה הזו; האשמה מוטלת באופן ישיר על המשתמשים החזקים.
לפני חודשיים,Foursquareהחל להשתמש באשכול של שני רסיסים, שלכל אחד מהם קיבולת מקסימלית של 66GB RAM. בתיאוריה, הצ'קים ייכתבו באופן שווה בין הרסיסים. לרוע המזל של כל הצדדים המעורבים, זה לא קרה.
"בהנחה שתתי קבוצות מסוימות של משתמשים פעילות יותר מאחרות", כתב הורוביץ, "אפשר להעלות על הדעת שהעדכונים שלהם עשויים לעבור כולם לאותו רסיס. זה מה שקרה במקרה הזה, וכתוצאה מכך רסיס אחד גדל ל-66GB והשני רק ל-50GB ."
אז ככל שהצ'קים של המשתמשים החזקים גדלו, Shard A קיבל יותר צ'ק-אין ממה שהוא יכול היה להתמודד, השאילתות הפכו איטיות, צבר צבר הצטבר ואז האתר ירד.
השאלה ההגיונית הבאה היא, "כיצד אתה בונה מערכת שמתרחבת עבור משתמשים מזדמנים ומשתמשים מתקדמים כאחד, במיוחד כאשר אתה מאחסן מספר גדול של אובייקטים עם גדלי קבצים קטנים יחסית?"
למרות שזו לא באמת שאלה שאנחנו מוסמכים לענות עליה, אנחנו שותפים למסקנה הברורה של הורוביץ שפיקוח על קיבולת המערכת הוא המפתח. הפעלה בתפוסה או קרובה היא מתכון לצרות.
"ברגע שאתה בקיבולת מקסימלית", הוא כתב, "קשה להוסיף עוד קיבולת ללא זמן השבתה מסוים כאשר חפצים קטנים. עם זאת, אם נתפסים מראש, הוספת רסיסים נוספים על מערכת חיה יכולה להיעשות ללא זמן השבתה". הוא המשיך לומר שעם 12 שעות התראה נוספות, ייתכן שההשבתה של Foursquare הייתה נמנעת.
אנו שמחים ש-10gen ו-Foursquare פועלות לשיפור MongoDB ולטפל בבעיות מדרגיות נוכחיות ועתידיות, אבל קשה לראות שירות גדל במהירות כמו Foursquare - הן מבחינת אימוץ המשתמש והן מבחינת שותפויות עם (וההכנסות) מ) מותגים לאומיים -- ויש להם כמויות מטרידות אלה של השבתה.
