איך מפתחים אפליקציות חסינות שאפשר להרחיב ולהקטין

Last reviewed 2025-05-05 UTC

במאמר הזה אנחנו מציגים כמה תבניות ושיטות ליצירת אפליקציות חסינות שאפשר להרחיב ולהקטין לפי הצורך: שני יעדים חשובים בהרבה תרגילים מודרניים של בניית ארכיטקטורה. אם האפליקציה תוכננה נכון, אפשר להרחיב ולהקטין אותה בהתאם לעומס, והיא תהיה חסינה מספיק כדי לשרוד שיבושים בשירות. כדי ליצור ולהפעיל אפליקציות שעומדות בדרישות האלה, צריך לתכנן ולעצב אותן בקפידה.

מדרגיות: התאמת הקיבולת בהתאם לביקוש

מדרגיות היא מדד ליכולת של מערכת לטפל בכמויות משתנות של עבודה על ידי הוספה או הסרה של משאבים מהמערכת. לדוגמה, אפליקציית אינטרנט ניתנת להרחבה אם היא פועלת בצורה טובה עם משתמש אחד או עם משתמשים רבים, ומטפלת בצורה חלקה בשיאים ובשפל בתנועה.

הגמישות להתאים את המשאבים שנצרכים על ידי אפליקציה היא גורם מרכזי שמניע עסקים לעבור לענן. בעזרת תכנון נכון, אפשר להפחית את העלויות על ידי הסרת משאבים שלא מנוצלים מספיק, בלי לפגוע בביצועים או בחוויית המשתמש. באופן דומה, אפשר להוסיף עוד משאבים כדי לשמור על חוויית משתמש טובה בתקופות של תנועה גבוהה. כך האפליקציה יכולה לצרוך רק את המשאבים שדרושים כדי לעמוד בביקוש.

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

עמידות: תכנון שיאפשר עמידה בפני כשלים

אפליקציה עמידה היא אפליקציה שממשיכה לפעול למרות כשלים ברכיבי המערכת. כדי להשיג חוסן, צריך לתכנן את הארכיטקטורה בכל הרמות. היא משפיעה על הפריסה של התשתית והרשת, ועל העיצוב של האפליקציה ואחסון הנתונים. החוסן מתייחס גם לאנשים ולתרבות.

קשה ליצור ולהפעיל אפליקציות עמידות. זה נכון במיוחד לגבי אפליקציות מבוזרות, שעשויות להכיל כמה שכבות של תשתית, רשתות ושירותים. טעויות והפסקות זמניות בשירות קורות, ושיפור החוסן (resilience) של האפליקציה הוא התהליך שלי. בעזרת תכנון קפדני, אפשר לשפר את היכולת של האפליקציה להתמודד עם כשלים. בעזרת תהליכים מתאימים ותרבות ארגונית, אפשר גם ללמוד מטעויות כדי לשפר עוד יותר את החוסן של האפליקציה.

‫Google Cloud 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), כך שכל שינוי בהגדרות ייבדק וייפרס באופן אוטומטי.

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

העדפת שירותים מנוהלים

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

בתרשים הבא מוצג מאזן עומסים חיצוני שמפיץ תנועה גלובלית בין שני אזורים, us-central1 ו-asia-east1. בנוסף, מוצג איזון עומסים פנימי שמפיץ את התעבורה משכבת האינטרנט לשכבה הפנימית בכל אזור.

הפצת תנועה גלובלית בין אזורים.

מעקב אחרי התשתית והאפליקציות

כדי להחליט איך לשפר את החוסן והגמישות של האפליקציה, צריך להבין את ההתנהגות שלה. גישה למערך מקיף של מדדים רלוונטיים ולסדרות עיתיות לגבי הביצועים והתקינות של האפליקציה יכולה לעזור לכם לגלות בעיות פוטנציאליות לפני שהן גורמות להפסקה זמנית בשירות. הם גם יכולים לעזור לכם לאבחן ולפתור הפסקה זמנית בשירות אם היא מתרחשת. בפרק monitoring distributed systems בספר SRE book של Google יש סקירה כללית טובה של כמה גישות למעקב.

