ריבוי דיירים בלי הז'רגון: מדריך ליזמים

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

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

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

מה "multi-tenant" באמת אומר

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

הגישה ההפוכה היא single-tenant: כל לקוח מקבל עותק נפרד משלו של התוכנה, כמו לבנות בית פרטי חדש לגמרי לכל אחד. פרטי יותר, ניתן להתאמה אישית יותר — ויקר באופן דרמטי לבנות, להפעיל ולעדכן, כי עכשיו אתם מתחזקים חמישים בתים במקום בניין אחד.

כמעט כל מוצר שאתם משתמשים בו מדי יום הוא multi-tenant. הדוא"ל שלכם, כלי הנהלת החשבונות, מערכת ההזמנות, ה-CRM שצוות המכירות שלכם חי בו. אתם ואלף חברות אחרות חולקים את אותה תוכנת בסיס, ואף אחד מכם לעולם לא רואה את האחר. אותה אי-נראות — אותה הפרדה נקייה — היא כל האמנות של ריבוי דיירים.

למה ההחלטה הזו נוגעת בכל העסק שלכם

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

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

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

שלוש הדרכים להפריד בין דיירים

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

1. מסד נתונים משותף, טבלאות משותפות

הנתונים של כולם חיים באותו מסד נתונים, באותן טבלאות, עם תווית מוסתרת — "tenant ID" — המסמנת אילו שורות שייכות למי. התוכנה אחראית לסנן תמיד לפי אותה תווית, כך שלקוח A יראה רק את השורות של לקוח A. זה המודל הזול והניתן להרחבה ביותר, זה שרוב מוצרי ה-SaaS המוקדמים משתמשים בו. המלכוד: ההפרדה חיה בקוד, ולכן מסנן בודד שנשכח הוא הדרך לדליפת נתונים. זה דורש הנדסה זהירה וממושמעת.

2. מסד נתונים משותף, תאים נפרדים

מסד נתונים אחד, אבל כל דייר מקבל קטע מגודר משלו בתוכו (מפתחים קוראים לאלה "schemas"). הפרדה חזקה יותר מהמודל הראשון, עדיין יעיל למדי, וקל יותר, נניח, לייצא או למחוק את נתוני לקוח אחד באופן נקי. ה-trade-off הוא יותר חלקים נעים לנהל ככל שאתם גדלים למאות ואלפי דיירים.

3. מסד נתונים נפרד לכל דייר

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

החלק שאסור לטעות בו: בידוד

אם יש מקום אחד להשקיע בו את הדאגה שלכם, זה כאן. בידוד דיירים הוא הערובה שלקוח A לעולם לא יוכל, בשום מצב, לראות, לערוך או אפילו לחוש בקיומם של נתוני לקוח B. זה נשמע מובן מאליו. זה גם המקור הנפוץ ביותר לבאגים חמורים במוצרי multi-tenant, כי הכשל שקט — הכל נראה תקין עד היום שבו מישהו פותח דוח ורואה בתוכו את הלקוחות של זר.

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

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

מתי single-tenant באמת הבחירה הנכונה

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

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

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

השאלות שכדאי לשאול לפני שמישהו כותב קוד

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

1. 1
   כיצד תפרידו בין נתוני הדיירים?

   אתם מקשיבים לתשובה מבנית — המערכת אוכפת זאת — לא "נהיה זהירים". זו השאלה הבלתי מתפשרת.
2. 2
   באיזה מודל אנחנו משתמשים, ולמה?

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

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

   כיצד המערכת מונעת מדייר כבד אחד להאט את כל השאר? אתם רוצים לשמוע שתרחישי שכן רועש נשקלו.
5. 5
   כיצד אנו מייצאים או מוחקים את נתוני לקוח אחד באופן נקי?

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

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

דוגמה קצרה ומציאותית

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

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

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

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

שאלות נפוצות