במסמך הזה, שמופיע ב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, שנפרסים באמצעות הגישות של שרשור והקבלה:
בדוגמאות הקודמות, לשני השירותים יש הסכם SLA של 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 וזמינות גבוהה (HA) הם מושגים שונים. בפריסות בענן, התאוששות מאסון (DR) חלה בדרך כלל על פריסות במספר אזורים, וזמינות גבוהה (HA) חלה על פריסות אזוריות. ארכיטיפים של פריסה תומכים במנגנוני שכפול שונים.
- HA: שירותים מנוהלים רבים מספקים שכפול סינכרוני בין אזורים בתוך אזור יחיד כברירת מחדל. שירותים כאלה תומכים ביעד להתאוששות מאסון (RPO) וביעד משך ההתאוששות (RTO) של אפס או קרוב לאפס. התמיכה הזו מאפשרת ליצור טופולוגיית פריסה פעילה-פעילה ללא נקודת כשל יחידה (SPOF).
- DR: לעומסי עבודה שנפרסים בשני אזורים או יותר, אם לא משתמשים בשירותים גלובליים או בשירותים במספר אזורים, צריך להגדיר אסטרטגיית שכפול. אסטרטגיית השכפול היא בדרך כלל אסינכרונית. חשוב להעריך בקפידה איך השכפול הזה משפיע על זמן ההתאוששות (RTO) ועל נקודת ההתאוששות (RPO) של אפליקציות קריטיות. זיהוי הפעולות הידניות או החצי-אוטומטיות שנדרשות למעבר לגיבוי בעת כשל.
במוסדות פיננסיים, הבחירה של אזור מעבר לגיבוי בעת כשל עשויה להיות מוגבלת על ידי תקנות בנושא ריבונות נתונים ומיקום נתונים. אם אתם צריכים טופולוגיה פעילה-פעילה בשני אזורים, מומלץ לבחור שירותים מנוהלים של מספר אזורים, כמו Spanner ו-Cloud Storage, במיוחד אם שכפול נתונים הוא קריטי.
כדאי לשקול את ההמלצות הבאות:
- להשתמש בשירותי אחסון מנוהלים במספר אזורים בשביל הנתונים.
- יוצרים תמונות מצב של נתונים בדיסקים לאחסון מתמיד (persistent disks) ומאחסנים את תמונות המצב במיקומים רב-אזוריים.
- כשמשתמשים במשאבים אזוריים או של תחום מוגדר, צריך להגדיר רפליקציה של נתונים לאזורים אחרים.
- כדי לוודא שתוכניות ה-DR שלכם יעילות, חשוב לבדוק את התוכנית באופן קבוע.
- חשוב להכיר את ה-RTO ואת ה-RPO ואת הקשר שלהם לסבילות להשפעה שנקבעה בתקנות הפיננסיות בתחום השיפוט שלכם.
מידע נוסף מופיע במאמר תכנון התאוששות מאסון (DR) להפסקות בשירותי תשתית ענן.
שימוש בשירותים מנוהלים
כשאפשר, כדאי להשתמש בשירותים מנוהלים כדי ליהנות מהתכונות המובנות לגיבויים, לזמינות גבוהה ולמדרגיות. כדאי לקחת בחשבון את ההמלצות הבאות לשימוש בשירותים מנוהלים:
- שימוש בשירותים מנוהלים ב- Google Cloud. הם מספקים זמינות גבוהה שמגובה בהסכמי רמת שירות (SLA). הם כוללים גם מנגנוני גיבוי מובנים ותכונות עמידות.
- לניהול נתונים, כדאי להשתמש בשירותים כמו Cloud SQL, Cloud Storage ו-Spanner.
- למחשוב ולאירוח אפליקציות, כדאי לשקול קבוצות של מופעי מכונה מנוהלים (MIG) ב-Compute Engine ואשכולות Google Kubernetes Engine (GKE). קבוצות אזוריות של מכונות וירטואליות ואשכולות אזוריים של GKE עמידים בפני הפסקות זמניות בשירות באזור מסוים.
- כדי לשפר את החוסן (resilience) מפני הפסקות חשמל באזור, כדאי להשתמש בשירותים מנוהלים במספר אזורים.
- לזהות את הצורך בתוכניות יציאה לשירותים עם מאפיינים ייחודיים ולהגדיר את התוכניות הנדרשות. רגולטורים פיננסיים כמו FCA, PRA ו-EBA דורשים מחברות להגדיר אסטרטגיות ותוכניות מגירה לשחזור נתונים ולהמשכיות תפעולית במקרה של סיום הקשר עם ספק שירותי ענן. חברות צריכות להעריך את היתכנות היציאה לפני שהן חותמות על חוזים עם ספקי ענן, והן צריכות לשמור על היכולת לשנות ספקים בלי שיבושים תפעוליים.
- מוודאים שהשירותים שבוחרים תומכים בייצוא נתונים לפורמט פתוח כמו CSV, Parquet ו-Avro. בודקים אם השירותים מבוססים על טכנולוגיות פתוחות, כמו תמיכה ב-GKE בפורמט Open Container Initiative (OCI) או Managed Service for Apache Airflow שמבוסס על Apache Airflow.
אוטומציה של תהליכי הקצאת התשתית והשחזור
האוטומציה עוזרת לצמצם את טעויות האנוש ולקצר את הזמן שנדרש לטיפול באירועים, וגם לצמצם את המשאבים שנדרשים לכך. השימוש באוטומציה יכול לעזור להבטיח התאוששות מהירה יותר מכשלים ותוצאות עקביות יותר. כדאי ליישם את ההמלצות הבאות כדי לאוטומט את הקצאה והשחזור של משאבים:
- מצמצמים את הטעויות האנושיות באמצעות כלים של תשתית כקוד (IaC) כמו Terraform.
- צמצום ההתערבות הידנית באמצעות אוטומציה של תהליכי מעבר לגיבוי. תשובות אוטומטיות יכולות גם לעזור לצמצם את ההשפעה של כשלים. לדוגמה, אפשר להשתמש ב-Eventarc או ב-Workflows כדי להפעיל אוטומטית פעולות לתיקון בעיות שנצפו באמצעות יומני ביקורת.
- כדי להגדיל את הקיבולת של משאבי הענן במהלך מעבר לגיבוי, אפשר להשתמש בהתאמת קנה מידה אוטומטית.
- הטמעה של הנדסת פלטפורמה מאפשרת להחיל באופן אוטומטי מדיניות ואמצעי הגנה על דרישות רגולטוריות בטופולוגיית הענן במהלך פריסת השירות.