בדף הזה מוסברות שיטות מומלצות לשימוש ב-Memorystore for Memcached.
תכנון הארכיטקטורה של האפליקציה כך שתטפל בחיפושים במטמון שלא הניבו תוצאות
כדאי לפעול לפי השיטות המומלצות לעיצוב מטמון, ולעצב את המטמון כך שיטפל במקרים של החמצת מטמון ובמקרים שבהם השירות לא זמין. מידע על המחויבות של Memorystore for Memcached לזמן פעולה תקינה מופיע בהסכם רמת השירות.
תכננו את האפליקציה כך שפספוסים במטמון והשבתה זמנית של השירות לא ימנעו מהאפליקציה לאחזר נתונים ממסד הנתונים הבסיסי שמופע Memcached תומך בו.
בנוסף, אם נתקלתם במצב שבו אין אפשרות לגשת למרחב המפתחות, צריך להמתין ולנסות שוב באמצעות השהיה מעריכית לפני ניסיון חוזר (exponential backoff). חשוב להגדיר מגבלת זמן שבסיומה תופסק אסטרטגיית הניסיון החוזר.
התחברות לצמתי Memcached
כששולחים שאילתות לצמתי Memcached באמצעות פקודות כמו set, get ו-delete, צריך להתחבר ישירות לכתובות ה-IP של הצמתים. אפשר להריץ את הפקודות האלה בנקודת הקצה של גילוי אוטומטי, אבל לא מומלץ לעשות את זה כי זה גורם לירידה בביצועים של האפליקציה.
מומלץ להפעיל גילוי אוטומטי
מומלץ להשתמש בשירות הגילוי האוטומטי של Memorystore for Memcached. השירות הזה מבצע אוטומטית ניהול של כתובות IP של אשכולות כשמוסיפים או מסירים צמתים מהאשכול. הוראות להגדרת גילוי אוטומטי של האשכול זמינות במאמר שימוש בשירות הגילוי האוטומטי.
הגדרת הפרמטר max-item-size בצורה נכונה
בקטע הזה מוסבר איך הכי טוב להגדיר את הפרמטר max-item-size. במאמר הגדרת מופעים של Memcached מוסבר איך לשנות את פרמטר ההגדרה הזה.
רשימה מלאה של פרמטרים זמינים להגדרת Memcached מופיעה במאמר הגדרות Memcached.
ערכים נתמכים וערכי ברירת מחדל
ב-Memcached בקוד פתוח, הערך המינימלי של max-item-size הוא 1KiB, הערך המקסימלי הוא 1 GiB וערך ברירת המחדל הוא 1 MiB. ב-Memorystore for Memcached, הערך המינימלי הוא 512 KiB, הערך המקסימלי הוא 128
MiB וערך ברירת המחדל הוא 1 MiB. בנוסף, כל ערך שמגדירים בהגדרה הזו צריך להתחלק ב-512 KiB ללא שארית.
שמירת רשומה במטמון שגודלה גדול מ-max-item-size
כשמנסים לשמור במטמון רשומה שגדולה מהערך המוגדר של max-item-size, הפעולה ב-Memcached נכשלת ומוחזר הערך false. אם אפשר, כדאי להוסיף לאפליקציה לוגיקה שתציג את השגיאה הזו מלקוח Memcached OSS, כדי שתוכלו לנפות את הבאגים. ניסיון לשמור במטמון רשומה שגודלה גדול מ-max-item-size שמוגדר, עלול לגרום לזמן אחזור גבוה במופע.
הגדרה של max-item-size לערך המקסימלי
אפשר לפתור חלק מהבעיות בפרמטר max-item-size על ידי הגדרת הערך המקסימלי, אבל זו לא שיטה מומלצת, ולכן לא כדאי להשתמש בה בסביבת ייצור. ניהול הזיכרון ב-Memcached מבוסס על slabs, ואחסון פריטים שגדולים מה-slab מוביל להקצאת זיכרון לא יעילה.
איך נמנעים מבעיות בהגדרות של max-item-size
קודם כל, צריך להבין מה הגודל המקסימלי של הפריט שנדרש למטמון. כדי ליצור מרווח ביטחון, כדאי להגדיר את max-item-size כגדול יותר מגודל הפריט הכי גדול.
שימו לב: גודל הערכים שנכתבים למטמון באפליקציה עשוי להשתנות עם הזמן. יכול להיות גם שהאשכול הוגדר בצורה שגויה (לדוגמה, כשמבצעים העברה מסביבה אחת לסביבה אחרת). אמצעי נוסף שאפשר לנקוט הוא אימות הגודל המקסימלי של הפריט באפליקציה, כך שהבקשה תידחה אם האפליקציה תנסה לשמור במטמון פריטים גדולים יותר מההגדרה שנקבעה.
איך מאזנים אשכול Memcached לא מאוזן
איך נוצרים אשכולות לא מאוזנים ומהם הסיכונים הכרוכים בכך
במקרים נדירים, כשיוצרים צמתים של מכונות Memcached, יכול להיות שהם יתחלקו בצורה לא אחידה בין אזורים באזור. זה קורה אם תחום מסוים לא זמין באותו זמן שבו אתם מקצים את האשכול.
במקרה של אשכול לא מאוזן, הסיכוי לאובדן נתונים גדל כי הצמתים לא מחולקים בצורה אחידה ככל האפשר. האשכול לא מבצע איזון מחדש באופן אוטומטי כשאזור הזמינות שהיה מושבת חוזר למצב אונליין.
איך מאזנים מחדש את האשכול
אפשר לאזן מחדש את האשכול על ידי הגדלה זמנית של מספר הצמתים באשכול, ולאחר מכן הקטנה של מספר הצמתים למספר המקורי. פעולת ההרחבה והצמצום הזו מאפשרת למערכת Memorystore for Memcached לחלק מחדש את הצמתים באופן שווה בין האזורים הזמינים.
ההצלחה של השיטה הזו לאיזון מחדש של האשכול תלויה בזמינות של האזורים הרלוונטיים.בשלב הזה, לא מופיעים אזורים זמינים או לא זמינים, כך שאפשר לדעת אם האזור מחובר רק אם הצמתים מאוזנים בצורה נכונה במהלך פעולת ההרחבה. Google Cloud
שיטות מומלצות לשימוש ב-Cloud Monitoring
כדי לעקוב אחרי הביצועים של המטמון לאורך זמן, כדאי להשתמש ב-Cloud Monitoring כדי לעקוב אחרי כמה מדדים חיוניים של Memorystore for Memcached:
- שימוש בזיכרון (
memcache.googleapis.com/node/cache_memory) - אחוז השימוש במעבד (
memcache.googleapis.com/node/cpu/utilization)
מעקב אחרי שני המדדים האלה לאורך זמן עוזר לכם לקבוע עד כמה נעשה שימוש יעיל באשכול, והאם כדאי להגדיל או להקטין את גודל האשכול.
לדוגמה, אם המדדים מצביעים על כך שהשימוש בזיכרון ובמעבד גדל לאורך זמן ליותר מ-80%, יכול להיות שהמגמה הזו תימשך. כתוצאה מכך, יכול להיות שתצטרכו להגדיל את גודל המופע בשלב מוקדם כדי שבמטמון יהיה מקום לאחסון ערכים חדשים ככל שדרישות המשאבים של האפליקציה יגדלו.
מומלץ להגדיר התראה למצב שבו השימוש בזיכרון ובמעבד מגיע ל-80%.
לחלופין, מעקב אחרי המדדים האלה לאורך זמן עשוי להצביע על כך שאתם לא משתמשים בכל נפח האחסון ומשאבי ה-CPU שיש לכם כרגע. במקרה כזה, כדאי להקטין את גודל האשכול כדי לחסוך בעלויות.