בנוסף למתן תובנות לגבי תקינות האפליקציה, אפשר להשתמש במדדים גם כדי לשלוט בהתנהגות של התאמה אוטומטית לעומס בשירותים.

‫Cloud Monitoring הוא כלי המעקב המשולב של Google Cloud. מערכת Cloud Monitoring מטמיעה נתונים של אירועים, מדדים ומטא-נתונים, ומספקת תובנות באמצעות לוחות בקרה והתראות. רוב Google Cloud השירותים שולחים מדדים ל-Cloud Monitoring באופן אוטומטי, Google Cloud והוא תומך גם במקורות רבים של צדדים שלישיים. אפשר גם להשתמש ב-Cloud Monitoring כבק-אנד עבור כלי מעקב פופולריים בקוד פתוח, כדי לקבל תצוגת נתונים מאוחדת של האפליקציה.

מעקב בכל הרמות

איסוף מדדים ברמות או בשכבות שונות בארכיטקטורה מספק תמונה הוליסטית של תקינות האפליקציה וההתנהגות שלה.

מעקב אחר התשתית

מעקב ברמת התשתית מספק את נתוני הבסיס של תקינות וביצועים של האפליקציה. בגישה הזו למעקב נאסף מידע כמו עומס המעבד, השימוש בזיכרון ומספר הבייטים שנכתבו בדיסק. המדדים האלה יכולים להצביע על כך שמכונה עמוסה מדי או שלא פועלת כמצופה.

בנוסף למדדים שנאספים באופן אוטומטי, 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. אתם יכולים ליצור מדיניות התראות על יעדי רמת השירות כדי לדעת אם אתם עלולים להפר יעד רמת שירות.

אחסון המדדים

מדדים ממערכת המעקב שימושיים בטווח הקצר כדי לעזור בבדיקות תקינות בזמן אמת או כדי לחקור בעיות מהזמן האחרון. כדי לתת מענה לתרחישים האלה, המדדים שלכם נשמרים ב-Cloud Monitoring למשך כמה שבועות.

עם זאת, יש גם ערך באחסון מדדי המעקב לניתוח לטווח ארוך. גישה לרשומה היסטורית יכולה לעזור לכם לאמץ גישה מבוססת-נתונים לשיפור ארכיטקטורת האפליקציה. אתם יכולים להשתמש בנתונים שנאספו במהלך הפסקה זמנית בשירות ואחריה כדי לזהות צווארי בקבוק ותלות הדדית באפליקציות שלכם. אפשר גם להשתמש בנתונים כדי ליצור ולבדוק ניסויים משמעותיים.

נתונים היסטוריים יכולים גם לעזור לכם לוודא שהאפליקציה תומכת ביעדים העסקיים שלכם בתקופות חשובות. לדוגמה, הנתונים יכולים לעזור לכם לנתח את מידת ההתאמה של האפליקציה שלכם במהלך אירועים שיווקיים עם תנועה גבוהה, במהלך הרבעונים האחרונים או אפילו השנים האחרונות.

פרטים על ייצוא ואחסון של מדדים מופיעים במאמר בנושא ייצוא מדדים מ-Cloud Monitoring.

קביעת פרופיל שינוי הגודל

אתם רוצים שהאפליקציה תעמוד ביעדים של חוויית המשתמש והביצועים בלי להקצות יותר מדי משאבים.

בתרשים הבא מוצגת דוגמה פשוטה של פרופיל שינוי הגודל של אפליקציה. האפליקציה שומרת על רמת בסיס של משאבים, ומשתמשת בהתאמה אוטומטית לעומס כדי להגיב לשינויים בביקוש.

פרופיל לקביעת קנה מידה באפליקציות.

איזון בין עלות לבין חוויית משתמש

ההחלטה אם להרחיב את האפליקציה מתבססת בעיקר על איזון בין העלות לבין חוויית המשתמש. קובעים מהי רמת הביצועים המינימלית המקובלת, ואולי גם מגדירים תקרה. הסף הזה משתנה מאפליקציה לאפליקציה, ויכול להיות שהוא משתנה גם בין רכיבים או שירותים שונים באותה אפליקציה.

