אפשרויות פריסה של Redis ב-Google Cloud

במסמך הזה מוסבר על פריסות של Redis ועל העברות ל- Google Cloud, כולל האפשרויות והשיקולים לפריסת Redis בשירותים שונים, בהתאם לדרישות שלכם.

‫Redis הוא מאגר של מבני נתונים בזיכרון שאפשר להשתמש בו כמסד נתונים, כמטמון, כברוקר הודעות ועוד. Google Cloud תומך באופן מלא ב-Redis, כולל:

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

ארכיטקטורות

אפשר לפרוס את Redis באחת מהארכיטקטורות הבאות:

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

התמיכה זמינה ב-Memorystore (מנוהל באופן מלא) ובתוכנת קוד פתוח (OSS) של Redis (בניהול עצמי).

הגדרה של ניהול עצמי היא מורכבת יותר. ‫Memorystore היא אפשרות טובה להתחלה מהירה.

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

יש תמיכה ב-Memorystore (מנוהל באופן מלא) וב-Redis OSS (בניהול עצמי).

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

הגדרה של ניהול עצמי היא מורכבת יותר. ‫Memorystore היא אפשרות טובה להתחלה מהירה.

Multi-AZ Multi node צומת יחיד
אשכול (ללא שרתי proxy) כמה צמתים מפצלים את פעולות כתיבת הנתונים עם רסיסי נתונים נפרדים. אפשר להוסיף זמינות גבוהה ועותקים לקריאה. מקרים שבהם צומת אחד לא יכול לספק את תפוקת הכתיבה, ונדרשת זמינות גבוהה או שכפול קריאה. Multi-AZ Multi node Multi node
אשכול (עם שרתי proxy) כמה צמתים מפצלים את פעולות כתיבת הנתונים עם רסיסי נתונים נפרדים. אפשר להוסיף זמינות גבוהה ועותקים לקריאה. שרתי proxy נפרסים בכל צומת ראשי. מקרים שבהם קצב העברת הנתונים לכתיבה לא יכול להיות מוגש על ידי צומת אחד, ונדרשת זמינות גבוהה או שכפול קריאה, ושבהם יקר מדי או לא נוח מדי לבצע רפקטורינג באפליקציות לקוח כדי להשתמש ב-Redis Cluster API, או שיש יתרונות אחרים לשימוש בשרתי proxy.

התמיכה ניתנת על ידי Redis Enterprise Cloud (מנוהל באופן מלא) או Redis Enterprise Software (בניהול עצמי).

ניהול עצמי באמצעות Redis OSS דורש הגדרה מורכבת יותר. ‫Redis Enterprise Cloud היא אפשרות טובה להתחלת עבודה מהירה.

מספר אזורי זמינות או מספר אזורים (Redis Enterprise בלבד) Multi node צומת יחיד

אפשרויות פריסה

Google Cloud מציעה את אפשרויות הפריסה הבאות של Redis:

  • Memorystore for Redis מנוהל באופן מלא על ידי Google Cloud: שירות Redis מנוהל באופן מלא, עם זמינות גבוהה ועמידות, שמנוהל על ידי Google. השירות חסכוני וקל להגדרה, להפעלה ולשינוי גודל. ‫Memorystore תומך ב-Redis Cluster וב-standalone Redis עם זמינות גבוהה אופציונלית.
  • Redis Enterprise בניהול עצמי או בניהול מלא של Redis Ltd.: קלאסטר Redis עם זמינות גבוהה ועמידות, ברישיון של Redis Ltd., עם שתי אפשרויות ניהול: ניהול על ידי Redis Ltd. ‏(Redis Enterprise Cloud) או ניהול עצמי (Redis Enterprise Software) עם תמיכה של Redis Ltd. אפשר לרכוש את Redis Enterprise ישירות מ-Redis Ltd. או דרך Google Cloud Marketplace. חברת Redis Ltd. תומכת בפריסות ב-Compute Engine , ב-Google Kubernetes Engine וב-OpenShift.
  • Redis בקוד פתוח (OSS) בניהול עצמי: אשכול Redis בניהול עצמי או Redis עצמאי עם זמינות גבוהה אופציונלית, שאפשר לפרוס ב-Compute Engine, ב-Google Kubernetes Engine או ב-OpenShift.

בחירת אפשרות פריסה של Redis

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

עץ החלטות לבחירת אפשרות פריסה של Redis.
תרשים 1: גורמים להחלטה ואפשרויות פריסה.

בחירת מודל ניהול של Redis

