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