במסמך הזה, שהוא חלק מ-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: כברירת מחדל, שירותים מנוהלים רבים מספקים רפליקציה סינכרונית בין אזורים בתוך אותו אזור. שירותים כאלה תומכים ביעד זמן התאוששות (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 כדי להפעיל באופן אוטומטי פעולות תיקון בתגובה לבעיות שזוהו באמצעות יומני הביקורת.
- הגדלת הקיבולת של משאבי הענן במהלך יתירות כשל באמצעות התאמה אוטומטית לעומס.
- הנדסת פלטפורמה מאפשרת להחיל באופן אוטומטי כללי מדיניות ומגבלות לדרישות רגולטוריות בטופולוגיית הענן במהלך פריסת השירות.