לדוגמה, לאפליקציה לנייד או לאתר שפונים לצרכנים עשויים להיות יעדים מחמירים של זמן אחזור. מחקרים מראים שאפילו עיכובים קטנים יכולים להשפיע לרעה על התפיסה של המשתמשים לגבי האפליקציה, וכתוצאה מכך להוביל לירידה במספר ההמרות ובמספר ההרשמות. לכן חשוב לוודא שלאפליקציה יש מספיק קיבולת להצגת מודעות כדי להגיב במהירות לבקשות של משתמשים. במקרה כזה, יכול להיות שהעלויות הגבוהות יותר של הפעלת יותר שרתי אינטרנט מוצדקות.

יכול להיות שיחס העלות לביצועים יהיה שונה באפליקציה פנימית שהיא לא קריטית לעסק, שבה סביר להניח שהמשתמשים יגלו סובלנות רבה יותר לעיכובים קלים. לכן, פרופיל ההרחבה יכול להיות פחות אגרסיבי. במקרה הזה, יכול להיות שהשאיפה לעלויות נמוכות חשובה יותר מאופטימיזציה של חוויית המשתמש.

הגדרת משאבי בסיס

רכיב חשוב נוסף בפרופיל ההתאמה הוא החלטה על קבוצת משאבים מינימלית מתאימה.

בדרך כלל לוקח זמן להגדיל את הקיבולת של מכונות וירטואליות ב-Compute Engine או של אשכולות GKE, כי צריך ליצור צמתים חדשים ולאתחל אותם. לכן, יכול להיות שיהיה צורך לשמור על קבוצה מינימלית של משאבים, גם אם אין תנועה. שוב, היקף משאבי הבסיס מושפע מסוג האפליקציה ומפרופיל התנועה.

לעומת זאת, טכנולוגיות בלי שרת כמו App Engine, פונקציות Cloud Run ו-Cloud Run מיועדות להתרחבות לאפס, ולהתחלה ולהתרחבות מהירות, גם במקרה של הפעלה במצב התחלתי (cold start). בהתאם לסוג האפליקציה ולפרופיל התנועה, הטכנולוגיות האלה יכולות לשפר את היעילות של חלקים באפליקציה.

הגדרת התאמה אוטומטית לעומס (autoscaling)

התאמה אוטומטית לעומס (automatic scaling) עוזרת לכם להתאים באופן אוטומטי את גודל משאבי המחשוב שנצרכים על ידי האפליקציה. בדרך כלל, התאמה אוטומטית לעומס (automatic scaling) מתרחשת כשחורגים ממדדים מסוימים או כשמתקיימים תנאים מסוימים. לדוגמה, אם זמן האחזור של הבקשות בשכבת האינטרנט מתחיל לחרוג מערך מסוים, יכול להיות שתרצו להוסיף עוד מכונות באופן אוטומטי כדי להגדיל את קיבולת ההגשה.

הרבה מוצרי Google Cloud מחשוב כוללים תכונות של התאמה אוטומטית לעומס. שירותים מנוהלים ללא שרת כמו Cloud Run, פונקציות Cloud Run ו-App Engine מיועדים להרחבה מהירה. בדרך כלל, השירותים האלה מציעים אפשרויות הגדרה להגבלת ההתנהגות של התאמה אוטומטית לעומס או להשפעה עליה, אבל באופן כללי, חלק גדול מההתנהגות של מידרוג אוטומטי מוסתר מהמפעיל.

ב-Compute Engine וב-GKE יש יותר אפשרויות לשליטה בהתנהגות של שינוי הגודל. ב-Compute Engine, אפשר לבצע שינוי גודל על סמך קלט שונה, כולל מדדים מותאמים אישית של Cloud Monitoring וקיבולת ההגשה של מאזן העומסים. אפשר להגדיר מגבלות מינימום ומקסימום על התנהגות ההתאמה האוטומטית לעומס, וגם להגדיר מדיניות להתאמה אוטומטית לעומס עם כמה אותות כדי לטפל בתרחישים שונים. בדומה ל-GKE, אפשר להגדיר את מידרוג אוטומטי של האשכול כדי להוסיף או להסיר צמתים על סמך עומס העבודה או מדדים של Podים, או על סמך מדדים חיצוניים לאשכול.

