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

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

הערה: דוגמאות להגדרת לקוח של אשכול Redis זמינות במאמר דוגמאות קוד של ספריות לקוח.

שיטות מומלצות לניהול זיכרון

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

מושגים שקשורים לניהול זיכרון

• עומס כתיבה – הנפח והמהירות שבהם מוסיפים או מעדכנים מפתחות באשכול Redis. עומס הכתיבה יכול להיות רגיל או גבוה מאוד, בהתאם לתרחיש השימוש ב-Redis ולדפוסי השימוש באפליקציה.

• מדיניות פינוי – ב-Memorystore for Redis Cluster נעשה שימוש בvolatile-lruמדיניות פינוי. אפשר להשתמש בפקודות כמו EXPIRE כדי להגדיר מחיקות של מפתחות.

מעקב אחרי אשכול עם עומס כתיבה רגיל

צופים במדד /cluster/memory/maximum_utilization. אם הערך של /cluster/memory/maximum_utilization הוא 100% או פחות, ביצועי אשכול Redis טובים כשמשתמשים בעומס כתיבה רגיל.

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

מעקב אחרי אשכול עם עומס כתיבה גבוה

צופים במדד /cluster/memory/maximum_utilization. בהתאם לחומרת עומס הכתיבה הגבוה, יכול להיות שתיתקלו בבעיות בביצועים של האשכול אם תגיעו לסף הבא:

• אם /cluster/memory/maximum_utilizationמגיע ל-65% או יותר, יכולות להיות בעיות בעומסי כתיבה גבוהים מאוד.

• אם /cluster/memory/maximum_utilization מגיע ל-85% או יותר, יכולות להיות בעיות בעומסי כתיבה גבוהים באופן מתון.

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

אם נתקלתם בבעיות או שאתם חוששים שמופעל על המופע שלכם עומס כתיבה גבוה, אתם יכולים לפנות אל Google Cloud התמיכה.

שינוי הגודל של שרדים

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

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

בתרחישי שימוש ב-Redis שבהם לא רוצים לאבד מפתחות, צריך להקטין את גודל האשכול רק עד לגודל שעדיין יש בו מספיק מקום לנתונים. מספר הרסיסים החדש צריך לאפשר לפחות פי 1.5 מהזיכרון שמשמש את הנתונים. במילים אחרות, צריך להקצות מספיק רסיסים כדי להכיל כמות נתונים שגדולה פי 1.5 מכמות הנתונים באשכול. אפשר להשתמש במדד /cluster/memory/total_used_memory כדי לראות כמה נתונים מאוחסנים במופע.

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

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

בנוסף, מומלץ לנהל את השימוש ב-CPU של הצמתים כך שיהיה לצמתים מספיק תקורה של CPU כדי לטפל בתנועה נוספת מקיבולת שאבדה אם מתרחש הפסקת חשמל בלתי צפויה באזור. כדאי לעקוב אחרי השימוש במעבד (CPU) בשרתים הראשיים וברפליקות באמצעות המדד Main Thread CPU Seconds /cluster/cpu/maximum_utilization.

בהתאם למספר העותקים שאתם מקצים לכל צומת, אנחנו ממליצים על /cluster/cpu/maximum_utilizationיעדי השימוש הבאים במעבד:

• במופעים עם עותק אחד לכל צומת, כדאי להגדיר ערך של 0.5 שניות למופע הראשי ו-0.5 שניות לעותק./cluster/cpu/maximum_utilization
• במקרים עם שני עותקים משוכפלים לכל צומת או יותר, כדאי לשאוף לערך של /cluster/cpu/maximum_utilization שניות לשרת הראשי ו-0.5 שניות לכל עותק משוכפל.

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

אם יש ניצול גבוה של CPU באשכול או שהמשאבים של האשכול מוצו (לדוגמה, בגלל יותר מדי חיבורים), יכול להיות שהאשכול יתנהג בצורה לא צפויה ויחסרו מדדים חיצוניים.

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

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

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

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

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

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

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

שיטות מומלצות לשימוש בלקוח Redis

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

מיפוי לקוחות

הלקוחות צריכים לקבל רשימה מלאה של משבצות ושל הצמתים הממופים במצבים הבאים:

• כשמאתחלים את הלקוח, הוא צריך לאכלס את המיפוי הראשוני של משבצת ל-nodes.

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

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

• כשמתקבלת שגיאת READONLY מהשרת. מצב כזה יכול לקרות כששרת ראשי מורד לדרגת שרת משוכפל.

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

חיפוש לקוחות

