שיטות מומלצות לשימוש ב-Memorystore for Redis

בדף הזה מפורטות הנחיות לשימוש אופטימלי ב-Memorystore for Redis. בדף הזה מפורטות גם בעיות פוטנציאליות שכדאי להימנע מהן.

רשימה של תרחישים לפתרון בעיות מופיעה במאמר פתרון בעיות.

ייצוא של RDB

כשמייצאים גיבוי של RDB, חשוב לפעול לפי ההנחיות הבאות:

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

פעולות שצורכות הרבה משאבים

במכונות Redis במסלול הרגיל, הפעולות הבאות משתמשות בזיכרון נוסף למשך הפעולה:

• שדרוג גרסה
• הגדלה או הקטנה של הקיבולת
• מעבר ידני לגיבוי
• ייבוא / ייצוא

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

פעולות ייבוא וייצוא דורשות זיכרון נוסף בגלל תהליך ה-fork של Redis וניהול הנתונים מסוג copy-on-write שמשויכים לפעולות האלה.

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

• מפחיתים את ההגדרה maxmemory ל-80% מקיבולת המופע למשך הפעולה. כך יש מספיק זמן לביצוע הפעולה בהצלחה.
• עוקבים אחרי מדד יחס השימוש בזיכרון המערכת ומוודאים שהמדד הזה מתחת ל-80% לפני שמריצים אחת מהפעולות האלה.
• מומלץ להפעיל את הפעולות האלה בתקופות של תנועה נמוכה במופע (למשל, במהלך הלילה, בסוף השבוע וכו').
• לפני שמריצים את הפעולות האלה, צריך להגדיר לוגיקה של ניסיון חוזר עם השהיה מעריכית לפני ניסיון חוזר (exponential backoff).

פעולות ותרחישים שדורשים ניסיון חוזר להתחבר

הפעולות והתרחישים הבאים גורמים לניתוק החיבור לרשת בין הרשת שלכם לבין מופע Redis:

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

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

תחזוקה שוטפת

מכונות של Memorystore for Redis עוברות תחזוקה מעת לעת. פרטים נוספים זמינים במדיניות התחזוקה של Memorystore for Redis.

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

• הגדרת חלון זמן לתחזוקה שבו יכולים להתבצע עדכוני תחזוקה.
  • כדאי לתזמן חלונות תחזוקה לשעות שבהן תנועת הגולשים במופע נמוכה ויש מספיק זיכרון זמין. מידע נוסף זמין במאמר בנושא ההשפעות של עדכוני תחזוקה.
• הפעלת התראות על חלונות זמן לתחזוקה כדי לקבל התראות על תחזוקה שעומדת להתבצע.
• הטמעת לוגיקה לניסיון חוזר עם השהיה מעריכית לפני ניסיון חוזר (exponential backoff).
• במכונות במסלול Standard אפשר לדמות אירוע תחזוקה באמצעות מעבר ידני לגיבוי כדי לראות איך המעבר לגיבוי שנגרם בגלל תחזוקה משפיע על האפליקציה.
• במקרים של מכונות וירטואליות ברמת Basic, אפשר לדמות את ההשפעה של עדכון תחזוקה על ידי שינוי הגודל של המכונה הווירטואלית לגודל גדול יותר באופן זמני. אחרי שרואים את ההשפעה, אפשר להקטין את התמונה בחזרה לגודל המקורי.

ניהול זיכרון

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

הדרך הכי טובה לעקוב אחרי עומס הזיכרון במופע Memorystore היא באמצעות מדד יחס השימוש בזיכרון המערכת. במאמר הזה יש מדריך מפורט יותר לניהול הזיכרון ב-Memorystore for Redis.

ניהול חיבורים לא פעילים

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

שמות משאבים של Access Transparency

אסור לאחסן מידע אישי רגיש בשמות של משאבים ב-Memorystore for Redis. בשמות של משאבים אנחנו מתכוונים לשמות של מכונות Memorystore for Redis ולמטא-נתונים של מכונות, כמו תגים. אין ערובה לכך שנתונים שמאוחסנים בשמות של משאבים יהיו מוגנים על ידי Google Cloud Access Transparency, ויכול להיות שהם לא יעמדו בדרישות התאימות של הארגון ל-Access Transparency.

נדרש מחבר חיבור לרשת (VPC) מאפליקציית serverless בסביבות מסוימות ללא שרת

בסביבות מסוימות של serverless נדרש מחבר של חיבור לרשת (VPC) מאפליקציית serverless כדי להתחבר ל-Memorystore for Redis. אם רוצים להתחבר באמצעות אחת מהסביבות האלה, צריך להגדיר את מחבר הגישה לרשת (VPC) מאפליקציית serverless לפרויקט.

Networking

מומלץ להשתמש במצב החיבור גישה לשירותים פרטיים. ב-Memorystore for Redis יש שני מצבי חיבור: גישה לשירותים פרטיים וקישור ישיר בין רשתות שכנות (direct peering). מצב החיבור של גישה לשירותים פרטיים מפשט את ניהול טווח כתובות ה-IP ומאפשר לכם להשתמש ב-VPC משותף אם אתם רוצים.

אחרי שיוצרים מופע, אי אפשר לשנות את מצב החיבור.

פרטים נוספים זמינים במאמר בנושא רשתות.

מעקב והתרעות

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

מומלץ להגדיר את התראות ברירת המחדל הבאות:

• הגדרת התראה ב-Cloud Monitoring לגבי השימוש בזיכרון
• הגדרת התראה ב-Cloud Monitoring לגבי יחס השימוש בזיכרון המערכת

שיטות מומלצות לשימוש במעבד

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

מומלץ להשתמש ב-Cloud Monitoring כדי להגדיר התראות למדד Main Thread CPU Seconds ‏(redis.googleapis.com/stats/cpu_utilization_main_thread) כדי לוודא שהשימוש במעבד לא יעלה על 0.8 שניות עבור הצומת הראשי או על 0.5 שניות עבור כל צומת רפליקה, כשהרפליקה מוגדרת כרפליקה לקריאה.

אם מופע Redis חורג מהערכים המומלצים, מומלץ להגדיל את המופע לרמת קיבולת גבוהה יותר או לפעול לפי ההוראות לפתרון בעיות כדי להימנע מפעולות שדורשות הרבה משאבי CPU.

פקודות שדורשות הרבה משאבים

מומלץ מאוד להימנע משימוש בפקודות Redis שצורכות הרבה משאבים. שימוש בפקודות האלה עלול לגרום לבעיות הביצועים הבאות:

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

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

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

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

קטגוריה	פקודה שדורשת הרבה משאבים	חלופה יעילה יותר מבחינת משאבים
הפעלה לכל מרחב המפתחות	KEYS	SCAN
הרצה עבור קבוצת מקשים באורך משתנה	LRANGE	להגביל את הגודל של הטווח שמשמש לשאילתה.
	ZRANGE	להגביל את הגודל של הטווח שמשמש לשאילתה.
	HGETALL	HSCAN
	SMEMBERS	SSCAN
חסימה של הרצת סקריפט	EVAL	מוודאים שהסקריפט לא פועל ללא הגבלת זמן.
	EVALSHA	מוודאים שהסקריפט לא פועל ללא הגבלת זמן.
הסרת קבצים וקישורים	DEL	UNLINK
פרסום והרשמה למינוי	PUBLISH	SPUBLISH
	SUBSCRIBE	SSUBSCRIBE