מומלץ להגדיר את התנהגות ההתאמה האוטומטית לעומס על סמך מדדי אפליקציה מרכזיים, פרופיל העלויות ורמת המשאבים המינימלית הנדרשת שהגדרתם.

צמצום זמן ההפעלה

כדי שההתאמה תהיה יעילה, היא צריכה לקרות מספיק מהר כדי להתמודד עם העומס הגדל. זה נכון במיוחד כשמוסיפים יכולת חישוב או יכולת הצגה.

שימוש בתמונות מוכנות מראש

אם האפליקציה שלכם פועלת במכונות VM ב-Compute Engine, סביר להניח שתצטרכו להתקין תוכנה ולהגדיר את המכונות כדי להריץ את האפליקציה. למרות שאפשר להשתמש בסקריפטים להפעלה כדי להגדיר מכונות חדשות, דרך יעילה יותר היא ליצור תמונה מותאמת אישית. תמונה בהתאמה אישית היא דיסק אתחול שהגדרתם עם תוכנה והגדרות ספציפיות לאפליקציה.

מידע נוסף על ניהול תמונות זמין במאמר שיטות מומלצות לניהול תמונות.

אחרי שיוצרים את התמונה, אפשר להגדיר תבנית של הגדרות מכונה. תבניות של הגדרות מכונה משלבות את קובץ האימג' של דיסק האתחול, את סוג המכונה ומאפיינים אחרים של המכונה. אחר כך אפשר להשתמש בתבנית של הגדרות מכונה כדי ליצור מופעי מכונה נפרדים או קבוצת מופעי מכונה מנוהלים. תבניות של מכונות הן דרך נוחה לשמור את ההגדרה של מכונה וירטואלית, כדי שתוכלו להשתמש בה בהמשך כדי ליצור מכונות וירטואליות חדשות זהות.

יצירת תמונות בהתאמה אישית ותבניות של מכונות וירטואליות יכולה להגדיל את מהירות הפריסה, אבל היא גם יכולה להגדיל את עלויות התחזוקה כי יכול להיות שיהיה צורך לעדכן את התמונות בתדירות גבוהה יותר. מידע נוסף זמין במאמר בנושא איזון בין תצורת התמונה לבין מהירות הפריסה.

העברת האפליקציה לקונטיינר

אפשרות חלופית ליצירת מופעי מכונה וירטואלית בהתאמה אישית היא להשתמש בקונטיינרים של האפליקציה. קונטיינר הוא חבילת תוכנה קלה, עצמאית וניתנת להרצה, שכוללת את כל מה שצריך להרצת אפליקציה: קוד, זמן ריצה, כלי מערכת, ספריות מערכת והגדרות. המאפיינים האלה הופכים את האפליקציות שמבוססות על קונטיינרים לניידות יותר, קלות יותר לפריסה וקלות יותר לתחזוקה בקנה מידה גדול בהשוואה למכונות וירטואליות. בנוסף, בדרך כלל קונטיינרים מתחילים לפעול במהירות, ולכן הם מתאימים לאפליקציות שניתנות להרחבה ועמידות.

Google Cloud מציע כמה שירותים להרצת קונטיינרים של אפליקציות. ‫Cloud Run מספק פלטפורמת מחשוב מנוהלת בלי שרת (serverless) לאירוח קונטיינרים בלי שמירת מצב. בסביבת App Engine Flexible מתארחים הקונטיינרים שלכם בפלטפורמה כשירות (PaaS) מנוהלת. ‫GKE מספק סביבת Kubernetes מנוהלת לאירוח ולתזמור של אפליקציות בקונטיינרים. אפשר גם להריץ את הקונטיינרים של האפליקציה ב-Compute Engine כשרוצים שליטה מלאה בסביבת הקונטיינרים.

אופטימיזציה של האפליקציה להפעלה מהירה

בנוסף לוודאות שאפשר לפרוס את התשתית והאפליקציה בצורה יעילה ככל האפשר, חשוב גם לוודא שהאפליקציה תהיה זמינה באינטרנט במהירות.