גילוי הלקוח מתבצע בדרך כלל על ידי הפעלת הפקודה CLUSTER SLOT, CLUSTER NODE או CLUSTER SHARDS בשרת Redis. מומלץ להשתמש בפקודה CLUSTER SHARDS. ‫CLUSTER SHARDS מחליף את הפקודה CLUSTER SLOTS (שהשימוש בה הופסק), ומספק ייצוג יעיל וניתן להרחבה יותר של האשכול.

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

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

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

איך נמנעים מעומס יתר על Redis

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

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

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

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

שיטות מומלצות לשימוש בנתונים מתמשכים

בקטע הזה מוסברות שיטות מומלצות להתמדה.

שמירת נתונים ב-RDB והוספת עותקים משוכפלים

כדי לקבל את התוצאות הטובות ביותר בגיבוי של המופע באמצעות תמונות מצב של RDB או בהוספת רפליקות למופע, מומלץ להשתמש בשיטות המומלצות הבאות:

ניהול זיכרון

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

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

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

כדי לפתור את הבעיה, אפשר לצמצם את השימוש בזיכרון של האשכול באחת מהדרכים הבאות:

• מצמצמים את הזיכרון שבשימוש של האשכול לפחות מ-80% מהזיכרון המקסימלי המותר של הצומת.
• מגדילים את סוג הצומת של האשכול כדי שיהיה לו יותר זיכרון.

אחרי שהשימוש בזיכרון של האשכול יירד מתחת לסף של 80%, מוסיפים את העותק המשוכפל שוב.

תמונות מצב לא עדכניות

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

ההשפעה של תמונות מצב של RDB על הביצועים

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

לדוגמה, אם יש לכם נפח תנועה נמוך במופע בין השעות 1:00 ל-4:00, אתם יכולים להגדיר את שעת ההתחלה ל-3:00 ואת המרווח ל-24 שעות.

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

הוספת עותק

כדי להוסיף רפליקה צריך ליצור תמונת מצב של RDB. מידע נוסף על תמונות מצב של RDB זמין במאמר ניהול זיכרון.

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

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

עלות וביצועים

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

איך מצמצמים את ההשפעה של הפסקת השירות

כשבוחרים באשכול עם אזור יחיד, פחות סביר ששיבושים באזור ישפיעו על האשכול. אם ממקמים את כל הצמתים באזור אחד, הסיכוי להפסקת חשמל אזורית שתשפיע על השרת יורד מ-100% ל-33%. יש סיכוי של 33% שהאזור שבו האשכול שלכם ממוקם יושבת, לעומת סיכוי של 100% שהצמתים שממוקמים באזור הלא זמין יושפעו.

שחזור מהיר

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

שיטות מומלצות לשימוש ב-Lettuce

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

עדכון ערכי הפרמטרים

כשמשתמשים ב-Lettuce, צריך לשנות את הפרמטר validateClusterNodeMembership ל-false. אחרת, כשיהיו שינויים בטופולוגיה, יכול להיות שתקבלו שגיאות unknownPartition.

הפעלה של Transport Layer Security‏ (TLS)

בקטע הזה מוסבר על היתרונות של השימוש ב-Transport Layer Security ‏ (TLS) מבחינת אבטחה וביצועים, ומופיעות המלצות להפעלת הפרוטוקול.

הטבות אבטחה

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

• אימות של ניהול זהויות והרשאות גישה (IAM): פרוטוקול TLS משתמש בסוג האימות הזה כדי להגן מפני מתקפות התחזות לשרת, כמו מתקפות אדם בתווך.
• הצפנה בזמן ההעברה: ההצפנה המובנית שלGoogle Cloudמגנה על התעבורה בתוך הרשת של Google ברמת התשתית. עם זאת, כדי לעשות את זה צריך לבטוח גם במארח של Google וגם במערכות הרשת שלה. ההצפנה הזו שקופה ומופעלת כברירת מחדל, אבל היא לא מקצה לקצה. לעומת זאת, TLS משתמש בהצפנה בזמן ההעברה בשכבת האפליקציה. ההצפנה מקצה לקצה מאפשרת לכם לשלוט יותר במפתחות ובתהליכי ההצפנה.
• הגנה על אסימוני אימות: אם משתמשים באימות IAM, הפעלת TLS מצמצמת את הסיכון לחשיפה ולדליפה של אסימוני האימות.

השלכות על הביצועים

ההשפעה של TLS על הביצועים מתבטאת בדרכים הבאות:

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

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

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

המלצות

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

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