הרחבה מהירה של אחסון מקוון לשירות יותר ממיליארד משתמשי ChatGPT

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

Habitat היא פלטפורמת האחסון המקוון שבנינו כדי שמוצרי OpenAI יוכלו לגשת למידע הדרוש להם במהירות ובאמינות. Habitat מטפלת כיום ביותר מ־70 מיליון בקשות בכל שנייה, ותומכת במוצרים שמשמשים יותר ממיליארד אנשים מדי שבוע, בכמעט 40 אזורים גאוגרפיים. Habitat הושקה לראשונה כדי לתמוך ב־GPTs ב־DevDay 2023, והחלה כספריית Python פשוטה בצד הלקוח, המחוברת למסד נתונים יחיד. כיום היא מערכת מבוזרת מורכבת שמספקת גישה ליותר מ־500 פטה־בייט של נתונים.

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

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

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

Habitat התחילה מרעיון פשוט: מהנדסי מוצר לא צריכים להתעסק בניהול מסדי נתונים. Habitat הושקה לראשונה כדי לתמוך ב־GPTs ב־DevDay 2023, כספריית Python קטנה שפעלה מול השרת הראשי של ChatGPT. היא תמכה בקבוצה מצומצמת של פעולות, שמאחורי הקלעים מופו לפעולות במסד הנתונים Azure Cosmos DB.

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

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

ספריית ה־Python הזאת עבדה היטב, ו־Habitat אומצה במהירות בקרב מהנדסי המוצר ב־OpenAI, אף שלא היה מהלך ארגוני מתואם להתרחק משימוש עצמאי ב־Postgres וב־Azure Cosmos DB.

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

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

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

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

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

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

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

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

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

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

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

Asyncio מסייעת ל־Python להריץ בו־זמנית עומסי עבודה שמוגבלים על ידי קלט/פלט, אך אינה עוזרת לעקוף את ה־GIL של Python ולספק מקביליות במעבד. מלבד תיווך בקשות עתיר קלט/פלט, Habitat מטפלת במשימות רבות עתירות מעבד ובמשימות רקע: ניתוב, דחיסה, הצפנה, חישוב סכומי ביקורת, בדיקות תקינות של שירותי המשך, שכפול בקשות לצורכי בדיקה ושליחת בקשות גיבוי.

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

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

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

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

בהשקה הראשונית של השירות, ניתוח פרופיל השימוש במעבד בשירות הפעיל חשף את אחד מגורמי השורש לעיכוב גבוה ב־asyncio, ובעקבותיו לזמני השהיה גבוהים בזנב: פענוח תקופתי של תצורת דגלי התכונות שלנו בפורמט JSON באמצעות Statsig, כלי לניהול דגלי תכונות שאפשר להשתמש בו גם לבדיקות A/B ועוד.

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

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

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

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

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

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

כיום אנחנו מסתמכים בעיקר על Istio ועל Envoy לניהול מאגרי חיבורים וליישום שיטות איזון טובות יותר שמתחשבות בעומס השרתים בכל תשתיות OpenAI, וכך נמנעים מהבעיה לחלוטין.

אחת מתופעות הלוואי של כוונון לעיכוב נמוך ב־asyncio ושל ריבוי תהליכי Python היא שקל מאוד להציף את השירותים התלויים בהמשך השרשרת במספר עצום של חיבורים — תופעה המכונה „עדר שועט”.

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

אנחנו מסתמכים גם על Envoy כדי לאחד כמה שיותר חיבורים. אנחנו משתמשים בו כדי לשדרג את חיבורי ה־HTTP/1 של Python ל־HTTP/2 ולנצל ריבוב, ולאחר מכן לרכז את החיבורים האלה במאגר ולהאריך את משך חייהם. Envoy מספק לנו גם מקום מרכזי ליישום מגבלות קצב ומנגנוני ניתוק אוטומטי, שהיו יעילים פחות אילו יושמו בכל תהליך Python בנפרד.

אחת הסיבות שבזכותן הצלחנו להרחיב את השימוש ב־Python עד כדי כך הייתה ה־API המצומצם של Habitat, שמאפשר לחזות את עלות הבקשות. במקום לאפשר ללקוחות להרכיב שאילתות SQL שרירותיות, שעלולות לגרום לסריקות של טבלאות גדולות או לצירופים בין טבלאות רבות, Habitat חושפת API פשוט של NoSQL. הוויתור על API רב־עוצמה הוא פשרה מכוונת בתכנון של Habitat.

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

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

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

Habitat חושפת API של NoSQL המבוסס על סוגי אובייקטים וקשתות שהלקוח מגדיר, בהשראת TAO⁠(נפתח בחלון חדש). הלקוחות מגדירים מראש אובייקטים וקשתות ואת היחסים ביניהם, אך לא את התוכן של כל סוג. היחסים שנוצרים דומים לגרף, אבל Habitat עצמה אינה תומכת בשאילתות טיפוסיות של מעבר בגרף, מלבד שאילתות על הקשתות הישירות של אובייקט מסוים.

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

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

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

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

ברבעון השני של 2026, בעזרת שני מהנדסים בלבד, Codex ו־GPT‑5.5, הצלחנו לכתוב מחדש את כל השירות ב־Rust. שירות ה־Rust החדש מטפל כעת ב־95% מהבקשות בסביבת הייצור; בשבועות הקרובים נפסיק לחלוטין את השימוש ב־Python. הנתונים שלנו מראים ששירות ה־Rust יעיל פי 6 בניצול המעבד ופי 15 בניצול הזיכרון בהשוואה לגרסת ה־Python, עם זמני השהיה נמוכים משמעותית גם בממוצע וגם בזנב ההתפלגות. אנחנו מתכננים לשתף תובנות נוספות בפוסט עתידי בבלוג.

השירות שנכתב ב־Python, וכעת ב־Rust, הוא רק היבט אחד של Habitat. בחלק השני של הסדרה, שמסבירה איך הרחבנו במהירות את האחסון המקוון שלנו כדי לשרת יותר ממיליארד משתמשי ChatGPT, נדבר על שכבת האחסון ועל האופן שבו Habitat מספקת גישה ליותר מ־500 פטה־בייט ומטפלת ביותר מ־70 מיליון בקשות בכל שנייה.

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