אפשר לבחור באחד ממודלי הניהול הבאים:

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

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

    • יש לכם כבר כלכלה תפעולית של נפח גדול, ולכן ניהול והפעלה של Redis בארגון שלכם הם הגיוניים מבחינה כלכלית.

    • יש לכם העדפה אסטרטגית לתלות ב-IaaS בלבד.

    • אתם צריכים אופטימיזציות מתקדמות.

הערכת אפשרויות הפריסה

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

אפשרויות מנוהלות באופן מלא

בפריסות מנוהלות באופן מלא, אפשר להשתמש ב-Memorystore או ב-Redis Enterprise Cloud.

Memorystore

בוחרים באפשרות Memorystore אם מתקיים אחד מהתנאים הבאים:

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

מידע נוסף על Memorystore זמין במסמכי התיעוד של המוצר.

אפשרויות פריסה
‫Redis Enterprise Cloud

בוחרים ב-Redis Enterprise Cloud אם מתקיים אחד מהתנאים הבאים:

  • אתם צריכים תכונות ספציפיות שזמינות רק ב-Redis Enterprise Cloud (לדוגמה, כתיבות מרובות פעילות חוצות אזורים עם SLA של 99.999%, תרחיש שימוש ב-RedisSearch).
  • אתם צריכים לשנות את גודל האשכול עבור אפליקציה שלא תומכת ב-Redis Cluster API.

מידע נוסף על Redis Enterprise Cloud זמין במסמכי העזרה של Redis Cloud.

אפשרויות בניהול עצמי

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

‫Redis Enterprise

בוחרים באפשרות של ניהול עצמי של Redis Enterprise אם מתקיים אחד מהתנאים הבאים:

  • האפליקציה שלכם דורשת תכונות ייחודיות, כמו חלוקה מחדש אוטומטית של נתונים (re-sharding) לצורך הרחבת היקף הפעילות, Redis on flash או Redis Enterprise Operator for Kubernetes.
  • לצוות התפעול שלך אין את מערך הכישורים הנדרש לטיפול בבעיות מורכבות ב-Redis באופן פנימי ללא תמיכה מוסמכת של צד שלישי.
  • אתם מעדיפים את התמיכה בארגונים שמספקת Redis Ltd., והעלויות של הרישיונות הנלווים הן סבירות לארגון שלכם.

מידע נוסף על Redis Enterprise Software זמין במאמרי העזרה של Redis Enterprise Software.

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

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

  • אתם רוצים או מעדיפים התאמה אישית מלאה שלא אפשרית בדרך אחרת.
  • לצוות התפעול שלכם יש את מערך הכישורים הנדרש לטיפול בבעיות מורכבות ב-Redis באופן פנימי, ללא תמיכה מוסמכת של צד שלישי.
  • אתם רוצים להימנע מעלויות רישוי.
  • יש לכם משאבים נרחבים לשיפור ביצועים של Redis ושל ליבת Linux, או שתרחיש השימוש שלכם לא דורש שיפור ביצועים.

כשפורסים תוכנה בקוד פתוח של Redis בניהול עצמי, בוחרים יעד פריסה על סמך הבחירה שלכם באסטרטגיית הפלטפורמה. אפשר לפרוס את תוכנת הקוד הפתוח של Redis ב-Compute Engine, ב-Google Kubernetes Engine או ב-OpenShift. ‫GKE Autopilot יכול לצמצם את המאמצים שנדרשים לפריסה ולניהול, אבל יכול להיות שהוא מוגבל יותר, למשל קשה יותר להרחבה.

מידע נוסף על תוכנת קוד פתוח של Redis זמין באתר Redis.io.

מקורות מידע נוספים

השוואה בין תכונות

בטבלה הבאה מסוכמים ההבדלים העיקריים בין כל אפשרויות הפריסה:

מאפייני הפריסה אפשרויות פריסה
Memorystore for Redis ו-Redis Cluster Redis Enterprise Cloud תוכנת Redis Enterprise תוכנה בקוד פתוח של Redis
מנוהל על ידי מנוהל באופן מלא על ידי Google מנוהל באופן מלא על ידי Redis Ltd. בניהול עצמי בניהול עצמי
נתמך על ידי Google Redis Ltd. Redis Ltd. תמיכה עצמית
חויב על ידי Google ‫Redis Ltd. ‎ או Google

התשתית מחויבת על ידי Google.

החיוב על הרישיון והתמיכה של Redis Ltd. מתבצע על ידי Redis Ltd. או על ידי Google.

