השימוש באפליקציות אינטרנט יכול להשתנות באופן קיצוני. רוב האפליקציות הארגוניות לא מתמודדות עם האתגר הזה, אבל ארגונים רבים צריכים להתמודד עם סוג אחר של עומס עבודה משתנה: עבודות אצווה או עבודות CI/CD.
תבנית הארכיטקטורה הזו מסתמכת על פריסה מיותרת של אפליקציות במספר סביבות מחשוב. המטרה היא להגדיל את הקיבולת, את העמידות או את שניהם.
אפשר להקצות יותר מדי משאבים כדי להתמודד עם עומסי עבודה עם שיאי פעילות בסביבת מחשוב שמבוססת על מרכזי נתונים, אבל יכול להיות שהגישה הזו לא תהיה חסכונית. בעזרת משימות אצווה אפשר לבצע אופטימיזציה של השימוש על ידי הארכת משך הביצוע שלהן, אבל לא מומלץ לדחות משימות שרגישות לזמן.
הרעיון של תבנית cloud bursting הוא להשתמש בסביבת מחשוב פרטית עבור עומס הבסיס, ולעבור באופן זמני לענן כשצריך קיבולת נוספת.
בתרשים שלמעלה, אם הקיבולת של הנתונים בסביבה פרטית מקומית מגיעה למקסימום, המערכת יכולה לקבל קיבולת נוספת מסביבתGoogle Cloud כשצריך.
הגורמים העיקריים לדפוס הזה הם חיסכון בכסף וקיצור הזמן והמאמץ שנדרשים כדי להגיב לשינויים בדרישות לגבי קנה מידה. בגישה הזו, אתם משלמים רק על המשאבים שבהם נעשה שימוש כשמטפלים בעומסים נוספים. כלומר, לא צריך להקצות יותר מדי משאבים לתשתית. במקום זאת, אתם יכולים לנצל את המשאבים בענן על פי דרישה ולהתאים אותם לביקוש ולמדדים שהוגדרו מראש. כתוצאה מכך, יכול להיות שהחברה שלכם תמנע שיבושים בשירות בזמנים של ביקוש שיא.
דרישה פוטנציאלית לתרחישי cloud bursting היא ניידות של עומסי עבודה. כשמאפשרים פריסה של עומסי עבודה בסביבות שונות, צריך להסתיר את ההבדלים בין הסביבות. לדוגמה, Kubernetes מאפשרת לכם להשיג עקביות ברמת עומס העבודה בסביבות מגוונות שמשתמשות בתשתיות שונות. למידע נוסף, תוכלו לעיין בארכיטקטורת העזר של סביבה היברידית ב-Google Kubernetes Engine (GKE).
שיקולים בתכנון
התבנית של cloud bursting חלה על עומסי עבודה אינטראקטיביים ועל עומסי עבודה באצווה. אבל כשמדובר בעומסי עבודה אינטראקטיביים, צריך להחליט איך לבזר את הבקשות בין הסביבות:
אתם יכולים להפנות בקשות משתמשים נכנסות למאזן עומסים שפועל במרכז הנתונים הקיים, ואז להגדיר את מאזן העומסים כך שיפיץ את הבקשות בין המשאבים המקומיים והמשאבים בענן.
בגישה הזו, מאזן העומסים או מערכת אחרת שפועלים במרכז הנתונים הקיים צריכים לעקוב גם אחרי המשאבים שמוקצים בענן. מאזן העומסים או מערכת אחרת צריכים גם ליזום את הגדלת או הקטנת המשאבים באופן אוטומטי. באמצעות הגישה הזו, אפשר להוציא משימוש את כל משאבי הענן בזמנים של פעילות נמוכה. עם זאת, הטמעה של מנגנונים למעקב אחרי משאבים עשויה לחרוג מהיכולות של פתרונות איזון העומסים, ולכן להגביר את המורכבות הכוללת.
במקום להטמיע מנגנונים למעקב אחרי משאבים, אפשר להשתמש ב-Cloud Load Balancing עם קצה עורפי של קבוצת נקודות קצה ברשת (NEG) לקישוריות היברידית. אתם משתמשים במאזן העומסים הזה כדי להפנות בקשות של לקוחות פנימיים או בקשות של לקוחות חיצוניים אל שרתים עורפיים שנמצאים גם במקום וגם ב-Google Cloud , ושמבוססים על מדדים שונים, כמו פיצול תנועה לפי משקל. בנוסף, אפשר לשנות את גודל שרתי הבק-אנד בהתאם לקיבולת ההגשה של איזון העומסים עבור עומסי עבודה ב- Google Cloud. מידע נוסף זמין במאמר סקירה כללית על ניהול תעבורת נתונים במאזן עומסים גלובלי חיצוני של אפליקציות (ALB).
לגישה הזו יש כמה יתרונות נוספים, כמו ניצול יכולות ההגנה מפני מתקפות DDoS של Google Cloud Armor, חומת אש ליישומי אינטרנט (WAF) ושמירת תוכן במטמון בקצה הענן באמצעות Cloud CDN. עם זאת, צריך להתאים את גודל הקישוריות של הרשת ההיברידית כדי לטפל בתנועה הנוספת.
כפי שצוין במאמר בנושא ניוד עומסי עבודה, יכול להיות שאפשר לנייד אפליקציה לסביבה אחרת עם שינויים מינימליים כדי להשיג עקביות בעומס העבודה, אבל זה לא אומר שהביצועים של האפליקציה יהיו זהים בשתי הסביבות. ההבדלים בביצועים נובעים בדרך כלל מההבדלים בחישוב הבסיסי, ביכולות האבטחה של התשתית או בתשתית הרשת, וגם מהקרבה לשירותים תלויים. בעזרת בדיקות, תוכלו לקבל תובנות מדויקות יותר ולהבין את ציפיות הביצועים.
אתם יכולים להשתמש בשירותי תשתית ענן כדי לבנות סביבה לאירוח האפליקציות שלכם בלי ניידות. כדי לטפל בבקשות של לקוחות כשנפח התנועה מופנה מחדש בשעות השיא של הביקוש, אפשר להשתמש בגישות הבאות:
- כדאי להשתמש בכלים עקביים כדי לעקוב אחרי שתי הסביבות האלה ולנהל אותן.
- חשוב לוודא שהגרסאות של עומסי העבודה עקביות ושמקורות הנתונים עדכניים.
- יכול להיות שתצטרכו להוסיף אוטומציה כדי להקצות את סביבת הענן ולנתב מחדש את התנועה כשעולה הביקוש, וכשעומס העבודה בענן צפוי לקבל בקשות לקוח עבור האפליקציה שלכם.
אם אתם מתכוונים להשבית את כל Google Cloud המשאבים בזמנים של ביקוש נמוך, שימוש בכללי מדיניות של ניתוב DNS בעיקר לאיזון עומסי תנועה לא תמיד יהיה אופטימלי. הסיבות העיקריות לכך הן:
- יכול להיות שיעבור זמן עד שהמשאבים יאותחלו ויהיו זמינים למשתמשים.
- עדכוני DNS מופצים באינטרנט בדרך כלל לאט.
כתוצאה מכך:
- יכול להיות שהמשתמשים ינותבו לסביבת הענן גם אם אין משאבים זמינים לעיבוד הבקשות שלהם.
- יכול להיות שהמשתמשים ימשיכו להיות מנותבים לסביבה המקומית באופן זמני בזמן שהעדכונים של ה-DNS מתפשטים באינטרנט.
בעזרת Cloud DNS, אתם יכולים לבחור את מדיניות ה-DNS ומדיניות הניתוב שמתאימות לארכיטקטורה ולהתנהגות של הפתרון שלכם, כמו מדיניות ניתוב DNS לפי מיקום גיאוגרפי. Cloud DNS תומך גם בבדיקות תקינות של מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי ומאזן עומסים פנימי של אפליקציות (ALB). במקרה כזה, תוכלו לשלב אותו בהגדרת ה-DNS ההיברידי הכוללת שלכם שמבוססת על הדפוס הזה.
בתרחישים מסוימים, אפשר להשתמש ב-Cloud DNS כדי להפיץ בקשות של לקוחות עם בדיקות תקינות ב- Google Cloud, למשל כשמשתמשים במאזני עומסים פנימיים של אפליקציות או במאזני עומסים פנימיים של אפליקציות בין אזורים. בתרחיש הזה, Cloud DNS בודק את התקינות הכוללת של מאזן העומסים הפנימי של האפליקציה, שבודק בעצמו את התקינות של מופעי ה-Backend. מידע נוסף זמין במאמר ניהול מדיניות ניתוב DNS ובדיקות תקינות.
אפשר גם להשתמש בחלוקת האופק ב-Cloud DNS. התכונה 'אופק מפוצל' ב-Cloud DNS היא גישה להגדרת תגובות או רשומות DNS למיקום או לרשת הספציפיים של יוצר שאילתת ה-DNS עבור אותו שם דומיין. הגישה הזו נפוצה בדרך כלל כדי לענות על דרישות שבהן אפליקציה מיועדת להציע חוויה פרטית וגם חוויה ציבורית, שלכל אחת מהן יש תכונות ייחודיות. הגישה הזו עוזרת גם לחלק את עומס התנועה בין הסביבות.
בהתחשב בשיקולים האלה, בדרך כלל כדאי יותר להשתמש ב-cloud bursting לעומסי עבודה של אצווה מאשר לעומסי עבודה אינטראקטיביים.
יתרונות
היתרונות המרכזיים של תבנית הארכיטקטורה cloud bursting:
- באמצעות Cloud bursting, אפשר לעשות שימוש חוזר בהשקעות קיימות במרכזי נתונים ובסביבות מחשוב פרטיות. השימוש החוזר יכול להיות קבוע או בתוקף עד שהציוד הקיים יגיע למועד ההחלפה, ובשלב הזה כדאי לשקול מעבר מלא.
- מכיוון שלא צריך יותר לשמור על קיבולת עודפת כדי לעמוד בביקוש בשיא, יכול להיות שתוכלו להגדיל את השימוש בסביבות המחשוב הפרטיות שלכם ולשפר את העלות-תועלת שלהן.
- בעזרת Cloud bursting אפשר להריץ משימות אצווה בזמן בלי להקצות יותר מדי משאבי מחשוב.
שיטות מומלצות
כשמטמיעים את cloud bursting, כדאי לפעול לפי השיטות המומלצות הבאות:
- כדי לוודא שעומסי עבודה שפועלים בענן יכולים לגשת למשאבים באותו אופן כמו עומסי עבודה שפועלים בסביבה מקומית, צריך להשתמש בדפוס רשת עם העיקרון של הרשאות מינימליות לגישה מאובטחת. אם עיצוב עומס העבודה מאפשר זאת, אפשר לאפשר גישה רק מהענן לסביבת המחשוב המקומית, ולא להיפך.
- כדי לצמצם את זמן האחזור בתקשורת בין סביבות, צריך לבחור Google Cloud אזור שקרוב מבחינה גיאוגרפית לסביבת המחשוב הפרטית. למידע נוסף, ראו שיטות מומלצות לבחירת אזורים ב-Compute Engine.
- אם משתמשים ב-cloud bursting רק לעומסי עבודה של אצווה, כדאי לצמצם את שטח הפנים של מתקפת האבטחה על ידי שמירה על פרטיות של כל Google Cloud המשאבים. אסור לאפשר גישה ישירה למשאבים האלה מהאינטרנט, גם אם משתמשים באיזון עומסים חיצוני כדי לספק את נקודת הכניסה לעומס העבודה. Google Cloud
בוחרים את מדיניות ה-DNS ומדיניות הניתוב שמתאימות לדפוס הארכיטקטורה ולהתנהגות הפתרון המטורגט.
- כחלק מהדפוס הזה, אתם יכולים להחיל את העיצוב של מדיניות ה-DNS שלכם באופן קבוע או כשאתם צריכים קיבולת נוספת באמצעות סביבה אחרת בזמנים של ביקוש שיא.
- אתם יכולים להשתמש במדיניות ניתוב של DNS לפי מיקום גיאוגרפי כדי להגדיר נקודת קצה גלובלית של DNS למאזני העומסים האזוריים שלכם. יש הרבה תרחישי שימוש בטקטיקה הזו במדיניות ניתוב DNS לפי מיקום גיאוגרפי, כולל אפליקציות היברידיות שמשתמשות ב- Google Cloud לצד פריסה מקומית שבה קיים אזור Google Cloud .
אם אתם צריכים לספק רשומות שונות לאותן שאילתות DNS, אתם יכולים להשתמש ב-DNS עם אופק מפוצל – לדוגמה, שאילתות מלקוחות פנימיים וחיצוניים.
מידע נוסף זמין במאמר תרשימי עזר לארכיטקטורות של DNS היברידי
כדי לוודא ששינויים ב-DNS יופצו במהירות, צריך להגדיר את ה-DNS עם אורך חיים (TTL) קצר יחסית, כדי שתוכלו להפנות מחדש משתמשים למערכות המתנה כשתזדקקו לקיבולת נוספת באמצעות סביבות ענן.
למשימות שלא דורשות ביצוע בזמן קריטי, ושלא מאחסנות נתונים באופן מקומי, כדאי להשתמש במכונות וירטואליות מסוג Spot, שהן זולות משמעותית ממכונות וירטואליות רגילות. עם זאת, יש תנאי מקדים: אם משימת ה-VM נקטעת, המערכת צריכה להיות מסוגלת להפעיל מחדש את המשימה באופן אוטומטי.
להשתמש בקונטיינרים כדי להשיג ניידות של עומסי עבודה במקרים הרלוונטיים. בנוסף, GKE יכול להיות טכנולוגיה מרכזית שמאפשרת את התכנון הזה. מידע נוסף זמין במאמר ארכיטקטורת עזר של סביבה היברידית ב-GKE.
מעקב אחרי תנועה שנשלחת מ Google Cloud לסביבת מחשוב אחרת. התנועה הזו כפופה לחיובים על העברת נתונים יוצאת.
אם אתם מתכננים להשתמש בארכיטקטורה הזו לטווח ארוך עם נפח גבוה של העברת נתונים יוצאים, כדאי לשקול שימוש ב-Cloud Interconnect. Cloud Interconnect יכול לעזור לשפר את ביצועי הקישוריות, ועשוי להפחית את העלויות של העברת נתונים יוצאים לתנועה שעומדת בתנאים מסוימים. מידע נוסף זמין במאמר בנושא תמחור של Cloud Interconnect.
כשמשתמשים ב-Cloud Load Balancing, כדאי להשתמש ביכולות האופטימיזציה של קיבולת האפליקציה שלו, איפה שרלוונטי. הפעולה הזו יכולה לעזור לכם להתמודד עם חלק מהבעיות שקשורות לקיבולת שיכולות לקרות באפליקציות שמופצות ברחבי העולם.
כדי לאמת את האנשים שמשתמשים במערכות שלכם, צריך ליצור זהות משותפת בין הסביבות, כדי שהמערכות יוכלו לבצע אימות מאובטח בין גבולות הסביבות.
כדי להגן על מידע רגיש, מומלץ מאוד להצפין את כל התקשורת בזמן ההעברה. אם נדרשת הצפנה בשכבת הקישוריות, יש אפשרויות שונות בהתאם לפתרון הקישוריות ההיברידי שנבחר. האפשרויות האלה כוללות מנהרות VPN, HA VPN over Cloud Interconnect ו-MACsec ל-Cloud Interconnect.