האופטימיזציות שמתאימות לאפליקציה שלכם משתנות בהתאם למאפיינים של האפליקציה ולפלטפורמת ההפעלה שלה. חשוב לבצע את הפעולות הבאות:

  • כדי למצוא צווארי בקבוק ולפתור אותם, צריך ליצור פרופיל של הקטעים הקריטיים באפליקציה שמופעלים בהפעלה.
  • כדי לקצר את זמן ההפעלה הראשוני, כדאי להטמיע טכניקות כמו אתחול עצלני, במיוחד של משאבים יקרים.
  • מצמצמים את התלות באפליקציות שאולי צריך לטעון בזמן ההפעלה.

העדפה של ארכיטקטורות מודולריות

כדי להגדיל את הגמישות של האפליקציה, אפשר לבחור ארכיטקטורות שמאפשרות פריסה, ניהול והרחבה של רכיבים באופן עצמאי. הדפוס הזה יכול גם לשפר את העמידות על ידי ביטול נקודות כשל בודדות.

פירוק האפליקציה לשירותים עצמאיים

אם תתכננו את האפליקציה כקבוצה של שירותים עצמאיים בצימוד חלש, תוכלו להגדיל את הגמישות של האפליקציה. אם תבחרו בעיצוב עם צימוד חלש, תוכלו להפעיל ולפרוס את השירותים שלכם באופן עצמאי. בנוסף ליתרונות רבים אחרים, הגישה הזו מאפשרת לשירותים האלה להשתמש במערכות טכנולוגיות שונות ולצוותים שונים לנהל אותם. הגישה הזו בצימוד חלש היא הנושא המרכזי של דפוסי ארכיטקטורה כמו מיקרו-שירותים ו-SOA.

כשחושבים איך להגדיר גבולות לשירותים, דרישות הזמינות והמדרגיות הן מימדים חשובים. לדוגמה, אם לרכיב מסוים יש דרישת זמינות או פרופיל שינוי גודל שונים מהרכיבים האחרים, יכול להיות שכדאי להפוך אותו לשירות עצמאי.

שואפים למצב חסר מצב

אפליקציה או שירות בלי שמירת מצב לא שומרים נתונים או מצב מקומיים קבועים. מודל בלי שמירת מצב מבטיח שתוכלו לטפל בכל בקשה או אינטראקציה עם השירות באופן עצמאי, ללא תלות בבקשות קודמות. המודל הזה מאפשר יכולת הרחבה ושחזור, כי הוא מאפשר לשירות לגדול, להצטמצם או להפעיל מחדש בלי לאבד נתונים שנדרשים כדי לטפל בתהליכים או בבקשות שנמצאים בתהליך. בלי שמירת מצב חשוב במיוחד כשמשתמשים במידרוג אוטומטי, כי אפשר ליצור ולכבות סופית את המופעים, הצמתים או ה-Podים שמארחים את השירות באופן בלתי צפוי.

יכול להיות שלא תוכלו להפוך את כל השירותים שלכם לבלי שמירת מצב. במקרה כזה, חשוב לציין במפורש אילו שירותים דורשים מצב. הפרדה ברורה בין שירותים ללא מצב (stateless) לבין שירותים עם מצב (stateful) מאפשרת לכם להבטיח יכולת הרחבה פשוטה לשירותים ללא מצב, תוך אימוץ גישה מחושבת יותר לשירותים עם מצב.

ניהול התקשורת בין שירותים

אחד האתגרים בארכיטקטורות מבוזרות של מיקרו-שירותים הוא ניהול התקשורת בין השירותים. ככל שהרשת של השירותים גדלה, סביר להניח שגם התלות ההדדית בין השירותים תגדל. אתם לא רוצים שכשל בשירות אחד יוביל לכשל בשירותים אחרים, מצב שלפעמים נקרא כשל מדורג.

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

עיצוב לבדיקה

בדיקות אוטומטיות הן רכיב מרכזי בשיטות מודרניות של הכנת תוכנה להפצה. היכולת להריץ קבוצה מקיפה של בדיקות יחידה, בדיקות שילוב ובדיקות מערכת חיונית כדי לוודא שהאפליקציה מתנהגת כמצופה, ושהיא יכולה להתקדם לשלב הבא במחזור הפריסה. היכולת לבצע בדיקות היא קריטריון עיצוב חשוב לאפליקציה.

