במסמך הזה, שמופיע בGoogle Cloud Well-Architected Framework: Financial services (FS) perspective, מפורטת סקירה כללית של העקרונות וההמלצות לתכנון, לפריסה ולהפעלה של עומסי עבודה מהימנים של שירותים פיננסיים ב- Google Cloud. במסמך הזה מוסבר איך לשלב שיטות מתקדמות של אמינות וניטור בתרשימי הארכיטקטורה שלכם. ההמלצות במסמך הזה תואמות לעקרון המהימנות של Well-Architected Framework.
עבור מוסדות פיננסיים, תשתית אמינה ועמידה היא גם צורך עסקי וגם חובה רגולטורית. כדי לוודא שעומסי העבודה של FS ב-Google Cloud אמינים, צריך להבין את נקודות הכשל הפוטנציאליות ולצמצם אותן, לפרוס משאבים בצורה מיותרת ולתכנן את השחזור. חוסן תפעולי הוא תוצאה של אמינות. היא היכולת לספוג שיבושים, להסתגל אליהם ולהתאושש מהם. חוסן תפעולי עוזר לארגונים בתחום השירותים הפיננסיים לעמוד בדרישות רגולטוריות מחמירות. היא גם עוזרת למנוע פגיעה בלתי נסבלת בלקוחות.
אבני הבניין העיקריות של מהימנות ב- Google Cloud הן אזורים, תחומים (zones) והיקפי המיקום השונים של משאבי הענן: תחום, אזור, מספר אזורים וגלובלי. כדי לשפר את הזמינות, אפשר להשתמש בשירותים מנוהלים, להפיץ משאבים, להטמיע דפוסי זמינות גבוהה ולבצע אוטומציה של תהליכים.
דרישות רגולטוריות
ארגונים פיננסיים פועלים תחת הנחיות מחמירות בנוגע למהימנות, שמוכתבות על ידי סוכנויות רגולטוריות כמו Federal Reserve System בארה"ב, European Banking Authority באיחוד האירופי ו-Prudential Regulation Authority בבריטניה. ברחבי העולם, הרגולטורים מדגישים את החשיבות של חוסן תפעולי, שהוא חיוני ליציבות פיננסית ולהגנה על הצרכנים. חוסן תפעולי הוא היכולת לעמוד בפני שיבושים, להתאושש מהם ביעילות ולשמור על שירותים קריטיים. לשם כך, נדרשת גישה אחידה לניהול סיכונים טכנולוגיים ולתלות בצדדים שלישיים.
הדרישות הרגולטוריות ברוב תחומי השיפוט כוללות את הנושאים המשותפים הבאים:
- אבטחת סייבר וחוסן טכנולוגי: חיזוק ההגנות מפני איומי סייבר והבטחת החוסן של מערכות ה-IT.
- ניהול סיכונים של צד שלישי: ניהול הסיכונים שקשורים למיקור חוץ של שירותים לספקי טכנולוגיית מידע ותקשורת (ICT).
- המשכיות עסקית ותגובה לאירועים: תכנון מקיף לשמירה על פעולות קריטיות במהלך שיבושים ולהתאוששות יעילה.
- הגנה על היציבות הפיננסית: שמירה על היציבות של המערכת הפיננסית הרחבה יותר.
ההמלצות בנושא מהימנות במסמך הזה ממופות לעקרונות הליבה הבאים:
- תעדיפו פריסות בכמה אזורים וכמה אזורים
- ביטול נקודות כשל בודדות (SPOFs)
- הסבר על זמינות מצטברת וניהול שלה
- הטמעה של אסטרטגיית DR חזקה
- שימוש בשירותים מנוהלים
- אוטומציה של תהליכי הקצאת התשתית והשחזור
העדיפו פריסות במספר אזורים ובכמה אזורים
לאפליקציות קריטיות של שירותים פיננסיים, מומלץ להשתמש בטופולוגיה במספר אזורים שמפוזרת לפחות על פני שני אזורים ועל פני שלושה אזורים בכל אזור. הגישה הזו חשובה כדי להבטיח עמידות במקרה של הפסקות חשמל באזורים ובאזורי זמינות. הגישה הזו מוגדרת לעיתים קרובות בתקנות, כי אם מתרחש כשל באזור אחד, ברוב המקרים שיבוש חמור באזור שני נחשב לתוצאה סבירה. ההסבר לכך הוא שאם מיקום אחד נכשל, יכול להיות שהמיקום השני יקבל כמות גבוהה במיוחד של תנועה נוספת.
כדי לשפר את החוסן (resilience) שלכם בפני הפסקות זמניות בשירות באזורים ובאזורי זמינות, כדאי לפעול לפי ההמלצות הבאות:
- מומלץ להשתמש במשאבים עם היקף מיקום רחב יותר. כשאפשר, כדאי להשתמש במשאבים אזוריים במקום במשאבים של תחום מוגדר, ובמשאבים גלובליים או שמנוהלים במספר אזורים במקום במשאבים אזוריים. הגישה הזו עוזרת להימנע מהצורך לשחזר פעולות באמצעות גיבויים.
- בכל אזור, כדאי להשתמש בשלושה תחומים ולא בשניים. כדי לטפל במעבר לגיבוי, כדאי להקצות שליש יותר קיבולת מההערכה.
- כדי לצמצם את השלבים של שחזור ידני, כדאי להטמיע פריסות פעילות-פעילות, כמו בדוגמאות הבאות:
- מסדי נתונים מבוזרים כמו Spanner מספקים יתירות מובנית וסנכרון בין אזורים.
- תכונת הזמינות הגבוהה של Cloud SQL מספקת טופולוגיה שהיא כמעט פעילה-פעילה, עם רפליקות לקריאה באזורים שונים. הוא מספק יעד להתאוששות מאסון (RPO) בין אזורים שקרוב ל-0.
- כדי לחלק את תעבורת המשתמשים בין האזורים, משתמשים ב-Cloud DNS ומפריסים מאזן עומסים אזורי בכל אזור. מאזן עומסים גלובלי הוא אפשרות נוספת שאפשר לשקול בהתאם לדרישות ולחשיבות שלכם. מידע נוסף זמין במאמר היתרונות והסיכונים של איזון עומסים גלובלי לפריסות מרובות אזורים.
- כדי לאחסן נתונים, צריך להשתמש בשירותים מרובי-אזורים כמו Spanner ו-Cloud Storage.
ביטול נקודות כשל בודדות
כדאי לפזר את המשאבים במיקומים שונים ולהשתמש במשאבים מיותרים כדי למנוע מצב שבו נקודת כשל יחידה (SPOF) תשפיע על כל מחסנית האפליקציה.
כדי להימנע מנקודות כשל יחידות, כדאי לפעול לפי ההמלצות הבאות:
- מומלץ להימנע מפריסה של שרת אפליקציה או מסד נתונים יחיד.
- כדי להבטיח יצירה מחדש אוטומטית של מכונות וירטואליות שנכשלו, כדאי להשתמש בקבוצות של מופעי מכונה מנוהלים (MIG).
- כדי לפזר את התנועה באופן שווה בין המשאבים הזמינים, צריך להטמיע איזון עומסים.
- להשתמש בתצורות HA למסדי נתונים כמו Cloud SQL.
- כדי לשפר את זמינות הנתונים, אפשר להשתמש בדיסקים לאחסון מתמיד אזורי עם שכפול סינכרוני.
מידע נוסף זמין במאמר בנושא תכנון תשתית מהימנה לעומסי עבודה ב- Google Cloud.
הסבר על זמינות מצטברת וניהול שלה
חשוב לדעת שהזמינות הכוללת או המצטברת של מערכת מושפעת מהזמינות של כל רמה או רכיב במערכת. מספר השכבות במערך אפליקציות נמצא ביחס הפוך לזמינות המצטברת של המערך. כדאי לקחת בחשבון את ההמלצות הבאות לניהול הזמינות הכוללת:
כדי לחשב את הזמינות הכוללת של מחסנית מרובת רמות, משתמשים בנוסחה tier1_availability × tier2_availability × tierN_availability.
התרשים הבא מציג את החישוב של זמינות מצטברת למערכת רב-שכבתית שמורכבת מארבעה שירותים:
בתרשים שלמעלה, רמת הזמינות של השירות בכל שכבה היא 99.9%, אבל רמת הזמינות הכוללת של המערכת נמוכה יותר ועומדת על 99.6% (0.999 × 0.999 × 0.999 × 0.999). באופן כללי, הזמינות המצטברת של מחסנית מרובת-שכבות נמוכה מהזמינות של השכבה שמספקת את הזמינות הנמוכה ביותר.
במקרים שבהם זה אפשרי, עדיף לבחור באפשרות טעינה במקביל במקום באפשרות שרשור. בשירותים מקבילים, הזמינות מקצה לקצה גבוהה יותר מהזמינות של כל שירות בנפרד.
התרשים הבא מציג שני שירותים, A ו-B, שנפרסים באמצעות הגישות של שרשור והקבלה:
בדוגמאות שלמעלה, לשני השירותים יש הסכם רמת שירות של 99%, ולכן רמת הזמינות הכוללת תהיה כפי שמוצג בהמשך, בהתאם לגישת ההטמעה:
- שירותים בשרשרת מניבים זמינות מצטברת של 98% בלבד (0.99 × 0 .99).
- שירותים מקבילים מניבים זמינות מצטברת גבוהה יותר של 99.99% כי כל שירות פועל באופן עצמאי, והזמינות של שירותים מסוימים לא מושפעת מהזמינות של שירותים אחרים. הנוסחה לשירותים מצטברים שמקבילים זה לזה היא 1 − (1 − A) × (1 − B).
בחרו Google Cloud שירותים עם הסכמי רמת שירות (SLA) לזמן פעולה תקינה, שיעזרו לכם לעמוד ברמת הזמינות הכוללת הנדרשת עבור חבילת האפליקציות שלכם.
כשמתכננים את הארכיטקטורה, חשוב לשקול את האיזון בין זמינות, מורכבות תפעולית, זמן אחזור ועלות. הגדלת מספר התשעיות של הזמינות בדרך כלל עולה יותר, אבל היא עוזרת לעמוד בדרישות הרגולטוריות.
לדוגמה, זמינות של 99.9% (שלוש תשיעיות) פירושה זמן השבתה פוטנציאלי של 86 שניות ביום של 24 שעות. לעומת זאת, 99% (שני תשיעיות) פירושו זמן השבתה של 864 שניות באותו פרק זמן, שהוא פי 10 יותר זמן השבתה מאשר עם שלוש תשיעיות של זמינות.
יכול להיות שאפשרויות הארכיטקטורה יהיו מוגבלות בשירותים פיננסיים קריטיים. עם זאת, חשוב לזהות את דרישות הזמינות ולחשב את הזמינות בצורה מדויקת. הערכה כזו עוזרת לכם להבין את ההשלכות של החלטות העיצוב על הארכיטקטורה והתקציב שלכם.
יישום אסטרטגיית DR חזקה
ליצור תוכניות מוגדרות היטב לתרחישי אסון שונים, כולל הפסקות חשמל אזוריות ואזוריות. אסטרטגיה מוגדרת היטב לתוכנית התאוששות מאסון (DR) מאפשרת לכם להתאושש משיבוש ולחזור לפעילות רגילה עם השפעה מינימלית.
התאוששות מאסון (DR) וזמינות גבוהה (HA) הם שני מושגים שונים. בפריסות בענן, בדרך כלל, התאוששות מאסון (DR) חלה על פריסות במספר אזורים וזמינות גבוהה (HA) חלה על פריסות אזוריות. ארכיטיפים של פריסה תומכים במנגנוני שכפול שונים.
- HA: שירותים מנוהלים רבים מספקים שכפול סינכרוני בין אזורים בתוך אזור יחיד כברירת מחדל. שירותים כאלה תומכים ביעד להתאוששות מאסון (RPO) וביעד משך ההתאוששות (RTO) של אפס או קרוב לאפס. התמיכה הזו מאפשרת ליצור טופולוגיית פריסה פעילה-פעילה ללא נקודת כשל יחידה (SPOF).
- DR: בעומסי עבודה שנפרסים בשני אזורים או יותר, אם לא משתמשים בשירותים גלובליים או בשירותים במספר אזורים, צריך להגדיר אסטרטגיית שכפול. אסטרטגיית השכפול היא בדרך כלל אסינכרונית. חשוב להעריך בקפידה איך השכפול הזה משפיע על RTO ו-RPO של אפליקציות קריטיות. זיהוי הפעולות הידניות או האוטומטיות למחצה שנדרשות למעבר לשירות גיבוי במקרה של כשל.
במוסדות פיננסיים, יכול להיות שהבחירה של אזור מעבר לגיבוי בעת כשל תהיה מוגבלת בגלל תקנות בנושא ריבונות נתונים ומיקום נתונים. אם אתם צריכים טופולוגיה פעילה-פעילה בשני אזורים, מומלץ לבחור שירותים מנוהלים של מספר אזורים, כמו Spanner ו-Cloud Storage, במיוחד אם שכפול נתונים הוא קריטי.
כדאי לשקול את ההמלצות הבאות:
- להשתמש בשירותי אחסון מנוהלים במספר אזורים בשביל הנתונים.
- יוצרים תמונות מצב של נתונים בדיסקים לאחסון מתמיד ומאחסנים את תמונות המצב במיקומים במספר אזורים.
- כשמשתמשים במשאבים אזוריים או של תחום מוגדר, צריך להגדיר רפליקציה של הנתונים לאזורים אחרים.
- כדי לוודא שתוכניות ה-DR שלכם יעילות, חשוב לבדוק אותן באופן קבוע.
- חשוב להכיר את ה-RTO ואת ה-RPO ואת הקשר שלהם לסבילות להשפעה שנקבעה בתקנות הפיננסיות בסמכות השיפוט שלכם.
מידע נוסף מופיע במאמר תכנון התאוששות מאסון (DR) במקרה של הפסקות בשירותי התשתית בענן.
שימוש בשירותים מנוהלים
כשאפשר, כדאי להשתמש בשירותים מנוהלים כדי ליהנות מהתכונות המובנות לגיבויים, לזמינות גבוהה ולמדרגיות. כדאי לקחת בחשבון את ההמלצות הבאות לשימוש בשירותים מנוהלים:
- שימוש בשירותים מנוהלים ב- Google Cloud. הם מספקים זמינות גבוהה שמגובה בהסכמי רמת שירות (SLA). הם כוללים גם מנגנוני גיבוי מובנים ותכונות עמידות.
- לניהול נתונים, כדאי להשתמש בשירותים כמו Cloud SQL, Cloud Storage ו-Spanner.
- למחשוב ולאירוח אפליקציות, כדאי לשקול קבוצות של מופעי מכונה מנוהלים (MIG) ב-Compute Engine ואשכולות של Google Kubernetes Engine (GKE). קבוצות אזוריות של מכונות וירטואליות (MIG) ואשכולות אזוריים של GKE עמידים בפני הפסקות זמניות בשירות באזור מסוים.
- כדי לשפר את החוסן (resilience) מפני הפסקות זמניות בשירות באזור מסוים, כדאי להשתמש בשירותים מנוהלים במספר אזורים.
- לזהות את הצורך בתוכניות יציאה לשירותים עם מאפיינים ייחודיים ולהגדיר את התוכניות הנדרשות. רגולטורים פיננסיים כמו FCA, PRA ו-EBA דורשים מחברות להגדיר אסטרטגיות ותוכניות מגירה לשחזור נתונים ולהמשכיות תפעולית במקרה של סיום הקשר עם ספק שירותי ענן. חברות צריכות להעריך את היתכנות היציאה לפני שהן חותמות על חוזים עם ספקי ענן, והן צריכות לשמור על היכולת לשנות ספקים בלי שיבושים תפעוליים.
- מוודאים שהשירותים שבוחרים תומכים בייצוא נתונים לפורמט פתוח כמו CSV, Parquet ו-Avro. בודקים אם השירותים מבוססים על טכנולוגיות פתוחות, כמו תמיכה ב-GKE בפורמט Open Container Initiative (OCI) או Cloud Composer שמבוסס על Apache Airflow.
אוטומציה של תהליכי הקצאת התשתית והשחזור
אוטומציה עוזרת לצמצם טעויות אנוש ולקצר את הזמן שנדרש לטיפול באירועים, וגם לצמצם את המשאבים שנדרשים לכך. השימוש באוטומציה יכול לעזור להבטיח התאוששות מהירה יותר מכשלים ותוצאות עקביות יותר. כדאי ליישם את ההמלצות הבאות כדי לאוטומט את הקצאה והשחזור של משאבים:
- מצמצמים את הטעויות האנושיות באמצעות כלים של תשתית כקוד (IaC) כמו Terraform.
- צמצום ההתערבות הידנית על ידי אוטומציה של תהליכי מעבר לגיבוי. תגובות אוטומטיות יכולות גם לעזור לצמצם את ההשפעה של כשלים. לדוגמה, אפשר להשתמש ב-Eventarc או ב-Workflows כדי להפעיל אוטומטית פעולות לתיקון בעיות שנצפו באמצעות יומני ביקורת.
- כדי להגדיל את הקיבולת של משאבי הענן במהלך מעבר לגיבוי, אפשר להשתמש בהתאמת קנה מידה אוטומטית.
- הטמעה של הנדסת פלטפורמה מאפשרת להחיל באופן אוטומטי מדיניות ואמצעי הגנה על דרישות רגולטוריות בטופולוגיית הענן במהלך פריסת השירות.