במאמר הזה נציג כמה תבניות ושיטות ליצירת אפליקציות חסינות שאפשר להרחיב ולהקטין לפי הצורך: שני יעדים חשובים בהרבה תרגילים מודרניים של בניית ארכיטקטורה. אם האפליקציה תוכננה נכון, אפשר להרחיב ולהקטין אותה בהתאם לעומס, והיא תהיה חסינה מספיק כדי לשרוד שיבושים בשירות. כדי לבנות ולהפעיל אפליקציות שעומדות בדרישות האלה, צריך לתכנן ולעצב אותן בקפידה.
מדרגיות: התאמת הקיבולת כדי לעמוד בביקוש
מדרגיות היא מדד ליכולת של מערכת לטפל בכמויות משתנות של עבודה על ידי הוספה או הסרה של משאבים מהמערכת. לדוגמה, אפליקציית אינטרנט ניתנת להרחבה אם היא פועלת בצורה טובה עם משתמש אחד או עם משתמשים רבים, ומטפלת בצורה חלקה בשיאים ובשפל בתנועה.
הגמישות להתאים את המשאבים שנצרכים על ידי אפליקציה היא גורם מרכזי שמניע עסקים לעבור לענן. בעזרת תכנון נכון, אפשר להפחית את העלויות על ידי הסרת משאבים שלא מנוצלים מספיק, בלי לפגוע בביצועים או בחוויית המשתמש. באופן דומה, אפשר להוסיף עוד משאבים כדי לשמור על חוויית משתמש טובה בתקופות של תנועה גבוהה. כך האפליקציה יכולה לצרוך רק את המשאבים שדרושים כדי לעמוד בביקוש.
Google Cloud מספקת מוצרים ותכונות שיעזרו לכם ליצור אפליקציות יעילות וניתנות להרחבה:
- מכונות וירטואליות של Compute Engine ואשכולות של Google Kubernetes Engine (GKE) משולבים עם כלי התאמה אוטומטית לעומס, שמאפשרים להגדיל או להקטין את צריכת המשאבים על סמך מדדים שאתם מגדירים.
- Google Cloud's serverless platform provides managed compute, database, and other services that scale quickly from zero to high request volumes, and you pay only for what you use.
- מוצרי מסדי נתונים כמו BigQuery, Spanner ו-Bigtable יכולים לספק ביצועים עקביים גם כשמדובר בנתונים בכמויות גדולות.
- Cloud Monitoring מספק מדדים לגבי האפליקציות והתשתית שלכם, ועוזר לכם לקבל החלטות מבוססות-נתונים לגבי שינוי גודל.
עמידות: תכנון שיאפשר עמידה בפני כשלים
אפליקציה עמידה היא אפליקציה שממשיכה לפעול למרות כשלים ברכיבי המערכת. כדי להשיג חוסן צריך לתכנן את כל הרמות של הארכיטקטורה. הוא משפיע על האופן שבו אתם מתכננים את התשתית והרשת, ועל האופן שבו אתם מעצבים את האפליקציה ואת אחסון הנתונים. החוסן מתייחס גם לאנשים ולתרבות.
קשה ליצור ולהפעיל אפליקציות עמידות. זה נכון במיוחד לגבי אפליקציות מבוזרות, שעשויות להכיל כמה שכבות של תשתית, רשתות ושירותים. טעויות והפסקות שירות קורות, ושיפור החוסן של האפליקציה הוא תהליך מתמשך. בעזרת תכנון קפדני, תוכלו לשפר את היכולת של האפליקציה שלכם לעמוד בכשלים. בעזרת תהליכים מתאימים ותרבות ארגונית, אפשר גם ללמוד מכישלונות כדי לשפר עוד יותר את החוסן של האפליקציה.
Google Cloud מספק כלים ושירותים שיעזרו לכם ליצור אפליקציות עם זמינות גבוהה ועמידות:
- שירותיGoogle Cloud זמינים באזורים ותחומים ברחבי העולם, כך שתוכלו לפרוס את האפליקציה שלכם בצורה שתעזור לכם להשיג את יעדי הזמינות שלכם.
- אפשר לפרוס ולנהל קבוצות של מכונות ב-Compute Engine ואשכולות GKE בתחומים (zones) הזמינים באזור נתון.
- דיסקים לאחסון מתמיד של אזור ב-Compute Engine משוכפלים באופן סינכרוני בין תחומים באזור.
- Google Cloud מספק מגוון של אפשרויות לאיזון עומסים לניהול תעבורת הנתונים של האפליקציה, כולל איזון עומסים גלובלי שיכול להפנות תעבורת נתונים לאזור תקין שקרוב ביותר למשתמשים.
- Google Cloud's serverless platform includes managed compute and database products that offer built-in redundancy and load balancing.
- Cloud Build מריץ את גרסאות ה-build ב- Google Cloud ומאפשר לכם לפרוס בפלטפורמות כמו App Engine, Compute Engine, Cloud Run ו-GKE.
- Cloud Monitoring מספק מדדים לגבי האפליקציות והתשתית שלכם, ועוזר לכם לקבל החלטות מבוססות-נתונים לגבי הביצועים והתקינות של האפליקציות.
גורמים ומגבלות
יש דרישות ושיקולים שונים לשיפור יכולת ההתאמה לגודל (scalability) והחוסן (resilience) של האפליקציה. יכול להיות גם שיש מגבלות שמקשות על השגת היעדים שלכם בנוגע ליכולת ההתאמה לגודל ולחוסן. החשיבות היחסית של הדרישות והמגבלות האלה משתנה בהתאם לסוג האפליקציה, לפרופיל המשתמשים ולגודל ולרמת הבשלות של הארגון.
דרייברים
כדי לעזור לכם לתעדף את הדרישות, כדאי לקחת בחשבון את הגורמים המניעים של חלקי הארגון השונים.
מניעים עסקיים
הגורמים הנפוצים בצד העסקי כוללים את הדברים הבאים:
- אופטימיזציה של העלויות ושל צריכת המשאבים.
- למזער את זמן ההשבתה של האפליקציה.
- לוודא שאפשר לעמוד בביקוש מצד המשתמשים בתקופות של שימוש גבוה.
- לשפר את האיכות והזמינות של השירות.
- חשוב לוודא שחוויית המשתמש והאמון של המשתמשים נשמרים במהלך הפסקות שירות.
- שיפור הגמישות והזריזות כדי להתמודד עם שינויים בביקוש בשוק.
גורמי פיתוח
הגורמים הנפוצים לכך מצד הפיתוח הם:
- צמצום הזמן שמושקע בחקירת כשלים.
- להגדיל את הזמן שמוקדש לפיתוח תכונות חדשות.
- צמצום העבודה המייגעת שחוזרת על עצמה באמצעות אוטומציה.
- פיתוח אפליקציות באמצעות הדפוסים והשיטות העדכניים ביותר בתעשייה.
גורמים שמשפיעים על התפעול
הדרישות שצריך לקחת בחשבון מבחינת התפעול כוללות את הדברים הבאים:
- הפחתת התדירות של כשלים שדורשים התערבות אנושית.
- שיפור היכולת להתאושש באופן אוטומטי מכשלים.
- צמצום העבודה המייגעת שחוזרת על עצמה באמצעות אוטומציה.
- למזער את ההשפעה של כשל ברכיב מסוים.
מגבלות
אילוצים עלולים להגביל את היכולת שלכם להגדיל את יכולת ההתאמה ואת העמידות של האפליקציה. חשוב לוודא שהחלטות העיצוב שלכם לא יוצרות את האילוצים הבאים או תורמות להם:
- תלויות בחומרה או בתוכנה שקשה להרחיב.
- תלויות בחומרה או בתוכנה שקשה להפעיל בהגדרת זמינות גבוהה.
- תלויות בין אפליקציות.
- הגבלות רישוי.
- אין מספיק כישורים או ניסיון בצוותי הפיתוח והתפעול שלכם.
- התנגדות ארגונית לאוטומציה.
דפוסים ושיטות
בהמשך המסמך מוגדרים דפוסים ושיטות שיעזרו לכם לפתח אפליקציות עמידות שניתנות להרחבה. הדפוסים האלה משפיעים על כל חלקי מחזור החיים של האפליקציה, כולל עיצוב התשתית, ארכיטקטורת האפליקציה, אפשרויות האחסון, תהליכי הפריסה והתרבות הארגונית.
אפשר לראות שלושה נושאים בדפוסים:
- פעולות אוטומטיות. כדי לבנות אפליקציות עמידות שניתנות להרחבה, צריך להשתמש באוטומציה. אוטומציה של הקצאת התשתית, הבדיקות ופריסת האפליקציות מגבירה את העקביות והמהירות, ומצמצמת את טעויות האנוש.
- צימוד רופף. התייחסות למערכת כאל אוסף של רכיבים עצמאיים עם צימוד רופף מאפשרת גמישות ועמידות. עצמאות כוללת את האופן שבו אתם מפזרים פיזית את המשאבים, את הארכיטקטורה של האפליקציה ואת עיצוב האחסון.
- עיצוב שמבוסס על נתונים. איסוף מדדים כדי להבין את ההתנהגות של האפליקציה הוא קריטי. החלטות לגבי מתי להרחיב את האפליקציה או אם שירות מסוים לא תקין צריכות להתבסס על נתונים. מדדים ויומנים צריכים להיות תכונות מרכזיות.
אוטומציה של הקצאת הרשאות לתשתית
כדאי ליצור תשתית בלתי משתנה באמצעות אוטומציה כדי לשפר את העקביות של הסביבות ולהגדיל את הסיכוי להצלחת הפריסות.
התייחסות לתשתית כמו לקוד
תשתית כקוד (IaC) היא טכניקה שמעודדת אתכם להתייחס להקצאת התשתית ולהגדרות שלה באותו אופן שבו אתם מתייחסים לקוד האפליקציה. לוגיקת ההקצאה וההגדרה מאוחסנת בבקרת מקורות, כך שאפשר לגלות אותה, לנהל לה גרסאות ולבצע בה ביקורת. מכיוון שהיא נמצאת במאגר המקורות של הקוד, אתם יכולים לנצל את פייפליינים של אינטגרציה רציפה (CI) ופריסה רציפה (CD) (CI/CD), כך שכל שינוי בהגדרה ייבדק וייפרס באופן אוטומטי.
הסרת שלבים ידניים מהקצאת התשתית מאפשרת ל-IaC לצמצם את הטעויות האנושיות ולשפר את העקביות והשחזור של האפליקציות והסביבות. כך, אימוץ של IaC מגדיל את החוסן של האפליקציות שלכם.
Infrastructure Manager מאפשר לכם לבצע אוטומציה של היצירה והניהול של משאבים Google Cloud . אפשרות אחרת היא להשתמש ב-Config Connector כדי לנהל את המשאבים באמצעות טכניקות ותהליכי עבודה של Kubernetes. ל-Google Cloud יש גם תמיכה מובנית בכלי IaC פופולריים של צד שלישי, כולל Terraform, Chef ו-Puppet.
יצירת תשתית שלא ניתן לשנות
תשתית בלתי ניתנת לשינוי היא פילוסופיה שמבוססת על היתרונות של תשתית כקוד. תשתית שלא ניתנת לשינוי מחייבת שהמשאבים לא ישתנו אחרי הפריסה שלהם. אם צריך לעדכן מכונה וירטואלית, אשכול Kubernetes או כלל חומת אש, אפשר לעדכן את ההגדרה של המשאב במאגר המקור. אחרי שבודקים ומאמתים את השינויים, פורסים מחדש את המשאב באופן מלא באמצעות ההגדרה החדשה. במילים אחרות, במקום לשנות משאבים, יוצרים אותם מחדש.
יצירת תשתית בלתי ניתנת לשינוי מובילה לפריסות ולחזרה לגרסה קודמת צפויות יותר. היא גם מצמצמת בעיות שכיחות בתשתיות שניתנות לשינוי, כמו סחף הגדרות ושרתי snowflake. כך, אימוץ תשתית בלתי ניתנת לשינוי משפר עוד יותר את העקביות והאמינות של הסביבות.
תכנון להשגת זמינות גבוהה
זמינות היא מדד של חלקיק הזמן שבו אפשר להשתמש בשירות. זמינות משמשת לעיתים קרובות כאינדיקטור מרכזי למצב הכללי של השירות. ארכיטקטורות עם זמינות גבוהה נועדו למקסם את זמינות השירות, בדרך כלל באמצעות פריסה של רכיבים באופן מיותר. במילים פשוטות, כדי להשיג זמינות גבוהה צריך בדרך כלל להפיץ משאבי מחשוב, לבצע איזון עומסים ולשכפל נתונים.
חלוקת משאבים פיזית
שירותיGoogle Cloud זמינים במיקומים שונים ברחבי העולם. המיקומים האלה מחולקים לאזורים ולתחומים. האופן שבו פורסים את האפליקציה באזורים ובתחומים האלה משפיע על הזמינות, זמן האחזור ומאפיינים אחרים של האפליקציה. מידע נוסף זמין במאמר בנושא שיטות מומלצות לבחירת אזורים ב-Compute Engine.
יתירות היא שכפול של רכיבים במערכת כדי להגדיל את הזמינות הכוללת של המערכת. ב- Google Cloud, בדרך כלל אפשר להשיג יתירות על ידי פריסת האפליקציה או השירות במספר אזורים, או אפילו במספר אזורים. אם שירות קיים בכמה אזורים או אזורי זמינות, הוא יכול לעמוד טוב יותר בשיבושים בשירות באזור או באזור זמינות מסוים. למרות ש- Google Cloud עושה כל מאמץ כדי למנוע שיבושים כאלה, אירועים מסוימים הם בלתי צפויים, ולכן מומלץ להיות מוכנים.
בעזרת קבוצות של מכונות וירטואליות מנוהלות ב-Compute Engine, אפשר לפזר מכונות וירטואליות בכמה אזורים באזור מסוים, ולנהל את המכונות כיחידה לוגית. Google Cloud מציע גם דיסקים קשיחים אזוריים כדי לשכפל את הנתונים באופן אוטומטי לשני אזורים באזור מסוים.
באופן דומה, אפשר לשפר את הזמינות והעמידות של האפליקציות שפרסתם ב-GKE על ידי יצירת אשכולות אזוריים. באשכול אזורי, רכיבי מישור הבקרה של GKE, הצמתים וה-Pods מפוזרים על פני כמה אזורים בתוך אזור מסוים. רכיבי מישור הבקרה מפוזרים, ולכן תוכלו להמשיך לגשת למישור הבקרה של האשכול גם במהלך הפסקה זמנית בשירות שמשפיעה על תחום (zone) אחד או יותר (אבל לא על כל התחומים).
העדפת שירותים מנוהלים
במקום להתקין בנפרד את כל החלקים של סטאק האפליקציות, לתמוך בהם ולהפעיל אותם, תוכלו להשתמש בשירותים מנוהלים כדי לצרוך חלקים מסטאק האפליקציות בתור שירותים. לדוגמה, במקום להתקין ולנהל מסד נתונים של MySQL במכונות וירטואליות (VM), אפשר להשתמש במסד נתונים של MySQL שמסופק על ידי Cloud SQL. לאחר מכן תקבלו הסכם רמת שירות (SLA) לגבי זמינות, ותוכלו להסתמך על Google Cloud לניהול שכפול נתונים, גיבויים והתשתית הבסיסית. כשמשתמשים בשירותים מנוהלים, אפשר להקדיש פחות זמן לניהול התשתית ויותר זמן לשיפור האמינות של האפליקציה.
רבים משירותי המחשוב, מסדי הנתונים והאחסון המנוהלים של Google Cloudמציעים יתירות מובנית, שיכולה לעזור לכם לעמוד ביעדי הזמינות שלכם. רבים מהשירותים האלה מציעים מודל אזורי, כלומר התשתית שמריצה את האפליקציה שלכם ממוקמת באזור ספציפי ומנוהלת על ידי Google כך שתהיה זמינה באופן יתיר בכל האזורים בתוך אותו אזור. אם תחום הופך ללא זמין, האפליקציה או הנתונים שלכם מוגשים באופן אוטומטי מתחום אחר באזור.
שירותים מסוימים של מסדי נתונים ואחסון מציעים גם זמינות במספר אזורים, כלומר התשתית שמריצה את האפליקציה שלכם ממוקמת בכמה אזורים. שירותים רב-אזוריים יכולים לעמוד באובדן של אזור שלם, אבל בדרך כלל זה כרוך בזמן אחזור גבוה יותר.
איזון עומסים בכל רמה
איזון עומסים מאפשר לכם לחלק את התנועה בין קבוצות של משאבים. כשמפזרים את תעבורת הנתונים, עוזרים לוודא שמשאבים ספציפיים לא יהיו עמוסים מדי בזמן שמשאבים אחרים יהיו בלי פעילות. רוב מאזני העומסים מספקים גם תכונות של בדיקת תקינות, כדי לוודא שהתנועה לא מנותבת למשאבים לא תקינים או לא זמינים.
Google Cloud מציע כמה אפשרויות לאיזון עומסים. אם האפליקציה שלכם פועלת ב-Compute Engine או ב-GKE, תוכלו לבחור את סוג איזון העומסים המתאים ביותר בהתאם לסוג התנועה, למקור שלה ולמאפיינים אחרים שלה. מידע נוסף זמין במאמר סקירה כללית על איזון עומסים ובמאמר סקירה כללית על רשתות GKE.
לחלופין, חלק מהשירותים המנוהלים על ידי Google Cloud, כמו App Engine ו-Cloud Run, מבצעים איזון עומסים אוטומטי של התעבורה. Google Cloud
נהוג לבצע איזון עומסים של בקשות שמתקבלות ממקורות חיצוניים, כמו לקוחות אינטרנט או לקוחות לנייד. עם זאת, שימוש במאזני עומסים בין שירותים או רמות שונים באפליקציה יכול גם לשפר את העמידות והגמישות. Google Cloud מספקת איזון עומסים פנימי של שכבה 4 ושל שכבה 7 למטרה הזו.
בתרשים הבא מוצג מאזן עומסים חיצוני שמפיץ תנועה גלובלית בין שני אזורים, us-central1 ו-asia-east1. בנוסף, מוצג איזון עומסים פנימי שמפיץ את התעבורה משכבת האינטרנט לשכבה הפנימית בכל אזור.
מעקב אחרי התשתית והאפליקציות
כדי להחליט איך לשפר את החוסן (resilience) והמדרגיות של האפליקציה, צריך להבין את ההתנהגות שלה. גישה למערך מקיף של מדדים רלוונטיים וסדרות זמנים לגבי הביצועים והתקינות של האפליקציה יכולה לעזור לכם לגלות בעיות פוטנציאליות לפני שהן גורמות להפסקה זמנית בשירות. בנוסף, הם יכולים לעזור לכם לאבחן ולפתור הפסקה זמנית בשירות אם היא מתרחשת. בפרק monitoring distributed systems בספר SRE book של Google יש סקירה כללית טובה של כמה גישות למעקב.
בנוסף למתן תובנות לגבי תקינות האפליקציה, אפשר להשתמש במדדים גם כדי לשלוט בהתנהגות של התאמה אוטומטית לעומס בשירותים.
Cloud Monitoring הוא כלי מעקב משולב של Google Cloud. Cloud Monitoring קולט אירועים, מדדים ומטא-נתונים, ומספק תובנות באמצעות מרכזי בקרה והתראות. רוב השירותים של Google Cloud שולחים מדדים אל Cloud Monitoring באופן אוטומטי, ו-Cloud Monitoring תומך גם במקורות רבים של צד שלישי. אפשר להשתמש ב-Cloud Monitoring גם כקצה עורפי (backend) לכלים פופולריים למעקב אחרי קוד פתוח, וכך לקבל "תצוגת נתונים מאוחדת" של האפליקציה. Google Cloud
מעקב בכל הרמות
איסוף מדדים ברמות שונות בארכיטקטורה מספק תמונה הוליסטית של מצב האפליקציה וההתנהגות שלה.
מעקב אחר תשתיות
מעקב ברמת התשתית מספק את נתוני הבסיס של התקינות והביצועים של האפליקציה. הגישה הזו למעקב מתעדת מידע כמו עומס המעבד, השימוש בזיכרון ומספר הבייטים שנכתבו בדיסק. המדדים האלה יכולים להצביע על כך שמחשב עמוס מדי או שלא פועל כמצופה.
בנוסף למדדים שנאספים באופן אוטומטי, Cloud Monitoring מספק סוכן שאפשר להתקין כדי לאסוף מידע מפורט יותר ממכונות וירטואליות ב-Compute Engine, כולל מאפליקציות של צד שלישי שפועלות במכונות האלה.
מעקב אחרי אפליקציות
מומלץ לתעד מדדים ברמת האפליקציה. לדוגמה, יכול להיות שתרצו למדוד כמה זמן לוקח להריץ שאילתה מסוימת, או כמה זמן לוקח לבצע רצף קשור של קריאות לשירות. אתם מגדירים את המדדים האלה ברמת האפליקציה. הם מתעדים מידע שלא ניתן לתעד באמצעות המדדים המובנים של Cloud Monitoring. מדדים ברמת האפליקציה יכולים לתעד תנאים מצטברים שמשקפים בצורה מדויקת יותר תהליכי עבודה מרכזיים, והם יכולים לחשוף בעיות שלא נראות במדדי תשתית ברמה נמוכה.
מומלץ גם להשתמש ב-OpenTelemetry כדי לתעד את המדדים ברמת האפליקציה. OpenTelemetry מספק תקן פתוח יחיד לנתוני טלמטריה. אפשר להשתמש ב-OpenTelemetry כדי לאסוף ולייצא נתונים מהאפליקציות והתשתיות שלכם שמתמקדות בענן. לאחר מכן תוכלו לעקוב אחרי נתוני הטלמטריה המיוצאים ולנתח אותם.
ניטור שירותים
באפליקציות מבוזרות ובאפליקציות שמבוססות על מיקרו-שירותים, חשוב לעקוב אחרי האינטראקציות בין השירותים והרכיבים השונים באפליקציות. המדדים האלה יכולים לעזור לכם לאבחן בעיות כמו עלייה במספר השגיאות או חביון בין השירותים.
Cloud Service Mesh הוא רשת Service mesh שזמינה ב- Google Cloud ומאפשרת לכם לנהל, לצפות, למדוד ולאבטח את המיקרו-שירותים בתשתית שבחרתם, ב-Google Cloudומחוצה לה.
מעקב מקצה לקצה
בניטור מקצה לקצה, שנקרא גם ניטור משתמשי קצה, נבדקת התנהגות שגלויות חיצונית כמו שהמשתמש רואה אותן. סוג הניטור הזה בודק אם משתמש יכול להשלים פעולות קריטיות בתוך הספים שהגדרתם. ניטור גס יכול לחשוף שגיאות או חביון שאולי לא יתגלו בניטור מדויק יותר, והוא חושף את הזמינות כפי שהמשתמש תופס אותה.
חשיפת מצב התקינות של האפליקציות
מערכת עם זמינות גבוהה צריכה לכלול דרך כלשהי לקבוע אילו חלקים במערכת תקינים ופועלים בצורה נכונה. אם משאבים מסוימים נראים לא תקינים, המערכת יכולה לשלוח בקשות למקום אחר. בדרך כלל, בדיקות תקינות כוללות שליפת נתונים מנקודת קצה כדי לקבוע את הסטטוס או התקינות של שירות מסוים.
בדיקות תקינות הן חלק חשוב מהתפקיד של מאזני עומסים. כשיוצרים מאזן עומסים שמשויך לקבוצה של מופעים של מכונות וירטואליות, מגדירים גם בדיקת תקינות. בבדיקת תקינות מוגדרת הדרך שבה מאזן העומסים מתקשר עם המכונות הווירטואליות כדי להעריך אם מופעים מסוימים צריכים להמשיך לקבל תנועה. אפשר גם להשתמש בבדיקות תקינות של מאזן עומסים כדי לתקן באופן אוטומטי קבוצות של מכונות וירטואליות, כך שמכונות לא תקינות ייווצרו מחדש. אם אתם מפעילים את GKE ומאזנים עומסים של תעבורה חיצונית באמצעות משאב Ingress, GKE יוצר באופן אוטומטי בדיקות תקינות מתאימות למאזן העומסים.
ל-Kubernetes יש תמיכה מובנית בבדיקות תקינות (liveness) ובבדיקות מוכנות (readiness). הבדיקות האלה עוזרות למנהל התזמור של Kubernetes להחליט איך לנהל את קבוצות ה-Pod והבקשות באשכול. אם האפליקציה שלכם נפרסת ב-Kubernetes, מומלץ לחשוף את מצב התקינות של האפליקציה לבדיקות האלה באמצעות נקודות קצה מתאימות.
הגדרת מדדים מרכזיים
המעקב והבדיקות של תקינות האפליקציה מספקים מדדים לגבי ההתנהגות והסטטוס שלה. השלב הבא הוא לנתח את המדדים האלה כדי לקבוע אילו מהם הכי מתארים או משפיעים. המדדים העיקריים משתנים בהתאם לפלטפורמה שבה האפליקציה נפרסת, ולעבודה שהאפליקציה מבצעת.
סביר להניח שלא תמצאו מדד אחד שיצביע על כך שכדאי להרחיב את האפליקציה או ששירות מסוים לא תקין. לרוב מדובר בשילוב של גורמים שמצביעים יחד על קבוצה מסוימת של תנאים. בעזרת Cloud Monitoring, אפשר ליצור מדדים מותאמים אישית שיעזרו לכם לתעד את התנאים האלה. בספר של Google בנושא SRE מומלץ לעקוב אחרי ארבעה אותות חשובים כדי לנטר מערכת שפונה למשתמשים: זמן האחזור, תנועת הגולשים, שגיאות וניצול הקיבולת.
כדאי גם לקחת בחשבון את הסבילות שלכם לערכים חריגים. יכול להיות ששימוש בערך ממוצע או בערך חציוני כדי למדוד את התקינות או את הביצועים לא יהיה הבחירה הכי טובה, כי המדדים האלה יכולים להסתיר חוסר איזון משמעותי. לכן חשוב להתייחס לפיזור המדדים. יכול להיות שהאחוזון ה-99 יהיה מדד אינפורמטיבי יותר מהממוצע.
הגדרת יעדים למדידת רמת השירות (SLO)
אתם יכולים להשתמש במדדים שנאספים על ידי מערכת המעקב שלכם כדי להגדיר יעדים לרמת השירות (SLO). הסכמי רמת שירות (SLO) מציינים רמת ביצועים או מהימנות יעד לשירות שלכם. יעדים למדידת רמת השירות (SLO) הם אחד מעמודי התווך של שיטות העבודה המומלצות ב-SRE. הם מתוארים בפירוט בפרק יעדים למדידת רמת השירות בספר SRE, וגם בפרק הטמעה של יעדים למדידת רמת השירות בחוברת העבודה SRE.
אתם יכולים להשתמש במעקב אחרי שירותים כדי להגדיר יעדי זמינות (SLO) על סמך המדדים ב-Cloud Monitoring. אתם יכולים ליצור מדיניות התראות על SLO כדי לדעת אם אתם עלולים להפר SLO.
אחסון המדדים
מדדים ממערכת המעקב שלכם שימושיים בטווח הקצר כדי לעזור בבדיקות תקינות בזמן אמת או כדי לחקור בעיות מהזמן האחרון. כדי לתת מענה לתרחישים האלה, המדדים שלכם נשמרים ב-Cloud Monitoring למשך כמה שבועות.
עם זאת, יש ערך גם באחסון מדדי המעקב לניתוח לטווח ארוך. גישה לרשומה היסטורית יכולה לעזור לכם לאמץ גישה מבוססת-נתונים לשיפור ארכיטקטורת האפליקציה. אתם יכולים להשתמש בנתונים שנאספו במהלך הפסקת השירות ואחריה כדי לזהות צווארי בקבוק ותלות הדדית באפליקציות שלכם. אתם יכולים גם להשתמש בנתונים כדי ליצור ולבדוק בדיקות משמעותיות.
נתונים היסטוריים יכולים גם לעזור לכם לוודא שהאפליקציה תומכת ביעדים העסקיים שלכם בתקופות מרכזיות. לדוגמה, הנתונים יכולים לעזור לכם לנתח את מידת ההתאמה של האפליקציה במהלך אירועים שיווקיים עם נפח תנועה גבוה במהלך הרבעונים האחרונים או אפילו השנים האחרונות.
פרטים על ייצוא ואחסון של מדדים מופיעים במאמר בנושא ייצוא מדדים מ-Cloud Monitoring.
קביעת פרופיל שינוי הגודל
אתם רוצים שהאפליקציה תעמוד ביעדים של חוויית המשתמש והביצועים בלי להקצות יותר מדי משאבים.
בתרשים הבא מוצגת דוגמה פשוטה של פרופיל שינוי הגודל של אפליקציה. האפליקציה שומרת על רמת בסיס של משאבים, ומשתמשת בהתאמה אוטומטית לעומס כדי להגיב לשינויים בביקוש.
איזון בין עלות לבין חוויית משתמש
ההחלטה אם להרחיב את האפליקציה מתבססת בעיקר על איזון בין עלות לבין חוויית משתמש. צריך להחליט מה רמת הביצועים המינימלית המקובלת, ואולי גם מה הרמה המקסימלית. ספי הביצועים האלה משתנים מאפליקציה לאפליקציה, ואולי גם בין רכיבים או שירותים שונים באפליקציה אחת.
לדוגמה, לאפליקציה לנייד או לאתר שפונים לצרכנים עשויים להיות יעדים מחמירים של זמן אחזור. מחקרים מראים שאפילו עיכובים קטנים יכולים להשפיע לרעה על התפיסה של המשתמשים לגבי האפליקציה, וכתוצאה מכך להוביל לירידה במספר ההמרות ובמספר ההרשמות. לכן חשוב לוודא שלאפליקציה יש מספיק קיבולת להצגת מודעות כדי להגיב במהירות לבקשות של משתמשים. במקרה כזה, יכול להיות שהעלויות הגבוהות יותר של הפעלת יותר שרתי אינטרנט מוצדקות.
יכול להיות שיחס עלות-ביצועים יהיה שונה באפליקציה פנימית שלא חיונית לעסק, שבה המשתמשים כנראה סובלניים יותר לעיכובים קטנים. לכן, פרופיל התאמה לעומס יכול להיות פחות אגרסיבי. במקרה כזה, שמירה על עלויות נמוכות עשויה להיות חשובה יותר מאופטימיזציה של חוויית המשתמש.
הגדרת משאבי בסיס
רכיב חשוב נוסף בפרופיל ההתאמה הוא החלטה על קבוצת משאבים מינימלית מתאימה.
בדרך כלל לוקח זמן להגדיל את הקיבולת של מכונות וירטואליות ב-Compute Engine או של אשכולות GKE, כי צריך ליצור צמתים חדשים ולאתחל אותם. לכן, יכול להיות שיהיה צורך לשמור על קבוצה מינימלית של משאבים, גם אם אין תנועה. שוב, היקף משאבי הבסיס מושפע מסוג האפליקציה ומפרופיל התנועה.
לעומת זאת, טכנולוגיות בלי שרת כמו App Engine, פונקציות Cloud Run ו-Cloud Run מתוכננות להתרחבות עד לאפס, ולהתחלה ולהתרחבות מהירות, גם במקרה של הפעלה במצב התחלתי (cold start). בהתאם לסוג האפליקציה ולפרופיל התנועה, הטכנולוגיות האלה יכולות לייעל חלקים מהאפליקציה.
הגדרת התאמה אוטומטית לעומס
התאמה אוטומטית לעומס (automatic scaling) עוזרת לכם להתאים באופן אוטומטי את גודל משאבי המחשוב שנצרכים על ידי האפליקציה. בדרך כלל, התאמה אוטומטית לעומס (automatic scaling) מתרחשת כשחורגים מערכים מסוימים של מדדים או כשמתקיימים תנאים מסוימים. לדוגמה, אם זמן האחזור של הבקשות בשכבת האינטרנט מתחיל לחרוג מערך מסוים, יכול להיות שתרצו להוסיף עוד מכונות באופן אוטומטי כדי להגדיל את קיבולת ההגשה.
לרבים ממוצרי Google Cloud ה-Compute יש תכונות של התאמה אוטומטית לעומס. שירותים מנוהלים ללא שרתים כמו Cloud Run, פונקציות Cloud Run ו-App Engine מתוכננים להתאמה מהירה לעומס. בדרך כלל, השירותים האלה מציעים אפשרויות הגדרה להגבלת ההתנהגות של ההתאמה האוטומטית לעומס או להשפעה עליה, אבל באופן כללי, רוב ההתנהגות של הכלי להתאמה אוטומטית לעומס מוסתרת מהמפעיל.
Compute Engine ו-GKE מספקים יותר אפשרויות לשליטה בהתנהגות של שינוי הגודל. ב-Compute Engine, אפשר לבצע שינוי גודל על סמך קלט שונה, כולל מדדים מותאמים אישית של Cloud Monitoring וקיבולת ההגשה של מאזן העומסים. אפשר להגדיר מגבלות מינימום ומקסימום על התנהגות ההתאמה האוטומטית לעומס, וגם להגדיר מדיניות להתאמה אוטומטית לעומס עם כמה אותות כדי לטפל בתרחישים שונים. בדומה ל-GKE, אפשר להגדיר את התכונה לשינוי גודל האשכול באופן אוטומטי כדי להוסיף או להסיר צמתים על סמך עומס העבודה או מדדים של פודים, או על סמך מדדים חיצוניים לאשכול.
מומלץ להגדיר את התנהגות ההתאמה האוטומטית לעומס על סמך מדדי אפליקציה מרכזיים, על סמך פרופיל העלויות ועל סמך רמת המינימום של המשאבים שהוגדרה.
צמצום זמן ההפעלה
כדי שהרחבת הקיבולת תהיה יעילה, היא צריכה לקרות מספיק מהר כדי להתמודד עם העומס הגדל. זה נכון במיוחד כשמוסיפים קיבולת חישוב או קיבולת להצגת מודעות.
שימוש בתמונות מוכנות מראש
אם האפליקציה שלכם פועלת במכונות VM של Compute Engine, סביר להניח שתצטרכו להתקין תוכנה ולהגדיר את המכונות כדי להריץ את האפליקציה. למרות שאפשר להשתמש בסקריפטים להפעלה כדי להגדיר מכונות חדשות, דרך יעילה יותר היא ליצור קובץ אימג' בהתאמה אישית. קובץ אימג' בהתאמה אישית הוא דיסק אתחול שהגדרתם עם תוכנה והגדרות שספציפיות לאפליקציה.
מידע נוסף על ניהול תמונות זמין במאמר בנושא שיטות מומלצות לניהול תמונות.
אחרי שיוצרים תמונה, אפשר להגדיר תבנית של הגדרות מכונה. בתבניות של הגדרות מכונה משולבים תמונת דיסק האתחול, סוג המכונה ומאפיינים אחרים של המכונה. לאחר מכן אפשר להשתמש בתבנית של הגדרות מכונה כדי ליצור מופעי מכונה וירטואליים נפרדים או קבוצת מופעי מכונה מנוהלים. תבניות של הגדרות מכונה הן דרך נוחה לשמור את ההגדרה של מופע מכונה וירטואלית, כדי שתוכלו להשתמש בה בהמשך ליצירת מופעי מכונה וירטואליים חדשים זהים.
יצירת תמונות בהתאמה אישית ותבניות של מכונות וירטואליות יכולה להגדיל את מהירות הפריסה, אבל היא גם יכולה להגדיל את עלויות התחזוקה כי יכול להיות שיהיה צורך לעדכן את התמונות בתדירות גבוהה יותר. מידע נוסף זמין במאמר בנושא איזון בין הגדרת תמונות לבין מהירות הפריסה.
העברת האפליקציה לקונטיינר
אפשרות חלופית ליצירת מופעי מכונה וירטואלית בהתאמה אישית היא ליצור קונטיינר לאפליקציה. קונטיינר הוא חבילת תוכנה קלה, עצמאית וניתנת להפעלה, שכוללת את כל מה שצריך כדי להפעיל אפליקציה: קוד, זמן ריצה, כלי מערכת, ספריות מערכת והגדרות. המאפיינים האלה הופכים את האפליקציות שמבוססות על קונטיינרים לניידות יותר, קלות יותר לפריסה וקלות יותר לתחזוקה בקנה מידה גדול בהשוואה למכונות וירטואליות. בנוסף, בדרך כלל קונטיינרים מופעלים במהירות, ולכן הם מתאימים לאפליקציות שניתנות להרחבה ועמידות.
Google Cloud מציע כמה שירותים להרצת קונטיינרים של אפליקציות. Cloud Run מספק פלטפורמת מחשוב מנוהלת בלי שרת (serverless) לאירוח קונטיינרים בלי שמירת מצב. בסביבת App Engine Flexible מתארחים הקונטיינרים שלכם בפלטפורמה כשירות (PaaS) מנוהלת. GKE מספק סביבת Kubernetes מנוהלת לאירוח ולתזמור של אפליקציות בקונטיינרים. אפשר גם להריץ את הקונטיינרים של האפליקציה ב-Compute Engine כשרוצים שליטה מלאה בסביבת הקונטיינרים.
אופטימיזציה של האפליקציה להפעלה מהירה
בנוסף לווידוא שאפשר לפרוס את התשתית והאפליקציה בצורה יעילה ככל האפשר, חשוב גם לוודא שהאפליקציה תהיה זמינה באינטרנט במהירות.
האופטימיזציות שמתאימות לאפליקציה שלכם משתנות בהתאם למאפיינים של האפליקציה ולפלטפורמת ההפעלה שלה. חשוב לבצע את הפעולות הבאות:
- כדי למצוא צווארי בקבוק ולפתור אותם, צריך ליצור פרופיל של החלקים הקריטיים באפליקציה שמופעלים בהפעלה.
- כדי לקצר את זמן ההפעלה הראשוני, כדאי להטמיע טכניקות כמו אתחול עצלן, במיוחד של משאבים יקרים.
- מצמצמים את התלות באפליקציות שאולי צריך לטעון בזמן ההפעלה.
העדפה של ארכיטקטורות מודולריות
כדי להגדיל את הגמישות של האפליקציה, כדאי לבחור ארכיטקטורות שמאפשרות פריסה, ניהול והרחבה של רכיבים באופן עצמאי. התבנית הזו יכולה גם לשפר את העמידות על ידי ביטול נקודות כשל יחידות.
פירוק האפליקציה לשירותים עצמאיים
אם תתכננו את האפליקציה שלכם כקבוצה של שירותים עצמאיים עם צימוד רופף, תוכלו להגדיל את הגמישות של האפליקציה. אם תבחרו בעיצוב עם צימוד חלש, תוכלו להפיץ ולפרוס את השירותים שלכם באופן עצמאי. בנוסף ליתרונות רבים אחרים, הגישה הזו מאפשרת לשירותים האלה להשתמש במערכות טכנולוגיות שונות ולנוהל על ידי צוותים שונים. הגישה הזו של צימוד חלש היא הנושא המרכזי בדפוסי ארכיטקטורה כמו מיקרו-שירותים ו-SOA.
כשחושבים איך להגדיר גבולות לשירותים, דרישות הזמינות והמדרגיות הן מימדים חשובים. לדוגמה, אם לרכיב מסוים יש דרישת זמינות שונה או פרופיל קנה מידה שונה מהרכיבים האחרים, יכול להיות שכדאי להפוך אותו לשירות עצמאי.
שואפים להשתמש בגישה חסרת מצב
אפליקציה או שירות בלי שמירת מצב לא שומרים נתונים או מצב מקומיים קבועים. מודל חסר מצב מבטיח שתוכלו לטפל בכל בקשה או אינטראקציה עם השירות באופן עצמאי, ללא קשר לבקשות קודמות. המודל הזה מאפשר יכולת הרחבה ושחזור, כי הוא מאפשר לשירות לגדול, להצטמצם או להפעיל מחדש בלי לאבד נתונים שנדרשים כדי לטפל בתהליכים או בבקשות שנמצאים בתהליך. היעדר מצב חשוב במיוחד כשמשתמשים בשינוי גודל אוטומטי, כי אפשר ליצור ולהרוס את המופעים, הצמתים או התרמילים שמארחים את השירות באופן בלתי צפוי.
יכול להיות שלא תוכלו להפוך את כל השירותים שלכם לבלי שמירת מצב. במקרה כזה, צריך לציין במפורש אילו שירותים דורשים מצב. הקפדה על הפרדה ברורה בין שירותים בלי שמירת מצב לבין שירותים עם שמירת מצב מאפשרת לכם להבטיח מדרגיות פשוטה לשירותים בלי שמירת מצב, תוך אימוץ גישה מחושבת יותר לשירותים עם שמירת מצב.
ניהול התקשורת בין שירותים
אחד האתגרים בארכיטקטורות מבוזרות של מיקרו-שירותים הוא ניהול התקשורת בין השירותים. ככל שרשת השירותים שלכם גדלה, סביר להניח שגם התלות ההדדית בין השירותים תגדל. אתם לא רוצים שכשל בשירות אחד יוביל לכשל בשירותים אחרים, מצב שלפעמים נקרא כשל מדורג.
כדי לצמצם את נפח התנועה לשירות שעמוס מדי או לשירות שנכשל, אפשר להשתמש בטכניקות כמו מפסק זרם, השהיות אקספוננציאליות והשבתה הדרגתית. הדפוסים האלה מגדילים את החוסן של האפליקציה, או על ידי מתן הזדמנות לשירותים עמוסים להתאושש, או על ידי טיפול אלגנטי במצבי שגיאה. מידע נוסף זמין בפרק Addressing Cascading Failures בספר Google SRE.
שימוש בService mesh יכול לעזור לכם לנהל את תעבורת הנתונים בשירותים המבוזרים שלכם. Service mesh היא תוכנה שמקשרת בין שירותים ועוזרת להפריד בין לוגיקה עסקית לבין רישות. Service mesh בדרך כלל מספקת תכונות חוסן כמו ניסיונות חוזרים של בקשות, יתירות כשל ומפסקי זרם.
שימוש בטכנולוגיית אחסון ומסד נתונים מתאימה
קשה להרחיב ולשפר את העמידות של מסדי נתונים מסוימים וסוגים מסוימים של אחסון. חשוב לוודא שהבחירות שלכם לגבי מסד הנתונים לא מגבילות את הזמינות וההתאמה של האפליקציה.
הערכת הצרכים שלכם ממסד הנתונים
הדפוס של עיצוב האפליקציה כקבוצה של שירותים עצמאיים חל גם על מסדי הנתונים והאחסון. יכול להיות שיהיה נכון לבחור סוגים שונים של אחסון לחלקים שונים באפליקציה, וכך ליצור אחסון הטרוגני.
אפליקציות רגילות פועלות לרוב באופן בלעדי עם מסדי נתונים רלציוניים. מסדי נתונים רלציוניים מציעים פונקציונליות שימושית כמו עסקאות, עקביות חזקה, שלמות רפרנציאלית ושאילתות מתוחכמות בטבלאות. התכונות האלה הופכות את מסדי הנתונים הרלציוניים לבחירה טובה עבור הרבה תכונות נפוצות באפליקציות. עם זאת, יש גם אילוצים במסדי נתונים רלציוניים. בדרך כלל קשה להרחיב אותם, ונדרש ניהול קפדני בהגדרה של זמינות גבוהה. יכול להיות שמסד נתונים רלציוני הוא לא הבחירה הכי טובה לכל הצרכים שלכם.
מסדי נתונים לא רלציוניים, שמכונים לעיתים קרובות מסדי נתונים מסוג NoSQL, פועלים בגישה שונה. הפרטים משתנים בין המוצרים, אבל בדרך כלל מסדי נתונים מסוג NoSQL מוותרים על חלק מהתכונות של מסדי נתונים רלציוניים כדי להגדיל את הזמינות ולשפר את יכולת ההתאמה לעומס. מבחינת משפט CAP, מסדי נתונים NoSQL בוחרים לעיתים קרובות בזמינות על פני עקביות.
ההחלטה אם מסד נתונים מסוג NoSQL מתאים לכם תלויה במידה רבה ברמת העקביות הנדרשת. אם מודל הנתונים של שירות מסוים לא דורש את כל התכונות של RDBMS, ואפשר לעצב אותו כך שיהיה עקבי בסופו של דבר, בחירה במסד נתונים NoSQL עשויה להציע זמינות ומדרגיות משופרות.
בתחום ניהול הנתונים, מסדי נתונים רלציוניים ולא רלציוניים נתפסים לעיתים קרובות כטכנולוגיות משלימות ולא מתחרות. שימוש אסטרטגי בשני סוגי מסדי הנתונים מאפשר לארגונים לנצל את היתרונות של כל אחד מהם כדי להשיג תוצאות אופטימליות באחסון, באחזור ובניתוח של נתונים.
בנוסף למגוון מסדי נתונים רלציוניים ו-NoSQL, Google Cloud מציע גם את Spanner, מסד נתונים עקבי מאוד, זמין מאוד ומבוזר גלובלית עם תמיכה ב-SQL. מידע על בחירת מסד נתונים מתאים ב-Google Cloudזמין במאמר בנושא מסדי נתונים שלGoogle Cloud .
הטמעה של שמירה במטמון
המטרה העיקרית של מטמון היא לשפר את הביצועים של אחזור הנתונים על ידי צמצום הצורך בגישה לשכבת האחסון הבסיסית האיטית יותר.
השימוש במטמון תומך בהרחבת יכולת ההתאמה לגודל, כי הוא מפחית את ההסתמכות על אחסון מבוסס-דיסק. מכיוון שאפשר להגיב לבקשות מהזיכרון, זמן האחזור של הבקשות לשכבת האחסון קצר יותר, ובדרך כלל השירות יכול לטפל ביותר בקשות. בנוסף, השימוש במטמון יכול להפחית את העומס על שירותים שנמצאים במורד הזרם של האפליקציה, במיוחד מסדי נתונים, וכך לאפשר גם לרכיבים אחרים שמתקשרים עם השירות הזה במורד הזרם להתרחב יותר, או בכלל.
השימוש במטמון יכול גם לשפר את העמידות באמצעות תמיכה בטכניקות כמו שדרוג הדרגתי. אם שכבת האחסון הבסיסית עמוסה מדי או לא זמינה, המטמון יכול להמשיך לטפל בבקשות. גם אם הנתונים שמוחזרים מהמטמון לא מלאים או לא עדכניים, יכול להיות שזה מקובל בתרחישים מסוימים.
Memorystore for Redis מספק שירות מנוהל מלא שמבוסס על מאגר הנתונים בזיכרון של Redis. שירות Memorystore for Redis מספק גישה עם זמן אחזור נמוך וקצב העברת נתונים גבוה לנתונים שמתבצעת אליהם גישה תכופה. אפשר לפרוס אותו בהגדרה של זמינות גבוהה שמספקת שכפול בין אזורים ומעבר אוטומטי לגיבוי בעת כשל.
מודרניזציה של תהליכי הפיתוח והתרבות
אפשר להתייחס ל-DevOps כאל אוסף רחב של תהליכים, תרבות וכלים שמקדמים גמישות ומקצרים את זמן היציאה לשוק (Time to market) של אפליקציות ותכונות. זאת על ידי פירוק של סילואים בין צוותי הפיתוח, התפעול וצוותים קשורים. הטכניקות של DevOps נועדו לשפר את האיכות והאמינות של התוכנה.
הדיון המפורט בנושא DevOps חורג מהיקף המסמך הזה, אבל בחלקים הבאים נדון בכמה היבטים מרכזיים שקשורים לשיפור המהימנות והחוסן של האפליקציה. פרטים נוספים זמיניםGoogle Cloud בדף בנושא DevOps.
עיצוב שמאפשר בדיקה
בדיקות אוטומטיות הן רכיב מרכזי בשיטות מודרניות של הכנת תוכנה להפצה. היכולת להריץ קבוצה מקיפה של בדיקות יחידה, בדיקות שילוב ובדיקות מערכת חיונית כדי לוודא שהאפליקציה מתנהגת כמצופה, ושהיא יכולה להתקדם לשלב הבא במחזור הפריסה. היכולת לבדוק היא קריטריון עיצוב מרכזי לאפליקציה.
מומלץ להשתמש בבדיקות יחידה לרוב הבדיקות, כי הן מהירות לביצוע ובדרך כלל קל לתחזק אותן. מומלץ גם להפוך לאוטומטיות את הבדיקות של השילובים והמערכות ברמה גבוהה יותר. הבדיקות האלה פשוטות הרבה יותר אם משתמשים בטכניקות של תשתית כקוד, כי אפשר ליצור סביבות בדיקה ומשאבים ייעודיים לפי דרישה, ואז להסיר אותם אחרי שהבדיקות מסתיימות.
ככל שאחוז בסיס הקוד שמכוסה על ידי בדיקות עולה, כך פוחתת אי הוודאות והירידה הפוטנציאלית באמינות מכל שינוי בקוד. כיסוי בדיקות הולם מאפשר לבצע יותר שינויים לפני שהמהימנות יורדת מתחת לרמה מקובלת.
בדיקות אוטומטיות הן חלק בלתי נפרד מאינטגרציה רציפה. ביצוע של סדרה מקיפה של בדיקות אוטומטיות על כל קוד מחויב מספק משוב מהיר על שינויים, ומשפר את האיכות והמהימנות של התוכנה. Google Cloud– כלים מקוריים כמו Cloud Build וכלים של צד שלישי כמו Jenkins יכולים לעזור לכם להטמיע אינטגרציה רציפה.
אוטומציה של הפריסות
שילוב רציף ואוטומציה מקיפה של בדיקות מאפשרים לכם להיות בטוחים ביציבות של התוכנה. אחרי שמטמיעים אותם, השלב הבא הוא אוטומציה של פריסת האפליקציה. רמת האוטומציה של הפריסה משתנה בהתאם לרמת הבשלות של הארגון.
בחירה של אסטרטגיית פריסה מתאימה היא חיונית כדי לצמצם את הסיכונים שקשורים לפריסה של תוכנה חדשה. בעזרת האסטרטגיה הנכונה, אפשר להגדיל בהדרגה את החשיפה של גרסאות חדשות לקהלים גדולים יותר, ולאמת את ההתנהגות לאורך הדרך. אפשר גם להגדיר הוראות ברורות לביטול השינויים אם מתרחשות בעיות.
אימוץ שיטות SRE להתמודדות עם כשלים
באפליקציות מבוזרות שפועלות בהיקף גדול, נפוץ שחלק מהרכיבים נכשלים. אם תיישמו את הדפוסים שמתוארים במסמך הזה, האפליקציה תוכל להתמודד טוב יותר עם שיבושים שנגרמים כתוצאה מהפצה של תוכנה פגומה, סיום לא צפוי של מכונות וירטואליות או אפילו הפסקת פעולה של התשתית שמשפיעה על אזור שלם.
עם זאת, גם אם תתכננו את האפליקציה בקפידה, בסופו של דבר תיתקלו באירועים לא צפויים שידרשו התערבות אנושית. אם תיישמו תהליכים מובנים לניהול האירועים האלה, תוכלו לצמצם באופן משמעותי את ההשפעה שלהם ולפתור אותם מהר יותר. בנוסף, אם תבדקו את הסיבות לאירוע ואת התגובות אליו, תוכלו להגן על האפליקציה מפני אירועים דומים בעתיד.
תהליכים חזקים לניהול אירועים ולביצוע ניתוח לאחר אירוע ללא האשמה הם עקרונות מרכזיים ב-SRE. יכול להיות שהטמעה של כל השיטות של Google SRE לא תהיה מעשית בארגון שלכם, אבל אם תאמצו אפילו קבוצה מינימלית של הנחיות, תוכלו לשפר את החוסן של האפליקציה. בנספחים של הספר בנושא SRE יש כמה תבניות שיכולות לעזור לכם לעצב את התהליכים שלכם.
אימות ובדיקה של הארכיטקטורה
האפליקציה שלכם מתפתחת, וכך גם התנהגות המשתמשים, פרופילי התנועה ואפילו סדרי העדיפויות העסקיים. באופן דומה, גם שירותים או תשתיות אחרים שהאפליקציה שלכם תלויה בהם יכולים להתפתח. לכן, חשוב לבדוק מדי פעם את החוסן והמדרגיות של האפליקציה ולאמת אותם.
בדיקת החוסן
חשוב מאוד לבדוק שהאפליקציה מגיבה לכשלים בצורה שציפיתם. הנושא המרכזי הוא שהדרך הטובה ביותר להימנע מכישלון היא להכיר את הכישלון וללמוד ממנו.
הסימולציה של כשלים והצגתם מורכבות. בנוסף לאימות ההתנהגות של האפליקציה או השירות, צריך גם לוודא שהתראות צפויות נוצרות ומדדים מתאימים נוצרים. מומלץ להשתמש בגישה מובנית, שבה מתחילים עם כשלים בסיסיים ואז עוברים לכשלים מורכבים יותר.
לדוגמה, אפשר לפעול באופן הבא, לאמת ולתעד את ההתנהגות בכל שלב:
- הוספת כשלים לסירוגין.
- חסימת הגישה לתלות של השירות.
- חסימת כל התקשורת ברשת.
- למחוק את המארחים?
מידע נוסף מופיע בסרטון Breaking your systems to make them unbreakable מ- Google Cloud Next 2019.
אם אתם משתמשים ב-Service mesh כמו Istio כדי לנהל את שירותי האפליקציה, אתם יכולים להחדיר תקלות בשכבת האפליקציות במקום להשבית Podים או מכונות, או להחדיר מנות פגומות בשכבת ה-TCP. אתם יכולים להוסיף עיכובים כדי לדמות חביון ברשת או מערכת עליונה שעמוסה מדי. אפשר גם להגדיר ביטולים, שמדמים כשלים במערכות במעלה הזרם.
בדיקת התנהגות ההתאמה לעומס
מומלץ להשתמש בבדיקות אוטומטיות לא פונקציונליות כדי לוודא שהאפליקציה ניתנת להרחבה כמצופה. לעתים קרובות האימות הזה משולב עם בדיקות ביצועים או בדיקות עומס. אפשר להשתמש בכלים כמו hey כדי לשלוח עומס לאפליקציית אינטרנט. דוגמה מפורטת יותר שמראה איך לבצע בדיקות עומס מול נקודת קצה של REST מופיעה במאמר בדיקות עומס מבוזרות באמצעות Google Kubernetes Engine.
גישה נפוצה אחת היא לוודא שהמדדים העיקריים נשארים ברמות הצפויות בעומסים משתנים. לדוגמה, אם בודקים את יכולת ההתאמה של שכבת האינטרנט, אפשר למדוד את זמן האחזור הממוצע של הבקשות עבור נפחים משתנים של בקשות משתמשים. באופן דומה, עבור תכונה של עיבוד בקצה העורפי, אפשר למדוד את זמן העיבוד הממוצע של המשימות כשנפח המשימות גדל באופן פתאומי.
בנוסף, כדאי שהבדיקות ימדדו את מספר המשאבים שנוצרו כדי לטפל בעומס הבדיקה, ויוודאו שהוא נמצא בטווח הצפוי. לדוגמה, הבדיקות יכולות לוודא שמספר המכונות הווירטואליות שנוצרו כדי לטפל במשימות מסוימות בעורף המערכת לא חורג מערך מסוים.
חשוב גם לבדוק מקרים קיצוניים. מה קורה באפליקציה או בשירות כשמגיעים למגבלות המקסימליות של ההרחבה? מה קורה אם השירות שלך מצטמצם ואז העומס גדל שוב באופן פתאומי?
תמיד לתכנן את הארכיטקטורה
עולם הטכנולוגיה מתפתח במהירות, וזה נכון במיוחד לגבי הענן. מוצרים ותכונות חדשים מושקים לעיתים קרובות, דפוסים חדשים צצים והדרישות מהמשתמשים ובעלי העניין הפנימיים ממשיכות לגדול.
כפי שמוסבר בפוסט בבלוג בנושא עקרונות לארכיטקטורה מבוססת-ענן, חשוב תמיד לחפש דרכים לשפר ולפשט את הארכיטקטורה של האפליקציות. מערכות תוכנה הן דבר חי שצריך להתאים את עצמו לשינויים בסדרי העדיפויות שלכם.
המאמרים הבאים
- מומלץ לקרוא את הפוסט בבלוג בנושא עקרונות לארכיטקטורה מבוססת-ענן.
- אפשר לקרוא את הספרים בנושא SRE כדי לקבל פרטים על אופן הניהול של סביבת הייצור של Google.
- DevOps ב- Google Cloud
- כדאי להעמיק את הקריאה ולהכיר דוגמאות לארכיטקטורות, תרשימים ושיטות מומלצות בנושאי Google Cloud. כל אלה זמינים במרכז הארכיטקטורה של Cloud.