ארכיטקטורה מרובת-דיירים אינה רק פרט טכני

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

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

לגבי הטענה שסינון נתונים לפי מזהה לקוח הוא פתרון לוגי שאינו מספק לקוחות אנטרפרייז הדורשים הפרדה פיזית של המידע; אני חלוק מעט על איתן וביקורתי לגביה. בעבר זה היה נכון לחלוטין. כיום, עם מנגנוני Row-Level Security חזקים ומסדי נתונים מודרניים תומכי Per-tenant encryption keys, הגבול הלוגי הפך להיות קשיח כמעט כמו הפרדה פיזית, ויכול לספק לקוחות אנטרפרייז רבים.

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

https://www.linkedin.com/pulse/multi-tenant-architecture-assessment-eitan-schuler-czqhf/?trackingId=Qjyx8wD0gAGfEOM2A34ATA%3D%3D

ארכיטקטורה מרובת-דיירים אינה רק פרט טכני

דברו איתי:

שלמה יונה

מייסד ומדען ראשי, מתמטיקאי מחקר ופיתוח בע"מ

053-7326360

shlomo.yona@mathematic.ai 

https://mathematic.ai

פודקאסט על החברה ועליי, שלמה יונה, ואופן העבודה שלנו ואיתנו: A technical deep dive about Mathematic.ai