OpenAI חזרה למסד משותף אבל אתם לא יכולים

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

פלטפורמת Habitat משרתת כיום יותר ממיליארד משתמשים בלמעלה מ-40 אזורי ענן גלובליים, כולל נקודות קצה סמוכות לישראל שמזינות את זמני התגובה של ChatGPT. לפי נתוני החברה, התשתית מחזיקה כיום יותר מ-500 פטה-בייט של מידע. כדי להבין את גודל הסיבוב הפרסתי, צריך להביט במחיר שגובה בידוד מוחלט. תכנון הקיבולת עבור כל מכולה בנפרד דרש מכל צוות מוצר לחזות את צריכת המשאבים בעצמו ונכשל ארגונית. במקום לפתור עומסים, צוותי הפיתוח מצאו את עצמם מנחשים מספרים בטבלאות לפני כל פיצ'ר קטן.

הפיצול שפתר תקלה ויצר בירוקרטיה

בראשית הדרך, Habitat הסתמכה על קונטיינר יחיד של Azure Cosmos DB שבו שכנו כלל השירותים של החברה. המפתחות הלוגיים חולקו ישירות לפי מזהי לקוח כמו user_id או workspace_id בין עומסים שונים, ומגבלת התעבורה הרשמית של 10,000 יחידות בקשה לשנייה (RU/s) למחיצה לוגית אמורה הייתה לספק לחץ נגדי מספק. בפועל, החברה חוותה בעבר בעיות דומות כשניהלה בסיסי נתונים מבוססי Postgres, שם ארגון פעיל במיוחד או מפתח לוהט יכלו להפיל מסד נתונים שלם. הצוותים השקיעו מאמץ הנדסי רב בשכבות מטמון ובמנגנוני החכרה במקרה של פספוס במטמון כדי למנוע עומס על בסיס הנתונים, אך המעבר לענן מנוהל חשף בעיות דומות.

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

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

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

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

התקרה הפיזית של הענן המנוהל

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

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

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

שלושת התנאים לחזרה למסד משותף

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

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

הרכיב השלישי והקריטי ביותר היה שכתוב מנוע ה-Serverless של Cosmos DB. המודל הקיים שזמין בענן הוגבל ל-5K RU/s למחיצה פיזית והתפצל על בסיס נפח אחסון בלבד, מה שמנע התאמה לעומסי תעבורה כבדים. צוות ההנדסה של Azure בנה עבור OpenAI גרסה ייעודית שמאפשרת לכל מחיצה פיזית לזנק עד ל-10K RU/s, והוסיף פיצול אוטומטי של מחיצות המבוסס על צריכת יחידות תפוקה בפועל לצד פיצול מבוסס אחסון. השדרוג הזה ביטל את הצורך לנטר ולהרחיב ידנית קונטיינרים, ומאז הטמעתו לא נרשמו בחברה תקלות שכן רועש.

מה שקורה כשאתה הלקוח הכי גדול

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

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

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

מה שחסר בבנצ'מרק של החברה

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

המספרים החסרים מדברים בעד עצמם.

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