מומלץ להשתמש בבדיקות יחידה לרוב הבדיקות, כי הן מהירות לביצוע ובדרך כלל קל לתחזק אותן. מומלץ גם להפוך לאוטומטיות את הבדיקות של השילובים והמערכות ברמה גבוהה יותר. הבדיקות האלה פשוטות הרבה יותר אם משתמשים בטכניקות של תשתית כקוד, כי אפשר ליצור סביבות בדיקה ומשאבים ייעודיים לפי דרישה, ואז להסיר אותם אחרי שהבדיקות מסתיימות.

ככל שאחוז בסיס הקוד שמכוסה על ידי בדיקות עולה, כך מצטמצם חוסר הוודאות והפוטנציאל לירידה באמינות מכל שינוי בקוד. כיסוי בדיקות הולם מאפשר לבצע יותר שינויים לפני שהמהימנות יורדת מתחת לרמה מקובלת.

בדיקות אוטומטיות הן חלק בלתי נפרד מאינטגרציה רציפה (CI). הפעלת קבוצה חזקה של בדיקות אוטומטיות על כל קוד שמועבר למאגר מספקת משוב מהיר על שינויים, ומשפרת את האיכות והמהימנות של התוכנה. Google Cloud– כלים מקוריים כמו Cloud Build וכלים של צד שלישי כמו Jenkins יכולים לעזור לכם להטמיע אינטגרציה רציפה (CI).

אוטומציה של הפריסות

אינטגרציה רציפה ואוטומציה מקיפה של בדיקות מאפשרות לכם להיות בטוחים ביציבות של התוכנה. אחרי שהם מוגדרים, השלב הבא הוא אוטומציה של פריסת האפליקציה. רמת האוטומציה של הפריסה משתנה בהתאם לרמת הבשלות של הארגון.

בחירה של אסטרטגיית פריסה מתאימה היא חיונית כדי למזער את הסיכונים שקשורים לפריסה של תוכנה חדשה. באמצעות האסטרטגיה הנכונה, אפשר להגדיל בהדרגה את החשיפה של גרסאות חדשות לקהלים גדולים יותר, ולבדוק את ההתנהגות לאורך הדרך. אפשר גם להגדיר הוראות ברורות לשחזור אם מתעוררות בעיות.

אימוץ שיטות SRE להתמודדות עם כשלים

באפליקציות מבוזרות שפועלות בהיקף גדול, נפוץ שחלק מהרכיבים נכשלים. אם תאמצו את התבניות שמתוארות במסמך הזה, האפליקציה שלכם תוכל להתמודד טוב יותר עם שיבושים שנגרמים בגלל גרסת תוכנה פגומה, סיום לא צפוי של מכונות וירטואליות או אפילו הפסקה זמנית בשירות של תשתית שמשפיעה על אזור שלם.

עם זאת, גם אם תתכננו את האפליקציה בקפידה, בסופו של דבר תיתקלו באירועים לא צפויים שידרשו התערבות אנושית. אם תיישמו תהליכים מובנים לניהול האירועים האלה, תוכלו לצמצם באופן משמעותי את ההשפעה שלהם ולפתור אותם מהר יותר. בנוסף, אם תבדקו את הסיבות לאירוע ואת התגובות לו, תוכלו להגן על האפליקציה מפני אירועים דומים בעתיד.

תהליכים חזקים לניהול אירועים ולביצוע הסקת מסקנות לאחר האירוע ללא האשמות הם עקרונות מרכזיים ב-SRE. יכול להיות שיישום כל השיטות של Google SRE לא יהיה מעשי בארגון שלכם, אבל אם תאמצו אפילו קבוצה מינימלית של הנחיות, תוכלו לשפר את חוסן (resilience) האפליקציה. בנספחים של הספר בנושא SRE יש כמה תבניות שיכולות לעזור לכם לעצב את התהליכים שלכם.

אימות ובדיקה של הארכיטקטורה

האפליקציה מתפתחת, והתנהגות המשתמשים, פרופילי התנועה ואפילו סדרי העדיפויות העסקיים יכולים להשתנות. באופן דומה, שירותים או תשתיות אחרים שהאפליקציה שלכם תלויה בהם יכולים להתפתח. לכן חשוב לבדוק מדי פעם את העמידות והמדרגיות של האפליקציה ולאמת אותן.

