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

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

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

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

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

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

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

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

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

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

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

שינוי קנה מידה של שברי מסד נתונים במצב Cluster Mode Enabled

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

עבור מופעים שמופעל בהם מצב אשכול

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

מיפוי לקוחות

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

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

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

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

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

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

חיפוש לקוחות

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

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

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

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

שימוש בנקודת קצה לגילוי לצורך גילוי צמתים

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

למופעים שבהם מצב האשכול מושבת

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

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

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

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

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

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

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

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

ניהול זיכרון

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

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

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

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

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

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

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

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

הוספת עותק

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

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

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

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

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

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

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

שחזור מהיר

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

הפעלה של אבטחת שכבת התעבורה (TLS)

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

הטבות אבטחה

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

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

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

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

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

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

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

המלצות

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

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