הנחיות לגבי חלוקת נתונים ב-Config Controller

במאמר הזה מובאות המלצות לגבי חלוקת השימוש ב-Config Controller. חלוקה לרסיסים (Sharding) היא תהליך של פיצול משאבים שמנוהלים על ידי Config Controller Google Cloud בין מרחבי שמות, אשכולות או פרויקטים שונים.

היתרונות של חלוקת נתונים:

  • מצמצם את ההשפעה של שינויים: אם אחד מהרסיסים מפסיק לפעול, הרסיסים האחרים לא מושפעים.
  • עוזר לכם לנהל את האבטחה: לכל שארד יכולות להיות הגדרות ייעודיות של IAM ו-RBAC. תוקפים זדוניים שפורצים לשבר אחד לא יכולים לגשת לשברים אחרים. טעות בהגדרה של רסיס אחד לא יכולה להשפיע על רסיסים אחרים.
  • שיפור יכולת ההתאמה לגודל: יכולים להיות צווארי בקבוק בהתאמה לגודל של רכיב יחיד, כמו מספר האובייקטים המנוהלים או מכסות ה-API. שימוש בכמה רסיסים מגדיל את יכולת ההתאמה הכוללת של השימוש ב-Config Controller.

שימוש ב-sharding עם Config Controller

יש כמה דרכים שונות להטמיע פיצול (sharding). הגישה הכי טובה תלויה בצרכים ובדרישות הספציפיים שלכם.

חלוקת מודלים

יש שני מודלים עיקריים של חלוקה למקטעים:

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

צמצום הצורך בהפניות בין שרדים

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

מנגנוני פיצול

יש שלושה מנגנונים עיקריים של חלוקה למקטעים:

  • לפי מרחבי שמות: אפשר ליצור מרחבי שמות נוספים ולהגדיר את Config Connector לניהול משאבים במרחבי השמות האלה.
  • לפי מופעים של Config Controller: אפשר ליצור כמה מופעים של Config Controller בפרויקט אחד ב- Google Cloud Google Cloud.
  • לפי פרויקטים: אתם יכולים ליצור כמה מופעים של Config Controller בכמה פרויקטים של Google Cloud . המנגנון הזה עוזר לפתור בעיות שקשורות למכסות של API אם אתם נתקלים בצווארי בקבוק של מכסות בפרויקט יחיד. פרטים נוספים זמינים במאמר בנושא פיצול המשאבים למספר פרויקטים.

הערות חשובות לגבי הטמעת פיצול (sharding)

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

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

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

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

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

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

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

מכסות ל-API

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

המאמרים הבאים