כשעוברים מסביבת מחשוב לא היברידית או לא מרובת עננים לארכיטקטורה היברידית או מרובת עננים, חשוב קודם לשקול את המגבלות של האפליקציות הקיימות ואת האופן שבו המגבלות האלה עלולות לגרום לכשל באפליקציה. השיקול הזה חשוב במיוחד אם האפליקציות או רכיבי האפליקציות פועלים בצורה מבוזרת בסביבות שונות. אחרי ששוקלים את המגבלות, צריך לגבש תוכנית כדי להימנע מהן או להתגבר עליהן. חשוב לשקול את היכולות הייחודיות של כל סביבת מחשוב בארכיטקטורה מבוזרת.
שיקולים לגבי העיצוב
השיקולים הבאים רלוונטיים לדפוסי פריסה מבוזרים. העדיפות וההשפעה של כל שיקול עשויות להשתנות בהתאם לפתרון המטרה וליעדים העסקיים.
זמן אחזור
בכל תבנית ארכיטקטורה שמפיצה רכיבי אפליקציה (ממשקי קצה, קצה עורפי או מיקרו-שירותים) בסביבות מחשוב שונות, יכול להתרחש זמן אחזור בתקשורת. זמן האחזור הזה מושפע מקישוריות הרשת ההיברידית (Cloud VPN ו-Cloud Interconnect) ומהמרחק הגיאוגרפי בין האתר המקומי לבין האזורים בענן, או בין אזורים בענן בהגדרה של כמה עננים. לכן, חשוב להעריך את דרישות זמן האחזור של האפליקציות ואת הרגישות שלהן לעיכובים ברשת. אפליקציות שיכולות לסבול זמן אחזור הן מועמדות מתאימות יותר לפריסה מבוזרת ראשונית בסביבה היברידית או בסביבה של כמה עננים.
ארכיטקטורה של מצב זמני לעומת מצב סופי
כדי לציין את הציפיות ואת ההשלכות הפוטנציאליות על העלות, על ההתאמה ועל הביצועים, חשוב בשלב התכנון לנתח את סוג הארכיטקטורה שאתם צריכים ואת משך הזמן המיועד. לדוגמה, אם אתם מתכננים להשתמש בארכיטקטורה היברידית או מרובת עננים (multi-cloud) לטווח ארוך או באופן קבוע, כדאי לשקול שימוש ב-Cloud Interconnect. כדי להפחית את עלויות העברת הנתונים היוצאים ולבצע אופטימיזציה של ביצועי הרשת בקישוריות היברידית, Cloud Interconnect מעניק הנחות על חיובים של העברת נתונים יוצאים שעומדים בתנאים של שיעור הנחה על העברת נתונים.
אמינות
אמינות היא שיקול חשוב בתכנון של מערכות IT. זמינות זמן הפעולה היא היבט חיוני באמינות המערכת. ב- Google Cloud, אפשר להגדיל את החוסן של אפליקציה על ידי פריסת רכיבים מיותרים של האפליקציה הזו בכמה אזורים באזור יחיד1, או בכמה אזורים, עם יכולות מעבר אוטומטי. יתירות היא אחד מהאלמנטים החשובים לשיפור הזמינות הכוללת של אפליקציה. באפליקציות עם הגדרה מבוזרת בסביבות היברידיות ומרובות עננים (multi-cloud), חשוב לשמור על רמת זמינות עקבית.
כדי לשפר את הזמינות של מערכת בסביבה מקומית או בסביבות ענן אחרות, כדאי לשקול אילו חומרה או תוכנה מיותרות – עם מנגנוני מעבר לגיבוי – נדרשות לאפליקציות ולרכיבים שלהן. באופן אידיאלי, כדאי לשקול את הזמינות של שירות או אפליקציה ברכיבים השונים ובתשתית התומכת (כולל זמינות של קישוריות היברידית) בכל הסביבות. המושג הזה נקרא גם זמינות מורכבת של אפליקציה או שירות.
בהתאם לתלות בין הרכיבים או השירותים, הזמינות המורכבת של אפליקציה עשויה להיות גבוהה או נמוכה יותר מזו של שירות או רכיב בודדים. מידע נוסף זמין במאמר זמינות משולבת: חישוב הזמינות הכוללת של תשתיות ענן.
כדי להשיג את רמת המהימנות הרצויה של המערכת, צריך להגדיר מדדי מהימנות ברורים ולתכנן את האפליקציות כך שיתקנו את עצמן ויעמדו בפני שיבושים ביעילות בסביבות השונות. כדי להגדיר דרכים מתאימות למדידת חוויית הלקוח בשירותים שלכם, אפשר לעיין במאמר בנושא הגדרת מהימנות על סמך יעדים של חוויית משתמש.
קישוריות היברידית ומרובת עננים (multi-cloud)
הדרישות של התקשורת בין רכיבי האפליקציות המבוזרות צריכות להשפיע על הבחירה שלכם באפשרות קישוריות לרשת היברידית. לכל אפשרות קישוריות יש יתרונות וחסרונות, וגם גורמים ספציפיים שצריך לקחת בחשבון, כמו עלות, נפח תנועה, אבטחה וכן הלאה. מידע נוסף זמין בקטע שיקולים בתכנון הקישוריות.
ניהול הענן
כדי להגדיר בהצלחה סביבות היברידיות וסביבות מרובות עננים (עם או בלי ניוד של עומסי עבודה), חשוב להשתמש בכלים עקביים ומאוחדים לניהול ולניטור. בטווח הקצר, הכלים האלה יכולים להוסיף עלויות פיתוח, בדיקה ותפעול. מבחינה טכנית, ככל שמשתמשים ביותר ספקי שירות בענן, כך ניהול הסביבות נעשה מורכב יותר. לרוב ספקי הענן הציבורי יש לא רק תכונות שונות, אלא גם כלים, הסכמי רמת שירות (SLA) וממשקי API שונים לניהול שירותי הענן. לכן, חשוב לשקול את היתרונות האסטרטגיים של הארכיטקטורה שבחרתם לעומת המורכבות הפוטנציאלית לטווח הקצר והיתרונות לטווח הארוך.
עלות
לכל ספק שירותי ענן בסביבת מולטי-ענן יש מדדים וכלים משלו לחיוב. כדי לקבל תמונה ברורה יותר ומרכזי בקרה מאוחדים, כדאי להשתמש בכלים לניהול עלויות ולאופטימיזציה של עלויות בענן מרובה ספקים. לדוגמה, כשמפתחים פתרונות שמתאימים לענן בכמה סביבות ענן, המוצרים, התמחור, ההנחות וכלי הניהול של כל ספק יכולים ליצור חוסר עקביות בעלויות בין הסביבות האלה.
מומלץ להשתמש בשיטה מוגדרת אחת לחישוב העלויות המלאות של משאבי הענן, כדי לקבל תמונה ברורה של העלויות. תמונה ברורה של העלויות חיונית לאופטימיזציה של העלויות. לדוגמה, אפשר לשלב נתוני חיוב מספקי הענן שבהם אתם משתמשים ולהשתמש ב- Google Cloud Looker Cloud Cost Management Block כדי ליצור תצוגה מרכזית של העלויות בענן מרובה ספקים. התצוגה הזו יכולה לעזור לכם לקבל דוח מאוחד של ההוצאות שלכם בעננים שונים. למידע נוסף, אפשר לעיין במאמר אסטרטגיה לאופטימיזציה יעילה של ניהול עלויות בחיוב ב-Cloud.
מומלץ גם להשתמש בשיטות FinOps כדי להציג את העלויות. כחלק משיטת FinOps יעילה, צוות מרכזי יכול להקצות לצוותים אחרים שמעורבים בפרויקט את האחריות לקבלת החלטות לגבי אופטימיזציה של משאבים, כדי לעודד אחריות אישית. במודל הזה, הצוות המרכזי צריך לתקנן את התהליך, את הדיווח ואת הכלים לאופטימיזציה של העלויות. מידע נוסף על ההמלצות וההיבטים השונים של אופטימיזציה של עלויות זמין במאמר Google Cloud Well-Architected Framework: Cost optimization.
העברת נתונים
העברת נתונים היא שיקול חשוב בתכנון אסטרטגיה וארכיטקטורה של סביבות היברידיות ומרובות עננים (multi-cloud), במיוחד במערכות מבוזרות. חברות צריכות לזהות את המקרים העסקיים השונים שלהן, את הנתונים שמפעילים אותם ואת סיווג הנתונים (בתעשיות מפוקחות). כדאי גם לחשוב איך אחסון, שיתוף וגישה לנתונים במערכות מבוזרות בסביבות שונות עשויים להשפיע על ביצועי האפליקציה ועקביות הנתונים. הגורמים האלה עשויים להשפיע על האפליקציה ועל ארכיטקטורת צינור הנתונים. Google Cloudהסט המקיף של אפשרויות להעברת נתונים מאפשר לעסקים לענות על הצרכים הספציפיים שלהם ולאמץ ארכיטקטורות היברידיות וארכיטקטורות מרובות עננים בלי להתפשר על פשטות, יעילות או ביצועים.
אבטחה
כשמעבירים אפליקציות לענן, חשוב לקחת בחשבון יכולות אבטחה שמתאימות לענן, כמו עקביות, יכולת צפייה ושקיפות אבטחתית מאוחדת. לכל ספק שירותי ענן ציבורי יש גישה משלו, שיטות מומלצות ויכולות אבטחה. חשוב לנתח את היכולות האלה ולהתאים אותן כדי לבנות ארכיטקטורת אבטחה סטנדרטית ופונקציונלית. אמצעי בקרה חזקים של IAM, הצפנת נתונים, בדיקת נקודות חולשה ועמידה בתקנות התעשייה הם גם היבטים חשובים של אבטחת ענן.
כשמתכננים אסטרטגיית מיגרציה, מומלץ לנתח את השיקולים שצוינו למעלה. הם יכולים לעזור לכם לצמצם את הסיכויים להוספת מורכבויות לארכיטקטורה ככל שהאפליקציות או נפחי התנועה גדלים. בנוסף, תכנון ובנייה של אזור נחיתה הם כמעט תמיד תנאי מוקדם לפריסת עומסי עבודה ארגוניים בסביבת ענן. אזור נחיתה עוזר לארגון שלכם לפרוס, להשתמש ולהרחיב שירותי ענן בצורה מאובטחת יותר במספר תחומים, והוא כולל רכיבים שונים, כמו זהויות, ניהול משאבים, אבטחה ורשת. למידע נוסף, אפשר לעיין במאמר בנושא תכנון אזור נחיתה ב- Google Cloud.
במסמכים הבאים בסדרה הזו מתוארים דפוסי ארכיטקטורה מבוזרת אחרים:
- תבנית היברידית מדורגת
- תבנית מרובת עננים עם חלוקה למחיצות
- דפוס היברידי ומרובה עננים ב-Analytics
- תבנית היברידית של Edge
-
מידע נוסף על שיקולים ספציפיים לאזור זמין במאמר מיקום גיאוגרפי ואזורים. ↩