בדיקת החוסן

חשוב מאוד לבדוק שהאפליקציה מגיבה לכשלים בצורה שציפיתם. הנושא המרכזי הוא שהדרך הטובה ביותר להימנע מכישלון היא להכיר את הכישלון וללמוד ממנו.

הסימולציה של כשלים והצגתם היא תהליך מורכב. בנוסף לאימות ההתנהגות של האפליקציה או השירות, צריך גם לוודא שהתראות צפויות נוצרות ושמדדים מתאימים נוצרים. מומלץ להשתמש בגישה מובנית, שבה מתחילים עם כשלים בסיסיים ואז עוברים לכשלים מורכבים יותר.

לדוגמה, אפשר לפעול באופן הבא, ולאמת ולתעד את ההתנהגות בכל שלב:

  • הוספת כשלים לסירוגין.
  • חסימת הגישה לתלות של השירות.
  • חסימת כל התקשורת ברשת.
  • למחוק את המארחים?

פרטים נוספים זמינים בסרטון Breaking your systems to make them unbreakable מ- Google Cloud Next 2019.

אם אתם משתמשים ב-Service mesh כמו Istio כדי לנהל את שירותי האפליקציה, אתם יכולים להחדיר תקלות בשכבת האפליקציות במקום להשבית Podים או מכונות, או להחדיר מנות פגומות בשכבת ה-TCP. אתם יכולים להוסיף השהיות כדי לדמות חביון ברשת או מערכת עליונה שעמוסה מדי. אפשר גם להגדיר ביטולים, שמדמים כשלים במערכות במעלה הזרם.

בדיקת התנהגות ההתאמה לעומס

מומלץ להשתמש בבדיקות אוטומטיות לא פונקציונליות כדי לוודא שהאפליקציה ניתנת להרחבה כמצופה. לעתים קרובות האימות הזה משולב עם בדיקות ביצועים או בדיקות עומס. אפשר להשתמש בכלים כמו hey כדי לשלוח עומס לאפליקציית אינטרנט. דוגמה מפורטת יותר שמראה איך לבצע בדיקת עומס מול נקודת קצה של REST זמינה במאמר בדיקת עומס מבוזרת באמצעות Google Kubernetes Engine.

גישה נפוצה אחת היא לוודא שהמדדים המרכזיים נשארים ברמות הצפויות בעומסים שונים. לדוגמה, אם בודקים את יכולת ההתאמה של שכבת האינטרנט, אפשר למדוד את חביון הבקשות הממוצע עבור נפחים משתנים של בקשות משתמשים. באופן דומה, כשמדובר בתכונה לעיבוד בקצה העורפי, אפשר למדוד את הזמן הממוצע לעיבוד משימות כשנפח המשימות גדל באופן פתאומי.

בנוסף, כדאי שהבדיקות ימדדו את מספר המשאבים שנוצרו כדי לטפל בעומס הבדיקה, ויוודאו שהוא נמצא בטווח הצפוי. לדוגמה, יכול להיות שהבדיקות שלכם יאמתו שמספר המכונות הווירטואליות שנוצרו כדי לטפל במשימות מסוימות בעורף לא חורג מערך מסוים.

חשוב גם לבדוק מקרים קיצוניים. מה קורה באפליקציה או בשירות כשמגיעים למגבלות המקסימליות של שינוי הגודל? מה קורה אם השירות שלך מצטמצם ואז העומס גדל שוב באופן פתאומי?

תמיד לתכנן את הארכיטקטורה

העולם הטכנולוגי מתקדם בקצב מהיר, וזה נכון במיוחד לגבי הענן. מוצרים ותכונות חדשים יוצאים לשוק לעיתים קרובות, דפוסים חדשים צצים, והדרישות מהמשתמשים ובעלי העניין הפנימיים ממשיכות לגדול.

כפי שמוגדר בפוסט בבלוג בנושא עקרונות לארכיטקטורה מבוססת-ענן, חשוב תמיד לחפש דרכים לשפר, לפשט ולעדכן את הארכיטקטורה של האפליקציות. מערכות תוכנה הן ישויות חיות שצריכות להתאים את עצמן לשינויים בסדרי העדיפויות שלכם.

המאמרים הבאים