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

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

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

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

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

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

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

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

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

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

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

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

מיפוי לקוחות

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

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

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

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

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

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

חיפוש לקוחות

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

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

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

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

איך נמנעים מעומס יתר על Redis

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

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

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

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

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

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

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

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

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

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

כשמשתמשים ב-Lettuce, צריך לשנות את הפרמטר validateClusterNodeMembership ל-false. אחרת, כשיהיו שינויים בטופולוגיה, יכול להיות שתקבלו שגיאות unknownPartition.

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

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

הטבות אבטחה

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

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

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

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

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

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

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

המלצות

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

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