השלב הראשון בבניית תשתית אמינה לעומסי העבודה בענן הוא לזהות את דרישות האמינות של עומסי העבודה. החלק הזה של Google Cloud מדריך האמינות של התשתית מספק הנחיות שיעזרו לכם להגדיר את דרישות האמינות של עומסי עבודה שאתם פורסים ב- Google Cloud.
קביעת דרישות ספציפיות לעומסי עבודה
דרישות האמינות של אפליקציה תלויות באופי השירות שהאפליקציה מספקת או בתהליך שהיא מבצעת. לדוגמה, אפליקציה שמספקת שירותי כספומט לבנק עשויה לדרוש זמינות של 99.999%. אתר שתומך בפלטפורמת מסחר אונליין עשוי לדרוש זמינות של 99.999% וזמן תגובה מהיר. תהליך אצווה שכותב עסקאות בנק לספר חשבונות בסוף כל יום עשוי להיות בעל יעד של 8 שעות לרענון הנתונים.
בתוך אפליקציה, יכול להיות שלרכיבים או לפעולות שונים יהיו דרישות שונות לגבי מהימנות. לדוגמה, באפליקציה לעיבוד הזמנות יכול להיות שיהיה צורך במהימנות גבוהה יותר לפעולות שכותבות נתונים למסד הנתונים של ההזמנות, בהשוואה לבקשות קריאה.
הערכה של דרישות האמינות של עומסי העבודה ברמת הגרנולריות עוזרת לכם למקד את ההוצאות והמאמצים בעומסי העבודה שחיוניים לעסק שלכם.
זיהוי תקופות קריטיות
יכול להיות שיהיו תקופות שבהן אפליקציה מסוימת תהיה קריטית יותר לעסק מאשר בתקופות אחרות. בדרך כלל אלה התקופות שבהן העומס על האפליקציה הוא בשיא. כדאי לזהות את התקופות האלה, לתכנן קיבולת מתאימה ולבדוק את האפליקציה בתנאי עומס שיא. כדי להימנע מהסיכון להפסקות פעולה של האפליקציה בתקופות של עומס שימוש גבוה, אפשר להשתמש בשיטות תפעול מתאימות, כמו הקפאת קוד הייצור.
הדוגמאות הבאות הן של אפליקציות שחווות עליות עונתיות בעומס:
- בדרך כלל, השימוש במודול המלאי של אפליקציית הנהלת חשבונות פיננסית אינטנסיבי יותר בימים שבהם מתוכננות ביקורות מלאי חודשיות, רבעוניות או שנתיות.
- באתר מסחר אלקטרוני יהיו עליות משמעותיות בעומס במהלך עונות קניות שיא או אירועים שיווקיים.
- במסד נתונים שתומך במודול קבלת התלמידים של אוניברסיטה, יהיה נפח גבוה של פעולות כתיבה בחודשים מסוימים בכל שנה.
- שירות מקוון להגשת דוחות מס יחווה עומס גבוה במהלך עונת הגשת דוחות המס.
- פלטפורמת מסחר אונליין עשויה לדרוש זמינות של 99.999% וזמן תגובה מהיר, אבל רק בשעות המסחר (לדוגמה, מ-8:00 עד 17:00 מיום שני עד יום שישי).
שיקולים לגבי דרישות לא פונקציונליות אחרות
בנוסף לדרישות האמינות, לאפליקציות ארגוניות יכולות להיות דרישות חשובות אחרות שאינן פונקציונליות, כמו דרישות אבטחה, ביצועים, עלות ויעילות תפעולית. כשמעריכים את דרישות המהימנות של אפליקציה, צריך לקחת בחשבון את התלות ואת הפשרות עם הדרישות האחרות האלה.
הדוגמאות הבאות הן של דרישות שלא קשורות למהימנות, אבל יכולות להיות כרוכות בפשרות עם דרישות מהימנות.
- אופטימיזציה של עלויות: כדי לייעל את עלויות ה-IT, יכול להיות שהארגון שלכם יגדיר מכסות למשאבי ענן מסוימים. לדוגמה, כדי להפחית את העלות של רישיונות לתוכנות של צד שלישי, הארגון יכול להגדיר מכסות למספר ליבות המחשוב שאפשר להקצות. יכולות להיות מכסות דומות לגבי כמות הנתונים שאפשר לאחסן ונפח תנועת הרשת בין אזורים. כדאי לקחת בחשבון את ההשפעות של מגבלות העלויות האלה על האפשרויות הזמינות לתכנון תשתית אמינה.
- מיקום הנתונים: כדי לעמוד בדרישות רגולטוריות, יכול להיות שהאפליקציה שלכם תצטרך לאחסן ולעבד נתונים במדינות ספציפיות, גם אם העסק משרת משתמשים ברחבי העולם. חשוב לקחת בחשבון את ההגבלות האלה על מיקום הנתונים כשמחליטים באילו אזורים ובאילו תחומים אפשר לפרוס את האפליקציות.
החלטות עיצוביות מסוימות שאתם מקבלים כדי לעמוד בדרישות אחרות יכולות לעזור לשפר את המהימנות של האפליקציות שלכם. הנה כמה דוגמאות:
- אוטומציה של פריסה: כדי להפעיל את הפריסות בענן בצורה יעילה, אפשר להחליט להפוך את תהליך הקצאת המשאבים לאוטומטי באמצעות תשתית כקוד (IaC). באופן דומה, אפשר לבצע אוטומציה של תהליך ה-build והפריסה של האפליקציה באמצעות צינור עיבוד נתונים של אינטגרציה רציפה (CI) ופריסה רציפה (CD). שימוש ב-IaC ובצינורות CI/CD יכול לעזור לשפר לא רק את היעילות התפעולית, אלא גם את המהימנות של עומסי העבודה.
- אמצעי בקרה לאבטחה: אמצעי בקרה לאבטחה שאתם מטמיעים יכולים גם לעזור לשפר את הזמינות של האפליקציה. לדוגמה, כללי מדיניות האבטחה של Google Cloud Armor יכולים לעזור לוודא שהאפליקציה תישאר זמינה במהלך התקפות מניעת שירות (DoS).
- שמירת תוכן במטמון: כדי לשפר את הביצועים של אפליקציה להצגת תוכן, אפשר להפעיל שמירה במטמון כחלק מההגדרה של מאזן העומסים. בעזרת העיצוב הזה, המשתמשים נהנים לא רק מגישה מהירה יותר לתוכן, אלא גם מזמינות גבוהה יותר. הם יכולים לגשת לתוכן שנשמר במטמון גם כשהשרתים המקוריים מושבתים.
בדיקה מחדש של הדרישות מדי פעם
כשהעסק מתפתח וגדל, יכול להיות שהדרישות של האפליקציות ישתנו. חשוב להעריך מחדש את דרישות המהימנות שלכם מעת לעת, ולוודא שהן תואמות ליעדים ולסדרי העדיפויות העסקיים הנוכחיים של הארגון.
נניח שיש לכם אפליקציה שמספקת רמת זמינות רגילה לכל המשתמשים. יכול להיות שפרסתם את האפליקציה בשני תחומים (zones) בתוך אזור מסוים, עם מאזן עומסים אזורי כקצה קדמי. אם הארגון שלכם מתכנן להשיק אפשרות לשירות פרימיום שמספק זמינות גבוהה יותר, דרישות האמינות של האפליקציה משתנות. כדי לעמוד בדרישות הזמינות החדשות, יכול להיות שתצטרכו לפרוס את האפליקציה בכמה אזורים ולהשתמש במאזן עומסים גלובלי עם Cloud CDN מופעל.
הזדמנות נוספת להערכה מחדש של דרישות הזמינות של האפליקציות שלכם היא אחרי הפסקת שירות. הפסקות שירות עשויות לחשוף חוסר התאמה בציפיות בין צוותים שונים בעסק שלכם. לדוגמה, צוות אחד עשוי להחשיב הפסקת שירות של 45 דקות פעם בשנה (כלומר, זמינות שנתית של 99.99%) כמצב מקובל. אבל צוות אחר עשוי לצפות לזמן השבתה מקסימלי של 4.3 דקות בחודש (כלומר, זמינות חודשית של 99.99%). בהתאם להחלטה שלכם לגבי שינוי או הבהרה של דרישות הזמינות, תצטרכו להתאים את הארכיטקטורה שלכם לדרישות החדשות.