בדף הזה מוסבר איך להשתמש ב-Memorystore for Redis Cluster בצורה אופטימלית. בדף הזה מצוינות גם בעיות פוטנציאליות שכדאי להימנע מהן.
שיטות מומלצות לניהול הזיכרון
בקטע הזה מתוארות שיטות לניהול הזיכרון של אשכולות, כדי ש-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.
בהתאם למספר הרפליקות שאתם מקצים לכל צומת, אנחנו ממליצים על יעדי השימוש הבאים ב-CPU של /cluster/cpu/maximum_utilization:
- באשכולות עם רפליקה אחת לכל צומת, כדאי להגדיר ערך של 0.5 שניות ל-
/cluster/cpu/maximum_utilizationהראשי ו-0.5 שניות לרפליקה. - באשכולות עם שתי רפליקות או יותר לכל צומת, כדאי להגדיר ערך
/cluster/cpu/maximum_utilizationשל 0.9 שניות לצומת הראשי ו-0.5 שניות לכל רפליקה.
אם ערכי המדד חורגים מההמלצות האלה, מומלץ להגדיל את מספר השארדים באשכול. אם יש לכם פחות מחמש רפליקות לאשכול, אתם יכולים גם להגדיל את מספר הרפליקות עד למקסימום של חמש רפליקות.
אם באשכול יש ניצול גבוה של המעבד (CPU) או שמשאבי האשכול מוצו (לדוגמה, אם יש יותר מדי חיבורים), יכול להיות שהאשכול לא יפעל כמו שצריך ויהיו חסרים מדדים חיצוניים.
פקודות Redis שצורכות הרבה משאבים
מומלץ מאוד להימנע משימוש בפקודות Redis שדורשות משאבים רבים. שימוש בפקודות האלה עלול לגרום לבעיות הבאות בביצועים:
- זמן אחזור ארוך וזמן קצוב לתפוגה של לקוח
- עומס על הזיכרון שנגרם בגלל פקודות שמגדילות את השימוש בזיכרון
- אובדן נתונים במהלך שכפול וסנכרון של צמתים, כי ה-thread הראשי של Redis חסום
- בדיקות תקינות, ניראות (observability) ויצירת רפליקות במצב של מחסור במשאבים
בטבלה הבאה מפורטות דוגמאות לפקודות Redis שצורכות הרבה משאבים, ומוצעות חלופות שצורכות פחות משאבים.
| קטגוריה | פקודה שצורכת הרבה משאבים | חלופה חסכונית במשאבים |
|---|---|---|
| הפעלה לכל מרחב המפתחות | KEYS |
SCAN |
| הפעלה של קבוצת מפתחות באורך משתנה | LRANGE |
הגבילו את גודל הטווח שבו אתם משתמשים בשאילתה. |
ZRANGE |
הגבילו את גודל הטווח שבו אתם משתמשים בשאילתה. | |
HGETALL |
HSCAN |
|
SMEMBERS |
SSCAN |
|
| חסימת הרצה של סקריפט | EVAL |
מוודאים שהסקריפט לא פועל ללא הגבלת זמן. |
EVALSHA |
מוודאים שהסקריפט לא פועל ללא הגבלת זמן. | |
| הסרת קבצים וקישורים | DEL |
UNLINK |
| פרסום והרשמה | PUBLISH |
SPUBLISH |
SUBSCRIBE |
SSUBSCRIBE |
שיטות מומלצות להגדלת הסף
התרחישים של סף ההתאמה מחולקים לקטגוריות הבאות:
- שינוי קנה המידה של ניצול הזיכרון
- שינוי קנה המידה של ניצול המעבד (CPU)
- התאמה לעומס (scaling) כדי לצמצם נקודות חמות
אם עומס העבודה שלכם מסתמך על פינוי מפתחות, Google לא ממליצה על צמצום ניצול המעבד או הזיכרון. בעומסי העבודה האלה, ניצול הזיכרון מגיע לעיתים קרובות לקיבולת המקסימלית לפני שמתרחשות פעולות פינוי אוטומטיות. העלייה החדה בשימוש בזיכרון חוסמת את פעולות ההקטנה.
בקטעים הבאים מפורטים תרחישים נפוצים וערכי סף של מדדים שעשויים להצדיק שינוי לעומס (scaling).
שינוי קנה המידה של ניצול הזיכרון
כדי לקבוע מתי לשנות את קנה המידה על סמך השימוש בזיכרון, עוקבים אחרי המדדים /cluster/memory/average_utilization ו-/cluster/memory/maximum_utilization. מידע נוסף על המדדים האלה זמין במאמר מדדי מעקב נתמכים.
אם האשכול עומד באחד מהתנאים הבאים, כדאי להפעיל פעולת הרחבה אופקית בהתאם לעומס (scale out):
- ניצול הזיכרון הממוצע של האשכול חורג מהסף המומלץ של 70%.
- ניצול הזיכרון המקסימלי הוא יותר מ-80% וניצול הזיכרון הממוצע הוא יותר מ-50%.
אם האשכול עומד באחד מהתנאים הבאים, כדאי לשקול להפעיל פעולת הקטנה:
- ניצול הזיכרון הממוצע של האשכול יורד מתחת לסף המומלץ של 50%.
- ניצול הזיכרון המקסימלי יורד מתחת ל-60% וניצול הזיכרון הממוצע יורד מתחת ל-40%.
שינוי קנה המידה של ניצול המעבד (CPU)
כדי לקבוע מתי לשנות את קנה המידה על סמך השימוש במעבד (CPU), עוקבים אחרי המדדים /cluster/cpu/average_utilization ו-/cluster/cpu/maximum_utilization.
אם האשכול עומד באחד מהתנאים הבאים, כדאי להפעיל פעולת הרחבה אופקית בהתאם לעומס (scale out):
- ניצול המעבד (CPU) הממוצע של האשכול חורג מהסף המומלץ של 70%.
- ניצול המעבד (CPU) המקסימלי הוא יותר מ-80% וניצול המעבד הממוצע הוא יותר מ-50%.
אם האשכול עומד באחד מהתנאים הבאים, כדאי לשקול להפעיל פעולת הקטנה:
- השימוש הממוצע ב-CPU של האשכול יורד מתחת לסף המוצע של 50%.
- השימוש המקסימלי ב-CPU יורד מתחת ל-60% והשימוש הממוצע ב-CPU יורד מתחת ל-40%.
התאמה לעומס (scaling) כדי לצמצם נקודות חמות
ב-Memorystore for Redis Cluster יש וריאציות של הממוצע והמקסימום של אותו מדד, שבעזרתן אפשר לזהות נקודות חמות של אותה משפחת מדדים. הערך המקסימלי מייצג את הצומת באשכול שהעומס עליו הוא הכי גבוה, והערך הממוצע מייצג את העומס על האשכול כולו. אם הערך המקסימלי גבוה משמעותית מהערך הממוצע, זה מצביע על כך שצומת ספציפי נטען באופן לא פרופורציונלי (נקודה חמה). כדי לפתור את הבעיה, מומלץ להרחיב אופקית בהתאם לעומס (scale out) את האשכול. מידע נוסף זמין במאמר שינוי הקיבולת של אשכול.
אם אתם מבחינים בהבדל משמעותי בין הממוצע לבין השונות המקסימלית, אתם יכולים להריץ את הפקודות INFO memory ו-INFO cpu בצומתי האשכול כדי לאסוף נתונים בזמן אמת ישירות מהאשכול. למידע נוסף על השימוש בפקודות האלה, קראו את המאמר INFO במסמכי התיעוד של Redis.
שיטות מומלצות לשימוש בלקוח Redis
כדי להתחבר לאשכול, האפליקציה צריכה להשתמש בלקוח Redis שמזהה אשכולות. בדוגמאות הקוד של ספריית הלקוח תוכלו למצוא דוגמאות ללקוחות שמזהים אשכולות ודוגמאות להגדרות אישיות. הלקוח צריך לשמור מיפוי של משבצות גיבוב (hash slots) לצמתים המתאימים באשכול, כדי לשלוח בקשות לצמתים הנכונים ולמנוע את התקורה בביצועים שנגרמת כתוצאה מהפניות אוטומטיות באשכול.
מיפוי לקוחות
הלקוחות צריכים לקבל רשימה מלאה של משבצות והצמתים הממופים במצבים הבאים:
כשהלקוח מאותחל, הוא צריך לאכלס את המיפוי הראשוני של המשבצות לצמתים.
כשמתקבלת הפניה אוטומטית מסוג
MOVEDמהשרת, למשל במצב של יתירות כשל כשכל המשבצות ששירתו את הצומת הראשי הקודם נלקחות על ידי הרפליקה, או כשמבצעים חלוקה מחדש של הנתונים למאגרי משנה (sharding) והמשבצות מועברות מהצומת הראשי המקורי לצומת הראשי המיועד.כשמתקבלת שגיאת
CLUSTERDOWNמהשרת או כשהחיבורים לשרת מסוים נתקלים שוב ושוב בפסקי זמן קצובים לתפוגה.כשמתקבלת שגיאת
READONLYמהשרת. זה יכול לקרות כשמורידים בדרגה את המכונה הראשית לרפליקה.בנוסף, הלקוחות צריכים לרענן את הטופולוגיה מדי פעם כדי שהלקוחות יהיו מוכנים לכל שינוי, ולקבל מידע על שינויים שלא בהכרח יגרמו להפניות או לשגיאות מהשרת, למשל כשמוסיפים צומתי רפליקה חדשים. שימו לב שצריך גם לסגור את כל החיבורים הישנים כחלק מרענון הטופולוגיה, כדי להפחית את הצורך לטפל בחיבורים שנכשלו בזמן הרצת הפקודה.
גילוי לקוחות
גילוי הלקוח מתבצע בדרך כלל על ידי הנפקת פקודה CLUSTER SLOT, CLUSTER NODE או CLUSTER SHARDS לשרת Redis. מומלץ להשתמש בפקודה CLUSTER SHARDS. הפקודה CLUSTER SHARDS מחליפה את הפקודה CLUSTER SLOTS (הוצאה משימוש), ומספקת ייצוג יעיל וניתן להרחבה יותר של האשכול.
גודל התגובה לפקודות של גילוי לקוחות באשכול יכול להשתנות בהתאם לגודל האשכול ולטופולוגיה שלו. באשכולות גדולים יותר עם יותר צמתים, התגובה גדולה יותר. לכן חשוב לוודא שמספר הלקוחות שמבצעים את גילוי הטופולוגיה של האשכול לא גדל ללא הגבלה.
רענוני הטופולוגיה האלה יקרים בשרת Redis, אבל הם גם חשובים לזמינות של האפליקציה. לכן חשוב לוודא שכל לקוח שולח בקשת גילוי אחת בכל זמן נתון (ושומר את התוצאה במטמון בזיכרון), ושהמספר של הלקוחות ששולחים את הבקשות מוגבל כדי למנוע עומס יתר על השרת.
לדוגמה, כשאפליקציית הלקוח מופעלת או מאבדת את החיבור לשרת וצריכה לבצע גילוי אשכולות, טעות נפוצה היא שאפליקציית הלקוח שולחת כמה בקשות לחיבור מחדש ולגילוי בלי להוסיף השהיה מעריכית לפני ניסיון חוזר (exponential backoff). זה עלול לגרום לשרת Redis לא להגיב במשך זמן רב, ולגרום לניצול גבוה מאוד של המעבד (CPU).
איך להימנע מעומס יתר של גילוי ב-Redis
כדי לצמצם את ההשפעה של זרם פתאומי של בקשות חיבור וגילוי, מומלץ:
מטמיעים מאגר חיבורים של לקוחות בגודל קטן ומוגבל כדי להגביל את מספר החיבורים הנכנסים בו-זמנית מאפליקציית הלקוח.
כשהלקוח מתנתק מהשרת בגלל זמן קצוב לתפוגה, נסו שוב עם השהיה מעריכית לפני ניסיון חוזר (exponential backoff) עם ריצוד (jitter). כך אפשר למנוע מצב שבו כמה לקוחות מעמיסים על השרת בו-זמנית.
כדי לגלות אשכולות, משתמשים בנקודת הקצה לגילוי של 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 והוספת רפליקות
כדי לגבות את האשכול באמצעות קובצי snapshot של RDB או להוסיף רפליקות לאשכול, מומלץ לפעול לפי השיטות המומלצות הבאות:
ניהול זיכרון
תמונות מצב של RDB משתמשות בפיצול תהליכים ובמנגנון'העתקה בזמן כתיבה' כדי ליצור תמונת מצב של נתוני הצומת. בהתאם לדפוס הכתיבה לצמתים, השימוש בזיכרון של הצמתים גדל ככל שמועתקים דפים שהכתיבה נוגעת בהם. הזיכרון שבשימוש יכול להיות עד פי שניים מגודל הנתונים בצומת.
כדי לוודא שלצמתים יש מספיק זיכרון להשלמת קובץ ה-snapshot, צריך להשאיר או להגדיר את maxmemory ב-80% מקיבולת הצומת, כך ש-20% יישמרו לתקורה. התקורה הזו של הזיכרון, בנוסף למעקב אחרי קובצי ה-snapshot, עוזרת לכם לנהל את עומס העבודה כדי ליצור קובצי snapshot מוצלחים. בנוסף, כשמוסיפים רפליקות, צריך להפחית את תנועת הכתיבה ככל האפשר. מידע נוסף זמין במאמר מעקב אחרי אשכול עם עומס כתיבה גבוה.
תמונות מצב לא עדכניות
שחזור צמתים מתמונת מצב ישנה יכול לגרום לבעיות בביצועים של האפליקציה, כי היא מנסה להתאים כמות משמעותית של מפתחות ישנים או שינויים אחרים במסד הנתונים, כמו שינוי סכימה. אם אתם חוששים משחזור של קובץ snapshot לא עדכני, אתם יכולים להשבית את התכונה RDB persistence. אחרי שמפעילים מחדש את השמירה, תמונת המצב נוצרת במרווח הזמן הבא שנקבע ליצירת תמונות מצב.
ההשפעה של תמונות מצב של RDB על הביצועים
בהתאם לדפוס עומס העבודה, תמונות מצב של RDB יכולות להשפיע על הביצועים של האשכול ולהגדיל את זמן האחזור של האפליקציות. כדי למזער את ההשפעה של קובצי snapshot של RDB על הביצועים, אפשר לתזמן אותם כך שיפעלו בתקופות של תנועה נמוכה באשכול, אם אתם מסתפקים בקובצי snapshot בתדירות נמוכה יותר.
לדוגמה, אם באשכול יש תנועה נמוכה בין 1:00 ל-4:00, אפשר להגדיר את שעת ההתחלה ל-3:00 ואת המרווח ל-24 שעות.
אם המערכת שלכם פועלת בעומס קבוע ודורשת תמונות מצב תכופות, כדאי להעריך בקפידה את ההשפעה על הביצועים ולשקול את היתרונות של שימוש בתמונות מצב של RDB לעומס העבודה.
הוספת רפליקה
כדי להוסיף רפליקה, צריך תמונת מצב של RDB. מידע נוסף על קובצי Snapshot של RDB זמין במאמר ניהול זיכרון.
מתי כדאי להשתמש באשכול באזור יחיד
אם אתם מגדירים אשכול שלא משתמש ברפליקות, מומלץ להשתמש באשכול באזור יחיד. אלו הסיבות לכך:
עלות וביצועים
אם המטרה העיקרית שלכם היא למזער את העלויות ולהשיג ביצועים מקסימליים ללקוחות שנמצאים באותו אזור, מומלץ לבחור באשכול עם אזור יחיד.
מזעור ההשפעה של הפסקות חשמל
כשבוחרים אשכול באזור יחיד, יש פחות סיכוי שהפסקות חשמל באזור ישפיעו על האשכול. אם כל הצמתים נמצאים באזור אחד, הסיכוי שהפסקת חשמל באזור תשפיע על השרת יורד מ-100% ל-33%. יש סיכוי של 33% שהאזור שבו נמצא האשכול יושבת, לעומת סיכוי של 100% שהצמתים שנמצאים באזור הלא זמין יושפעו.
שחזור מהיר
אם מתרחשת הפסקה זמנית בשירות באשכול עם אזור אחד, Memorystore for Redis Cluster מייעל את שחזור הנתונים. אתם יכולים להקצות במהירות אשכול חדש באזור תקין ולהפנות מחדש את האפליקציה, כדי שהפעולות יופרעו כמה שפחות.
שיטות מומלצות לתכנון קיבולת
כדי לוודא שתוכלו להקצות משאבים בהצלחה ולבנות ארכיטקטורות גמישות, מומלץ לפעול לפי השיטות המומלצות הבאות לתכנון קיבולת:
- פריסה בכמה מיקומים: אם אתם לא מצליחים ליצור אשכול באזור המועדף בגלל אילוצי משאבים זמניים, נסו ליצור את האשכול באזור אחר באותו מחוז או במחוז אחר.
- שימוש בגישה חוצת-אזורים: הגדרת הלקוחות כך שיוכלו לגשת לאשכולות שנמצאים באזורים שונים. אם אתם צריכים להקצות אשכול שנמצא באזור אחר בגלל אילוצים של משאבים מקומיים, הלקוחות שלכם יכולים להתחבר לאשכול.
- שימוש ברפליקציה בין אזורים: כדי להעלות בדרגה אשכול משני באזור חלופי לאשכול קריאה או כתיבה ראשי לצורך תוכנית התאוששות מאסון (DR), מבצעים מעבר.
שיטות מומלצות לשימוש ב-Lettuce
בקטע הזה מתוארות שיטות מומלצות לשימוש ב-Lettuce כדי להתחבר לאשכול.
עדכון ערכי הפרמטרים
כשמשתמשים ב-Lettuce, צריך לשנות את הפרמטר validateClusterNodeMembership ל-false. אחרת, כשהטופולוגיה תשתנה, יכול להיות שתקבלו שגיאות unknownPartition.
הפעלת Transport Layer Security (TLS)
בקטע הזה מוסברים יתרונות האבטחה וההשלכות על הביצועים של השימוש ב-Transport Layer Security (TLS), וגם המלצות להפעלה שלו.
יתרונות האבטחה
השימוש ב-TLS מספק את יתרונות האבטחה הבאים:
- אימות באמצעות ניהול זהויות והרשאות גישה (IAM): פרוטוקול TLS משתמש בסוג האימות הזה כדי להגן מפני התקפות זיוף של שרתים, כמו התקפות אדם בתווך.
- הצפנה במעבר: ההצפנה המובנית שלGoogle Cloudמגינה על תעבורת הנתונים ברשת של Google ברמת התשתית. עם זאת, במקרה כזה צריך לסמוך גם על המארח וגם על מקבצי הרשת (network stack) של Google. למרות שההצפנה הזו שקופה ומופעלת כברירת מחדל, היא לא מקצה לקצה. לעומת זאת, ב-TLS נעשה שימוש בהצפנה במעבר בשכבת האפליקציה. ההצפנה מקצה לקצה נותנת לכם יותר שליטה על מפתחות ההצפנה ועל תהליכי ההצפנה.
- הגנה על אסימוני אימות: אם אתם משתמשים באימות IAM, הפעלת TLS מפחיתה את הסיכון לחשיפה ולדליפה של אסימוני האימות.
השלכות על הביצועים
TLS משפיע על הביצועים בדרכים הבאות:
יצירת חיבורים: לקוח ושרת שיצרו סשן TLS יכולים להמשיך את הסשן בלי לחזור על התהליך עתיר המשאבים של יצירת החיבור בין הלקוח לשרת. הפעלת חידוש TLS מפחיתה את התקורה של יצירת חיבור בין הלקוח לשרת.
אם לא מגדירים חידוש TLS, יצירת החיבורים דורשת משאבים רבים. גם בחיבורים חדשים וגם בחיבורים קיימים, חיבורים רבים בין הלקוח לשרת עלולים להוביל לזמן קצוב לתפוגה של החיבור. זה יכול לגרום לאפקט כדור שלג, כי Memorystore for Redis Cluster מנסה ליצור מחדש חיבורים שנגמר הזמן הקצוב שלהם, מה שמגדיל את המשאבים שמשמשים ליצירת חיבורים.
הצפנה ופענוח של נתונים: הצפנה ופענוח של נתונים כוללים פעולות שדורשות הרבה משאבי מעבד (CPU), ומשפיעות גם על הלקוח וגם על השרת. זה יכול להקטין את הקיבולת של האשכול ולהגדיל את זמן האחזור שלו.
המלצות
כשאתם שוקלים אם להפעיל את TLS, מומלץ לבדוק את מדיניות האבטחה שלכם ולהביא בחשבון את היתרונות והחסרונות של TLS. אם אתם בוחרים להפעיל את TLS, חשוב לזכור את הדברים הבאים:
- הפעלת חידוש TLS מפחיתה את התקורה ליצירת חיבורים. חיבור בין הלקוח לשרת נדרש רק לחיבור הראשוני. עם זאת, הרחבה פתאומית של גודל האשכול של הלקוח עלולה לגרום לשיבוש קצר, שנגרם על ידי לחיצת היד המלאה הראשונית של כל מארח לקוח חדש.
- יכול להיות שבחלק מספריות הלקוח לא יהיו אמצעי בקרה מובנים להפעלת TLS, אבל אתם יכולים להשתמש בקוד בהתאמה אישית כדי לשלב את הפונקציונליות הזו באשכולות שלכם.