בידוד נתונים בין דיירים: Namespace, Network, DB

היכן נשברת בידוד הדיירים באשכול משותף

בידוד באשכול משותף הוא לעתים קרובות הצהרתי יותר מאשר ממשי.

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

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

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

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

מה משתנה לאחר הפרדת הסביבות: האפקט במדדים

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

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

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

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

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

אפשרויות בידוד דיירים: מרחבי שמות משותפים או סביבות נפרדות

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

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

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

סדר היישום: מביקורת ועד מסירה לתפעול

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

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

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

מה נשאר בידי הצוות: תצורות, סכימות ונהלים

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

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

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

כיצד זה נראה בפועל: הפרדת סביבות עם מסדי נתונים משותפים

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

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

מה הראו המדדים

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

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

במה שונה הגבלה ברשת מהפרדת הרשאות במסד הנתונים?

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

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

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

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

ספקות טכניים אופייניים לפני ההתחלה

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

ההרשאות כבר ניתנו בנדיבות — הכול יישבר?

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

מספר הסביבות גדל — האם הניהול לא יסתבך?

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

מה אם נצטרך לחזור לסכימה הקודמת?

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

נדון במשימה שלכם ונחזור עם תוכנית

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

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

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