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

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

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

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

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

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

המלצות

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

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