במסמך הזה, שהוא חלק מ-Google Cloud Well-Architected Framework: Financial services (FS) perspective, מוצגת סקירה כללית של העקרונות וההמלצות לתכנון, לפריסה ולהפעלה של עומסי עבודה אמינים של שירותים פיננסיים ב- Google Cloud. במסמך מוסבר איך לשלב שיטות מתקדמות של אמינות וניראות בתוכניות האדריכליות. ההמלצות במסמך הזה תואמות לעקרון האמינות של Well-Architected Framework.
למוסדות פיננסיים, תשתית אמינה וגמישה היא גם צורך עסקי וגם חובה רגולטורית. כדי לוודא שעומסי העבודה של FS ב-Google Cloud אמינים, צריך להבין ולצמצם את נקודות הכשל הפוטנציאליות, לפרוס משאבים בצורה יתירה ולתכנן את ההתאוששות. חוסן תפעולי הוא תוצאה של אמינות. זו היכולת לספוג שיבושים, להסתגל אליהם ולהתאושש מהם. חוסן תפעולי עוזר לארגונים בתחום השירותים הפיננסיים לעמוד בדרישות רגולטוריות מחמירות. הוא גם עוזר למנוע נזק בלתי נסבל ללקוחות.
אבני הבניין העיקריות של אמינות ב- Google Cloud הן אזורים, תחומים והיקפי המיקום השונים של משאבי הענן: תחום, אזור, מספר אזורים וגלובלי. כדי לשפר את הזמינות, אתם יכולים להשתמש בשירותים מנוהלים, להפיץ משאבים, להטמיע דפוסים של זמינות גבוהה ולהפוך תהליכים לאוטומטיים.
דרישות רגולטוריות
ארגונים בתחום השירותים הפיננסיים פועלים תחת דרישות מחמירות של אמינות מצד רשויות רגולטוריות, כמו הבנק המרכזי בארה"ב, רשות הבנקאות האירופית באיחוד האירופי והרשות לפיקוח על הבנקים בבריטניה. רגולטורים ברחבי העולם מדגישים את החשיבות של חוסן תפעולי, שחיוני ליציבות פיננסית ולהגנה על הצרכן. חוסן תפעולי הוא היכולת לעמוד בשיבושים, להתאושש ביעילות ולשמור על שירותים קריטיים. לשם כך נדרשת גישה מתואמת לניהול סיכונים טכנולוגיים ותלות בצדדים שלישיים.
הדרישות הרגולטוריות ברוב תחומי השיפוט כוללות את הנושאים המשותפים הבאים:
- אבטחת סייבר וחוסן טכנולוגי: חיזוק ההגנה מפני איומי סייבר והבטחת החוסן של מערכות IT.
- ניהול סיכונים של צד שלישי: ניהול הסיכונים שקשורים למיקור חוץ של שירותים לספקי טכנולוגיית מידע ותקשורת (ICT).
- המשכיות עסקית ותגובה לאירועים: תכנון קפדני כדי לשמור על פעולות קריטיות במהלך שיבושים ולהתאושש ביעילות.
- הגנה על היציבות הפיננסית: הבטחת התקינות והיציבות של המערכת הפיננסית הרחבה יותר.
ההמלצות לאמינות במסמך הזה ממופות לעקרונות הליבה הבאים:
- מתן עדיפות לפריסות בכמה אזורים ובכמה אזורים גיאוגרפיים
- ביטול נקודות כשל בודדות (SPOF)
- הסבר על זמינות מצטברת וניהול שלה
- הטמעה של אסטרטגיית התאוששות מאסון (DR) חזקה
- שימוש בשירותים מנוהלים
- אוטומציה של תהליכי ההקצאה והשחזור של התשתית
תעדוף של פריסות במספר אזורים ובמספר תחומים
באפליקציות קריטיות של שירותים פיננסיים, מומלץ להשתמש בטופולוגיה של מספר אזורים, שמתפרסת על פני שני אזורים לפחות ועל פני שלושה אזורים בכל אזור. הגישה הזו חשובה כדי להגן מפני הפסקות חשמל באזורים ובאזורי משנה. התקנות לעיתים קרובות מחייבות את הגישה הזו, כי אם מתרחש כשל באזור אחד, רוב תחומי השיפוט מחשיבים שיבוש חמור באזור שני כתוצאה סבירה. הסיבה לכך היא שאם מיקום אחד נכשל, המיקום השני עשוי לקבל כמות גבוהה במיוחד של תנועה נוספת.
כדי להגן על המערכת מפני הפסקות זמניות בשירות באזורים ובמחוזות, כדאי לפעול לפי ההמלצות הבאות:
- עדיף להשתמש במשאבים עם היקף מיקום רחב יותר. במידת האפשר, השתמשו במשאבים אזוריים במקום במשאבים של תחום מוגדר, ובמשאבים במספר אזורים או במשאבים גלובליים במקום במשאבים אזוריים. כך לא צריך לשחזר את הפעולות באמצעות גיבויים.
- בכל אזור, כדאי להשתמש בשלושה תחומים במקום בשניים. כדי לטפל ביתירות כשל, כדאי להקצות קיבולת עודפת בשליש יותר מההערכה.
- כדי לצמצם את שלבי השחזור הידני, כדאי להטמיע פריסות מסוג active-active, כמו בדוגמאות הבאות:
- מסדי נתונים מבוזרים כמו Spanner מספקים יתירות וסנכרון מובנים בין אזורים.
- התכונה HA של Cloud SQL מספקת טופולוגיה שהיא כמעט פעילה-פעילה, עם רפליקות לקריאה בלבד באזורים שונים. הוא מספק יעד להתאוששות מאסון (RPO) בין אזורים שקרוב ל-0.
- אתם יכולים לחלק את תנועת המשתמשים בין אזורים באמצעות Cloud DNS, ולפרוס מאזן עומסים אזורי בכל אזור. מאזן עומסים גלובלי הוא אפשרות נוספת שאפשר לשקול, בהתאם לדרישות ולרמת הקריטיות. למידע נוסף, קראו את המאמר היתרונות והסיכונים של איזון עומסים גלובלי בפריסות בכמה אזורים.
- כדי לאחסן נתונים, השתמשו בשירותים שפועלים במספר אזורים, כמו Spanner ו-Cloud Storage.
הימנעות מנקודות כשל בודדות
כדי למנוע מצב שבו נקודת כשל בודדת (SPOF) משפיעה על כל מחסנית האפליקציה, כדאי לפזר את המשאבים במיקומים שונים ולהשתמש במשאבים מיותרים.
כדי להימנע מנקודות כשל בודדות, כדאי לפעול לפי ההמלצות הבאות:
- אל תפרסו רק שרת אפליקציות אחד או מסד נתונים אחד.
- כדי להבטיח יצירה מחדש באופן אוטומטי של מכונות וירטואליות שנכשלו, השתמשו בקבוצות מופעי מכונה מנוהלים (MIG).
- להטמיע איזון עומסים כדי לפזר את התנועה באופן שווה בין המשאבים הזמינים.
- להשתמש בהגדרות של זמינות גבוהה למסדי נתונים כמו Cloud SQL.
- כדי לשפר את זמינות הנתונים, כדאי להשתמש בPersistent Disk אזוריים עם שכפול סינכרוני.
מידע נוסף זמין במאמר תכנון תשתית אמינה לעומסי העבודה ב- Google Cloud.
הסבר על זמינות מצטברת וניהול שלה
חשוב לזכור שהזמינות הכוללת או המצטברת של מערכת מושפעת מהזמינות של כל שכבה או רכיב במערכת. מספר השכבות במקבץ האפליקציות נמצא ביחס הפוך לזמינות המצטברת של המקבץ. כדאי להביא בחשבון את ההמלצות הבאות לניהול הזמינות המצטברת:
כדי לחשב את הזמינות המצטברת של סטאק עם כמה שכבות, משתמשים בנוסחה tier1_availability × tier2_availability × tierN_availability.
התרשים הבא מציג את חישוב הזמינות המצטברת של מערכת מרובת שכבות שמורכבת מארבעה שירותים:
בתרשים שלמעלה, השירות בכל שכבה מספק זמינות של 99.9%, אבל הזמינות המצטברת של המערכת נמוכה יותר, 99.6% (0.999 × 0.999 × 0.999 × 0.999). באופן כללי, הזמינות המצטברת של סטאק עם כמה שכבות נמוכה יותר מהזמינות של השכבה שמספקת את הזמינות הנמוכה ביותר.
במידת האפשר, בחרו בטעינה במקביל על פני שרשור. בשירותים מקבילים, הזמינות מקצה לקצה גבוהה יותר מהזמינות של כל שירות בנפרד.
בתרשים הבא מוצגים שני שירותים, א' וב', שנפרסים באמצעות גישות השרשור וההקבלה:
בדוגמאות הקודמות, לשני השירותים יש הסכם רמת שירות של 99%, וכתוצאה מכך הזמינות המצטברת הבאה תלויה בגישת ההטמעה:
- שירותים משורשרים מניבים זמינות מצטברת של 98% בלבד (.99 × .99).
- שירותים מקבילים מניבים זמינות מצטברת גבוהה יותר של 99.99%, כי כל שירות פועל באופן עצמאי והשירותים הנפרדים לא מושפעים מהזמינות של השירותים האחרים. הנוסחה לשירותים מקבילים מצטברים היא 1 − (1 − A) × (1 − B).
בחרו שירותי Google Cloud עם הסכמי SLA לזמן פעולה תקינה שיכולים לעזור לכם לעמוד ברמה הנדרשת של זמן פעולה תקינה כולל של מחסנית האפליקציות.
כשאתם מתכננים את הארכיטקטורה, חשוב שתשקלו את היתרונות והחסרונות של זמינות, מורכבות תפעולית, זמן אחזור ועלות. ככל שרמת הזמינות גבוהה יותר, כך העלות גבוהה יותר, אבל זה עוזר לכם לעמוד בדרישות הרגולטוריות.
לדוגמה, זמינות של 99.9% (שלושה תשיעיות) פירושה זמן השבתה פוטנציאלי של 86 שניות ביום של 24 שעות. לעומת זאת, 99% (שני תשיעיות) פירושו זמן השבתה של 864 שניות באותה תקופה, שהוא פי 10 יותר זמן השבתה מאשר עם שלוש תשיעיות של זמינות.
בשירותים פיננסיים קריטיים, יכול להיות שאפשרויות הארכיטקטורה יהיו מוגבלות. עם זאת, חשוב מאוד לזהות את דרישות הזמינות ולחשב אותה בצורה מדויקת. הערכה כזו עוזרת לכם להבין את ההשלכות של החלטות העיצוב על הארכיטקטורה והתקציב.
הטמעה של אסטרטגיית התאוששות מאסון (DR) יעילה
צרו תוכניות מוגדרות היטב לתרחישי אסון שונים, כולל הפסקות חשמל אזוריות. אסטרטגיה מוגדרת היטב של תוכנית התאוששות מאסון (DR) מאפשרת לכם להתאושש משיבוש ולחזור לפעילות רגילה עם השפעה מינימלית.
התאוששות מאסון וזמינות גבוהה (HA) הם מושגים שונים. בפריסות בענן, באופן כללי, התאוששות מאסון רלוונטית לפריסות במספר אזורים, וזמינות גבוהה רלוונטית לפריסות אזוריות. הארכיטיפים האלה לפריסה תומכים במנגנוני רפליקציה שונים.
- HA: כברירת מחדל, שירותים מנוהלים רבים מספקים רפליקציה סינכרונית בין אזורים בתוך אותו Region. השירותים האלה תומכים ביעד זמן התאוששות (RTO) וביעד נקודת התאוששות (RPO) של אפס או קרוב לאפס. התמיכה הזו מאפשרת ליצור טופולוגיית פריסה פעילה-פעילה ללא נקודת כשל יחידה.
- DR: בעומסי עבודה שנפרסים בשני אזורים או יותר, אם אתם לא משתמשים בשירותים גלובליים או בשירותים במספר אזורים, אתם צריכים להגדיר אסטרטגיית רפליקציה. אסטרטגיית הרפליקציה היא בדרך כלל אסינכרונית. חשוב לבדוק היטב איך הרפליקציה הזו משפיעה על ה-RTO וה-RPO של אפליקציות קריטיות. זהו את הפעולות הידניות או החצי-אוטומטיות שנדרשות ליתירות כשל.
במוסדות פיננסיים, יכול להיות שהבחירה באזור ליתירות כשל תהיה מוגבלת בגלל תקנות בנושא ריבונות הנתונים ומיקום אחסון הנתונים. אם אתם צריכים טופולוגיית active-active בשני אזורים, מומלץ לבחור שירותים מנוהלים במספר אזורים, כמו Spanner ו-Cloud Storage, במיוחד כששכפול הנתונים הוא קריטי.
כדאי לשקול את ההמלצות הבאות:
- להשתמש בשירותי אחסון מנוהלים במספר אזורים לנתונים.
- יצירת קובצי snapshot של נתונים בדיסקים לאחסון מתמיד (persistent disks) ושמירת קובצי ה-snapshot במיקומים במספר אזורים.
- כשאתם משתמשים במשאבים אזוריים או במשאבים של תחום מוגדר, הגדירו רפליקציה של הנתונים באזורים אחרים.
- כדי לוודא שתוכניות ה-DR שלכם יעילות, בדקו אותן באופן קבוע.
- חשוב להכיר את ה-RTO וה-RPO ואת הקשר שלהם לסבילות להשפעה שנקבעה בתקנות הפיננסיות בסמכות השיפוט שלכם.
מידע נוסף מופיע במאמר תכנון תוכנית התאוששות מאסון (DR) להפסקות זמניות בשירות של תשתית הענן.
שימוש בשירותים מנוהלים
כשאפשר, כדאי להשתמש בשירותים מנוהלים כדי לנצל את התכונות המובנות לגיבויים, לזמינות גבוהה וליכולת התאמה לעומס. כדאי להביא בחשבון את ההמלצות הבאות לשימוש בשירותים מנוהלים:
- שימוש בשירותים מנוהלים ב- Google Cloud. הם מספקים זמינות גבוהה שמגובה בהסכמי SLA. הם גם מציעים מנגנוני גיבוי מובנים ותכונות עמידות.
- לניהול נתונים, כדאי להשתמש בשירותים כמו Cloud SQL, Cloud Storage ו-Spanner.
- לאירוח של אפליקציות ומחשוב, כדאי להשתמש בקבוצות של מופעי מכונה מנוהלים (MIG) ב-Compute Engine ובאשכולות של Google Kubernetes Engine (GKE). קבוצות MIG אזוריות ואשכולות אזוריים של GKE עמידים בפני הפסקות זמניות בשירות באזורים מסוימים.
- כדי לשפר את העמידות בפני הפסקות חשמל באזור, השתמשו בשירותים מנוהלים במספר אזורים.
- לזהות את הצורך בתוכניות יציאה לשירותים עם מאפיינים ייחודיים ולהגדיר את התוכניות הנדרשות. רגולטורים פיננסיים כמו FCA, PRA ו-EBA דורשים מהחברות להכין אסטרטגיות ותוכניות מגירה לאחזור נתונים ולהמשכיות תפעולית במקרה שהקשר עם ספק שירותי הענן יסתיים. חברות חייבות להעריך את היתכנות היציאה לפני שהן חותמות על חוזים בענן, והן חייבות לשמור על היכולת להחליף ספקים בלי לשבש את הפעילות.
- חשוב לוודא שהשירותים שבחרתם תומכים בייצוא נתונים לפורמט פתוח כמו CSV, Parquet ו-Avro. בדקו אם השירותים מבוססים על טכנולוגיות פתוחות, כמו תמיכה של GKE בפורמט Open Container Initiative (OCI) או ב-Managed Service for Apache Airflow.
אוטומציה של תהליכי ההקצאה והשחזור של התשתית
אוטומציה עוזרת לצמצם טעויות אנוש, וגם את הזמן והמשאבים שנדרשים כדי להגיב לאירועים. שימוש באוטומציה יכול לעזור להבטיח התאוששות מהירה יותר מתקלות ותוצאות עקביות יותר. כדי להפוך את ההקצאה והשחזור של המשאבים לאוטומטיים, כדאי לפעול לפי ההמלצות הבאות:
- כדי לצמצם טעויות אנוש, כדאי להשתמש בכלים של תשתית כקוד (IaC) כמו Terraform.
- להפחית את הצורך בהתערבות ידנית באמצעות אוטומציה של תהליכי יתירות כשל. תגובות אוטומטיות יכולות גם לעזור לצמצם את ההשפעה של כשלים. לדוגמה, אתם יכולים להשתמש ב-Eventarc או ב-Workflows כדי להפעיל באופן אוטומטי פעולות תיקון בתגובה לבעיות שזוהו באמצעות יומני הביקורת.
- הגדלת הקיבולת של משאבי הענן במהלך יתירות כשל באמצעות התאמה אוטומטית לעומס (automatic scaling).
- הנדסת פלטפורמה מאפשרת להחיל באופן אוטומטי כללי מדיניות ומגבלות לדרישות רגולטוריות בטופולוגיית הענן במהלך פריסת השירות.