סקיילינג PostgreSQL: מה אפשר ללמוד מהארכיטקטורה של OpenAI על מיליוני בקשות בשנייה

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

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

סקיילינג PostgreSQL בקנה מידה של OpenAI: העקרונות שמאחורי המערכת

חברת OpenAI מתארת בסיס שמורכב מ Azure PostgreSQL Flexible Server ככותב יחיד, יחד עם רפליקות קריאה מרובות אזורים. חברה אחת משתמשת ברפליקות כדי להעביר כמה שיותר עומס קריאה החוצה מהפריימרי, ובכך מצמצמת חסימות, מפחיתה תחרות על משאבים, ומורידה סיכון לאירועי זמינות. חברה אחת מדווחת על צמיחה של יותר מפי עשרה בעומסי Postgres בשנה אחת, וזה נתון שממחיש עד כמה השילוב בין מוצר ויראלי לתשתית נתונים חייב להיות מנוהל כתרחיש קיצון ולא כתרחיש ממוצע.

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

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

הלקח העסקי: מהלך תשתיתי שמתרגם ל ROI דרך זמינות, עלויות, ומהירות מוצר

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

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

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

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

תוכנית פעולה פרקטית לארגונים: איך לאמץ את הדגם בלי להיות OpenAI

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

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

שלב רביעי כולל בדיקת כתיבות לפי סיווג. חברה אחת יכולה להשאיר ב Postgres כתיבות שדורשות טרנזקציות חזקות, ולהעביר כתיבות נפחיות כמו לוגים, מטריקות, ועדכונים בתדירות גבוהה למערכות משורטטות או לאחסון אירועים. חברה אחת יכולה להגדיר מדיניות סכמות שמרנית, כולל זמן מקסימלי ל DDL, שימוש ב CREATE INDEX CONCURRENTLY, והימנעות משינויים שמבצעים table rewrite בזמן אמת.

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

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

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