Google
רכיבי עלות

כל העלויות כלולות.

כולל: תשתיות, רישוי, תמיכה ועלויות ניהול.

מידע נוסף זמין במאמר בנושא תמחור של Memorystore.

כל העלויות כלולות.

כולל: תשתיות, רישוי, תמיכה ועלויות ניהול.

מידע נוסף זמין במאמר תמחור של Redis Enterprise Cloud.

העלויות כוללות רישיון לתוכנה ותמיכה. השימוש בתשתית מחויב בנפרד על ידי Google Cloud.

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

מידע נוסף זמין במאמר בנושא תמחור של תוכנת Redis Enterprise.

אין עמלות שירות או עמלות רישוי. חיוב על השימוש בתשתית מבוצע על ידי Google Cloud.

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

SLA
  • ‫Redis standard: זמן פעילות של 99.9%; זמן השבתה של עד 43.2 דקות בחודש
  • Redis Cluster: זמינות של 99.99% עם HA ב-Multi-AZ; זמן השבתה של עד 4.38 דקות בחודש.

מידע נוסף מופיע בהסכם רמת השירות (SLA) של Memorystore.

  • ‫Redis standard: זמן פעילות של 99.9%; זמן השבתה של עד 43.2 דקות בחודש
  • Redis Cluster: זמינות של 99.99% עם HA ב-Multi-AZ; זמן השבתה של עד 4.38 דקות בחודש.
  • זמינות גבוהה (HA) פעילה-פעילה בכמה אזורים: זמן פעולה של 99.999%; זמן השבתה של עד 26.3 דקות בחודש.

מידע נוסף מופיע בהסכם רמת השירות (SLA) של Redis Cloud.

לא רלוונטי.

אתם אחראים לזמינות.

לא רלוונטי.

אתם אחראים לזמינות.

תוכנית בחינם לא כן תקופת ניסיון בחינם למשך 30 יום לא רלוונטי
סיווג נתונים לרמות לא העברה אוטומטית לרמות אחסון שונות העברה אוטומטית לרמות אחסון שונות לא
מרובה עננים (multi-cloud) לא כן ידנית אפשרי, אבל דורש מאמץ רב
פעיל-פעיל במספר אזורים לא כן ידנית אפשרי, אבל דורש מאמץ רב
מודולים
תאימות תמיכה מובנית במשטרים שונים של תאימות. מידע נוסף זמין במאמר בנושא הצעות לפתרונות תאימות. תמיכה מובנית במשטרים שונים של תאימות. מידע נוסף זמין במרכז המידע של Redis. תמיכה מובנית במשטרים שונים של תאימות. מידע נוסף זמין במרכז המידע של Redis. נדרש ניהול ידני של התאימות. מידע נוסף זמין במאמר בנושא הצעות לפתרונות תאימות.
התאמה לעומס (scaling) של כתיבה באשכול הגדלה והקטנה של התצוגה הגדלה והקטנה של התצוגה סילומיות אופקית (scale out). הגדלת נפח השימוש דורשת מאמץ ידני. בניהול עצמי, נדרשת עבודה ידנית.
איזון מחדש אוטומטי כן כן בניהול עצמי, נדרשת עבודה ידנית בניהול עצמי, נדרשת עבודה ידנית
הוספת זמינות גבוהה המעבר חלק ולא צריך לפרוס מחדש המעבר חלק ולא צריך לפרוס מחדש לא נדרש פריסה מחדש, אבל נדרשת עבודה ידנית נדרשת השקעה משמעותית של עבודה ידנית – יכול להיות שיהיה צורך בפריסה מחדש, בהתאם לארכיטקטורה המקורית
הוספת עותקים לקריאה המעבר חלק ולא צריך לפרוס מחדש המעבר חלק ולא צריך לפרוס מחדש נדרשת השקעה משמעותית של עבודה ידנית – יכול להיות שיהיה צורך בפריסה מחדש, בהתאם לארכיטקטורה המקורית בניהול עצמי, נדרשת עבודה ידנית
מעבר ל-Redis Cluster עם חלוקת נתונים (data-sharded) כשקצב העברת הנתונים לכתיבה (write throughput) כבר לא מספיק נדרשת פריסה מחדש, אבל יש כלים שיכולים להקל על התהליך. צריך לשנות את מבנה הלקוחות כדי לתמוך ב-Redis Cluster API. המעבר חלק ולא צריך לפרוס מחדש המעבר חלק ולא צריך לפרוס מחדש בניהול עצמי, נדרשת עבודה ידנית