במסמך הזה, שמופיע בGoogle Cloud Well-Architected Framework: Financial services (FS) perspective, מפורטת סקירה כללית של העקרונות וההמלצות לתכנון, לפריסה ולהפעלה של עומסי עבודה מהימנים של שירותים פיננסיים ב- Google Cloud. במסמך הזה מוסבר איך לשלב שיטות מתקדמות של אמינות וניטור בתרשימי הארכיטקטורה שלכם. ההמלצות במסמך הזה תואמות לעקרון המהימנות של Well-Architected Framework.
עבור מוסדות פיננסיים, תשתית מהימנה ועמידה היא גם צורך עסקי וגם דרישה רגולטורית. כדי לוודא שעומסי העבודה של FS ב-Google Cloud אמינים, צריך להבין את נקודות הכשל הפוטנציאליות ולצמצם אותן, לפרוס משאבים באופן מיותר ולתכנן את השחזור. חוסן תפעולי הוא תוצאה של אמינות. היא היכולת לספוג שיבושים, להסתגל אליהם ולהתאושש מהם. חוסן תפעולי עוזר לארגונים בתחום השירותים הפיננסיים לעמוד בדרישות רגולטוריות מחמירות. זה גם עוזר למנוע נזק בלתי נסבל ללקוחות.
אבני הבניין העיקריות של מהימנות ב- Google Cloud הן אזורים, תחומים מוגדרים והיקפי המיקום השונים של משאבי הענן: תחום מוגדר, אזורי, רב-אזורי וגלובלי. אפשר לשפר את הזמינות באמצעות שימוש בשירותים מנוהלים, הפצת משאבים, הטמעה של דפוסי זמינות גבוהה ואוטומציה של תהליכים.
דרישות רגולטוריות
ארגונים פיננסיים פועלים תחת דרישות מחמירות של מהימנות מצד סוכנויות רגולטוריות כמו 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.
- כדי לשפר את זמינות הנתונים, כדאי להשתמש באחסון מתמיד (persistent disk) אזורי עם שכפול סינכרוני.
מידע נוסף זמין במאמר בנושא תכנון תשתית מהימנה לעומסי עבודה ב- 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 יותר מזמן ההשבתה עם זמינות של 99.9%.
יכול להיות שאפשרויות הארכיטקטורה יהיו מוגבלות בשירותים פיננסיים קריטיים. עם זאת, חשוב מאוד לזהות את דרישות הזמינות ולחשב את הזמינות בצורה מדויקת. הערכה כזו עוזרת לכם להבין את ההשלכות של החלטות העיצוב על הארכיטקטורה והתקציב שלכם.
הטמעה של אסטרטגיית DR חזקה
ליצור תוכניות מוגדרות היטב לתרחישי אסון שונים, כולל הפסקות חשמל אזוריות ואזוריות. אסטרטגיה מוגדרת היטב לתוכנית התאוששות מאסון (DR) מאפשרת לכם להתאושש משיבוש ולחזור לפעילות רגילה עם השפעה מינימלית.
התאוששות מאסון (DR) וזמינות גבוהה (HA) הם מושגים שונים. בפריסות בענן, באופן כללי, התאוששות מאסון מתייחסת לפריסות מרובות אזורים, וזמינות גבוהה מתייחסת לפריסות אזוריות. ארכיטיפים של פריסות תומכים במנגנוני שכפול שונים.
- HA: שירותים מנוהלים רבים מספקים שכפול סינכרוני בין אזורים בתוך אזור יחיד כברירת מחדל. שירותים כאלה תומכים ביעד להתאוששות מאסון (RPO) וביעד משך ההתאוששות (RTO) של אפס או קרוב לאפס. התמיכה הזו מאפשרת ליצור טופולוגיית פריסה פעילה-פעילה ללא נקודת כשל יחידה (SPOF).
- DR: בעומסי עבודה שנפרסים בשני אזורים או יותר, אם לא משתמשים בשירותים גלובליים או בשירותים שפועלים בכמה אזורים, צריך להגדיר אסטרטגיית שכפול. אסטרטגיית השכפול היא בדרך כלל אסינכרונית. חשוב להעריך בקפידה איך השכפול הזה משפיע על RTO ו-RPO של אפליקציות קריטיות. צריך לזהות את הפעולות הידניות או החצי-אוטומטיות שנדרשות למעבר לגיבוי.
מוסדות פיננסיים עשויים להיות מוגבלים בבחירת אזור יתירות כשל בשל תקנות בנושא ריבונות הנתונים ומיקום נתונים. אם אתם צריכים טופולוגיה פעילה-פעילה בשני אזורים, מומלץ לבחור שירותים מנוהלים במספר אזורים, כמו Spanner ו-Cloud Storage, במיוחד אם רפליקציה של נתונים היא קריטית.
כדאי לשקול את ההמלצות הבאות:
- להשתמש בשירותי אחסון מנוהלים במספר אזורים בשביל הנתונים.
- יוצרים תמונות מצב של נתונים בדיסקים לאחסון מתמיד (persistent disks) ומאחסנים את תמונות המצב במיקומים רב-אזוריים.
- כשמשתמשים במשאבים אזוריים או של תחום מוגדר, צריך להגדיר רפליקציה של נתונים לאזורים אחרים.
- כדי לוודא שתוכניות ה-DR שלכם אפקטיביות, מומלץ לבדוק אותן באופן קבוע.
- חשוב להכיר את ה-RTO ואת ה-RPO ואת הקשר שלהם לסבילות להשפעה שנקבעה בתקנות פיננסיות בסמכות השיפוט שלכם.
מידע נוסף מופיע במאמר תכנון התאוששות מאסון (DR) להפסקות בשירותי תשתית ענן.
שימוש בשירותים מנוהלים
כשאפשר, כדאי להשתמש בשירותים מנוהלים כדי ליהנות מהתכונות המובנות לגיבויים, לזמינות גבוהה ולמדרגיות. כדאי לקחת בחשבון את ההמלצות הבאות לשימוש בשירותים מנוהלים:
- שימוש בשירותים מנוהלים ב- Google Cloud. הם מספקים זמינות גבוהה (HA) שמגובה בהסכמי רמת שירות (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) או בManaged Service for Apache Airflow שמבוסס על Apache Airflow.
אוטומציה של תהליכי הקצאת התשתית והשחזור
אוטומציה עוזרת לצמצם טעויות אנוש ולקצר את הזמן שנדרש לטיפול באירועים, וגם לצמצם את המשאבים שנדרשים לכך. השימוש באוטומציה יכול לעזור להבטיח התאוששות מהירה יותר מכשלים ותוצאות עקביות יותר. כדאי ליישם את ההמלצות הבאות כדי לאוטומט את הקצאה והשחזור של משאבים:
- מצמצמים את הטעויות האנושיות באמצעות כלים של תשתית כקוד (IaC) כמו Terraform.
- צמצום ההתערבות הידנית על ידי אוטומציה של תהליכי מעבר לגיבוי בעת כשל. תשובות אוטומטיות יכולות גם לעזור לצמצם את ההשפעה של כשלים. לדוגמה, אפשר להשתמש ב-Eventarc או ב-Workflows כדי להפעיל באופן אוטומטי פעולות לתיקון בעיות שנצפו באמצעות יומני ביקורת.
- כדי להגדיל את הקיבולת של משאבי הענן במהלך מעבר לגיבוי בעת כשל, אפשר להשתמש בהתאמת קנה מידה אוטומטית.
- הטמעה של הנדסת פלטפורמה מאפשרת להחיל באופן אוטומטי מדיניות ואמצעי הגנה על דרישות רגולטוריות בטופולוגיית הענן במהלך פריסת השירות.