במאמר הזה מתוארות ארכיטקטורות פריסה, תרחישים לדוגמה ושיטות מומלצות לניהול מסדי נתונים בכמה עננים. הוא מיועד לאדריכלים ולמהנדסים שמתכננים ומטמיעים אפליקציות עם שמירת מצב (stateful) בענן אחד או בכמה עננים.
ארכיטקטורות של אפליקציות מרובות-עננים שניגשות למסדי נתונים תלויות בתרחיש לדוגמה. אין ארכיטקטורה אחת של אפליקציה עם שמירת מצב שיכולה לתמוך בכל תרחישי השימוש בריבוי עננים. לדוגמה, פתרון מסד הנתונים הטוב ביותר לתרחיש לדוגמה של cloud bursting שונה מפתרון מסד הנתונים הטוב ביותר לאפליקציה שפועלת בו-זמנית בכמה סביבות ענן.
בעננים ציבוריים כמו Google Cloud, יש טכנולוגיות שונות של מסדי נתונים שמתאימות לתרחישים ספציפיים של שימוש בריבוי עננים. כדי לפרוס אפליקציה במספר אזורים בענן ציבורי אחד, אפשר להשתמש במסד נתונים בענן ציבורי שמנוהל על ידי ספק במספר אזורים, כמו Spanner. כדי לפרוס אפליקציה שניתן להעביר בין עננים ציבוריים, יכול להיות שעדיף לבחור במסד נתונים שלא תלוי בפלטפורמה, כמו AlloyDB Omni או PostgreSQL.
במסמך הזה מוצגת הגדרה של אפליקציית מסד נתונים עם שמירת מצב (stateful), ואחריה ניתוח של תרחיש לדוגמה של מסד נתונים בכמה עננים. לאחר מכן מוצג סיווג מפורט של מערכות מסדי נתונים לארכיטקטורות של פריסה בכמה עננים, על סמך תרחישי השימוש.
בנוסף, מוצג במסמך עץ החלטות לבחירת מסדי נתונים, שמתאר נקודות החלטה חשובות לבחירת טכנולוגיית מסד נתונים מתאימה. בסוף השיעור נדון בשיטות מומלצות לניהול מסדי נתונים בכמה עננים.
מונחים והגדרות מרכזיים
בקטע הזה מופיעה טרמינולוגיה ומוגדרת אפליקציית מסד הנתונים הגנרית עם שמירת המצב שבה משתמשים במסמך הזה.
הסברים על המונחים
- ענן ציבורי. ענן ציבורי מספק תשתית (בדרך כלל גלובלית) עם כמה דיירים ושירותים, שבהם הלקוחות יכולים להשתמש כדי להריץ את עומסי העבודה שלהם בסביבת הייצור. Google Cloud הוא ספק שירותי ענן ציבורי שמספק הרבה שירותים מנוהלים, כולל GKE ומסדי נתונים מנוהלים.
- ענן היברידי. ענן היברידי הוא שילוב של ענן ציבורי עם מרכז נתונים מקומי אחד או יותר. לקוחות של ענן היברידי יכולים לשלב את השירותים המקומיים שלהם עם שירותים נוספים שמספק ענן ציבורי.
- ריבוי עננים. סביבה מרובת-עננים היא שילוב של כמה עננים ציבוריים ומרכזי נתונים מקומיים. ענן היברידי הוא תת-קבוצה של סביבה מרובת-עננים.
- מיקום הפריסה. מיקום תשתית הוא מיקום פיזי שבו אפשר לפרוס ולהריץ עומסי עבודה, כולל אפליקציות ומסדי נתונים. לדוגמה, ב- Google Cloud, מיקומי הפריסה הם אזורים ותחומים. ברמה מופשטת, אזור או תחום בענן ציבורי ומרכז נתונים מקומי הם מיקומי פריסה.
אפליקציות של מסדי נתונים עם שמירת מצב (stateful)
כדי להגדיר תרחישים לדוגמה של ריבוי עננים, במאמר הזה נעשה שימוש בארכיטקטורה גנרית של אפליקציית מסד נתונים עם שמירת מצב, כמו שמוצג בתרשים הבא.
בתרשים מוצגים הרכיבים הבאים:
- מסד נתונים. מסד נתונים יכול להיות מופע יחיד, כמה מופעים במקביל, או מסד נתונים מבוזר, שנפרס בצומתי מחשוב או זמין כשירות מנוהל בענן.
- שירותי אפליקציות. השירותים האלה משולבים כאפליקציה שמיישמת את הלוגיקה העסקית. שירותי האפליקציה יכולים להיות כל אחד מהבאים:
- מיקרו-שירותים (microservices) ב-Kubernetes.
- תהליכים גסים שפועלים במכונה וירטואלית אחת או יותר.
- אפליקציה מונוליתית במכונה וירטואלית אחת גדולה.
- קוד ללא שרת (serverless) בפונקציות Cloud Run או ב-Cloud Run. חלק משירותי האפליקציות יכולים לגשת למסד הנתונים. אפשר לפרוס כל שירות של אפליקציה כמה פעמים. כל פריסה של שירות אפליקציה היא מכונה של אותו שירות אפליקציה.
- לקוחות של אפליקציות. לקוחות של אפליקציות ניגשים לפונקציונליות שמסופקת על ידי שירותי האפליקציות. לקוחות של אפליקציות יכולים להיות אחד מהבאים:
- לקוחות פרוסים, שבהם הקוד פועל במכונה, במחשב נייד או בטלפון נייד.
- לקוחות שלא נפרסו, שבהם קוד הלקוח פועל בדפדפן. מכונות של לקוחות אפליקציה תמיד ניגשות למכונה אחת או יותר של שירותי אפליקציה.
בהקשר של דיון על מסד נתונים בכמה עננים, ההפשטה הארכיטקטונית של אפליקציה עם שמירת מצב מורכבת ממסד נתונים, משירותי אפליקציה ומלקוחות של אפליקציה. בהטמעה של אפליקציה, גורמים כמו השימוש במערכות הפעלה או בשפות התכנות שבהן משתמשים יכולים להשתנות. עם זאת, הפרטים האלה לא משפיעים על ניהול מסדי נתונים בכמה עננים.
תורים וקבצים כשירותי אחסון נתונים
יש הרבה משאבים זמינים לשמירת נתונים בשירותי אפליקציות. המשאבים האלה כוללים מסדי נתונים, תורים וקבצים. כל משאב שמירת נתונים מספק מודלים של נתוני אחסון ודפוסי גישה שמותאמים למודלים האלה. למרות שאפליקציות משתמשות בתורים, במערכות להעברת הודעות ובמערכות קבצים, בקטע הבא נתמקד באופן ספציפי במסדי נתונים.
למרות שאותם שיקולים לגבי גורמים כמו מיקום הפריסה, שיתוף המצב, שכפול סינכרוני ואסינכרוני של מסדי נתונים מרובי-עננים רלוונטיים לתורים ולקבצים, הדיון הזה חורג מהיקף המסמך.
Networking
בארכיטקטורה של אפליקציה גנרית עם שמירת מצב (שמוצגת שוב בתרשים הבא), כל חץ בין הרכיבים מייצג קשר תקשורת דרך חיבור לרשת – לדוגמה, לקוח של אפליקציה שניגש לשירות של אפליקציה.
החיבור יכול להיות בתוך אזור או בין אזורים, מחוזות או עננים. יכולים להיות חיבורים בין כל שילוב של מיקומי פריסה. בסביבות עם כמה עננים, הרישות בין העננים הוא שיקול חשוב ויש כמה אפשרויות שאפשר להשתמש בהן. למידע נוסף על רשתות בעננים שונים, קראו את המאמרים Cross-Cloud Network לאפליקציות מבוזרות והתחברות אל Google Cloud: הסבר על האפשרויות שלכם לרשתות.
בתרחישים לדוגמה שבמסמך הזה, אנחנו מניחים את ההנחות הבאות:
- יש חיבור מאובטח לרשת בין העננים.
- מסדי הנתונים והרכיבים שלהם יכולים לתקשר זה עם זה.
מבחינה לא פונקציונלית, גודל הרשת, כלומר קצב העברת הנתונים וזמן האחזור, עשוי להשפיע על זמן האחזור וקצב העברת הנתונים של מסד הנתונים. מבחינה פונקציונלית, בדרך כלל אין השפעה על הרשת.
תרחישים לדוגמה של מסדי נתונים בכמה עננים
בקטע הזה מוצג מבחר של תרחישים נפוצים לניהול מסדי נתונים בכמה עננים. בתרחישים לדוגמה האלה, ההנחה היא שיש קישוריות מאובטחת לרשת בין העננים לבין צומתי מסד הנתונים.
העברת אפליקציות
בהקשר של ניהול מסדי נתונים בכמה עננים, העברת אפליקציות מתייחסת להעברה של אפליקציה, כל שירותי האפליקציה ומסד הנתונים מהענן הנוכחי לענן היעד. יש הרבה סיבות שבגללן ארגון עשוי להחליט להעביר אפליקציה, למשל כדי להימנע ממצב של תחרות עם ספק שירותי הענן, כדי לשדרג את הטכנולוגיה או כדי להפחית את עלות הבעלות הכוללת (TCO).
בהעברת אפליקציות, המטרה היא להפסיק את הייצור בענן הנוכחי ולהמשיך את הייצור בענן היעד אחרי שההעברה מסתיימת. שירותי האפליקציה צריכים לפעול בענן היעד. כדי להטמיע את השירותים, אפשר להשתמש בגישת העברה ללא שינוי. בגישה הזו, אותו קוד נפרס בענן היעד. כדי להטמיע מחדש את השירות, אפשר להשתמש בטכנולוגיות הענן המודרניות שזמינות בענן היעד.
מבחינת מסד הנתונים, כדאי לשקול את האפשרויות החלופיות הבאות להעברת אפליקציות:
- העברה של מסד נתונים בשיטת Lift and Shift: אם אותו מנוע של מסד נתונים זמין בענן היעד, אפשר להעביר את מסד הנתונים בשיטת Lift and Shift כדי ליצור פריסה זהה בענן היעד.
- העברה של מסד נתונים לגרסה מקבילה מנוהלת: אפשר להעביר מסד נתונים בניהול עצמי לגרסה מנוהלת של אותו מנוע של מסד נתונים, אם הוא זמין אצל ספק שירותי הענן היעד.
- מודרניזציה של מסדי נתונים: בעננים שונים יש טכנולוגיות שונות של מסדי נתונים. למסדי נתונים שמנוהלים על ידי ספק שירותי ענן יכולים להיות יתרונות כמו הסכמי רמת שירות (SLA) מחמירים יותר, מדרגיות ותוכנית התאוששות מאסון (DR) אוטומטית.
לא משנה באיזו אסטרטגיית פריסה תבחרו, העברת מסד נתונים היא תהליך שלוקח זמן כי צריך להעביר נתונים מהענן הנוכחי לענן היעד. אפשר להשתמש בגישה של ייצוא וייבוא שגורמת לזמן השבתה, אבל עדיף להשתמש בהעברה עם זמן השבתה מינימלי או ללא זמן השבתה. הגישה הזו מצמצמת את זמן ההשבתה של האפליקציה, וההשפעה שלה על הארגון ועל הלקוחות שלו היא הקטנה ביותר. עם זאת, בדרך כלל נדרשת הגדרת העברה מורכבת יותר, כי היא כוללת טעינה ראשונית, שכפול מתמשך, מעקב, אימות פרטני וסנכרון בזמן המעבר. כדי לתמוך בתרחישי חזרה למצב קודם, צריך להטמיע מנגנון שכפול הפוך כדי לסנכרן את השינויים בחזרה למסד הנתונים של המקור אחרי המעבר למסד הנתונים של היעד.
תוכנית התאוששות מאסון (DR)
תוכנית התאוששות מאסון (DR) מתייחסת ליכולת של אפליקציה להמשיך לספק שירותים ללקוחות שלה במהלך הפסקה זמנית בפעילות באזור. כדי להבטיח התאוששות מאסון, צריך לפרוס את האפליקציה בשני אזורים לפחות ולהכין אותה להפעלה בכל שלב. בסביבת הייצור, האפליקציה פועלת באזור הראשי. עם זאת, אם מתרחשת הפסקה, אזור משני הופך לאזור הראשי. אלה מודלים שונים של מוכנות להתאוששות מאסון:
- המתנה חמה. האפליקציה פרוסה בשני אזורים או יותר (ראשי ומשני), והיא פועלת באופן מלא בכל אזור. אם האזור הראשי נכשל, האפליקציה באזור המשני יכולה לקבל מיד את תנועת הלקוחות של האפליקציה.
- המתנה קרה. האפליקציה פועלת באזור הראשי, אבל היא מוכנה להפעלה באזור משני (אבל לא פועלת). אם האזור הראשי נכשל, האפליקציה מופעלת באזור המשני. ההפסקה בפעילות האפליקציה נמשכת עד שהאפליקציה יכולה לפעול ולספק את כל שירותי האפליקציה ללקוחות שלה.
- אין מצב המתנה. במודל הזה, קוד האפליקציה מוכן לפריסה אבל עדיין לא נפרס באזור המשני (ולכן לא משתמש במשאבים שנפרסו). אם יש הפסקה זמנית בשירות באזור הראשי, הפריסה הראשונה של האפליקציה צריכה להיות באזור המשני. הפריסה הזו מעבירה את האפליקציה לאותו מצב כמו גיבוי קר, כלומר צריך להפעיל אותה. בגישה הזו, משך הזמן שבו האפליקציה לא זמינה ארוך יותר בהשוואה למצב של גיבוי קר, כי קודם צריך לפרוס את האפליקציה, כולל יצירת משאבים בענן.
מנקודת המבט של מסד הנתונים, מודלי המוכנות שנדונו ברשימה הקודמת תואמים לגישות הבאות של מסד הנתונים:
- מסד נתונים שמסונכרן לפי טרנזקציות. מסד הנתונים הזה תואם למודל הגיבוי החם. כל טרנזקציה באזור הראשי מתבצעת בתיאום סינכרוני באזור המשני. כשהאזור המשני הופך לאזור הראשי במהלך הפסקה, מסד הנתונים עקבי וזמין באופן מיידי. במודל הזה, גם היעד להתאוששות מאסון (RPO) וגם היעד לזמן התאוששות (RTO) הם אפס.
- מסד נתונים שמשוכפל באופן אסינכרוני. מסד הנתונים הזה תואם גם למודל הגיבוי החם. מכיוון שהרפליקציה של מסד הנתונים מהאזור הראשי לאזור המשני היא אסינכרונית, יכול להיות שאם האזור הראשי ייכשל, חלק מהטרנזקציות ישוכפלו לאזור המשני. מסד הנתונים באזור המשני מוכן לעומס הייצור, אבל יכול להיות שהנתונים בו לא הכי עדכניים. לכן, יכול להיות שהאפליקציה תאבד טרנזקציות שלא ניתן לשחזר. בגלל הסיכון הזה, בגישה הזו ה-RTO הוא אפס, אבל ה-RPO גדול מאפס.
- מסד נתונים במצב המתנה. מסד הנתונים הזה תואם למודל הגיבוי החם. מסד הנתונים נוצר בלי נתונים. כשהאזור הראשי נכשל, צריך לטעון את הנתונים למסד הנתונים הלא פעיל. כדי להפעיל את הפעולה הזו, צריך לבצע גיבוי רגיל באזור הראשי ולהעביר אותו לאזור המשני. הגיבוי יכול להיות מלא או מצטבר, בהתאם למה שהמנוע של מסד הנתונים תומך בו. בשני המקרים, מסד הנתונים מוגדר חזרה לגיבוי האחרון, ומנקודת המבט של האפליקציה, יכול להיות שטרנזקציות רבות יאבדו בהשוואה לאזור הראשי. הגישה הזו אולי חסכונית, אבל הערך שלה נפגע בגלל הסיכון שכל הטרנזקציות מאז הגיבוי הזמין האחרון עלולות ללכת לאיבוד, כי מצב מסד הנתונים לא מעודכן.
- אין מסד נתונים. המודל הזה שווה ערך למקרה של ללא המתנה. באזור המשני לא מותקן מסד נתונים, ואם האזור הראשי נכשל, צריך ליצור מסד נתונים. אחרי שיוצרים את מסד הנתונים, כמו במקרה של מסד נתונים במצב המתנה, צריך לטעון אותו בנתונים לפני שהוא יהיה זמין לאפליקציה.
הגישות להתאוששות מאסון שמתוארות במאמר הזה רלוונטיות גם אם משתמשים בענן ראשי ובענן משני במקום באזור ראשי ובאזור משני. ההבדל העיקרי הוא שבגלל ההטרוגניות של הרשת בין העננים, זמן האחזור בין העננים עשוי לגדול בהשוואה למרחק הרשת בין אזורים בתוך ענן. פערים אחרים יכולים לנבוע מתכונות שונות ומהגדרות ברירת מחדל של מסדי נתונים מנוהלים של ספקי שירותי ענן שונים.
הסבירות לכשל בענן שלם נמוכה מהסבירות לכשל באזור. עם זאת, יכול להיות שעדיין יהיה שימושי לארגונים לפרוס אפליקציה בשני עננים. הגישה הזו יכולה לעזור להגן על ארגון מפני כשל, או לעזור לו לעמוד בתקנות עסקיות או בתקנות של התחום.
גישה אחרת לתוכנית התאוששות מאסון היא להגדיר אזור ראשי ואזור משני, וענן ראשי וענן משני. כך ארגונים יכולים לבחור את תוכנית ההתאוששות מאסון (DR) שהכי מתאימה למצב הכשל. כדי לאפשר לאפליקציה לפעול, אפשר להשתמש באזור משני או בענן משני, בהתאם לחומרת ההפסקה.
Cloud bursting
Cloud bursting מתייחס להגדרה שמאפשרת להגדיל את תנועת הלקוחות באפליקציה במיקומי פריסה שונים. התפרצות של אפליקציה מתרחשת כשהביקוש לקיבולת עולה, ומיקום המתנה מספק קיבולת נוספת. מיקום ראשי תומך בתנועה הרגילה, ומיקום חלופי יכול לספק קיבולת נוספת במקרה שתנועת הלקוחות באפליקציה גדלה מעבר למה שהמיקום הראשי יכול לתמוך בו. מופעים של שירות האפליקציה פרוסים גם במיקום הראשי וגם במיקום הגיבוי.
הטמעה של Cloud bursting בעננים שונים, כשאחד מהם הוא הענן הראשי והשני הוא הענן המשני. הוא משמש בהקשר של ענן היברידי כדי להגדיל מספר מוגבל של משאבי מחשוב במרכזי נתונים מקומיים באמצעות משאבי מחשוב גמישים בענן ציבורי.
אפשרויות התמיכה במסדי נתונים:
- פריסה במיקום הראשי. בפריסה הזו, מסד הנתונים נפרס רק במיקום הראשי ולא במיקום החלופי. כשהאפליקציה עוברת למצב של עומס חריג, האפליקציה במיקום הגיבוי ניגשת למסד הנתונים במיקום הראשי.
- פריסה במיקום ראשי ובמיקום חלופי. הפריסה הזו תומכת גם במיקום הראשי וגם במיקום החלופי. מכונה של מסד נתונים נפרסת בשני המיקומים, והגישה אליה מתבצעת באמצעות מכונות של שירותי האפליקציה של אותו מיקום, במיוחד במקרה של התפרצות. כמו במאמר תוכנית התאוששות מאסון (DR) בתוך עננים וביניהם, אפשר לסנכרן את שני מסדי הנתונים באופן טרנזקציוני או אסינכרוני. בסנכרון אסינכרוני יכול להיות עיכוב. אם מתבצעים עדכונים במיקום הגיבוי, צריך להפיץ את העדכונים האלה בחזרה למיקום הראשי. אם אפשר לבצע עדכונים בו-זמנית בשני המיקומים, צריך להטמיע פתרון לבעיות של התנגשויות.
Cloud bursting הוא תרחיש נפוץ לשימוש בעננים היברידיים כדי להגדיל את הקיבולת במרכזי נתונים מקומיים. זו גם גישה שאפשר להשתמש בה בעננים ציבוריים, כשהנתונים צריכים להישאר בתוך המדינה. במצבים שבהם לענן ציבורי יש רק אזור אחד במדינה, אפשר להרחיב לאזור של ענן ציבורי אחר באותה מדינה. כך הנתונים נשארים במדינה, ועדיין אפשר להתמודד עם מגבלות המשאבים באזורים של הענן הציבורי.
שימוש בשירותי ענן מהשורה הראשונה
חלק מהאפליקציות דורשות שירותי ענן ומוצרים מיוחדים שלא זמינים בענן אחד. לדוגמה, אפליקציה יכולה לבצע עיבוד של לוגיקה עסקית של נתונים עסקיים בענן אחד, וניתוח של הנתונים העסקיים בענן אחר. בתרחיש לדוגמה הזה, החלקים של עיבוד הלוגיקה העסקית והחלקים של ניתוח הנתונים באפליקציה נפרסים בעננים שונים.
מנקודת מבט של ניהול נתונים, אלה תרחישי השימוש:
- נתונים מחולקים. לכל חלק באפליקציה יש מסד נתונים משלו (מחיצה נפרדת), ואף אחד ממסדי הנתונים לא מחובר ישירות לאחרים. האפליקציה שמנהלת את הנתונים כותבת פעמיים את כל הנתונים שצריכים להיות זמינים בשני מסדי הנתונים (המחיצות).
- מסד נתונים שמשוכפל באופן אסינכרוני. אם נתונים מענן אחד צריכים להיות זמינים בענן השני, יכול להיות שיתאים קשר של רפליקציה אסינכרונית. לדוגמה, אם אפליקציית ניתוח נתונים דורשת את אותה קבוצת נתונים או קבוצת משנה של קבוצת הנתונים של אפליקציה עסקית, אפשר לשכפל את קבוצת הנתונים של האפליקציה העסקית בין העננים.
- מסד נתונים שמסונכרן לפי טרנזקציות. מסדי נתונים כאלה מאפשרים לכם להפוך את הנתונים לזמינים בשני חלקי האפליקציה. כל עדכון מכל אחת מהאפליקציות עקבי מבחינת טרנזקציות וזמין לשני מסדי הנתונים (המחיצות) באופן מיידי. מסדי נתונים שמסונכרנים בטרנזקציות פועלים למעשה כמסד נתונים מבוזר אחד.
שירותים מבוזרים
שירות מבוזר נפרס ומופעל בשני מיקומי פריסה או יותר. אפשר לפרוס את כל המכונות של השירות בכל מיקומי הפריסה. לחלופין, אפשר לפרוס חלק מהשירותים בכל המיקומים, וחלק רק באחד מהמיקומים, על סמך גורמים כמו זמינות החומרה או עומס מוגבל צפוי.
הנתונים במסד נתונים שמסונכרן באמצעות טרנזקציות עקביים בכל המיקומים. לכן, מסד נתונים כזה הוא האפשרות הטובה ביותר לפריסת מופעי שירות בכל מיקומי הפריסה.
כשמשתמשים במסד נתונים אסינכרוני משוכפל, יש סיכון שפריט נתונים מסוים ישתנה בשני מיקומי פריסה בו-זמנית. כדי לקבוע איזה משני השינויים המתנגשים הוא המצב העקבי הסופי, צריך להטמיע אסטרטגיה לפתרון סתירות. אפשר להטמיע אסטרטגיה לפתרון התנגשויות, אבל זה לא תמיד פשוט, ובמקרים מסוימים צריך התערבות ידנית כדי לשחזר את הנתונים למצב עקבי.
העברת שירותים מבוזרים ויתירות כשל
אם אזור שלם בענן נכשל, מתחילה תוכנית התאוששות מאסון (DR). אם שירות אחד באפליקציית מסד נתונים עם שמירת מצב נכשל (לא האזור או האפליקציה כולה), צריך לשחזר את השירות ולהפעיל אותו מחדש.
גישה ראשונית לתוכנית התאוששות מאסון היא להפעיל מחדש את השירות שנכשל במיקום הפריסה המקורי שלו (גישה של הפעלה מחדש במקום). טכנולוגיות כמו Kubernetes מפעילות מחדש שירות באופן אוטומטי על סמך ההגדרות שלו.
עם זאת, אם הגישה הזו של הפעלה מחדש במקום לא מצליחה, אפשר להפעיל מחדש את השירות במיקום משני. השירות עובר מגיבוי במיקום הראשי למיקום המשני. אם האפליקציה פרוסה כקבוצה של שירותים מבוזרים, יתירות הכשל של שירות יחיד יכולה להתבצע באופן דינמי.
מנקודת המבט של מסד הנתונים, הפעלה מחדש של השירות במיקום הפריסה המקורי שלו לא דורשת פריסה ספציפית של מסד הנתונים. כשמעבירים שירות למיקום פריסה חלופי והשירות ניגש למסד הנתונים, חלים אותם מודלים של מוכנות שנדונו קודם לכן במסמך הזה בקטע שירותים מבוזרים.
אם שירות מועבר באופן זמני, וזמני אחזור ארוכים יותר מקובלים על הארגון במהלך ההעברה, השירות יכול לגשת למסד הנתונים במיקומי הפריסה. למרות שהשירות הועבר, הוא ממשיך לגשת למסד הנתונים באותו אופן שבו הוא ניגש אליו ממיקום הפריסה המקורי.
פריסה תלוית הקשר
באופן כללי, פריסה של אפליקציה אחת כדי לשרת את כל לקוחות האפליקציה כוללת את כל שירותי האפליקציה ומסדי הנתונים שלה. עם זאת, יש מקרים חריגים. פריסה אחת של אפליקציה יכולה לשרת רק קבוצת משנה של לקוחות (על סמך קריטריונים ספציפיים), ולכן צריך יותר מפריסה אחת של אפליקציה. כל פריסה משרתת קבוצת משנה אחרת של לקוחות, וכל הפריסות יחד משרתות את כל הלקוחות.
דוגמאות לתרחישים לדוגמה של פריסה תלוית-הקשר:
- כשפורסים אפליקציה עם כמה דיירים, שבה אפליקציה אחת נפרסת לכל הדיירים הקטנים, אפליקציה אחרת נפרסת לכל 10 דיירים בינוניים ואפליקציה אחת נפרסת לכל דייר פרימיום.
- כשצריך להפריד בין לקוחות, למשל לקוחות עסקיים ולקוחות ממשלתיים.
- כשצריך להפריד בין סביבות פיתוח, Staging וייצור.
מבחינת מסד הנתונים, אפשר לפרוס מסד נתונים אחד לכל פריסת אפליקציה באסטרטגיית פריסה של אחד לאחד. כפי שמוצג בדיאגרמה הבאה, האסטרטגיה הזו היא גישה פשוטה שבה נוצרים נתונים מחולקים למחיצות (partitioning), כי לכל Deployment (פריסה) יש קבוצת נתונים משלה.
בתרשים שלמעלה מוצגים:
- הגדרה עם שלוש פריסות של אפליקציה.
- לכל קבוצת נתונים יש מסד נתונים משלה.
- לא משותפים נתונים בין הפריסות.
במקרים רבים, פריסה של אחד לאחד היא האסטרטגיה המתאימה ביותר, אבל יש גם חלופות.
במקרה של ריבוי דיירים, יכול להיות שהדיירים יועברו למקום אחר. דייר קטן יכול להפוך לדייר בינוני, וצריך להעביר אותו לאפליקציה אחרת. במקרה כזה, פריסות נפרדות של מסדי נתונים דורשות העברה של מסד הנתונים. אם פורסים מסד נתונים מבוזר וכל הפריסות משתמשות בו בו-זמנית, כל נתוני הדיירים נמצאים במערכת אחת של מסד נתונים. לכן, העברת דייר בין מסדי נתונים לא דורשת העברה של מסד הנתונים. התרשים הבא מציג דוגמה למסד נתונים מהסוג הזה:
בתרשים שלמעלה מוצגים:
- שלושה פריסות של אפליקציה.
- כל הפריסות חולקות מסד נתונים מבוזר אחד.
- האפליקציות יכולות לגשת לכל הנתונים בכל פריסה.
- לא מוגדרת חלוקה למחיצות של נתונים.
אם בארגון מעבירים דיירים לעיתים קרובות כחלק מפעולות מחזור החיים, שכפול מסד הנתונים יכול להיות חלופה שימושית. בגישה הזו, הנתונים של הדייר משוכפלים בין מסדי נתונים לפני העברת הדייר. במקרה כזה, משתמשים במסדי נתונים עצמאיים לפריסות שונות של אפליקציות, ומגדירים אותם לרפליקציה רק לפני ההעברה של הדייר ובמהלכה. בתרשים הבא מוצג רפליקציה זמנית בין שני Deployment (פריסה) של אפליקציות במהלך מיגרציה של דייר (tenant).
בתרשים הקודם מוצגים שלושה פריסות של אפליקציה עם שלושה מסדי נתונים נפרדים שמכילים את הנתונים שמשויכים לכל פריסה. כדי להעביר נתונים ממסד נתונים אחד לאחר, אפשר להגדיר העברה זמנית של מסד נתונים.
ניידות של אפליקציות
ניידות של אפליקציות מבטיחה שאפשר לפרוס אפליקציה במיקומי פריסה שונים, במיוחד בעננים שונים. הניידות הזו מבטיחה שאפשר להעביר אפליקציה בכל שלב, בלי צורך בתכנון מחדש ספציפי להעברה או בפיתוח נוסף של האפליקציה כדי להתכונן להעברה.
כדי להבטיח את ניידות האפליקציה, אפשר להשתמש באחת מהגישות הבאות, שמתוארות בהמשך הקטע הזה:
- ניידות מבוססת-מערכת
- תאימות ל-API
- ניידות מבוססת-פונקציונליות
ניידות מבוססת-מערכת משתמשת באותם רכיבים טכניים שמשמשים בכל הפריסות האפשריות. כדי להבטיח ניידות מבוססת-מערכת, כל טכנולוגיה צריכה להיות זמינה בכל מיקומי הפריסה הפוטנציאליים. לדוגמה, אם מסד נתונים כמו PostgreSQL הוא מועמד, צריך לוודא שהוא זמין בכל מיקומי הפריסה הפוטנציאליים למשך הזמן הצפוי. כך גם לגבי כל הטכנולוגיות האחרות, כמו שפות תכנות וטכנולוגיות תשתית. כפי שמוצג בדיאגרמה הבאה, גישה זו יוצרת קבוצה של פונקציות משותפות בכל מיקומי הפריסה, על סמך הטכנולוגיה.
בתרשים הקודם מוצג פריסת אפליקציה ניידת שבה האפליקציה מצפה לאותה מערכת מסד נתונים בדיוק בכל מיקום שבו היא נפרסת. מכיוון שבכל מיקום נעשה שימוש באותה מערכת של מסד נתונים, האפליקציה ניידת. האפליקציה יכולה לצפות שאותה מערכת מסד נתונים בדיוק תשמש בכל הפריסה. לכן, אפשר להניח שהממשק וההתנהגות של מערכת מסד הנתונים יהיו זהים.
בהקשר של מסדי נתונים, במערכת תאימות ה-API, הלקוח משתמש בספריית גישה ספציפית למסד נתונים (לדוגמה, ספריית לקוח של MySQL) כדי לוודא שהוא יכול להתחבר לכל הטמעה תואמת שעשויה להיות זמינה בסביבת ענן. התרשים הבא ממחיש את התאימות של ה-API.
בתרשים הקודם מוצגת ניידות של אפליקציות שמבוססת על ה-API של מערכת מסד הנתונים, במקום על מערכת מסד הנתונים עצמה. למרות שמערכות מסדי הנתונים יכולות להיות שונות בכל אחד מהמיקומים, ה-API זהה וחושף את אותה פונקציונליות. האפליקציה ניידת כי היא יכולה להניח שקיים אותו API בכל מיקום, גם אם מערכת מסד הנתונים הבסיסית היא טכנולוגיית מסד נתונים אחרת.
בניידות שמבוססת על פונקציונליות, יכול להיות שבעננים שונים ייעשה שימוש בטכנולוגיות שונות שמספקות את אותה פונקציונליות. לדוגמה, יכול להיות שאפשר להגביל את השימוש במסדי נתונים למודל היחסי. מכיוון שכל מערכת של מסד נתונים רלציוני יכולה לתמוך באפליקציה, אפשר להשתמש במערכות שונות של מסדי נתונים בגרסאות שונות בעננים שונים, בלי להשפיע על הניידות של האפליקציה. החיסרון של ניידות מבוססת-פונקציונליות הוא שאפשר להשתמש רק בחלקים של מודל מסד הנתונים שכל המערכות של מסדי הנתונים הרלציוניים תומכות בהם. במקום מערכת מסד נתונים שתואמת לכל העננים, צריך להשתמש במודל של מסד נתונים. התרשים הבא מציג ארכיטקטורה לדוגמה של ניידות מבוססת-פונקציונליות.
כמו שמוצג בתרשים הקודם, ה-API של מערכת מסד הנתונים ומערכת מסד הנתונים עשויים להיות שונים בכל מיקום. כדי להבטיח ניידות, האפליקציה צריכה להשתמש רק בחלקים של כל מערכת מסד נתונים וכל API שזמינים בכל מיקום. בכל מיקום זמינה בדרך כלל רק קבוצת משנה של כל מערכת מסד נתונים, ולכן האפליקציה צריכה להגביל את השימוש שלה לקבוצת המשנה הזו.
כדי להבטיח ניידות לכל האפשרויות בקטע הזה, צריך לפרוס באופן רציף את הארכיטקטורה המלאה בכל מיקומי היעד. כל מקרי הבדיקה של היחידה ובדיקת המערכת צריכים להתבצע מול הפריסות האלה. אלה דרישות חיוניות כדי לזהות שינויים בתשתיות ובטכנולוגיות בשלב מוקדם ולטפל בהם.
מניעת תלות בספק
מניעת תלות בספק (נעילה) עוזרת לצמצם את הסיכון לתלות בטכנולוגיה ובספק ספציפיים. הוא דומה באופן שטחי לניידות של אפליקציות. מניעת תלות בספק חלה על כל הטכנולוגיות שבהן משתמשים, ולא רק על שירותי ענן. לדוגמה, אם משתמשים ב-MySQL כמערכת של מסד נתונים ומתקינים אותה במכונות וירטואליות בעננים, אין תלות מנקודת המבט של הענן, אבל יש תלות ב-MySQL. אפליקציה שאפשר להעביר בין עננים עדיין עשויה להיות תלויה בטכנולוגיות שמסופקות על ידי ספקים שונים מהענן.
כדי למנוע תלות בספק, כל הטכנולוגיות צריכות להיות ניתנות להחלפה. לכן, צריך הפשטה יסודית ומובנית של כל הפונקציונליות של האפליקציה, כדי שכל שירות של האפליקציה יוכל להיות מוטמע מחדש בבסיס טכנולוגי אחר בלי להשפיע על אופן ההטמעה של האפליקציה. מנקודת המבט של מסד הנתונים, אפשר לבצע את ההפשטה הזו על ידי הפרדת השימוש במודל של מסד נתונים ממערכת ספציפית לניהול מסדי נתונים.
מערכת קיימת לניהול מסדי נתונים בסביבת הייצור
אפליקציות רבות של ריבוי עננים מפותחות עם מערכות של מסדי נתונים כחלק מהתכנון שלהן, אבל ארגונים רבים מפתחים אפליקציות של ריבוי עננים כחלק מהמאמץ שלהם למודרניזציה של אפליקציות. האפליקציות האלה מפותחות בהנחה שהאפליקציה החדשה שתוכננה ויושמה ניגשת למסדי הנתונים הקיימים.
יש הרבה סיבות לכך שלא משלבים מסדי נתונים קיימים במאמצי המודרניזציה. יכול להיות שאתם משתמשים בתכונות ספציפיות שלא זמינות במערכות אחרות של מסדי נתונים. לארגון יכולים להיות מסדי נתונים עם תהליכי ניהול מורכבים ומבוססים, כך שהמעבר למערכת אחרת לא מעשי או לא משתלם. לחלופין, ארגון יכול לבחור לשדרג אפליקציה בשלב הראשון, ולשדרג את מסד הנתונים בשלב השני.
כשארגון משתמש במערכת מסד נתונים קיימת, מי שמתכנן את האפליקציה מרובת העננים צריך להחליט אם זה יהיה מסד הנתונים היחיד שבו ישתמשו, או אם צריך להוסיף מערכת מסד נתונים אחרת למיקומי פריסה שונים. לדוגמה, אם משתמשים במסד נתונים מקומי וצריך להריץ את האפליקציה גם ב- Google Cloud, צריך לבדוק אם שירותי האפליקציה שנפרסו ב- Google Cloud ניגשים למסד הנתונים המקומי. לחלופין, אם צריך לפרוס מסד נתונים שני גם ב-Google Cloud וגם בשירותי האפליקציה שפועלים באופן מקומי.
אם פורסים מסד נתונים שני ב- Google Cloud, יכול להיות שתרחיש השימוש יהיה זהה לתרחישי השימוש שנדונו בקטע Cloud bursting או בקטע שירותים מבוזרים. בשני המקרים, הדיון על מסד הנתונים זהה לזה שבקטעים האלה. עם זאת, היא מוגבלת לפונקציונליות בין מיקומים שבה מסד הנתונים המקומי הקיים יכול לתמוך – לדוגמה, סנכרון ושכפול.
דפוסי פריסה
התרחישים לדוגמה שמוצגים במסמך הזה מעלים שאלה נפוצה מנקודת המבט של מסד הנתונים: אם מסדי הנתונים נמצאים ביותר ממיקום פריסה אחד, מה הקשר ביניהם?
אלה סוגי הקשרים העיקריים (דפוסי פריסה), שנדון בהם בקטע הבא:
- חלוקה למחיצות ללא תלות בין מסדי נתונים
- רפליקציה אסינכרונית חד-כיוונית
- שכפול דו-כיווני עם פתרון התנגשויות
- מערכת מבוזרת מסונכרנת פעילה-פעילה באופן מלא
אפשר למפות כל תרחיש לדוגמה במסמך הזה לאחת או יותר מארבע תבניות הפריסה.
בדיון הבא, ההנחה היא שהלקוחות ניגשים ישירות לשירותי האפליקציה. בהתאם לתרחיש לדוגמה, יכול להיות שיהיה צורך במאזן עומסים כדי להפנות באופן דינמי את הגישה של הלקוח לאפליקציות, כמו שמוצג בתרשים הבא.
בתרשים הקודם, מאזן עומסים בענן מפנה קריאות של לקוחות לאחד מהמיקומים הזמינים. מאזן העומסים מוודא שכללי המדיניות של איזון העומסים נאכפים, ושהלקוחות מופנים למיקום הנכון של האפליקציה ומסד הנתונים שלה.
חלוקה למחיצות ללא תלות בין מסדי נתונים
דפוס הפריסה הזה הוא הפשוט ביותר מבין כל הדפוסים שמתוארים במסמך הזה: לכל מיקום או ענן יש מסד נתונים, ומסדי הנתונים מכילים קבוצות נתונים מחולקות שלא תלויות זו בזו. פריט נתונים מאוחסן במסד נתונים אחד בלבד. כל מחיצת נתונים נמצאת במסד נתונים משלה. דוגמה לתבנית הזו היא אפליקציה עם כמה דיירים, שבה מערך הנתונים נמצא באחד ממסדי הנתונים. הדיאגרמה הבאה מציגה שתי אפליקציות עם חלוקה מלאה למחיצות.
כפי שמוצג בתרשים הקודם, אפליקציה נפרסת בשני מיקומים, שכל אחד מהם אחראי למחיצה של מערך הנתונים כולו. כל פריט נתונים נמצא רק באחד מהמיקומים, כדי להבטיח שקבוצת הנתונים מחולקת למחיצות בלי שכפול בין שני המיקומים.
דפוס פריסה חלופי למסדי נתונים מחולקים למחיצות הוא מצב שבו מערך הנתונים מחולק לחלוטין למחיצות, אבל עדיין מאוחסן באותו מסד נתונים. יש רק מסד נתונים אחד שמכיל את כל מערכי הנתונים. למרות שקבוצות הנתונים מאוחסנות באותו מסד נתונים, הן מופרדות לחלוטין (מחולקות למחיצות) ושינוי באחת מהן לא גורם לשינויים באחרת. בתרשים הבא מוצגות שתי אפליקציות שחולקות מסד נתונים אחד.
בתרשים שלמעלה מוצגים:
- שני פריסות של אפליקציות שחולקות מסד נתונים משותף, שנמצא במיקום הראשון.
- כל אפליקציה יכולה לגשת לכל הנתונים בפריסה כי מערך הנתונים לא מחולק למחיצות.
רפליקציה אסינכרונית חד-כיוונית
בתבנית הפריסה הזו יש מסד נתונים ראשי שמשוכפל למסד נתונים משני אחד או יותר. אפשר להשתמש במסד הנתונים המשני לגישת קריאה, אבל האפליקציה צריכה להביא בחשבון עיכוב אפשרי בשכפול. דוגמה לתבנית הזו היא כשמסד הנתונים הטוב ביותר לתרחיש לדוגמה מסוים משמש כמסד הנתונים הראשי, ומסד הנתונים המשני משמש לניתוח נתונים. בתרשים הבא מוצגות שתי אפליקציות שניגשות למסדי נתונים שמשוכפלים באופן חד-כיווני.
כפי שמוצג בתרשים הקודם, אחד משני מסדי הנתונים הוא עותק של השני. החץ בתרשים מציין את כיוון הרפליקציה: הנתונים ממערכת מסד הנתונים במיקום 1 משוכפלים למערכת מסד הנתונים במיקום 2.
שכפול דו-כיווני עם פתרון התנגשויות
בתבנית הפריסה הזו יש שני מסדי נתונים ראשיים שמשוכפלים באופן אסינכרוני זה לזה. אם אותם נתונים נכתבים בו-זמנית בכל מסד נתונים (לדוגמה, אותו מפתח ראשי), זה עלול לגרום להתנגשות כתיבה-כתיבה. בגלל הסיכון הזה, צריך להגדיר פתרון לבעיות כדי לקבוע מהו המצב האחרון במהלך השכפול. אפשר להשתמש בתבנית הזו במצבים שבהם הסיכוי להתנגשות כתיבה-כתיבה הוא נדיר. בתרשים הבא מוצגות שתי אפליקציות שניגשות למסדי נתונים שמשוכפלים באופן דו-כיווני.
כמו שמוצג בתרשים שלמעלה, כל מסד נתונים משוכפל למסד הנתונים השני. שתי הרפליקציות לא תלויות זו בזו, כפי שמצוין בתרשים באמצעות שני חצים כחולים נפרדים. מכיוון ששני השכפולים הם בלתי תלויים, יכולה להיווצר התנגשות אם במקרה אותו פריט נתונים משתנה על ידי כל אחת מהאפליקציות ומשוכפל בו-זמנית. במקרה כזה, צריך לפתור את ההתנגשות.
מערכת מבוזרת מסונכרנת פעילה-פעילה באופן מלא
בתבנית הפריסה הזו יש מסד נתונים אחד עם הגדרת active-active (או primary-primary). בהגדרה של פעיל-פעיל, עדכון של נתונים בכל מסד נתונים ראשי הוא עקבי מבחינת טרנזקציות ומשוכפל באופן סינכרוני. דוגמה לתרחיש לדוגמה של התבנית הזו היא מחשוב מבוזר. בתרשים הבא מוצגות שתי אפליקציות שניגשות למסד נתונים ראשי-ראשי מסונכרן לחלוטין.
כפי שמוצג בתרשים הקודם, הסידור הזה מבטיח שכל אפליקציה תמיד תיגש למצב העקבי האחרון, ללא עיכוב או סיכון להתנגשות. שינוי במסד נתונים אחד זמין באופן מיידי במסד הנתונים השני. כל שינוי משתקף בשני מסדי הנתונים כשמתבצעת פעולת commit של טרנזקציית שינוי.
סיווג מערכת מסד הנתונים
לא כל המערכות לניהול מסדי נתונים מתאימות באותה מידה לדפוסי הפריסה שמתוארים במאמר הזה. בהתאם לתרחיש לדוגמה, יכול להיות שתוכלו להטמיע רק דפוס פריסה אחד או שילוב של דפוסי פריסה עם קבוצת משנה של מערכות מסדי נתונים.
בקטע הבא, המערכות השונות של מסדי הנתונים מסווגות וממופות לארבעת דפוסי הפריסה.
אפשר לסווג מסדי נתונים לפי מאפיינים שונים, כמו מודל נתונים, ארכיטקטורה פנימית, מודל פריסה וסוגי טרנזקציות. בקטע הבא, לצורך ניהול מסדי נתונים בכמה עננים, נעשה שימוש בשני מאפיינים:
- ארכיטקטורת פריסה. הארכיטקטורה של פריסת מערכת לניהול מסדי נתונים במשאבים של עננים (לדוגמה, Compute Engine או ניהול בענן).
- מודל ההפצה. מודל ההפצה שבו מערכת מסד הנתונים תומכת (לדוגמה, מכונה אחת או הפצה מלאה).
שני המאפיינים האלה הם הרלוונטיים ביותר בהקשר של תרחישי שימוש בסביבות מרובות-עננים, והם יכולים לתמוך בארבעת דפוסי הפריסה שנגזרים מתרחישי השימוש במסדי נתונים בסביבות מרובות-עננים. סיווג פופולרי מבוסס על מודלים של נתונים שנתמכים על ידי מערכת לניהול מסדי נתונים. יש מערכות שתומכות רק במודל אחד (למשל, מודל גרף). מערכות אחרות תומכות בכמה מודלים של נתונים בו-זמנית (לדוגמה, מודלים יחסיים ומודלים של מסמכים). עם זאת, בהקשר של ניהול מסדי נתונים בכמה עננים, הסיווג הזה לא רלוונטי כי אפליקציות בכמה עננים יכולות להשתמש בכל מודל נתונים לפריסה שלהן בכמה עננים.
מערכת מסד נתונים לפי ארכיטקטורת פריסה
ניהול מסדי נתונים בכמה עננים כולל את ארבעת הסוגים העיקריים הבאים של ארכיטקטורת פריסה למערכות ניהול של מסדי נתונים:
- מסדי נתונים מובנים בענן. מסדי נתונים מובנים בענן מתוכננים, נבנים ומותאמים לעבודה עם טכנולוגיית ענן. לדוגמה, מערכות מסוימות של מסדי נתונים משתמשות ב-Kubernetes כפלטפורמת ההטמעה שלהן ומשתמשות בפונקציונליות של Kubernetes. CockroachDB ו-YugaByte הם דוגמאות למסדי נתונים מהסוג הזה. אפשר לפרוס אותם בכל ענן שתומך ב-Kubernetes.
- מסדי נתונים שמנוהלים על ידי ספק שירותי ענן. מסדי נתונים שמנוהלים על ידי ספק שירותי ענן מבוססים על טכנולוגיה ספציפית של ספק שירותי הענן, והם שירות של מסד נתונים שמנוהל על ידי ספק שירותי ענן ספציפי. Spanner, Bigtable, Firestore ו-AlloyDB ל-PostgreSQL הם דוגמאות למסדי נתונים מהסוג הזה. מסדי נתונים שמנוהלים על ידי ספק שירותי ענן זמינים רק בענן של הספק, ואי אפשר להתקין ולהריץ אותם במקום אחר. עם זאת, AlloyDB ל-PostgreSQL תואם באופן מלא ל-PostgreSQL.
- מסדי נתונים לפני הענן. מסדי נתונים שנוצרו לפני פיתוח טכנולוגיית הענן (לפעמים הרבה לפני) ופועלים בדרך כלל על חומרת Bare Metal ומכונות וירטואליות (VM). PostgreSQL, MySQL ו-SQL Server הם דוגמאות למסדי נתונים מהסוג הזה. המערכות האלה יכולות לפעול בכל ענן שתומך במכונות הווירטואליות הנדרשות או בחומרת Bare Metal.
- מסדי נתונים בענן שמנוהלים על ידי שותפים. בחלק מהעננים הציבוריים יש שותפי מסדי נתונים שמתקינים ומנהלים את מסדי הנתונים של הלקוחות בענן הציבורי. לכן, הלקוחות לא צריכים לנהל את מסדי הנתונים האלה בעצמם. דוגמאות למסדי נתונים מהסוג הזה: MongoDB Atlas, MariaDB ו-ScyllaDB.
יש כמה גרסאות של הקטגוריות העיקריות האלה. לדוגמה, ספק של מסד נתונים שמטמיע מסד נתונים שמיועד לענן, יכול גם לספק התקנה בטכנולוגיה שמיועדת לענן והצעה מנוהלת ללקוחות בענן שסופק על ידי הספק. הגישה הזו מקבילה לספק שמציע ענן ציבורי שתומך רק במסד הנתונים שלו כשירות יחיד.
מסדי נתונים שנוצרו לפני הענן יכולים גם להיות בקונטיינרים, ואפשר לפרוס אותם באשכול Kubernetes. עם זאת, מסדי הנתונים האלה לא משתמשים בפונקציונליות ספציפית ל-Kubernetes, כמו התאמה לעומס (scaling), פריסה של כמה שירותים או פריסה של כמה פודים.
ספקי מסדי נתונים יכולים לעבוד עם יותר מספק שירותי ענן ציבורי אחד בו-זמנית, ולהציע את מסד הנתונים שלהם כמסד נתונים שמנוהל על ידי שותף ענן ביותר מענן ציבורי אחד.
מערכת מסד נתונים לפי מודל הפצה
מערכות שונות לניהול מסדי נתונים מוטמעות בהתאם למודלים של ההפצה בארכיטקטורה של מסד הנתונים. אלה המודלים של מסדי הנתונים:
- מופע יחיד. מכונה אחת של מסד נתונים פועלת במכונה וירטואלית אחת או בקונטיינר אחד, ומשמשת כמערכת מרכזית. המערכת הזו מנהלת את כל הגישה למסד הנתונים. מכיוון שאי אפשר לחבר את המכונה היחידה למכונה אחרת, מערכת מסד הנתונים לא תומכת ברפליקציה.
- Multi-instance active-passive. בארכיטקטורה הנפוצה הזו, כמה מופעים של מסדי נתונים מקושרים יחד. הקישור הנפוץ ביותר הוא קשר פעיל-סביל, שבו מכונה אחת היא מכונת מסד הנתונים הפעילה שתומכת בשתי המכונות, וכותבת וקוראת. מערכת פסיבית אחת או יותר מוגדרת לקריאה בלבד, ומקבלת את כל השינויים במסד הנתונים מהמערכת הראשית באופן סינכרוני או אסינכרוני. מערכות פסיביות יכולות לספק גישת קריאה. המודל הזה נקרא גם "ראשי-משני" או "מקור-רפליקה".
- Multi-instance active-active. בארכיטקטורה הזו, שהיא יחסית לא נפוצה, כל מכונה היא מכונה פעילה. במקרה כזה, כל מכונה יכולה לבצע עסקאות קריאה וכתיבה ולספק עקביות בנתונים. לכן, כדי למנוע חוסר עקביות בנתונים, כל המופעים תמיד מסונכרנים.
- מצב פעיל-פעיל עם כמה מופעים במקביל ופתרון התנגשויות. זו גם מערכת יחסית לא נפוצה. כל מכונה זמינה לגישת כתיבה וקריאה, אבל מסדי הנתונים מסונכרנים במצב אסינכרוני. אפשר לעדכן בו-זמנית את אותו פריט נתונים, מה שמוביל למצב לא עקבי. מדיניות פתרון ההתנגשויות צריכה לקבוע איזה מהמצבים הוא המצב העקבי האחרון.
- פיצול לכמה מופעים במקביל. חלוקה לפלחים מבוססת על ניהול של מחיצות נתונים (לא קשורות). כל מחיצה מנוהלת על ידי מכונה נפרדת של מסד נתונים. ההפצה הזו ניתנת להתאמה, כי אפשר להוסיף עוד פיצולים באופן דינמי לאורך זמן. עם זאת, יכול להיות שלא תוכלו להריץ שאילתות בין-שאריות, כי לא כל המערכות תומכות בפונקציונליות הזו.
כל מודלי ההפצה שמוזכרים בקטע הזה יכולים לתמוך בחלוקה לפלחים, ויכולים להיות מערכת מחולקת לפלחים. עם זאת, לא כל המערכות מיועדות לספק אפשרות של פיצול. חלוקה לפלחים היא קונספט של יכולת התרחבות, ובדרך כלל היא לא רלוונטית לבחירת ארכיטקטורה של מסד נתונים בסביבות של ריבוי עננים.
מודלי ההפצה שונים במסדי נתונים שמנוהלים בענן ובמסדי נתונים שמנוהלים על ידי שותפים. מכיוון שמסדי הנתונים האלה קשורים לארכיטקטורה של ספק שירותי הענן, המערכות האלה מיישמות ארכיטקטורות שמבוססות על מיקומי הפריסה הבאים:
- מערכת אזורית. מערכת מסד נתונים שמנוהלת ברמת האזור מקושרת לאזור. כשהאזור זמין, גם מערכת מסד הנתונים זמינה. עם זאת, אם האזור לא זמין, אי אפשר לגשת למסד הנתונים.
- מערכת אזורית. מסד נתונים בניהול אזורי מקושר לאזור, ואפשר לגשת אליו כשלפחות אזור אחד נגיש. כל שילוב של אזורים יכול להפוך ללא נגיש.
- מערכת חוצת-אזורים. מערכת חוצת-אזורים קשורה לשני אזורים או יותר, והיא פועלת כראוי כשלפחות אזור אחד זמין.
מערכת חוצת-אזורים יכולה גם לתמוך במערכת חוצת-עננים, אם אפשר להתקין את מסד הנתונים בכל העננים שהארגון מתכוון להשתמש בהם.
יש עוד חלופות אפשריות לארכיטקטורות של מסדי נתונים מנוהלים שמוזכרות בקטע הזה. במערכת אזורית, יכול להיות שדיסק ישותף בין שני אזורים. אם אחד משני האזורים לא נגיש, מערכת מסד הנתונים יכולה להמשיך לפעול באזור שנותר. עם זאת, אם הפסקת החשמל משפיעה על שני האזורים, מערכת מסד הנתונים לא תהיה זמינה, למרות שאזורים אחרים עדיין יהיו מחוברים לאינטרנט.
מיפוי מערכות של מסדי נתונים לתבניות פריסה
בטבלה הבאה מתוארים הקשרים בין דפוסי הפריסה וארכיטקטורות הפריסה שמוזכרים במסמך הזה. השדות מציינים את התנאים שנדרשים כדי ששילוב יהיה אפשרי, על סמך דפוס הפריסה וארכיטקטורת הפריסה.
| ארכיטקטורת פריסה | תבנית פריסה | ||||
|---|---|---|---|---|---|
| חלוקה למחיצות ללא תלות בין מסדי נתונים | רפליקציה אסינכרונית חד-כיוונית | שכפול דו-כיווני עם פתרון התנגשויות | מערכת מבוזרת מסונכרנת פעילה-פעילה באופן מלא | ||
| מסדי נתונים מובנים בענן | אפשר להשתמש בה בכל העננים שמספקים טכנולוגיית ענן מובנית שמשמשת מערכות של מסדי נתונים.
אם אותו מסד נתונים לא זמין, אפשר להשתמש במערכות אחרות של מסדי נתונים. |
מסד נתונים בענן שמספק רפליקציה. | מסד נתונים בענן שמספק רפליקציה דו-כיוונית. | מסד נתונים בענן שמספק סנכרון בין מסדי נתונים ראשיים. | |
| מסדי נתונים שמנוהלים על ידי ספק שירותי ענן | מערכות של מסדי נתונים יכולות להיות שונות בעננים שונים. | הרפליקה לא חייבת להיות מסד הנתונים שמנוהל על ידי ספק שירותי הענן (ראו התפקיד של טכנולוגיית העברת מסדי נתונים בתבניות פריסה). | רק בתוך ענן, לא בין עננים, אם מסד הנתונים מספק רפליקציה דו-כיוונית. | רק בתוך ענן, לא בין עננים, אם מסד הנתונים מספק סנכרון ראשי-ראשי. | |
| מסדי נתונים לפני המעבר לענן | מערכות מסדי הנתונים יכולות להיות זהות או שונות בעננים שונים. | אפשר לשכפל נתונים בכמה עננים. | מערכת מסד הנתונים מספקת רפליקציה דו-כיוונית ופתרון התנגשויות. | מערכת מסד הנתונים מספקת סנכרון בין מסד נתונים ראשי למסד נתונים ראשי. | |
| מסדי נתונים בענן שמנוהלים על ידי שותפים | מערכות של מסדי נתונים יכולות להיות שונות בעננים שונים.
אם השותף מספק מערכת מסד נתונים מנוהלת בכל העננים הנדרשים, אפשר להשתמש באותו מסד נתונים. |
הרפליקה לא חייבת להיות מסד הנתונים שמנוהל על ידי ספק שירותי הענן. אם השותף מספק מערכת מסד נתונים מנוהלת בכל העננים הנדרשים, אפשר להשתמש באותו מסד נתונים. |
מערכת מסד הנתונים מספקת רפליקציה דו-כיוונית ופתרון התנגשויות. | מערכת מסד הנתונים מספקת סנכרון בין מסד נתונים ראשי למסד נתונים ראשי. | |
אם מערכת מסד הנתונים לא מספקת רפליקציה מובנית, יכול להיות שאפשר להשתמש בטכנולוגיית רפליקציה של מסד נתונים במקום זאת. למידע נוסף, קראו את המאמר תפקיד טכנולוגיית ההעברה של מסדי נתונים בתבניות פריסה.
בטבלה הבאה מוצג הקשר בין דפוסי הפריסה למודלים של ההפצה. השדות מציינים את התנאים שבהם השילוב אפשרי, בהתאם לדפוס הפריסה ולמודל ההפצה.
| מודל הפצה | תבנית פריסה | ||||
|---|---|---|---|---|---|
| חלוקה למחיצות ללא תלות בין מסדי נתונים | רפליקציה אסינכרונית חד-כיוונית | שכפול דו-כיווני עם פתרון התנגשויות | מערכת מבוזרת מסונכרנת פעילה-פעילה באופן מלא | ||
| מופע יחיד | אפשר להשתמש באותה מערכת של מסד נתונים או במערכת אחרת בעננים המעורבים. | לא רלוונטי | לא רלוונטי | לא רלוונטי | |
| כמה מופעים במקביל – פעיל-פסיבי | אפשר להשתמש באותה מערכת של מסד נתונים או במערכת אחרת בעננים המעורבים. | אפשר לשכפל בין עננים. | אפשר לשכפל בין עננים. | לא רלוונטי | |
| כמה מופעים במקביל פעילים-פעילים | אפשר להשתמש באותה מערכת של מסד נתונים או במערכת אחרת בעננים המעורבים. | לא רלוונטי | לא רלוונטי | אפשר לסנכרן בין עננים. | |
| מצב פעיל-פעיל עם כמה מופעים במקביל ופתרון התנגשויות | אפשר להשתמש באותה מערכת של מסד נתונים או במערכת אחרת בעננים המעורבים. | לא רלוונטי | לא רלוונטי | רלוונטי אם אפשר לבצע רפליקציה דו-כיוונית בין עננים. | |
בחלק מההטמעות של מודלים של הפצה שמוסיפים עוד הפשטה על סמך טכנולוגיית מסד הנתונים הבסיסית, אין מודל הפצה מובנה כזה – לדוגמה, Postgres-BDR, מערכת פעילה-פעילה. מערכות כאלה נכללות בטבלה שלמעלה בקטגוריה המתאימה. מנקודת מבט של ריבוי עננים, לא משנה איך מודל ההפצה מיושם.
העברה ורפליקציה של מסדי נתונים
בהתאם לתרחיש לדוגמה, יכול להיות שארגון יצטרך להעביר מסד נתונים ממיקום פריסה אחד לאחר. לחלופין, לצורך עיבוד במורד הזרם, יכול להיות שיהיה צורך לשכפל את הנתונים של מסד נתונים למיקום אחר. בקטע הבא נדון בפירוט בהעברת מסדי נתונים וברפליקציה של מסדי נתונים.
העברה של מסדי נתונים
העברת מסד נתונים משמשת כשמעבירים מסד נתונים ממיקום פריסה אחד למיקום אחר. לדוגמה, מסד נתונים שפועל במרכז נתונים מקומי מועבר כדי לפעול בענן. בסיום ההעברה, מסד הנתונים במרכז הנתונים המקומי מושבת.
אלה הגישות העיקריות להעברת מסדי נתונים:
- חותכים ולוקחים. המכונה הווירטואלית והדיסקים שמריצים את המכונות של מסד הנתונים מועתקים לסביבת היעד כמו שהם. אחרי שההעתקה מסתיימת, המכונות מופעלות וההעברה מסתיימת.
- ייצוא וייבוא וגיבוי ושחזור. בשתי הגישות האלה משתמשים בפונקציונליות של מערכת מסד הנתונים כדי להחצין מסד נתונים וליצור אותו מחדש במיקום היעד. ייצוא וייבוא מבוססים בדרך כלל על פורמט ASCII, ואילו גיבוי ושחזור מבוססים על פורמט בינארי.
- העברה ללא זמן השבתה. בגישה הזו, מסד הנתונים מועבר בזמן שמערכות האפליקציה ניגשות למערכת המקור. אחרי הטעינה הראשונית, השינויים מועברים ממסד הנתונים של המקור למסד הנתונים של היעד באמצעות טכנולוגיות של סימון נתונים שהשתנו (CDC). האפליקציה מושבתת מרגע שהיא נעצרת במערכת מסד הנתונים של המקור, ועד שהיא מופעלת מחדש במערכת מסד הנתונים של היעד אחרי שההעברה מסתיימת.
העברת מסדי נתונים רלוונטית לתרחישי שימוש של ריבוי עננים כשמעבירים מסד נתונים מענן אחד לאחר, או מסוג אחד של המנוע של מסד הנתונים לאחר.
העברת מסד נתונים היא תהליך רב-שלבי. למידע נוסף, קראו את המאמרים העברת מסדי נתונים: מושגים ועקרונות (חלק 1) והעברת מסדי נתונים: מושגים ועקרונות (חלק 2).
אפשר להשתמש בטכנולוגיות מובנות של מסדי נתונים כדי להעביר מסדי נתונים – לדוגמה, ייצוא וייבוא, גיבוי ושחזור או פרוטוקולים מובנים של שכפול. כשמערכת המקור ומערכת היעד הן מערכות שונות של מסדי נתונים, טכנולוגיות העברה הן האפשרות הטובה ביותר להעברת מסדי נתונים. Database Migration Service, Striim ו-Debezium הם דוגמאות לטכנולוגיות של העברת מסדי נתונים.
שכפול מסד נתונים
רפליקציה של מסד נתונים דומה להעברה של מסד נתונים. לעומת זאת, במהלך רפליקציה של מסד נתונים, המערכת של מסד הנתונים המקורי נשארת במקום, וכל שינוי מועבר למסד הנתונים המיועד.
רפליקציה של מסד נתונים היא תהליך רציף שבו שינויים נשלחים ממסד הנתונים המקורי למסד הנתונים המיועד. כשהתהליך הזה אסינכרוני, השינויים מגיעים למסד הנתונים של היעד אחרי עיכוב קצר. אם התהליך סינכרוני, השינויים במערכת המקור מתבצעים במערכת היעד באותו הזמן ובאותן עסקאות.
בנוסף לשכפול של מסד נתונים ממקור ליעד, שיטה נפוצה היא לשכפל נתונים ממסד נתונים של מקור למערכת ניתוח נתונים של יעד.
כמו בהעברת מסד נתונים, אם פרוטוקולי הרפליקציה זמינים, אפשר להשתמש בטכנולוגיית מסד נתונים מובנית לרפליקציה של מסד נתונים. אם אין פרוטוקולי שכפול מובנים, אפשר להשתמש בטכנולוגיית שכפול כמו Datastream, Striim או Debezium.
התפקיד של טכנולוגיית העברת מסדי נתונים בתבניות פריסה
טכנולוגיית מסד נתונים מובנית שמאפשרת שכפול לא זמינה לכלל המשתמשים בדרך כלל כשמשתמשים במערכות שונות של מסדי נתונים בתבניות פריסה – לדוגמה, שכפול אסינכרוני (הטרוגני). במקום זאת, אפשר לפרוס טכנולוגיה להעברת מסדי נתונים כדי לאפשר שכפול כזה. חלק ממערכות ההעברה האלה גם מטמיעות רפליקציה דו-כיוונית.
אם טכנולוגיית ההעברה או השכפול של מסד הנתונים זמינה למערכות של מסדי הנתונים שמשמשות בשילובים שמסומנים כ "לא רלוונטי" בטבלה 1 או בטבלה 2 במאמר מיפוי מערכות של מסדי נתונים לתבניות פריסה, יכול להיות שאפשר להשתמש בה לשכפול של מסד הנתונים. בתרשים הבא מוצגת גישה לשכפול מסד נתונים באמצעות טכנולוגיית העברה.
בתרשים שלמעלה, מסד הנתונים במיקום 1 משוכפל למסד הנתונים במיקום 2. במקום רפליקה ישירה של מערכת מסד הנתונים, נפרס שרת העברה כדי להטמיע את הרפליקה. הגישה הזו משמשת למערכות של מסדי נתונים שאין להן פונקציונליות מובנית של שכפול מסדי נתונים, וצריכות להסתמך על מערכת נפרדת ממערכת מסד הנתונים כדי להטמיע שכפול.
בחירת מסד נתונים בכמה עננים
תרחישי השימוש במסדי נתונים בכמה עננים, בשילוב עם סיווג מערכת מסד הנתונים, עוזרים לכם להחליט אילו מסדי נתונים הכי מתאימים לתרחיש שימוש נתון. לדוגמה, כדי להטמיע את תרחיש השימוש בניידות של אפליקציות, יש שתי אפשרויות. האפשרות הראשונה היא לוודא שאותו מנוע של מסד נתונים זמין בכל העננים. הגישה הזו מבטיחה את ניידות המערכת. האפשרות השנייה היא לוודא שאותו מודל נתונים וממשק שאילתות זמינים לכל העננים. למרות שמערכות מסדי הנתונים עשויות להיות שונות, הניידות ניתנת בממשק פונקציונלי.
עצי ההחלטות שבקטעים הבאים מציגים את הקריטריונים לקבלת החלטות בתרחישי השימוש במסדי נתונים בכמה עננים שמופיעים במסמך הזה. עצי ההחלטות מציעים את מסד הנתונים המתאים ביותר לכל תרחיש לדוגמה.
שיטות מומלצות למערכת מסד נתונים קיימת
אם מערכת מסד הנתונים נמצאת בסביבת ייצור, צריך להחליט אם להשאיר או להחליף אותה. התרשים הבא מציג את השאלות שצריך לשאול בתהליך קבלת ההחלטות:
אלה השאלות והתשובות בעץ ההחלטות:
- האם מערכת מסד הנתונים נמצאת בסביבת ייצור?
- אם אין מערכת מסדי נתונים בסביבת הייצור, בוחרים מערכת מסדי נתונים (מדלגים להחלטה על ניהול מסדי נתונים בסביבות מרובות-עננים).
- אם מערכת מסד הנתונים נמצאת בסביבת הייצור, צריך לבדוק אם כדאי לשמור אותה.
- אם מערכת מסד נתונים נמצאת בסביבת ייצור, צריך לבדוק אם כדאי לשמור אותה.
- אם צריך לשמור את מערכת מסד הנתונים, ההחלטה התקבלה ותהליך קבלת ההחלטות הושלם.
- אם צריך לשנות את מערכת מסד הנתונים או אם עדיין לא התקבלה החלטה, בוחרים מערכת מסד נתונים (מדלגים אל החלטה על ניהול מסדי נתונים בכמה עננים).
החלטה לגבי ניהול מסדי נתונים בכמה עננים
עץ ההחלטות הבא מיועד לתרחיש לדוגמה עם דרישה למסד נתונים בכמה מיקומים (כולל פריסה של מסד נתונים בכמה עננים). הוא משתמש בתבנית הפריסה כבסיס לקריטריונים לקבלת החלטות.
אלה השאלות והתשובות בעץ ההחלטות:
- האם הנתונים מחולקים למחיצות במסדי נתונים שונים ללא תלות בין מסדי הנתונים?
- אם כן, אפשר לבחור מערכות מסדי נתונים זהות או שונות לכל מיקום.
- אם לא, ממשיכים לשאלה הבאה.
- האם נדרשת רפליקציה אסינכרונית חד-כיוונית?
- אם כן, צריך לבדוק אם מערכת שכפול של מסד נתונים מתאימה.
- אם כן, בוחרים מערכות מסדי נתונים זהות או שונות שתואמות למערכת השכפול.
- אם לא, בחרו מערכת מסד נתונים שיכולה להטמיע מודל הפצה פעיל-סביל.
- אם לא, ממשיכים לשאלה הבאה.
- אם כן, צריך לבדוק אם מערכת שכפול של מסד נתונים מתאימה.
- בוחרים מערכת של מסד נתונים עם מכונות מסונכרנות.
- האם פתרון המחלוקת מקובל?
- אם כן, בוחרים מערכת מסד נתונים עם שכפול דו-כיווני או מערכת מסד נתונים פעילה-פעילה.
- אם לא, בוחרים מערכת פעילה-פעילה.
- האם פתרון המחלוקת מקובל?
אם מטמיעים יותר מתרחיש שימוש אחד בסביבה מרובת-עננים, צריך להחליט אם להשתמש במערכת מסד נתונים אחת כדי לתמוך בכל תרחישי השימוש, או בכמה מערכות של מסדי נתונים.
אם ארגון רוצה להשתמש במערכת מסד נתונים אחת כדי לתמוך בכל תרחישי השימוש, המערכת עם הסנכרון הטוב ביותר היא הבחירה הטובה ביותר. לדוגמה, אם נדרש שכפול חד-כיווני וגם מכונות מסונכרנות, האפשרות הטובה ביותר היא מכונות מסונכרנות.
ההיררכיה של איכות הסנכרון היא (מהנמוכה ביותר לגבוהה ביותר): מחולק למחיצות, רפליקציה חד-כיוונית, רפליקציה דו-כיוונית ורפליקציה בסנכרון מלא.
שיטות מומלצות לפריסה
בקטע הזה מפורטות שיטות מומלצות לבחירת מסד נתונים לפיתוח או להעברה של אפליקציות בסביבות מרובות-עננים.
מערכת קיימת לניהול מסדי נתונים
מומלץ לשמור על מסד הנתונים ולא לבצע שינויים במערכת מסד הנתונים, אלא אם כן נדרש תרחיש לדוגמה ספציפי. בארגון עם מערכת מבוססת לניהול מסדי נתונים, שכוללת תהליכי פיתוח, תפעול ותחזוקה יעילים, יכול להיות שעדיף להימנע משינויים.
בתרחיש לדוגמה של cloud bursting שלא דורש מערכת מסד נתונים בענן, יכול להיות שלא תצטרכו לשנות את מסד הנתונים. תרחיש לדוגמה נוסף הוא רפליקציה אסינכרונית למיקום פריסה אחר באותו ענן או בענן אחר. במקרים כאלה, מומלץ להטמיע נקודת השוואה ולוודא שהתקשורת בין המיקומים והזמן שלוקח להעביר נתונים בין המיקומים עומדים בדרישות של האפליקציה כשניגשים למסד הנתונים.
מערכת מסד נתונים כשירות Kubernetes
אם בארגון שוקלים להריץ מערכת מסד נתונים ב-Kubernetes כשירות שמבוסס על StatefulSets, צריך להביא בחשבון את הגורמים הבאים:
- אם מסד הנתונים מספק את מודל מסד הנתונים שהאפליקציה דורשת.
- גורמים לא פונקציונליים שקובעים איך התפעול מיושם במערכת מסד נתונים כשירות Kubernetes. לדוגמה, איך מתבצעת התאמה לעומס (הגדלה והקטנה), איך מנוהלים הגיבוי והשחזור ואיך המערכת מאפשרת מעקב. כדי להבין את הדרישות של מערכת מסדי נתונים שמבוססת על Kubernetes, ארגונים צריכים להשתמש בניסיון שלהם עם מסדי נתונים כנקודת השוואה.
- זמינות גבוהה ותוכנית התאוששות מאסון (DR). כדי לספק זמינות גבוהה, המערכת צריכה להמשיך לפעול גם אם יש תקלה באזור מסוים. מסד הנתונים צריך להיות מסוגל לעבור במהירות מאזור אחד לאחר במקרה של כשל. במקרה הטוב ביותר, למסד הנתונים יש מכונה שפועלת בכל אזור ומסונכרנת באופן מלא, כך שערכי ה-RTO וה-RPO הם אפס.
- תוכנית התאוששות מאסון (DR) כדי לטפל בכשל באזור (או בענן). בתרחיש אידיאלי, מסד הנתונים ממשיך לפעול באזור שני עם RPO ו-RTO של אפס. בתרחיש פחות אידיאלי, יכול להיות שמסד הנתונים באזור המשני לא יתעדכן בכל העסקאות ממסד הנתונים הראשי.
כדי להחליט מהי הדרך הטובה ביותר להריץ מסד נתונים ב-Kubernetes, כדאי לבצע הערכה מלאה של מסד הנתונים, במיוחד כשהמערכת צריכה להיות דומה למערכת בייצור מחוץ ל-Kubernetes.
מערכת מסד נתונים שלא תלויה ב-Kubernetes
לא תמיד צריך להריץ את מסד הנתונים ב-Kubernetes במקביל לאפליקציה שמוטמעת כשירותים ב-Kubernetes. יש הרבה סיבות לכך שמערכת מסד נתונים צריכה לפעול מחוץ ל-Kubernetes, למשל תהליכים מבוססים, ידע על מוצרים בארגון או חוסר זמינות. הקטגוריה הזו כוללת גם ספקי שירותי ענן וגם מסדי נתונים שמנוהלים על ידי שותפי ענן.
אפשר גם להריץ מסד נתונים ב-Compute Engine. כשבוחרים מערכת מסד נתונים, מומלץ לבצע הערכה מלאה של מסד הנתונים כדי לוודא שכל הדרישות של האפליקציה מתקיימות.
מנקודת המבט של עיצוב האפליקציה, מאגר החיבורים הוא שיקול עיצובי חשוב. שירות של אפליקציה שניגש למסד נתונים יכול להשתמש במאגר חיבורים באופן פנימי. שימוש במאגר חיבורים משפר את היעילות ומפחית את זמן האחזור. במקום זאת, הבקשות נלקחות מהמאגר בלי שצריך ליזום אותן, ואין צורך להמתין ליצירת החיבורים. אם מגדילים את האפליקציה על ידי הוספת מכונות של שירותי אפליקציה, כל מכונה יוצרת מאגר חיבורים. אם פועלים לפי השיטות המומלצות, כל מאגר יוצר מראש קבוצה מינימלית של חיבורים. בכל פעם שנוצר מופע נוסף של שירות אפליקציה לצורך התאמה לעומס (scaling), נוספים חיבורים למסד הנתונים. מבחינת התכנון, מכיוון שמסדי נתונים לא יכולים לתמוך במספר בלתי מוגבל של חיבורים, צריך לנהל את הוספת החיבורים כדי למנוע עומס יתר.
מערכת מסד הנתונים הטובה ביותר לעומת ניידות של מערכת מסד הנתונים
כשבוחרים מערכות של מסדי נתונים, ארגונים בדרך כלל בוחרים את המערכת שהכי מתאימה לדרישות של האפליקציה. בסביבה עם כמה עננים, אפשר לבחור את מסד הנתונים הכי טוב בכל ענן, ולקשר ביניהם בהתאם לתרחיש לדוגמה. אם המערכות האלה שונות, כל שכפול – חד-כיווני או דו-כיווני – דורש מאמץ משמעותי. הגישה הזו יכולה להיות מוצדקת אם היתרון של שימוש במערכת הטובה ביותר עולה על המאמץ שנדרש כדי להטמיע אותה.
עם זאת, מומלץ לשקול ולהעריך במקביל גישה למערכת של מסד נתונים שזמינה בכל העננים הנדרשים. יכול להיות שמסד נתונים כזה לא יהיה אידיאלי כמו האפשרות הטובה ביותר, אבל אולי יהיה הרבה יותר קל להטמיע, להפעיל ולתחזק מערכת כזו.
הערכה של מערכת מסדי נתונים בו-זמנית מדגימה את היתרונות והחסרונות של שתי מערכות מסדי הנתונים, ומספקת בסיס מוצק לבחירה.
רפליקציה של מערכת מסד נתונים מובנית לעומת חיצונית
בתרחישים לדוגמה שבהם נדרשת מערכת מסד נתונים בכל מיקומי הפריסה (אזורים, אזורים גיאוגרפיים או עננים), הרפליקציה היא תכונה חשובה. הרפליקציה יכולה להיות אסינכרונית, דו-כיוונית או רפליקציה פעילה-פעילה בסנכרון מלא. לא כל מערכות מסדי הנתונים תומכות בכל צורות הרפליקציה האלה.
במערכות שלא תומכות ברפליקציה כחלק מהטמעת המערכת, אפשר להשתמש במערכות כמו Striim כדי להשלים את הארכיטקטורה (כפי שמתואר במאמר העברת מסדי נתונים).
מומלץ לבחון מערכות חלופיות לניהול מסדי נתונים כדי להבין את היתרונות והחסרונות של מערכת עם רפליקציה מובנית, לעומת מערכת שדורשת טכנולוגיית רפליקציה.
גם סוג שלישי של טכנולוגיה ממלא תפקיד במקרה הזה. הסוג הזה מספק תוספים למערכות מסדי נתונים קיימות כדי לספק רפליקציה. דוגמה אחת היא MariaDB Galera Cluster. אם תהליך ההערכה מאפשר זאת, מומלץ להעריך את המערכות האלה.
מסדי נתונים מרובי מודלים
מסדי נתונים מרובי מודלים מספקים ניהול נתונים גמיש וניתן להרחבה בענן ובאפליקציות בזמן אמת. מסדי נתונים מרובי מודלים תומכים בכמה מודלים של נתונים, כמו מסמך, תרשים, ערך מפתח, קבוצת עמודות ומסד נתונים יחסי, בממשק שאילתות ובמנוע אחסון מאוחדים. היכולות האלה מספקות יתרונות כמו:
- ניהול פשוט יותר: המפתחים מנהלים סוגי נתונים שונים במערכת אחת של מסד נתונים, וכך מפחיתים את המורכבות התפעולית ואת התקורה.
- פיתוח מהיר יותר: מסדי נתונים מרובי מודלים מספקים את הגמישות להשתמש במודל הנתונים האופטימלי לצרכים שונים. הגמישות הזו יכולה להאיץ את הפיתוח ולעזור לכם להסתגל מהר יותר לדרישות המשתנות.
- שילוב קל יותר: ממשק שאילתות ומנוע אחסון מאוחדים מפחיתים את המורכבות של חיבור וסנכרון של מסדי נתונים שונים.
- שאילתות משופרות: מפתחים יכולים לשלוח שאילתות ולשלב נתונים ממודלים שונים, וכך לקבל תובנות עשירות יותר ולהשתמש בתכונות מתקדמות יותר באפליקציות.
- חיסכון בעלויות: פחות מערכות של מסדי נתונים פירושן עלויות נמוכות יותר של רישוי, חומרה והוצאות תפעוליות.
- אופטימיזציה של הביצועים: בחירה במודל הנתונים המתאים ביותר למשימות ספציפיות יכולה לשפר את ביצועי האפליקציה.
לדוגמה, Spanner מציע תכונות של מודלים מרובים עם תמיכה בניב של PostgreSQL. היכולת הזו מאפשרת לכם לפתח אפליקציות חכמות מבוססות-AI באמצעות נתונים יחסיים ונתוני NoSQL, לשלוח שאילתות לגבי קשרים מורכבים באמצעות Spanner Graph ולהשתמש בחיפוש וקטורי לחיפוש סמנטי.
המאמרים הבאים
- מידע על דפוסי ארכיטקטורה היברידית וריבוי עננים
- תבניות לחיבור ספקי שירותי ענן אחרים ל-Google Cloud
- מידע ולמידה על ארכיטקטורות של מעקב ורישום ביומן לפריסות היברידיות ומרובות עננים ב- Google Cloud.
- לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.
שותפים ביצירת התוכן
מחבר: אלכס קרצ'יו | ארכיטקט פתרונות