שיטות מומלצות לשימוש ב-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 לטיפול בתנועה נוספת מקיבולת שאבדה אם מתרחש הפסקת חשמל בלתי צפויה באזור. כדאי לעקוב אחרי השימוש במעבד (CPU) בשרתים הראשיים וברפליקות באמצעות המדד Main Thread CPU Seconds /cluster/cpu/maximum_utilization.

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

• במקרה של אשכולות עם עותק אחד לכל צומת, כדאי להגדיר ערך של /cluster/cpu/maximum_utilization0.5 שניות לשרת הראשי ו-0.5 שניות לעותק.
• במקרים של אשכולות עם שני עותקים משוכפלים לכל צומת או יותר, כדאי לשאוף ל/cluster/cpu/maximum_utilizationערך של 0.9 שניות לשרת הראשי ו-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

שיטות מומלצות להגדלת סף ההמרות

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

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

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

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

שינוי קנה מידה של ניצול הזיכרון

כדי לקבוע מתי לשנות את גודל הזיכרון על סמך השימוש בזיכרון, צריך לעקוב אחרי המדדים /cluster/memory/average_utilization ו-/cluster/memory/maximum_utilization. מידע נוסף על המדדים האלה זמין במאמר מדדי מעקב נתמכים.

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

• ממוצע ניצול הזיכרון באשכול חורג מהסף המומלץ של 70%.
• ניצול הזיכרון המקסימלי חורג מ-80% וניצול הזיכרון הממוצע חורג מ-50%.

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

• ממוצע ניצול הזיכרון של האשכול יורד מתחת לסף המומלץ של 50%.
• השימוש המקסימלי בזיכרון יורד מתחת ל-60% והשימוש הממוצע בזיכרון יורד מתחת ל-40%.

שינוי קנה מידה של ניצול המעבד

כדי לקבוע מתי להגדיל את הקיבולת על סמך השימוש במעבד, עוקבים אחרי המדדים /cluster/cpu/average_utilization ו-/cluster/cpu/maximum_utilization.

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

• אחוז הניצול הממוצע של המעבד (CPU) באשכול חורג מהסף המומלץ של 70%.
• ניצול המעבד המקסימלי חורג מ-80% וניצול המעבד הממוצע חורג מ-50%.

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

• השימוש הממוצע במעבד (CPU) באשכול יורד מתחת לסף המומלץ של 50%.
• השימוש המקסימלי במעבד יורד מתחת ל-60% והשימוש הממוצע במעבד יורד מתחת ל-40%.

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

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

אם אתם רואים הבדל משמעותי בין הממוצע לבין השונות המקסימלית, אתם יכולים להריץ את הפקודות INFO memory ו-INFO cpu בצמתי האשכול כדי לאסוף נתונים בזמן אמת ישירות מהאשכול. מידע נוסף על השימוש בפקודות האלה זמין במאמר INFO במסמכי התיעוד של Redis.

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

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

מיפוי לקוחות

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

• כשמאתחלים את הלקוח, הוא צריך לאכלס את המיפוי הראשוני של משבצת ל-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 כדי לבצע גילוי של אשכול. נקודת הקצה של הגילוי היא בעלת זמינות גבוהה ומתבצע איזון עומסים בין כל הצמתים באשכול. בנוסף, נקודת הקצה של הגילוי מנסה לנתב את בקשות הגילוי של האשכול לצמתים עם תצוגת הטופולוגיה העדכנית ביותר.

זיהוי וטיפול בחיבורים שלא מגיבים

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

• הגדרת פרמטרים של TCP keep-alive: מגדירים את הפרמטרים TCP keepalive time, TCP keepalive interval ו-TCP keepalive probes כך שהלקוחות יזהו וינתקו באופן יזום חיבורים שלא מגיבים, גם כשהחיבורים לא פעילים. לדוגמה, אם מגדירים את הפרמטר TCP keepalive time ל-30 שניות, את הפרמטר TCP keepalive interval ל-10 שניות ואת הפרמטר TCP keepalive probes ל-3, הלקוחות יאפסו חיבורים לא פעילים שלא מגיבים תוך דקה.
• הגדרה של פסק זמן למשתמשים ב-TCP: צריך להגדיר את פסק הזמן הזה בלקוחות כדי לאפס חיבורים שיש להם בקשות ממתינות ולא מגיבים. לדוגמה, אם מגדירים את הזמן הקצוב לתפוגה ל-15 שניות, הלקוחות מאפסים חיבורים שלא מגיבים שיש להם בקשות בהמתנה אחרי 15 שניות.

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

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

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

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

ניהול זיכרון

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

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

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

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

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

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

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

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

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

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

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

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

הוספת עותק

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

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

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

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

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

מזעור ההשפעה של הפסקת השירות

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

שחזור מהיר

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

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

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

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

כשמשתמשים ב-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, יצירת חיבורים דורשת הרבה משאבים. בחיבורים חדשים וקיימים, חיבורים רבים בין הלקוח לשרת עלולים להוביל לפסק זמן בחיבור. הבעיה הזו עלולה לגרום לאפקט כדור השלג, כי Memorystore for Redis Cluster מנסה ליצור מחדש חיבורים שפג תוקפם, מה שמגדיל את כמות המשאבים שנדרשים ליצירת חיבורים.

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

המלצות

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

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