כשמריצים מחסנית של אפליקציות על משאבים מבוזרים בענן, תעבורת הרשת צריכה להיות מנותבת בצורה יעילה למשאבים הזמינים בכמה מיקומים. בחלק הזה של Google Cloud המדריך לאמינות התשתית מתוארות טכניקות לניהול תעבורה ועומסים, שבעזרתן אפשר לשפר את האמינות של עומסי העבודה בענן.
תכנון קיבולת
כדי לוודא שלאפליקציה שפרסתם ב- Google Cloud יש מספיק משאבי תשתית, אתם צריכים להעריך את הקיבולת הנדרשת ולנהל את הקיבולת שנפרסה. בקטע הזה מפורטות הנחיות שיעזרו לכם לתכנן ולנהל את הקיבולת.
תחזית של עומס האפליקציה
כשמבצעים תחזית לגבי העומס, צריך לקחת בחשבון גורמים כמו מספר המשתמשים והקצב שבו האפליקציה עשויה לקבל בקשות. בתחזיות, כדאי להתייחס למגמות היסטוריות של עומס, לשינויים עונתיים, לעליות חדות בעומס במהלך אירועים מיוחדים ולצמיחה שנובעת משינויים עסקיים כמו התרחבות לאזורים גיאוגרפיים חדשים.
הערכת דרישות הקיבולת
על סמך ארכיטקטורת הפריסה שלכם, ובהתחשב ביעדי הביצועים והמהימנות של האפליקציה, צריך להעריך את כמות המשאבים מסוגGoogle Cloud שנדרשים לטיפול בעומס הצפוי. לדוגמה, אם אתם מתכננים להשתמש בקבוצות של מופעי מכונה מנוהלים (MIG) ב-Compute Engine, אתם צריכים להחליט על הגודל של כל MIG, על סוג המכונה הווירטואלית ועל המספר, הסוג והגודל של הדיסקים הקשיחים הקבועים. אפשר להשתמש בGoogle Cloud מחשבון עלויות כדי להעריך את העלות של משאבי Google Cloud .
תכנון יתירות מספקת
כשמעריכים את דרישות הקיבולת, חשוב לספק יתירות מספקת לכל רכיב במערך היישומים. לדוגמה, כדי להשיג יתירות N+1, כל רכיב במערך האפליקציה צריך לכלול לפחות רכיב יתיר אחד מעבר למינימום הנדרש לטיפול בעומס התחזית.
השוואה בין ביצועי האפליקציה לבין ביצועים של אפליקציות אחרות
להריץ בדיקות עומס כדי לקבוע את יעילות המשאבים של האפליקציה. יעילות המשאבים היא היחס בין העומס על האפליקציה לבין המשאבים שהאפליקציה צורכת, כמו מעבד (CPU) וזיכרון. יעילות השימוש במשאבים של אפליקציה יכולה להיפגע כשהעומס גבוה במיוחד, והיעילות עשויה להשתנות לאורך זמן. מומלץ לבצע בדיקות עומס בתנאים של עומס רגיל ושל עומס שיא, ולחזור על בדיקות ההשוואה במרווחי זמן קבועים.
ניהול מכסות
Google Cloud מכסות של שירותים הן מגבלות לכל פרויקט, שעוזרות לכם לשלוט בצריכת משאבי הענן. יש שני סוגים של מכסות: מכסות משאבים הן המשאבים המקסימליים שאפשר ליצור, כמו מספר אשכולות Google Kubernetes Engine (GKE) אזוריים באזור מסוים. מכסות לקצב שליחת בקשות מגבילות את מספר בקשות ה-API שאפשר לשלוח לשירות מסוים בפרק זמן מסוים. המיכסות יכולות להיות אזוריות, גלובליות או לפי אזור. מומלץ לבדוק את מכסות המשאבים הנוכחיות ואת מכסות הקצב של יצירת בקשות ל-API בשירותים שאתם מתכננים להשתמש בהם בפרויקטים. מוודאים שהמכסות מספיקות לקיבולת שאתם צריכים. במקרה הצורך, אפשר לבקש להגדיל את המכסה.
שמירת קיבולת מחשוב
כדי לוודא שהקיבולת של משאבי Compute Engine זמינה כשצריך, אפשר ליצור הזמנות. הזמנה מספקת קיבולת מובטחת באזור ספציפי למספר מסוים של מכונות וירטואליות מסוג מכונה שתבחרו. אפשר להגדיר הזמנה ספציפית לפרויקט, או לשתף אותה בין כמה פרויקטים. מידע נוסף על הזמנות זמין במאמר בנושא בחירת סוג הזמנה.
מעקב אחרי הניצול והערכה מחדש של הדרישות מעת לעת
אחרי שפורסים את המשאבים הנדרשים, עוקבים אחרי ניצול הקיבולת. יכול להיות שתזהו הזדמנויות לאופטימיזציה של העלויות על ידי הסרת משאבים לא פעילים. חשוב להעריך מחדש את דרישות הקיבולת באופן תקופתי, ולשקול שינויים בהתנהגות האפליקציה, ביעדי הביצועים והמהימנות, בעומס המשתמשים ובתקציב ה-IT.
התאמה אוטומטית לעומס (Automatic scaling)
כשמריצים אפליקציה במשאבים שמפוזרים בכמה מיקומים, האפליקציה נשארת זמינה גם אם יש הפסקות חשמל באחד מהמיקומים. בנוסף, יתירות עוזרת להבטיח שהמשתמשים יחוו התנהגות עקבית של האפליקציה. לדוגמה, כשיש עלייה פתאומית בעומס, המשאבים העודפים מבטיחים שהאפליקציה תמשיך לפעול ברמה צפויה. אבל כשהעומס על האפליקציה נמוך, יתירות עלולה לגרום לניצול לא יעיל של משאבי הענן.
לדוגמה, יכול להיות שרכיב עגלת הקניות באפליקציית מסחר אלקטרוני צריך לעבד תשלומים עבור 99.9% מההזמנות תוך 200 אלפיות השנייה אחרי אישור ההזמנה. כדי לעמוד בדרישה הזו בתקופות של עומס גבוה, יכול להיות שתצטרכו להקצות קיבולת מיותרת של מחשוב ואחסון. אבל כשהעומס על האפליקציה נמוך, יכול להיות שחלק מהקיבולת שהוקצתה לא ישמש אתכם או שתנצלו אותה באופן חלקי. כדי להסיר את המשאבים שלא נמצאים בשימוש, צריך לעקוב אחרי השימוש ולהתאים את הקיבולת. התאמה אוטומטית לעומס (autoscaling) עוזרת לכם לנהל את הקיבולת בענן ולשמור על רמת הזמינות הנדרשת בלי להוסיף עלויות תפעול של ניהול משאבים מיותרים. כשהעומס על האפליקציה גדל, התאמה אוטומטית לעומס (autoscaling) עוזרת לשפר את הזמינות של האפליקציה על ידי הקצאה אוטומטית של משאבים נוספים. במהלך תקופות של עומס נמוך, התאמה אוטומטית לעומס מסירה משאבים לא בשימוש, ועוזרת להפחית את העלויות.
בשירותים מסוימים של Google Cloud , כמו Compute Engine, אפשר להגדיר התאמה אוטומטית לעומס של המשאבים שמקצים. שירותים מנוהלים כמו Cloud Run יכולים להגדיל את הקיבולת באופן אוטומטי בלי שתצטרכו להגדיר משהו. דוגמאות ל Google Cloud שירותים שתומכים בהתאמה אוטומטית לעומס. זו רשימה חלקית.
- Compute Engine: קבוצות של מכונות מנוהלות (MIG) מאפשרות לכם לשנות את גודלן של אפליקציות חסרות מצב (stateless) שפריסתן מתבצעת במכונות וירטואליות של Compute Engine באופן אוטומטי, כך שהקיבולת תתאים לעומס הנוכחי. מידע נוסף זמין במאמר בנושא קבוצות של מופעים עם שינוי גודל אוטומטי.
- GKE: אפשר להגדיר אשכולות GKE כך שגודל מאגרי הצמתים ישתנה אוטומטית בהתאם לעומס הנוכחי. מידע נוסף זמין במאמר בנושא מידרוג אוטומטי של אשכול. באשכולות GKE שמוקצים במצב Autopilot, המערכת מתאימה אוטומטית את הצמתים ואת עומסי העבודה לעומס התנועה.
- Cloud Run: שירותים שאתם מקצים ב-Cloud Run מתרחבים אוטומטית למספר המכונות של הקונטיינרים שדרוש לטיפול בעומס הנוכחי. כשהאפליקציה לא טוענת, השירות מצמצם אוטומטית את מספר מופעי הקונטיינר לאפס. מידע נוסף זמין במאמר בנושא שינוי אוטומטי של גודל מופע המאגר.
- פונקציות Cloud Run: כל בקשה לפונקציה מוקצית למופע של הפונקציה. אם נפח הבקשות הנכנסות חורג ממספר המופעים הקיימים של הפונקציה, פונקציות Cloud Run מפעילות אוטומטית מופעים חדשים של הפונקציה. מידע נוסף זמין במאמר בנושא סביבת ההפעלה של פונקציות Cloud Run.
- Bigtable: כשיוצרים אשכול במופע Bigtable, אפשר להגדיר את האשכול כך שגודלו ישתנה באופן אוטומטי. Bigtable עוקב אחרי העומס על המעבד ועל נפח האחסון, ומשנה את מספר הצמתים באשכול כדי לשמור על שיעורי הניצול של משאבי המטרה שציינתם. מידע נוסף זמין במאמר בנושא שינוי גודל אוטומטי ב-Bigtable.
- Google Cloud Serverless for Apache Spark: כששולחים עומס עבודה של Apache Spark batch, Google Cloud Serverless for Apache Spark משנה את קנה המידה של משאבי עומס העבודה באופן דינמי, כמו מספר תהליכי הביצוע, כדי להריץ את עומס העבודה בצורה יעילה. מידע נוסף זמין במאמר בנושא Google Cloud Serverless for Apache Spark for Spark autoscaling.
איזון עומסים
איזון עומסים עוזר לשפר את האמינות של האפליקציה על ידי ניתוב התנועה רק למשאבים הזמינים, ועל ידי הבטחה שמשאבים ספציפיים לא יהיו עמוסים מדי.
כשבוחרים ומגדירים מאזני עומסים לפריסה בענן, כדאי להביא בחשבון את ההמלצות הבאות בנוגע לאמינות.
איזון עומסים של תנועה פנימית
כדאי להגדיר איזון עומסים גם לתנועת הגולשים בין השכבות של מחסנית האפליקציות, ולא רק לתנועת הגולשים בין הלקוחות החיצוניים לבין האפליקציה. לדוגמה, במערך של אפליקציית אינטרנט בת 3 שכבות, אפשר להשתמש במאזן עומסים פנימי כדי ליצור תקשורת מהימנה בין שכבות האינטרנט והאפליקציה.
בחירת סוג מתאים של מאזן עומסים
כדי לאזן עומסים של תנועה חיצונית לאפליקציה שמפוזרת על פני כמה אזורים, אפשר להשתמש במאזן עומסים גלובלי או בכמה מאזני עומסים אזוריים. מידע נוסף זמין במאמר היתרונות והסיכונים של איזון עומסים גלובלי בפריסות מרובות אזורים.
אם השרתים העורפיים נמצאים באזור יחיד ואתם לא צריכים את התכונות של איזון עומסים גלובלי, אתם יכולים להשתמש במאזן עומסים אזורי, שהוא עמיד להפסקות זמניות של אזורים.
כשבוחרים את סוג מאזן העומסים, צריך לקחת בחשבון גורמים נוספים מלבד הזמינות, כמו שליטה גיאוגרפית בסיום TLS, ביצועים, עלות וסוג התנועה. מידע נוסף זמין במאמר בנושא בחירת מאזן עומסים.
הגדרת בדיקות תקינות
התכונה 'שינוי קנה מידה אוטומטי' עוזרת לוודא שיש לאפליקציות שלכם מספיק משאבי תשתית כדי להתמודד עם העומס הנוכחי. אבל גם אם יש מספיק משאבי תשתית, יכול להיות שאפליקציה או חלקים ממנה לא יגיבו. לדוגמה, כל המכונות הווירטואליות שמארחות את האפליקציה שלכם עשויות להיות במצב RUNNING. אבל יכול להיות שתוכנת האפליקציה שנפרסה בחלק מהמכונות הווירטואליות קרסה.
בדיקות תקינות של איזון עומסים
מוודאות שמאזני העומסים מנתבים את תעבורת האפליקציות רק לקצוות העורפיים
שמגיבים. אם ה-backend שלכם הוא MIG, כדאי להגדיר שכבת בדיקות תקינות נוספת כדי לתקן באופן אוטומטי את מכונות ה-VM שלא זמינות. כשמגדירים תיקון אוטומטי לקבוצת מופעים מנוהלת (MIG), מכונות ה-VM שלא זמינות נמחקות באופן יזום, ונוצרות מכונות VM חדשות.
הגבלת קצב של יצירת בקשות
לפעמים, יכול להיות שיהיה באפליקציה שלכם גידול מהיר או מתמשך בעומס. אם האפליקציה לא מתוכננת להתמודד עם העומס המוגבר, יכול להיות שהיא או המשאבים שבה ישתבשו, והיא לא תהיה זמינה. העומס המוגבר עשוי להיגרם מבקשות זדוניות, כמו מתקפות מבוזרות של מניעת שירות (DDoS) שמבוססות על רשת. עלייה פתאומית בעומס יכולה להתרחש גם בגלל סיבות אחרות, כמו שגיאות בהגדרות של תוכנת הלקוח. כדי לוודא שהאפליקציה יכולה להתמודד עם עומס יתר, כדאי להשתמש במנגנונים מתאימים להגבלת קצב הבקשות. לדוגמה, אתם יכולים להגדיר מכסות למספר בקשות ה-API ששירות מסוים יכול לקבל. Google Cloud
טכניקות להגבלת קצב יכולות גם לעזור לכם לבצע אופטימיזציה של העלות של תשתית הענן. לדוגמה, אם מגדירים מכסות ברמת הפרויקט למשאבים ספציפיים, אפשר להגביל את החיוב שהפרויקט יכול לצבור על המשאבים האלה.
Network Service Tier
Google Cloud מסלולי שירות הרשת מאפשרים לכם לבצע אופטימיזציה של הקישוריות בין מערכות באינטרנט לבין עומסי העבודה שלכם ב-Google Cloud . אם יש לכם אפליקציות שמשרתות משתמשים ברחבי העולם ויש להן בק-אנד ביותר מאזור אחד, כדאי לבחור במסלול פרימיום. תעבורת נתונים מהאינטרנט נכנסת לרשת עם הביצועים המיטביים של Google ב-point of presence (PoP) שהכי קרובה למערכת ששלחה אותה. ברשת של Google, תעבורת הנתונים מנותבת מנקודת הכניסה (PoP) למשאב המתאים, כמו מכונה וירטואלית ב-Compute Engine. Google Cloud תעבורת נתונים יוצאת נשלחת דרך הרשת של Google ויוצאת בנקודת ה-PoP שהכי קרובה ליעד. שיטת הניתוב הזו עוזרת לשפר את תפיסת הזמינות של המשתמשים באמצעות הפחתה של מספר הצעדים ברשת בין המשתמשים לנקודות ה-PoP שהכי קרובות אליהם.