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

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

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

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

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

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

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

מעקב אחרי השימוש בזיכרון של מכונה

כדי לעקוב אחרי השימוש בזיכרון של מכונה של Memorystore for Valkey, מומלץ להציג את המדד /instance/memory/maximum_utilization. אם השימוש בזיכרון של המכונה מתקרב ל-80% ואתם צופים שהשימוש בנתונים יגדל, הגדילו את המכונה כדי לפנות מקום לנתונים חדשים.

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

• מגדילים את המכונה.
• מפחיתים את הערך של פרמטר ההגדרה maxmemory.

אם נתקלתם בבעיות, אתם יכולים לפנות אל Google Cloud Customer Care.

שינוי קנה המידה של המקטעים במצב אשכול מופעל

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

אם המכונה עומדת באחד מהתנאים הבאים, כדאי להפעיל פעולת הרחבה אופקית (scale out):

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

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

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

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

כדי לקבוע מתי לשנות את קנה המידה על סמך השימוש במעבד (CPU), עוקבים אחרי המדדים /instance/cpu/average_utilization ו-/instance/cpu/maximum_utilization.

אם המכונה עומדת באחד מהתנאים הבאים, כדאי להפעיל פעולת הרחבה אופקית (scale out):

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

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

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

התאמה לעומס (scaling) כדי לצמצם נקודות חמות

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

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

שיטות מומלצות ללקוחות Valkey

איך להימנע מעומס יתר של חיבורים ב-Valkey

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

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

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

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

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

• הגדרת פרמטרים של 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 שניות.

במכונות שבהן מופעל מצב אשכול (Cluster Mode Enabled)

כדי להתחבר למכונה של Memorystore for Valkey עם מצב אשכול מופעל, צריך להשתמש בלקוח Valkey שמזהה אשכולות. במאמר דוגמאות קוד בספריית הלקוח מופיעות דוגמאות ללקוחות שמזהים אשכולות ולהגדרות שלהם. הלקוח צריך לשמור מפה של משבצות גיבוב (hash slots) לצמתים המתאימים במכונה כדי לשלוח בקשות לצמתים הנכונים. כך נמנע עומס על הביצועים שנגרם כתוצאה מהפניות לכתובות אחרות.

מיפוי לקוחות

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

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

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

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

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

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

גילוי לקוחות

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

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

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

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

שימוש בנקודת קצה (endpoint) לזיהוי צמתים

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

במכונות שבהן מצב האשכול מושבת

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

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

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

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

אם אתם משתמשים באסטרטגיה הזו, יכול להיות שתקבלו את הודעת השגיאה הבאה:

READONLY You can't write against a read only replica.

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

שיטות מומלצות לשמירת נתונים

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

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

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

ניהול זיכרון

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

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

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

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

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

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

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

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

שיטות מומלצות לתכנון קיבולת

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

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

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

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

המלצות

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

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